Для многих компаний документ «Заказ поставщику» в их ERP-системе, будь то 1С или что-то другое, — это формальность. Сделали, распечатали, отправили, забыли. А потом начинается хаос: бухгалтерия ищет концы, чтобы оплатить счет; склад не понимает, что и когда приедет; логисты в панике ищут транспорт, а руководитель не может понять, на что ушли деньги. Знакомая картина?
Проблема в том, что к этому документу относятся как к простой «заявке», а не как к центральному узлу, который должен связывать воедино всю цепочку поставки. Правильно настроенный заказ — это ваш швейцарский нож в мире закупок. Он экономит часы работы для всех: от снабженца до финансового директора. Давайте разберем по косточкам, как превратить его из «мертвого» документа в живой и полезный инструмент, основываясь на реальной практике.
Фундамент: без чего заказ — это просто набор строк
Если у заказа нет четких идентификаторов, он теряется в системе. Это как человек без паспорта. Что будет, если этого нет? Менеджеры ищут заказы по сумме, дате, названию поставщика. Бухгалтер кричит: «Какой заказ оплачивать по этому счету?!». Склад разводит руками: «Мы приняли товар, а на какой заказ его повесить — не знаем».
Что будет, если это внедрить? Любой сотрудник — от кладовщика до финдира — по одному номеру мгновенно находит нужный документ и видит всю его историю.
Вот базовый набор, который должен быть железобетонно в каждом заказе:
- Уникальный номер заказа в ERP (1С). Это паспорт сделки. Система должна присваивать его автоматически, по шаблону, например, PO-2024-05-001. Это исключает дубли и человеческий фактор. Без него — анархия. С ним — порядок.
- Внутренний статус заказа. Это пульс вашей закупки. Статус показывает, на какой стадии находится заказ, и кто следующий в цепочке должен взять его в работу. Если статусов нет, менеджеру приходится обзванивать коллег: «Вася, ты согласовал?», «Петя, ты поставщику отправил?». Это колоссальная трата времени.Пример жизненного цикла статусов в 1С:
| Статус | Кто меняет / Что происходит |
|---|---|
| Черновик | Менеджер по закупкам создает и наполняет заказ. |
| На согласовании | Документ ушел по маршруту согласования (начальнику, финдиру). |
| Утвержден | Все визы получены, можно отправлять поставщику. |
| Отправлен поставщику | Факт отправки зафиксирован. |
| Подтвержден поставщиком | Получен ответ от контрагента (например, привязан его счет). |
| Выполнен | Товар полностью оприходован на склад. |
| Закрыт в бухгалтерии | Все финансовые документы проведены. |
- Ответственный владелец. Конкретный человек (ФИО, отдел), который ведет этот заказ от начала до конца. Не «отдел снабжения», а «Иванов Иван». Если что-то пойдет не так, все знают, кому звонить. Без этого — коллективная безответственность.
- Ключевые даты. Они должны проставляться автоматически, где это возможно. Дата создания, дата утверждения. А вот планируемая дата поставки и обещанная поставщиком дата — это уже результат коммуникации. Фактическая дата выполнения закроется сама при проведении документа поступления. Если не фиксировать даты, вы не сможете анализировать надежность поставщиков и строить прогнозы.
Детализация для снабжения и склада: дьявол в мелочах
Когда заказ попадает на склад или в отдел логистики, общие фразы уже не работают. Им нужны конкретные инструкции. Что будет, если детализации нет? Склад принимает товар «на глаз», а потом выясняется, что приехало не то, не в тех единицах измерения или не на тот объект. Логист заказывает машину, не зная точного веса и объема.
Что будет, если это внедрить? Склад точно знает, что сверять при приемке. Логистика планирует транспорт заранее. Ошибки приемки и пересортица стремятся к нулю.
Критически важные поля в каждой строке заказа:
- Внутренний артикул/код номенклатуры. Ваш главный ключ. Именно по нему система понимает, что это за товар.
- Артикул поставщика. Для сверки с его документами (счетом, накладной). Избавляет от споров «а мы думали, это вот та позиция».
- Заказанное количество и единица измерения (ЕИ). Простая, казалось бы, вещь. Но сколько проблем возникает, когда заказывают в «штуках», а поставщик отгружает в «коробках» или «килограммах». Четкое указание ЕИ обязательно.
- Цена за единицу и валюта. Основа для финансового планирования.
- Место назначения (склад, цех). Куда конкретно должен приехать товар? Это поле — прямая команда для склада и логистики. Не «на центральный склад», а на «Склад готовой продукции, стеллаж 5, ячейка B2».
Финансовый контроль: держим руку на пульсе бюджета
Закупки — это деньги. И финансовый отдел должен видеть не просто итоговую сумму, а всю подноготную. Что будет, если этого нет? Закупки выходят за рамки бюджета. Финансовый директор узнает о крупной сделке постфактум, когда на счету уже нет денег.
Что будет, если это внедрить? Полная прозрачность расходов. Каждый заказ проходит через настроенный маршрут согласования, и ответственные лица ставят свою электронную визу, подтверждая целесообразность и наличие лимитов.
Что нужно финансистам в заказе:
- Маршрут согласования. Четкая цепочка: менеджер → начальник отдела → финансовый директор. В ERP-системе (1С) должно быть видно, кто и когда согласовал заказ. Если кто-то не согласовал — заказ дальше не движется. Это автоматический барьер от неконтролируемых трат.
- Обоснование закупки. Простое текстовое поле, где менеджер в двух словах пишет, зачем это нужно. Например: «Для проекта ‘Альфа’», «На замену сломанного станка в цехе №3», «По результатам тендера №123». Это поле экономит часы финдиру: ему не нужно звонить и выяснять, что это за трата. Он видит контекст прямо в документе.
Связь с другими процессами: строим единую экосистему
Заказ поставщику не живет в вакууме. Он рождается из внутренней потребности и порождает физическое движение товара.
- Связь с первичной заявкой. Часто закупка начинается с того, что какой-то отдел (например, производство) создает внутреннюю заявку. В заказе поставщику должна быть прямая ссылка на номер этой заявки. Зачем это? Чтобы в любой момент можно было отследить всю цепочку: кто изначально попросил, что просил и что в итоге заказали. Это снимает вопросы «А кто это вообще просил купить?».
- Данные для приемки. На основании утвержденного заказа система должна автоматически создавать «Ожидаемое поступление». Когда товар физически приезжает на склад, кладовщик не придумывает документ с нуля, а открывает готовый и просто сверяет факт с планом. Это ускоряет приемку в разы и минимизирует ошибки.
Вывод: от хаоса к управляемости
Правильно настроенный документ «Заказ поставщику» в ERP — это не дополнительная бюрократия. Это инвестиция в порядок. Он перестает быть просто формальностью для отправки поставщику и становится центральным хабом информации.
Что вы получаете в итоге:
- Прозрачность: любой участник процесса видит актуальный статус и всю историю.
- Скорость: автоматизация статусов, согласований и создания связанных документов экономит часы ручного труда.
- Контроль: финансовые лимиты и обоснования не дают деньгам утекать бесконтрольно.
- Снижение ошибок: четкие данные по номенклатуре, количеству и месту назначения исключают пересортицу и неверные поставки.
В конечном счете, вы получаете управляемую, предсказуемую и эффективную систему закупок, где каждый знает свою роль, а информация доступна всем в режиме реального времени. И все это начинается с одного-единственного, но правильно настроенного документа.
Чек-лист для настройки документа «Заказ поставщику» в ERP (для вставки в Excel)
| Категория | Пункт проверки | Статус (Да/Нет/В доработке) | Ответственный/Комментарий |
|---|---|---|---|
| I. Базовые реквизиты | Уникальный номер заказа присваивается автоматически | ||
| Настроен и используется справочник статусов заказа | |||
| В заказе всегда указан ответственный менеджер (владелец) | |||
| Автоматически фиксируется дата создания и утверждения | |||
| Есть поля для плановой и обещанной поставщиком даты поставки | |||
| II. Данные для логистики | Каждая строка содержит внутренний артикул (код номенклатуры) | ||
| В строках есть поле для артикула поставщика | |||
| Количество и Единица Измерения — обязательные поля | |||
| Цена и валюта указываются для каждой позиции | |||
| Есть возможность указать точное место назначения (склад/цех) | |||
| III. Финансовый контроль | Настроен электронный маршрут согласования с визами | ||
| Есть обязательное текстовое поле «Обоснование закупки» | |||
| Система контролирует бюджеты/лимиты при согласовании | |||
| IV. Интеграция | Заказ можно создать на основании внутренней заявки (есть связь) | ||
| На основании заказа автоматически создается «Ожидаемое поступление» | |||
| V. Работа с поставщиком | Есть функция удобной выгрузки заказа в PDF/Excel для отправки | ||
| В системе можно зафиксировать подтверждение от поставщика (статус/счет) |