For this discussion, a “Staging Database” refers to any intermediate database that would fill the gap between Electronic Data Interchange (EDI) transactions and the backend business application. Whether obtained through a third party or developed in-house, some applications provide interface files that are “EDI Intelligent” and support the required EDI transactions. For applications that do not, the Staging Database should be considered for the following reasons and with the following purposes:
Data Grouping/Restructuring: Spreadsheet-type (SDQ) orders, where a single purchase order describes multiple ship-to destinations, might not be supported in the application because many applications define an order as a single ship-to destination. In this case, the single spreadsheet order needs to be broken down into separate orders by ship-to destination prior to insertion into the application. A multi-line order could have the same ship-to destination repeated several times. Therefore, data grouping would be required for later reorganization of all lines (for each ship-to) and transforming into a single order within the application.
The Staging Database would provide sorting/grouping functionality to support such reorganization. For example, an order with two lines, each having three SDQ pairs (defines the “ship-to location” and “quantity” breakdowns), and where one location is repeated on both lines, might result in six orders instead of five without such grouping.