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 Transfer to Stock Order 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.
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”.
Warehouse routing configuration entries: Outbound messages to the warehouse system is dependent on the setting for the “WarehouseSystemActive”, “WarehouseSystemRouteToToLoc”, and “WarehouseSystemRouteToFromLoc” configuration properties.
Transfer messages denoting a transfer out of a warehouse will be routed to the appropriate warehouse topic only if the “WarehouseSystemActive” and the “WarehouseSystemRouteToFromLoc” configuration properties have both been set to true.
Transfer messages denoting a transfer into a warehouse will be routed to the appropriate warehouse topic only if the “WarehouseSystemActive” and the “WarehouseSystemRouteToToLoc” configuration properties have both been set to true.
The TAFR will not process any messages successfully if the “WarehouseSystemActive” property is set to “true” and both the “WarehouseSystemRouteToToLoc” and “WarehouseSystemRouteToFromLoc” are set to “false”
Store inventory system routing configuration entries: Outbound messages to the store inventory system is dependent on the configuration setting for the “StoreSystemActive”, “StoreSystemRouteToToLoc”, and “StoreSystemRouteToFromLoc” properties.
Transfer messages denoting a transfer out of a warehouse will be routed to the store inventory system topic only if the “StoreSystemActive” and the “StoreSystemRouteToFromLoc” have both been set to true.
Transfer messages denoting a transfer into a store will be routed to the store inventory system topic only if the “StoreSystemActive” and the “StoreSystemRouteToToLoc” have both been set to true.
The TAFR will not process any messages successfully if the “StoreSystemActive” property is set to “true” and both the “StoreSystemRouteToToLoc” and “StoreSystemRouteToFromLoc” are set to “false”
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>, <hospitalRef>, <hospitalID>, <failure>, <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 DOCTYPE Declaration: The <messageData> or “payload” string will contain a <DOCTYPE> tag detailing the URL of a document type definition 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 DTD file specified will be either “SODesc.dtd” or “SORef.dtd” depending on if the payload class is an SODesc or an 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 |
|
|
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 or DTD. 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.retek.payload.SORef class. The input payload class will be the com.retek.payload.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.