Allocation messages are published by a merchandizing system, such as RMS to allocate a known quantity of goods on behalf of a specific store. These messages are closely related to Transfers, but have different business semantics. However, store and warehouse inventory business processes treat both Transfers and Allocations in the same manner. Hence, the store and warehouse systems accept Stock Order messages while the merchandizing system produces both Allocation and Transfer messages. Other business processing systems may accept separate Transfers or Allocation messages.
The Allocation to Stock Order TAFR takes Allocation messages converts these messages to Stock Order messages. Stock Order messages are subscribed to by both store and warehouse management system. 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 or store with warehouse or store specific information.
The routing information for a message is assumed to contain the “from location specification” and the “to location specification”. The message will be considered to be in error if the “from location” is not from a warehouse and the “to location” is not to a store or a warehouse.
Outbound messages will have the same values as the input messages for the RIB message envelope tags of : <ribmessageID>, <customFlag>, <customData>, <id>. If one of these input fields are not present, then the output message will also not contain this tag. Nested tags within these fields will also be copied. An input message may contain a null or missing <publishTime>, while the output message may contain a set publishTime. All output message <publishTime> fields must be set to a date/time equal to or after the input publishTime.
The <messageData> or “payload” 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, thus allowing the customer to configure his/her own value. The name of the XSD file specified will be either “SODesc.xsd” or “SORef.xsd” depending on if the payload class is SODesc or SORef.
Input messages having a <type> value of “alloccre”, “allocdtlcre”, “allochdrmod”, or “allocdtlmod” will have output message <type> value of “socre”, “sodtlcre”, “sohdrmod”, “sodtlmod”, respectively. The output payload class type for this set of messages will be the com.oracle.retail.integration.base.bo.sodesc.v1.SODesc class. The input payload class will be the com.oracle.retail.integration.base.bo.allocdesc.v1.AllocDesc class. The table below details the conversion between the AllocDesc fields and the SODesc fields. Any AllocDesc field not contained in the table will be ignored.
|
AllocDesc field |
SODesc field |
Comment |
|
alloc_no |
distro_nbr |
|
|
doc_type |
document_type |
|
|
physical_wh |
dc_dest_id |
|
|
pick_not_before_date |
pick_not_before_date |
Year,month,day,hour,minute,second copied |
|
pick_not_after_date |
pick_not_after_date |
Year,month,day,hour,minute,second copied |
|
order_type |
order_type |
|
|
order_no |
po_nbr |
|
|
event |
event_code |
|
|
event_description |
event_description |
|
|
priority |
priority |
|
AllocDtl records will be copied to SODtlDesc records according to the table below. Any AllocDtl field not included in the table below will be ignored. On input, Alloc Detail records are included in an array of <AllocDtl> elements. On output, SODtlDesc records are held in an array of <SODtlDesc> elements.
|
AllocDtl field |
SODtl field |
Comment |
|
to_loc |
dest_id |
|
|
|
item_id |
|
|
qty_allocated |
requested_unit_qty |
|
|
price |
retail_price |
“price” is an optional field that RMS always publishes. “retail_price” is mandatory as per the XSD. The implementation will assume the presence of “price”. |
|
selling_uom |
selling_uom |
|
|
priority |
priority |
|
|
store_ord_mult |
store_ord_mult |
|
|
in_store_date |
in_store_date |
|
|
rush_flag |
rush_flag |
|
Note: The item_id field of the SODtlDesc object will come from the AllocDesc item field.
AllocDtlTckt (allocation detail ticket) records will be copied to SODtlTckt records according to the table below. Any AllocDtlTckt field not included in the table below will be ignored. On input, Alloc Detail ticket records are included in an array of <AllocDtlTckt> elements found in an <AllocDtl> tag. On output, SODtlTcktDesc records are held in an array of <SODtlTcktDesc> elements found within a <SODtl> tag.
|
AllocDtlTckt field |
SODtlTcktDesc field |
Comment |
|
comp_item |
component_item_id |
|
|
comp_price |
retail_price |
|
|
comp_selling_uom |
selling_uom |
|
AllocToSO.9: Input messages having a <type> value of “allocdel” or “allocdtldel” will have an output message <type> value of “sohdrdel” or “sodtldel”, respectively. The output payload class type for this set of messages will be the com.oracle.retail.integration.base.bo.soref.v1.SORef class. The input payload class will be the com.oracle.retail.integration.base.bo.allocref.v1.AllocRef class. The table below details the conversion between the AllocRef fields and the SORef fields. Any AllocRef field not contained in the table will be ignored.
|
AllocRef field |
SORef field |
Comment |
|
alloc_no |
distro_nbr |
|
|
doc_type |
document_type |
|
|
physical_wh |
dc_dest_id |
|
AllocDtlRef records will be copied to SODtlRef records according to the table below. Any AllocDtlRef field not included in the table below will be ignored. On input, AllocDtlRef records are included in an array of <AllocDtlRef> elements. On output, SODtlRef records are held in an array of <SODtlRef> elements.
|
AllocDtlRef field |
SODtlRef field |
Comment |
|
to_loc |
dest_id |
|
|
|
item_id |
|
Note: The item_id field of the SODtlRef object will come from the AllocRef item field.