Работая с 1С:ERP, думаю, многие сталкивались с ситуацией:
товар физически лежит на складе, но ERP не дает его продать или списать.
Причем выглядит это обычно довольно странно.
Например, менеджер пытается оформить продажу 20 штук товара “Тумбочка под обувь”, а система отвечает:
По организации Промресурс на складе Склад готовой продукции не хватает 10 шт товара Тумбочка под обувь
На первый взгляд – обычный дефицит.
Но дальше начинается самое интересное.
Когда на складе 100 штук, а доступно только 10
Открываем ведомость по товарам на складах.
Видим:
Конечный остаток: 100 шт
То есть товар находится на складе.
Далее открываем типовой отчет “Остатки и доступность товаров”.
Там уже:
Доступно: 10 шт
Но отчет не объясняет главного:
куда исчезли остальные 90 штук?
Справедливости ради это можно увидеть, если нажать галку «Показать обособленные товары»
Но согласитесь, что обособление – это фактически резерв, а показывается как товар «В наличии» да и нажать показать обособление не всем придёт в голову.
Что показала дополнительная диагностика
Для анализа таких ситуаций я решил сделать отдельный диагностический инструмент поверх ERP.
Инструмент агрегирует несколько механизмов резервирования одновременно:
- мягкие резервы;
- жесткие резервы (обособление);
- ожидаемые поступления;
- резервы в будущих поступлениях.
В результате по той же позиции получили:
Жесткий резерв: 90
Доступный остаток: 10
То есть проблема была не в физическом остатке.
Проблема была в механизме жесткого резервирования (обособления), который удерживал товар.
Кейс №2. Потерянный «мягкий резерв»
Еще один интересный пример.
В типовом отчете по доступности пользователь видит:
Поступит: 4
В резерве: 4
Доступно: 0
К обеспечению/дефицит: 2
Пробуем включить «Показать обособленные товары»
Вам стало понятней, что происходит? Мне лично нет.
Дополнительная диагностика моим инструментом показывает:
В пути: 4
Зарезервировано в пути: 4
Мягкий резерв: 10
Доступный остаток: -6
То есть поверх ожидаемого поступления в 4 шт которое полностью зарезервировано существует еще и мягкий резерв (дополнительно 6шт), который удерживает товар.
Кейс №3. Потерянные «Товары в пути»
Еще одна ситуация.
Типовой отчет по доступности показывает пустое поле “Ожидается” по позиции «Жидкость охлаждающая "Тосол-Э40" (до минус 40 °С)».
К обеспечению/дефицит: 19
Но диагностика обнаруживает:
Товар в пути: 19
Зарезервировано в пути: 19
Документ:
Заказ поставщику от 2021 года
То есть фактически существует Заказ поставщику (зарезервированный), который по факту должен был попасть в графу «Ожидается», но не попал.
Почему вообще возникла идея этого инструмента
Изначально у меня вообще не было задачи “сделать еще один убер-отчет по резервированию”.
У меня возник другой вопрос:
можно ли пройти полный цикл ERP-разработки через пайплайн с ИИ ассистентом, а не просто сгенерировать кусок кода?
Хотелось проверить мой no1C подход на реальной ERP-задаче:
- со сложной предметной областью;
- со сложными запросами к регистрам;
- с диагностикой;
- с реальными бизнес-ограничениями.
Что именно я проверял
В эксперименте использовался следующий пайплайн:
1. Автоматическая генерация бизнес-ТЗ
2. Автоматическая генерация архитектурного ТЗ
3. Автогенерация no1C кода
4. Автогенерация тестов
5. Автоисправление 1С-запросов
6. Проверка кода «на лету»
7. Автоисправление кода и повторные итерации
При этом основной целью не было “полностью заменить разработчика”, целью было снизить стоимость инженерных итераций.
Почему именно ERP-задачи особенно интересны
В обычных CRUD-системах AI-генерация уже мало кого удивляет.
Но ERP-задачи существенно сложнее:
- несколько механизмов учета;
- виртуальные таблицы;
- движения регистров;
- обособление;
- резервирование;
- сложная логика;
- сложные бизнес-ограничения.
Именно поэтому было интересно проверить no1C-пайплайн на задаче, где:
ERP знает ответ, но пользователю сложно понять причинно-следственную связь.
Оценка классической разработки
Перед началом эксперимента я попробовал оценить трудоемкость задачи “классическим” способом по набору бизнес-требований, которые я прикрепил к статье дополнительно чтобы не загромождать текст.
Получились примерно такие оценки:
|
Вариант |
ChatGPT |
Grok |
Gemini |
Среднее |
|
Минимальный |
51 ч |
58 ч |
42 ч |
50 ч |
|
Рабочий |
122 ч |
144 ч |
116 ч |
127 ч |
|
Сдача заказчику |
228 ч |
282 ч |
239 ч |
250 ч |
Понятно, что оценки условны и зависят от уровня экспертизы бизнес-консультанта и разработчика, но усредненная оценка практически совпала с моей собственной (80/120/240).
Если есть сомнения в оценке - можете сделать это самостоятельно - файлы с требованиями во вложении.
Что получилось в эксперименте
В результате no1C-пайплайн позволил мне получить работающий MVP-инструмент примерно за 8 часов.
Понятно, что MVP ≠ готовое внедрение.
Некоторые моменты еще требуют доработки.
Но даже в текущем виде инструмент уже оказался полезен как:
Операционный диагностический уровень поверх ERP
Что оказалось самым важным
Причем минимизация времени крылась не только и не столько в генерации кода.
Основное ускорение дало резкое удешевление инженерной итерации:
→ бизнес ТЗ
→ архитектурное ТЗ
→ генерация кода
→ автоисправление запросов
→ автотесты
→ автоисправление кода
→ повторная генерация
Отдельной проблемой оказались запросы к ERP:
- виртуальные таблицы;
- аналитики;
- разные механизмы резервирования;
- неоднозначные поля.
Для этого в пайплайн появился отдельный слой, который:
- анализирует ошибки запросов;
- предлагает исправления;
- повторно выполняет проверку;
- помогает диагностировать конфликты ERP-логики.
Подход no1C
Инструмент полностью реализован в моем no1C подходе:
1С = транзакционное учетное ядро
Python = внешний слой диагностики и аналитики
API = интеграционный слой
ERP продолжает выполнять свои основные задачи:
- учет;
- проведение документов;
- движения;
- транзакции.
Внешний контур берет на себя:
- объяснимость;
- диагностику;
- классификацию;
- управление;
- инжиниринг с помощью ИИ.
Вывод
В сложных ERP-системах проблема часто заключается не в отсутствии данных.
Наоборот – данных слишком много.
Основная сложность в том, чтобы быстро понять:
какой именно механизм сейчас влияет на доступность товара.
И, похоже, инструменты объяснимости поверх ERP действительно могут дать очень большой практический эффект.
А no1C-пайплайн оказался интересен не как “магическая генерация кода”, а как способ существенно снизить стоимость инженерных итераций при разработке ERP-решений.
Дополнительно чтобы убрать «эффект магии» можно посмотреть мое видео о том, как я это делаю по этой ссылке https://youtu.be/W6ZPVX_T9WA.
Вступайте в нашу телеграмм-группу Инфостарт