R12.2.3: New profile option to run Create Accounting in detail

Upgrading to R12 brought a lot of changes from 11.5.10.2 across every module and Receivables with the transition from needing to run the "General Ledger Transfer" report to running the "Create Accounting" report.  With R12.2.3 enough people have requested a new feature so the Create Accounting can mimic the General Ledger Transfer a bit which My Oracle Support article "How to run create accounting in detail level with no merge in R12" goes into detail in document ID 1992895.1 about the patch required and the profile option which needs to be enabled to take advantage of this development.

R12.1.2: Internet Expenses may throw Java Unparseable errors

Following a lot of what I have been doing on the blog lately, My Oracle Support document "Expenses Unparseable Date Error" from note ID 1986536.1 has yet another lesson about verifying your application changes because this issue stems from an ICX profile option which changed with the patch/upgrade.  Sure R12.1.2 is lower than R12.1.3 that I see a lot of error reports for, and it seems like most people have gone to R12.1.3 also, but there is no reason we cannot learn something from this issue by preparing for this type of change going forward so that we do not get caught out by any of these changes in the future!

Personalizing the R12 login page

Were you aware that there is a profile option value you can change in order to personalize the login page for R12?  Read MOS document "How To Remove Links From R12.X Login Page?" from note ID 1939787.1 for the details on what profile option value it is, what it needs to be, and what the page looks like when it gets updated.

Limiting your attachment size in EBS

Did you know there is a built-in profile option to limit how much space users can upload in a single attachment for your Oracle EBS application?  After reading the MOS article "How to Limit The Attachment File Size?" via note ID 604458.1 you will know about the profile option as well and can start thinking of ways to use it to limit potential abuse.

Folders: Allow Customization profile option

Today I learned something from our team about the profile option "Folders: Allow Customization" from an unusual situation!  A/P reported that they were not able to sort their Invoice Workbench in responsibilities for one organization, as they were with responsibilities in another organization, so I thought this was going to be fairly easy and straightforward but the more I looked everything seemed okay.  The same folders were created and assigned to responsibilities being used in BOTH organizations, and even to some users which weren't able to sort them either, so I was stumped.  Our project team had the solution that the profile option value for "Folders: Allow Customization" needed to be set to Yes at the responsibility level for all of the responsibilities that the users needed to use because we have "Folders: Allow Customization" set to No at the Site level so it didn't matter what the folder assignments were!

R12: Workflow Agent Listener Service logging

Yesterday I posted the what of our problem with FND_LOG_MESSAGES, but I never explained the WHY of it.  I'll rectify that right now!

In the course of our investigation we found MOS note 741087.1 which suggested that our settings for the Workflow Agent Listener Service were set wrong.  Guess what?  They were!  This note is good to review as well to confirm the settings are correct for the FND: Debug Log profile options in your EBS application.

R12: Data changes in gv$session colums

I've posted several articles using gv$session to do different things (finding RMAN or CM holding a report lock), but imagine our surprise when development needed to retrofit a script for us based on gv$session with MODULE and ACTION no longer displaying the correct information!  Luckily enough for us, they also found MOS Note ID 1359998.1 which addressed the changes in the table to these columns AND that it requires the Profile Option FND_CONNECTION_TAGGING to be set to Enabled as well in the EBS application.

R12: MO Operating Unit

With changes in R12, it is possible to change your setup from using the profile option "MO: Operating Unit" to start using the profile option "MO: Default Operating Unit".  While that isn't horrible, it does mean that you have to go through your entire system to scour out the old profile option from all responsibility setup and the hard coded details in reports.  This is because if you do not complete this task it is entirely possible to miss something so when you try to run a report it errors out, or if you have some type of audit or alerts run based on MO: Operating Unit when run they will not give you the type of results you're expecting.

This is yet another small piece of advice for a running R12 checklist that I seem to have been building here over the last few months.  :}

Unauthenticated setting of a profile value

You read the title right.  Oracle has documented in My Oracle Support note 364503.1 how you can set a profile value without being authenticated to the EBS application at all.  Sure, it is supposed to be used in an emergency manner and only for those that want to go and do some good or fix their systems.  What if it is used by individuals that don't exactly have good things in mind?  Would it be possible for somebody to get an authenticated database session, maybe using other things I talk about during Security Week, to your system and then really start to take over your EBS application?  Maybe they don't even try to take over your EBS system, but just start to collect usernames and passwords by changing something like where your authentication system directs to which can then be leveraged for more sensitive systems that you might have.

Of course if they get a authenticated database session with enough privileges it might make this a moot point, but if you visit that note you might find out a new way of setting your profile values at least!

APPLSYSPUB security - Part 2

Following up my first article on securing the APPLSYSPUB account, is this new article which tells you yet another place the password is hidden in your system and Oracle will ask you for it.  When the report Diagnostics: Apps Check (OMCHECK.sql) is run with the parameter of Application Object Library it will find all of the associated Profile Option Values for the Application Object Library module, which doesn't seem like a bad thing unless you realize that it will list the value for the profile option "Gateway User ID".

Not only does this profile option value have the username/password combination for APPLSYSPUB hard coded, but the Diagnostics: Apps Check report has no further security validation built into it so once it is available to a responsibility it is available to run for ANY module.  Ever have to add this to a responsibility to give Oracle some data?  Did you make sure to remove it?  Do you know who is running this in your system?

Application cookie value

Recently we cloned our PROD environment back into TEST, and were going through the checklist to reintegrate everything when we encountered a problem.  The cookie value for the application was still showing PROD, even though we had cloned it onto the TEST database so we knew it had to be some type of configuration value but we didn't know exactly what it was.  Doing a quick search of the profile options showed that the value for "Applications Database ID" had the PROD database name in it which isn't the way it should be in TEST!  We changed it to what it should be for TEST, but nothing changed so we bounced Apache and then we had the correct cookie value being returned!