EDI onboarding is driven by humans, which includes back and forth feedback loops that aren’t in real time. This results in wasted time and delays. When you engage a new trading partner, there are many steps your team must go through before you can successfully start trading with your new partner. If you are performing EDI onboarding with a new partner, below are the steps you can expect.
Requirements Gathering: Every partner has a set of guidelines which define the EDI transactions they expect to transact with you. These guidelines define the content, structure, and the way in which you must send the data to them. Each partner you work with will have unique requirements. For example, one partner might send you an 850 purchase order that contains an SDQ segment identifying which locations to ship the order to. While another partner might send one 850 purchase order for each shipment location. The guideline requirements define how you will integrate with each partner, which is guaranteed to be unique.
Inbound EDI Integration and Mapping: Next you need to figure out how you are going to receive inbound transactions and get them into your system of record. Understanding both your system requirements, the data needed by your ERP or system of record, and the content in the inbound transaction, which is outlined in the guidelines, will be key to building your integration. Now you will need to decide what data you need to create the transaction in your own system. For example, if you receive an 850 purchase order, it may include data you don’t need in your system of record like a vendor number. However, it may be important to store the data so that it can be used in your outbound transactions.Most EDI developers will convert the transaction into a data format they can understand. This can come in the format of XML, JSON, a CSV file, or even database records. EDI data is sent as a flat file that is asterisk delimited and most systems can’t process this data natively. This job of converting the data from an EDI format into something your system of record or ERP can understand can be complicated. Most modern ERPs have APIs while legacy ERPs have staging tables to process data. Either way, this will require a developer to parse the EDI file and reconstruct it into a format your ERP can understand.
Outbound EDI Integration and Mapping: Similar to inbound transactions, you need to take data from your system of record and generate the EDI transaction in the format that matches the guidelines. The most common way of doing this is to use EDI field mapping software. However, the challenge with creating outbound transactions is you need to follow the specific guidelines of the trading partner. Most EDI tools do not validate your data against those guidelines. If validation is available, it simply compares the generated EDI file to generic EDI specification, which does not take into consideration the uniqueness of your trading partners guidelines.Because most EDI software providers don’t provide validation against your trading partners actual guidelines, and it is difficult to uncover errors in your transaction with your eyes, you will need to do a lot of testing.
EDI Scenario Testing and Validating: Once you have completed the integration for each document you must now test and validate the work. This is the most time intensive part of EDI onboarding. Each individual document must be validated in the order that your partner defines, which means you must send a sample or test transaction to your partner based on the inbound data they sent to you. For example, if you are testing in a retail scenario, your partner will send you an 850 purchase order and you must respond with the proper outbound data. This may include an 810 invoice, an 856 advance shipment notice, and an 855 acknowledgement that all have related data from the inbound 850 purchase order.Your partner will validate the transaction either electronically or manually. If the transaction is invalid, you will have to re-engage your developers to make changes, then try again. This process of back and forth can take weeks to ensure each document is valid prior to sending live transactions. For many partners, this process is handled over email. Trading partners like Walmart or Amazon have portals providing self-service scenario testing. However, most retailers, or what we at Orderful call “Leaders” as they define the requirements, do not have a self-service experience. This manual back and forth validation and testing can take months to accomplish.
Setting Up the Communication Channels: Each partner will require you send and receive data in a unique way. Some will choose to use a VAN, AS2, or SFTP. Even though you might use the same technology to trade with multiple partners, each connection is unique and requires configuration. Communication infrastructure is typically hosted on its own server because it’s critical to the lifecycle of these transactions and you have to account for scale.
Handling EDI Acknowledgements: EDI acknowledgements are known as 997s. Since EDI was founded before the concept of the internet, these are a critical way to confirm the receipt of a transaction. Think of these 997s as a handshake between you and your trading partner’s system. Your trading partner will send you a 997 once they have processed the transaction in their system of record and you will be required to send 997s when you process the transaction in your system. These 997s are typically built into the communication channels of systems, meaning it automatically gets sent, downplaying the importance of validating that the transaction was created in your system. Best practice would be to generate these acknowledgements after you’ve created a valid transaction into your system of record.
Live Trading and Troubleshooting: Now that you’ve completed the steps above, you are ready to begin transacting with your partner. Live transactions are sensitive. If they process cleanly and create records in your system, you will see these transactions in your backend. If you send accepted transactions, you will receive valid 997s from your partners. Monitoring this is important and often overlooked. While you’re trading production data, it’s important to have the right notifications in place when something doesn’t work. For example, if a partner sends you a part number that your system doesn’t recognize, you will want to understand what it is they were trying to order. If you don’t, you could be losing out on valuable revenue. The same goes for outbound data like invoices. If your invoices fail to deliver to your partners due to data errors or communication channel errors, you will want to know there is something wrong so you can resend or notify your partner that the invoices are coming and delayed. If these invoices go unnoticed, it’s likely that your partner will never pay for the product and you will have to reconcile these challenges at a later time.
You must follow these steps for each partner and transaction type. This process of EDI onboarding quickly becomes a full time job. It’s the lifeblood of your business and defines the execution between you and your supply chain. The work involved takes unique skills to parse EDI transactions, understand your system of record, manage communication channel infrastructure and create production notification services that quickly become complex. Many enterprises end up with hundreds of point-to-point mappings and custom code to detect these kinds of errors. These complex integration environments become an EDI headache. However, your business depends on EDI and you must get the job done.