Тут недавно произошло неприятное событие - некорректно прошел пересчет склада. При разноске ГК система взяла не все сопоставления. Соответственно, ваучер сопоставления неполный и не во всех сопоставлениях (с заполненными счетами) проставлен признак Posted. Расследование показало, что задача Завершение уровня расчета стартанула еще до завершения связанных подзадач (из BatchConstraint), быстро завершилась и создала задачу разноски в ГК, а задачи по генерации сопоставлений продолжили выполняться и нагенерили необработанных сопоставлений.
Есть подозрение, что некорректно работает подсистема пакетных заданий, а именно метод BatchRun::serverProcessDependencies.
В этом методе у МС зачем то ставятся принудительно хинты readCommittedLock. Я вот грешным делом думал, что read commited и так используется в аксапте всегда, если точнее read commited snapshot. Но то ли МС об этом не знает, то ли этот метод особенный. Если метод особенный, то меня смущает, что для таблицы Batch в методе нету хинта:
X++:
batchJob.readCommittedLock(true);
constraintsOr.readCommittedLock(true);
batchDependsOr.readCommittedLock(true);
constraintsAnd.readCommittedLock(true);
batchDependsAnd.readCommittedLock(true);
Если предположить, что там по умолчанию грязное чтение, то может быть ситуация, что запись Batch видна, а ограничения (BatchConstraint) система не видит и спокойно обновляет статус.
Кто что думает по этому поводу? Либо можно все списать на барабашку.