Показать сообщение отдельно
Старый 09.06.2019, 12:55   #5  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,275 / 3476 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
Спасибо.

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

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

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

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

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

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

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