tag:blogger.com,1999:blog-6764383762615376176.post7231193351014054869..comments2023-09-26T02:05:11.867+13:00Comments on TharangaC: Error : The transaction cannot be completed because it will cause inconsistencies - NAV 2009 SP 01 | NAV 2009 R2TharangaChttp://www.blogger.com/profile/11987354478263235046noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-6764383762615376176.post-35203019934197979892016-06-22T16:25:33.877+12:002016-06-22T16:25:33.877+12:00Let me check on that and get back to you.Let me check on that and get back to you.Soul Whisperhttps://www.blogger.com/profile/01474211029817995499noreply@blogger.comtag:blogger.com,1999:blog-6764383762615376176.post-52344087400864943742016-06-21T21:28:09.514+12:002016-06-21T21:28:09.514+12:00Are these codes compatible with 2015 version?Are these codes compatible with 2015 version?Priyanga de Silvanoreply@blogger.comtag:blogger.com,1999:blog-6764383762615376176.post-42899224099922310242014-10-25T09:16:37.682+13:002014-10-25T09:16:37.682+13:00Hi Tharanga,
a few comments on this, as discussed...Hi Tharanga,<br /><br />a few comments on this, as discussed:<br /><br />the hotfix you mention is only a hotfix, not a fix for the underlying issue. When you apply it, the unapply posting wil go through alright, but the resulting additional reporting currency (ACY) amounts can be wrong in the end. That's not always good ;)<br /><br />I try to explain it, it's a little complicated. The ACY handling in codeunit 12 is not complete, they are tinkering on it since the 2013 version on almost every other Cumulative Update. In the NAV3,NAV4,NAV5,NAV2009 code base, it's also a little bit like layer cake, it's bugs on bugs that normally cancel each other out, but not always.<br /><br />Root cause is the "wrong" dependency between GenJnlLine."Source Currency Code", InitGLEntry() and CalcAddCurrency(). Add to this missing ACY amounts in the customer/vendor ledger entries and detailed entries. How ACY gets calculated on the GLEntry level depends on "Source Currency Code". If it is just empty (but the source cust/vend ledger entry has a currency code), this leads to a different calculation. If the currency code should be the same as ACY code, the the amount will be used unchanged. And now you have several combinations, where sometimes the "right" combination is used and sometimes not. In a small percentage of these cases, you will get the consistency check error.<br /><br />Back to the hotfix: This forces the calculation of the ACY from the LCY values on the GLEntry level, regardless of the ACY values generated on the cust/vend ledger level. So, this will (almost) always be consistent, but depending on the currency code of the cust/vend ledger entry and if ACY is used the ACY value in the G/L can be really wrong. The only way to cleanly solve this is to set up source currency code for the corresponding det. entry buffer before every InitGLEntry() or after every record change (in the buffers).<br /><br />A useful shortcut is to force ACY as Source Currency Code in the GenJnlLine for AutoEntrForDtldCust/VendLedgEntries() even if it isn't, to ensure that ACY amounts that have been calculated will actually be used. The idea behind it is that a great deal of effort is used in the code to calculate these ACY values with the right exchange rate anf save the value in DtldCVLedgEntryBuf, only to not always / never use them, depending on the currency codes in the unapplication.<br /><br />As I said, microsoft is reworking this mess and releases fixes every other CU for this. The code more and more approaches my code for the Transaction Currency AddOn :) I had to go over the whole of CU12 for this, and due to the requirement (track the amounts in originating currency, also in the G/L and VAT entries) I had to insert proper currency code handling for ACY, too.<br /><br />It's a complicated topic, I'll see if I can find a good example for this. <br /><br />with best regards<br /><br />Jensrookie701010https://www.blogger.com/profile/03644308071482983656noreply@blogger.com