Окончание.

Почему одной правки кода было недостаточно

В моей системе есть жесткие зависимости между складскими документами: приходами, расходами, перемещениями, инвентаризациями и другими операциями. Нельзя просто изменить старый документ задним числом, если материалы из него уже использовались в последующих движениях. Сначала нужно отменить зависимые документы, а затем перепровести всю цепочку в правильном порядке. Такая жесткость была сделана специально. Она защищала систему от бесконечных исправлений задним числом, которые могли менять фактическую стоимость изделий из-за перераспределения партий с разными ценами. Для менеджеров это было критично: изделие уже изготовлено, отгружено, себестоимость рассчитана, а после правки некоторых документов задним числом она могла неожиданно измениться. Чтобы такие изменения не проходили незаметно для менеджера, в системе и были сделаны жесткие зависимости и блокировки. Если заказ в производство проведен и заблокирован менеджером, производство уже не может самостоятельно отменить и перепровести связанные документы расхода. Для изменения документов по такому заказу производство запрашивает разрешение у ответственного менеджера, и менеджер заранее понимает, что по конкретному заказу могут измениться данные по себестоимости.

После исправления логики микроостатков нужно было отдельно “вылечить” определенный период: перепровести документы уже с учетом новых правил и проверок. Это должно было очистить основную часть отрицательных остатков и дать производству возможность при необходимости исправлять прошлые документы в рамках уже вылеченного периода. Такая необходимость периодически все-таки возникает по разным причинам. Без перепроведения периода это было бы рискованно: отмена или изменение отдельных документов из проблемного периода могла снова вскрыть старые некорректные движения и породить новые расхождения по остаткам и суммам. Часть отрицательных остатков за более ранние периоды была исправлена отдельно — прямыми техническими записями в регистр.

Дополнительная причина перепроведения выбранного периода была в том, что перепроведение было связано не только с лечением микроостатков, но и с первым этапом миграции партий. Перепроведение большого периода стало первым шагом перехода на новый ключ партии — документ-основание. Раньше партия определялась набором старых ключей: номер документа, дата документа, контрагент и строка материала. В будущем планируется перейти к более простой схеме: документ-основание и строка материала. Вместе с правками по исправлению микроостатков в код были внесены изменения для этой миграции: при перепроведении начал заполняться новый ключ документ-основание, а для дальнейшей работы системы его заполнение стало обязательным.

Эту часть работы фактически тоже выполнял агент под моим контролем: проектировал и писал модуль перепроведения и миграции, создал форму с отображением прогресса процесса, добавил логирование и вывод документов в формате “было/стало”, чтобы можно было видеть реальные изменения в цифрах. Это было важно, потому что процесс затрагивал большой объем документов, и его нельзя было запускать вслепую: нужно было понимать, что именно изменилось, где возникли ошибки и какой результат получился после перепроведения.

Итог

Работать при помщи ИИ с 1С вполне реально. Конечно ИИ не заменяет понимание 1С и учетной логики. Но если у агента есть кодовая база, правила проекта, инструменты работы с тестовой базой и нормальный цикл проверки, он сильно ускоряет разработку и анализ.