Инструменты, приемы и рекомендации для отладки разноски в LedgerVoucher?

[mazzy]

Какие приемы и рекомендации вы можете дать для отладки разноски в LedgerVoucher?
Какой инструментарий помимо самого отладчика вы используете для отладки LedgerVoucher? и как именно? (xTableBrowser, ListView и пр.)

отладка может происходить во время разбирательств с ошибками (в большинстве случаев), а также при добавлении новых фич в разноску.
поскольку в новых версиях аксапты, в отличие от классических, отладчик находится в Visual Studio, обязательно указывайте версию аксапты.
Да, в этой ветке обсуждения хотелось бы сосредоточиться именно на финансовых проводках и LedgerVoucher.

вопрос тщательно обдуман.
конечно же лучшие ответы планирую использовать в своей работе.
конечно же у меня нет конкретной проблемы с LedgerVoucher.

Но если вам так уж нужен сценарий, то вот некоторые типичные (это далеко не все сценарии):
1. представьте что вы получаете в проводке "не тот" счет, что ожидаете при настройке. или "лишнее движение". вы хотите понять как это происходит.
2. вы получили сообщение об ошибке "проводки не балансируют" с суммами 0 в основной и вторичной валюте. вы хотите понять где, как и когда появляются не округленные суммы в ваучере.

[sukhanchik]

Не занимался отладкой в LedgerVoucher, но описанные выше задачи (AX3..AX2009) решал достаточно просто.

Предположение:
Люди, которые программировали в тех местах, которые я раскапывал - были либо из Microsoft, либо не усложняли себе жизнь и делали проводки не с помощью классов LedgerVoucher, а с помощью LedgerJournalTable / LedgerJournalTrans. Т.е. если разработчик малоопытный - то он не полезет использовать LedgerVoucher, а если он с большим опытом, то либо тем более не полезет ), либо воспользуется грамотно (т.е. как в Microsoft)

Исходя из этого - делаем следующее:
1. Ищем вызовы LedgerVoucherTransObject::newCreateTrans по перекрестным ссылкам и ставим туда бряку.
2. Для каждого счета есть свое значение енума LedgerPostingType, по которому практически однозначно можно определить - из какой настройки берётся счет. Т.е. если у меня взялся не тот счет или создалась не та проводка - то в ней проставилось какое-то значение енума LedgerPostingType, по которому я могу практически однозначно сказать из какой настройки он взялся (ну или сильно сузить круг подозреваемых настроек).
3. В отладчике в методе newCreateTrans я вижу все вычисленные счета и суммы, которые в этот метод передаются, т.о. я могу на бумажку выписать все счета и суммы, которые задействовались в разноске и исходя из этого сделать вывод о том, где у меня пошла не та сумма, которую я ожидал. И уже начинаю искать причины вне классов LedgerVoucher*

Собственно всё. Здесь обычно все проблемы решаются. Точнее их поиск уходит из классов LedgerVoucher*.

Безусловно, могут быть случаи, когда:
- не был задействован метод newCreateTrans. В этом случае все равно нужно искать место, где инициализируется объект LedgerVoucherTransObject и смотреть, какие счета и суммы приходят в него (перекрестные ссылки - наше всё).
- кто-то решил выпендриться и покодить в классах LedgerVoucher. В этом случае ошибку надо искать в том месте, в котором покодили . Ну или как вариант - нафиг удалять все изменения ) и применять метод, описанный выше (а лучше переделать на генерацию LedgerJournalTable / LedgerJournalTrans)

[mazzy]

Спасибо.

Цитата:

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

3. В отладчике в методе newCreateTrans я вижу все вычисленные счета и суммы, которые в этот метод передаются, т.о. я могу на бумажку выписать все счета и суммы, которые задействовались в разноске и исходя из этого сделать вывод о том, где у меня пошла не та сумма, которую я ожидал

не совсем.
есть суммирование входящих сумм, если тип ваучера не Detailed
есть allocation на счетах главной книги.
есть налоги

идея понятна, конечно.
вопрос про случай, когда нужно залезть глубже, чем интерфейс создания.

[mazzy]

Цитата:

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

- кто-то решил выпендриться и покодить в классах LedgerVoucher. В этом случае ошибку надо искать в том месте, в котором покодили .

в стандарте куча ошибок, связанных с курсами:
* курсы не доведены до места где они применяются (используется 0, вместо заданного пользователем),
* постоянная путаница ExchRate и ExchRate_W
* постоянно теряется fixedRate

ну, и функционал, который делает проводки, не всегда таки создается только для того,
чтобы выпендриться

[sukhanchik]

Цитата:

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

Спасибо.

не совсем.
есть суммирование входящих сумм, если тип ваучера не Detailed
есть allocation на счетах главной книги.
есть налоги

идея понятна, конечно.
вопрос про случай, когда нужно залезть глубже, чем интерфейс создания.

Любая разноска предполагает, что счет ГК берётся из тех или иных параметров.
Любая разноска предполагает, что сумма даётся на вход в LedgerVoucher*.
Налоги - также ловятся и очень хорошо ловятся.
Распределение.. Да, тут согласен - уже посложнее. Равно как и суммирование входящих сумм. Но описанные сценарии в исходном сообщении не предполагают такое усложнение - во-первых.
Во-вторых, чтобы выработать какое-то общее решение нужно сначала столкнуться с несколькими ситуациями. А с этим уже гораздо сложнее, т.к. ... далеко не все специалисты при внедрении владеют информацией по этому функционалу

Цитата:

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

в стандарте куча ошибок, связанных с курсами:
* курсы не доведены до места где они применяются (используется 0, вместо заданного пользователем),
* постоянная путаница ExchRate и ExchRate_W
* постоянно теряется fixedRate

ну, и функционал, который делает проводки, не всегда таки создается только для того,
чтобы выпендриться

Согласен, прошу прощения за резкость - тут виноват. Однако и в случае с курсовыми разницами такая же бодяга - алгоритм расчета курсовых разниц находится вне классов LedgerVoucher*

В общем, хочу зарезюмировать свои мысли:
1. Руководствуясь правилом 20/80 80% проблем решаются не влезая в недра LedgerVoucher, а просто анализируя то, что подаётся на вход в LedgerVoucher*. В моей практике так решались 100% вопросов. Конечно я ходил по внутренностям LedgerVoucher, но решение в результате находил только применяя описанный выше способ. Анализ внутренностей LedgerVoucher мне ничего не давал.

2. Распределение ГК (стандартное) и суммирование ваучеров являются нечасто используемым функционалом при внедрении, т.о. массовой статистики решения проблем в этой области просто нет. Оговорюсь, что я составил свой вывод по личному опыту работах на проектах, а также по тому - сколько людей на курсах спрашивало меня про эту функциональность и с каким интересом. Т.е. я допускаю, что есть люди, которые эти проблемы решали, но крайне скептически отношусь к тому, что они читают эту тему на форуме (просто с т.з. теории вероятности)

3. Проблемы с курсовыми разницами есть, никто не спорит, но они решались путем правок самого алгоритма расчета и уж никак не трогались классы LedgerVoucher*. Да, делалось так, чтобы классам LedgerVoucher* уже скормить итоговую информацию. При этом надо понимать опять-таки, что далеко не все компании уделяют этому вопросу должное внимание, т.е. проблема не у всех встаёт и не все её стремятся решать, тем более так глобально

[trud]

Цитата:

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

1. Руководствуясь правилом 20/80 80% проблем решаются не влезая в недра LedgerVoucher, а просто анализируя то, что подаётся на вход в LedgerVoucher*.

Проблема тут в том что с 2012 много разносок идет через распределения(SourceDocument), там нет LedgerVoucher. Я раза три встречался с проблемами описанными в первом сообщении, и во всех случаях отлаживать не получалось(т.е. после 10 вложенного метода "класс передается в класс" смысл теряется). Т.е. помогали какие-то случайные вещи - типа найти где выполняется поиск счета или кто-то из консультантов находил пропущенную настройку. Будет замечательно, если кто-то поделится своим опытом в этом.

[sukhanchik]

Я поэтому и написал, что мой метод поиска актуален до 2012. В 2012 поиск по LedgerVoucher* уже не поможет ((