Codeunit 12 -> BalanceCheckAmount

[NeNavision_imported]

В чем глубокий космический смысл расчета значений BalanceCheckAmount для проверки баланса таким способом?

 BalanceCheckAmount :=
   BalanceCheckAmount + GLEntry.Amount * ((GLEntry."Posting Date" - 01010000D) MOD 99 + 1);
 BalanceCheckAmount2 :=
   BalanceCheckAmount2 + GLEntry.Amount * ((GLEntry."Posting Date" - 01010000D) MOD 98 + 1);

[romeo]

Цитата:

Сообщение от NeNavision

В чем глубокий космический смысл расчета значений BalanceCheckAmount для проверки баланса таким способом?

 BalanceCheckAmount :=
   BalanceCheckAmount + GLEntry.Amount * ((GLEntry."Posting Date" - 01010000D) MOD 99 + 1);
 BalanceCheckAmount2 :=
   BalanceCheckAmount2 + GLEntry.Amount * ((GLEntry."Posting Date" - 01010000D) MOD 98 + 1);

Датчане - христиане. 01010000D - рождество Христово -) Может скрытый смысел в том, чтобы упомянуть об этом. Шутка.

[rmv]

Предполагаю что комбинация BalanceCheckAmount и BalanceCheckAmount2 однозначно сводит баланс на ДАТУ УЧЕТА.

[NeNavision_imported]

Интересно, как он считает.
Моя версия:
Понятно, что цель контроль баланса.
Баланс контролируется по сумме и по дате.
Для всех счетов баланс на любую дату должен быть = 0
Можно по-разному определять баланс на дату. Но выбрали такой хитрый способ.
Допустим в результате учета создались несколько операций. с 22.02.07..по 24.02.2007...
Баланс = 0, Но баланс по дате не везде равен нулю.
[attachment=555:attachment]
С помошью BalanceCheckAmount это легко отследить, т.к. для каждого дня свой коэффициент.
Но такой метод не гарантиирует абсолютной точности, если учитываются операции с разностью дат более 99 дней. Чтобы учесть и эту ситацию используется BalanceCheckAmount2.

[artkashin]

Цитата:

Сообщение от NeNavision

В чем глубокий космический смысл расчета значений BalanceCheckAmount для проверки баланса таким способом?

 BalanceCheckAmount :=
   BalanceCheckAmount + GLEntry.Amount * ((GLEntry."Posting Date" - 01010000D) MOD 99 + 1);
 BalanceCheckAmount2 :=
   BalanceCheckAmount2 + GLEntry.Amount * ((GLEntry."Posting Date" - 01010000D) MOD 98 + 1);

Значением операции (GLEntry."Posting Date" - 01010000D) является число. Сделано, чтобы не плодить операторы EVALUATE. Заметьте, отнять 0D, 1D нельзя, это вызывает ошибки, поэтому, в рамках синтаксиса Нава 01010000D выбрано за своеобразное начало координат всех чисел, которые получаются в результате разности.

На момент проверки GLEntry.CONSISTENT ((BalanceCheckAmount = 0)...) в базе существуют только строки в 17 таблице, объединенные одной транзакцией. Система позволяет, чтобы в результате ОДНОЙ транзакции, были учтены строки с различными датами учета (другое дело, что соответствующего кода нет, транзакции разделяются по датам учета). MOD используется для того, чтобы не было возможного переполнения буфера , в случае множества строк.

обычно, в результате финучета строк появляются примерные записи

"Entry No." = 1, "Transaction No." = 1, Amount = 500, "Posting Date" = 01012007D, "Account No." = X
"Entry No." = 2, "Transaction No." = 1, Amount = -400, "Posting Date" = 01012007D, "Account No." = Y1
"Entry No." = 3, "Transaction No." = 1, Amount = -100, "Posting Date" = 01012007D, "Account No." = Y2

(01012007D - 01010000D) =733042

В этом случае, по результатам трех сложений, BalanceCheckAmount = 0, а также BalanceCheckAmount2 =0
И так, представьте себе, что в результате ОДНОЙ транзакции, появились строки с разными датами. Допустим

"Entry No." = 1, "Transaction No." = 1, Amount = 500, "Posting Date" = 01012007D, "Account No." = X
"Entry No." = 2, "Transaction No." = 1, Amount = -400, "Posting Date" = 01012007D, "Account No." = Y1
"Entry No." = 3, "Transaction No." = 1, Amount = -100, "Posting Date" = 01012007D, "Account No." = Y2
"Entry No." = 4, "Transaction No." = 1, Amount = 500, "Posting Date" = 12122007D, "Account No." = X1
"Entry No." = 5, "Transaction No." = 1, Amount = -500, "Posting Date" = 12122007D, "Account No." = Y3

Такая проверка также даст по результатам уже ПЯТИ сложений, BalanceCheckAmount = 0, а также BalanceCheckAmount2 =0

Есть и недостаток - вслучае, если разница между датами будет 99*98 = 9702 дня, то данная проверка считает даты одинаковыми, и вероятная ошибка не будет обнаружена..
Но это возможно только теоритически :-)

[NeNavision_imported]

В общем, красиво написан механизм контроля баланса на дату.

[artkashin]

Цитата:

Сообщение от Kashin

(другое дело, что соответствующего кода нет, транзакции разделяются по датам учета

Извиняюсь, проверил повнимательнее.. Логика работы 12 и 13 кодюнита несколько отличается от того что я написал, и Маркировка записи на Consistent происходит по всем строкам финжурнала, по которым в данный момент идет учет, вне зависимости от транзакции. Т.е. если вы массово учитываете строки финжурнала с различными датами, то сложение BalanceCheckAmount и BalanceCheckAmount2 происходит в рамках всех строк. Т.е. под транзакцией выше не поле "Transaction No.", а весь процесс учета строк, от начала и до конца.

[NeNavision_imported]

Ага так и есть. Не хотелось придираться к мелочам.
Главное смысл правильный.