Частичные отгрузки без путаницы в заказах и обмене с 1С

Из пяти заказанных чашек три можно отправить сегодня, а две будут готовы через неделю. Покупатель согласен получить заказ частями. Если магазин после первой посылки поставит всему заказу статус «Выполнен», оставшиеся чашки легко потерять из виду. Если создаст второй независимый заказ, появятся новые вопросы: куда отнести уже полученные деньги и не передаст ли обмен в 1С продажу повторно?

Рабочая модель сохраняет один заказ и отдельно описывает каждую отгрузку. При этом количество запланированных к отправке вещей, факт отправки и состояние оплаты учитываются независимо. В «1С-Битрикс: Управление сайтом» существуют отдельные документы отгрузок и оплат. Но наличие этих сущностей само по себе не доказывает, что конкретный модуль обмена передаёт их правильно.

Продолжим условный пример с одной товарной позицией. В заказе пять одинаковых чашек. В первой отгрузке запланированы три, во второй — две. Состав заказа не уменьшается до трёх только потому, что сегодня склад готов отправить именно столько. Покупатель по-прежнему ждёт исполнения обязательства на пять единиц.

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

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

У заказа с несколькими товарами одна отгрузка может содержать часть каждой строки. Поэтому связь «одна строка заказа — один документ отгрузки» слишком узкая. Нужна возможность распределить количество строки между несколькими документами и увидеть нераспределённый остаток. Для проекта полезно записать проверку простыми словами: ни одна единица не должна одновременно числиться в двух действующих планах отправки.

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

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

Официальный курс 1С-Битрикс описывает разделение ещё не начатой отгрузки на несколько документов без изменения состава заказа. Приведённая там процедура имеет условие: процесс отгрузки товаров ещё не начат. Переносить её на уже отправленный документ нельзя. Эта статья объясняет модель работы; удаление и пересоздание документов в действующем магазине здесь не предлагается.

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

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

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

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

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

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

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

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

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

Освобождение резерва, изменение суммы и возврат денег могут происходить в разных системах и в разное время. После решения менеджера об отмене нельзя автоматически считать, что все три действия уже завершились. Каждому нужен ответственный источник и проверяемое подтверждение. Особенно опасно одновременно вернуть доступность товара на сайте и в 1С двумя независимыми обработчиками одного события.

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

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

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

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

Three of the five ordered mugs can be shipped today, while the other two will be ready in a week. The buyer agrees to receive the order in parts. If the store marks the entire order as "Completed" after the first shipment, the remaining mugs are easily overlooked. If a second independent order is created, new questions arise: where to allocate the already received funds, and will the 1C exchange process the sale again?

The working model maintains a single order while describing each shipment separately. The quantity planned for shipment, the actual shipment status, and payment status are tracked independently. In "1C-Bitrix: Site Management," there are separate shipment and payment documents. However, the mere existence of these entities does not prove that a specific exchange module transmits them correctly.

Let's continue the conditional example with a single product item. The order contains five identical mugs. The first shipment is scheduled for three, the second for two. The order quantity does not decrease to three simply because the warehouse is ready to ship exactly that many today. The buyer still expects fulfillment of the obligation for five units.

Now the first batch has actually been handed over to the carrier. The accounting system must distinguish three values: five ordered, three shipped, and two remaining to be shipped. The second shipment may already exist as a plan, but creating it does not turn the planned two mugs into shipped ones. The sum of quantities in documents and the sum of actually fulfilled items answer different questions.

Control is required for each order line, not just the total number of items. Three mugs and two plates also sum to five, but they do not fulfill the original order. In data exchange, it is crucial to maintain a stable link with the product item, its variant, and the unit of measurement. If one system counts pieces while another counts packages, agree on the conversion coefficient and allowable fractional precision before launch.

An order with multiple items may have a single shipment containing part of each line. Therefore, the one-to-one relationship between an order line and a shipment document is too narrow. It is necessary to be able to distribute the line quantity across multiple documents and view the unallocated remainder. For the project, it is useful to record the check in simple terms: no single unit should simultaneously be counted in two active shipping plans.

A single shipment may be split across multiple boxes. Conversely, a carrier may offer its own model for consolidating shipments. One cannot equate the number of boxes with the number of shipments without verifying the rules of the specific module. The store document ID, the accounting system document number, and the carrier tracking number serve different purposes.

This distinction is especially important for notifications. The message "three items shipped" describes the fulfillment of order lines. The message "two shipping units handed over" describes the packaging. If two cups are packed into one box, the customer should not be promised two parcels. In the manager interface, it is useful to see both the batch composition and the associated tracking numbers without substituting one for the other.

The official 1C-Bitrix course describes splitting a shipment that has not yet started into multiple documents without changing the order composition. The procedure provided there has a condition: the goods shipment process must not have started. It cannot be applied to a document that has already been shipped. This article explains the working model; it does not propose deleting and recreating documents in a live store.

Implementation requires separately checking the product edition, the store module version, the delivery solution, and the warehouse accounting mode. An external module may store the carrier request internally. Changing the document on the site does not guarantee cancellation of an already created request in the external system, even if the interface button executed without error.

The buyer might have paid for all five cups in advance. In that case, after the first shipment, the order is fully paid but only partially fulfilled. In another agreement, funds arrive by batches. Both schemes require explicit rules, not automatic copying of the shipment status to the payment status.

Delivery costs may also change: two shipments often have different economics than one. Before splitting, determine who pays for the additional transport and what amount the buyer will see. The order total, the carrier's calculation, and the store's actual cost may differ. This discrepancy must be explained in the process, not hidden by manually editing a single figure.

Do not distribute a payment across documents proportionally to the number of items without an agreed model. Products may have different prices and discounts. Even two batches that look identical can have different shipping costs. Responsible specialists verify requirements for payment, accounting, and cash documents for a specific sales scheme; a general example with cups does not replace such verification.

In the integration task, specify which system creates the document, which confirms the physical shipment, and who is authorized to change the remaining quantity. The phrase 'statuses are synchronized' does not answer these questions. If the website and 1C independently edit the same fact, the older state may overwrite the confirmed new state during the next exchange.

Each document requires a stable link between systems. An order number alone is insufficient: it already has two shipments. A repeated message about the first batch must update or confirm the same record, not create another shipment of three cups. Date, amount, and similar names are unreliable as the sole method of matching.

Let us consider another training scenario. In 1C, the first batch is confirmed, but the website's response was lost. Repeating the exchange is logical. If the handler treats any incoming message as a new shipment, the store will display six shipped cups instead of five. Duplicate protection must be verified at the document and operation level, preserving a diagnostic record of the processing result.

A separate scenario involves messages arriving out of order. A shipment confirmation must not be silently replaced by an earlier picking plan. The developer selects the appropriate versioning, event, or priority rules for the specific exchange. Universal time comparison across two servers is unreliable without an agreed format and understanding of the time source.

Cancelling the unshipped portion and returning already shipped items are different events. In our example, three cups are already with the carrier, while two remain in the plan. Refusing these two must not cancel the fact of the first shipment. The subsequent order state must show the fulfilled portion and the agreed change to the remaining obligation.

Releasing a reserve, changing the amount, and refunding money can occur in different systems at different times. After a manager decides to cancel, one cannot automatically assume that all three actions are complete. Each requires a responsible source and verifiable confirmation. It is especially dangerous to simultaneously restore product availability on the website and in 1C using two independent handlers for the same event.

When returning a received item, another fact arises: was the product actually accepted and is it suitable for resale? A customer marking "I want to return" does not equal arrival at the warehouse. Such events should be modeled separately from canceling an unshipped reserve; otherwise, the count of available products will depend on correspondence rather than actual movement.

Prepare a small synthetic example for discussion, not a full production database. It should include one line for five units, two shipping plans, and pre-agreed payment. Ask the team to show which documents and links appear in both systems after the first shipment. Then add a message retry, a delayed exchange, and a reserve cancellation. These are scenarios for future verification, not a statement about testing a specific store.

Review the results for individual facts: how many were ordered, how many were actually shipped, how many remain, which payments have been received, and which operations are still pending confirmation. An exchange error must be visible separately from the normal expectation of a second shipment. The manager must be able to determine whether a delivery is delayed or a message was lost.

The buyer does not need to see the entire complexity. They only need a precise answer: three cups have been shipped, two are expected within the agreed timeframe, and tracking is available for each shipped batch. If internal documents allow generating such an answer without manual investigation, splitting the order into parts truly supports store operations.