Программа учёта заказов ведёт одну запись заказа через именованные статусы: получен, подтверждён, в сборке или в производстве, отправлен, доставлен, оплачен, и на каждом переходе фиксирует, кто, что и когда изменил. Коротко: если поток заказов стандартный (заказы из интернет-магазина или с маркетплейса, один склад, один прайс-лист), готовой системы учёта заказов достаточно; если у вас производство, опт или B2B (частичные отгрузки, цены по дилерам, связь с производственным заказом, интеграция со взаиморасчётами, этапы согласования), ответ в заказной разработке. А Excel перестаёт справляться не «когда вырастем», а в первый день, когда два человека правят один файл и никто не может сказать, кто и когда поменял статус. В этой статье мы рассказываем, как принимаем это решение в проектах по корпоративным решениям.
Что именно делает программа учёта заказов?
Учёт заказов звучит сложно, но держится на одной идее: есть одна запись заказа, и она проходит через определённые статусы. Программа управляет этим движением, знает, какие переходы разрешены, и записывает каждый переход в журнал. Типичная цепочка статусов выглядит так:
- Получен: заказ попал в систему; клиент, позиции, адрес и цена зафиксированы.
- Подтверждён: проверка остатков или цены пройдена, менеджер по продажам одобрил заказ.
- В сборке или в производстве: склад комплектует, либо открыт производственный заказ.
- Отправлен: есть трек-номер, посылка передана перевозчику.
- Доставлен: клиент получил товар, пошёл срок возврата.
- Оплачен: оплата отражена в бухгалтерии, заказ закрыт.
Рядом с каждым переходом стоят три факта: кто сделал, когда и из какого статуса. Без этой тройки ответ на вопрос «где заказ?» живёт в памяти сотрудников, а не в программе. Прослеживаемость, ещё до всяких отчётов, и есть главная ценность системы учёта заказов.
Где именно ломается Excel?
Excel разумный старт для компании с небольшим числом заказов и одним ответственным; проблема не в масштабе, а в двух конкретных точках излома. Первая: несколько человек правят один файл одновременно. Продажи вносят заказ, пока склад меняет статус, правки затирают друг друга, и никто не знает, какая строка верна. Вторая: нет истории статусов. Сегодня в ячейке написано «отправлен», но что там было вчера, кто это поменял и было ли согласование на самом деле, потеряно. Когда клиент звонит спросить, почему заказ опаздывает, оба пробела проявляются в один и тот же момент.
Переходить на программу учёта заказов нужно не «когда вырастем». В первый день, когда два человека правят одну таблицу и кто-то спрашивает, кто и когда изменил статус, предел Excel уже достигнут.
Ту же блокировку мы видим на стороне склада; точки излома из статьи программа складского учёта или заказная разработка подчиняются той же логике, что и учёт заказов, потому что в обоих случаях одна запись проходит через несколько рук.
Готовая система учёта заказов или заказная разработка?
Готовое решение подходит компаниям со стандартным потоком заказов. Стандартный значит: заказы приходят из интернет-магазина или с маркетплейса, уходят с одного склада, у всех клиентов один прайс-лист, и позиции не меняются до отгрузки. В таком потоке статусы, подключение к службе доставки и уведомления готового продукта закрывают всю потребность, а заказная разработка была бы лишними расходами.
Заказная система учёта заказов отвечает на задачи производства, опта и B2B. Там заказ не единое целое, и появляются правила, которых готовые продукты не предполагают:
- Частичные отгрузки: часть заказа уходит сегодня, остальное после производства; две накладные, один заказ.
- Прайс-листы по дилерам: один и тот же товар продаётся каждому клиенту по своей цене и с своей отсрочкой платежа.
- Связь с производственным заказом: подтверждение открывает производственный заказ, завершение производства само продвигает заказ дальше.
- Интеграция со взаиморасчётами: подтверждение заказа проверяет баланс клиента и кредитный лимит.
- Этапы согласования: заказы выше определённой суммы или со скидкой ждут решения руководителя.
Тест для решения прост: откройте форму заказа, которой пользуетесь сегодня, и посчитайте нестандартные поля. Код дилера, отсрочка платежа, срок производства, кратность упаковки, особая скидка, кто согласовал: если в форме готового продукта их нет, каждое станет «временным обходом». Если таких полей больше нескольких, готовый продукт будут гнуть, пока он не сломается; с этого момента заказная разработка выходит дешевле. Дилерскую сторону мы разобрали в статье B2B-система заказов для дилеров, связь с производством в статье программа учёта производства (MRP).
Обязательные функции программы учёта заказов
Готовая или заказная, не принимайте решение, пока не запросили эти шесть функций:
- Модель статусов с историей: каждый переход сохраняется с данными кто, когда и из какого статуса и не может быть удалён.
- Уведомление клиента при смене статуса: SMS, WhatsApp или e-mail при подтверждении, отправке и доставке; подробности в статье интеграция WhatsApp Business API.
- Ролевой доступ: продажи вносят и подтверждают, склад собирает и отправляет, бухгалтерия закрывает оплату; никто не меняет статус вне своей роли.
- Интеграция с бухгалтерией: заказ превращается в счёт и проводку в учётной системе, например 1С или, на турецком рынке, Logo; как это подключается, описано в статье интеграция с бухгалтерской программой.
- Интеграция с доставкой: этикетка печатается из системы, трек-номер автоматически записывается в заказ; см. интеграция со службами доставки.
- Отчёт по просроченным заказам: заказы, вышедшие за срок или задержавшиеся в одном статусе дольше ожидаемого, выводятся ежедневно.
Для тех, кому интересно, как модель статусов выглядит в коде, ниже небольшой пример на TypeScript, где разрешённые переходы хранятся в одной таблице. Поскольку таблица лежит в одном месте, правила вроде «отправленный заказ не может вернуться в ожидание подтверждения» работают одинаково на каждом экране:
type OrderStatus =
| 'received'
| 'confirmed'
| 'preparing'
| 'shipped'
| 'delivered'
| 'collected'
| 'cancelled';
const transitions: Record<OrderStatus, OrderStatus[]> = {
received: ['confirmed', 'cancelled'],
confirmed: ['preparing', 'cancelled'],
preparing: ['shipped'],
shipped: ['delivered'],
delivered: ['collected'],
collected: [],
cancelled: [],
};
function changeStatus(order: Order, next: OrderStatus, userId: string) {
if (!transitions[order.status].includes(next)) {
throw new Error(`${order.status} -> ${next} is not allowed`);
}
order.history.push({ from: order.status, to: next, userId, at: new Date() });
order.status = next;
}От чего зависит стоимость программы учёта заказов?
У готового продукта стоимость определяется числом пользователей и набором модулей, у заказной разработки широтой охвата. Сравнивая предложения, спрашивайте о каждом из этих пунктов отдельно; разница между двумя сметами обычно возникает из-за того, что один из них вынесен за рамки:
- Число статусов и этапов согласования: каждый дополнительный статус это экран, право доступа и уведомление.
- Число интеграций: бухгалтерия, доставка, интернет-магазин, маркетплейс и производственная система это отдельные подключения.
- Роли пользователей: насколько разделены экраны продаж, склада, бухгалтерии и руководителя.
- Перенос существующих данных: загрузка открытых заказов и списка клиентов из Excel в систему.
- Мобильное использование: нужен ли складу или выездным сотрудникам экран планшета или телефона.
- Сопровождение и хостинг: кто отвечает за обновления, резервные копии и поддержку.
Если складская и отгрузочная часть перерастает учёт заказов, ещё на этапе сметы стоит уточнить, где заканчивается система заказов и начинается система управления складом; две системы, хранящие одну запись дважды, это самая частая ошибка проектирования.
Вывод
При выборе программы учёта заказов вопрос не «какой бренд?», а «стандартный ли у меня поток?». Если вы работаете с заказами из магазина или маркетплейса, одним складом и одним прайс-листом, готового продукта достаточно; если есть частичные отгрузки, дилерские цены, производственные заказы и согласование по взаиморасчётам, вы будете нести продукт на себе, а не он вас. Начните с подсчёта нестандартных полей в форме заказа; если их больше нескольких, заказная разработка более верный путь. Пришлите нам текущую форму и схему потока через форму запроса, и на первой встрече мы вместе составим модель статусов.