Table of Contents

• Overview
• Install psaCentralWave
  • Prerequisites
  • Download the Application & License
  • Install the License
  • Install the Application
• Configure psaCentralWave
  • Initial Configuration
  • Source Specific Configuration
  • DSW Reports
  • Security Configuration
  • Scope of Relevancy
  • Naming Conventions
  • Design Notes
    • Target Design
    • Source Design
    • Target Rules
      • Transaction Based Target Tables
      • Master Target Tables
      • Transaction Based Source Tables
      • Master Source Tables

NOTE: Syniti’s Professional Service Accelerators (psa) have been developed and are supported by

a team of senior consultants. The psas are designed to supplement the Stewardship Tier delivered features with content and automation that accelerate the progress of the project. If you have any questions or encounter any issues while using a psa, please submit a support ticket and be sure to select the psa on the form.

Overview

The PSA Relevancy is a tool built on the Syniti Stewardship Tier (SST, formerly DSP). It has been designed to support the identification of relevant MASTER Records (Customer, Vendor and Material) in preparation for further processing.

The tool uses a combination of SST delivered applications and custom configuration that controls either by:

• Number of days or fixed date
• In and out of scope Company, Sales Organization, Purchasing Organization, Plants, Customer Account Group, Material Type
• Relevant client by zSource
• Specific inclusion or exclusion by object key

Any remaining transactions after the filters are applied are considered relevant therefore causing an associated master record to be relevant.

The SST applications in use are:

Install psaCentralWave

The application can be installed on Syniti Solutions SST versions 7.4.1 and above. It has not been thoroughly tested on lower versions.

Prerequisites

PsaPerformanceBench needs to be installed prior to psaCentralWave installation. Refer to psaPerformanceBench Application Guide for install details.

Download the Application & License

The psaCentralWave application and/or license are obtained by opening a support ticket at support.syniti.com

Perform the following steps to retrieve the necessary information for a license request:

1. On the SST application server, locate the Hardware Identifier program (called “HardwareIdentifier.exe") included in a zip file along with the SST installation software and documentation previously downloaded from Syniti.
2. Open the program.
3. Click Generate.
4. Copy the automatically generated ID and collect the following additional information. All information below pertains to the application server running SST; no information is needed regarding the database server:
   • Hardware ID (as mentioned above)
   • Windows computer name
   • Number of processor cores (as shown in the Task Manager CPU tab)
   • Usage of the SST instance, as in, DEV, TEST (or QA) or PROD
5. Syniti Licensing will deliver the license file via the support ticket.

Install the License

Perform the following steps to install the license:

1. Log in to the SST site as an Administrator.
2. Select Admin > Configuration > Product Licenses in the Navigation pane.
3. Click the Upload a file icon in the FILE NAME column next to the Upload a New Product License link.
4. Locate the license file that was provided by Syniti Licensing.
5. Click Open.
6. Verify the license is uploaded.

   NOTE: If the Navigation pane does not display all the licensed components as expected, use

   the browser refresh button or the F5 key to refresh the screen. At this point the full vertical menu will appear.

Install the Application

Perform the following steps to install the application:

1. Right click on psaCentralWave.zip and go to Properties. Ensure to unblock the file if it is blocked.
2. Unzip the file.
3. Navigate to the SST Installation folder (e.g., D:\BOA\DSP or C:\Program Files (x86)\BOA\DSP)
4. Back up the DSP Install\BOA\DSP folder to a compressed zip file
5. Back up all Syniti-supplied SQL Server databases or verify that a complete recent backup already exists

   NOTE: Supplied databases: AutoGen, cMap, cMap_Data, cMass, cMass_Data, Console, CranPort,

   CranSoft, DataConstructionServer, DataDialysis, DataGarage, DBMoto_Client, DGE, DGE_Data, dgReports, dgSAP, dspAddOn, DSPCommon, dspMonitor_AccPak, dspMonitorConfig, DSW, IGC, Integrate, IntegrateStaging, InterfaceServer, MC, & RADToolkit

6. Stop IIS

   This process disconnects all active SST users, so it is highly recommended to perform the install when no users are on the system. This process stops IIS on the web server.

   1. Open Windows Start Menu.
   2. Open the Command Prompt (run as an administrator).
   3. Type: IISReset –stop.
   4. Press the Enter key.
   5. Leave the Command Prompt window open for later use.
7. Stop all services that start with “Cransoft Service …”

   This process stops all SST background jobs, so it is highly recommended to perform the install when no scheduled operations are running on the system.

   1. Open Windows Start Menu.
   2. Select Administrative Tools.
   3. Run Services.
   4. Right-click the SST service.
   5. Select Stop.
   6. Repeat the previous two steps for any additional SST services.
8. Copy the Web folder from the zip file to your existing DSP install\Web folder. If prompted, replace the files in the destination.
9. Copy the Databases folder from the zip file to your existing DSP install\Databases folder. If prompted, replace the files in the destination.(when copying the Databases\Apps folder do not replace files in that folder).
10. Navigate to DSP install\Databases and execute file psaCentralWave_Install.bat (run as an administrator).
11. Start all services that start with “Cransoft Service …”
    1. Open Windows Start Menu.
    2. Select Administrative Tools.
    3. Run Services.
    4. Locate the SST service(s).
    5. Right-click the SST service.
    6. Select Start.
    7. Repeat the previous two steps for any additional SST services.
12. Start IIS.
    1. Open Windows Start Menu.
    2. Open the Command Prompt (run as an administrator).
    3. Type: IISReset –start.
    4. Press the Enter key.

Configure psaCentralWave

psaCentralWave comes pre-configured with default values in the configuration tables, but they will require modification per specific client needs.

If the Navigation pane in SST does not display psaCentralWave, then try these steps:

1. Log in to the SST site as an Administrator.
2. Select Admin > Configuration > Product License in the Navigation pane.

   NOTE: Ensure that psaCentralWave displays.

3. Select Admin > Configuration > Site Menu in the Navigation pane.

   NOTE: Ensure that psaCentralWave displays. If not, then:

1. Click Add.
2. Enter a priority in the PRIORITY field.
3. Enter psaCentralWave as the label for the site menu option in the LABEL field.
4. Select the psaCentralWave:psaCentralWave page from the LINK TO PAGE ID list box.
4. Select Admin > Configuration > Parameters in the Navigation pane.
   1. Click Clear Cache.
   2. Reload the browser tab.

If the psaCentralWave application is still not able to display, then review the “Define Security Roles” article in the SST Online Help to ensure the SST user has access to psaCentralWave. The SST Online Help is accessible from the question mark icon in the top-right corner of all SST pages. Also open a ticket at support.syniti.com for assistance with PsaPerformanceBench Configuration.

In order for the ADM rules to run properly, psaPerformanceBench must be configured for the Targets registered under the Object ‘Business Transactions’. These include the following:

• ttAPHistory
• ttAPOpen
• ttARHistory
• ttAROpen
• ttMaterialMovement
• ttPayments
• ttProductionOrder
• ttPurchLine
• ttSalesHeader
• ttSalesLine
• ttSalesPartners

1. For each of the above Target Tables navigate to psaPerformanceBench on the left menu pane.

   

2. Click on Objects/Targets and select the WaveName ProcessArea/Name - Central/Relevancy/BusinessTransactions line. Click the Targets Icon

   

3. The pane below will display all the Targets listed above. For each Target click the activate button.
4. Click on the Sources Icon for each of the activated Target Tables.
5. Activate the Source Table on this line.  This will activate bulk processing for this source table.
6. If any mapping changes were made, refresh the mapping. 

   NOTE: Make sure that field zActive = 1 is added to filtering if there are rules that adjust zActive flag

7. Build the rules.

Once all Target and Source tables have been activated navigate to Transform > Business Transactions and process each target listed above to verify it is error free. The “normal” rules will display as de-activated with new rules added.

Initial Configuration

Add users to supplied SAP_ECC zSource, if appropriate.

• Select Advanced Data Migration > Construct > ZSource in the Navigation pane.

Add users to the developer under design to see and utilize automate.

1. Select Advanced Data Migration > Design > Targets in the Navigation pane.
2. Add users to the developer icon.

1. Select Advanced Data Migration > Design > Append Utility Columns in the Navigation pane.
2. Review Utility fields and determine visibility. This controls whether a utility field will show up in MAP and whether at the Source or Target level. zActive is used within the application and is generally expected to be visibility of NONE. Refer to ADM_DM Config Inventory for further information

In psaCentralWave, there are two initial configuration areas that must be confirmed prior to the Source relevancy criteria definition.

• Org Unit Type
• Operand Config

Org Unit Type

The following Org Units are provided out of the box, but you can add custom Org Units to fit the business requirements. Org units defined here can be used to enter specific exclude criteria at the Source Relevancy level.

The Org units can be found in the table: ztOrgUnit – Contains the check table for various Organizational Units that will be used in relevancy determination. Multiple Types are provided out of the box. All associated rules are also provided in transform. If new Org Unit Types are added, additional custom rules will need to be developed.

Operand Config

“Exclude” and “Include” are provided as out of the box operands. You can add additional operands as needed to meet the business needs. These Operands will be used in defining the specific Source Relevancy.

Operands can be found in table ztOperand.

Source Specific Configuration

Once the Org Units and Operands have been identified, capture the the relevancy criteria specific to each source.

Source Relevancy:

Specify the criteria required to support relevant record selection at the source level. The parameters defined in Source Relevancy can be found in the table ztSourceRelevancy. This table contains the parameters that control transactional relevancy determination.

The zSources data sources can be marked as Active or mark to not facilitate processing against specific zSources. All source zsource data sources associated to the Central Wave processing area will be affected.

NOTE: Either the xxxDays_xxxxxxx OR xxxDate_xxxxxx need to be populated, but not both. Typically,

in the beginning of projects, Days are used .Then as the GoLive date gets closer, the user may define a specific cut-off date.

There are three areas within Source Relevancy that require configuration:

Vertical View for the zSource

Source Relevancy will specify most of the details that define relevancy for that specific zSource. There are many parameters to define, and multiple tabs.

The General tab contains these parameters:

• zSource—The zSource data source for relevancy.
• PrimaryLanguage—Primary language used (used in Material description and Address selection)
• Client—The client number for relevancy and is used as the first rule to set the relevant flag
• LastClientRefresh—Used in the calculation of days (e.g., dbo.ztSourceRelevancy.LastClientRefresh AS smalldatetime—dbo.ztSourceRelevancy.OldDays_APPayment > dbo.ttPayments.PrintDate.  This date is critical for all relevancy criteria based on Days.
• Vendor_InterCompany—The Account group recognized as Vendor Intercompany account and should always be deemed relevant from a general view
• Customer_InterCompany—The Account group recognized as Customer Intercompany and should always be deemed relevant from a general view
• BOMExplosionLimit—The number of recursive calls to be made to gather all subsequent component materials

The New Days tab determines the characteristics that will be used to identify an object that remains in scope, even without activity; if it falls within the “new days” calculations.

NOTE: Define New Days OR New Date, not both.

New Days tab contains these fields:

• NewDays_Customer—Number of days (considering refresh date) after entry date that a customer is still considered a new customer and subsequent transactional relevant requirements do not apply.
• NewDays_Vendor—Number of days (considering refresh date) after entry date that a vendor is still considered a new vendor and subsequent transactional relevant requirements do not apply.
• NewDays_Material—Number of days (considering refresh date) after entry date that a material is still considered a new material and subsequent transactional relevant requirements do not apply.
• NewDays_POContract—Number of days (considering refresh date) after entry date that a Purchasing contract is still considered a new customer and subsequent transactional relevant requirements do not apply.
• NewDays_SOContract—Number of days (considering refresh date) after entry date that a Sales Order contract is still considered a new customer and subsequent transactional relevant requirements do not apply.

The Old Days tab determines the timeframe, in days, that will be used to identify records that will fall out of scope due to their age. Once transactions or items reach the days from the refresh date (defined on the General tab), the object falls out of scope, unless specifically overridden.

NOTE: Define Old Days OR Old Date, but not both.

Old Days tab contains these fields:

Vendors:

• OldDays_PO Contract—The number of days (considering refresh date) after DocCreate for ttPurchHeader where PurchCat = K/L that the record is considered part of the relevant determination of Vendor.

  NOTE: Review that the indicated PurchCat(s) are appropriate to the client environment.

• OldDays_PO—The number of days (including Refresh Date) after DocCreate for ttPurchHeader where PurchCat = F/A that the record is considered part of the relevant determination of Vendor.

  NOTE: Review that the indicated PurchCat(s) are appropriate to the client environment.

• OldDays_AP Payment—The number of days (including Refresh Date) after ClearingDate for ttAPHistory or PrintDate for ttPayments that the record is considered part of the relevant determination of Vendor.

Customers:

• OldDays_SO Contract—The number of days (including Refresh Date) after DocCreate for ttSalesHeader where the OrdCat = B/C that the record is considered part of the relevant determination of Customer.

  NOTE: Review and determine that the indicated OrdCat(s) are appropriate to the client environment.

• OldDays_SO—The number of days (including Refresh Date) after DocCreate for ttSalesHeader where the OrdCat <> B/C that the record is considered part of the relevant determination of Customer.

  NOTE: Review and determine that the indicated OrdCat(s) are appropriate to the client environment

• OldDays_AR Payment—The number of days (including Refresh Date) after ClearingDate for ttARHistory or PrintDate for ttPayments that the record is considered part of the relevant determination of Customer.

Materials:

• OldDays_Mat Movement
• OldDays__Production Ord
• OldDaysMM—The number of days (considering refresh date) after ItemFinishDate or ActualFinishDate or SchedRelDate if any are > 0 for ttMaterialMovement that the record is considered part of the relevant determination of Material

No longer used:

• Old Days P2P—not currently used and can be utilized for customization purposes
• Old Days SD—not currently used and can be utilized for customization purposes

The New Date tab is used to identify the timeframe, based on a specific date, that will be used to identify records that will remain in scope regardless of the activity for that record.

NOTE: Define New Days OR New Date, but not both.

New Date tab contains these fields:

• NewDate_Customer—The date less than or equal to the entry date when a customer is still considered a new customer and subsequent transactional relevant requirements do not apply.
• NewDate_Vendor—The date less than or equal to the entry date when a vendor is still considered a new customer and subsequent transactional relevant requirements do not apply.
• NewDate_Material—The date less than or equal to the entry date when a material is still considered a new customer and subsequent transactional relevant requirements do not apply.
• NewDate_POContract—The date less than or equal to the entry date when a Purchasing contract is still considered a new customer and subsequent transactional relevant requirements do not apply.
• NewDate_SOContract—The date less than or equal to the entry date when a Sales Order contract is still considered a new customer and subsequent transactional relevant requirements do not apply

The Old Date tab is used to identify the timeframe, based on a specific date, that will be utilized to identify records that will fall out of scope due to their age. If activity occurs prior to the specified date, the item falls out of scope unless specifically overridden.

NOTE: Define Old Days OR Old Date, but not both.

Old Date tab contains these fields:

Vendors:

• OldDate_Contract—The date that is less than the DocCreate for ttPurchHeader where PurchCat = K/L that the record is considered part of the relevant determination of Vendor.

  NOTE: Review that the indicated PurchCat(s) are appropriate to the client environment.

• OldDate_PO—The date that is less than the DocCreate for ttPurchHeader where PurchCat = F/A that the record is considered part of the relevant determination of Vendor.

  NOTE: Review that the indicated PurchCat(s) are appropriate to the client environment.

• OldDate_AP Payment—The date that is less than the ClearingDate for ttAPHistory or PrintDate for ttPayments that the record is considered part of the relevant determination of Vendor.

Customers:

• OldDate_SO Contract—The date that is less than the DocCreate for ttSalesHeader where the OrdCat = B/C that the record is considered part of the relevant determination of Customer.

  NOTE: Review that the indicated OrdCat(s) are appropriate to the client environment.

• OldDate_SO—The date that is less than the DocCreate for ttSalesHeader where the OrdCat <> B/C that the record is considered part of the relevant determination of Customer.

  NOTE: Review that the indicated OrdCat(s) are appropriate to the client environment.

• OldDate_AR Payment—The date that is less than the ClearingDate for ttARHistory or PrintDate for ttPayments that the record is considered part of the relevant determination of Customer.

Materials:

• OldDate_Mat Movement
• OldDate_Production Ord
• OldDateMM—The Date used to determine relevancy if ItemFinishDate or ActualFinishDate or SchedRelDate are greater than the defined date, the record will be considered part of the relevant determination of Material.

No longer used:

• OldDaysP2P—not currently used and can be utilized for customization purposes.
• OldDaysSD—not currently used and can be utilized for customization purposes.

Org Unit Values:

Specify the values to execute from the dataset. The Org Units values provided on this tab are configured in Org Unit Type page.

This data is stored in the table ztSourceRelevancyOrgUnit, which contains by zSource, the *NOT* relevant OrgUnit(s) defined by the ztOrgUnit type table. If not populated, then all entries associated to that OrgUnit type are deemed relevant.

Org Unit definition is used for excluding specific org units, and not for defining which are relevant. By forcing the client to indicate Non-relevant values, all values will be taken into consideration rather than indicating relevant values and missing unused, little used or new values.

Override:

Specify the exact values to be included or excluded (or other Operands defined above). This section is specific to indicating records that will be excluded/included based on criteria defined in Source Relevancy or Org Unit Values.

Excel integration has been enabled for this page so values may be uploaded from a spreadsheet if needed.

The following are examples for reference:

Each entry can be flagged as Active or not.

Note that this Override will not supersede criteria for downstream objects. For example, if a BOM is included as relevant but one of the Materials on that BOM is on the Override page to be excluded, that Material will not actually be excluded because it is a component on a BOM that is relevant. However the BOM could be excluded.

The data for Overrides is stored in table ztOverride

The Override section in Source Relevancy is different from the Override main menu object in that it is Source specific when the Overrides are entered at the source level. The main menu Override option is not specific to a source but is a compilation of all Overrides across all zSources.Overrides can be entered via either option since the zSource is captured when the Override is defined.

Relevancy sequencing is as follows:

1. Relevancy is processed first against date/days (Defined in the Vertical view of zSource). Records are flagged relevant or not based on the parameters provided. These can be superseded by Org Unit or Override definitions.
2. After dates have been used to include/ exclude records, Org Unit exclusions are then processed. If an item was flagged as relevant from date processing, it can be flagged as not relevant based on org unit exclusions. Org unit relevancy will always trump relevancy assigned based on dates/days.
3. Final processing is done against the specific Overrides defined. However, Overrides must work in conjunction with Org Type definitions. As example: A Customer Account group is excluded in Org Types, but the Customer is added to the Override page. The Account Group flagged as not relevant will supersede the Customer assigned in the Override page – so the Customer may not be added if its Account Group is not relevant.

DSW Reports

psaCentralWave also includes a compilation of the reports that are generated in ADM for easier reference:

These reports can be found in Transform > Target Reports but are dynamically updated on this menu option for a central reference.

Security Configuration

Prior to users being able to login and view data in psaCentralWave, security must be configured. Users must be provisioned in SST before they will be able to access the tool.

SST Roles

PSA.User—End-user access

PSA.Administrator—Admin Configuration access

Navigate to the SST Admin > Security page.

1. Click the security menu > Click the Security Defintions menu.
2. Select Security Roles.
3. Identify the Role(s) that require access to psaCentralWave.

Scope of Relevancy

Once psaCentralWave has been installed and setup, it will pre-populate Objects required to support relevancy processing in Advanced Data Migration. The priorities of the Objects and Targets has been determined and should not be re-sequenced without significant review.

The system is delivered with the following Objects:

These objects have supporting Targets as follows:

• Organizational Structure

  NOTE: Not used in this version of psaCentralWave but can be leveraged as needed

  

• Business Transaction

  

• Material Master Relevant

  

• Customer Master Relevant

  

• Vendor Master Relevant

  

• Business Entity Relevant Only—used for subsequent processing (e.g., psaAddress, psaHarmonization)

  

• Material Master Relevant Only—used for subsequent processing (e.g., psaHarmonization)

  

NOTE: Subsequent target processing should provide views back to dswCentral as the means

to either insert into Source only relevant records and utilize the reconciliation counts from the Relevancy process, or insert into Source all records and delete out non-relevant records.

Also, make sure that the determination of account groups and material types occur within the relevancy processing so that any subsequent quality reporting can be written with the validation utilizing the “new” determination and not the old.

The following are the Primary relevancy transaction tables, used to define transaction activity that will drive Master Data object relevancy. They are included as a part of the “Business Transactions” object.

Each of these tables will need to be mapped to the legacy source to bring in system-agnostic fields. This should be completed via the standard ADM process (Design, Map, Transform, etc.). The PSA provides default mapping and processing for SAP_ECC. This mapping should be reviewed for any unique Client differences.

NOTE: The most efficient way to use psaCentral Wave processing is to setup Collect to put the SAP_ECC

tables into sdbSAP_ECC. For more than one SAP system, contact SMT for viable options depending on the circumstances.

The Secondary transaction tables are used to capture additional details for determining relevancy. These tables also require mapping to legacy tables and fields.

They can be found in the Relevant Objects (e.g., Material Master Relevant).

Naming Conventions

The Relevancy tool follows Syniti naming conventions. SQL objects are named as follows:

CustomerSales_SAP_ECC_KNVV = Source Table

Source tables contain source data used for an application or migration in the data model that corresponds to the system it originated from.

ttCustomerSales =TargetTable

Target tables contain staged or application data in generically named fields.

tvMaterialLocation_zRelevant_IsFalseSel= TargetView (Select)

Target views are reports or other saved views related to transformed or application data.

svLFA1_Mariposa_EKPO_POsFromMariposaSel= Source View (Select)

Source views are reports or other saved reference data that is limited to data in a source system.

ztSource_Relevancy = Configuration Table

Configuration tables contain lists of values, parameters, or other configuration elements.

xtLFA1 = Cross Reference

Cross-references provide source-to-target or other tabular data references.

Design Notes

Target Design

• Key fields are always set and include zSource
• zRevelant field defaults to True (1) in the design as well as any other Bit type fields. The target rules will update the zRelevant flag as needed to False (0).
• zRelevantOverrideReason field will indicate which relevancy criteria is used to determine status of non-relevant. If a record is deemed not relevant due to Org Unit relevancy rule, a specific object key inclusion will not override that rule. For example, a customer is tied to an account group deemed not relevant but that customer is in the inclusion list. The relevancy will not be overridden since it is assumed that the account group will not exist. Place the new rules toward the end of the list.
• Target is always brought into the System type for dswCentral through Platform > Common > System Types > vertical of CentralWave > Import button.
• Target is brought into Design through either the target table or the system type, all fields are marked active.
• All of standard ADM automation performs as expected.

Source Design

• Tables are created as part of automation with zActive field defaulting value to True (1).
• For transactional processing, the zActive field is defined on the vertical view of the source for the where clause well as defined in psaPerformanceBench. If there is a performance issue in the handling of excessive records being placed into the target tables before being deleted due to non-relevancy, the relevancy rules can be copied and adjusted to the appropriate source fields and utilize zActive = 0 to remove them from the insert.
• Source is always brought into the System type for dswCentral through Platform > Common > System Types > vertical of CentralWave > Import button.
• Source can be brought into MAP and mapped allowing automation to create and register the subsequent views and rules. If Mapping is created or changed from the pre-delivered SAP_ECC mapping and the target is a transactional target, then automation should be rule then psaPerformanceBench mapping will need to be refreshed and the rules re-created to take into consideration the mapping changes.

Target Rules

Transaction Based Target Tables

• Checking of Old Days and Old Date sets the zDelete flag.
• Checking of non-relevant Organizational Units sets the zDelete flag.
• Missing master data elements can set the zDelete Flag.
• Registered Rule 100—Deletes flagged records from the target table.

Master Target Tables

• Updates from associated target transaction tables of counts, flag and total.
• Update of zNew flag from comparing Data or Days from ztSourceRelevancy.
• Registered Rule 100—Flags the records relevant based on the set of flags from all the associated transaction tables.
• Registered Rule 110(s)—Flags non-relevant records according to the Org Unit exclusion list.

  Note: If the Org Unit in question is Account Group or Material Type, there are rules that will

  exclude associated master data records in previously processed target. As example: Customer account group Z100 is not relevant, then Customer Company, Sales, Partner records will also be designated not relevant.  The associated reports will process at the end of the conversion after these rules.

• Registered Rule 120(s)—Flags non-relevant records according to the Override Exclusion list.
• Registered Rule 130(s)—Flags relevant records according to the Override Inclusion list IF not. excluded due to Org Unit exclusion list.

  Note: Fields have been provided for the “New” material type or account group to be determined

  and utilized within future reporting requirements. Place all the rules determining account group in this processing area and to access them when running the actual migration targets.

Transaction Based Source Tables

• All rules are generated through MAP and Automation.
• It is assumed that only one client is in the source tables (controlled through the collect packages)
• If psaPerformanceBench is utilized, the automatically rules will be marked BulkUpd and several Stored Procedure rules will be generated that aggregate the Copy, Xref and Default rules into a single Stored Procedure. There will be a new insert into Source Stored Procedure and well as a new insert into Target.

Master source tables

• All rules and inserts are generated through MAP and Automation.
• It is assumed that only one client is in the source tables (controlled through the collect packages).
• ALL master records are inserted into target so that reconciliation numbers are easier to validate from source to target.

The attached PDF file contains the contents of this article.

Professional Service Accelerators (PSAs) are licensed separately from the SST. For more information, please email NASMT@syniti.com. To download or install a PSA, submit a request to Syniti support.

Updated on September 7th, 2021