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

[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 вложенного метода "класс передается в класс" смысл теряется). Т.е. помогали какие-то случайные вещи - типа найти где выполняется поиск счета или кто-то из консультантов находил пропущенную настройку. Будет замечательно, если кто-то поделится своим опытом в этом.