Частичные отгрузки в опте: как не потерять остаток заказа

При частичной отгрузке оптового заказа состояние нужно хранить по строкам и количеству, а не только общим статусом документа. Отправка первой партии не завершает обещание поставить остальное. Для управления поставками разделите согласованный объём, состоявшиеся отгрузки, подтверждённые отмены и ещё не выполненную часть. Ниже — предлагаемая модель учёта, которую можно включить в задание на разработку. Это не инструкция по бухгалтерским документам и не описание возможностей конкретной готовой CRM.

Рассмотрим условный заказ на сто одинаковых изделий. Сначала отправили сорок, затем тридцать пять. Ещё десять заказчик согласовал отменить. В рабочей очереди остаются пятнадцать изделий: сто минус сорок минус тридцать пять минус десять. Этот учебный пример показывает арифметику количества. Он не определяет момент перехода прав, признание выручки или порядок расчётов: такие вопросы зависят от согласованных условий и требуют отдельного учёта.

Заказ на сто изделий не превращается в три независимых заказа

Если для каждой отправки создавать несвязанный документ с новой суммой потребности, менеджер теряет первоначальный объём. Из общей переписки уже непонятно, покупатель заказал сто изделий или три раза повторил пожелание. Каждую отгрузку лучше связывать с исходной строкой заказа, сохраняя собственную дату и количество. Тогда можно получить историю исполнения и объяснить остаток без восстановления событий из сообщений склада.

Название товара недостаточно для такой связи. В строке нужен устойчивый идентификатор согласованной позиции, выбранная единица и относящиеся к ней условия. Замена артикула не должна происходить только потому, что свободный товар похож по описанию. Если покупатель согласился на замену, сохраните отдельное решение и его влияние на исходное обязательство. Иначе система может показывать выполненную строку, которую клиент считает недопоставленной.

Проверьте и единицы количества. Коробки, отдельные изделия и комплекты нельзя вычитать друг из друга без определённого правила пересчёта. Для учебного заказа мы используем только изделия и не меняем упаковку. В реальном проекте соотношение единиц, округления и возможность вскрывать упаковку согласуют до реализации. Нельзя незаметно принять любую коробку за одинаковое число штук во всех партиях поставщика.

Четыре записи, которые удобно разбирать отдельно

Заказ хранит потребность, отгрузка — событие исполнения, резерв — назначение доступного запаса, а план поставки — ожидание будущего действия. Это предложенное разделение для проектирования. Конкретный состав документов зависит от процессов компании, но смысловые различия полезно сохранять. Иначе обещанное поступление на склад начинает уменьшать задолженность перед покупателем, хотя товар ещё не отправлен.

Резерв также не равен выполнению. Склад может выделить нужное количество под заказ, после чего обнаружить препятствие к отправке. Если менеджер видит только «закрыто резервом», он перестаёт работать с остатком. В рабочей таблице лучше одновременно показывать непоставленное количество, резерв и следующее действие. Эти значения отвечают на разные вопросы: сколько ещё должны выполнить, чем обеспечено и что сотруднику делать дальше.

Отменили десять или перенесли десять — разные решения

В учебном примере отмена десяти изделий уменьшила остаток до пятнадцати. Если вместо отмены согласовали более позднюю дату, после двух отгрузок оставалось бы двадцать пять. Разница нужна сотруднику при закупке и разговоре с покупателем. Поле «не отправлено сейчас» не сообщает, исчезла ли потребность или её требуется выполнить позже. Поэтому причина изменения и подтверждение решения должны быть видны.

Для отмены оставьте исходное количество и отдельную запись изменения. Перезапись ста на девяносто без истории затруднит объяснение прежних согласований. Укажите, кто принял решение, к каким строкам оно относится и что делать с уже назначенным резервом. Не освобождайте весь резерв заказа по отмене одной позиции. Если операция затрагивает расчёты или документы, маршрут её согласования обсуждают отдельно с ответственными сотрудниками.

Перенос даты тоже не должен быть одним свободным текстом. Нужны прежняя дата, новая согласованная дата либо явно неизвестный срок и следующее действие. Если поставщик пока не подтвердил поступление, не обещайте покупателю точный день только ради заполнения обязательного поля. Неопределённость лучше оставить видимой: кто уточняет, какое подтверждение ждёт и когда вернётся к вопросу. Это рабочая задача, которую можно поставить в очередь.

Возврат не даёт системе права самостоятельно обещать замену

Допустим, из первой партии вернули пять изделий. Это ещё не отвечает на вопрос, нужно ли повторно поставить пять. Покупатель может ожидать замену, отказаться от части заказа или обсуждать другой вариант. Отразите движение товара и отдельное согласованное решение по дальнейшему исполнению. Пока решения нет, сотрудник должен видеть вопрос, а не автоматически возникшее обещание новой отгрузки.

Не исправляйте старое событие отправки так, будто этих пяти изделий никогда не было. Оно объясняет прежний остаток и действия компании. Для предложенной модели возврат связывается с исходной отгрузкой, а новое обязательство появляется по согласованному правилу. Это позволит отдельно проверить движение запаса и объём следующей поставки. Финансовые последствия такого события здесь не рассчитываются: для них требуется собственная согласованная модель.

Импорт событий должен выдерживать повторную загрузку

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

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

Рабочая очередь менеджера: сначала причина, потом дата

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

Причины ожидания должны помогать действовать: ждём поступление, согласуем замену, уточняем отмену, готовим отправку. У каждой причины может быть своё следующее действие. Общая отметка «в работе» не объясняет, нужно ли звонить поставщику, комплектовать товар или дождаться ответа покупателя. При изменении причины сохраняйте историю, чтобы следующий сотрудник видел, что уже проверено, и не начинал разговор заново.

Набор испытаний для будущей системы

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

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

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