I agree with your comments regarding performance; the less unecessary data that has to load, the better the end user experience. I guess that there is always going to be a trade off between availability of data and performance, it is just in this case the availability of said flag would have been pretty handy!

When screens (forms) and pages (OA FWK) are designed the design team determines what data is needed to complete a flow. That flow would typically follow the 80/20 rule, ie, the majority of their user base. E.g, If I own the Oracle Projects suite, my focus will be on Project Admins, Managers, team members etc. But if another application interfaces to Oracle Projects and their users require a certain piece of information to be displayed, I may not know unless an enhancement request is made etc. My long winded point is that I will focus on the data for my product users given there is usually a certain number of columns that are displayed on the screen to save real estate.

Lastly, we need to pay attention to the size of data being returned to the user, whilst one flag is hardly enough to break the bank, the recommended guidelines to development tems that oracle does have published in one of the tech docs is around 164K and certainly not anywhere like 1MB. So adding a flag, may just add 8 bytes or so, but if you have many rows that can grow particularly if its a field thats 240 chars or so. Why? to prevent performance issues…

Whilst I agree that 95% of the time the invoice workbench is used by input clerks, there are occasions where Projects users may need to venture into Payables (even if it is in a support capacity).

I was not suggesting that the pa_addition_flag values themselves are presented in the workbench, but rather a meaningful decode of the values (again, much in the same fashion as the transfer status of CDLs in Projects). Obviously the user will still require a grasp of the integration mechanism between Projects and Payables, which is why this requirement has a select audience.

As for writing a SQL query, this is only trivial to those on the techie side of the fence. In terms of someone in a front line support role, they may wish to quickly see whether an invoice distribution has been interfaced successfully to Projects. Likewise, access to the database is not always allowed, especially on security restricted sites (which is actually what prompted me to write this blog article!).

Kind regards,
Andy.

1) The Invoice Workbench is designed to be used by input clerks who probably don’t care about whether an Invoice has interfaced to Projects or not
2) The values in the flag aren’t immediately obvious to the users as to what they mean (particularly if you are interfacing supplier invoice adjustments back)
3) It is trivial to write a report/SQL statement to get the information out of Toad.