Как автосопоставить проводки после импорта журнала через general journal entity

[Lankey]

Клиент импортирует общие журналы через general journal entity в управлении Данными. У entity поле "Обработка на основе набора" не отмечен. Поле settleVoucher при импорте автоматически не заполняется, и, как следствие, проводки не автосопоствавляютя при разноске журнала

Можно ли вылечить без кастомизации? У вас это работает?

[sukhanchik]

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

[Lankey]

Извините, плохо,видимо, плохо сформулирован вопрос.
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]

Аааа вот в чём вопрос... Ну тогда - да - вопрос к коду. Собственно тот факт, что Вы не видите ничего в коде и говорит о том, что в SettleVoucher прописывается 0, а не 1.
Т.е. условно - был код, но ... пропал . Может с обновлением; может код пошел чуток по другой ветке, в которой SettleVoucher не инициализируется.

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

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

Да, конечно, какие-то подметоды могут вызываться единые, но в целом - это 2 разных алгоритма.Ну и само собой - всё может меняться в жизни...

[Lankey]

Спасибо .
А само поле SettleVoucher, что означает ? Я читаю доки про процесс сопоставления. Пишут только про параметры, настройки приоритетов .. но нигде не нахожу его описания. Я так понимаю, это оно показывает как раз то, какие проводки будут выбираться для сопоставления: открытые, помеченные..., а значение "нет" значит что? Как раз, что не будет сопоставления проводиться при разноске, да ( То есть, что после разноски кто-то руками должен проводить сопоставление)?

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

[ashu]

Цитата:

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

Спасибо .
а кто-то потом должен вручную их все сопоставлять? Это же очень трудоемко и долго. Все так и работают, или я что-то в процессе не понимаю?

ну зачем же вручную, есть же периодическая операция сопоставления. сорри за небольшой оффтоп.
а вот тут у вас что? CustParameters.AutoSettle

[ashu]

Цитата:

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

Вопрос: почему при импорте журнала SettleVoucher не ведет себя так же , как при ручном создании журнала?

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

[Lankey]

Цитата:

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

ну зачем же вручную, есть же периодическая операция сопоставления. сорри за небольшой оффтоп.
а вот тут у вас что? CustParameters.AutoSettle

Добрый день

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

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

[ashu]

Цитата:

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

Добрый день

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

автосопоставление есть давно, точно с версии 3.0. для поставщиков это класс CustVendAutoSettlement_Vend_RU (я не разработчик, потому прошу учесть) думаю надо у вас посмотреть конфигурационные ключи, хотя если не ошибаюсь автосопоставление и клиентов и поставщиков это LedgerBasic, главное включить функции для регионов CRSERussia.

[Lankey]

Если кому интерено - клиент был неправ. Никогда у них автосопоставление не работало при разноске этих импортируемых журналов.
Это именно из-за того, что у entity поле "Обработка на основе набора" не отмечен. И , как следствие, поле settleVoucher при импорте автоматически не заполняется, и поэтому проводки не автосопоствавляютя при разноске журнала

Как обход можно "Обработка на основе набора"(Set-based processing) отметить. Тогда settleVoucher при импорте автоматически заполняется, и проводки поэтому сопоставляются. Все ок. Но засада в том, что надо в файле импорта задавать сразу номер ваучера(а не полагаться на автоматическое его заполнение аксаптой) . В документации написано, что этот импортированный номер временнный, и при разноске журнала переписывается номером, присвоенным акскаптой, но в моем эксперименте этого не произошло. Дальше не копала, тк клиент посмотрел и не захотел дополнять импортируемый файл колонкой с ваучером.

Version: 10.0.38