多くの企業が、自己モールに加えて、（などリンクス、Jingdongは、など）他のチャネルは、集中パフォーマンスの複数のチャンネルを注文する方法がありますか？順序は次のように全体のプロセスを履行しましたか？そして、小さなQの物語は、あなたがマルチプラットフォームのシステム設計のアイデアが履行システムを注文すると発表しました。宇宙関係のために、記事が前方コンプライアンスプロセスを説明し、その後の記事の更新を配置するためのプロセスを逆に〜
「ここでの話であり、任意の類似性は純粋な偶然であれば、文字は、フィクションの著者です：
小Q：インターネット製薬会社の背景、プロダクトマネージャーは、同社のサプライチェーンとバックエンドの電力供給に関連するシステムの再構築を計画し始めました」。
三十九寒い、夜北の風が、友人の輪が雪のデビューを記念して2019年に全国の友人を持って、来年に前方の良い顔をしているロイヤルパーク孤独、冷たい風荒れ狂う大暴れプラスヘイズを超える除く外を期待し、空気がでいっぱいインフルエンザの傲慢は、低温より昨日よりも、視認性がたくさん低くなります。ハムは首から髪に、北の圧力面を総なめにした、すべての四肢の部分が氷ナイフ本体として公開され、凍結された刺すような、剣の戦いのバックのようなHachu白ガス口、空気中凝固、ゆっくりと奴隷に減少ヘイズを放散続く、焦げた臭いのダストヘイズで満たさ鼻腔は、一つだけが彼の歯sizzlesの間に砂を感じることができるかむ。10分間、単純にマッチしないような小さなQ悪天候でSouthernerとして、まだ浸透着実に内部に冷気外側を感じるが、コットンキャップ用とボディアヒル、ダウンジャケットを身に着けている間。
01注文履行システムアーキテクチャおよびコア機能
この時間は、タスクは、その技術的なGG注文履行システム要件を説明するために北京に旅行にあります。
「いわゆる受注処理、トランザクションが最終ユーザーに順番から生成された後、プロセス全体の売却を含め、商品を受け取る。したがって、私たちの受注システムの目標は、そのユーザー体験を確保するために、効率的かつ透明順履行プロセス全体を完了することであるの主な成果。 "
「公式の説明の需要に先立ち、私たちは会社のビジネスの状況を初めて目、」小さなQもプログラマーでなく、に非常に必要では最初の開始点として需要にどのようなビジネスの背景を理解することは、より多くのフィッティングサービスを設計しますシステム、およびそれが参加のより多くの意味になります。
私たちは、事業の二つのカテゴリー持っ①」：三者ビジネスプラットフォームと独自のプラットフォームを、当社の三者のプラットフォームはリンクス、Jingdongは、その他電気・プロバイダー店舗プラットフォーム上で開いている、プラットフォームが私たち自身の自己建てのショッピングモールで、外部の数SDK、APIおよび他のチャンネル。
②川下我々はすべての異なる分布域にわたり、全国の複数の倉庫を持っています。
③プラットフォーム上で自己だけでなく、私たちの新しい小売業、ユーザーが言及から買い物が出来るだけでなく、迅速な配信流通事業。"
第1の小Q書かPRD開かれ、「これらの現状の組み合わせは、私たちが受注システムアーキテクチャ設計を説明しましょう」。
▲受注システムアーキテクチャ設計
「データ、垂直転送チャネル注文、下向き3層系から導か注文履行全体から：中心線の変換、注文履行センター、倉庫ルーティングセンター。
変換順序の注文履行システムの上流ではないので、Aの、内部オーダーフローの標準化を確実にするためにコンプライアンス体制で受注の管理を統一するために、異なるプラットフォームのための構造ので、プラットフォームをドッキングすべての販売の中心地であります調整メイン構造のプラットフォームを移動、順序変換センター内の各プラットフォームのコンフィギュレーションの異なるアダプタが、順序は、将来の標準化システムの性能と通信します。アダプターに必要な情報は、商品、住所、注文状況、物流会社が含まれています。
下流パフォーマンスストレージシステムは、それぞれの新しい小売店、倉庫システムと対話するためのルーティング中心である財務省の目標出荷情報を収集し、注文履行センターに返送されている間、オーダールーティングは、生産のためのターゲット・ウェアハウスに配布されます。
受注システムが受注の、変換中心と販売プラットフォームを介して注文に関する同期情報にプロセス全体を処理する、倉庫の中心を通って次のルートは、中央スケジューリング、分配システムと他の周辺システムを介して注文情報、内部在庫をダウン通過します注文情報層アセンブリと解体、条件実行可能な命令を満足する性能を処理する注文。
上記構成によれば、引き出すためのフルフィルメント・システムのコア機能は次の通りであります：
▲受注システムのコア機能」
02オーダー履行プロセス全体は、詳細な
「システムの観点から、エンドユーザに販売プラットフォームの下に単一のクラスから受注の種類は、販売プラットフォーム、順変換センター、コンプライアンスシステム、中央在庫、流通システム、記憶ルーティングを含む、10個の以上のノードの性能を経験しますコアは履行プロセスが調整されている要求し、滑らかなので、複数のシステムセンター、倉庫/小売新しいシステムに、システムだけは一緒に仕事、開始から終了までの実行の順序は非常に滑らかされ、合意された年齢内の完全な遵守を確保するために、各ノードを終了しています任意のノードは、プラットフォームで顧客の信頼に影響を与える、コンプライアンスストレッチにつながる高齢化、スタック表示されます。」
物理的な順序は、全体のプロセスを履行しました▲
“ 1.新订单：订单系统接到新单的状态。此处根据业务分为两块逻辑处理：三方平台（如天猫、京东）的订单，客户在销售平台上完成了交易，由订单系统接到销售平台同步的订单后的状态；自营平台的订单，客户提交订单后，订单系统便生成一张新订单，不过此订单需判断若为在线支付订单，需付款以后才能继续往下流转。
2.订单拆分：为了更好的购物体验，大部分电商平台支持合并提交支付，在订单生成以后，需按照商家、仓库、商品、金额、物流等规则进行订单拆分，分为多个子订单发货。
3.订单预分仓：为防止超卖，已经下单的订单需尽快进行库存预占，以免库存被其它订单占用。分仓过程由中央库存提供服务。订单预分仓可以提前锁定订单发货仓库，若订单核心信息发生变化，再重新分仓。若业务上允许一个订单被拆分为多个库房发货，订单需再次拆分。需要注意的是，只有实物库存满足的订单才能预分仓成功，预售类的订单，可在订单拆分后进行截停等待，待真实库存采购入库以后再进行分仓流转。
4.订单拦截处理：某些不符合业务规则的订单，如疑似恶意订单，在订单系统中打上拦截标记，待人工审核通过后才能继续放行。若明确为恶意订单，则将订单取消。
（订单拦截规则因为行业、公司、业务不同，要根据实际业务情况进行梳理，不在这里详述。
另外，到底是先分仓预占，还是先拦截订单？木笔认为应该先进行分仓，虽然恶意订单可能会占用部分库存，但处理完以后，订单会被取消释放库存，此种处理方式好过一些疑似但不是恶意的订单因为被拦截了而没有分仓，导致后续库存被其它订单占用而引起超卖的情况。）
5.合并订单处理：为降低运费成本和库房作业成本，在一定时段内，满足合并条件的订单，在订单系统中合并为一单下发库房/门店发货。
6.订单审核：某些业务规则下，会要求订单在人工审核处理后方能继续流转，例如被拦截的订单、客户有特殊需求的订单等。为提升履约效率，其它订单可自动审核而无需人工一一处理。当然此审核功能可以直接放在履约系统中供客服使用，也可以提供服务供客服系统调用。
7.订单重新分仓：若在人工审核处理环节，客服修改了订单收货地址、商品及数量等分仓相关信息，从而影响了预分仓的结果，需要重新进行分仓预占，并清除原预分仓结果。
8.订单分物流：由于全国各仓的物流是单独签约，根据仓库所处的位置不同，签约的物流可能不尽相同，所以在明确了发货库房以后，履约系统调用物流配送系统提供的物流服务进行物流商的匹配，以及调用物流公司接口获取电子面单相关信息。
9.下发库房：物流公司分配完成以后，订单履约需要的信息已组装完全，订单履约系统根据订单距离和物流信息试算履约时效（履约时效主要用于服务承诺，为库房波次提供参考），并将订单下传仓储路由中心，经此系统路由至目标库房或门店生产发货。
10.波次下发：仓库/门店系统接到订单后，根据配送方向、时效承诺、订单类型等因素将订单生成波次，并按照出库策略对波次进行定位，生成库房拣货任务。在此过程中，若仓库零散货位库存不足而整件货位库存充裕，会产生波次补货。
11.生成批拣单：系统或库房操作员将定位成功后可以一起拣货的订单（如相同物流公司、相同拣货区域等）打包生成一张批拣单，在非自动化作业模式下，一张批拣单中含多少订单合适？一般按照拣货员推着拣货容器一次性能放下的拣货箱上限即可。例如一个拣货小车上能放下12个拣货箱，则可以设定1张批拣单含12张订单。
12.订单打印：打单员按照批拣单将每张订单的面单、纸质发票、发货清单打印出来并按订单顺序整理存放。
13.拣货：拣货员按批拣单领取拣货任务（纸单或PDA），并按拣货路径完成拣货任务（若拣货区域过大，可将批拣单再拆分为多个拣货任务，按区域完成拣货）。若是边拣边分模式，拣货员一边拣货一边将批拣的商品分拣到每个拣货箱,拣货完成也分拣完成；若是先拣后分模式，待拣货员拣货完成后再集中进行集货分拣。
14.复核打包：复核员按照订单的下单明细对商品进行复核确认，无误后交由打包员打包并粘贴物流运单。
15.订单发货：发货员将包裹交由快递员揽收，并在系统中操作发货，代表订单从库房发出。发货以后，若实际发货物流有变化，回传实际的物流公司及物流单号至履约系统，履约系统再通过订单转换中心将物流信息回传销售平台。
若是新零售下的自提业务，则由门店店员打包以后，等待客户上门自提。
16.物流揽件：物流公司快递员收到包裹后，在系统中操作揽件，揽件操作信息可由配送系统调用物流公司提供的接口获取，解析完后回传订单系统。
17.物流运输：包裹从物流公司的分拣中心分拨发出。
18.物流派件：包裹到达配送站点，派件员按照路线进行派件上门。
19.物流签收：包裹送达客户手中，完成签收。
以上便是一个实物订单的履约全流向，虚拟订单因为不涉及到库房发货和物流配送等环节，需走另外的系统流程。”
03 订单属性
“一张订单在订单履约全流向中，需要调度各个系统获取履约的各种信息，所以订单信息应该越全面越好，这里展示一些订单的核心属性：
1.基本信息：订单编号、来源编号、销售平台与销售店铺、下单时间、订单状态、支付方式（在线支付/货到付款）、买家留言、配送方式（物流配送/自提）、下单账号、订单类型（实物订单/虚拟订单）；
2.财务信息：付款方式（微信、支付宝、银行卡、现金…）、支付平台、支付账户（微信账号、支付宝账号）、商户订单号、支付流水号、订单应付总金额、已支付金额、货到付款金额、商品总金额、运费、客服增加/减免金额；
3.收货信息：收货人、收货人手机\电话、收货人省份、收货人市、收货人区\县、收货人乡镇、收货人详细地址；
4.发票信息：开发票的订单，应包含发票抬头和发票明细信息：
-
发票抬头信息：发票类型（纸质/电子）、发票号、抬头、发票税号、公司地址、电话号码、开户行、银行账号、发票金额、开票人
-
发票明细信息：明细类目明细、包装规格、包装单位、数量、含税单价、含税金额、税率；
5.促销信息：促销类型（优惠券、积分、满减等）、促销ID、金额；
6.物流信息：发货库房、系统指派物流公司、系统指派电子面单号、实际发货物流公司、实际发货物流单号、物流公司月结账号、大头笔信息；
7.商品明细信息：sku编码、sku名称、商品规格、销售单价、实付单价（各种优惠折扣计算完以后的单价）、数量、实付金额（实付单价*数量）；
8.订单全程跟踪信息：记录订单履约的每一步的操作人、操作时间及操作内容 ”
04 订单履约系统状态
“订单履约系统应该是所有订单的集散地，统一管理订单履约的全流程，按照订单的履约过程，我们梳理了履约系统的全部状态，以及对应到用户侧的显示状态，如图所示：”
▲ 订单履约状态说明
05 订单取消
“在电商系统中，取消场景主要有3类：
①、顾客发起的取消：客户在用户端发起的取消；
②、客服代为取消：客服代替顾客取消订单，此操作一般在后台客服系统或者在订单履约系统中直接操作；
③、系统取消：若客户下单后超时未支付，或系统判定为恶意订单，会自动取消订单。
由于订单取消会由多个环节触发，在系统设计的时候应该考虑到通用性，将订单取消做成一个公共服务，可供多个系统和场景按需调用。这也是符合SOA设计理念。”
▲ 订单取消服务
“根据订单在取消时可能存在于订单系统工作流、仓库作业、配送等多个环节，取消订单时需根据订单所处不同的状态执行不同的系统处理逻辑：
1.订单处于预分仓之前的状态：直接取消，更新订单状态为“已取消”，并判断是否需要退款触发退款流程；
2.订单已分仓，但尚未下发库房：取消订单，并通知中央库存清除订单预占；
3.订单已下发库房，但尚未发货：由履约系统对仓储系统发起询问，若仓储系统未发货且拦截订单成功，履约系统再取消订单，并通知中央库存清除订单预占；
4.订单已发货但尚未签收：若是自营配送，或者配送系统已与物流公司接口打通，则发货以后仍可以取消订单，履约系统询问配送系统，若配送系统拦截包裹成功，则履约系统更新订单状态为“已取消”，此阶段无需处理库存；
5.订单已签收：已经签收的订单，不支持取消，若想将货退回，只能走售后退货流程。”
06 订单拆分
“订单拆分是将一张订单拆分为多张子单独立发货的过程。订单履约过程中非常核心的一个环节，和订单取消一样，订单拆分会出现在订单履约的多个环节中，可以是系统自动拆单，也可以是人工拆单。所以订单拆分也应该设计为一个公共服务。常见的拆分业务如下：
▲ 订单拆分服务
拆分以后，父单作废，子单继续完成履约过程。但在前台和履约系统中需要有很明晰的父单和子单的对应关系。拆分过程中，对订单的处理逻辑如下：
1.基本信息（下单人、收货人、渠道等公共信息）：将父单信息复制到子单 。
2.财务信息： 订单应付总金额/已支付金额/发票金额/物流运费=按照各子订单的商品总价比例进行分摊，最后一个订单金额为剩余未分配金额。建议保留2位小数。
3.商品信息：按照需要拆分的sku或者数量进行拆分，保证所有子单的sku及数量之和与父单一致。
4.促销信息：针对整单的促销（例如整单优惠、满减、平台优惠券、积分抵扣等），拆分时按照订单中sku金额比例分摊；若是针对单sku的促销，拆分时仅考虑参与促销的单sku维度，其它sku 不参与促销分摊。”
07 订单合并
“将相同客户的多张订单合并一起发货，有诸多好处，于客户而言，多张订单一起送货，只需要签收一次包裹；于公司而言，可以节省库房的作业成本和配送的物流成本。所以订单履约系统中增加订单合并功能是很有必要的。
履约系统设计时可以设置订单集中等待10到15min，在此等待时间内进入履约系统的订单，若符合合并条件，可自动进行合并；超过等待时期进入系统的订单，可由客服手工合并。
▲ 订单ABC合并为D
订单合并条件：同销售平台、同下单会员账号、同收货地址、同收货人、同手机号、同支付方式（在线支付/货到付款/到店支付）、同出库仓库、同订单类型（如普通订单、预售订单）、同客户备注（客户备注一样or无备注）、同开发票方式（都开发票，且抬头信息一样；或者都不开发票）、同配送方式（自提/配送）
合并以后，各原单作废，合并后生成一张新单继续完成后续履约过程，但要求在销售平台上客户仍看到的是多张订单，仅发货时的物流公司和物流单号都是一样的。合并订单的处理逻辑如下：
1.基本信息（下单人、收货人、渠道等信息）：取任意一张子单（因为信息都一样）
2.财务及发票信息：订单应付总金额/已支付金额/发票金额/物流运费=各子单金额相加
3.商品信息：所有需要合并的子单SKU及数量进行汇总
4.促销信息：将所有子单促销明细集中至父单中 ”
08 订单反审核
“在订单履约过程中，已经审核过的订单，常常会被要求修改信息（例如客户要求修改地址、库房要求拆包裹发货等），客服需要将订单拉回至审核之前的状态，然后修改之后重新审核下发，此动作即为反审核。
反审核的系统处理逻辑为：
①将原订单做取消处理；
②根据要求修改后生成一张新订单重新下发完成履约流程。
新订单是否需要生成新的单号？ 取决于下游的仓库/门店系统是否兼容多个相同的订单号。若兼容，则无需更改单号，若不支持，则生成一个新订单号。订单在未下发仓库系统之前，原则上无需重新生成单号，系统记录一条反审日志即可。”
09 订单暂停与加急
“在某些业务场景下，需要临时将正在履约过程中的订单暂停处理，一般由客服发起，若订单在库房发货之前，可暂停成功，将订单拦截在仓库里，等待客服下一步操作（取消暂停/取消订单/反审核等），暂停的系统流程如图所示：
▲ 订单暂停逻辑
与暂停功能类似，某些订单需要临时提升出库优先级，加急出库，故订单履约系统需提供加急功能供客服使用，一旦订单被加急，库房在出库作业环节中均优先处理。优先级越高，出库越靠前。加急的系统流程如下：
▲ 订单加急逻辑
以上暂停和加急功能主要供客服内部使用，无需对客户开放。”
此次来北京出差，小Q从酒店出发步行到办公室，区区10分钟路程，好像走了半个世纪，看着形形色色的上班一族在寒潮和雾霾中穿梭，每个人都包裹的严严实实，棉衣棉帽棉口罩是标配，只留一副凝重的眼神与寒风对峙，像怀揣着救世使命一般神秘。不远处一位很时尚的女孩儿因为赶路太匆忙被路旁的共享单车绊倒，刚买的热包子和红豆粥洒落一地，白色的羽绒服被污染了一大片，女孩趴在地上30秒后，红着双眼慢慢爬起来，掏出包里的纸巾将自己脸上和身上收拾干净，又礼貌的将掉在地上的包子拾起来丢进了旁边的垃圾桶，然后满脸泪痕又故作坚强的前行。小Q望着女孩不停抬手擦拭眼泪的背影，陷入了沉思….
众生皆苦，万般无奈。所有的美妙光鲜背后，都有着不为人知的难言苦楚。不过因果交加，如果不是一次次的艰难困苦，人生又当如何进阶？眼前的坎，掉下去了叫入坑，自己爬起来抹平了，就变成了自己的路。要相信所有让我们变好的选择，过程都不会很舒服。
尼采说：凡不能毁灭我的，必使我强大！
=>更多文章请参考：《中国互联网业务研发体系架构指南》
https://blog.csdn.net/Ture010Love/article/details/104381157
=>更多行业权威架构案例、领域标准及技术趋势请关注微信公众号 '软件真理与光'：
