Materials Control. Daily Totals. Product Version Daily Totals. Document Title: Joerg Trommeschlaeger

Transcription

1 MICROS Product Version : : : Date: Version No. of Document: 1.7

2 Copyright 2015, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government. This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle. Page 2 of 36

3 Table of Contents INTRODUCTION 4 PRE-REQUISITES:... 5 APPLICATION VERSION:... 5 HARDWARE:... 5 RDBMS:... 5 CUSTOMIZATION:... 5 NEW DATABASE:... 6 PREPARATION:... 6 ACTIVATION:... 6 REQUIRED SCHEDULED JOBS: EXISTING DATABASE WITHOUT DTTLS: PREPARATION: FIND OUT SYSTEM START DATE: HISTORY REBUILD: ACTIVATION: REQUIRED SCHEDULED JOBS: EXISTING DATABASE WITH DTTLS: PREPARATION: IF DB VERSION < 11.05: IF DB VERSION > 11.05: FIND OUT SYSTEM START DATE: HISTORY REBUILD: REQUIRED SCHEDULED JOBS: DTTL CHECK AT INVENTORY: Page 3 of 36

4 Introduction This document describes the preparation of a MICROS database to work with. When using the concept, the system records several information per article per day per cost center. This allows to find out e.g. the exact stock on hand for a specific article at any date in the past including the correct average price information at this day. It also allows the correction of any document on a past date within the current inventory period including (batch) recalculation of all following transfer and production documents. Corrections in closed inventory periods are not allowed. NOTE: It needs to be considered that this function cannot be switched off anymore after activation! It is not possible to switch this function on for a testing period only and then return to the standard calculation mode afterwards! It is very important to follow strictly the guidelines below. Otherwise the correctness and consistency of data cannot be ensured and a new installation might be required! Page 4 of 36

5 Pre-requisites: The use of (DTTLs) has several advantages. But some points must be considered before activating this function. Application Version: The minimum required version of is , but it is strongly recommended always to use the latest released version with the most actual patch. NOTE: Depending on the existing database, the Update might not be the first step! Please read the detailed explanations below first! Hardware: This functionality requires higher hardware resources on the server side. - It is strongly recommended to use a dedicated server for only. o There are several jobs to be executed on a regular basis which will strain the server heavily. - The server should have at least a dual core processor. - The available RAM should be increased significantly, recommended minimum value is 4GB. - The database will grow massively. Make sure that enough disc space is available. When using DTTLs a database growth of several GB per year is possible! This depends on the number of booked transactions. RDBMS: - can be used on Oracle databases only. This function is not available on Centura SQLBase. - It is strongly recommended to use the most actual version of Oracle which released for use with. - Make sure that the table spaces assigned to the database are well sized! o The AutoExtend function should be considered! Customization: Customized reports, views and functions may need to be adjusted. The database table LAGER is no longer the main container for SOH and pricing information per cost center. This table is now updated through a scheduled job only. All customized functions must be adjusted to read data either from the table DAILYTOTALS or from the view V_MI_DAILY_TOTALS (contains less information!) Page 5 of 36

6 New Database: Preparation: The procedure for a new installation is very simple and will take some minutes only. Log in into and go to System > Database Update: Update the database and application to the latest version. Create a backup of the database and copy it to a save place. Activation: Make sure that no user is working in. Log in into. Go to System > Configuration: In the folder [NAMES] the hidden parameter SysDaily_Time can be found: Enter here the start date of the system in the format YYYY-MM-DD-HHHH-MI-SS., e.g for March 25 th 2013 at 01:05:27pm. It represents the booking date & time of the last checked transaction. This date will be checked and used as start date for the job Recalculation of COS from Documents. This date will be updated always once the system has successfully recalculated documents booked on older document dates. (It will not be updated with every execution!). NOTE: After this first time, do not edit this field unless clearly advised by MF EAME Support Team! Page 6 of 36

7 Go to System > Database Update: Switch to the tab Settings : Click on the button System Settings : NOTE: Do not use any other option in this dialog without clear advice/confirmation from the Product Management! Page 7 of 36

8 Activate the checkbox and select the required calculation method. - Last Price (not yet supported for and must not be used!) - Average Price - Standard Price (not yet supported for and must not be used!) Click on OK. A warning message will be displayed. Confirm with Yes to proceed. Now the system needs to execute a database reorganization since the stored procedures will be changed. Confirm with Yes and the system will start this process immediately. Page 8 of 36

9 After completion of the Reorganization the system is using the calculation method. Page 9 of 36

10 Required scheduled Jobs: There are several jobs which must be executed for on a daily basis. The jobs should be executed in the sequence as listed below! 1. Recalculation of COS from Documents This job recalculates documents to use the correct prices after doing corrections in the past. ATTENTION: This job could run several hours! This job must not be executed if the calculation method Last Price was selected. 2. Recalculation of This job updates the current and also Table LAGER (NAMES -> SysDailyRecalcUpdLager must be set!). o Keep in mind that table LAGER is updated only after execution of this job. Customized reports based on table LAGER might show outdated information! 3. Refresh COS of Recipes This job recalculates the COS of the Recipe Headers and Products. All other jobs like Import Sales, Transfer on Sales, etc. must run AFTER the jobs above! At least once a month we recommend to schedule the following job: 4. Update Oracle Statistics This job updates the Statistics of your Oracle Database to speed up the system. o Depending on the number of transactions it could be useful to execute this in shorter sequences. Page 10 of 36

11 Existing Database without DTTLs: This chapter will explain the preparation of the database for existing, running properties for the use of. It needs to be considered that the average prices for several articles might/will be changed, because the prices will be recalculated and backdated transactions will cause a recalculation of later booked documents. This is not the case when working without DTTLs! Depending on the size of the database the procedure described below can take several days. Some parts of the preparation process could run besides the normal operation, but may have impacts on the performance due to heavy utilization of the server. It is also possible to split one step into multiple small steps and run them e.g. during the weekend. Preparation: Create a backup of the database and copy it to a save place. Make sure that no user is working in. Log in into. Go to System > Database Update: Update the database and application to the latest version as usual. Before starting the Reorganisation activate the checkbox Include Oracle Statistics. The system will show the information message below. Page 11 of 36

12 Confirm with OK. Now click on the button Reorganisation to update the Oracle database statistics. Depending on the size of the database this may take several minutes. Once completed the system will show this message. Click OK to confirm. Now the application again can be opened for other users as well. Page 12 of 36

13 Find out System Start Date: As next step it is required to find out the system start date. The easiest way: Go to System > Export Data: Enter the following command into the white box and click on Select : select min(wes_datum) from invwes Now switch to the tab Export Data and check the displayed date: The content of the field WES_DATUM of the first record shows the first transaction booked in that database. In this example the start date is January 24 th This date will be needed for the next step. Page 13 of 36

14 History Rebuild: This step is the most important and also the most time-consuming one. Now the system needs to create & calculate the missing entries in the table DailyTotals for all transactions in the past. It needs to be decided if really the entire history should be created or e.g. the last 2 years only. Log in into. Go to System > Database Update: Switch to the tab Settings : Click on the button System Settings : NOTE: Do not use any other option in the following dialog without clear advice/confirmation from the Product Management! Page 14 of 36

15 Activate the checkbox Prepare Offline and select the required calculation method. - Last Price (not yet supported for and must not be used!) - Average Price - Standard Price (not yet supported for and must not be used!) ATTENTION: DO NOT ACTIVATE THE CHECKBOX! Click on OK. Now the system needs to execute a database reorganization since the stored procedures will be changed. This process is started immediately. Confirm with OK. The next step is the rebuild of the records. This should be done during a time period where the system is not heavily used, e.g. during the weekend. The are not yet activated for the current transactions, but for history rebuild only! The system can be used normally during the offline history rebuild, but there might be an impact on the performance. NOTE: Make sure that no other high-performance tasks are executed during the history rebuild. All inventories should be closed before starting this process! Page 15 of 36

16 No inventory should be generated before finishing this process! Go to System > Data Administration > Data Analysis: In the header menu a section Data Analysis 2 can be found. Here select the module DailyTotals Tool : NOTE: Do not use any other function in this module without clear advice/confirmation from the Product Management! Using this tool you can rebuild the daily totals records for one single article or the entire system Screen description: From Date: Article: Load: Rebuild Article: Create Rebuild List: Date selection for Rebuild time period. could be used to select a single article for rebuild. if a single article was selected before, this button will load the transaction records. Click this button to start the rebuild process for the selected single article. Click this button to generate the batch list of all articles to be rebuilt. Exec Rebuild List: Click this button to start the rebuild process for all articles in the rebuild list for the defined time period. Page 16 of 36

17 The history rebuild will be very time consuming, but could be split into multiple smaller steps. The rebuild should be started on the server directly in order not to slow down the process due to network speed. It is recommended to test a first rebuild for not longer than one month from the beginning of the (agreed) history time range to test the impact on the existing environment. Example: In the step explained above the system start date in the sample database was discovered as January 24 th Open the Rebuild module and define the date range as follows: (Date range covers the first complete month). Now click on the button Create Rebuild List. The system now checks for the existence of a file called dt_rebuildlist.wt in the subdirectory \Update\. This file must exist (could be empty). Otherwise the system will show a message: If the file exists, the system will generate the batch list for the execution. Page 17 of 36

18 NOTE: Do not edit this file! Click on the button Exec Rebuild List to start the process The system will now start the rebuild process for the history in the defined time range. Depending on the number of transactions this could take already longer, but gives you an idea about the time to expect for the entire history rebuild. Once this is finished check the log file (RECALC_COS_YYYYMMDD.LOG) of the rebuild. This can be found in the \LOG\ directory of the server: This file shows the timestamp, user name, recalculation step, article name and the transaction type, document date and several other benchmarks. At the end of each article section the status is shown: Page 18 of 36

19 :57:25-admin -1 -Recalculate Prices, ' '...(Okay, Prices not changed) (0,066) Here the rebuild was done and no prices of any booked document (transfer, usage, etc.) needed to be changed. In case the system discovers that a document needs to be changed, a 2 nd rebuild run for this article will be started: :57:34-admin -1-3-Production (20, ' ' )...(0) (0,000) :57:34-admin -1 -Recalculate Prices, ' '...(Okay, Prices changed) (0,076) :57:38-admin -2-1-Sales (2, ' ' )...(0) (0,000) Once completed the system will start another run if required or proceed with the next article. The End at the bottom of the screen indicates that the process is completed. Check the last record of the file to see the entire duration of this rebuild process :10:10-admin - -END This will give you an indication how long the entire history rebuild will take. Rebuild the history (in multiple steps) up to e.g. 2 months before the expected real live date (when the DTTLs will be switched on completely). Page 19 of 36

20 Activation: Once the history was rebuilt as described above, the DailyTotals could be activated completely. Based on the experience made during the history rebuild it should be possible to estimate the needed time for the rebuild of the remaining history. Once starting this process now the system must not be used by any other user or process until the end of the final rebuild. Make sure that also all jobs are switched off (e.g. POS Import, Backups, any other job connecting to the database)! Log in into. Go to System > Database Update: Switch to the tab Settings : Click on the button System Settings : Page 20 of 36

21 NOTE: Do not use any other option in the following dialog without clear advice/confirmation from the Product Management! This is the current setting from Offline History Rebuild: Now change the system to the Online mode: Once closing this dialog with OK the system will execute a reorganization to load the required stored procedures. Now start the rebuild once more, covering the date range from the previous end-time until the current date. Click on Create Rebuild List first. Click on Exec Rebuild List. Page 21 of 36

22 The End at the bottom of the screen indicates that the process is completed. Go to System > Configuration: In the folder [NAMES] the hidden parameter SysDaily_Time can be found: Enter here the start date of the system in the format YYYY-MM-DD-HHHH-MI-SS., e.g for March 25 th 2013 at 01:05:27pm. It represents the booking date & time of the last checked transaction. This date will be checked and used as start date for the job Recalculation of COS from Documents. NOTE: After this first time, do not edit this field unless clearly advised by MF EAME Support Team! Page 22 of 36

23 Required scheduled Jobs: There are several jobs which must be executed for on a daily basis. The jobs should be executed in the sequence as listed below! 1. Recalculation of COS from Documents This job recalculates documents to use the correct prices after doing corrections in the past. ATTENTION: This job could run several hours! This job must not be executed if the calculation method Last Price was selected. 2. Recalculation of This job updates the current and also Table LAGER (NAMES -> SysDailyRecalcUpdLager must be set!). o Keep in mind that table LAGER is updated only after execution of this job. Customized reports based on table LAGER might show outdated information! 3. Refresh COS of Recipes This job recalculates the COS of the Recipe Headers and Products. All other jobs like Import Sales, Transfer on Sales, etc. must run AFTER the jobs above! At least once a month we recommend to schedule the following job: 4. Update Oracle Statistics This job updates the Statistics of your Oracle Database to speed up the system. o Depending on the number of transactions it could be useful to execute this in shorter sequences. Page 23 of 36

24 Existing Database with DTTLs: This chapter will explain the preparation of the database for an existing, running property with already enabled. Even though the DailyTotals calculation method was not released for versions < it was possible to activate this functionality through administrative users. Since we cannot ensure the correctness of the existing records in the DailyTotals table the steps below must be executed! It needs to be considered that the average prices for several articles might/will be changed, because the prices will be recalculated and backdated transactions will cause a recalculation of later booked documents. This is not the case when working without DTTLs! Depending on the size of the database the procedure described below can take several days. Some parts of the preparation process could run besides the normal operation, but may have impacts on the performance due to heavy utilization of the server. It is also possible to split one step into multiple small steps and run them e.g. during the weekend. Preparation: Create a backup of the database and copy it to a save place. Make sure that no user is working in. At first the database version needs to be checked: Here we have to differentiate between two cases: If DB Version < 11.05: The application has written details into the table DAILYTOTALS, but not used them for any calculation in the system. These records must be removed completely. This will speed up the history rebuild process. (During the rebuild process the system will delete these records anyway before rebuilding the new ones!) Because of the (expected) size of that table we strongly recommend to truncate the table instead of using a delete command. NOTE: Keep in mind that the truncate command does not allow any rollback! Please contact your DBA for assistance if required. Page 24 of 36

25 The database can be considered now as in a status without having DAILYTOTALS activated before. Please follow the procedures explained for databases without activated DailyTotals in the chapter above. If DB Version > 11.05: In this case the application is using the actively already. But the history needs to be rebuilt (reasons explained above!). The records in the table DAILYTOTALS must not be deleted since the application is using them already in all modules! Log in into. Go to System > Database Update: Update the database and application to the latest version as usual. Before starting the Reorganisation activate the checkbox Include Oracle Statistics. The system will show the information message below. Confirm with OK. Page 25 of 36

26 Now click on the button Reorganisation to update the Oracle database statistics. Depending on the size of the database this may take several minutes. Once completed the system will show this message. Click OK to confirm. Now the application again can be opened for other users as well. Page 26 of 36

27 Find out System Start Date: As next step it is required to find out the system start date. The easiest way: Go to System > Export Data: Enter the following command into the white box and click on Select : select min(wes_datum) from invwes Now switch to the tab Export Data and check the displayed date: The content of the field WES_DATUM of the first record shows the first transaction booked in that database. In this example the start date is January 24 th This date will be needed for the next step. Page 27 of 36

28 History Rebuild: This step is the most important and also the most time-consuming one. Now the system needs to create & calculate the missing entries in the table DailyTotals for all transactions in the past. It needs to be decided if really the entire history should be created or e.g. the last 2 years only. Log in into. Go to System > Database Update: Switch to the tab Settings : Click on the button System Settings : NOTE: Do not use any other option in the following dialog without clear advice/confirmation from the Product Management! Page 28 of 36

29 Check the activation and make sure that the correct calculation method is selected. - Last Price (not yet supported for and must not be used!) - Average Price - Standard Price (not yet supported for and must not be used!) The next step is the rebuild of the records. This should be done during a time period where the system is not heavily used, e.g. during the weekend. The system can be used normally during the history rebuild, but there might be an impact on the performance. NOTE: Make sure that no other high-performance tasks are executed during the history rebuild. Go to System > Data Administration > Data Analysis: In the header menu a section Data Analysis 2 can be found. Here select the module DailyTotals Tool : NOTE: Do not use any other function in this module without clear advice/confirmation from the Product Management! Using this tool you can rebuild the daily totals records for Page 29 of 36

30 one single article or the entire system Screen description: From Date: Article: Load: Rebuild Article: Create Rebuild List: Exec Rebuild List: Date selection for Rebuild time period. could be used to select a single article for rebuild. if a single article was selected before, this button will load the transaction records. Click this button to start the rebuild process for the selected single article. Click this button to generate the batch list of all articles to be rebuilt. Click this button to start the rebuild process for all articles in the rebuild list for the defined time period. The history rebuild will be very time consuming, but could be split into multiple smaller steps. The rebuild should be started on the server directly in order not to slow down the process due to network speed. It is recommended to test a first rebuild for not longer than one month from the beginning of the (agreed) history time range to test the impact on the existing environment. Example: In the step explained above the system start date in the sample database was discovered as January 24 th Open the Rebuild module and define the date range as follows: (Date range covers the first complete month). Now click on the button Create Rebuild List. The system now checks for the existence of a file called dt_rebuildlist.wt in the subdirectory \Update\. This file must exist (could be empty). Otherwise the system will show a message: Page 30 of 36

31 If the file exists, the system will generate the batch list for the execution. NOTE: Do not edit this file! Click on the button Exec Rebuild List to start the process The system will now start the rebuild process for the history in the defined time range. Depending on the number of transactions this could take already longer, but gives you an idea about the time to expect for the entire history rebuild. Once this is finished check the log file (RECALC_COS_YYYYMMDD.LOG) of the rebuild. This can be found in the \LOG\ directory of the server: Page 31 of 36

32 This file shows the timestamp, user name, recalculation step, article name and the transaction type, document date and several other benchmarks. At the end of each article section the status is shown: :57:25-admin -1 -Recalculate Prices, ' '...(Okay, Prices not changed) (0,066) Here the rebuild was done and no prices of any booked document (transfer, usage, etc.) needed to be changed. In case the system discovers that a document needs to be changed, a 2 nd rebuild run for this article will be started: :57:34-admin -1-3-Production (20, ' ' )...(0) (0,000) :57:34-admin -1 -Recalculate Prices, ' '...(Okay, Prices changed) (0,076) :57:38-admin -2-1-Sales (2, ' ' )...(0) (0,000) Once completed the system will start another run if required or proceed with the next article. The End at the bottom of the screen indicates that the process is completed. Check the last record of the file to see the entire duration of this rebuild process. Page 32 of 36

33 :10:10-admin - -END This will give you an indication how long the entire history rebuild will take. Rebuild the history (in multiple steps) until the current date. NOTE: Make sure that no other high-performance tasks are executed during the history rebuild. All inventories should be closed before starting this process! No inventory should be generated before finishing this process! Go to System > Configuration: In the folder [NAMES] the hidden parameter SysDaily_Time can be found: Enter here the start date of the system in the format YYYY-MM-DD-HHHH-MI-SS., e.g for March 25 th 2013 at 01:05:27pm. It represents the booking date & time of the last checked transaction. This date will be checked and used as start date for the job Recalculation of COS from Documents. NOTE: After this first time, do not edit this field unless clearly advised by MF EAME Support Team! Required scheduled Jobs: There are several jobs which must be executed for on a daily basis. The jobs should be executed in the sequence as listed below! 1. Recalculation of COS from Documents This job recalculates documents to use the correct prices after doing corrections in the past. ATTENTION: This job could run several hours! This job must not be executed if the calculation method Last Price was selected. 2. Recalculation of This job updates the current and also Table LAGER Page 33 of 36

34 (NAMES -> SysDailyRecalcUpdLager must be set!). o Keep in mind that table LAGER is updated only after execution of this job. Customized reports based on table LAGER might show outdated information! 3. Refresh COS of Recipes This job recalculates the COS of the Recipe Headers and Products. All other jobs like Import Sales, Transfer on Sales, etc. must run AFTER the jobs above! At least once a month we recommend to schedule the following job: 4. Update Oracle Statistics This job updates the Statistics of your Oracle Database to speed up the system. o Depending on the number of transactions it could be useful to execute this in shorter sequences. Page 34 of 36

35 DTTL Check at Inventory: The module Inventory checks if there are any changed documents affecting the values in the inventory task. Example: Book a delivery note on March 1 st for a specific article. Book a Transfer on March 2 nd for the same article from the above receiving store to any other store. Now correct the delivery note booked on March 1 st and change the price for the article. Usually this would be corrected by the Scheduler Job Recalculation of COS from Documents. If this job was not executed and the figures are not up to date, the application now will show a warning message at refresh or booking attempts: At Refresh: o If the user selects No, the system will return to the Inventory Overview screen. o If the user selects Yes the system will perform the refresh using the existing figures without performing the recalculation of the documents. The inventory details could contain outdated/incorrect figures! At Booking: o If the user selects No, the system will return to the Inventory Overview screen. o If the user selects Yes the system will book and close the inventory using the existing figures without performing the recalculation of the documents. The inventory details could contain outdated/incorrect figures! In addition to this the system will write an entry into the Control Table as shown below: [Cost Center Name] {Inventory Name} Booking Process Started ignoring DTTLs COS of Documents Warning Page 35 of 36

36 MICROS-FIDELIO GmbH Europadamm Neuss Germany Phone: l Fax: Page 36 of 36