saving additional sale order information


VIP Member
There is a new business requirement to save some additional information about the F3211 into the F4211. Specifically when someone has a Y/N in a certain segment, they want that information at a glance and be QBE searchable, and not in a report or looking into the configurator.

I know how to query F3211 and determine what I need. I'm looking for suggestions/best practices in this situation.

As I see it I have 2 options

1) store the information in the F4211 user defined fields, modify V4211A to include those fields, and add those field to the P4210 form (probably P42101 too)
2) store the information in a new table (I believe, commonly refereed to as a tag file), create a new bsvw/form for inquiry.

My worry about number 1 is
1.a) what else will be affected by modifying the bsvw
1.b) what else are they gonna want added to it and i'm going to run out of user defined fields

My worry about number 2 is
2.a)Data available form new form that NOT available from P4210/P42101
2.b)What type of P4210 functionality am I going to duplicate (i'm thinking row/form exits)

please weigh in professionals


Legendary Poster
1. Adding data to user def fields (URAB, URAT, etc.) in F4211 is probably preferable if they are not currently being used. Simply adding these fields to any Business views that all ready have F4211 and/or F42119 poses virtually no risk at all. Additionally they will still be searchable by the business view that P42101 and P4210 use which is actually a union of F4211 and F42119 when you add these fields to those views.

2. We have F4201/F4211 tag tables since we ran out of F4211 user def fields years ago. Downside to this is that you can't join to these tables in the views used in P42101 and P4210 because like I mentioned before, these views are unions. Subsequently our tag table data is not easily searchable by default (no QBE in P42101 for example). Other than that it works great. We have "tag" cache that goes along with UI11/UI12 and when F4211FSEndDoc saves the cache contents to tables it writes our "tag" cache as well. You just have to be sure and make provisions in the SOE MBF to handle callers that might not implement your mods. In other words for us most applications we use that edit sales orders call both F4211FSEditLine and AcmeF4211EditLine. But we have to make sure that applications that only call F4211FSEditLine don't break, which if done carefully, is not a problem (writing default values if tag cache is not present, loading tag cache from tables for existing orders, etc.)


Legendary Poster
There is a 3rd (kinda sucky) option.

Go ahead and add your Y/N field to the P4210 Grid as a DD Item (not in view) with QBE enabled.

In either Grid Row Fetched or Before Grid Row write event add your own filtering logic:
Retrieve F3211 value into Grid Column
If a QBE Entry exists for the field then:
- If the F3211 value <> QBE value then Suppress Grid Row

The above is sucky because its potentially slow. However its only significantly slower if User uses that field to filter on AND query result set is quite large.
User also cannot use <, >, !=, *, etc. Advanced Query also would be unavailable.
But if its just a Y/N field then I think that's the approach I would use.

Last edited:


Legendary Poster
I have this in my work place too.

We also have a 'zero mod' policy where possible, so I was a bit stuck.

Instead of touching P4210 etc I just have a P554210 which is just a simple find browse form (I add extra tables to it's BSVW or do grid record is fetched ER to add extra fields not already there - shipment info, tag files etc) and it has a load of row exits that enable DB update.

At the bottom of the form I have a small strip with multiple tabs with a load of FC DD items in it. Here the users add what they want to update, select the grid rows and click the row exit to loop and update as needed.

This approach allows me to add what I want going forward without much of an impact as it's all custom.
It has different versions which hide/show many of these fields