Last updated on AUGUST 30, 2016
Applies to:Oracle Fusion Applications Common Components Cloud Service - Version 126.96.36.199.0 and later
Oracle Fusion Applications Common Components - Version 188.8.131.52.0 and later
Information in this document applies to any platform.
On : 184.108.40.206.0 version, Implement Applications-Migrate Application Setup
Implement Applications-Migrate Application Setup
FSM Import: Work Shifts fails with decimal value error.
Using FSM export / import functionality to migrate Work Shifts records from one Rel8 GA environment to another.
The import process is failing and reporting this error for 60 of the 89 Work Shift records.
"JBO-25026: Row oracle.jbo.Key[300000017956084 ] with XML tag ShiftVORow cannot be loaded.JBO-ZMM:::ZMM_SCHED_SHIFT_DURAT_DECIMAL:
You cannot enter decimal values for a shift duration in a time measure other than hours.
For a shift duration in hours, you can use up to two decimal places.
For example: 9.25 Hours.
JBO-27024: Failed to validate a row with key oracle.jbo.Key[300000017956084 ] in ShiftEOJBO-FND:::FND_CMN_REQ_ATTRIB_API_SERV:
You must provide a value for the attribute Type.
The issue can be reproduced at will with the following steps:
1. Created a configuration package for "Manage Work Shifts".
2. Create Elapsed shift with decimal hour value(1.6, 1.68 etc) for duration.
3. Exported the package.
4. Verified that DurationNumTransient field is NOT displayed in the ZMM_SR_SHIFT.xml in the exported configuration package.
5. Cannot Import the same configuration package
6. None of the Work Shifts were entered with more than 2 decimal places when they were manually created in the source environment,
but when I look at the data in the configuration package XML record the value is showing to 22 Decimal Places.
One example is as follows:
Work Shift Name : 1.68_Elapsed_Shift
Duration UOM: Hours
In the configuration package the 1.68 hours is shown as 1.6800000667572021484375.
From looking @ the base table ZMM_SR_SHIFTS_B,
the duration is held in milliseconds and the FSM export process is calculating the value in the UOM (Hours)
but is not applying the same rounding logic that is enforced by the Manage Work Shifts UI
The issue has the following business impact:
Client wants to use FSM to manage configuration changes from a source env to a number
of target environments in order to reduce mitigate the risk of mistakes in configuration.
This error is preventing them from using FSM to manage change in Work Shift data.
This problem occurs in a Data Conversion environment that has to be kept in line with
GOLD env in other to ensure the latest configuration is in place.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms