INTERFACE ID |
IB22 - ASN Inbound |
|||||
SOURCE |
RWMS, External |
|||||
DESTINATIONS |
RMS, SIM, RWMS |
|||||
INTEGRATION STYLE |
Asynchronous – Unidirectional |
|||||
DESCRIPTION |
RWMS publishes ASN messages that RMS and Store systems use to create or modify a shipment record. Any ASN that originates from RWMS is called an “outbound” ASN, also commonly known as a Bill Of Lading (BOL). An ASN that is coming into RWMS from EDI or another instance of RWMS is an “inbound” ASN. Inbound ASNs can originate from external systems or from another instance of RWMS. For example, if an outbound shipment occurs because of a transfer to another warehouse, the outbound ASN is transformed into an inbound ASN and routed to the receiving warehouse. Any outbound ASNs that originate because of a customer order are sent to RMS. Shipments occurring because of a transfer or an allocation are sent only to RMS. The ASN Out to ASN In TAFR operation transforms ASNs that are directed to another warehouse, such as transfers or allocations between two warehouses. It also routes the message to the proper warehouse based on the facility type and the “To” location found in the message data. A filter ensures that RMS receives only those ASNOut messages that pertain to Transfers or Allocations. Logic similar to that in RWMS exists for SIM. When SIM creates a transfer to a warehouse, it publishes an ASNOut message. This message is converted through the TAFR into in inbound ASN for the warehouse. |
|||||
DATA |
|
|||||
DEPLOYMENT |
RIB |
|||||
INTEGRATION SERVICE LEVELS |
Guaranteed, once-only delivery to destination |
Yes |
||||
Scheduled data exchange |
No |
|||||
Audit-trail kept for data exchange (state historical duration of audit trail) |
Auditing at message level. |
|||||
Alerting required should data exchange fail? |
Yes |
|||||
Retry of data exchange necessary? (state number of times before error is logged or failure condition is met) |
Yes. RIB Hospital. |
|||||
Data purge on data transmittal? |
Yes |
|||||
Security on data exchange required? |
No |
|||||
PERFORMANCE SERVICE LEVELS |
If this is a server application, what is the design-time number of concurrent clients that will be serviced? |
|
||||
Priority of integration (High, Medium, Low)? |
|
|||||
Fail-over required? |
|
|||||
Expected response time or batch processing window |
N/A |
|||||
Frequency of messaging or batch data exchange |
|
TAFRs