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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 03.06.2024, 08:45   #1  
Lankey is offline
Lankey
Участник
 
65 / 15 (1) ++
Регистрация: 19.05.2020
Как автосопоставить проводки после импорта журнала через general journal entity
Клиент импортирует общие журналы через general journal entity в управлении Данными. У entity поле "Обработка на основе набора" не отмечен. Поле settleVoucher при импорте автоматически не заполняется, и, как следствие, проводки не автосопоствавляютя при разноске журнала

Можно ли вылечить без кастомизации? У вас это работает?
Старый 03.06.2024, 16:23   #2  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,285 / 3492 (123) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Поле settleVoucher нужно для того, чтобы сопоставить журнал до его разноски. Оно логично, что не заполняется (ибо по идее нечем - это ж ваш внутренний номер).
Да, до разноски ЖГК сопоставление не сделать, но формально - функциональность автосопоставления никто не отменял - если есть проводка, с которой можно сопоставить загружаемый журнал (с учетом флажка автосопоставление в параметрах модуля, флажка сопоставления на профиле разноски, соответствия финаналитик, по которым выполняется сопоставление) - то... почему бы и нет. Правда уже управлять тем, с чем будет выполнено сопоставление - нельзя (т.е. будет взята первая попавшаяся запись с тем же профилем, аналитиками...)
__________________
Возможно сделать все. Вопрос времени
Старый 03.06.2024, 17:42   #3  
Lankey is offline
Lankey
Участник
 
65 / 15 (1) ++
Регистрация: 19.05.2020
Извините, плохо,видимо, плохо сформулирован вопрос.
SettleVoucher - это "Тип сопоставления", не номер ваучера (мне кажется, вы про ваучер говорите)
Делаю 2 сценария:
1) Создаю руками 2 строки журнала на одинаковый дебит и кредит . Разношу. Все хорошо: в custTrans две проводки по ваучеру и в Поле Баланс одной из них = 0
2) Создаю такие же 2 строки через импорт журнала. Разношу . В custTrans те же две проводки по ваучеру. Но Поле Баланс каждой вижу просто то же число, что и в Кредит или дебит соответствующей проводки. То есть, не обнуляется
Когда сравниваю через sql строки журналов перед разнесением, то вижу, что они отличаются только тем, что в SettleVoucher при создании строк руками записывается 1 ("Открытые проводки" ! "Open transactions")
А при создании через импорт ему присваивается 0 ("Нет"/ "None")
Но SettleVoucher не присутствует в general ledger entity. Через дебаггинг не вижу, чтобы оно вообще где-то присваивалось.
Если делаю через sql set SettleVoucher = 1 импортированному журналу , то оба журнала (ручной и импортированный) разносятся одинаково: создаются одинаковые проводки. То есть, загвоздка именно в SettleVoucher
Вопрос: почему при импорте журнала SettleVoucher не ведет себя так же , как при ручном создании журнала? Клиент говорит, что 3 месяца назад работало одинаково, но в коде не вижу даже установки SettleVoucher при импорте через Управлении Данными. Не понимаю, это новая версия что-то подкосила, или клиент какие-то настройки поменял,и поэтому такой спецэффект проявился. Подскажите, в чем может быть проблема?
За это сообщение автора поблагодарили: sukhanchik (2).
Старый 04.06.2024, 00:18   #4  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,285 / 3492 (123) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Аааа вот в чём вопрос... Ну тогда - да - вопрос к коду. Собственно тот факт, что Вы не видите ничего в коде и говорит о том, что в SettleVoucher прописывается 0, а не 1.
Т.е. условно - был код, но ... пропал . Может с обновлением; может код пошел чуток по другой ветке, в которой SettleVoucher не инициализируется.

Паршивость ситуации тут в том, что поля нет в Entity - т.о. его не заполнишь в исходном файле данных - т.е. по-любому только в код придется вмешиваться и где-нибудь (например, на initValue у Entity) устанавливать SettleVoucher = 1 (ну т.е. понятно, что придется сделать расширение к Entity и т.д.)

Почему код себя не ведет также? Да потому что он не единый. Код, который присутствует на Entity и код, который работает при создании журнала - разный. Когда-то давно - буквально пару версий назад - в системе для заказов на продажу пытались сделать единый код для того, что сейчас называется Entity - но... это оказалось весьма трудозатратным и сейчас при создании Entity особо не парятся - код по созданию записей через Entity - один, а код по созданию объекта вручную - другой

Да, конечно, какие-то подметоды могут вызываться единые, но в целом - это 2 разных алгоритма.Ну и само собой - всё может меняться в жизни...
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: Lankey (1).
Старый 04.06.2024, 02:23   #5  
Lankey is offline
Lankey
Участник
 
65 / 15 (1) ++
Регистрация: 19.05.2020
Спасибо .
А само поле SettleVoucher, что означает ? Я читаю доки про процесс сопоставления. Пишут только про параметры, настройки приоритетов .. но нигде не нахожу его описания. Я так понимаю, это оно показывает как раз то, какие проводки будут выбираться для сопоставления: открытые, помеченные..., а значение "нет" значит что? Как раз, что не будет сопоставления проводиться при разноске, да ( То есть, что после разноски кто-то руками должен проводить сопоставление)?

Меня немного удивялет, что, если мое понимание корректно, что без этого поля сопоставление проводиться не будет, то возникает вопрос : а как архитекторами задумывался процесс end-to-end? Импорт создает автоматически журнал ( причем с большим количеством строк, тк иначе можно было бы и руками забить) -> пакет их разносит -> а кто-то потом должен вручную их все сопоставлять? Это же очень трудоемко и долго. Все так и работают, или я что-то в процессе не понимаю?
(если это просто баг новой версии, то, наверное, уже бы все на ушах стояли)

Последний раз редактировалось Lankey; 04.06.2024 в 03:13.
Старый 04.06.2024, 07:29   #6  
ashu is offline
ashu
MCTS
MCBMSS
 
253 / 77 (3) ++++
Регистрация: 24.06.2008
Цитата:
Сообщение от Lankey Посмотреть сообщение
Спасибо .
а кто-то потом должен вручную их все сопоставлять? Это же очень трудоемко и долго. Все так и работают, или я что-то в процессе не понимаю?
ну зачем же вручную, есть же периодическая операция сопоставления. сорри за небольшой оффтоп.
а вот тут у вас что? CustParameters.AutoSettle

Последний раз редактировалось ashu; 04.06.2024 в 07:31.
Старый 04.06.2024, 09:23   #7  
ashu is offline
ashu
MCTS
MCBMSS
 
253 / 77 (3) ++++
Регистрация: 24.06.2008
Цитата:
Сообщение от Lankey Посмотреть сообщение
Вопрос: почему при импорте журнала SettleVoucher не ведет себя так же , как при ручном создании журнала?
могу предположить, гуру подправят, что это поле инициируется в зависимости от данных в строках журнала- например тип счета- клиент или поставщик, и это поле заполняется в зависимости от параметра указанного в соответсвущем модуле. при импорте не происходит этого кусочка кода судя по всему, надо его ка кто вызвать принудительно
Старый 04.06.2024, 10:02   #8  
Lankey is offline
Lankey
Участник
 
65 / 15 (1) ++
Регистрация: 19.05.2020
Цитата:
Сообщение от ashu Посмотреть сообщение
ну зачем же вручную, есть же периодическая операция сопоставления. сорри за небольшой оффтоп.
а вот тут у вас что? CustParameters.AutoSettle
Добрый день

Функция автосопоставления только появилась, разве нет?
https://learn.microsoft.com/en-us/dy...er/auto-settle
Upd: Проще прощеия, нет, это не то . Сопоставление по проводкам клиентов , действительно, уже есть. А почему, кстати, для вендоров нет?

Настрока CustParameters.AutoSettle игнорируется при импорте журналов, если "Обработка на основе набора" не отмечен

Последний раз редактировалось Lankey; 04.06.2024 в 11:53.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
dennis365foroperations: Yes, it’s here! The Copy configurations feature (and a look at other improvements related to Data Management) Blog bot DAX Blogs 0 12.10.2017 16:11
stoneridgesoftware: Part I: Configuring the Dynamics AX 2012 R3 Entity Store Blog bot DAX Blogs 0 27.04.2017 12:11
ОС: Ошибка при создании строк журнала ввода в эксплуатацию через групповую операцию USTA DAX: Функционал 1 14.05.2009 15:55
Вопрос про Demand Planner slava09 DAX: Функционал 4 25.09.2006 11:43
Нужен запрет на изменения данных журнала переноса после его распечатки ATimTim DAX: Программирование 4 19.01.2005 12:16

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

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

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