AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 09.06.2019, 10:42   #1  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,999 / 3921 (188) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Инструменты, приемы и рекомендации для отладки разноски в LedgerVoucher?
Какие приемы и рекомендации вы можете дать для отладки разноски в LedgerVoucher?
Какой инструментарий помимо самого отладчика вы используете для отладки LedgerVoucher? и как именно? (xTableBrowser, ListView и пр.)

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

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

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

Последний раз редактировалось mazzy; 09.06.2019 в 10:45.
За это сообщение автора поблагодарили: trud (2).
Старый 09.06.2019, 11:17   #2  
sukhanchik is offline
sukhanchik
Moderator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,738 / 2389 (85) +++++++++
Регистрация: 13.06.2004
Адрес: Москва
Не занимался отладкой в LedgerVoucher, но описанные выше задачи (AX3..AX2009) решал достаточно просто.

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

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

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

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

Последний раз редактировалось sukhanchik; 09.06.2019 в 11:21.
За это сообщение автора поблагодарили: mazzy (5).
Старый 09.06.2019, 11:28   #3  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,999 / 3921 (188) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Спасибо.
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
3. В отладчике в методе newCreateTrans я вижу все вычисленные счета и суммы, которые в этот метод передаются, т.о. я могу на бумажку выписать все счета и суммы, которые задействовались в разноске и исходя из этого сделать вывод о том, где у меня пошла не та сумма, которую я ожидал
не совсем.
есть суммирование входящих сумм, если тип ваучера не Detailed
есть allocation на счетах главной книги.
есть налоги

идея понятна, конечно.
вопрос про случай, когда нужно залезть глубже, чем интерфейс создания.
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
Старый 09.06.2019, 11:32   #4  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,999 / 3921 (188) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
- кто-то решил выпендриться и покодить в классах LedgerVoucher. В этом случае ошибку надо искать в том месте, в котором покодили .
в стандарте куча ошибок, связанных с курсами:
* курсы не доведены до места где они применяются (используется 0, вместо заданного пользователем),
* постоянная путаница ExchRate и ExchRate_W
* постоянно теряется fixedRate

ну, и функционал, который делает проводки, не всегда таки создается только для того,
чтобы выпендриться
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
За это сообщение автора поблагодарили: sukhanchik (4).
Старый 09.06.2019, 12:55   #5  
sukhanchik is offline
sukhanchik
Moderator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,738 / 2389 (85) +++++++++
Регистрация: 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* уже скормить итоговую информацию. При этом надо понимать опять-таки, что далеко не все компании уделяют этому вопросу должное внимание, т.е. проблема не у всех встаёт и не все её стремятся решать, тем более так глобально
__________________
Возможно сделать все. Вопрос времени
Старый 09.06.2019, 13:44   #6  
trud is offline
trud
Участник
Лучший по профессии 2017
 
801 / 1048 (36) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
1. Руководствуясь правилом 20/80 80% проблем решаются не влезая в недра LedgerVoucher, а просто анализируя то, что подаётся на вход в LedgerVoucher*.
Проблема тут в том что с 2012 много разносок идет через распределения(SourceDocument), там нет LedgerVoucher. Я раза три встречался с проблемами описанными в первом сообщении, и во всех случаях отлаживать не получалось(т.е. после 10 вложенного метода "класс передается в класс" смысл теряется). Т.е. помогали какие-то случайные вещи - типа найти где выполняется поиск счета или кто-то из консультантов находил пропущенную настройку. Будет замечательно, если кто-то поделится своим опытом в этом.
За это сообщение автора поблагодарили: sukhanchik (4).
Старый 09.06.2019, 17:04   #7  
sukhanchik is offline
sukhanchik
Moderator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,738 / 2389 (85) +++++++++
Регистрация: 13.06.2004
Адрес: Москва
Я поэтому и написал, что мой метод поиска актуален до 2012. В 2012 поиск по LedgerVoucher* уже не поможет ((
__________________
Возможно сделать все. Вопрос времени
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Как оптимально написать T-SQL запрос для выборки настройки Table/Group/All (например, счет ГК из профиля разноски) mazzy DAX: Программирование 48 23.04.2016 17:33
axforum blogs: Оптимизация разноски ГК закрытия склада AX2012 R2(российский функционал) Blog bot DAX Blogs 0 18.10.2013 00:15
Обработка накладной по закупке по 2 и более профилям разноски Buba DAX: Программирование 30 16.05.2011 21:44
Сопоставление с разными профилями разноски и одинаковой валютой операции Red Stranger DAX: Функционал 13 27.06.2006 18:40
Вопрос по профилям разноски ОС treeny DAX: Функционал 2 20.05.2005 16:02
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 02:03.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.