Продолжение.

Появление задачи для агента До недавнего времени я не использовал ИИ в работе с 1С. Мой основной проект — система складского и производственного учета с модулем калькуляций — был написан полностью вручную. Это большая самописная конфигурация: больше 40 тысяч строк кода. Проект я писал один, в качестве руководителя проекта, программиста, аналитика и тестировщика. Когда я начинал, я не закладывал полноценные автоматические тесты и формальный процесс проверки изменений. Система начала появляться спонтанно с небольшого модуля калькуляции и вводилась в эксплуатацию постепенно: модуль калькуляций, затем механизм заказа материалов из производства в снабжение, потом складской учет и позже производственный учет. Проверки в основном строились на ручных сценариях, которые я сам же и разрабатывал. Физически проверить вручную все возможные сценарии было невозможно: слишком много документов, движений, регистров, зависимостей и комбинаций данных. На раннем этапе этого хватало. Сейчас система, с момента реализации последнего крупного производственного модуля, активно эксплуатируется уже больше двух лет. Мелкие ошибки в работе периодически встречались, и я оперативно их исправлял. Но весной этого года всплыла новая проблема, которая оказалась не просто мелкой ошибкой. Кладовщик заметил, что по некоторым позициям начали появляться отрицательные микроостатки материала и большие отрицательные суммы. Важно обозначить границу проблемы. В моей системе учет материала ведется по нормализованным наименованиям, а бухгалтерия работает в обычном режиме: в документах может быть много разных наименований для фактически одной и той же позиции. Из моей системы для бухгалтерии материал передается в килограммах, штуках и других единицах измерения, с точным названием из входного документа и указанием конкретного документа прихода. Поэтому реальный финансовый учет затронут не был. Проблема проявлялась только в производственном управленческом учете: в отрицательных микроостатках некоторых партий и в искажении стоимости запасов. На фактический количественный учет материала это существенно не влияло, потому что речь шла именно о технических микроостатках около нуля. Разбирать такую цепочку вручную означало бы долго идти по коду, запросам, регистрам и конкретным документам. Поэтому я решил использовать этот случай как полноценную проверку нового подхода и основательно подключил ИИ к анализу.

Микроостатки: поиск причины и исправление при помощи агента

Агент проанализировал копию живой базы 1С и код конфигурации. В результате он подтвердил проблему, нашел конкретные докуметы и проводки, в которых появлялись микроостатки, а показал конкретное место в коде, где возникала причина.

Проблема оказалась в старой логике FIFO-списания. Изначально, когда я только начинал писать складской учет, я закладывал точность 0,01. Этого, мне казалось, достаточно для нашей области - производство металлоконструкций промышленного оборудования. Позже, по некоторым причинам, точность хранения количества была увеличена, но правила сравнения в старом участке кода остались прежними. Из-за этого в пограничных случаях партия могла списываться не совсем точно: оставалось микроколичество около нуля или, наоборот, списывалось чуть больше нужного.

При этом сумма списания рассчитывалась и округлялась отдельно, без финальной проверки, что после движения количество и сумма остаются согласованными. В итоге в производственном управленческом учете появлялись остатки вида "количество почти ноль, а сумма в рублях существенная". Именно из этого возникали отрицательные микроостатки и аномальные суммы при расчете стоимости.

Агент не только нашел причину, но и предложил решение. Логика списания партий была изменена: технические микрохвосты теперь закрываются автоматически, сумма списания берется корректно по партии, а проведение документов дополнительно проверяется на отрицательные остатки, расхождения между количеством и суммой и опасные расчетные цены.