We have been live in Navision for three years, but have yet to receive documentation or training on reversing customer payments. Two solution centers have not even been able to tell us how to do this. I cannot believe that an Accounting package selling in the United States for at least five years has no way to reverse payments! Currently our Accounts Receivable Department enters a bounced check, chargeback, etc. as an INVOICE Sales Journal document type because Navision will not allow document type Payments to be entered as Debits - regardless of whether you enter a positive number in Amount or Debit Amount field or a negative in Credit Amoount field. Is my company the first ever to have customer checks bounce or credit card chargebacks or checks from customers sent to the wrong people? Unfortunately our solution (INVOICE entries) means that the President of the company thinks we have more sales than we really do because of these entries looking just like INVOICES.[:(!][:(!][:(!]
Sean, unfortunately this is quite a common problem as you might notice on doing a search on “void payment” in this forum…[xx(] and you might find some hints on how to deal with this issue, and find references to Addons that have been developed by certain NSCs. By the way, Attain does have a new doc type “Refund” to deal with this issue. Our localized version can handle this with debit notes, which have the same effect as invoices but can be easily filtered in reports and statistics. Saludos Nils
Ah! Unfortunately we are only using 2.5 client-side executables and not yet 2.6 on server side (it might even be 2.0). We have a programming license but not the highest level license… can we create a new document type ourselves, and what would the ripple effect be? Once upon a time the blank document type was used, but we found that messed things up worse, because such transactions sometimes “hid” themselves or included themselves in odd places. Speaking of Debit Memos (is this the same thing as Debit Notes?) - how do we do those on both the Payables AND Receivables sides? And has anyone cornered Navision themselves and asked them where they parked their brains the day they had to deal with Payment Journals? Maybe in Denmark there are no bounced checks or chargebacks, but does no on in Denmark (or anywhere else they have been for at least five years) ever reverse payments? This sounds somewhat rude - and it is - my Account Receivable group has complained about this quite a while. I am about ready for some cheese to go with their whining.
Sean, I believe your process is wrong and I can understand people being upset at effectively reposting invoices to regain a balance on the customer account. Sales reporting must be a nightmare - I’m sure the auditors must have said something! The easiest way to ‘cancel’ the customers payment is to post a cash receipt journal for the customer with the Document Type field as ‘Blank’. The value of the bounced payment should be entered as a positive amount. This process effectively cancels the payment, but do bear in mind that it does not ‘unallocate’ the invoices that the original (now bounced) payment was posted to. Hope this helps.
We had at one time been using the blank document type, but had problems because certain things (reports, code, etc.) do not include the blanks. I do not know if native accounting modules, reports, etc. will see blanks and account for them as essentially payment types. The other problem we had is: all difficult to categorize entries were given doc type blank. We ended up with some blanks being payment data while others were revenue and yet others were adjustments to customer. This is a serious oversight that should have been accounted for by allowing some way to either “cancel” or “reverse” a payment and having native (and unmodifiable by anyone short of solution center) code take care of doc type, debit vs. credit amount, etc. Such code could restrict users to reversing ONLY existing payments. Another solution would have been for Navision to allow debit payments when that doc type is selected, or have a reverse payment doc type. My question still stands… does no one in Denmark ever reverse a payment? Another issue is whether blank doc type impacts balance due and ONLY balance due, while leaving revenue and sales figures unaffected.
After investigating this situation, I have found that the “G/L Entries” table has records of Document Type “Payment” with Amount positive! I then checked the “Gen. Journal Line” and “Cust. Ledger Entries” tables and found that there does not appear to be anything in either table to prevent positive amount Payment doc types. I looked at the “Cash Receipts Journal” form, then ran Post & Print with Debugger working and found that CodeUnit 11 is where the process is stopped for trying to create Payments with positive Amount (the Error message appears here). My next step will be to copy CodeUnit 11 to a new CodeUnit and remove the obstacle, then modify Cash Receipts Journal - however necessary - to actually hit my new CodeUnit instead of 11. I may have to do this kind of thing several times to make sure I remove all obstacles - I WILL create a Cust. Ledger Entry of Document Type Payment where Amount is positive… in our test db of course. That will be a tedious theoretical exercise… now - what will the ramifications be? Will I end up with trouble dealing with Financials, collections and other things just because the Amount of a Cust. Legder Entry Payment is positive? Will the “Cash Flow Statement - Detail” be messed up? What about the “Income Statement - Summary”, or “Aged Accounts Receivable” or an order’s Balance Due?
The way I have tackled this issue is to do a Cash Receipts Journal leaving the entry type and marking the ‘correction’ column in order to identify the debit transaction as a reversal. You need to make this column visible first. You can further create a new source code and attach a template to it specifically designed for corrections. However this means the reports that management/auditors review, need to see the correction column as well in their reports. This means a slight customization in the detailed trial balance reports. Fortunately 3.60 has ‘Refund’ added to the entry types which makes it easier.
Sean, at first sight your idea to “desactivate” that validation in C11 sounds ok and as far as I know C12 (the gl posting codeunit) there shouldn’t be any problem - don’t take it for granted though. [;)] As payments do not include any taxes and stuff, there are no problems from that side, but as you point out yourself… thorough testing before you include your changes in the hot database. Saludos Nils
Hi Sean Instead of changing the codeunit etc, have you used the Reason Code field. Setup a batch for reversing customer payments and set a reason code e.g. Custrev. The reason code can then be used for filtering on in the G/L or in Sales & Receivables for on screen inquiries or reports. Cheers Peter
My biggest concern with using any workaround that involves a document type other than Payment, is that there ends up being a prohibitively and grotesquely extensive customization involved with making sure that any and all parts of Navision that refer to Cust. Ledger Entries and G/L Entries tables properly account for how to deal with the blank Document Type. Here is the problem with using the poorly defined “Blank” “Document Type”… Blank document type record 1 is a customer note, the next is a payment REVERSAL while the one following is a payment someone made a mistake on - they forgot to enter a document type. The fourth blank is a credit memo that someone else goofed up and the one after is the correction of the credit memo mistake. Six through nine are invoices that someone created when they weren’t feeling well, so they missed a step (entering Document Type). Blanks ten through fifteen are entries from a previous legacy system when document types did not exist, and sixteen is to account for an old invoice for which we are still awaiting payment, but we cannot show it as a real invoice, but have to show something on the customer card. Payments should be document type Payment… reversals of payments should be document type “Payment”, “Debit Memo” or “Payment Reversal”. They are common enough in the United States - the country in which my employer purchased a product which was modified sufficiently for the U.S. market to make it worth considering in the U.S. market. Why could they not ensure that their product was adequately ready for US market???
Another way can be adding a new type to the g/l journal lines for your refunds and also to the g/l ledger entries and change the posting and check line codeunits to handle that new type as blank when posting but keeping the g/l ledger entries with that new type as document type.That can help you on filtering. Regards,
Hi, I have brought this topic back due to the fact that 3.7 is out now. I was wondering if 3.7 has come up with a solution to this problem. It really should be as easy as www.simcrest.com void check granule. So do I still have a need to purchase this granule or does 3.7 have a better solution than 3.1?