We seem to have what I think is a problem when suggesting vendor payments in the payment journal. We use Navision 2.6e on SQL 2000. After we suggest the vendor payments, which we also use an automatic numbering sequence for the document #, instead of getting a single document number for each vendor, we get two on some of them. The vendors that it seems to occur on are the ones that have a credit memo applied to their account. I then instruct the AP person to manually renumber those entries that are wrong, because we get errors when trying to print the checks that the amount can’t be a negative number. True enough, but it seems that Navision should be combining these entries together to generate one check a piece. Our NSC is looking in to it, as they could not immediately explain it. We are not using the Summarize per Vendor or New Doc No per Line functions of the suggest vendor payments. Anyone have any experience on this issue and how to fix it?
Hi Obviously using the summarize by Vendor routine would solve this problem, as it would be the total payment owed to the vendor less any open credit memos. The remittance advice would then show the unapplied credit memo netted off against the full payment. If you need the true detail of the line information I suggest you apply the open credit on account to an invoice, as this will alter the remaining amount and solve your problem. I think this is just the standard way Navision handles open credit notes on a vendors account, arguably not a correct way - but what should the system do - simply ignore unapplied credits on account? You could feasibly write a mod to handle this, but you may end up paying suppliers invoices in full when in reality there is a credit memo against them, so you would have to ask for a credit on a credit which could get very messy. Ultimately the system can handle this correctly in a number of processing ways, is there an overriding business reason why one of these cannot be adopted? I suggest wherever possible the credit memo is applied to the relevant invoice, the others are handled by exception - unless you want to go to the extent of writing a mod, which I feel, personally would be an unnecessary expense. Have fun! Steve
Thanks for the advice. I tried to do the summarize by Vendor option, and also had some problems with it on the posting end. Can’t remember what the exact problem was right now, but it had something to do with the fact that you can’t post entries that were already applied or something like that. And we do want the detail. The main reason that we have credits against accounts is that we just moved to Navision from an old system, and not all of the invoices from the previous system were carried over, and unfortunately we need to credit some of those invoices that are not in the system.
I think that this may be a related issue…Version 2.6 Canadian A client using both departments and projects used Suggest Vendor Payments and entered a document number into the Starting Document No. field on the Options tab. They did not check Summarize by Vendor. They did not have a number series on the Payment Journal batch. The result was a unique document number in the Payments Journal for every combination of vendor number, department and project. This would have led to multiple cheques per vendor. We corrected the problem by removing the starting document number. However, this worked when the currency was the local currency. We were forced to use Summarize by Vendor for non-local currency because we experienced rounding errors. Hope this helps!
We use Navision US 2.00 and it does the same thing. The problems is related to the department and project codes. The solution is to just not use document number when running the suggest payment routine. Then when you print the checks, you select One check per Vendor and document number, this produces one check per vendor with all the detail lines listed, including unapplied credit memos. It requires no modifications. If you must assign a document number before hand ( there is no reason you have to) you can modify report 393 (Suggest Vendor payments) to comment out the lines in the cal code // GenJnlLine3.SETRANGE(“Department Code”,VendLedgEntry.“Department Code”); // GenJnlLine3.SETRANGE(“Project Code”,VendLedgEntry.“Project Code”); This two line cause a new document number per department and per project code. David Mavis