Preventive Maintenance Engine Generates Service Requests with the Same Commit Time Hour No Matter When PM Runs
Last updated on MAY 07, 2018
Applies to:Siebel Field Service - Version 16.17 [IP2016] and later
Information in this document applies to any platform.
On : 16.17 [IP2016] version, Field Service
When Preventive Maintenance Engine generates service requests from service request templates the Commit time is set to the trigger date, but the time is set to the same value no matter what time PME is run. ( e.g. 3 PM)
This value seems to depend or is influenced by Default Time Zone system preference.
When there are users on more time zones, the commit time will appear on the second day due to time zone difference.
e.g. SR with Commit Time = 1 May 2018 03:00 PM (GMT) , for AUS with +10 UTC offset it looks like 01:00 AM next day.
Preventive Maintenance engine should generate Service Request on 1st day in the month no matter what users runs the PM
Steps to reproduce on standard SRF:
1) Login to the Siebel (Field Service).
2) Create SR Template from Administration Service -> Service request templates
3) If necessary create a product trackable as asset ( from Administration product -> products) and create an assed based on this product in Assets screen
4) Navigate to Preventive Maintenance screen and create PM plan Add a trigger on 06/01/2018 (1st of June ), add created SR Template, add the product created in step 3 and check All Asset flag.
5) Navigate to Agreements and create Agreement with End Date > 06/01/2018
6) Drill down on the agreement and select entitlement sub view. Create an entitlement
7 ) On the entitlement , select Products sub view and add the asset created in step 3
8) On the entitlement, select Preventive maintenance sub view and add created PM Plan ( make sure is Active)
9) From Agreement>Entitlement>Preventive Maintenance, select End Date = 06/01/2018 and click "Run PM"
10) Check the Committed field for the service request created ( In Service -> Service request list)
11) Repeat the all test at another time in the day: the Comitted time is the same as the one created in step 10
The issue has the following business impact:
Due to this behavior user cannot control the Commit time hour, and for users on different time zone the Committed field can be on the next day when the trigger run ( e.g 06/02/2018 instead of 06/01/2018)
Current behavior also affects services planned on the last day of agreement: in this case for AUS users last SR will not be created.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms