PA_ADDITION_FLAG not shown in Payables invoice distributions form
As a Projects user, an annoyance that I continue to encounter with Payables is that the pa_addition_flag is not shown as a column for Payables invoice distributions. The pa_addition_flag shows the status of Projects-coded invoice distributions, and among other things, indicates whether an invoice distribution has interfaced successfully to/from Projects. Therefore, if this flag were shown in the form, it would be immediately useful for functional Projects users trying to reconcile discrepancies with Payables. I was hoping that this flag would appear in R12.1.1, alas it has not.
For more information on the pa_addition_flag and for the meanings of the values it holds please refer to Metalink note 226881.1
The odd thing is that the pa_addition_flag is held in the form, and can be accessed using Diagnostics -> Examine. The problem with this workaround is that it is not possible to access Diagnostics on some restrictive sites, as is the case with database access.
The equivalent indicator in Projects is the “transfer status” flag, which is held against cost distribution lines. Rather more helpfully, the transer status flag is indeed shown in the application.
Does anyone else find this annoying, and more importantly, has anyone logged an enhancement request?
Surely the reasons why it aren’t included on the screen are
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.
Hi Rob, many thanks for your comments.
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.
I’ve not had a chance to look at the Invoice Workbench and one could argue that perhaps I should not be commenting! But, given its in ‘professional’ forms (I find this term annoying!) isn’t it possible to personalize the form and just add the column?
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…
The form can not be personalised to add the column, it would need to be customised. It is not really worth the risk and potential furture implications of a customisation for such a small requirement such as this.
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!