I am getting a CONSISTENCY ERROR when inserting to the G/L Entry table when account type is “Bank Account” In Codeunit 12, here is the code that results in the error GLEntry.CONSISTENT( (BalanceCheckAmount = 0) AND (BalanceCheckAmount2 = 0) AND (BalanceCheckAddCurrAmount = 0) AND (BalanceCheckAddCurrAmount2 = 0)); (and more but similar) The BalanceCheckAmount gets set with the following code that I am having a hard time understanding. Why BalanceCheckAmount <> 0. “Posting Date” = 4/3/03 or 1/1/01 or … I have tried many. IF GLEntry.“Posting Date” = NORMALDATE(GLEntry.“Posting Date”) THEN BEGIN BalanceCheckAmount := BalanceCheckAmount + GLEntry.Amount * ((GLEntry.“Posting Date” - 01010000D) MOD 99 + 1); BalanceCheckAmount2 := BalanceCheckAmount2 + GLEntry.Amount * ((GLEntry.“Posting Date” - 01010000D) MOD 98 + 1); END …

Without diving deep into that code it looks like a consistincy-check is made pr. date - i.e. to check that debit- and credit-amounts are equal pr. all dates. Navision demands balance pr. day; and - if set up - pr. document as well. In the old text-based Navision there was a simular check.

quote:

Originally posted by AnfinnurIn the old text-based Navision there was a simular check.

Yes but it was much easier to understand what it did. I too would like get this code explained, so that I (a non-mathematican) can understand it! [:D]

I think you try to test your database as well, and check your bank setup for correctness. None the less, First of all, subtraction of dates returns an Integer. The Mod operation when applied to the integer returns the remender of the applied number after division by the modular number. Eg 20MOD5 = 0, 21MOD5 =1. Therefore 100MOD99 := 1, 122MOD99 := 23 e.t.c BalanceCheckAmount and BalanceCheckAmount2 are basically two sets of data whose result should be the same and that’s why routine is same on each. This function makes sure inconsistent changes are not made in your accounts, by checking the table and marking it as consistent or inconsistent before any writes can occur. The example below will demonstrate the idea more (btw it is from ur online help) Postings made in the GL Entry table must cancel out (a debit line, and a Credit line) if say you used calsums function. The same principla should remain whichever modulus is used (99 or 98), and since any postings are expected to have balanced before posting, the situation should remain the same for any date. This is also why the function set the variables for additional curreny to zero if not in setup. You may not read this example if you already know how the function works. THE EXAMPLE: "A typical example of an inconsistency occurs when the sum of all the entries in a table containing general ledger entries does not balance (is not equal to zero). Imagine that your application includes a function object called ChangeAmount. This function is used to withdraw amounts that were put into the General Ledger Entry table in your application. When an amount is withdrawn from an account, the system is inconsistent until a corresponding amount is put in. The pseudo-code below illustrates the ChangeAmount function. FUNCTION ChangeAmount(DecimalNo.: Amount) BEGIN GLEntry.“G/L Account No.” := ‘1000’; GLEntry.Amount := Amount; GLEntry.INSERT; Balance := Balance + Amount; IF Balance = 0 THEN Consistent := TRUE ELSE Consistent := FALSE; GLEntry.CONSISTENT(Consistent); END; The function uses the variable Balance to express the change in balance. For example, when the function is used to withdraw $100, the Balance variable will reflect this as -$100. When you use the function to put in one or more amounts whose total equals +$100, the Balance variable then equals zero and the table is marked as consistent. This means that if an attempt is made to put in an amount and end the write transaction (commit the change) without withdrawing a corresponding amount, an error occurs and the system cancels the write transaction. " Robert Mutyaba

One more thing, whatever it is you are doing, make sure your treating the “Amount (LCY)” correctly or are not ignoring it. Robert

THANK YOU! I am probably forgetting the LCY amount. At least now I know what to look for! Thanks Again! sharon

hi one more thing, if u have customised the code somwhere, check if u have used the rounding precision correclty. This also sometime results in g/l inconsistency Harikesh