
Сейчас рынок труда многих ИТ-специальностей в пользу работодателей, похоже что в 2026 году это касается и 1С. Мы постучались к крупному франчайзи «Софт-Юнити» с предложением обсудить использование нашего продукта и получили такой ответ: «Я могу скинуть вам задание, которое даю аналитикам на собеседованиях. Прогоните его через свои инструменты, если ответ будет правильным, договоримся о встрече». Рассказываю о самом задании и как с ним справился ИИ-ассистент.
Задание звучало так
Ваш клиент это производственная компания. Они производят товары легкой промышленности и продают их оптом. Когда мощности производства не хватает, Ваш клиент покупает точно такие же товары у сторонних поставщиков для перепродажи.
Визуальных отличий между товарами, произведенными собственным производством, и купленных на стороне нет.
На складе кладовщики не ведут раздельный учет товаров, произведенных своим производством или купленнных на стороне. Все лежит в одном помещении и на одной полке вперемешку.
В исторической учетной системе один элемент справочника Номенклатура обозначает одновременно и закупаемые товары и производимые. Механизмы или аналитики, которые бы позволили определить источник возникновения товара отсутствуют.
К новой системе дается требование. В момент отгрузки товаров покупателю система должна автоматически определить откуда прибыл товар (из закупки или был произведен) и в случае закупа сделать проводку с использованием 41 счета, а в случае производства – с 43.
Ограничения: юр лицо используется одно, делать виртуальный склад нельзя, дублировать номенклатуру нельзя.
Вы внедряете клиенту 1С:ERP.
Нужно предложить минимум два варианта решения и определить функциональные разрывы – минимум один.
Шаг 1. Понимание задачи
1Yes спроектирован так, что основным объектом с которым работает аналитик является Бизнес-требование. Не долго думая вводим требование, система задает всего один уточняющий вопрос. Обычно их гораздо больше, но тут видимо задача была описана достаточно подробно.

Отвечаю «по FIFO».
Шаг 2. Формулирование требования
На этом шаге система формулирует требование в формате: Требование общими словами + аспекты требования с деталями.

Шаг 3. Анализ функциональных разрывов
Самое интересное. На этом шаге определяются функциональные ограничения 1С ERP, которые не позволяют реализовать требование. Здесь без глубоких знаний конкретной конфигурации не обойтись. Обычная LLM конечно ответит, но 80% ответа будет базироваться на галлюцинациях.
Вот как справился 1Yes:

На фоне цветной плашки описан краткий вердикт – почему это разрыв или почему нет. Чтобы аналитик мог углубиться в детали, есть еще 2 уровня детализации: подробный анализ и выдержки из источников (объектов метаданных и кода):

Шаг 4. Технические решения
Суть проблемы по мнению ИИ
Система знает происхождение каждой партии — измерение ДокументПоступления в регистрах ПартииТоваровОрганизаций и ДетализацияПартийТоваровДляНДСиУСН2_4 хранит ссылку на конкретный документ (ПриобретениеТоваровУслуг = закупка, ВыпускПродукции = производство). Но механизм формирования проводок определяет счёт через цепочку: Номенклатура →ГруппаФинансовогоУчета → регистр «ПорядокОтраженияНаСчетахУчета» →СчетУчета. Поскольку у номенклатуры может быть только одна ГФУ, счёт всегда будет один и тот же (либо 41, либо 43) — независимо от того, какая партия списывается по FIFO.
Вся фактура ясна, теперь можно приступить к формулированию технического решения. Система предложила 2 варианта, расписала их плюсы и минусы, подготовила критерии приемки. Коротко суть вариантов:
Решение 1
Доработка модуля отражения в регл. учёте на уровне определения счёта по партии. Не трогаем ГФУ номенклатуры, не создаём новых объектов метаданных. Точечно перехватываем момент формирования проводки и подменяем счёт кредита на основании типа ДокументПоступления списываемой по FIFO партии.
Решение 2
Разделение потоков через ВидыЗапасов с разными ГФУ. ВидыЗапасов — самостоятельное измерение в ПартииТоваровОрганизаций и ТоварыОрганизаций, и у него есть собственный реквизит ГруппаФинансовогоУчета. Разные потоки поступления одной номенклатуры можно разделить на уровне ВидЗапасов, не дублируя номенклатуру.
Здесь все технические детали решения писать не буду, оставлю ссылочку для тех, кому интересно.
Сравнение
|
Критерий |
Решение 1 |
Решение 2 |
|
Трудоёмкость |
Ниже |
Выше |
|
Количество доработок |
1 модуль |
2 модуля |
|
Управляемость |
код |
НСИ + код |
|
Расширяемость |
Доработка кода |
Добавление записей НСИ |
|
Аналитика в отчётах |
Без изменений |
Разрез по видам запасов |
|
Риск побочных эффектов |
Низкий |
Средний |
Вывод
Второй вариант решения устроил как работодателя так и наш контроль качества. Он чище по архитектуре, хотя и более трудоемок в реализации.
На все про все ушло 15 минут, интересно сколько времени такая задача займет при «ручном» подходе: 1С аналитики, прокомментируйте пожалуйста.
Автор: ArtemSporykhin


