Update field in F4211

[Eastwood]

We have a situation where we have to update the F4211.SDRPRC for a particular ship to state through P4210. After reading several postings we came to a conclusion that modifying P4210 is pain in the rear. We need to update the field RPRC right after an order has been saved. Further, our client doesn’t even mind calling the UBE which will update RPRC field after we exit the P4210 application. Is there a way we can call a custom UBE right after entering an order? Or is there a way whereby we can wrap P4210 and a custom UBE (which will update RPRC) in another UBE.
Thanks in advance.

 

[BBritain]

Eastwood,

I guess it all depends on what you are willing to try. I have two possible solutions for you.......

1) You can use an old reliable method of performing Table IO right after the End Doc MBF, or,
2) You can use the commented out code that JDE has put in the software (which was originally intended for clients to use for User Reserved fields).

1) Is where you add the field to the grid, custom populate it, and update the values w/ Table IO following the End Doc MBF in the Post (OK) Button is Clicked event. You will have to change the MBF by unchecking the Asynch check box. You will also have to process all the grid rows with a While loop and some Get Grid Row commands.

2) In (Grid) Row Exited & Changed - Asynch event there is some code commented out (search on User Reserved) specifically designed to accommodate the update of grid columns not handled by the F4211 Edit Line MBF. If you uncomment the code and map your added RPRC field to the bsfn F4211 Pre Process Values for Edit Line, you be able to save the RPRC fields. Oh, just one other thing, the If statement may not be to your liking - as it only tests User Reserved fields.......

Ben again,

 

[JackieB]

Maybe try creating a table trigger on F4211 to launch the UBE using the Launch Batch Application BSFN?

 

[BBritain]

The usual problem that you will encounter with table triggers is that they will start right away and the End Doc MBF which is running asynchronously will not be finished yet.

I have actually implemented the 'User Reserved method' in the past two hours and so far have had no errors while testing the results.

Ben again,

 

[Frosty the Coder]

A note on using the USER RESERVED code.
The "preprocess" bsfn that you enable, steps on the CAT CODES on F4211.

I've recently experienced this "feature".

 

[Eastwood]

We are sticking to the vanila P4210. We do not have any other modifications (yet) except for this requirement. I do not want to modify P4210 because it will take hell lot of time to test it out and which will push our go-live dates.

I think I will write a trigger (acceptable by the client) to update RPRC from the custom preferences table. Rest of the Reprice processing is handled by R42750(Reprice Order, an option on P4210). And that should take care of it. I was able to update F4211 through trigger successfully. The only drawback is that if any ESU touches F4211 trigger then we have to modify the trigger event rule.

Appreciate everyone's suggestion on this.

 

[BBritain]

So Gene,

What do you mean this 'steps on' the Cat codes. I am still working on this and want to know what to watch out for.

And Eastwood,

Your table trigger is already working? The reason I ask is because my tests with Sales Order Entry tripping the table trigger showed no values in the key fields for the record, therefore I didn't know what records to work on. I currently have an issue with PeopleSoft and have talked about it in this list under 'Caveat Emptor for table triggers'. If you are successful, could you let me know what you are doing?

Ben again,

 

[Zoltan_Gyimesi]

Hi,

I envy you that you can keep away to have custom mods on vanila objects (including P4210, P4310, etc.)

The chance is much more less that an ASU/ESU will affect F4210 than P4210.

My two cents (for the case when an ASU/ESU will affect F4210 and VERC doesn' work to retrofit your mods):

Prior installing the ASU/ESU:
1.) Print the trigger ER into text file making easier to re-create your ER variables in the same order with tha same name.
2.) Copy your ER onto the clipboard and save it into a .clp file. Later you can paste it when you retrofit your mods.

+1 cent:
Could be a good idea to encapsulate your logic into a custom Business Function, so you have to retrofit only a BSFN call when retrofit is necessary.

Regards,

Zoltán

 

[Frosty the Coder]

It blanks them out.
See KG SAR 5717406, 5717414.

It was kicked around on JDEList in both June & July 2003.
See the threads "Populate User Fields in P4210" and "How to save Grid Values in Sales Order Entry?"

(But did I remember this BEFORE I tried it? NOOOOOooooo.)

 

[DBohner-(db)]

Ben,

Here's a work-around that I have used in the past.

The incoming fields may be blank - so fetch (from inside the trigger) to a different view of the same table being updated. If the incoming fields are blank - populate them with the current record's fields.

On a 400 it is important that you create a table-trigger dedicated BSVW - since you can't select on a record that is already marked for update (performance issues and some collisions).

As has been reviewed before - there are some functions that work outside JDE's table trigger mechanism. Those functions bypass the TER mechanism - so, it's a waste of time... I don't have a list of those functions (I had previously identified).

HTH

Daniel

stilllllll....

 

[BBritain]

Daniel,

Are you referring to blank values in table trigger? Because if you are, I was specifically talking about key fields being blank, and if the key fields are blank- how would I fetch anything using a different view?

Ben again,

 

[DBohner-(db)]

Ben,

Your assumption that I was 'not' talking about Key Fields is correct.

Something to look at, regarding the key field issue. I'm guessing that the is a Select for Update statement prior to the update. That way there can be multiple updates to the same record - without doing additional selects. Locate where that SFU is taking place - and we'll find our key fields... An update must be predicated by a select of some form - and the select has to contain either the primary keys or RRN(cursor) of the record

I'll try to dig up more in the test machine.

db

 

[Eastwood]

Ben,
I am getting the DOCO (TK DocumentOrderInvoiceE) in the "Before Record is inserted" event. I have to still test rest of the values. In my case I just need to know the Item Number inserted in the detail line and fetch the corresponding value from a custom table for that item and then update the field RPRC with the value fetched.

Thanks-