Coupangの分割配送：注文は2件になるのか？ いいえ

いいえ。運用上、Coupangの分割配送は、複数のフルフィルメントイベントを伴う1件の顧客注文であり、独立した2件の注文や売上ではありません。元の注文リファレンスを親として保持し、その配下で対象となる注文明細、荷物、配送イベント、クレーム、返金を正しく照合してください。

Coupangの2つの分割配送フラグが実際に意味すること

Coupangでは、似た名前のシグナルが2つ提供されていますが、それぞれ別の問いに答えます。ableSplitShipping は注文で分割配送が可能であることを示します。splitShipping は分割配送が実際に処理されたことを示します。前者は能力、後者は結果として作成されたフルフィルメント記録を確認すべきことを伝えるシグナルです。

正確なペイロードとステータスの挙動は、ご利用のアカウントが使用するエンドポイントとバージョンに対応するCoupang公式Open API開発者向けドキュメントで確認してください。フィールド名から、ドキュメントが裏付けていない意味まで推測しないでください。

分割配送が可能であることだけでは、複数の配送が存在する証拠になりません。注文が分割可能でも、1つの荷物で配送される場合があります。ableSplitShipping が存在するだけで、連携システムが2つ目の注文や子荷物を作成してはいけません。

splitShipping が処理済みを示したら、関連する商品と配送の記録を確認してください。荷物の詳細がまだ自社システムに届いていない場合は、社内で「照合待ち」という状態を使ってください。注文が完全に配送済み、完全に未着、または金銭面でも完了したと推測してはいけません。

1つの親注文と複数のフルフィルメント記録を構築する

最も安全なデータモデルは親子関係です。つまり、元のCoupang注文を1件置き、その配下に対象となる注文明細、荷物、配送イベント、クレームを紐付けます。荷物は注文の配下にあるフルフィルメント記録であり、注文そのものの代替ではありません。

少なくとも、次の記録を保持してください。

関係は、どちらの方向からでも簡単に追跡できるようにしてください。

1件の顧客注文 → 対象の注文明細 → 荷物（複数可） → 配送イベント → 明細単位のクレームまたは返金

ERPや倉庫システムが荷物ごとに出荷オブジェクトを必要とする場合は、それらの出荷オブジェクトを同じ親注文の子として作成してください。元の注文総額は親レベルで保持してください。取引全体の注文情報を各荷物レコードにコピーしないでください。売上、プロモーション、在庫移動、返金リスクが重複する可能性があるためです。

正規化したステータスだけでなく、元のイベントデータも保持してください。現在のステータスは商品が今どこにあるかを示しますが、イベント履歴があれば、購入者が注文の一部しか受け取っていない理由、配送例外の後にクレームが発生したか、どのシステムが記録を変更したかを説明できます。複数のツールが同じセラーアカウントを扱う場合は、コネクターの設計も重要です。Coupang Open API：2つのシステムで1つのSeller IDを共有できるか？では、複数のシステムがそれぞれ直接解釈すると競合が生じる理由を説明しています。

フルフィルメント：最初の荷物が届いただけで注文を完了にしない

社内のフルフィルメントステータスは、明細単位で把握できるようにしてください。親のステータスは、最初の配送イベントが届いた時点で子記録を上書きするのではなく、子明細と荷物から導出してください。

実務上は、次の順序が使いやすいです。

1. 元の注文と、分割配送に関する2つのシグナルを取得します。
2. 対象となるすべての注文明細を荷物に紐付けるか、確認が必要なものは未紐付けとして明示的に残します。
3. 荷物レベルと明細レベルで、出荷状態と配送状態を記録します。
4. すべての明細から親の状態を導出します。一部が保留中である間は「一部フルフィルメント済み」とし、Coupangがサポートするワークフローで全明細が配送済みになるか、それぞれ別の終端結果に達した場合に限って完了または解決済みとします。
5. イベントが矛盾する、進行が止まる、または紐付けに失敗した場合は、対象の明細または荷物に対して例外を起票します。

たとえば、購入者が商品Aと商品Bを購入したとします。商品Aが先に出荷・配送され、商品Bはまだ輸送中です。この購入者には、配送済みの明細が1つと、未解決の明細が1つある1件の注文があります。社内の運用システムでは、親注文を「一部フルフィルメント済み」またはオープンのままにしてください。配送完了として扱ってはいけません。また、注文全体の返金や返品処理を開始してもいけません。

同じ考え方で在庫も守れます。荷物レコードでは、その荷物に含まれる明細だけを移動させてください。2つ目の荷物から2つ目の注文を作成すると、倉庫が同じ取引注文を2回引き当てたり、在庫から2回差し引いたりする可能性があります。一方、すべての荷物を1つのステータスにまとめると、未配送の明細まで完了したように見えてしまいます。購入者に表示される注文ページが1つであっても、明細数量、荷物への割り当て、例外状態は分けて管理してください。

カスタマーサービスと返品：まず対象商品を特定する

購入者が体験するのはデータベース上の関係ではなく、商品の一部だけが届く状態です。そのため、韓国語でカスタマーサービスに返信する際は、「注文」が単に遅れている、または見つからないと伝えるのではなく、対象の商品と荷物を特定してください。

返信前に、次を確認してください。

• 元の注文リファレンス
• 購入者が未着だと伝えているSKU、バリエーション、数量
• その明細に割り当てられた荷物番号または追跡番号
• その荷物の最新の出荷イベントと配送イベント
• 同じ注文に含まれる他の明細の状態
• クレーム、返品、キャンセル、返金がすでに存在するかどうか

その後の韓国語の返信では、どの商品が配送済みで、どの商品が輸送中または未解決の例外状態にあるのか、そしてCoupangでサポートされている次の手順は何かを伝えてください。実際の分割処理と荷物レコードがその内容を裏付けている場合に限り、購入品が別々の荷物で届くと説明してください。ableSplitShipping だけでは、2つの配送が向かっていると購入者に伝える根拠になりません。

この区別は、一部配送についての問い合わせで重要です。配送中の商品は、追跡可能な配送進捗がない商品や、紛失が確認された商品と同じ運用ケースではありません。まずイベント記録を確認し、その後、適切なCoupangのクレームワークフローに従ってください。荷物が1つ遅れているだけで、注文全体のキャンセル、返品、返金を提案してはいけません。

返品記録も同じ階層構造を保持してください。返品またはクレームを対象の商品と荷物に紐付け、Coupangのリファレンスと状態を保持し、残りの明細はそれぞれのフルフィルメント経路で処理を続けてください。Rocket Growthでは、プラットフォームが購入者向けの返品対応、集荷、返金を処理する場合があります。ただし、返品された現物とその処理結果は、引き続き注文と在庫の記録に紐付ける必要があります。Coupang Rocket Growthでは返品を誰が担当するのか？で、この運用上の境界を説明しています。購入者への返金が現物返品の到着前に記録される場合もあるため、金銭イベントと倉庫での受領は別々の記録として扱ってください。Coupangの即時返金：返品到着前に購入者へ返金される理由も参照してください。

精算：最初の配送ではなく、注文記録とクレーム記録を照合する

精算は、分割配送を管理するためのコントロールポイントであり、荷物の個数を数えるためのものではありません。最初の配送イベントから推測するのではなく、Coupangの注文、クレーム、返金、精算の各記録に基づいて金銭的な結果を照合してください。

親注文ごとに、次の順番で記録を確認してください。

1. 元の注文リファレンスと、購入された明細を確認します。
2. 各明細を、出荷、配送、キャンセル、返品の結果に照合します。
3. 荷物レベルの例外とクレームリファレンスを、対象の明細に紐付けます。
4. 売上、控除、キャンセル、返金を、関連するCoupangの記録に紐付けます。
5. 精算結果が注文について1回だけ計上され、記録された明細単位の結果に対してのみ調整されていることを確認します。

荷物リファレンスが2つあるからといって、売上を2件計上してはいけません。逆に、最初に届いた荷物を、すべての明細が金銭面で解決済みである証拠とみなすのもよくある誤りです。Coupangが注文レベルで控除または返金を示す場合は、元の記録を保持し、プラットフォームがその関係を提供している範囲で、クレームまたは明細の詳細を使って社内で配賦してください。配賦を確定できない場合は、各荷物に同じ調整額を割り当てるのではなく、確認対象としてフラグを立ててください。

Coupangが売上を収益として認識するタイミングについては、Coupangが売上を収益として認識するタイミングで説明しています。分割配送の運用での実務ルールは、もっと単純です。倉庫の状態、購入者向けの配送状態、クレーム状態、精算状態は相互に紐付ける必要がありますが、互いに置き換えてはいけません。

ローンチ前テスト：注文と荷物の関係を証明する

実際の購入者から一部配送の問い合わせを受ける前に、これをテストしてください。運用環境で正当に分割配送として処理できる、検証用の複数商品注文を使い、実行前に期待する状態を文書化してください。

1. 異なるSKUまたは注文明細を含む複数商品注文を作成し、それぞれを別の荷物に割り当てられるようにします。
2. 元の注文リファレンス、対象明細、2つの分割配送フラグを取得します。ableSplitShipping だけでは2つ目の注文を作成せず、複数の荷物の存在も示唆しないことを確認します。
3. Coupangがサポートするワークフロー、またはアカウントで利用できるテスト機能を使って分割処理を実行し、それぞれの荷物番号と明細の紐付けを取得します。
4. 最初の荷物を配送済みとして記録または観測し、もう一方を輸送中のままにします。ERP、倉庫ビュー、Coupangアカウントで、親注文がオープンまたは一部フルフィルメント済みの状態に保たれることを確認します。
5. 韓国語のサポートプロセスで一部配送の問い合わせを処理します。返信が、購入品を関連のない2件の注文として扱うのではなく、未着商品、荷物、現在の状態、次の対応を特定していることを確認します。
6. 対象明細だけを対象にクレームまたは返品をテストします。クレーム、在庫の処理結果、返金がその明細と荷物に紐付いたままで、注文全体が自動的に取り消し処理されないことを確認します。
7. 結果として生じた売上、控除、返金をCoupangの注文、クレーム、精算記録と照合します。荷物の数が計上する売上件数を変えていないことを確認します。

このテストは、すべてのチームが同じ元の注文リファレンスから出発し、同じ対象明細、荷物、イベント、クレーム、金銭的な結果にたどり着ける場合にのみ合格です。各ステップで元の生レスポンスと期待する社内ステータスを保存してください。そうしないと、後の連携変更によって、一部配送の状態が気付かないうちに完了注文へ平坦化される可能性があります。

Coupangの分割配送に関するよくある質問

ableSplitShipping は、すでに2つの荷物が存在するという意味ですか？

いいえ。分割配送が可能であることを意味します。複数の配送が存在すると購入者に伝える前に、実際に分割処理済みであることを示すステータスと荷物レベルの記録を確認してください。

splitShipping は、2つ目のCoupang注文を作成すべきだという意味ですか？

いいえ。親注文は1件のままにし、対象明細と荷物を追跡するために必要な子フルフィルメント記録を作成または更新してください。

最初の荷物が届いた時点で、注文全体を配送済みにできますか？

いいえ。配送済みの明細だけを更新し、残りの明細は、それぞれがサポートされる結果に達するまで、オープン、輸送中、または例外状態のままにしてください。

遅れている荷物がある場合、注文全体の返金や返品を開始すべきですか？

自動的にそうしてはいけません。まず、その荷物がまだ輸送中なのか、本当に未着なのかを判断し、その後、対象の商品または配送についてCoupangがサポートするクレームワークフローに従ってください。

分割配送を財務でどのように照合すべきですか？

元の注文、明細ごとの結果、クレーム記録、精算記録を組み合わせて使用してください。購入は1回として計上し、可能な場合は調整を対象明細に割り当て、最初の配送イベントから金銭的な結果を推測しないでください。