Has anyone worked around the limitation whereby you cannot mix the documents you are applying a payment/credit too?
Forgot to mention that the application will involve more that one currency
Hi Simon Could you just describe a mini example for me [:D]. Payment of £1000.00 covering an invoice for €800.00 and an invoice for $650.00?
Completely made up! posting date type doc currency amount 01/07/03 credit 104020 usd -117.50 01/07/03 credit 104021 rur -235.00 01/06/03 invoice 104022 ikr 587.50 The error is “The selected credit memo 104021 applies to credit memo 104020 which has the same sign. You can within one posting only apply - a single credit transaction to multiple debit transaction, or …”
Hi Simon You’ll kick yourself because this is SO silly [:D] When you are posting the application in your example the cursor is on one of the credit memos. Click onto the invoice line, it will post fine! I think it is the starting point and reading down - the techies could answer it better, but it tries to apply the credit memo to the credit memo, if the cursor is on the invoice it applies the invoice to the credit memo and then the invoice to the other credit memo. Its the little things that are sent to try us! [:D]
Hi, actually this is a bug fix from version 2.60… in that version it is possible to apply the way Simon describes it: mark invoice (nº1), mark credit note (nº2), mark credit note (nº3), and register, which will result in a quite messy “application” trail… you will have the last credit note (3) being applied to an invoice (1) and another credit note (2), and especially the invoice (1) will only be applied to one single credit note (3). All this is independent from the currency, currency diferences are simply calculated by differences between the "remaining amounts (LCY). This strange behaviour has to do with the “Apply to” functions in C12 and the way the different record get their “Closed by Entry Nº” - to make it short, always the “opposing” entry get’s the “Closed by Entry Nº”, given that it get’s closed completly. Therefore, given Simon’s example and supposing the the entry sum up completly, the credit note 3 would have “Closed by Entry Nº” = 0, the invoice 1 would have “Closed by Entry Nº” = 3 and the other credit note 2 will also have “Closed by Entry Nº” = 3. Therefore, the error message is a simple bug fix that will not allow the users to register the multiple entries side of an application, but instead forcing them to mark the opposed document type. Hope I made myself understood… [:D] By the way, thank’s for the “techie” comment, I’ll take it as an compliment [;)] Saludos Nils
Hi Nils I think you thoroughly vindicated my comment - and yes it is a compliment [:D] (I felt nervous enough just posting in the developers forum [;)]) You also illustrated the history of the bug - I just knew the oddity it had become - Simon’s application is possible, it just has to be done in the right way!
Ok. Understand the first solution. We also have the situation where there are multiple credits and debits being applied against one another. Perhaps we’ll leave this for now. Thanks for the help guys!
Sorry, I have to argue the point here[}:)], and Nils you know exactly what I am talking about… When these guys call us “techies”, they don’t mean it as a compliment…[:D]
Hi David I see you posted lots yesterday, so maybe you were tired! In your opinion you may disagree but as the author, it was a compliment. Many in the Navision world like to dabble in programming when they do not have the experience, knowledge and education, and in many parts of the world this has lead to poor implementations (We have all come across them I am sure). I would prefer to leave the development to the developers. I can see the error described here and I know a way around it - as for venturing into the code I will leave that to the “techies” or simply people more technical than myself! [:D] Anyway I am British, of course I would never purposely offend anyone [:D]