OrderToOrderWH_tafr

 

Order messages are published by a merchandizing system, such as RMS to Order a known quantity of goods. A merchandizing system produces an order message and it needs to be transformed and routed to various warehouses depending on the warehouse locations as specified by the order.

 

The Order to OrderWH TAFR takes Order messages and converts these messages to OrderWH messages. Order messages are subscribed by retail warehouse management system (RWMS). Besides transforming the message payload formats, the TAFR must also perform routing and filtering operations to insure the message is forwarded to the correct instance of the warehouse with warehouse specific information.

 

Functional requirements

 

1. It is an error for message not to contain one of the following message types: “podtlcre”, “podtlmod”, “pocre”, “pohdrmod”, “podtldel”, “podel”.

 

2. If the message is not of one of the types as mentioned in 1, it will result in an error message mentioning that the message type does not exist

 

3 Message routing is dependent upon the physical location as specified by payload detail’s location type. If the physical location type is not “w”, an output detail will not be published

 

4. Message routing is dependent upon the routing info detail value of the rib message’s routing info. If the detail value is not “w”, an output will not be published.

 

5. It is an error for the message to contain facility id not specified in the configuration file

 

6. If the message envelope does not contain any RoutingInfo, facility type, it will result in an error

 

7. The <messageData> string will contain a namespace xml schema declaration detailing the URL of a XML schema definition (XSD) file. The directory specification in this URL will reside in the configuration file, thus allowing the customer to configure his/her own value. The name of the XSD file specified will be either “PODesc.xsd” or “PORef.xsd” depending on if the payload class is PODesc or PORef. Note: the value of this element is defined as an application would read it. When reading it off of a JMS topic, or after the payload has been marshaled, one must substitute the appropriate string for these special characters. (that is, ‘<‘ is replaced by ‘&lt;’.)

 

8. Each message is divided into individual messages depending on the physical location specified by the PODtl of the Payload. All the other properties of the input RibMessage are copied into the output RibMessage. Routing info’s value is set as the id for the output message. A PO may contain multiple warehouse locations in the routing info and order line details. This will result in multiple output orders, each to a different topic.

 

9. Order payload details should only contain physical location referenced within the routing info records. Any detail location not in routing info records will not be copied to an output message.

 

10. All output orders must contain at least one detail.

 

11. Payload details physical location is set as the id for output message

 

 

 

Disclaimer: This document is a general data mapping and reference guide for data coming in and out of Oracle Retail application systems via RIB messages; it is not meant to give detailed information about every possible data scenario.