While they are maintained in codeunit 12, they are controlled by field values that are passed with the journal entry. Whenever the document number, document type or posting date changes you get a new transaction number. In the case of the unapply process, the UnapplyCustLedgEntry and UnapplyVendLedgEntry call the posting process but, in the cases I tested, don't actually create an entry. That is not to say they won't ever create one but they didn't in the cases I tried. In version 2013, the check management process was changed so that the document type being unapplied (like Payment or Refund) is now specified in the GL entries that are created. The problem is, they left it out of the two functions I mentioned. This means that the unapply process might call CU12 once with a document type of payment, once with a document type of blank and then again with a document type of payment. The result is that you end up with two entries spanning 3 transaction numbers. Most people won't notice it but we have an installation exporting to a parent company using SAP. They are importing the NAV entries mapping the transaction number to the corresponding field in SAP. The out of balance transactions were causing them quite a bit of concern.
↧