Коротко
- 1С остаётся системой учёта, аналитический сервис рассчитывает рекомендации.
- Сначала автоматизируют типовые решения, сложные исключения оставляют эксперту.
- Каждая рекомендация должна объяснять входные параметры и причину.
Какое решение помогает принять материал
Спроектировать рекомендательный контур поверх 1С, определить минимальный набор данных и автоматизировать типовые заказы без потери контроля над исключениями.
- Основной вопрос
- как автоматизировать закупки в 1С
- Тематический раздел
- Прогноз и закупки
Упрощённый расчёт потребности
Заказ = прогноз до следующего пополнения + страховой запас − доступный остаток − ожидаемые поступления.
После расчёта применяются MOQ, кратность упаковки, бюджет, календарь и ограничения поставщика.
Как разделить роли 1С и аналитического контура
Из 1С получают нормативно-справочную информацию, продажи, остатки, заказы, поступления, поставщиков и цены. В отдельном расчётном слое очищают данные, строят прогноз и оптимизируют заказ. В 1С возвращают черновик документа или рекомендации для подтверждения.
Такой подход не требует заменять учётную систему и позволяет развивать модели независимо. На первом пилоте обмен может идти через защищённые файлы, затем — через API или регламентные задания.
Какие данные обязательны
- SKU, склад, единицы измерения и статусы жизненного цикла.
- Продажи и возвраты по датам, желательно с признаком наличия.
- Текущие остатки, резервы и доступное количество.
- Открытые заказы поставщикам и ожидаемые даты.
- Фактические сроки и полнота прошлых поставок.
- MOQ, кратность, упаковка, календарь и закупочная цена.
Как выглядит ежедневный процесс
| Этап | Результат | Контроль |
|---|---|---|
| Загрузка | Актуальный срез данных | Пропуски и расхождения |
| Расчёт | Потребность по SKU × склад | Версия модели и параметров |
| Ограничения | Реализуемый заказ | MOQ, бюджет, транспорт |
| Подтверждение | Принято, изменено или отклонено | Причина ручной правки |
| Обратная связь | Факт поставки и продаж | Эффект и ошибки |
Что автоматизировать в первом пилоте
Лучший кандидат — категория с регулярным спросом, заметным числом SKU и понятными условиями поставщиков. Сначала рекомендации работают в режиме советчика: закупщик сравнивает их со своим решением и фиксирует причины расхождений.
После проверки качества часть типовых заказов можно переводить в автоматическое создание черновика, сохраняя подтверждение для дорогих, новых, промо- и Z-позиций.
Почему проекты автозаказа не взлетают
- Система не видит открытые заказы и повторно закупает уже заказанный товар.
- Договорной lead time отличается от фактического.
- Продажи в дефицит ошибочно интерпретируются как низкий спрос.
- Нет причин ручной корректировки, поэтому модель не обучается на процессе.
- Команде показывают число без объяснения и ожидают доверия.
ПроЗапасы начинает с аудита данных и процесса закупки, чтобы заранее найти эти ограничения и выбрать реалистичный контур интеграции.
Контракт данных между 1С и расчётным контуром
До разработки фиксируют не просто список таблиц, а смысл каждого поля: единицу измерения, часовой пояс, дату доступности остатка, статус заказа, правила отмены и идентификатор SKU. Особенно важны стабильные ключи. Если один товар имеет разные коды в продажах, остатках и прайс-листе поставщика, автозаказ будет ошибаться ещё до применения модели.
| Набор | Минимальные поля | Контроль качества |
|---|---|---|
| Продажи | Дата, SKU, склад, количество, сумма, возврат | Дубли и технические движения |
| Остатки | Дата снимка, доступно, резерв, в пути | Баланс и пропущенные снимки |
| Заказы | Поставщик, дата, количество, статус, ожидаемая дата | Отмены и частичное исполнение |
| Справочники | Единица, упаковка, аналог, категория, жизненный цикл | Изменение ключей и кратность |
Как должен выглядеть экран закупщика
Пользователю нужен не список из тысяч строк, а очередь исключений. Система автоматически принимает типовые позиции в заданных пределах, а на проверку выводит крупную сумму, новый товар, скачок спроса, ненадёжного поставщика, нарушение лимита или конфликт данных.
У каждой рекомендации должны быть объяснение и версия входных параметров: спрос на горизонте, текущая позиция запаса, ожидаемые поставки, страховой запас, MOQ и причина ручной корректировки. После поставки система сравнивает рекомендацию с фактом и сохраняет, где человек изменил количество. Это превращает ручной опыт в проверяемую обратную связь.
Безопасный периметр первого пилота
Для пилота выбирают одну товарную категорию, ограниченное число складов и поставщиков с предсказуемым обменом. Первые недели рекомендации работают в теневом режиме: система считает заказ, но документ создаётся только после проверки. Затем автоматизируют позиции с понятным спросом и устойчивыми ограничениями.
Критерий перехода к следующему этапу: данные сходятся, рекомендации объяснимы, число ручных исключений снижается, а запас и доступность не ухудшаются относительно базовой линии.
Частые вопросы
Нужно ли дорабатывать типовую конфигурацию 1С?
Не всегда. Обмен можно построить через расширение, API, регламентную выгрузку или загрузку черновиков документов, сохраняя типовую конфигурацию.
Можно ли сразу включить полностью автоматический заказ?
Для пилота безопаснее режим рекомендаций и подтверждения. Автоматизацию расширяют после измерения качества и разбора исключений.
Как контролировать работу алгоритма?
Хранить входные данные, версию параметров, расчёт, ручную правку, причину и фактический результат поставки.
Источники и методика
Расчётные примеры в статьях являются учебными, если прямо не указано иное. Они показывают методику, но не обещают такой же результат для конкретной компании.
- 1С:Предприятие: REST-интерфейс Официальное описание доступа внешних систем к данным 1С через OData и HTTP.
- 1С:Предприятие: интеграция Поддерживаемые платформой механизмы обмена и интеграции.