Our initial roll-out of R/3 (version 4.0B) was confined to our Home Base so we never had this "time zone" problem. Our Phase2 however, requires us to roll-out to affiliates in two other time zones (Los Angeles and Australia) using the same SAP Client in the same Home Base Server. RESULTING PROBLEM: With our existing Client configuration, our users in L.A. and Australia defaults to our Home Base Server time zone, tediously requiring them to erase this default date and time before they can proceed with their transactions. We cannot remove the default date and time because 80% of transactions occur in the Home Base. We've done research but no luck upto this time.
We are quite unhappy that our original implementation consultants left this issue hanging in the air. We can't imagine also that a leading global solution such as SAP doesn't have an "automatic time zone translator" readily configurable.
I can sympathize with your situation. We too have deployed SAP globally and have only one single instance (home base) here in Massachusetts. Believe it or not, the solution provided to us by SAP was to deploy SAP instances throughout each of the regions/time zone locations and use ALE to synchronize master data. We could not afford this approach so we came up with an alternate solution.
We developed a Visual Basic (VB) application known to us as Production Data Collection (PDC). PDC was designed with VB as the front-end and SAP Automation in the back-end. We actually recorded the transactions specific to Production Order and Internal Order Shop Floor Control. SAP Automation allows you to create VB code that can be included into other VB applications. PDC is basically a front end to the SAP Shop Floor Control environment. When the user invokes the PDC application, they are prompted to enter three values. These are SAP logon id, password and location. Location can either be IE (Ireland), UK (United Kingdom), USE (US East Coast) or USP (US Pacific Coast). The PDC application uses the current system clock from the home base computer and then adds/subtracts time based on the Location code entered. We then post transactions to an internally created SAP ZTABLE. There are fields in the Production Order transaction tables to set Start time and Stop time but we do not publish these fields as yet. For the most part, we use the ZTABLE to calculate elapsed time on a job (Scan-in to Scan-out time) based on the Location identifier and the SAP system clock. We then feed the elapsed time to the SAP Labor Capture system (CATS) which is then fed into SAP Payroll.
So.... in short aside from finding a work around, SAP has informed us that a local install per time-zone would be required and then synchronization would be necessary.
Dig Deeper on SAP implementation and upgrades
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.