Transfer messages are published by a merchandizing system, such as RMS to transfer a known quantity of goods on behalf of a specific store. These messages are closely related to Allocations, but have different business semantics. However, store and warehouse inventory business processes treat both Allocations and Transfers 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 also accept separate Allocation or Transfer messages.
Transfer messages may denote a transfer of goods from a warehouse to a store, a warehouse to another warehouse, a store to a warehouse or a store to another store.
The Transfers_tafr takes Transfer messages and converts them to Stock Order messages. Stock Order messages are subscribed to by both store and warehouse inventory management applications. 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.
Input message routing info
records: The routing information for
an input Transfer message is assumed to contain the “from physical location
specification” and the “to physical location specification”. All value
processing is performed in a case insensitive manner. “To physical loc” and
“from physical loc” Location ids should be numeric integer strings, but this
TAFR has no requirements for validation of this.
The input message should contain a “facility_type” routing info record. If it does not contain such a record, the configured default facility type identifier is used during processing.
The payload denotes a transfer to or from a warehouse by creating in the Rib Message envelope a “to_phys_loc” or “from_phys_loc” routing info record with a detail named “phys_loc_type” with a value of “w”. The location id is specified in this record's “value” tag. The topic messages are published to is dependent on the facility type value and a configuration entry named facilty_id.{facility type}.{location}, where {facility type} is the facility type identifier (see TAFR.6.1.2) and the {location} is the value of the <value> tag for the “to_phys_loc” or the “from_phys_loc” routing info record.
The payload denotes a transfer to or from a store by creating in the Rib Message envelope a “to_phys_loc” or “from_phys_loc” routing info record with a detail named “phys_loc_type” with a value of “s”. The location id is specified in this record's “value” tag.
The payload denotes a transfer to or from an external finisher location by creating in the Rib Message envelope a “to_phys_loc” or “from_phys_loc” routing info record with a detail named “phys_loc_type” with a value of “e”. The location id is specified in this record's “value” tag.
An error will occur if the “from_phys_loc” specification or the “to_phys_loc” specification has a “phys_loc_type” value other than “w” or “s” or “e”.
The payload denotes location finisher indicator by creating in the Rib Message envelope a “to_phys_loc” or “from_phys_loc” routing info record with a detail named “loc_finisher_ind” with a value of “y” or “n”.
If the routing info contains transfer to or from external finisher location then the message is dropped. Or if the routing info contains transfer from a warehouse and from location finisher indicator is “y” then the message is dropped. Or if the routing info contains transfer to a warehouse and to location finisher indicator is “y” then the message is dropped.
RIB Message Envelope processing: 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.
Message Type processing: The table below denotes valid input message type fields found in the Rib Message envelope. Any other message type will result in a processing error. The message type processing is case insensitive.
Input message type |
Input payload class |
output message type |
output payload class |
transfercre |
TsfDesc |
socre |
SODesc |
transferdtlcre |
TsfDesc |
sodtlcre |
SODesc |
transferhdrmod |
TsfDesc |
sohdrmod |
SODesc |
transferdtlmod |
TsfDesc |
sodtlmod |
SODesc |
transferdel |
TransferRef |
sohdrdel |
SORef |
transferdtldel |
TransferRef |
sodtldel |
SORef |
Output message XML schema declaration: 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 class, respectively.
The table below details the conversion between the TsfDesc fields and the SODesc fields. Any TsfDesc field not contained in the table will be ignored.
TsfDesc field |
SODesc field |
Required by |
Comment |
tsf_no |
distro_nbr |
Both |
|
doc_type |
document_type |
Both |
|
physical_from_loc |
dc_dest_id |
Both |
|
pick_not_before_date |
pick_not_before_date |
Both |
Year, month, day ,hour, minute, second copied |
pick_not_after_date |
pick_not_after_date |
Both |
Year ,month, day, hour, minute, second copied |
not_after_date |
not_after_date |
Neither |
|
exp_dc_date |
exp_dc_date |
Neither |
|
context_type |
context_type |
Neither |
|
context_value |
context_value |
Neither |
|
default_order_type |
order_type |
Both |
|
priority |
priority |
Both |
|
TsdDesc records may contain zero or more TsfDtl (Transfer detail) records. TsfDtl records will be copied to SODtlDesc records according to the table below. Any TsfDtl field not included in the table below will be ignored. On input, Transfer Detail records are included in an array of <TsfDtl> elements. On output, SODtlDesc records are held in an array of <SODtlDesc> elements.
TsfDtl field |
SODtl field |
Required by |
Comment |
|
dest_id |
Both |
See Note below.
|
item |
item_id |
Both |
|
tsf_qty |
requested_unit_qty |
Both |
|
price |
retail_price |
SODtl Only |
“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 |
Neither |
|
priority |
priority |
Neither |
|
ticket_type_id |
ticket_type |
Neither |
|
store_ord_mult |
store_ord_mult |
Neither |
|
expedite_flag |
expedite_flag |
Neither |
|
Note: the <dest_id> field of the SODtl record will use the same value as the <physical_to_loc> found in the TSFDesc record of the payload. This means that every SODtl will have the same value for all of the <dest_id> fields. Furthermore, <physical_to_loc> is defined to be a string, but <dest_id> is a long. The system will assume <physical_to_loc> is an integer string and an error will occur if it isn't.
TsfDtl records may contain zero or more TsfDtlTckt (transfer detail
ticket) records. TsfDtlTckt records will be copied to SODtlTckt records
according to the table below. The same parent/child relationship between
TsfDesc/TsfDtl/TsfDtlTckt records will be maintained within the
SODesc/SODtlDesc/SODtlTcktDesc hierarchy. |
SODtlTcktDesc field |
Required by |
Comment |
|
distro_nbr |
SODtlTcktDesc and TsfDesc |
See Note 1 below |
|
document_type |
SODtlTcktDesc and TsfDesc |
The <distro_nbr> and <document_type> fields of the output SODtlTcktDesc will be set with the same value as found in the <tsf_no> and <doc_type> fields in the TsfDesc record. This means that all SODtlTcktDesc records will have the same values for <distro_nbr> and <document_type>.
|
|
item_id |
TsfDesc only |
The <item_id> field
of the output SODtlTcktDesc will be set with the same value of the <item>
field found in the input TsfDtlTckt's parent TsfDtl record. This means that
all SODtlTcktDesc records for a given SODtlDesc will have the same
<item_id> value. |
comp_item |
component_item_id |
SODtlTcktDesc and TsfDtlTckt |
|
|
retail_price |
SODtlTcktDesc Only |
The <price> field of the output SODtlTcktDesc will be set with the same value as the <price> field found in the input TsfDtlTckt's parent TsfDtl record. This means that all SODtlTcktDesc records for a given SODtlDesc will have the same <retail_price> value. |
|
selling_uom |
SODtlTcktDesc Only |
The <selling_uom> field of the output SODtlTcktDesc will be set with the same value as the <selling_uom> field found in the input TsfDtlTckt's parent TsfDtl record. This means that all SODtlTcktDesc records for a given SODtlDesc will have the same <selling_uom> value. |
Input messages having a <type> value of “transferdel” or “transferdtldel” will have an output message <type> value of “sodel” 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.tsfref.v1.TsfRef class. The table below details the conversion between the TsfRef fields and the SORef fields. Any TsfRef field not contained in the table will be ignored.
TsfRef field |
SORef field |
Required by |
Comment |
tsf_no |
distro_nbr |
Both |
|
doc_type |
document_type |
Both |
|
physical_from__loc |
dc_dest_id |
Both |
|
TsfDtlRef records will be copied to SODtlRef records according to the table below. Any TsfDtlRef field not included in the table below will be ignored. On input, TsfDtlRef records are included in an array of <TsfDtlRef> elements. On output, SODtlRef records are held in an array of <SODtlRef> elements. The SODtlRef array is optional.
TsfDtlRef field |
SODtlRef field |
Required by |
Comment |
|
dest_id |
SODtlRef field and TsfRef |
See Note below. |
item |
item_id |
Both |
|
Note: The dest_id field of the SODtlRef object will come from the TsfRef <physical_to_loc> field. Hence, the same <dest_id> value will be present in all details.