This section covers features we created to handle common bulk updates requested by our customers.
- Before using one of these features in your production environment, you must ensure you have a complete understanding of the tool's purpose and possible consequences.
- We recommend that you run the update in a sandbox before attempting to run the update in a production environment so you can ensure that you are happy with the outcome. You cannot reverse the changes made by some of these updates.
- Some updates can run for a long time and should be run outside office hours to avoid locking
Sales History Dimension Update
Some companies want to change the dimensions of their historical entries when they change the dimensions of their customers. The Sales History Dimension Update allows you to update the dimensions selectively.
You can use this update to do the following:
- Correct sales transactions related to customers that got set up incorrectly.
- Introduce a new dimension linked to your customers and update all history.
- Reclassify your customers and allow this classification to get reflected in the history and future transactions.
If you use Analysis Views, you will need to rebuild them because this tool does not update analysis views.
The Sales History Dimension Update consists of two main parts:
- Update Customer Historical Dimensions processing-only report. This report triggers the update and specifies update options and filters.
- Sales Dimension History Updates. This list provides access to a log with additional details about who ran the update, when they ran it, what dimensions were updated, etc.
The above pages are available from the Theta Run Object page and Tell Me.
Update Sales Historical Dimensions
The request page of the update report is shown below:
The request page has the following options:
|Dimensions to Update||Specifies dimensions codes that should be updated. To select dimension codes from the list, press the assist edit button. You must select at least one dimension.|
|From Posting Date||Specifies the earliest Posting Date for sales transactions for which the app will update dimensions.|
|To Posting Date||Specifies the latest Posting Date for sales transactions for which the app will update dimensions.|
|Comment||Specifies optional comments from the user. By default, the comment reflects dimension codes to be updated.|
|Commit after each customer||Specifies that app should commit changes after processing each customer's history. This setting is to prevent one error from rolling back the entire batch.|
|Filter: Customer||The Filter section shows the default filter fields you use to limit which customers to update. To add a filter, choose the + Filter action, type the name of the field that you want to filter by, or pick a field from the drop-down list.|
As the sales history can consist of thousands of entries, scheduling this batch job using the job queue is recommended.
The dimension update report does not check whether customer dimensions selected for an update are currently blocked or certain dimension value combinations are currently prohibited. It is up to the user to decide which dimensions need to be reflected against the historical transactions.
Sales Dimension History Updates
Each time you run the Sales History Dimension Update, a new entry gets created in the Dimension History Update List. As can be seen in the screenshot below, the update got to run run twice in a test company:
Press Entry No. to open the card and get additional details about the update.
|1. General||Specifies general information about the update: user name, time-stamp and comment.|
|2. Lines||Specifies the entries that got updated in this batch.|
|3. Previous Dimension Set factbox||Specifies the current entry's dimension set before the update.|
|4. New Dimension Set factbox||Specifies dimension set which current entry received after the update.|
As seen in the Comment field in the screenshot above, the user ran the update to update the DEPARTMENT dimension code. The New Dimension Set fact box shows that the app enriched the dimension set for the selected entry with the new dimension code value 'ADM'.
Dimension Code Update Scenarios
Different update scenarios are possible depending on the current customer and existing historical dimension sets. For example:
|1. New dimension code DEPARTMENT with value 'ADM' got assigned to the customer.||Historical dimension sets for this customer will now show DEPARTMENT 'ADM'.|
|2. Dimension Code DEPARTMENT is changed from 'ADM' to 'SALES'.||Historical dimension sets for this customer will now show DEPARTMENT 'SALES'.|
|3. Dimension Code DEPARTMENT gets removed from the customer||Dimension Code DEPARTMENT will be removed from the historical dimension sets.|
The update report updates only dimension codes specified in the request page's Dimensions to Update field.
Special case of Bill-to Customer No. different from Sell-to Customer No.
Standard BC functionality allows Bill-To Customer No. to be different from the Sell-To Customer No. in sales documents. In such cases, the dimension set of specific entries gets updated from the Bill-To Customer No. dimensions and the dimension set of other entries gets updated from Sell-To Customer No. dimensions.
Namely, the dimension set of the below entries gets updated from Bill-to Customer No.:
- "G/L Entry"
- "Value Entry"
- "Cust. Ledger Entry"
- "Detailed Cust. Ledg. Entry"
- "Sales Cr.Memo Header"
- "Sales Cr.Memo Line"
- "Sales Invoice Header"
- "Sales Invoice Line"
The dimension set of the below entries gets updated from Sell-to Customer No.:
- "G/L Entry"
- "Value Entry"
- "Sales Shipment Header"
- "Sales Shipment Line"
- "Return Receipt Header"
- "Return Receipt Line"