EDI 810 Invoices

Joanna

I am in search for almost the same information. Do you use Drop Ship coding on your PO's. We are multi-facility healthcare organization. We have serveral vendors on 850, 855, 856, and 810 transmissions. However, the drop ship po's are fatal errors. Along with drop ships, I would like to get info on service pos which like you explained are non- receiving po's that are batched and not automatched. Have you had any response?

Hi Joanna & Rebecca -

You might consider using a Drop Ship Handling Code in your MA540 import file to segregate Drop Ship Invoices from the others being integrated using 3-way match, since a Drop Ship PO in Lawson does not have a receipt. You can also setup a Handling Code for Service Invoices in a similar manner.

All the best,

Rob

Does anyone process Non PO 810 Invoices into Lawson if so how and what jobs do you run. Thanks

Hi Jesse -

Normally, you would use the AP520 to load non-PO invoices and the MA540 to load PO Invoices. All EDI 810 Invoices must go through MA540 input program as that is the file produced by the Lawson EDI translation process (ED502). If you want to build a custom Lawson EDI translation engine to translate 810 and output into an AP520 file to bypass these Lawson EDI MA540 steps, then you could do that too, but that's a lot of work to do when you could just use the MA540.

RC

Anyone use PO520 to bring non-Lawson PO's into Lawson?

Hi Rob

We currently receive 810s from our Office supply company but the invoices are Non PO. Do you know of a process to bring them in thru Lawson. And no we don't want to do anything custom.

Jesse

If you have ProcessFlow, you could build a flow to read the 810 or even the MA540CSV file and dump it into AP52.1, AP52.32, etc. Then run your AP520 to pull them into Lawson.

Hi Jesse -

Are you currently setup now using Lawson EDI? I assume you have ED02, ED10, ED40, AP10 setup for this office supply vendor? Are you a GHX client?

Most clients setup Lawson EDI 'plain vanilla' to translate the 810 into the MA540CSV and then bring that into Lawson. There are some Lawson setups involved since these are non-PO/expense invoices, so you want to bypass the 3-way match, like using an expense handling code, EDI auto release, add only on the MA540 and an EDI specific rule group etc.

I built an 810 EDI translation engine for GHX this Spring using PFI and I have to say that it is quite a bit of work parsing the ANSI X12 into MA540! If you want to convert 810 to AP520, then I could also license that PFI code to your organization.

Please feel free to drop me an email on LinkedIn and we can setup a time to briefly chat over the phone on the subject. I've worked quite extensively with Lawson EDI and all this Procure to Pay stuff over the years and would be happy to help point you in the right direction.

All the best,

RC

Hi Everyone

Is anyone on the 9.0.1 version and if so are you have any problems with no charge line items. In the 9.0.0 version this was not a problem for us. With the new version our invoices coming in with a no charge line item for example baby formula we do not pay for it this causes the invoice to go to the fatal MA54. We then have to delete the line and release the MA54. Does anyone have any problems with this or any suggestions. Please help

Hey Jesse. I know you posted this a while ago, but we just recently converted to 9.0.1.9; did you have any luck figuring out a solution to this? Fixing these fatal invoices for zero dollar lines that are closed is already getting old.

I have gone back and fourth with Lawson and the Vendors we receive 810s from. Infor/Lawson told me to tell my vendors not to include lines with not charge because Infor will not process those lines. I reached out our some of our vendors Owens being one of them and they told me they will not remove any lines from the invoice to work it out with Infor on the no charge line processing. So no nothing as been done to help us with this issue we have to delete all lines with no charge in MA54. Sorry our automation processed turned into another manual process. Sorry no luck

Thanks for replying. We brainstormed a little here yesterday and had just one idea. And we don't know if we will get it approved through management or not.

When the PO is created, instead of choosing option Cost option 3 - no charge, purchasing can create that line of the PO using cost option 1 like normal, but put the price as $.00001 per unit. It should process through ok, for $0.00 unless that line of the PO has an extrememly large volume, we think. I do see lines come through from some of our vendors that are not "zero dollar - no charge" lines, but have units that small, and match to our lines that have the same unit prices.

We haven't tested it yet, but it's an idea.

I think the invoice coming in with a no charge from the vendor will still send it over to a fatal MA54. We have talked to our vendor about charging us $0.01 for the product and they won't do it. I have tried everything and can not get it to go thru. But we have told Infor this was not a problem on the version we were on before the one we are on now. Infor told me that was not true no charge lines have always hit the MA54 they should not be on the invoice. Don't know what else to do and the buyers hate it because that means they have to go in and make the fix in MA54. If you discovery anything please let me know jsegura@northbay.org

I know I'm late to this conversation but I have a few suggestions that might help. You could put a preprocess in place to validate the MA540 file before running the program. An example is something we do to resolve missing company numbers. We scan the file and if the company number is missing we remove/archive lines and rebuild the lines adding company number. (All PO numbers start with a company number). Not sure why you couldn't look for zero lines, pull them and if no lines remain pull the header. We archive the errors and email our on call that a change has occurred. Another option is to modify the perl script (Last resort option). Just some thoughts.

Just an update - our IT genious created something that runs BEFORE the file hits MA540 to strip all lines where the invoice line is zero dollars, and the corresponding PO line is no charge. Kind of scary changing the incoming invoice, but I haven't seen a single problem yet. That way, when the file hits MA540, that invoice line is gone. In our system it is called CP154. I don't understand all the technical stuff, but it's amazing.
In this same file, it also fixes incorrect info in the PO code field and strips spaces, etc. My fatal errors have dropped by 1/2 or more over the last few months.