Adding Column to P4210 Grid

[Jamie_Yates]

Hi List

I need to add the column F4211/RCD to the grid in P4210 - Form W4210A.
I added this column to the business view and then to the grid, but it doesn't update the F4211 table. On further inspection i realised that it uses the Sales Order MBFs to update the table but the field RCD isn't in there.
Could someone please tell me how i can do this.

Regards
Jamie

 

[mvsteen]

Hi

RCD is a field in the F42UI12 cache (processed via 'F4211 Pre Process Values For Edit Line'). This is like the values you can access via the SOE Additional Information exit in Take Order). Adding this field to the P4210 grid has to be checked carefully and by using mentioned function.

Hope this helps

XE sp 22 ,NT, Unix

 

[mvsteen]

Hi

RCD is a field in the F42UI12 cache (processed via 'F4211 Pre Process
Values For Edit Line'). This is like the values you can access via the SOE
Additional Information exit in Take Order). Adding this field to the P4210
grid has to be checked carefully and by using mentioned function.

Hope this helps

XE sp 22 ,NT, Unix

 

[BOster]

I'll just add one thing else. We had some problems using F4211FSEditLinePreProcess. Specifically it was wiping out some other fields like the SRP codes. I believe there was a SAR on the issue as well.

 

[BBritain]

Jamie Yates,

This can be overcome via two methods, the first option has been discussed in this forum several times - which is to update the grid values after End Document (there is more details in the archives). The other option is to use an altered version of the PreProcess function so that it doesn't clear those values that BOster refers to. This second option requires contracting someone who reads C code like poetry (not me) - or purchasing the code created for a company I previously contracted (I believe they were on version B9). If there is any interest in either of these options, contact me and I can verify that these options are still available.

Ben again,

 

[Jamie_Yates]

Thank you all for you helpful advice.
I got this BSFN working to update RCD, unfortunately it did clear the SRP fields. Hopefully I should be able to get the SAR installed to solve this.

Thanks
Jamie

 

[neil_shepherd]

Hi,

If your not able to apply the SAR (maybe effects too many other objects) consider doing a fetch on the F4102 and feeding the cat codes into the pre processor function. I think unwanted clears also effect other fields apart from the cat codes so check a before and after image of the data carefully.

Regards

Neil.

 

[peter_hamilton]

The thing to remember about the F4211 pre-processor, is that this is like a normal cache statement (in fact it does write to the cache).
Hence, if values are not passed, the value will be written as a blank (or null) to the cache.
So, to use the pre-processor, you need to supply values for ALL of the fields, not just the one field you want to use.

 

[ClaGe]

Hi BBritain,

I'm very interested in the first option that you mention, however cannot find any further available information in JDELIST, as you mention in your reply.
Could be my mistake though, however, could you please help me out?

 

[Zoltan_Gyimesi]

Hi ClaGe,

It was discussed last time not too far in the past.

Check the thread on this Forum:

Problem with adding a field in P4310/W4310A grid

Opened:

08/25/04 09:23 PM by fauberte

Regards,

Zoltán

 

[BBritain]

ClaGe,

Besides Zoltán's reference you can also search for "Sales Order Entry - saving a value". To restate everything here will take more free time than what I have available, but let me try to give you a high-level view.

When using Master Business Functions (MBFs) which both the sales order system (42) and purchase order system (43) use, the typical operation is to start the process with Begin Document. Begin Document MBF will validate header information and load that header information into cache memory. Then as the user enters grid information (detail information) each record is validated in several ways (data item validation and cross-data validation) from within the MBF "Edit Line", which also loads the information into cache. Once the user hits the OK button, the MBFs then use "End Document" to finalize the information and store the information to the table. This is made more complex when you also need to consider that sometimes the user is working in different modes.

1) New header info, New detail info.
2) Existing header info, Existing detail info.
3) Existing header info, New detail info.
4) Existing header info, Existing AND New detail info.

All of this adds to the complexity of the MBFs as well as the supporting program/UBE. Additionally, the cache memory can be redirected to the F4xUIxx tables as well. Because of this complexity, Edit Line has a gazillion (a lot of) parameters mapped to it. Because they didn't want to change the MBF functions and because of increasing pressure to be able to update User Defined values AND other values not previously covered in Edit Line, the Preprocess .... functions were created to update the values in cache memory (or UI table). Unfortunately for the Sale Order applications, this preprocess function has various deficiencies and a low priority for JDE/Peoplesoft to fix.

Developers have typically taken the approach to update values in Sales Orders called in football as an 'end around'. This term can refer to any situation where it is difficult to introduce changes in the middle of a process - so we wait for the process to end and then make the changes.

For this situation, the end of the process is in the OK button's Post Button is Clicked Event where the End Document MBF lives. We find a suitable place in the code after End Document (this is where the data is saved to the tables), and use Table I/O to update information directly to the tables. At this point in the code, you would loop through the grid records and read the information from the grid and update the records in the table.

Because the MBF End Document is usually set to run in asynchronous mode - meaning it will continue on with processing the rest of the event rules before the End Document has completed. This means that you might try updating the record before it really exists in the table. To solve this, we must uncheck the "run asynchronously" checkbox in the End Document function. Only then, will we be sure that the End Document has finished updating the table. In doing this 'end around' we also need to be aware that certain data combinations are not being validated.

Now the loop that you need to write, well, that's the artsy part of the process. Just, read each grid record and write the extra fields that you need.

I'm sure I have missed some portions of the process and all you experts be sure to let me know.

Ben again,

 

[BOster]

The "end around" technique is what we used on the P4210 for our user res fields. However to increase performance we are considering instead writing to the 42UI12 cache ourselves or modifying end doc to put our values in the DS right before it is written to the table.

However, another, less invasive idea came to me that I thought I might throw out. Instead of taking F4211FSEndDoc out of async mode why not write your values to your own cache then call your own custom end doc AFTER F4211FSEndDoc runs, also calling it in async mode, have it pick up the values in cache and update the fields in the F4211 table. If I understand the async process, there is a single async thread for running BSFNs that get called in async mode. They essentially get queued up behind each other so by calling your own BSFN in async mode to update the table you can be assured that F4211FSEndDoc will finish first and the records will be in the F4211 table to update by your BSFN all running in the async thread while the end user goes on his/her marry way.

 

[BBritain]

BOster,

If you are going to spend the time to create a custom cache (something I myself don't know how to do), why not use that same development time to fix the Preprocess function and also have all the Cat Codes and extra stuff now available for update? One of our esteemed experts on this forum did just that and I'm fairly certain it took him a lot less time than that needed for setting up a custom cache.

(to the esteemed expert) Any thoughts to add to this?

Ben again

 

[BBritain]

Re: RE: Adding Column to P4210 Grid

Peter,

The Preprocessor function does work the way you say, but know that it works that way because it has a bug, and that is not the way it was intended. If I remember right I did try to pass values in and the record still ended up all blanked out. I'll have to check my notes, but I am pretty sure that if the bug is fixed then the pre-processor can be used without having to pass everything in.

Ben again,

 

[BOster]

Well that is one of things we have looked at doing was writing to the 42UI12 cache ourselves instead of using F4211FSEditLinePreProcess.

My only thought was that if you didn't want to touch any of the JDE code or mess with any of their cache structures you could have a BSFN come along after end doc which executed in the same async thread that did the record updates. This would allow you to still have end doc run in async mode.

 

[Sebastien Leclerc]

One way of preventing values from being overriten is to slightly modify the preprocessor's function using some code that's already available in the edit line.

Basically, the preprocessor will perform like this:
1- Get the values from the calling structure and assign them to the cache structure
2- Perform a cache add
3- if the cache add fails (this means that there are values in there added by either the preprocessor itself or by the editline) , it does a fetch in a dummy structure, copies a few values from the original cache record (Invoice Number, Document Type, Company key, Freight Handling_FRTH, and Shipment Number if you're on B9. After copying these values, the record is updated with whatever was passed in the calling structure thus loosing some values.

There are 3 ways around that (in complexity order):

1- Set a condition in "Row exit and changed" so that the preprocessor is called only if GC Source of data is not 6. However, if some values are in the grid, they can only be modified when the line is first created and the field must be disabled after the first edit line

2- Pass '1' in cKitConfigWindowOpened after the first call to edit line. This will make the preprocessor use the cache that's already in, with the result that you cannot change fields values after the processor was called the first time. B9 does just that with SAR 4770977...

3- Go in the preprocessor's code, right after the fetch from the cache. Add the following: I4200310_CombineF42U12(lpBhvrCom, lpVoid, &dsF42UI12, &dsDummy);

Add the same call right after the JDB_FetchKeyed to support also Workfiles instead of Cache.

Note that if you want to keep invoice information, you'll have to figure it out...

I havent tested this call, but after looking at the code, I believe that it should work with little modification.

Good luck and keep us informed!

 

[peter_hamilton]

Creating your own jde c routine is pretty easy once you understand the c BSFN involved.

However, more the jde pre-processor.
Inside, B4200311, it checks the contents of the F42UI12, and if values exists, it uses that value. This is done within routine I4200310_LoadDataFromF42UI12.
In this routine, is checks if the value is NULL, if Null it does not use the value (and will use it from the F4211 if changing an existing line).

The problem the std pre-processor has in P4210, is that the application ER will pass blanks (not nulls) to the parameters. This is entirely different from a NER call to the same BSFN. As in NER, when a parameter is not defined, the value is a null.


Sure, you can write your own c cache BSFN (or use a WF), and after the F4211ENDDoc call (in Async) call your own NER in Async. Your NER will run after the F4211EndDoc has completed. And by reading your own cache/wf, you can then update the F4211 record.
Problem with this, is the amount of extra update statements to the F4211.

What you can always do, is in the F4211Enddoc, read your own cache/wf, and override the F4211 value directly (i.e. only the one I/o statement to the F4211).

However, you can't use the above solution(s) when the values you want to store in the F4211 affects how the F4211 edit line will execute. When this happens, you need to store the values into the F42UI12.

To summarise what you need to do, to set values in the F42UI12:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
If you wrote your own c bsfn to update the F42UI12 cache, you would get the current cache record. Set your new field(s), then write/update the cache record. Of course, your c bsfn, should cater for updating the F42UI12 cache and the F42UI12 wf (depending on the use cache/wf flag).

Outside coding in C, you need to treat the cache like a full table I/O statement. I.e. Read all the values in, set the field(s) and then write/update the record.
The same principle exists for caches (when using them outside c).
The reason why c is different, is that when the cache is read, all the current values are loaded into a datastructure. To match this in ER code, you have to read all the current values into variables. And of course, for the first F42UI12 record, when it is written, all the fields contain null, except those fields you have set.

So in P4210, to store values in the F42UI12, you need to get any existing values in the F42UI12 (there is a BSFN to read the F42UI12). If no F42UI12 cache record exists, then for existing lines, you need to get the current F4211 values. Set the fields(s) required, and then update the F42UI12 (call the pre-processor).


Hope that helps.

 

[BOster]

Re: RE: Adding Column to P4210 Grid

What you can always do, is in the F4211Enddoc, read your own cache/wf, and override the F4211 value directly (i.e. only the one I/o statement to the F4211).<br>

I have actually tested this very thing and it seems to work fine. The fields we are trying to set are just the user res fields so we don't need any MBF logic to act upon them luckily... we just need them set. It appears it is a pretty small mod to end doc to do this. Just insert your code to update the F4211 structure right after end doc makes its call to I4200310_LoadF4211ParmsForED.

 

[Zoltan_Gyimesi]

Hi Ben, ClaGe, BOster, Peter and Sebastian

As we can see, there are several way to solve the original issue (adding extra fields to the grid and manage their changes into the database).

More of you, who replied this thread, are expert C programing plus JDE C cache handling. I suppose, there isn't as experienced developers as you are at all site.

By my humble opinion, modifying original Master Business Function (MBF), generally not the best way. MBFs are frequently touched by ESUs, and sometimes could be harder to re- apply custom mods, though this is generaly text Copy/Paste, but MBF can be very complex (Maybe
I am mistaken).

Good idea to build our c cache and BSFN, which can be called asynch after EndDoc. This do not prevent the solution from extra update.

If there isn't enough C and C cahce experience, the NER solutions remain. There are at least 2 well known solution:

S1.) Using work table instead of c cache and update record from a BSFN after EndDoc.

Advantages:
- BSFN can be called asynch.

Disadvantages:
- Much more Table I/O (Insert, Update, Delete on work table)
- at least 3 additional custom object (TBLE, BSFN, DSTR)
- you have to modify vanila APPL at more place (Row/Column Exited and Changed - xxx, Post OK Button cliked, and maybe at other places too)

S2.) Going thru the grid and update records after EndDoc explicitly in the Post OK Button Clicked.

Advantages:
- the most simpliest, mainly for developers, who not experienced C and C Cache and BSFN development)
- just 1 extra update per record (own C cache solution also has 1 extra update)
- you have to modify the vanila APPL only at one place

Disadvantages:
- you have to turn off all Asynch BSFN execution before the update, so the user gets back the control later.

You should consider, what are your preferences:
a.) minimize Table I/O
b.) minimize user's waiting time
c.) minimize development cost
d.) minimize modifications on vanilla Objects
e.) minimize retrofitting cost after ESUs/UPDATEs in the future

I don't want to discusse pros and cons, just one aspect:

User spends 3-10 minutes to fill the form. Extra waiting time (synchonous BSFN execution) is 0,5-5 seconds. You can consider in this situation, that is it long or not (of course, this extra time can be extrame long in extrame circumtances).

You can minimize the number of extra updates, storing ang comparing previous values. Of course, this requires additinal coding.

Complex editing requirements on additional fields is an other issue.

At least, but not least - any solution have you choose (except modifying original MBFs), you have to ensure that your updates will be included in the same transaction that EndDoc MBF.

Regards,

Zoltán

 

[Sebastien Leclerc]

Re: Adding Column to P4210 Grid -- The simple and efficient way?

Good point, Zoltán... There are developpers who should'nt touch 'C' code...

So how to keep the benefits of the cache, while simplifying the whole thing???

Here is my last attempt to simplify:

We know that the Preprocessor will use whatever value we pass it to override the F42ui12 info. So why not query the cache from within E/R BEFORE calling the preprocessor?

Here is how the code would look like (please experiment and post back the results)


1- Define a local variable or a grid column for all the values you want to save.
2- BEFORE the call to the preprocessor, call GetSalesOrderDetailFromCache (I have this function available in B9. Does-it exist in Xe?).
3- Call the preprocessor

That's it!!

Isn't it simple enough

1- Pros: The function will retrieve the CACHE record if it was created. If the cache does not exist, it will get the F4211 record automatically!!! It is simple to do, simple to maintain!
2- Cons: possibly a lot of columns/variables to create...

good luck!