Import New and Changes to Existing POs

Since you are receiving requisitions. Isn't it better to use RQ100?

No, we aren't getting reqs. e-builder is doing all of that side. We'd only need a PO Number at that point. If we had to, we'd bring it in as an RQ500 and run PO100s to add new. But we also want to make changes to existing POs.

Depending on what you change I believe you can bring in changes to POs from eBuilder. Mess around with PO53 and PO53.2 with PO520 to see what values you can change. You will need to pass back the PO number to eBuilder so if changes are made there they come in with the PO number and line to change. For the record type on the Header and Line you can interface with Change.

Thanks - we are working to feed the PO Numbers back to them, so it *sounds* plausible. Now to prove it's doable!

Keep me posted. We're going to integrate eBuilder with Lawson also. eBuilder does a nice job of sourcing for construction. We are looking at feeding activity information for capital projects but really want the requisition/PO in Lawson for cash management.

I'm at kvila@mhs.net or scmsystemdept2@mhs.net if you want to email me, I'll share the project as we go. As it stands: Currently all activities and vendors are being fed from Lawson into ebuilder. ebuilder is handling all the heavy lifting from project evaluation and bidding to the cads and approval routing for budget. So it's the complete requisition and approval. We require our vendors to have a PO and they want it for the full contracted amount. So the future state idea is that we create an export from ebuilder to Lawson - treat it as an approved req and create a PO from it. As the activity, budget and vendor information came from Lawson, we aren't anticipating too many issues. They should be able to give us all the values and Cloverleaf should be able to get it into PO520 format. PO53s seem to only be the errors. So we're going to try it but there's a knowledge base article listing a couple of "gotchas" - we may end up building an IPA with an upload.

PO53 can be used to input data and then run PO520 with DB input option. It will pick up what is on PO53. It should have all the same input fields as the PO520 in a form entry format.

That just helped sort this out in my head - thank you! So the file we bring in and place on the server is populating PO53 like PO23 gets populated with approved req lines. PO520 is a job that's running against that table like PO100. We can either import a file to populate PO53 OR input directly on it -- either way, PO520 will convert to PO as new or change and leave behind what it couldn't?

You got it. I'd recommend creating an extract from eBuilder and loading into POCHEADER, POCLINE and POCMMDIST which are the tables PO53 uses. If you back fill the PO number on Requisitions in eBuilder you should be able to determine if it's a Add or a Change before sending to Lawson. There are some key fields that you can't change...so you have to treat as an additional line. If you use the csv file option on PO520 I'm not sure the intermediate tables above (PO23) is used. Never tried it.

Hello Kat and everyone else, We are starting a mini-project to bring in PO's from e-builder, too! I just started testing the PO520 for this process. I've used PO520 before to convert PO's from older system when implementing Lawson, but never for an on-going project like this. I'm running into a problem with PO number. Do you have to put in a PO Number in your file or can Lawson auto-assign it when running the PO520 so it just creates a PO Number in line with the normal PO Numbering scheme?

This is where we are currently stalled at as well. In PO520 is "Rec Type" segment Rec Type Numeric 2 "Record type / action taken 1 = Adding a Purchase Order Header Record (PURCHORDER) 2 = Adding a Purchase Order Line Record (POLINE) 3 = Changing a PO Header Record (PURCHORDER) 4 = Changing a Purchase Order Line Record (POLINE) 5 = Adding a PO Header Comment/Attachment (CMTPCR) 6 = Adding a PO Line Comment/Attachment (CMTPLI) 7 = Process a PO Header Cancel command (PURCHORDER) 8 = Process a PO Line Cancel command (POLINE) 9 = Process a PO AOC Spread Add command (POAOCSPRD) 10 = Process a PO AOC Misc/Line Add command (POAOCDTL) 11 = Process a PO AOC Comment add (POAOCDTL) 12 = Process a PO AOC Change command (POAOCDTL) 13 = Process a PO AOC Cancel command (POAOCDTL) 14 = Process a PO MMDIST Add command (MMDIST) 15 = Process a AM Defaults Add command (AMPODFLTS) 16 = Process a AM Defaults Change command (AMPODFLTS)" In theory, if the segment is 1 - it should send an ADD command to PurchOrder and generate a PO Number. 3 - would be change existing. The project stalled due to vacations and FMLAs, but ebuilder did not seem to think they could populate this?

Ouch, that's not reassuring. We are looking at probably doing a custom program to load to PO20, instead, because of the limitations of PO520 and auto-numbering.

As long as PO01 has numeric POs are auto numbering it should be able to add POs using option 1.  Make sure you have a number defined on PO01. 

If I remember correctly the problem was you had to add the header before the lines (as in run a file with all the headers and a separate file with lines - don't remember).   Play with PO53.1 and PO53.2 to get the process down and then you can replicate using PO520.

If you go the PO20 route I would still recommend using PO53 for a little more control.

Hi all, We are ramping up on this and I was playing around with PO520 and PO53. When I go directly into PO53 and attempt to add a new record, it tells me that I cannot have the PO Number field blank. So, I'm stuck again at getting the system to auto-assign the PO number. Kat: Did you get this up and going with e-builder?

No - project is ongoing. We're going back to RQ500 with settings to skip approvals (as they are being done in ebuilder) and seeing if they can provide that format. My IT is pushing back to get a standard format - but if you've got IPA - you might want to look at RPI/Don Petersen's Self Contained Workbooks. RPI had a webinar where they've managed to get an upload to add the header, return the new document number, then upload the line detail to the newly created header.

Hi, Kat. Just checking in to see if you've made any progress. We are ramping up on this and are trying to determine the best approach.

Not with PO520. We are moving forward with them giving us an RQ500 with a reference number in PO User Field 3. We will SQL an export where the PO Line Source Requester = "EBUILDER" (The RQ04 I'm giving them) and send the PO# and information back with that user field.

We're live. For the initial order - I've got requester EBUILDER set up as no approvals needed. We get an RQ500 inbound and IPA runs it, runs a PO100 set to export to csv and then uses it to create the handshake back to ebuilder with the PO numbers. For any subsequent changes - eBuilder is sending a PO520 to change the PO numbers we just gave them above. IPA is processing them and returning confirmations back with the modified PO line totals. We still process orders for projects outside eBuilder (furniture, IT equipment, etc) so there's a separate IPA to tell them when a new PO on the project not linked to a req from requester EBUILDER appears and another to tell them changes to those PO. We went live on the 7th and so far nothing's crashed.