Искусственным интеллектом в работе я пользуюсь давно и возможности его представляю неплохо. И всё равно он регулярно находит, чем удивить. Три недавних случая в рабочих базах 1С — как раз из таких, расскажу по порядку.
Оговорюсь сразу: все три кейса реальные, но конфиденциальные данные изменены или убраны — названия организаций, контрагенты, номенклатура, суммы. Отрасли оставил как есть: швейное производство спецодежды и ИП-разработчик ПО на патенте.
Случай первый: давальческое сырьё и ручные операции
Ситуация рядовая. Бухгалтер жалуется: в «Отчёте производства за смену» часть материалов — давальческие, их положено держать на забалансовом счёте, а документ туда не пускает — приходится каждый раз добивать ручными операциями.
Кто работал с производственными базами, ситуацию узнает. За ней стоит методологический клубок: кто в этой сделке организация, где чьё сырьё, каким документом что оформлять. Обычно такое разбирает методист, и это не на пять минут.
Я отдал задачу искусственному интеллекту. Не в режиме «подскажи по памяти», а с полноценным доступом к живой рабочей базе.
Первым делом я попросил его определиться, с чем мы работаем. Он выяснил конфигурацию и версию, затем разобрал сам «Отчёт производства за смену» — и сформулировал вывод, под которым я готов подписаться: документ рассчитан на свои материалы и свою продукцию; давальческое сырьё — чужое, живёт на забалансе, в затраты попадать не должно, и потому в этом документе ему делать нечего. Иными словами, программа не «кривая» — документ применяют не по назначению.
Дальше я спросил, как в базе вообще устроен учёт давальческого сырья. Он не стал рассуждать в общих чертах — пошёл в данные. Нашёл забалансовый счёт, нашёл документы переработки, поднял реальные проводки и сгруппировал их по документам-регистраторам: какой документ что двигает. Картина получилась наглядная: правильная схема в базе уже частично работает, а рядом с ней — ручные операции, те самые, на которые жаловался бухгалтер.
Отдельно отмечу момент, который считаю принципиальным. Выводы звучали складно, а со складными ответами ИИ надо быть осторожным — поэтому я потребовал проверки: сверься со встроенной справкой и с тем, как оформлены корректные документы. Проверил. Встроенная справка конфигурации — та, что писала фирма «1С», — подтвердила его вывод почти дословно. Проводки эталонного, правильно оформленного документа в базе сошлись с его рассуждениями. Попутно он сам отсёк похожий по названию документ, который относится к другой стороне сделки, — прямо пояснив, почему тот здесь неприменим.
И только после этого он выдал результат: полноценный документ для бухгалтера. Как правильно вести давальческое сырьё, в чём именно ошибка, какую операцию каким документом оформлять — на наших же примерах из базы. Попутно нашёл недочёт в учёте, о котором его никто не спрашивал. Я показал разбор бухгалтеру, мы его детально обсудили — замечаний по существу не нашли.
Случай второй: непроведённая выписка и налог у ИП на патенте
Второй случай — из моего собственного учёта, я вёл его буквально на днях. База ИП без сотрудников на патенте. Загружаю банковскую выписку за полгода — строки загрузились, а поступления не проводятся: у всех горит «Не заполнено отражение аванса в налоговом учёте». Списания при этом проведены. Классическая ситуация «что-то с базой, разбираться лень, отложу».
Отдал искусственному интеллекту — с тем же доступом к базе. Он поднял непроведённые документы и увидел: у всех пустой один и тот же реквизит. Затем — деталь, которая мне понравилась отдельно, — прочитал журнал регистрации и подтвердил причину цифрой: предупреждений ровно столько же, сколько непроведённых документов, других ошибок нет. Журнал регистрации — это то, что живой специалист смотреть, честно говоря, ленится. Он поднял его первым делом и снял все догадки.
Дальше он сравнил год к году: в прошлые годы это поле заполнялось само — тогда в базе был заведён патент. А потом открыл код конфигурации и прочитал штатную процедуру, которая заполняет это поле при загрузке выписки: она ищет действующий на дату платежа патент, и если его нет — оставляет поле пустым. Диагноз: программа исправна, просто выписку загрузили раньше, чем завели в базу патент на новый год. Знакомый мотив, правда? В первом кейсе — «документ применяют не по назначению», здесь — «данные ввели не в том порядке».
Патент я завёл, но уже загруженные документы остались пустыми — автозаполнение отрабатывает только в момент загрузки. Перегружать выписку заново не хотелось. Здесь раскрою карты: инструменты, через которые ИИ работает с базой, — моей разработки, так что их возможности я знаю хорошо. Поэтому просто дал команду: собери внешнюю обработку, которая это исправит. Заодно и проверка собственных инструментов на боевой задаче. Обработку он собрал грамотно: она проходит по непроведённым поступлениям и дозаполняет поле, вызывая ту же штатную процедуру конфигурации — не самодельную логику, а ровно то, что делает сама 1С при загрузке. Прогнал — все документы провелись за один заход. В конфигурацию при этом не полез, и это правильно: механизм исправен, разовая задача решается разовым инструментом.
Дальше я попросил разобраться с налогом целиком. Он прочитал PDF патента из налоговой и сверил с базой — сошлось до рубля. Разобрал выгрузки операций ЕНС из личного кабинета ФНС (CSV в кодировке, которую Excel открывает крякозябрами, — перекодировал молча) и сшил их с данными базы. По дороге снял ложную тревогу: по данным 1С выглядело, будто вычет за прошлый год задвоен, а выгрузка ФНС показала, что налоговая сама урезала заявленное до реальных взносов — нарушений нет. А потом нашёл живые деньги: неиспользованный страховой взнос, который 1С считала израсходованным, а налоговая не зачла. Не заметили бы — сгорел. С учётом него налог к уплате оказался примерно вдвое меньше.
Финал показательный. Уведомление в налоговую я формировал сам, штатным помощником 1С, — и суммы у нас с ним разошлись. Спросил почему. Он прочитал код помощника и объяснил: тот берёт остаток взноса из бухгалтерских проводок, а учёт ЕНС в этой базе не ведётся — поэтому помощник свободный взнос не видит. Подсказал поправить сумму в бланке вручную. Перед отправкой я выгрузил готовый XML — он сверил каждое поле и дал добро. То есть под конец уже не я проверял его, а он меня.
Случай третий: значки в «Передаче давальцу» и вопрос кладовщика
Третий случай — из другой базы того же швейного производства: там «1С:ERP» с доработками, и работает она на сервере заказчика в другом городе. Разбирался я со своего рабочего места — ИИ ходил в базу через веб-публикацию, той же связкой инструментов. Вопрос пришёл от кладовщика: прислал документ «Передача давальцу», в таблице тридцать четыре строки курток двух моделей — у летних значков нет, у утеплённых у всех слева зелёный значок. Что это за отметки и не сломалось ли чего?
ИИ пошёл по привычной схеме: сначала данные. Вычитал строки документа целиком и показал, что по всем служебным полям — заказ, серия, назначение, документ поступления — строки со значками и без не отличаются ничем. Значит, ответ не в данных, а в том, как их рисует форма. Открыл код формы и нашёл условие: значок ставится строке, у которой нет связи со строкой заказа давальца, — форма в этот момент пишет над таблицей «Строк сверх заказа». Тут же проверил заказ: утеплённые куртки в нём есть, все размеры, количества совпадают со строками документа один в один. Товар заказан — а строки к заказу не привязаны.
Как так вышло, рассказала история изменений документа, которую ИИ поднял из базы сам. Документ создали на основании заказа давальца — семнадцать строк летних курток, все с привязкой. Через неделю в него дописали семнадцать строк утеплённых, но уже обычным подбором по остаткам склада, а такой подбор связь с заказом не проставляет. Ещё через день провели. Никто ничего не «отвязывал» — у этих строк привязки просто никогда не было. Мотив третий раз подряд тот же: программа исправна, документ не сломан — данные ввели не тем способом.
Оставался вопрос «а как правильно». Конфигурация у заказчика доработанная, и типовые рецепты здесь не годятся — поэтому ИИ ответил не по памяти, а по коду именно этой базы: заказ давальца в ней включён в типы «распоряжений», так что верных пути два — создавать документ «на основании» заказа либо дозаполнять через «Подобрать по распоряжениям/ордерам». А «Подобрать товары» — это подбор по остаткам, связи с заказом он не даёт; им и была внесена вторая половина строк.
Итогом стала памятка кладовщику на страницу: что означает значок, что произошло с документом по датам и как за пять шагов привести его в порядок — с контрольными количествами для сверки. Отдельной строкой: значок ничему не мешает, документ проведён и учёт цел, так что решение «исправлять или оставить» осталось за людьми. Весь разбор — от вопроса кладовщика до готовой памятки — занял меньше часа, и большую часть этого времени я просто читал отчёты.
Второе дно: рецепт, который сначала не заработал
Памятку я решил не отдавать на веру, а сперва проверить сам рецепт — и вот тут случай стал интереснее всего предыдущего. Заполняем документ так, как советуем: «Заполнить», дальше «Подобрать по распоряжениям/ордерам». Строки подтягиваются, количества сходятся, привязка к заказу появляется. А в колонке «Характеристика» вместо цвета и размера — серая надпись «характеристики не используются». При том что характеристики у этой продукции ведутся и в заказе заполнены по каждой строке. И поправить ячейку руками программа не даёт.
Дальше ИИ пошёл по коду — от кнопки и до конца цепочки: команда формы, форма подбора, менеджер документа, который собирает остатки по распоряжениям, общий модуль переноса строк в табличную часть, условное оформление. Попутно проверял себя по живым данным: характеристики в заказе есть, у номенклатуры ведутся, в регистре распоряжений заполнены, пустых характеристик в проведённых документах не встречалось ни разу. Вывод получился неочевидный: данные в порядке, значение характеристики в строке есть — не видно только его. У каждой строки товаров есть служебный признак «характеристики используются»; по нему форма решает, показать значение или написать, что характеристики не ведутся, и закрыть ячейку от ввода. Обработчик, который переносит строки из подбора по распоряжениям, этот признак не проставляет — во всех остальных способах заполнения того же документа соответствующий вызов есть, а здесь его забыли.
Первая мысль была понятной: значит, кто-то дописывал этот кусок под заказчика. Проверили — не подтвердилось. Конфигурация стоит на поддержке, документ и его формы на замке, никто их не редактировал, а комментарии вокруг проблемного участка — стандартная разметка сборки самой «1С»: линейка собирается из общей базы, и фрагменты, которых не должно быть в «Управлении торговлей» и «Комплексной автоматизации», помечаются такими метками. То есть перед нами ошибка типовой конфигурации — в той ветке кода, которая существует только в «1С:ERP», в релизе 2.5.25.109. И это, пожалуй, самый неприятный тип проблем: пользователь уверен, что «программа сломалась», программист по описанию «не заполняются характеристики» ничего не найдёт — данные-то заполнены, — а в документации про такое, разумеется, не написано.
Лечение — в один клик: сразу после подбора нажать «Записать». При записи форма заново заполняет служебные признаки строк, и характеристики встают на место — проверили, работает. Нормальная правка на стороне разработки — одна строка: добавить в обработчик подбора тот самый вызов, который есть в остальных ветках заполнения этой же формы. Дефект стоит отправить в «1С» и заодно проверить на свежих релизах, но до исправления пользователю достаточно знать про кнопку «Записать».
И вот здесь, на мой взгляд, главное отличие третьего случая от первых двух. Те были про чтение данных: посмотреть документы, регистры, историю и объяснить человеку, что произошло. Этот — другого класса: ни ошибки пользователя, ни «программа так задумана», а ошибка в типовом коде конкретного релиза, спрятанная в цепочке из пяти модулей. Чтобы найти пропущенный вызов, надо удерживать в голове всю цепочку целиком и заранее знать, что видимостью характеристики управляет служебный признак строки, а не само значение. Программист на такое тратит несколько часов — и это в хорошем случае, когда он уже знает конфигурацию и у него под рукой отладчик. У связки это заняло один заход, без отладчика.
Что за этим стоит
Пару слов о том, что сделало это возможным. Сам по себе ИИ базу не видит — нужны инструменты доступа, те самые, моей разработки, о которых я упомянул выше. Данные — структуру, проводки, обороты, регистры — он читал через MCP:RSV Data (описание есть на Инфостарте). Код, метаданные, встроенную справку и журнал регистрации — через плагин для 1С:EDT собственной разработки; им же была собрана та внешняя обработка. Первый инструмент показывает, что лежит в базе, второй — как она устроена. Базы во всех трёх кейсах разные, конфигурации тоже — и в разных релизах, связка от этого не зависит. В третьем случае она и вовсе работала с базой на сервере заказчика, через веб-публикацию, — со стороны это неотличимо от работы с базой на своём компьютере.
Во всех трёх случаях сработал один и тот же приём, и его я бы выделил как главный: ИИ не рассуждает по памяти, а идёт в данные и в код, и проверяет себя об эталон — встроенную справку, штатные процедуры, документы налоговой. Результат каждый раз один: не «сгенерированный текст», а разбор, расчёт, инструмент или найденный в чужом коде дефект — то, что можно отдать пользователю без переделки. У специалиста каждый из этих кейсов занял бы день, а скорее больше.
Выводов навязывать не буду. Скажу лишь, что за годы работы в 1С я привык к постепенным изменениям, а здесь изменение качественное — и произошло оно быстрее, чем многие из нас заметили.
Вступайте в нашу телеграмм-группу Инфостарт