E9.1 Update PO Data outside of P4310.

[FrankCLT]

Good morning all,

We are integrating with a 3rd party vendor that will allow suppliers to change Quantities, maybe price and possibly cancel some lines on PO's and send that data back to us. Regardless of what data is being sent to and from the 3rd party, I would like to simulate the actions as if a purchasing agent was manually making the changes. For example, all the actions that take place when a quantity or price is changed, or line is cancelled, or a row is exited with a change.

Would I be looking at something like the EDI UBE's and tables related for Purchasing?

This would not be EDI, just want to leverage anything that JDE has that I can use.

Thank you,
FrankCLT

 

[DaveWagoner]

I've used EDI and z-file tables and UBEs for things like this (such as inputting orders from an e-commerce site), but it was never to accurately simulate what an actual purchasing user might go through. You can do SOME of that using the processor UBE proc options (app versions) but it's not exact, you're still typically just calling MBFs in sequence.

Orchestrator Form Requests are perfect for what you're asking b/c you can simulate down to the user, program, form, and version, but IIRC you aren't using Orch just quite yet.

Someone with more (and more recent) knowledge than me will probably have better input than this, just my 0.02

 

[DSauve]

Frank, what you are asking for is something that Orchestrations can do for you. Orchestrations can mimic what a user does by actually running the same apps/versions, but in an automated fashion. Plus you can add other logic into orchestrations to control how you process updates. I see you're on E1 9.1; what tools release? Oracle has put a ton of functionality into orchestrations and logic extensions, but most of the good stuff is in 9.2.x tools releases. Depending on your integration needs, you may want to use this as an example of why you might want to upgrade (the sooner the better).

 

[FrankCLT]

Thanks all.....

One more thing....

If using Z Tables (F4301Z1 \ F4311Z1) and the R4311Z1I, is this UBE just an ADD process? I think I just read that it was ADD only.

Does the R47071 (I think that's the EDI for Purchasing) allow UPDATEs as well as ADDs.

Thank you,
FrankCLT

 

[DaveWagoner]

Yes the EDI process allows for changes, it's a standard EDI transaction set though I can't remember the exact number (860 on a quick google)

The Z files can be maddening, if nobody ever wrote the "update" logic branch of the z file import. I do remember that detail on one or more of the z file processes, but I'll leave that to you to verify

 

[FrankCLT]

Thank you...

 

[FrankCLT]

Hi All,

I mentioned in some earlier related threads about a project involving a 3rd party Purchase Order processing. Well, contracts been signed, and it has fallen in my lap.

The process as it's been explained to me in early conversations. Is as follows:

"We will send a Supplier a PO through Leverage (this is the 3rd party), if they provide a response to the PO that differs from the original PO (a change to a line), those responses come back into Leverage (this is the 3rd party) into an escalation status called NEEDS REVIEW. The buyer (us) is alerted via email of the discrepancy and has to review and 'Accept' the changes in Leverage (this is the 3rd party), which then triggers those changes to be written back to update our tables. So, the buyer intervenes to confirm the proposed changes are approved first, and then we write back to update your tables."

So, I'm thinking if the supplier accepts the PO as is, our buyer will just process the PO with no further interaction. If there is a change that requires updates to the F4301 \ F4311, I was thinking of utilizing the F47071 \ F47071 and the R47071.

If I go this route, the first acknowledgement back to us that a change was made and we accept that change, I will go ahead and generate the F47 tables with all the pertinent information. From that point forward, we have a trail for this interaction with EDOC, EDCT, EKCO and EDLN. Quick question here, is the EDCT a "PO" or "OP"?

Once fully accepted the EDSP will equal "Y". If we don't accept, we reference the created EDOC, EDCT, EKCO and EDLN until complete. This would become our reference to this PO.

I haven't done anything like this before, most of my experience has been with 3rd parties that have integrated with JDE, and the flow was much easier.

What do you all think? Comments?

Thank you,
FrankCLT

 

[FrankCLT]

Hi All,

I've created a NER that creates the F47071 and F47072 according to document 625506.1, I used the minimum required fields to get some sort of reporting. Had some errors related to company being 00000, corrected that. Now I get the infamous error below.

I'm sure it's a field I'm missing to write to either the F47071 or 72. Those with more experience in the EDI F47 realm, I've written the minimums, not sure what I could be missing.
Can someone point me in the right direction as to see what fields are actually needed to create a PO?

Thank you,
FrankCLT

 

[vinngh]

Can you please send the F4311 and F47071/72 extract? Just check if the F47072.TNAC is with 02 or 04?

 

[FrankCLT]

Hello,

Thank you for your reply. There is no F4311. I am attempting to create those records in the F4301 \ F4311 tables. I didn't see the alias TNAC.

This is a USD order to be generated. I wanted to keep this a simple as I could. In the Log, I do see the insert into the F01131M with the message "Error: Record Invalid".

I have used JD document 625506.1 as a guide, but everything I've tried ends the same way. Has anyone attempted similar? I'm looking for the minimums entered into the F47071 \ F47072 to get an PO created when the R47071 executes.

FrankCLT

 

[vinngh]

Hello Frank - I believe R47071 should only be used for receiving purpose ( In F43121), it doesn't changes the order quantity , price or status at F4311 level.
We do have standard EDI for PO Acknowledgement received from Supplier Document ID - 1303201.1 ( Transaction set 855) however, it doesn't allow to change the PO quantity, price or dates. It generates the discrepancy report which compares the PO Acknowledgement received and the actual Purchase Order. By looking at this discrepancy report, Buyer to manually update the changes in PO ( If agreed with response) or contact further to supplier.
Standard EDI for transaction set 861, doesn't allow changes at PO level.

Thanks,
Vinay

 

[FrankCLT]

Hi Vinay,

You are correct. I am going a different route. What I was hoping to apparently will not work.

Thank you for your input.

FrankCLT

 

[FrankCLT]

Since this is all related to what I initially wanted to do, what is the Secondary Quantity Ordered (SQOR) on a PO? How is that originally stored or entered?

Never really noticed this before, but it changes with the regular Quantity is changed.

Thank you,
FrankCLT

 

[vinngh]

Hello Frank, SOQR value auto populated based on conversion factor between Primary and Secondary UOM. If Dual UOM is not enabled, then this value gets changes as per Primary UOM transaction quantity in Purchase order. If you change in Secondary UOM quantity, it doesn't change the primary and remains with same value. If you don't maintain Dual UOM then you can leave this value blank and system will take it automatically.

 

[FrankCLT]

Morning All,

Getting back to the root of my original thread question....If I wanted to update the Price, quantity or even Cancel a line in the F4311, how would one go about doing so? This would be external to the P4310 application. I not sure of all the other functionality that would need to occur in addition to the update of the F4311.

Thank you,
FrankCLT

 

[DSauve]

Going back to my original reply, I'd still recommend using orchestration(s) to accomplish this. You'd need to take the message from the external system and pass that data into an orchestration, which would run P4310 in the background. One huge benefit of using orchestrations is that you get all the benefits of the existing logic already in your P4310 (or any other JDE application you call in an orchestration). There are definitely security considerations, as with any external integration. If this is all new to you, I'd advise you to engage the services of a business partner to help you get started.

 

[FrankCLT]

Yeah, I would have enjoyed the opportunity to have used Orchestrator, unfortunately, our tools release is outdated, and we don't even have Orchestrator setup.

 

[FrankCLT]

Hi All,

last question and I'll put this to bed.

In my testing of different methods of updating the F4301\F4311 outside of the P4310, I've tried to mimic some of the calls to the following BSFN's in a custom NER. These are also in the order being called.

GetAuditInfo
X0010GetNextNumber - JobNumber
RetrieveProcessAndTransactionID

F4311FSBeginDoc
F4311EditLine
F4311EndDoc
F4311ClearWorkFiles

With the above F43 functions, I reviewed the calls from a Debug log from within the P4310 to make sure I passed the correct values.

I have done similar with the Sales BSFN's, and they worked fine.

When I execute the NER through object browser with the F43 functions, I get the same error.



Has anyone done something similar?

Thank you,
FrankCLT

 

[DaveWagoner]

One thing I've found in my travels recreating functionality that APPLs do by calling sequences of BFs, there is always one or 2 things hidden somewhere that are necessary for proper functioning I'd say that you are probably missing one or 2 things that are hiding. Whether that's a param value input, a param output, or an entire BF call that's hidden within controls within controls.

But the good news is that APPLs aren't magic and that they do make the same calls you can call via NER given correct inputs & outputs.

Check for Init MBF calls prior to the begin doc, for instance.

Here's a mapping of BF's I did for health and safety 54HS. It took quite a few iterations to recreate even to the point of basic functionality. I'm still missing some in here, but it covers everything I need at the moment.

 

[BOster]

I'll put in my two cents. I would take the same approach that I did with xmlCallObject and with BSSVs which worked well in the past and seems to also work well with Orchestrator in the extremely limited capacity I have worked with Orchestrator.

I always created "wrapper" functions around MBFs that simplifies the interface needed by the interop solution (xmlCallObject, BSSV, Orchestrator). I just found it was much easier to do all the "heavy lifting" in a BSFN as opposed to XML, Java, Orchestrator. It also allows you to do any additional logic needed before the MBF is called or after the MBF is called w/o exposing that complexity to the interop caller. For example, for the sales order MBF we may have needed to automatically change the price to what was passed in and automatically create a price adjustment in price history which is a whole other set of BSFN calls, table i/o, logic, etc. (get processing option values, call editline, get price, compute price diff, make call to bsfns to change price in the correct price adjustment record, recall editline, etc.). This is just one of many examples where we were able to hide the logic complexity in the wrapper function and present a more simplified interface to the interop tool. That way to create a sales order you just had three basic functions presented to the interop tool: WrapperBegDoc, WrapperEditLine, WrapperEndDoc with a minimal set of parameters to map (if done correctly you can hide the ridiculous data structure presented by most MBF calls) instead of the multitude of other BSFNs and related logic you would otherwise need to try and do in the interop tool. Even in BSSV/Java this became daunting and was just easier to do in a BSFN.

Granted I write all my BSFNs as C BSFNs so it makes it much easier to organize large amounts of code as opposed to the spaghetti mess that can often happen with very large NERs, but I would think even in an NER it would be easer to organize the complex internal logic of all the calls needed to be made. Additionally it would be easier to handle things like cleanup logic so you don't have jdeCache cursor and memory leaks (again, especially easier in a well written C BSFN). It also allows you to do some things which may be needed that can only be done in a C BSFN like passing in a pointer to a caller provided table record buffer or something like that.

It also makes it much easer to develop and test. I did build a BSFN unit tester that I use quite extensively which makes development/testing of BSFNs much quicker and easier, but even if you create a throw away test APPL to make the calls its going to make development go a lot faster and easer with the additional advantage of being able to actually debug not only the wrapper functions you are creating but the MBF calls themselves and grab debugging logs, etc.

In other words, let Orchestrator (or any other interop tool) do what it is good at and use traditional development tools for what they are good for - let each tool play to it's strengths.