Картина знакомая почти любой компании на 1С:ERP. Менеджер провёл заказ клиента — со складом, датами отгрузки, назначением. Для продаж документ «готовый». Для закупки он пока ничего не значит: закупщику всё равно нужно понять, чего на складе не хватает, у какого поставщика это брать, на какую дату и не заказали ли это уже вчера по другому заказу.
Типовая ERP умеет обеспечивать заказы, резервировать остаток и строить график. Но «создать заявку на заказ поставщику из заказа клиента так, чтобы в неё попал только дефицит» из коробки обычно нет. Между двумя документами остаётся человек с калькулятором и риском заказать лишнее — или не заказать вовремя.
Но этот разрыв можно закрыть, и не отдельным Excel-контуром, а кнопкой в привычном заказе клиента. В статье мы рассмотрим где обычно теряется время и какая логика стоит за кнопкой, чтобы она помогала, а не плодила мусор в закупках.
Связка «заказ клиента → заявка на закупку» в 1С:ERP решает три конкретные проблемы: ручной пересчёт дефицита (система вычитает свободный остаток сама), копирование не тех цен (цены продажи в заявку не переносятся) и дублирование заявок на одну потребность (перед созданием проверяется, нет ли уже открытой заявки по этому заказу). Логика расчёта зависит от способа обеспечения строки: при обычном — в заявку уходит только недостача; при обособленном обеспечении — полный объём под клиента, чужой свободный остаток не затрагивается. Если дефицита нет — документ не открывается, появляется сообщение. Реализуется расширением, чтобы конфигурация оставалась на поддержке.
Где на самом деле тратится время?
Само создание документа занимает минуты. Часы уходят на то, что вокруг него.
Закупщик открывает заказ на 30–40 строк и сравнивает его со свободным остатком. Часть позиций уже на складе, часть — в пути, часть нужна «под клиента» и чужой свободный остаток брать нельзя. Потом вручную переносит в заявку количества, склад, договор, дату. Потом ещё раз проверяет, не сделал ли коллега заявку по этому же заказу утром.
С какими проблемами можно столкнуться при таком режиме:
- В заявку уехал весь заказ, а не недостача. На складе лежат свободные 40 штук, в заказе 100 — закупают 100. Через неделю — излишки и замороженные деньги.
- В закупку уехали цены продажи. Менеджер дал клиенту скидку, закупщик скопировал сумму «как есть». Потом невозможно понять, где маржа, а где ошибка переноса.
- Одна потребность — две заявки. Смену сдали, документ не нашли, создали ещё раз. Поставщик получает двойной заказ, отменять уже неудобно или невозможно.
Автоматизация здесь нужна, чтобы система сделала ту работу, в которой человек может допускать ошибки: вычесть остаток, не перепутать обеспечение, не задвоить открытую заявку.
Свободный остаток и «под заказ» — это не одно и то же
Если скопировать в заявку все строки заказа клиента, получится красивый, но бесполезный документ. Считать нужно по-разному.
Когда строка стоит к обеспечению, в закупку должно уйти только то, чего не покрывает свободный остаток на складе. Заказали 100, свободно 40 — в заявке 60. Если свободно 120, строки в заявке быть не должно: закупать нечего.
Когда строка обеспечивается обособленно — «этот товар именно этому клиенту» — свободный чужой остаток не экономит закупку. В заявку идёт полный объём. Иначе система «съест» склад, который уже обещан другому заказу, а нужный клиент останется без отгрузки.
Что происходит, когда нажимают «создать на основании»:
Рабочий сценарий выглядит так.
Менеджер довёл заказ клиента до статуса, с которым отдел закупок уже может работать — например, «К обеспечению» или «Удерживать». Из списка заказов или из самого документа выбирает создание заявки на заказ поставщику.
Система проходит по строкам, считает дефицит, собирает шапку. Организация берётся из заказа клиента. Желаемая дата поступления — из даты отгрузки; если даты стоят построчно, в шапку уходит самая ранняя, чтобы закупка не опоздала к первой отгрузке. Если включено обособленное обеспечение, в заявку подставляется назначение под этот заказ клиента.
Поставщика система не выдумывает. Если в карточке номенклатуры или в соглашении указан основной поставщик — он попадает в шапку. Если нет — поле пустое, закупщик выбирает сам. Договор заполняется только когда для этой организации и поставщика в базе ровно один действующий договор «с поставщиком». Несколько договоров — тоже ручной выбор. Это намеренно: лучше пустое поле, чем случайный договор.
Цены продажи в заявку не копируются. Если в базе уже есть тип цен поставщика — можно подставить закупочную цену. Если нет, сумма остаётся для закупщика. Склад лучше держать в строках: один заказ клиента часто собирается с двух складов, и «средний» склад в шапке только путает отгрузку.
Если дефицита нет, документ не должен открываться пустым. Достаточно сообщения: все товары по заказу есть на складе, заявка не нужна. Пустая заявка в журнале — это не контроль, а шум.
И последнее, перед созданием система проверяет, нет ли уже открытой заявки на этот же дефицит по этому заказу клиента. Есть — новую не делает.
Зачем делать это расширением, а не «допилить конфигурацию»?
Кажется, что проще вставить кнопку прямо в типовую ERP. На практике это значит снять конфигурацию с поддержки и на каждом обновлении вендора заново сверять закупки, обеспечение и формы заказов.
Та же логика переносится на 1С:Комплексную автоматизацию — там контур заказов и обеспечения близкий. На других конфигурациях идею можно повторить, но сначала нужно смотреть, какими документами живут продажа и закупка.
Кому подходит и что необходимо проверить перед началом:
Автоматизация хорошо встаёт, когда заказы клиентов — постоянный поток, а не редкий документ, и закупка реально отталкивается от продаж, а не от «склада впрок». Особенно если часть номенклатуры идёт под конкретного клиента, склады разные, а в заявках уже случались дубли.
Что проверить перед началом доработки:
- заполнены ли основные поставщики хотя бы на ходовой номенклатуре;
- не размножены ли договоры «с поставщиком» без необходимости — иначе договор всё равно будут выбирать руками;
- включены ли склады в табличную часть, если отгрузка идёт с нескольких площадок;
- настроены ли типы цен поставщиков — иначе заявки будут без сумм.
Если этого нет, кнопка всё равно сэкономит пересчёт количества. Но «магию» поставщика, договора и цены она не вытянет из пустых справочников.
Связка заказа клиента и заявки на закупку стоит того, когда она убирает три вещи: ручной пересчёт дефицита, копирование не тех цен и повторные заявки на одну потребность. Тогда у закупщика остаётся работа, которую система не заменяет: выбрать поставщика, если их несколько, согласовать срок и превратить заявку в заказ поставщику.
Часто задаваемые вопросы
Как система считает, сколько товара нужно заказать у поставщика?
Расчёт зависит от способа обеспечения строки заказа клиента. Строка «к обеспечению»: из заказанного количества вычитается свободный остаток на складе — в заявку уходит только недостача. Если свободного хватает, строки в заявке не будет. Строка «обособленно»: в заявку идёт полный объём под клиента, свободный чужой остаток не учитывается — иначе система израсходует склад, уже обещанный другому заказу.
Почему поставщик или договор иногда остаются пустыми в созданной заявке?
Это намеренно. Поставщик подставляется только если в карточке номенклатуры или в соглашении указан основной поставщик. Договор заполняется только когда для данной организации и поставщика в базе ровно один действующий договор «с поставщиком». Если поставщиков несколько или договоров несколько — поле остаётся пустым: лучше пустое поле, чем случайный договор. Это не баг — это приглашение закупщику сделать осознанный выбор.
Что нужно проверить в базе перед внедрением доработки?
Четыре вещи: (1) заполнены ли основные поставщики хотя бы на ходовой номенклатуре; (2) не размножены ли договоры «с поставщиком» без необходимости — иначе договор всё равно будут выбирать руками; (3) включены ли склады в табличную часть, если отгрузка идёт с нескольких площадок; (4) настроены ли типы цен поставщиков — иначе заявки будут без сумм. Без этого кнопка сэкономит пересчёт количества, но поставщика, договор и цену из пустых справочников не вытянет.
Работает ли та же логика в 1С:Комплексной автоматизации?
Да. Контур заказов и обеспечения в «1С:Комплексной автоматизации» близкий к 1С:ERP, поэтому та же логика переносится без принципиальных изменений. Для других конфигураций нужно сначала проверить, какими документами живут продажа и закупка, — структура может отличаться.