Business scenarios cainiao

Jiahai Golden Beam Docking Guide

Updated: 2019/06/11 Visits: 528

1. Business scenarios

Solutions to the strong control system of Tmall fast-moving, cosmetics and clothing industries

2. Programme description

2.1 Merchant warehouse + rookie warehouse

2.1.1 Business Functional Process

2.1.2 Business Scenario Requirements Description

1. Merchant warehouses are shipped by ERP management.

2. Cainiao warehouse Tao channel (BMS shipping merchant) orders can only be shipped by BMS, and rookie warehouse non-tao orders are shipped by ERP.

3. Merchant ERP still obtains transaction orders from Jushi Tower, but there will be orders that are prohibited from shipping. The order will be modified after BMS priority binding and routing.

The status of ERP obtaining the order message from Jushi Tower is to parse the sub-order dimension of the new logistics delivery structure when waiting for the seller to deliver the goods.

6. The inventory of the merchant warehouse is updated by ERP through the new interface provided by OIC.

7. Xiao Er needs to set up the warehouse routing template at the Xiao Er workbench to set the shipping routing rules.

8. The routing rules of the order are only warehouse coverage and repository priority setting (secondary setting)

9. Merchant ERP in this mode will not be able to issue relevant instructions for the sales and delivery of Tao orders under the rookie warehouse through the Qimen interface (ordinary delivery, replacement delivery, replacement);

10. The warehousing orders, warehousing orders and inventory orders of rookie warehouse are all synchronized to ERP results by BMS, and ERP cannot create relevant documents (this period is not defined as P0-level requirements for the time being).

11. Tao is an order shipped by a rookie warehouse. All the control processes in both positive and reverse are completed in BMS, and ERP only perceives the final result.

12. A marketing campaign can only be undertaken by BMS or ERP, ERP-managed activities can only be shipped by merchant warehouses, and BMS-managed activities can be shipped by merchant warehouses and rookie warehouses.

13. Who manages the delivery and return to the warehouse: BMS manages the rookie warehouse, ERP manages the sales and return of merchant warehouse and non-tao channel transaction orders.

2.1.3 ERP transformation program description

The synchronization of goods information has been changed from manual to automatic (one code and multiple products are not supported for the time being, and synchronization fails. ERP will modify the barcode and merchant code as the unique value and try again)
Baby inventory synchronization has been changed to merchant warehouse inventory synchronization. For the interface, please refer to interface description 3.11.
ISV will process orders that need to be shipped from merchant warehouses according to JST data results:

1) Delivery label of rookie warehouse merchant warehouse;

2) Analysis of logistics delivery information: BMS binding identification, transaction baby delivery analysis

4. The Correspondence Between The Front-end Baby And The Back-end Goods Needs To Be Completed By BMS, And ERP Obtains Data Through The Existing STORE TOP Interface (the Merchant Code Of The Baby Is Filled In The Item Code In The Rookie Interface, And ISV Uses This Field To Obtain The Binding Relationship Between The Rookie's Item ID And The Baby ID. );

5. When the sub-order delivery goods of the transaction order need to be changed, customer service needs to enter BMS first to confirm whether the sub-order line confirms the delivery of the rookie warehouse or the merchant warehouse. The delivery suborder of the rookie warehouse is modified by BMS. The suborder shipped by the merchant warehouse enters ERP for modification, and the final result modified by BMS will be shipped. The interface pushes ERP perception of the final delivery results.

6. For the cancellation of transaction orders, ERP is responsible for the merchant warehouse, and BMS is responsible for the rookie warehouse (this point is a relatively challenging operation for customer service, which needs to be communicated and confirmed by the business party and the merchant) - business consent

7. Sales order shipping confirmation of BMS shipment (ordinary shipment, replacement, replacement) ERP receiving modification instructions:

1) In the shipment confirmation, ERP changes the delivery status of the transaction order according to the sub-transaction order number;

2) Some delivery and out-of-stock delivery scenarios are not included in this demand;

3) The actual deduction of inventory goods and quantities from transaction orders and logistics invoices shall be subject to the return of the rookie warehouse;

4) ERP can only rely on the shippers + transaction order number to verify whether the data is legal, and cannot be used to make reliable judgments of data through ERPID.

5) In the scenario of reissue, if ERP finds that the transaction order number of the shipment cannot be recognized, it can only be judged by the cargo owner ID. Once the cargo owner ID is verified, ERP will create a replacement order that cannot match the relationship for processing.

8. For the return of BMS shipping orders, ERP trusts the middle platform to complete the data through the interface of the return of the return of the warehouse receipt. The information returned by the middle office must include the transaction order number and sub-order number, as well as itemID, itemcode information.

2.1.4 Description of the internal renovation plan of the middle office

JST's order data requirements (the definition of transaction order structure will be modified on TOP before the Spring Festival)

In the main form of JST orders, the order status is marked with no shipping.
New rookie warehouse delivery and merchant warehouse delivery labels in the sub-order dimension
New logistics delivery structure, the data is defined as follows:

Field name	Type	Explanation
Transaction number		TB main transaction number
Sub-transaction number		TB sub-transaction number
Baby ID
SKUID
ItemID		Rookie Storage ID
Itemcode		ID in the ERP system of the goods merchant
Rookie warehouse shipping label		CN=Rookie delivery, SC merchant warehouse delivery
Amount due		Quantity due for orders
Shipping Warehouse		If it is a rookie warehouse, fill in the regional warehouse code of the rookie warehouse, and fill in "SC" if the merchant warehouse delivers.
Type		Mark whether the sub-transaction is available on the transaction or increased by BMS, enumeration value (00 = transaction, 10 = BMS binding)

BMS binding and canceling interface

Trigger condition of the interface: All the parts of the rookie warehouse of the transaction order have been shipped except for the gift, and the gift will not be shipped in the future;
Interface data description:

Field name	Type	Explanation
Main transaction number	string
Sub-transaction number	string
Status		Enumeration value: 00=Cancel
This interface can only return the cancellation information of goods added by the BMS of one main transaction number at a time.
Trigger condition: All uncancelled rookie warehouse delivery details under the main transaction number have been completed.

Merchant warehouse inventory synchronization interface

New interface, see 3.11

Sales and delivery confirmation interface transformation
ERP senses the shipping status and shipping type of the subtransaction order.

Solution for the full delivery of rookie warehouses for transaction orders - to be confirmed

Non-API field requirements

During ERP data interaction, the ERPID field is composed of ISV set ID + BMSID.
The logistics order query interface for sales and delivery increases the conditions for order delivery information query through the main transaction number and the sub-transaction number.
The query interface of the return-in warehouse receipt increases the conditions for the query of the return-in warehouse receipt information through the main transaction number and the sub-transaction number.

3. Interface description

3.1 Ordinary B2C Stone Tower Order Acquisition Interface

3.1.1 Interface Description:

Merchants obtain the interface of transaction order details of ordinary B2C Taobao platform

3.1.2 Interface Name

taobao.trade.fullinfo.get (get details of a single transaction)

3.1.3 Interface link:

//open.taobao.com/docs/api.htm? spm=a219a.7629065.0.0. F1kNvJ&apiId=54

3.1.4 Interface Description

1. A new structure called logics_infos has been added to the interface, which contains the results after BMS auditing and warehouses.

2. Add the erpHold label to the trade_attr field of the interface: -1 = abnormal, 0 = non-strong control, 1 = strong control, 2 = completion of the order; if the highly controlled merchant of the erpHold tag = -1, it indicates that there is a missing label in the order, please ask ISV not to process the order, this After the order BMS is processed, the erpHold label will be directly changed to 2.

3.2 Rookie goods creation interface

3.2.1 Interface Description

Merchants call the information of rookies that can be created by this interface through ERP.

Interface name:

Name of the Qimen API called by ERP: taobao.qimen.singleitem.synchronize

API name of Qimen calling WMS: singleitem.synchronize

3.2.2 Interface link: taobao.qimen.singleitem.synchronize

Online address: http://pac.i56.taobao.com/apiinfo/showDetail.htm? spm=0.0.0.0.94smkF&apiId=taobao.qimen.singleitem.synchronize&type=cainiao_warehouse_qimen

3.1.3 Considerations

Not yet.

3.3 Rookie goods inquiry interface

3.3.1 Interface Description

Merchants call this interface through ERP to query the merchant's goods in Cainiao.

Interface name:

Name of the Qimen API called by ERP: taobao.qimen.singleitem.query

The API name of Qimen calls WMS: singleitem.query

3.3.2 Interface link: taobao.qimen.singleitem.query

Online address: http://pac.i56.taobao.com/apiinfo/showDetail.htm? spm=0.0.0.0.94smkF&apiId=taobao.qimen.singleitem.query&type=cainiao_warehouse_qimen

3.3.3 Considerations

Not yet.

3.4 Combined goods creation interface

3.4.1 Interface Description

Merchants call this interface through ERP to create a relationship between rookie combination goods.

Interface name:

The name of the Qimen API called by ERP: taobao.qimen.combineitem.synchronize

API name of Qimen calling WMS: combineitem.synchronize

3.4.2 Interface link: taobao.qimen.combineitem.synchronize

Online address: http://pac.i56.taobao.com/apiinfo/showDetail.htm? spm=0.0.0.0.94smkF&apiId=taobao.qimen.combineitem.synchronize&type=cainiao_warehouse_qimen

3.4.3 Considerations

Not yet.

3.5 Combined goods inquiry interface

3.5.1 Interface Description

Merchants call this interface through ERP to query the information of the combined goods in Cainiao.

Interface name:

The name of the Qimen API called by ERP: taobao.qimen. combineitem.query

API name of Qimen calling WMS: combineitem.query

3.5.2 Interface link: taobao.qimen. combineitem.query

Online address: http://pac.i56.taobao.com/apiinfo/showDetail.htm? spm=0.0.0.0.94smkF&apiId=taobao.qimen.combineitem.query&type=cainiao_warehouse_qimen

3.5.3 Considerations

Not yet.

3.6 Combined Item Deletion Interface

3.6.1 Interface Description

The merchant calls this interface through ERP to delete the information of the combined goods in the rookie.

Interface name:

The name of the Qimen API called by ERP: taobao.qimen.combineitem.delete

API name of Qimen calling WMS: combineitem.delete

3.6.2 Interface link: taobao.qimen.combineitem.delete

Online address: http://pac.i56.taobao.com/apiinfo/showDetail.htm? spm=0.0.0.0.94smkF&apiId=taobao.qimen.combineitem.delete&type=cainiao_warehouse_qimen

3.6.3 Considerations

Not yet.

3.7 Invoice confirmation interface

3.7.1 Interface Description

After the delivery of the rookie warehouse outgoing form, send back the outgoing order and package information to ERP, and ERP will decide how to deal with it.

Interface Name: Pending

3.7.2 Reference interface link: deliveryorder.confirm

Online address: http://pac.i56.taobao.com/apiinfo/showDetail.htm? spm=0.0.0.0.94smkF&apiId=deliveryorder.confirm&type=cainiao_warehouse_qimen

3.7.3 Considerations

1. Because auto-shipped orders are directly notified of the transaction, the deliveryOrderCode field can no longer be used as a condition for ERP judgment. ERP can only verify data according to the orderSourceCode field.

2. The transaction update logic after accepting the shipment confirmation will not change according to the existing ISV logic.

3. A personalized field BmsOrderType will be added to the interface, promotional giveaway = 01
Transaction giveaway = 02, manual input gift = 03; transaction authenticity = 04; manual entry of authenticity = 05

4. Due to the phenomenon of closing orders in logistics orders, if the ERP system does not support the scenario of reissuance orders or replacement orders and transaction orders, it needs to be explained to customer service sophomore that BMS supports the reissue and replacement logistics orders and normal transaction logistics orders.

5. The order delivery confirmation interface of large and small electricity and Meijia merchants is also transmitted back through this interface.

3.8 BMS Shipping Order Return Order Confirmation Interface

3.8.1 Interface Description

Merchants receive data on the arrival of BMS shipping orders through this interface.

Interface name:

3.8.2 Interface name: taobao.qimen.auto.returnorder.confirm

Use scenario supply chain middle platform to dock with ERP

Qimen personalized scene, which can be obtained after authorization.

3.8.3 Considerations

1. The interface returns the return-to-warehousing information of all orders shipped by BMS, and the return-to-warehousing information shipped by ERP still uses the Qimen standard return-in warehousing list for data acquisition.

3.9 Warehouse receipt confirmation return

3.9.1 Interface Description

Rookie sends back ERP rookie warehouse warehousing list information through this interface.

3.9.2 Reference interface link:

Online address: http://pac.i56.taobao.com/apiinfo/showDetail.htm? spm=0.0.0.0.8dD3Am&apiId= entryorder.confirm&type=cainiao_warehouse_qimen

3.9.3 Considerations

1. This interface carries ordinary warehouse receipts and warehouse receipts for one plate of goods. The document type of warehouse receipt for one pallet of goods is CJBHRK.

2. The ERP processing business logic of a plate of goods needs to be confirmed by merchants and ERP. A set of goods is mainly used to solve the problem of how to sell goods between the merchant's Tmall flagship store owner and the cat overstock owner.

3.10 Warehouse receipt confirmation and return

3.10.1 Interface Description

Cainiao sends back ERP rookie warehouse warehouse outgoing information through this interface

3.10.2 Reference interface link:

Online address: http://pac.i56.taobao.com/apiinfo/showDetail.htm? spm=0.0.0.0.8dD3Am&apiId= stockout.confirm&type=cainiao_warehouse_qimen

3.10.3 Caution

1. This interface carries ordinary warehouse receipts and warehouse receipts for one shipment. The document type of warehouse receipt for one shipment is CJBHCK.

3.11 Merchant Warehouse Storage and Return

3.11.1 Interface Description

ERP sends back the merchant's total inventory through this interface.

Interface name:
cainiao.merchant.inventory.adjust

3.11.2 Interface definition:

After the interface TOP is authorized, ISV can view documents in the background. The main fields are described as follows:

Field name	Type	Explanation
The owner		TB main transaction number
Merchant warehouse code		TB sub-transaction number
ItemID		Rookie Storage ID
Itemcode		ID in the ERP system of the goods merchant
Goods inventory		Quantity due for orders
Type of inventory		ZP = genuine, CC = residual.

3.11.3 Considerations

1. This interface only supports full inventory updates, not incremental inventory updates.

2. When the interface is called, the interface needs to be called by the session of the shipowner's store.

3.12 Distribution B2C Poly Stone Tower Order Acquisition Interface

3.12.1 Interface Description:

Merchants obtain the interface for distributing B2C Taobao platform transaction order details

3.12.2 Interface name:

taobao.trade.fullinfo.get (Check purchase order information)

3.12.3 Interface link:

//open.taobao.com/docs/api.htm? spm=a219a.73,86797.0.0. PcRVBy&source=search&apiId=180

3.12.4 Interface Description

A new structure called logics_infos has been added to the interface, which contains the results after BMS auditing and warehouses. The model of this structure can refer to the 3.1 ordinary B2C polystone tower order for interface information.

3.13 Outgoing list to create a pushback interface

3.13.1 Interface Description:

After the merchant's warehouse receipt is created, ERP will be pushed back, and ERP will be preoccupied by inventory.

3.13.2 Interface name:

Qimen personalized interface (use scenario supply chain middle platform to dock with ERP):

qimen.taobao.icp.order.stockoutordermessagetoerp

3.13.3 Interface link:

Qimen internal link, which can be viewed after authorization.

3.13.4 Interface Description

1. This interface carries ordinary warehouse receipts and warehouse receipts for one shipment. The document type of warehouse receipt for one shipment is CJBHCK.

3.14 Create a cancellation notification interface for outgoing orders

3.14.1 Interface Description:

After the merchant's warehouse receipt is created, ERP will be pushed back, and ERP will be preoccupied by inventory.

3.14.2 Interface name:

Qimen personalized interface (use scenario supply chain middle platform to dock with ERP):

taobao.qimen.auto.entryorder.giftitemcancel

3.14.3 Interface link:

Qimen internal link, which can be viewed after authorization.

3.14.4 Interface Description

3.15 Haijinliang orders cancel the delivery confirmation interface

3.15.1 Interface Description:

Jiahai Jinliang merchant order cancellation merchant warehouse delivery confirmation interface

3.15.2 Interface name:

Qimen official scene interface: qimen.taobao.bms.erptrade.intercept

3.15.3 Interface link:

https://open.taobao.com/api.htm? docId=38418&docType=2

3.15.4 Interface Description

1. This interface is used for BMS to notify ERP to cancel merchant warehouse delivery orders;

2. Interface usage scenarios: front-end transaction initiation refund application, rookie warehouse and merchant warehouse exchange, gift binding exception handling, inventory routing exception

2. Type At Present, There Is Only One Situation Of Warehouse Interception. The Details Of The Orders Delivered By Merchant Warehouse Are Warehouse Intercepted By Default Interception Before The Front-end Delivery Of The Return Transaction. After Returning, Interception Specified ERP Will Be Initiated (for The Status Problems Caused By Network Delay, ERP Subject To The Status In Its Own System, Such As E In the RP system, the merchant warehouse has been out of the warehouse, and the interface failed to return.)

3. When there is only the main transaction number in the cancellation notice, ERP must cancel all the shipments of all merchant warehouses corresponding to the main transaction number to return to success, otherwise it must return failure (must be all success or all failures, and part of the failure part of the failure is equal to all failures).

When there is information about the main transaction number and sub-transaction number in the cancellation notice, ERP must cancel all shipments of all merchant warehouses corresponding to the sub-transaction number to return to success, otherwise return failure (must be all success or all failures, and partial failures are equal to all failures).

3.16 Rookie warehouse merchant warehouse interchange interface

3.16.1 Interface Description:

Jiahai Jinliang merchant order cancellation merchant warehouse delivery confirmation interface

3.16.2 Interface name:

Qimen official scene interface: qimen.taobao.bms.erptrade.transferconsign

3.16.3 Interface link:

https://open.taobao.com/api.htm? docId=38426&docType=2

3.16.4 Interface Description

1. This interface is used for the conversion between the delivery of rookie warehouses and merchant warehouses of shelves.

The repository in the store_code field is the result repository where the order needs to be modified.

3. When notifying ERP to modify the information, ERP must successfully modify all the shipping warehouse corresponding to all the sub-transaction numbers in the notification, otherwise it will return failure (must be all or all failures, and partial failures and partial success is equal to all failures).

3.17 Cainiao Warehouse Delivery Transaction Order Information Return Interface

3.17.1 Interface Description:

Jiahai Jinliang merchant's order rookie warehouse delivery information returned

3.17.2 Interface name:

Qimen official scene interface: qimen.taobao.bms.trade.consign

3.17.3 Interface link:

https://open.taobao.com/api.htm? docId=38427&docType=2

3.17.4 Interface Description

1. This interface is used to notify ERP customs after all the rookie warehouses of the orders of Haijinliang are shipped.

2. The order is to return ERP in the dimension of the transaction number, the full status of the order delivered by the rookie warehouse, and the information is returned. The transaction order is closed, and finance and other related processing can be carried out.

3. There may be an out-of-order between the interface and the shipping confirmation interface, which requires ERP to store the data of the interface first and then process it.

3.18 Rookie warehouse transfer information return interface

3.18.1 Interface Description:

The rookie system initiates the transfer between the rookie warehouses, and sends back the ISV or merchant ERP system three times according to the dial order number through Qimen. After the ERP system receives the instructions, the inventory of the ERP system will be updated. ( The transfer orders have been created once successfully, all out of the warehouse will be returned once, all incoming orders will be returned once, and all incoming representatives have completed the transfer orders have been completed.)

3.18.2 Interface name:

Qimen official scene interface: transferorder.report

3.18.3 Interface link:

http://pac.i56.taobao.com/apiinfo/showDetail.htm? spm=0.0.0.0. M9KUfZ&apiId=transferorder.report&type=cainiao_warehouse_qimen

3.18.4 Interface Description

1. The number of outgoing and incoming warehouses sent back by rookies may not be consistent, and they need to be received normally by the ERP system.

2. The number of warehousing orders returned by rookies is genuine and residues, which need to be received normally by the ERP system, and can be normally distinguished in the ERP system to calculate the corresponding inventory separately.

3. The number of differences generated by the transfer needs to be displayed in the ERP system. This part of the difference data is checked offline by Cainiao Xiao Er and the merchant. The ERP system should have the function of exporting these differences.

4. When the rookie returns, there will only be a dialer number, and the dialer number will not be returned;

5. There will be three return calls for the rookie's callback confirmation. One is to create the dialer, one is to confirm the return from the warehouse, and the other is to confirm the return to the warehouse.

Outgoing confirmation return before incoming confirmation return.

3.19 Rookie Job Information Inquiry Interface (Non-required Interface)

3.19.1 Interface Description:

Rookie invoice status information inquiry

3.19.2 Interface name:

Qimen official scene interface: taobao.qimen.orderprocess.query

3.19.3 Interface link:

http://pac.i56.taobao.com/apiinfo/showDetail.htm? spm=0.0.0.0.bjLNth&apiId=taobao.qimen.orderprocess.query

3.19.4 Interface Description

1. After ERP receives the relevant job documents of rookie, it can query the relevant document job status and key node information with this interface.

4. Supply Chain Scenario Docking Guide

4.1 Active transfer between rookie warehouses

Supported by the 3.18 interface, as long as ERP docks with the 3.18 interface, Cainiao can actively transfer business to merchants.

4.2 One shipment

Supported by the interfaces of 3.9 and 3.10, as long as ERP is docked with 3.9 and 3.10 interfaces, ERP can correctly receive the flow of warehouse entry and exit documents of a shipment.

How to use document flow requires ERP and merchants to confirm the product process.

4.3 Middle-end replenishment plan

Supported by interfaces of 3.9 and 3.10, as long as ERP is docked with 3.9 and 3.10 interfaces, ERP can correctly receive the warehouse receipts of the middle-sized supply chain system.

The flowing water of the relevant documents can be treated according to the flowing water of the normal warehouse entry and exit list.

ERP docking - sub-package shipping process

Updated: 2019/05/21 Visits: 5507

ERP docking mode---parcel delivery process

Version0.1

Date: December 22, 2017

Serial number	Version number	Revision	Author	Date
1	V0.1	New	Perseverance	December 22nd

1. Business scenarios

In order to provide Tmall buyers with a better experience of order fulfillment, ERP is required to receive partial delivery of the order and send back the corresponding logistics information to the Tmall trading platform.

2. Process description

3. Description of the existing interface

3.1 Shipping Order Creation Interface

3.2.1 Interface Description

Merchants can create rookie invoices that can be created by merchants through ERP.

Interface name:

The name of the Qimen API called by ERP: taobao.qimen.deliveryorder.create

The API name of Qimen calls WMS: deliveryorder.create

3.2.2 Interface link: taobao.qimen.deliveryorder.create

Online address: http://pac.i56.taobao.com/apiinfo/showDetail.htm? spm=0.0.0.0. TpJlVc&apiId=taobao.qimen.deliveryorder.create

3.2.3 Considerations

3.2 Contact the logistics delivery interface by yourself

3.2.1 Interface Description

Merchant ERP calls this interface to return the details of order shipping logistics.

Interface name:

TOPAPI name called by ERP: taobao.logistics.offline.send

3.2.2 Interface link

Online address: //open.taobao.com/docs/api.htm? spm=a219a.73,86797.0.0. JNDT2u&source=search&apiId=10690

3.2.3 Considerations

1. The interface needs to be modified to be compatible with the return of some packages.

2. When ERP returns the shipping type, a new partial shipping status is added.

4. New interface data description

4.1 Partial Shipment Notification Interface

4.1.1 Interface Description

Merchants receive information from part of the order out of the warehouse through this interface.

4.1.2 Interface link (not available)

4.1.3 Interface Field Description

<deliveryOrderCode>Exit order number, string (50), required</deliveryOrderCode>

<deliveryOrderId>Warehouse system outgoing order number, string (50), required</deliveryOrderId>

<warehouseCode>Resitory code, string (50), required</warehouseCode>

<orderType>Exit order type, string (50), JYCK=general transaction warehousing, HHCK=replacement warehousing, BFCK=replenishment warehousing, QTCK=other warehousing orders, required</orderType>

<outBizCode>string (50), external business code, message ID, used for de-heaving, ISV assigns a unique encoding for the same request. It is used to ensure that the request will not be repeated due to network and other reasons. The condition is required. When an order needs to be confirmed many times </outBizCode>

<orderConfirmTime>Order completion time, string (19) , YYYY-MM-DD HH:MM:SS </orderConfirmTime>

<operatorCode>Current state operator code, string (50) </operatorCode>

<operatorName>Current state operator name, string (50) </operatorName>

<operateTime>Current state operation time, string (19) , YYYY-MM-DD HH:MM:SS</operateTime>

</deliveryOrder>

<logisticsCode>Logistics company code, string (50), SF=SF Express, EMS=standard express, EYB=Economic express, ZJS=home express delivery, YTO=yuantong, ZTO=Zhongtong (ZTO), HTK Y=BISHUITONG, UC=EXCELLENT SPEED, STO=ShenTONG,TTKDEX=DIANDIANDEX, QFKD=QIANFENG, FAST=EXCREQUEST, POSTAL PACKAGE, GTO=GUOTONG, YUNDA=YNDA, JD=JDD DELIVERY, DD=DANGDANG HOME DISPIELD, AMAZO N=Amazon Logistics, OTHER=Other, required, (English code only) </logisticsCode>

<logisticsName>Logistics company name, string (200) </logisticsName>

<expressCode>Context No., string (50), required</expressCode>

<packageCode>Package number, string (50) </packageCode>

<length>Package length (cm), double (18, 2) </length>

<width>Pack width (cm), double (18, 2) </width>

<height>Pack height (cm), double (18, 2) </height>

<theoreticalWeight>Package theoretical weight (kg), double (18, 3) </theoreticalWeight>

<weight>Package weight (kg), double (18, 3) </weight>

<volume>Package volume (liter, L), double (18, 3) </volume>

<invoiceNo>Invoice number, string (500) </invoiceNo>

<type>Package model, string (50) </type>

<quantity>The number of packaged materials, int</quantity>

</packageMaterial>

</packageMaterialList>

<items>

<item>

<itemCode>EAN Code, string (50) , Required</itemCode>

<itemId>Commodity storage system code, string (50)</itemId>

<quantity>The quantity of the goods in the package, int, required</quantity>

</item>

</items>

</package>

</packages>

<orderLineNo>Doceder line number, string(50)</orderLineNo>

<orderSourceCode>Platform transaction order code, string (50) </orderSourceCode>

<subSourceCode>Platform trading suborder code, string (50) </subSourceCode>

<ownerCode>Consignor code, string (50) </ownerCode>

<itemCode>EAN Code, string (50) </itemCode>

<itemId>Commodity storage system code, string (50)</itemId>

<ownerCode>Consignor code, string(50)</ownerCode>

<itemName>Product name, string (200) </itemName>

<extCode>Trading platform commodity code, string (50) </extCode>

<planQty>Number of goods due, int</planQty>

<actualQty>Number of actual products, int</actualQty>

<batchCode>Batch number, string(50),</batchCode>

<productDate>Date of production, string(10), YYYY-MM-DD</productDate>

<expireDate>Expiration date, string(10), YYYY-MM-DD </expireDate>

<produceCode>Produce batch number, string(50),</produceCode>

<batch>

<batchCode>Batch number, string(50)</batchCode>

<productDate>Date of production, string(10), YYYY-MM-DD</productDate>

<expireDate>Expiration date, string(10), YYYY-MM-DD </expireDate>

<produceCode>Produce batch number, string(50),</produceCode>

<inventoryType>Inventory type, string (50), ZP=genuine, CC=dissidual,JS=machine loss, XS=box loss, ZT=in-transit inventory, check all types of inventory by default</invento ryType>

<actualQty>The number of live sends, int, requires that the sum of all the actual number of live sends under the batch node is equal to the number of actual senders in orderline</actualQty>

</batch>

</batchs>

</orderLine>

</orderLines>

</request>