using URCD on P421001 (powerform SO header)

I'm attempting to add URCD (user reserved code) to the sales order header (power form P421001) and have it write to the F4201. The S421001E (B4210610) is the business function used to process the header, which calls several other functions internally. I've added URCD to the Data structure for B4210610, but having a hard time finding how to move my urcd value into dsBusinessData from there. The data structures that are used to write to the header cache/workfile/table already have URCD in them. My issue is populating it.
Thanks.
Marshall

Windows x64
E1 9.1
tools. 9.1.03
SQL 2008r2

Hello

I have an equivalent problem but with an old JDE's version. As i remember, this field is not in the data structure and i couldn't find any simple ESU to solve that.

So you should have to do that on your own.

I wouldn't do it that way. Avoid changing any SOE BSFN structures at all costs. The P42101 is a mess, in my opinion. I'm half convinced it was someone's evil experiment in abstraction.

Instead, do an update directly against F4201 immediately after Enddoc.

Thanks for the responses.
The business function data structures already have the user reserved fields in them, they just aren't populated (I, so far, have modified the data structure for S421001E, as it is the calling bsfn from P421001 and did not contain user reserved fields). Thats the main reason I was pursuing this route. Seemed like it should be fairly straightforward.

Serge,
If its helpful, when talking about an older JDE version if you are using P4210 for Sales order entry the data structures do have the user reserved fields in them. On OK button from SO Header there is F4211 Begin Doc and Determine Changed SO Header Values that already contain the user reserved fields.

[ QUOTE ]
I wouldn't do it that way. Avoid changing any SOE BSFN structures at all costs. The P42101 is a mess, in my opinion. I'm half convinced it was someone's evil experiment in abstraction.


[/ QUOTE ]

I agree completely. Not limited to sales order though, I am currently working with Load Build and they also have user defined fields in the tables but no standard way to use them. Why they don't include these in the MBFs/Model is beyond me.

For P42101, even if you do mod the view controller DS (again , not advisable to mod a pristine DS), you would still have no way to write the value to the table because these fields are not in the MBFs data struct either.

[ QUOTE ]

Instead, do an update directly against F4201 immediately after Enddoc.

[/ QUOTE ]

This is one way and probably the most straight forward and easy (remember you will now have to call EndDoc in sync mode or make a wrapper BSFN that calls EndDoc then updates the table).

I prefer to make my own tag or extension cache. Then just mod the MBF (in this case B4200310) to pick up your values out of your custom cache instance when it inserts/updates the tables. Additionally, you will then have a framework in place for future modifications to write to an extension or tag table(s). If you mod B4200310 correctly it can even account for calling applications that have not implemented your custom cache so your stuff doesn't break when something like sales update (which may not have implemented your mods) runs.

[ QUOTE ]
I wouldn't do it that way. Avoid changing any SOE BSFN structures at all costs. The P42101 is a mess, in my opinion. I'm half convinced it was someone's evil experiment in abstraction.

[/ QUOTE ]

Oh, and the part I agree with is that you shouldn't mod a pristine DS.

I couldn't disagree more about P42101. I happen to think that the P42101 is one of the better, if not the best, architected pristine applications in E1. It is a quantum leap improvement over P4210.

Thanks BOster,
I find it frustrating, as you mentioned, they have almost made the user reserved fields useful, but not quite. Anyway, I've got multiple suggestions to not modify the DS, I suppose I'll pursue a different route.

-also I would agree (not to create camps!) that the 42101 is very well done. It takes just a bit to get used to the architecture and figure out the flow, but once you do its nice to work with.

Yeah, the P42101 is nice and pretty, and fairly straight forward... until you want to do what JD Edwards is known for - Customizations!

I tend to agree with both camps.
- Some of the Prettiest Code ever (if you can read C and have a sound understanding of Caching)
- Some of the Worst Design in History (if you need to provide any additional functionality to a product that is known for the ease to enhance functionality).

You can't "copy" it to a 55 - without six months worth of heads-down work (Externally Defined Forms and it's all about Cache)...

(db)

[ QUOTE ]

- Some of the Worst Design in History (if you need to provide any additional functionality to a product that is known for the ease to enhance functionality).

You can't "copy" it to a 55 - without six months worth of heads-down work (Externally Defined Forms and it's all about Cache)...

(db)

[/ QUOTE ]

1. I find it much easier to mod and maintain/retrofit P42101 mods then P4210 mods.

2. Why ever copy anything to a "55"? I have never understood the copy and mod reasoning.

B,

#2 - Copy to a 55:
- On the last few upgrades I've been on, there has been a Zero-Tolerance rule for Modifications. Yes, I typed 'Zero'.... For a software package that's claim to fame is the ability to enhance - I'm not all-for that rule, either.

Oracle requires us to be able to replicate issues on Standard Objects. I'd suggest to clients that Pristine always be up-to-date with whatever ESUs and Updates have been applied to Production. That way, they can always attempt to replicate the issue against Pristine.

I haven't delved into the cache functionality embedded into the P42101, much, but I recall seeing a snip of code that was specific to P42101. That stated, a developer would not be able to replicate the P42101 without replicating the functions that drive it.

(db)

I guess if you have a client dictating it then you have no choice (and for P42101... wow, that would be a job if not down right impossible. A simple little 2 day mod to P42101 might be a two month mod to P5642101).

Its a shame that there is this mis-informed belief out there that a copy-and-mod is the "correct" way to do things. If you really sit down and analyze it, in almost all cases (not all, but most) it makes absolutely no sense. I really think things like this get dictated because someone heard from someone else that this was the correct way to do things. And of course, the person they heard it from never really thought about it but simply decided it was the right way to go because someone told them, and so on and so on.

A copy and mod ends up being:

1) much harder to do
2) more prone to errors (now you have to have IDENTICAL versions for both P4210 and P564210)
3) often much more invasive (remember all those form interconnects out there from other applications)
4) harder to retrofit and maintain going forward
5) and most likely will put you in a worse position with Oracle support instead of a better position.