INTERFACE ID |
IB47 – Payment Terms |
|||||||||||
SOURCE |
External |
|||||||||||
DESTINATIONS |
RMS |
|||||||||||
INTEGRATION STYLE |
Asynchronous – Unidirectional |
|||||||||||
DESCRIPTION |
Payment Terms from external financial applications are published to RMS to identify various payment conditions associated to a supplier. Payment Terms are created in external financial applications as a separate entity and are associated to a supplier when a new supplier is created. Retailers often use a complex system of Payment Terms to choose the most favorable schedule for payments to a Supplier or Partner. This system is based on Payment Terms that allow for static and non-static payment dates, detailed discount windows and ranked choices. Terms Ranking is a cardinal representation of the relative financial merits of a set of Terms, based on an external calculation (often performed within financial applications). |
|||||||||||
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 |
|