Remember when EDI used to be simple?  You did a few 850′s, sent out a couple of 810′s, maybe even an 856 with one of your more daring trading partners, and you were a hero.Â
Not much has stayed the way it was ten years ago, however, and EDI is no exception. The problem is everyone keeps raising the bar and pretty soon the old standbys are just not enough. But what are the new darlings of the EDI world? What are the bench mark documents that you simply have to be doing to be somebody, anybody? Â
Inbound Remittance Advice (820)
This is a payment notice. It comes from your customer in response to an 810 (invoice) from you and it indicates how much they are paying and what invoices (generally) it is being paid on. The 820 can come from either your customer or else from his bank. If it comes from the customer, then it is an indication of what they are going to pay, while if it comes from the bank it is generally an indication of what has been paid.
Obviously, this eliminates having to post checks manually using the AR0015 function. Batches are considered as an entity and all posting is done at the batch level vice transaction. That means if you have 10 transactions in the batch and there is an error in one of them (maybe a bad invoice number), then the nine good transactions will be held until the one bad one is fixed. This ensures the audit integrity of the batch. Editing is very important here as is the matching facility, being able to match an 820 transaction against an invoice and mark that invoice as having been paid.  Â
Nominally, PRMS provides support for the inbound 820 (starting with 9.1 and continuing in 9.2). The only problem is that it doesn’t work as well as it should, particularly in the matching arena. Fortunately,
Inbound Forecast (830)
More and more companies are using forecasts instead of customer orders to carry demand and so the ability to take these in must be supported. The end goal is to load these forecasts into the Forecast File, after having gone through the necessary edits, of course. Â
What makes this difficult is the fact that you are getting the same records over and over again. That is, if you get forecasts daily then you will get the forecast for April 22 for weeks until you finally go past that date. And so you need to know if you are going to delete your old forecast and replace it with the new one for that date, or if the forecast transactions represent changes to an initial forecast, either positive or negative. This is not a decision you can just make on your own, you need to check with your partner and see what he is planning to send, then react accordingly.
Unfortunately, PRMS does not have any native support for this document, but
Inbound Shipping Schedules (866)
The shipping schedule is similar to a forecast, but represents what the customer expects you to ship him today. In that sense it is the final version of the forecast. Generally this is not loaded into the forecast files (it is too late for
Within PRMS you would map these transactions into the Batch Order Entry system, although many customers will go through an intermediate phase of reviewing the final forecast and then, either line by line or en-mass automatically cutting the associated orders. And fortunately,
Outbound Forecast (830)
Turn about is fair play and so if you can receive 830′s you also want to be able to send 830′s. That is, we need to be able to send your forecast to your vendors.Â
This is also known as vendor scheduling and PRMS provides support for this via the Vendor Scheduling module. You simply map the
Summary
There are many EDI transactions that we have not mentioned here (like the 832, the inbound 810, etc.) but this is a good start. EDI is more than the 85x series today. The question is, are you ready to play, are you ready to bump it up a notch and take the next step in terms of making your EDI system a competitive advantage?   If so,