Owens & Minor EDI - one acct. # - multiple companies

I can see this working for outbound transmissions but can't think of a way for inbound. How would your configuration know which company to translate it for unless you seperated by Location/Ship to.

Supposedly this is a configuration they use. They are trying to line up another Lawson client who has this configuration for a conference call. I'll keep you posted.

I recently took on a task of boarding as many EDI Trading Partners as possible, including 810's (where capable). I ran into the same problem, but ended up designing a 'workaround'. Basically, I have a Crystal Report that runs each morning that exports a CSV file of the Purchase Order Headers over the past 90 days. When our EDI Inbound transmission is complete and we have the MA540CSV file created, a script (which we wrote) then runs and compares the Vendor Numbers between the 2 files (using the PO Number as the 'Key'). When a mismatch is found, we change the vendor number in the MA540CSV file to match that of the Purchase Order. Without this, we would not have been able to board a majority of the 25+ vendors we boarded, due to Purchase From/Pay To matters.

I have written several interfaces that update the MA540CSV file for many things, including company number issues. Since data come in from several vendor systems, it is not practical to allow the inbound data to be written straight into the Lawson database; because, too many records would fail. Therefore, Lawson designed this inbound interface program--MA540--to have its interface data written to a file--the MA540CSV file. Now, in most all other Lawson interface programs the raw inbound data is, in fact, written straight into the database: this allows users to edit data [i] before [/i] the interface program runs. Not so with the MA540. You are running it against the vendor data. Granted there are some EDI translations; but, not nearly enough to account for the many issues that can thwart matching--taxes, company, process level, add-on costs, PO numbers, etc. Therefore, you should have your integraton layer, an interface, read and transform the MA540CSV according to a logical map: this map determines what the interface does in the event the company number is missing; or, the tax codes are missing; or, just about anything else. Your match rate will go through the roof.

Robin Luce
Director of Client Services/ and your interface guru
Weber and Associates Consulting Inc.
robin.luce@weber-associatesconsulting.com
240 423 4134

Duane,
The constraint in this issue is the EDI Substitution table (ED40). As ConsultantDavidW said, you can consolidate many variables (including companies) on the outbound translation, but the inbound translation is much more limited. Basically, if you have multiple options for xx_I_COMPANY with an account number of ZZZZZ, there is nothing available to determine which of the lines is the "valid" option. We have the same issue with process levels within a company. For this reason, we require the suppliers to create the full breadth of account numbers necessary for us to appropriately route invoices.

That is not to say that the above suggestions do not work, but they seem to spend a lot of ongoing energy managing a process that far exceeds the short-term angst of getting the vendor to supply you another account.
Red

I agree with Red. That's the way I'd go.