Разработка системы управления закупками: от заявки до оплаты поставщику

Типовые позиции заказчик выбирает из справочника: единица, цена по действующему договору и поставщик по умолчанию подставляются сами. Нетиповое описывается текстом и проходит через закупщика, который заводит позицию в справочник или покупает разово. Справочник остаётся в учёте, чтобы у позиции был один хозяин; порядок в номенклатуре описан в статье про нормативно-справочную информацию.

• Порог по сумме и категория. Малую закупку согласует руководитель подразделения, крупную ведут дальше по цепочке; ИТ-оборудование согласует ИТ, расходники — хозяйственная служба. Пороги задаёт заказчик системы, а не разработчик.
• Бюджет. До согласования система показывает остаток по центру затрат и то, что останется после закупки. Бюджет ведётся в вашем учёте, система читает копию.
• Замещение и сроки. Согласующего нет на месте: заявка идёт к заместителю, нет ответа в срок: напоминание и эскалация. Молчаливое согласование по истечении срока не вводим, пока вы этого прямо не потребуете.
• Возврат на доработку. Согласующий возвращает заявку с комментарием, а не отклоняет целиком; история правок сохраняется.

Маршрут записывается таблицей: условие, согласующий, срок, действие при пропуске. Её подписывает владелец процесса до разработки. Действует разделение обязанностей: кто заявил, тот не согласует и не оплачивает свою заявку; журнал фиксирует каждое изменение, а согласованный заказ меняется только новой версией с повторным согласованием. Дробление закупки на части ниже порога система не запрещает, а показывает похожие закупки по поставщику и периоду и просит обоснование.

Карточка поставщика в учёте остаётся главной: реквизиты, договоры, банковские данные. Система добавляет то, чего в учёте обычно нет: категории, по которым поставщик допущен, статус проверки, сроки действия документов, историю предложений и исполнения. Данные объединяются по одному идентификатору контрагента, а дубли (один поставщик, заведённый трижды) вычищаются до запуска.

Если поставщиков немного, они работают через почту: система сама отправляет запросы и заказы и принимает ответы по ссылке. Если поставщиков много и заказы идут постоянно, есть смысл в кабинете поставщика: заказы и статусы, подтверждение сроков, загрузка счетов, сообщение о задержке. Нижняя граница по порталам и кабинетам — от 250 000 ₽, подробнее на странице порталов.

Оценка поставщика строится на фактах: доля заказов в срок, расхождения по приёмке, время ответа. Формулы ваши, рейтинга «по умолчанию» нет.

Система сравнивает заказ, приёмку и счёт по каждой позиции: количество, цену, сумму, условия. Совпало в пределах допуска — счёт идёт на оплату по расписанию. Не совпало — счёт останавливается у ответственного с указанием, что расходится.

• Допуски. Допустимое расхождение по цене и количеству задаёт финансовая служба, для разных категорий разное. Допуски записаны, а не живут в голове бухгалтера.
• Частичные поставки. Заказ закрывается несколькими приёмками, остаток остаётся открытым, закупщик получает напоминание.
• Приёмка без заказа и счёт без приёмки помечаются и не идут в оплату без решения ответственного: именно они ведут к повторным и ошибочным платежам. Для услуг вместо складской приёмки акт, подтверждённый заказчиком.

Счета и накладные приходят файлами и сканами. Распознавание на нашем сервере в закрытом контуре и загрузка результата в учёт описаны на страницах распознавания документов и загрузки документов в 1С. Решение «принимать счёт или нет» остаётся за человеком.

Если закупки простые (один контур, один склад, немного согласующих), нередко хватает модуля закупок в 1С или ERP и настройки маршрута. Заказная система нужна, когда процесс нетиповой: сложный маршрут по категориям, выбор по критериям, кабинет поставщика, несколько юридических лиц. Логика сравнения та же, что в статье «Своя CRM или готовая», а общий выбор ERP разобран в статье «Как выбрать ERP-систему».

Закупки близки к внутренним системам на заказ. Витрина для ваших собственных покупателей — это оптовая платформа. Если главное в обмене с учётом без интерфейса, начинают с интеграции ERP или API и бэкенда.