vLMS Document updates with UTC dates issue

[rorennie]

Hi All,

We are having issues where our external Document management system is interfacing with vLMS, this integration works just fine with all documents whether they are new, up versioned or marked as obsolete are all being received into iContent via the Item Connector file.

The issue we have is that all our documents are dated and time stamped in AEST (Australian Eastern Standard Time), the item connector is running based on UTC time zone which is -10hrs, resulting in some instances where the Required by Date is calculated wrongly (depending on time of the job run).

Example:

Item connector Job executed at 8.05am AEST on 1/09/2021  for a document which has a Required by date based on INIT filed being 7 days, this should have resulted in the required by Date being the 8/09/2021 (taking into consideration that the current period always has to end before the count starts), however, due to the db setting being UTC this meant that the system reads this as 10.05pm UTC on the 31/08/2021 resulting in the Required by Dates being wrongly calculated as the 7/08/2021. This despite local timezone setting in LMS etc being set as AEST.

Has anyone suffered any such errors and how did you overcome them, my personal opinion is that this is an oversight and should be corrected to local timezones

Thanks

bob

[Maria_Consiglia]

Hi Bob,

we built an interface between our document management system and VLMS using the Item Connector. Our solution has been to transform the date and hour in UTC to build the correct file to import.

I hope our experience will be useful to you.

[rorennie]

Hi Maria/Mary Katherine,

The file import all seems to be ok, the date and timestamps all seem to align (these are in UTC), our issue is with the clash between the effective date on the PDF for the SOP/WI/POL documents and the LMS Required by Date.

All documents originate from our DMS, the PDF details exactly when documents are approved and are awaiting release for use in the LMS system, which on average is 20 days before the Documents Effective Date and all are based on AEST.

In our middleware we calculate the number of days between today's date ( the extract date from DMS) and the documents effective date, this populates the INIT field on the item connector (this is because a revision date cannot be based on a future date in LMS), several other metadata fields like ID, title, revision numbers are all populated in the item connector file and then await the next run.

We would like to pick up and run all documents through before normal business hours start i.e. before 8am, this is the exact point we have the issue as the connector file runs and populates the INIT days thinking that it is the previous day (10pm UTC) and produces a Required by Date which is a day earlier than expected, all other dates such as the Revision date etc are all good.

We have along with our implementation partner reviewed all settings (that we know of) but cannot seem to get to where we need too which is to ensure the same dates are populating in LMS curricula as are in the actual PDF, our quality department are not willing to accept the discrepancies as this is where our compliance reporting comes into play.

I know the post is very similar to last night, just thought I would detail out a few more steps to see if triggered any other thoughts. it could well be that this is just an anomaly, but I would have thought that the system capability would have overcome such issues.

[MaryKatherineJ]

@rorennie Bob, thanks for explaining in more detail. To paraphrase for my own confirmation, your middleware calculates the INIT days value based on the document's extraction date (today) and the document's effective date (a future date), but due to the time of day that your connector is running (e.g. 8:00 AM AEST time today, which is 10:00 PM UTC yesterday), the Required Date is getting shorted by one day so that it does not match the intended Document Effective Date. If this is the case, you might want to consider using a very low-tech tactic of changing your middleware calculation of the INIT days value to, literally, add 1 to the result. As long as your connector gets run before 12:00 AM UTC, the (effective date - extraction date + 1) calculation would compensate for the timezone difference. Admittedly, however, this strategy might be undesirable if you need to manually run your item connector file later in the day for some reason (e.g. if the connector rejected a record or failed to execute as expected). But if you are manually re-running an archived item connector file, you can take manual steps to "fix" the INIT value in the file before you run it, or you can use Required Dates Editor to "fix" the Required Dates after you run it. Valid choices, even if they are not good ones.
     I understand the dilemma you are facing with your quality department not being willing to accept the discrepancies with the dates due to the impact on compliance reporting. Perhaps they would be more inclined to accept the +1 change to the calculation to compensate? If this strategy gives the desire Required Dates and your connector is able to run before 12:00 AM UTC time 80% of the time or better, it might be less painful than what you are currently dealing with.

You are in a tough spot. Good luck!

Mary Katherine

[rorennie]

@mary katherine johnson Many thanks once again for the comprehensive response to the issues we are facing, you clearly understand the issue and to be honest with you, we have gone through the options you have outlined and whilst I like the idea of adding +1 to the calculation based on timing we did have issues when the file was not picked up or was rejected.

In short our conclusions are pretty much aligned, we plan to run all jobs between 10am and 11.59pm AEST this allows for all calculations to take place and provides the correct INIT days, therefore the Required by Date is aligned, should the learning administrators need to run outside of this window i.e. before 10am AEST, the process is to then ensure that the item connector file is updated or fix the Item with the Required Dates Editor (just as you have pointed out).

Thanks once again for assisting in confirming that this is indeed a standard system behaviour and that we have not missed any settings along the way. 

Regards

Bob

[jorgecampos]

Hi,

When we migrated to Validated Learning from on-premise our SuccessFactors consultants added the setting item.connector.defaultValue.timezone to our CONNECTOR configuration file.

[Alan_Yang]

Hi Bob,

Can you provide some clarification? I am assuming that the initial required by date is based on the timestamp of when it is assigned, are you experiencing this issue specifically when a document is revised and automatically assigned? I would think that the required by date should take into account time zone. Have you tried to manually revise  an Item via the admin interface using the same parameters (ex. revise at 8.05am AEST) to see if the system exhibits the same behavior? If it does calculate the required date correctly then I would think this is a bug in the Item Connector and should be addressed by SAP. 

[rorennie]

Hi,

Yes, when the item is assigned to the user the INIT days drive the Required by Date from that day onwards, will double check with the team on the manual update.

Mary Katherine has given me some options to check out and I will look into these and report back after investigation, thanks for your response 

Regards

Bob

[MaryKatherineJ]

@rorennie, I think you are dealing with two separate but related issues. First, you are correct that all LMS environments are now configured with a standard database time zone of Coordinated UTC time. And like Maria Consiglia said, when we implemented the item connector, we chose to use a third-party middleware tool (e.g. Dell Boomi) to transform the document revision data from our document management system into the text file format with the appropriate headers required by the LMS. As part of the configuration of the middleware integration, we coded our middleware to transform the revision date and time provided by the document management system from US/Eastern time zone to UTC time zone. When the item connector runs, the LMS creates the item using the UTC date and time.

      The second issue you are facing is that your company's preferred time zone for Required Date is different from the default database UTC time zone. We have this same issue. In our environment, each user is assigned a Preferred Time zone based on their physical work location. The user's preferred time zone is set in the SuccessFactors BizX Platform module and passed to the LMS through the LMS SF User connector. In addition, each of our LMS Administrators has their Administrator preferred time zone set to reflect the geographic region that they support. For example, my personal user time zone might be US/Central while my LMS admin time zone might be US/Eastern. In this example, when I run reports as an LMS admin, the dates will often display in US/Eastern because that is the preferred time zone set on my admin record. (Please note that time zone display behavior will vary by report.)

        As for the behavior of the Required Date, when an admin views a user's Assign Items tab, they will see a message explaining the following: "The Required Date is in [the user's preferred] time zone, Assignment Date is in Coordinated Universal Time time zone and Completion/Failure Date is in [the admin record] time zone." So with your scenario, if the Required Dates are not showing the date you expect, look closely at the user's preferred time zone vs. the admin's preferred admin time zone. If both the user and the admin have their time zones set to AEST, and if AEST is 10 hours ahead of UTC, then users and admins will often see the Required Date as one day earlier than the date displayed in UTC time zone. I don't think this is an LMS bug, but more a fluke of time zone translations. Perhaps find a test user and change the user's preferred time zone to UTC to see if the Required Date displays closer to what you would prefer. Try the same change with the time zone on your admin account and see if the Require Dates change for you.

      We have a similar issue in reverse: UTC is currently 6 hours ahead of the time zone at our corporate location. My strategy: Any time I am running a User Compliance report (the one that shows if training was completed On Time or Overdue), I will set my admin time zone to UTC. Making that change causes the report to display both Completion Date and Required Date in the same time zone so there is no ambiguity as to whether the training was completed before or after the Required Date.

Hope this helps,
Mary Katherine

[rorennie]

Hi Mary Katherine,

Thanks for the detailed response to our issue, I will have the team have a closer look at the settings to see if there are indeed changes that can be made, we have thought that somewhere we may have a missing entry to do with time zones, appreciate the time and effort taken to compile your response. Will update after investigation.

Regards

Bob