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>,
  etc)

• 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)

            <Item>

                <ID>10</ID> 

         <ID>10</ID> 

• 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.

For example,
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.

Tim.