Oracle E-Business Suite Blog

Okay, so unfortunately, our SRs have not progressed has hoped.

 The SR dealing with Project Name and Task Name not appearing on the timecard has officially come full circle to repeating the white paper doc enhancement and being told that it is fixed in 12.1.1.  Understood - but it is still not working in 12.1.1.  Again, not a show stopper, but a nice to have and an enhancement that many have asked for in the past. 

 **Last update: Thank you for your last update. I think that the post install steps were followed. This issue was not reported till now by any other customers that have upgraded their instances to R12.1.1**

Contingent worker time is still not transferring to Projects.  We have run many diagnostics and scripts, but not much progress yet.  Initially, advised that and OTL Preference was set incorrectly; however, we have verified it is set the exact same as in Production where time transfers effectively.  I have asked to have this SR escalated as this will prevent us from successfully upgrading.

Our last SR refers to closing all projects and recreating with the new Project Type of contingent worker enabled.  This is still 'Awaiting Internal Response'.  I have asked for updates on the status and to have this issue escalated.  Their initial response what this is standard functionality for all Project Enhancements, so we shall see...

 

Comment (0)

Some things there are just no explanation for and this is one of them.

 When we first started testing in Iteration 1, I opened an SR because when creating a NACHA payment run, we came across this error:

Payments cannot be marked complete because an error was returned by the callout AP_PMT_CALLOUT_PKG.payments_completed.

I opened an SR and gave Oracle Support all the necessary documentation from that run, outputs, diagnostics, etc.  They came back and wanted me to retest the payment run in debug mode.  Wouldn't you know that when I went to retest again, twice, that everything worked flawlessly, no errors.  So, since we can't reproduce and the error is no longer an issue, I have closed the SR.

The third SR, that has been open since we upgraded to R12, is still an issue.  We had hoped it would be fixed with R12.1, but that is not the case.  This issue has to do with random lines on our NACHA output being off by .01.  Sometimes, the total is off by a penny as well, but most often not.  Oracle support is closing down our existing R12 SR regarding this issue and reopening one for the same issue in R12.1.  It would definitely be nice to get this issue resolved!

Comment (0)

Unfortunately, our Projects SRs are not progressing as hoped.  Oracle has closed one, based on the question of 'what the contingent worker enhancement is' has been answered and the issues with it are being worked in the other SRs.

 The SR that refers to the project and task appearing in OTL as an enhancement has thanked me for my patience as development continues to investigate.  This is not a 'show stopper', but a nice to have and one that was specifically noted as an enhancement, so I will continue to work with Oracle for a resolution.

The SR that requests a work-around has gone around in a circle and I think we are finally at a point where Oracle is understanding the inability to Enable Contingent Worker function at the Project Type and have it propogate to all existing Projects is a problem and the clarification that we do not use POs is now being considered. 

I asked for an update this morning and got the following response: Development has responded as follows:
>> Flipping of this checkbox effects only projects created thereafter.

I responded: Yes, we understand that. We are looking for an alternative to having to close our existing projects and recreate them with the box enable for the project type.  Having to close and recreate all our projects that currently allow contingent workers to bill time in our 12.0.6 instance is not feasiable.  In order for us to upgrade, we need an alternative workaround for this enhancement. We understand all our new projects going forward should be okay, as long as we update the Project Type. Our issue is with existing projects that are being updated.

Oracle responded: Regarding your issue with existing projects, I believe it is being worked on in a separate SR

I responded: That SR is for contingent worker time not transferring to projects at all, regardless of new or old project type.

I have been told by Oracle that inorder for contingent workers to bill to an existing project after upgrading to R12.1, we need to close those projects and recreate them under the new project type with contingent worker enabled. This is what I need a work around for. To close and recreate all our projects that allow contingent workers to bill time is not feasible.

In our current 12.0.6, contingent worker time successfully transfers to projects for many different projects under our existing Project Types. After upgrading, this functionality has been lost and we have been told in order to continue with this functionality we would have to close and recreate. Please let me know if you need any further details.

Bit repetative, but the request has been sent back to development and they are working on it.......and we are 'Awaiting Internal Response'.

The last SR is being actively worked by Oracle.  I have just sent them a bunch of test files, log files, and trace files to review and assist with the issue of Contingent Worker time not transferring to Projects regardless of if the Contingent Worker Enabled function is selected at the project type level or not.  This issue is for upgraded and newly created contingent workers and projects.  I should have some feedback on this one by Wednesday.

Comment (0)

After some additional testing, the Entitlement Balances functionality is working fine.  One of our testers discovered note 473272.1 on Metalink which appeared to be similar to our problem.  The issue was resolved by extending our payroll calendar out by another two years. Oracle has logged Bug 5743838 in which part of this issue is described.

The screen shot below show a successful calculation in June 2010 after the extension of the payroll calendar.

Comment (0)

Okay, so unfortunately I do not have great updates yet...2 of the 3 SRs are still "Awaiting Internal Response".  These are the two requesting a different fix to closing all current projects and recreating them under the new Project Type with "contingent worker enabled".

 The third SR has also not made much progress (this is the one referring to Contingent Worker timecards not importing to Projects).  Here is the last correspondance we had:

1. Do you have 'Contingent Worker Enabled' selected for project type?
Yes. I have submitted timecards for existing project that were upgraded and I have submitted timecards for new projects with the contingent worker enabled selected. However, I have another SR opened to see if we can get Project Type to progate to all our projects.

2. In implementation options do you have 'Import Contingent Worker Timecards with Purchase Order Integration' selected?
This is an upgrade. In our current instance contingent workers are able to submit timecards and they upgrade fine. We do not use Purchase Orders, so this is not selected.

I'll keep you posted on any furhter progress.

 

 

 

Comment (0)

  Release 12.1 includes a useful addition to Absence Management. Employees and Managers can now use Self Service to calculate leave accruals based on an effective date. The new tab in the Absence Management function, named "Entitlement Balances", is shown below.

A user simply inputs the desired date and hits the "Go" button.  The accrual is calculated as of the date entered.  This is useful for both employees and managers wishing to view accrual balances on a given date.

This new functionality appears to work well within the current plan year.  Curious to see what would happen if I entered a date in the next year, I tried 01-Jan-2010.  I immediately received an error indicating a problem with a user defined function in the accrual formula "PTO_PAYROLL_CALCULATION". We'll have to take a closer look at this to see what is happening.  I would fully expect someone to try a date far into the future, so we'll need a more graceful ending than a framework error page.

Even with that small issue, the new Entitlement Balances functionality looks like a useful addition to both Employee and Manager Self Service.

Comment (2)

We have successfully resolved the Payment Document issue.  Thankfully it was a fairly easy fix.  We simply had to remove the documents from the setup and add them back in.  Why?  Can't explain, but it seems to have fixed the issue and I was able to complete a printed check run with no issues.

I've entered numerous expense reports to retest the two NACHA issues in Iteration 1.  I'm having to rerun the processes for NACHA runs in debug mode to get Oracle the data they need for the flagged completion issue.  I'll also be testing the penny issue with the same data.

 I'll keep you posted as we progress.

Comment (0)

There has been a lot of back and forth between our DBA's and Oracle Support overnight, but so far, we are not much closer to a resolution.  Our initial problem was escalated to development and a bug was logged ( Bug 8553240 ). After our OWC session with development, Oracle sent us a file to place in the Class Path of our test instance.  The idea is that the supplied file will create extra debug statements to help track down the issue.  Unfortunately, the supplied file has not so far generated any information.

Luckily, our DBA's have been working closely with our internal Java developers and have passed some suggestions back to Oracle.  We are now waiting for Oracle Development to supply a new Java class file incorporating some of those suggestions.

Comment (0)

I am pleased to announce that I have worked through most of the Payroll issues that I encountered in my first pass of testing.  The fact that the data was scrambled had no impact on my testing afterall.  What happened early on is that some of my testing failed with the following error message: 
APP-FND-00314: Invalid printer ( noprint ) and print style ( USLWPORTRAIT) combination. 

The failure of these tests impacts the rest of testing as they are sequential.  I found the following solution in Metalink:  

Solution

To implement the solution, please execute below steps:

1. Copy the INLOC_P.prt from $JA_TOP/IN60105D2 directory to $FND_TOP/reports directory.

2. Navigate to "Install -> Printer -> Register" under system administrator responsibility and query for all printers installed at your site.

3. For each printer installed, check the type and click on "Printer Types"button and query for all printer types.

4. Add a new record under printer drivers with "INLOC_BACS" as style and "INLOC_AT_EFT" as driver name and save the record.

5.Bounce the Concurrent Manager after this step for the changes to take effect.

However, for testing purposes (I did not need to print) I did the following:

 

 

You may find that you will need to follow these steps a few times in the process of testing.  I am now able to run the tests and continue with the next steps.

*************************** 

I have one outstanding issue for Payroll remaining.  It is when I run the GRE Total Reports program.  I am getting the following error: 

MSG-00001: tmp002:
REP-1401: 'cf_1formula': Fatal PL/SQL error occurred.
ORA-01422: exact fetch returns more than requested number of rows

REP-0069: Internal error
REP-57054: In-process job terminated:Terminated with error:
REP-1401: MSG-00001: tmp002:
REP-1401: 'cf_1formula': Fatal PL/SQL error occurred.
ORA-01422: exact fetch returns more than requested number of rows

 I found the following information on Metalink:

Subject:	Error Running GRE Totals Report REP-1401 and ORA-1422
	Doc ID:	152461.1	Type:	PROBLEM
	Modified Date:	23-MAY-2009	Status:	PUBLISHED

  
fact: Oracle Payroll 11.5.3 
fact: PAYUSTOT - GRE Totals Report 
symptom: GRE Totals Report fails 
symptom: ERR REP-1401: 'cf_1formula': Fatal PL/SQL error occurred 
symptom: ORA-01422 : Exact fetch returns more than the requested number of  rows 
symptom: GRE Totals report completes successfully for other GREs 
change: NOTE ROLE:  Troubleshooting Step:  Here is the formula function for CF_1Formula: function CF_1Formula return VARCHAR2 is begin   declare  l_sui_ein    varchar2(20); begin  select  sein.org_information3 into    l_sui_ein from    hr_organization_information   sein where   sein.organization_id                   = :gre_id and     sein.org_information1  = :state and     sein.org_information_context           = 'State Tax Rules';  A simple select, the ORA-1422 indicates the system found two rows that met this  criteria. 
cause: A duplicate state tax rule was entered in the GRE State Tax Rules  set up.  
  fix:  Delete the duplicate State Tax record  US HRMS Manager (or similar responsibility) --> Work Structures -->  Organization --> Description - Find the organization defined as your GRE   Arrow down to the Organization Classification = GRE/Legal Entity --> OTHERS   Select State Tax Rules from the list   Inspect the rows returned for a duplicate state code (first two characters)   Delete the duplicate row using the red "X" from the toolbar 

 

I followed the instructions and found the duplicate state tax rule.  I removed one and reran the program with success.  This closes out all my payroll issues.  None of the issues I encountered seem to be a result of the upgrade.

Comment (0)

Well - so far testing is going so so.  I've had no issues in most of the modules I've been testing.   AR, Advanced Collections, FA, GL and iExpense have gone alright. 

The thorn in my side right now is AP.  Right now, I've got two current SR's open, both have to do with payments, which obviously would be a show stopper for go live. 

The first issue I have is with NACHA payments.  The process itself is going okay, however, in the output from the Format Payments report there is an error at the bottom stating:

Payments cannot be marked complete because an error was returned by the callout AP_PMT_CALLOUT_PKG.payments_completed.

 I've updated the SR with multiple diagnostics that I've ran on our system, so we'll see what Oracle has to say.

 The second issue is with the Created Printed Payment Instructions process.  On step 2 in the process, when selecting the Payment Process Profile of Standard Check Format, I end up with no LOV in the Payment Document field which is a required field. 

I've check the Payment Process Profile setup under Payment Administrator and everything is setup correctly.  So in theory, I should have 2 values in that field.  After updating the SR with some diagnostics and some screenshots, I'm waiting on Oracle.

On top of those two issues, we are hoping that our long standing issue with NACHA payments is resolved with the R12.1 upgrade.  This has to do with all our NACHA payments being off by a penny.  Causing us to have to manually manipulate the file we send to the bank.  Jessica opened this SR when we upgraded to R12 April 2008.

 

Comment (0)