Third Party Logistics in BYD – Top 10 Best Practices
I have written 10 best practices for implementing 3PL for your BYD project. I have grouped as “Programming” or “Testing” where these bset practices are to be used. (BTW, I meant to number the bullets but the blog bulletting is a bit unwieldy.)
- Programming – Correctly mapping to the XML WSDL.
The documentation for each message type needs to be read thoroughly by the development team. Attention must be paid to the TypeCode within
the message, since a message can be used for multiple purposes. Eg for an IDEC (inbound delivery confirmation) message, the codes are allowed:
1563 Customer Return
1564 Intracompany Confirmed Inbound Delivery
1566 Supplier Confirmed Inbound Delivery
to denote what the IDEC is for. Similarly each field has a range of valid codes, and the developer should not use any invalid values (such as 1567, etc).
- Programming – The sequence of the XML blocks. The 3PL is pretty rigid as tothe sequence of the XML blocks (eg <ID> followed by <TypeCode>,
- Programming – Getting the right formats needed in XML fields – datetime fields (ISO standard), message ID numbers.
- Programming – The developer team should use soapUI tool. The development team must use this independent tool to validate and test their own XML. Full ownership of this task is important, and not rely on SAP support. This item is very important.
- Programming – Sequencing the multiple line items properly in the XML. Errors occur when the same item number is used twice:
(Item block should have ID – 10, 20, etc)
- Message ID numbering must be unique. Generally the confirmation messages (IDEC, ODEC) allow for the 3PL partner to do the numbering. The numbering pattern is unique to warehouse.
SGN-201209040002 – is a message from the Singapore warehouse. The use of the date with a sequence (0002) guarantees uniqueness for up to 9999 messages in 1 day.
If a ODEC ID is re-used, there will be an error. Attention must be paid to use the right format and unique sequencing.
- Testing – Start using simple examples for each message (ODER, ODEC, etc). 1 order with 1 line item
- Testing – Designing the full spectrum of test cases. For each pair of XML messages (ODER, ODEC), full testing of each type code must be tested – this co-relates to the functional testing of the 3PL system.
For example, an ODER should be tested for normal shipping , return to manufacturer and other functional codes. In addition, the dimension of 1 item and multiple line items must be tested also.
Also, testing must be done for the negative case. In other words, testing should be done for invalid sales orders, invalid 3PL ODERs, invalid quantities to confirm the system handling.
- Testing – With multiple 3PL warehouses, there can be a rush-to-judgement that if it works for 1 warehouse, it must work for all. However, the same range of test cases should be repeated for every 3PL warehouse.
- Testing – Using the Business Communication Monitoring (BCM). The development team should have access to BCM tool in BYD, and rely on this as one of their core tools for development and testing.
For any nonworking message, the team should get the payload XML and diagnose the issue using multiple methods, including soapUI (see item 4)
- As a bonus best practice, the requirements of 3PL must be clear up front. If kitting or serial number functionality is needed in 3PL, my recommendation is that functionality can be added AFTER the basic 3PL is fully validated and working.
I hope this tips help your 3PL implementation. I welcome your feedback and of course, your likes.
thanks for your interesting article regarding 3PL. Do you know if there are different communication techniques which can be used for this scenario - or is it restricted to WS XML?
This is Good but only mentions the Inbound interfaces. The outbound messaging is not mentioned above and is a Key part of any 3pl integration to BYD. Having implemented several 3pl, WMS and EDI integrations that all make use the 3pl interface. The outbound Messaging is just as important if not more... Most of the inbound information is based off of the outbound requests you are confirming with the exception of inventory notifications (Which is also not covered above)
Some missing things are the Sender party info and Receiving party info in the message header... also the Document Numbering Formats (PREFIX) that are required.
Tim thanks for this information.
You mention the importance of correctly mapping to the XML WSDL however I cant find any documentation about this in the current 1405 release - (the on-line help is empty). Do you know where I can find this?