Закупки под заказ клиента в Битрикс24: как связать потребность, поставщика и поступление
Менеджер обещает клиенту комплект деталей, снабженец заказывает их у нескольких поставщиков, а склад принимает поставку частями. Разбираем, как сохранить связь между этими действиями и увидеть, что ещё мешает исполнить заказ.
Заказ клиента и заказ поставщику редко совпадают один к одному. Одному покупателю нужны позиции от разных производителей; одна закупка может закрывать потребности нескольких покупателей. Если хранить в сделке только общий статус «заказано», менеджер не поймёт, какая часть комплекта уже приехала и кому она предназначена.
Ниже — проектная схема для поставок под заказ. Её нужно адаптировать к действующей системе учёта: CRM организует работу продаж и снабжения, а подтверждённые складские операции остаются в выбранном учётном контуре.
Вместе с заявкой снабженец должен получить идентификатор товара, требуемое количество, единицу измерения, допустимость аналога и дату, к которой товар нужен клиенту. Для запчастей дополнительно могут потребоваться артикул производителя, модель оборудования и ограничения совместимости. Фраза «нужен такой же насос» не является спецификацией для заказа.
Каждой строке потребности назначают устойчивый идентификатор. Если клиент изменил количество, сохраняют новую редакцию, а не создают незаметно вторую заявку. Снабженец должен видеть разницу: что добавили, от чего отказались и какие уже размещённые заказы затронуты.
Для рабочих карточек можно использовать отдельный смарт-процесс, связанный со сделкой. Возможность таких связей описана в документации Битрикс24 . При этом одной связи карточек недостаточно для распределения количества по строкам: эту модель проектируют отдельно.
Какая часть поставки закрывает конкретную потребность
Объясняет готовность заказа клиента
Предложение поставщика не должно автоматически становиться заказом. На этапе сравнения вариантов можно запросить одну позицию у нескольких компаний; суммировать эти ответы как ожидаемое поступление нельзя. Заказ появляется после выбора и подтверждения условий.
Самая низкая цена в письме может относиться к другой упаковке, валюте или составу доставки. В карточке сравнения сохраняют исходную цену и отдельные составляющие расчёта: количество в упаковке, доставку, дополнительные расходы и дату курса, если пересчёт нужен. Правила расчёта согласуют с финансовой службой; универсальную формулу налогов для всех компаний задавать нельзя.
Замена товара требует отдельного решения. Снабженец предлагает аналог с описанием отличий, а сотрудник, уполномоченный согласовать замену с клиентом, фиксирует ответ. Молчание клиента и похожее название детали не означают согласия. После одобрения меняют редакцию спецификации и проверяют цену и срок повторно.
Учебный пример: клиенту нужны десять одинаковых деталей. Поставщик подтвердил десять, но склад принял шесть. В CRM следует показать: заказано десять, принято шесть, ещё ожидается четыре. Если две из принятых деталей выделены другому заказу, для этого клиента доступны четыре, а не шесть.
Подтверждение поставщиком, физическое поступление и выделение клиенту — разные события. Источник каждого показателя должен быть определён заранее. Если поступления ведутся в 1С, интеграция передаёт идентификатор документа, строки, количество, состояние проведения и отмены. Повтор одного события обновляет известную запись, а не увеличивает поступление второй раз.
Менеджеру полезно показывать готовность всего комплекта: какие строки закрыты, какая деталь задерживает отгрузку и возможна ли согласованная частичная доставка. Общий процент готовности скрывает проблему, если недостающая позиция делает остальные бесполезными.
Отмена клиента требует решения по уже заказанному товару #
При уменьшении заказа нельзя просто удалить строку потребности: товар мог быть оплачен или находиться в пути. Система должна поставить снабженцу задачу решить судьбу остатка — отменить у поставщика, вернуть, перевести в свободный запас или распределить на другой подтверждённый заказ. Решение и ответственного сохраняют в истории.
То же относится к исправлению складского документа. Если поступление отменили в учёте, CRM должна пересчитать доступность и вернуть затронутые потребности в работу. Сделка, которая остаётся «готова к отгрузке» после такой отмены, показывает опасно устаревший результат.
Проведите сквозной тест: две сделки требуют один товар, закупка объединяет их потребности, приходит часть поставки, затем один клиент уменьшает заказ. Проверьте распределение количества, остаток обязательств и список задач снабженца. Повторно передайте событие поступления и убедитесь, что количество не удвоилось. Затем отмените документ в тестовом контуре и проверьте обратный пересчёт.
Отдельно войдите под снабженцем и менеджером. Каждому нужны данные для своей работы; доступ к закупочным условиям и марже должен соответствовать его роли. Итог настройки — возможность объяснить каждую обещанную клиенту единицу товара через подтверждённый источник поставки.
Можно ли обойтись одной сделкой без смарт-процессов? #
Да, если закупка проста: один поставщик, один заказ клиента, без объединения потребностей и частичных поступлений. Когда появляются несколько предложений и распределение количества, дополнительные поля сделки становятся неудобным реестром. Тогда нужны отдельные связанные объекты или интеграция с закупочным контуром учётной системы.
Если снабжение уже полноценно работает в 1С, обычно полезнее передать в CRM потребности, подтверждённые сроки и готовность строк. Создавать второй независимый учёт заказов поставщикам стоит только после определения владельца каждого документа и правил сверки.
NetLabCS поможет спроектировать строки потребностей и сравнение предложений. Если закупки ведутся в учётной системе, интеграция Битрикс24 с 1С позволит связать их с клиентскими заказами по согласованной модели обмена. Для начала обсудите проект : покажите пример клиентского заказа, заказ поставщику и частичное поступление — по ним можно определить, где сегодня теряется связь между продажей и снабжением.
