Software Development Kit (SDK) Data Migrator Guide

Software Development Kit (SDK) Data Migrator Guide Sage ERP MAS 500

Copyright 2000-2011 Sage Software, Inc. All rights reserved. Sage, the Sage logos, and the Sage product and service names mentioned herein are registered trademarks or trademarks of Sage Software, Inc. or its affiliated entities. All other trademarks are the property of their respective owners.

Contents Chapter 1: Overview... 1 Introduction to Data Migrator...1 Using Data Migrator...2 Setting Up Migration Links...2 Migrating Data...2 Chapter 2: Data Migrator Architecture... 3 High Level Data Flow...4 Supported Data Migrator Configurations...5 Data Migrator Processes & Communication...6 Processes and Communication Details...8 Migration Links...8 Role of Assisted Company Setup in Migration...11 Migrate <Step Name>...12 Staging Table Architecture Details...16 Migration Calling Architectural Overview...17 Migration Interface: dmmigrateintfc...17 Migration Caller Interface: IOwner...18 Migration Interface Enumerated Types...18 Extraction Architecture Details...21 Heterogeneous Data Sources Issue...21 Getting Extraction Data in Sets...22 Extraction COM Interface: IExtract...22 Extraction Stored Procedure Interface...24 Insert Architecture Details...25 Background Information and Overview...25 Insert Stored Procedures Interface...27 Migration Parameter Behavior and Metadata...28 Sage ERP MAS 500 SDK Data Migrator Guide iii

CONTENTS Chapter 3: Data Migrator Customization...33 Calling the APIs... 34 Determine the API Name... 34 Determine the... 34 Passing Data to the API... 35 Maximizing API Performance... 36 Return Values... 37 Populating Migration Parameters... 37 Getting API Error Logs... 38 Example of Calling the APIs... 38 Creating a New Source System Migration... 39 Create the Custom Extract Procedure... 39 Defining a Migration Link For Your Source System... 46 Add Metadata for Your Extractions... 46 Adding Functionality to Existing Extractions and Insertions... 47 Sample Add-on Extraction Metadata... 47 Adding a Staging Table to a Migration Step... 48 Chapter 4: API Reference...49 Balances... 49 General Ledger Account Balances... 49 Inventory Balances... 51 Inventory Balances Actual Cost Method... 51 Cash... 52 Banks... 52 Bank Accounts... 52 Tender Types... 53 Customers... 53 Customer Classes... 53 Customer Custom Fields... 53 Customer Items... 54 Customer Payment Terms... 54 Customer Price Groups... 55 Customers... 55 Sales Territories... 57 General... 57 Commission Classes...57 Processing Cycles... 58 Product Categories... 58 Reason Codes... 58 General Ledger... 59 Allocations... 59 Journals... 59 General Ledger Accounts... 60 Account Segments... 60 Budgets... 60 General Ledger Custom Fields... 61 Natural Accounts... 61 Sales Tax Accounts... 61 iv Sage ERP MAS 500 SDK Data Migrator Guide

CONTENTS Global...62 Sales Tax Classes...62 Sales Tax Codes...62 Sales Tax Schedules...63 History...64 Closed AP Invoices...64 Closed AR Invoices...65 Closed Purchase Orders...66 Closed Sales Orders...67 General Ledger Transactions...67 Inventory History...67 Inventory...68 Inventory...68 Inventory Item Class...69 Inventory Items...70 Warehouse Bin...72 Warehouses...72 Items...73 Freight Classes...73 Item Custom Fields...73 Noninventory Item Class...73 Noninventory Items...74 Product Price Groups...74 Purchase Product Line...75 Sales Product Line...75 Manufacturing...75 Employees...75 Operations...76 Routings...76 Tools...77 Work Centers...77 Open Orders...77 Purchase Orders...77 Sales Orders...78 Open Transactions...78 Bank Account Transactions...78 Open AP Invoices...79 Open AR Invoices...79 Pricing...81 Customer (Contract) Pricing...81 Matrix Pricing by Product Price Group...82 Matrix Pricing by Customer Group...83 Price Sheets...83 Product Group Pricing...83 Purchasing...84 Buyers...84 Purchase Order Custom Fields...84 Purchase Order Departments...85 Sales...85 Sales Transaction Custom Fields...85 Shipping Methods...86 Sage ERP MAS 500 SDK Data Migrator Guide v

CONTENTS Sales Organizations... 86 Sales Commissions... 86 Sales Teams... 87 Sales Persons... 88 Vendors... 88 Vendor Classes... 88 Vendor Custom Fields...88 Payment Terms... 89 Vendor Items... 89 Vendors... 90 vi Sage ERP MAS 500 SDK Data Migrator Guide

Overview 1 Use this guide to learn what drives migration, how to build your own migration for any legacy system you want to upgrade, and how to use Data Migrator APIs to load data on an ongoing basis. This guide provides detailed information on the technical aspects of Data Migrator, including: Schema and metadata that drive migration APIs used in Data Migrator Calling the Data Migrator APIs Modifying and creating extractions and insertions Introduction to Data Migrator Data Migrator, a task in Assisted Company Setup, offers a straightforward means of upgrading from Sage ERP MAS 90 and 200 to Sage ERP MAS 500. This migration feature replaces the need to write custom routines to transfer customer, vendor, and inventory information and to transfer the data to flat files for use with the import programs. Migrations are available for most of the data entry tasks, including all of the critical and voluminous items. Data Migrator automates many aspects of upgrading a back-office system to Sage ERP MAS 500. With the features available in Assisted Company Setup, Data Migrator provides the following features: A guided list of steps to set up a new company in Sage ERP MAS 500, including access to the appropriate migration, import, and data entry forms Expert schema mapping from Sage ERP MAS 90 and 200 to Sage ERP MAS 500 Staging tables to hold data between the source and Sage ERP MAS 500 Integrated access to Microsoft Excel for changing or adding to the data to be inserted Reporting capabilities that list records that do not meet the business rule requirements of Sage ERP MAS 500 An opportunity to fix failed records Metadata-driven architecture that supports customized extraction and insertion logic Sage ERP MAS 500 SDK Data Migrator Guide 1

CHAPTER 1 Using Data Migrator Setting Up Migration Links Migrating Data If your migration involves automatic extraction of data from a source system, you must first define a migration link that refers to the source system. For example, a migration link may indicate that the source data is Sage ERP MAS 90 Level 3.70, company ABC, and is found on the centralized server called Accounting in the MAS90 shared folder. By giving this migration link a name, the user can refer to the particular Sage ERP MAS 90 information without having to know where it is or how to extract it. You do not need to set up a migration link if you are going to use Data Migrator only as an insertion tool, entering data into the staging tables yourself, and then running the insertion process. For more information, refer to the Assisted Company Setup Help. Data Migrator consists of three separate activities: 1 Extracting the data from the source system (this is optional and used only for Sage ERP MAS 90 and 200) 2 Modifying, deleting, or adding records to those extracted 3 Inserting the records into Sage ERP MAS 500 The first and third steps are controlled with the Processing Options tab on the Migrate form. You can input data manually by going to the tab and using Excel to populate the staging tables, or you can use Data Transformation Services (DTS) in SQL. Processing options allow the choice of how to handle certain records. 2 Sage ERP MAS 500 SDK Data Migrator Guide

Data Migrator Architecture 2 There are several perspectives from which to discuss the Data Migrator architecture including the following: A high level view of the data flow The supported topologies The various processes and communication between them A functional view of the various processes in Data Migrator Sage ERP MAS 500 SDK Data Migrator Guide 3

CHAPTER 2 High Level Data Flow The figure below illustrates how Data Migrator supports the concept of moving data from a source system to the staging table holding area in the Sage ERP MAS 500 database. Data in the staging tables can be examined and modified using tools such as Microsoft Excel. The data can then be moved into the Sage ERP MAS 500 permanent tables and accessed through the front-end forms. Sage ERP MAS 500 Client PC Current Accounting System Database Sage ERP MAS 500 Staging Tables Sage ERP MAS 500 Permanent Tables Figure 1 - Data Migrator High Level Data Flow 4 Sage ERP MAS 500 SDK Data Migrator Guide

DATA MIGRATOR ARCHITECTURE Supported Data Migrator Configurations The figure below illustrates the five supported configurations. The first two configurations indicate that a source database, including a Sage ERP MAS 200 SQL database, can reside on any server in the network that has access to the Sage ERP MAS 500 client and server. (Sage ERP MAS 200 data is in a database pair: one database, MAS_xxx, where xxx is the company ID, and MAS_SYSTEM, which contains information common to all Sage ERP MAS 200 companies.) The third configuration, shown in the figure below, depicts the support for Sage ERP MAS 90 and 200. The fourth configuration indicates that any source system accessible using a connection string can be supported with customization. In particular, the common code can be used with an ODBC or OLE DB provider that can communicate using ActiveX Data Objects (ADO). Even if the common access code cannot support getting the source system data, you can still exploit the migration architecture, including the Assisted Customer Setup (ACS) forms, and use your access mechanism to put the data into the Sage ERP MAS 500 staging tables using the Sage ERP MAS 500 connection. The fifth configuration indicates that you can put Sage ERP MAS 90 or 200 data on the same server as SQL and the Sage ERP MAS 500 database. This configuration avoids network traffic and increases system performance. Figure 2 - Supported Configurations Sage ERP MAS 500 SDK Data Migrator Guide 5

CHAPTER 2 The SQL commands required to move data between SQL Servers is different than those required when the databases reside on the same server. Also, some connection properties and behaviors are different for the ProvideX ODBC driver, other ODBC drivers, and OLE DB. Sage has built a common piece of code to handle many of these differences. The third configuration in the figure shown above indicates that Sage ERP MAS 90 and 200 files can be located on any server in the network, including the Sage ERP MAS 500 database server. Because Sage ERP MAS 90 and 200 databases are files, passing of data between them and SQL server does not depend on where they are in the network, as long as both servers can be accessed by the client PC. For information on the methodology used to obtain data in all four cases, see Processes and Communication Details. Data Migrator Processes & Communication There are three main recurring processes in Data Migrator: the extraction, the insertion, and the Assisted Company Setup (ACS) form interaction (which contains two parts). The main ACS form and migration form are the first two pieces in the process: taking requests from the user, and calling the appropriate extractions and insertions, based on the current ACS step. The main processes and their primary responsibilities include: Assisted Company Setup Helps the user set up a Sage ERP MAS 500 company. Lets the user pick a migration source system. Determines if a migration is available for a particular ACS step. Launches the migration processing form. Migrate <Step Name> This is the primary migration interaction form. <Step Name> is the name of the current ACS step (for example, Sales Tax Accounts). Based on user choices, this migration interaction form runs the extraction and insertion and allows staging table data manipulation. A migration progress dialog box displays when either extraction or insertion is running. Extraction Places all data related to a particular step into the Sage ERP MAS 500 staging tables associated with that step. Insertion Applies the Sage ERP MAS 500 business rules to data in a step's staging tables and inserts the records into Sage ERP MAS 500. Depending on the report setting, information may be stored about the successes, warnings, and failures of each attempted record. The communication between the migration process and the extraction and insertion processes is done through two well-defined interfaces. All extractions use the same interface and all insertions use the same interface. The migration process uses metadata to determine what extractions and insertions to call for a particular step. The details of this process are provided later in this document. 6 Sage ERP MAS 500 SDK Data Migrator Guide

DATA MIGRATOR ARCHITECTURE The diagram below depicts a data flow of the migration process. User-interface interaction Assisted Company Setup Step related migration data Migrate System, link and step information Extract, insert, and staging table manipulation requests (using user-interface interaction) Migrate Step Step related extract, insert, and parameter data Data M igration System Tables Staging table data Excel Source System Database or Files Sage ERP MAS 500 connection, continue flag, number of records processed, success, failure Insertion Report Log Step entity related data (all records that can be migrated) Extraction Source link, Sage ERP MAS 500 connection, success, failure Data to Migrate Step form, m odifications returned to staging table Staging table data meeting step s Sage ERP MAS 500 business rules Source system data mapped to staging table layout Staging Tables Sage ERP MAS 500 Database Figure 3 - Data Migrator Data Flow Diagram Sage ERP MAS 500 SDK Data Migrator Guide 7

CHAPTER 2 Processes and Communication Details Migration Links This section describes the primary migration processes, the metadata that drives them, and the communication between the processes. Migration links are specific to a particular source system and version, for example, Sage ERP MAS 90 Level 3.61. They are restricted to a single company, so if you want to migrate two Sage ERP MAS 90 companies, you need to either define two migration links, or migrate the first company's data, modify the migration link to point to the second Sage ERP MAS 90 company, and then migrate the second company's data. Migration links are one of four types: Linked server A linked server is a SQL Server object that allows the execution of commands against OLE DB data sources. These can be used to communicate with Sage ERP MAS 200 SQL databases that reside on another server. Same server database Another database located on the same server as the Sage ERP MAS 500 application databases. ProvideX ODBC driver The ODBC driver for Sage ERP MAS 90 and 200 files. Other connection string supported providers These include ODBC and OLE DB providers. If a migration link's source system is one of the natively supported products, the migration link type is determined automatically. Selecting either Sage ERP MAS 90 or 200 results in a ProvideX ODBC type. Selecting Sage ERP MAS 200 results in either a linked server or a database link, depending on whether the source database is on the same server as Sage ERP MAS 500. Custom migration source links support a connection string provider. If the connection string provider is supported by ADO, the common code can be used to obtain the source data; otherwise, another means needs to be employed to put the data into the staging tables. This does not, however, preclude utilizing the communication between the migration process and your extract logic. Migration link data are stored in tsmmigratelink, which is described more fully in the Schema Browser. Migration links require a Migration Source system (for example, an entry in tsmmigratesource). 8 Sage ERP MAS 500 SDK Data Migrator Guide

DATA MIGRATOR ARCHITECTURE Linked Servers Linked servers exist in SQL server at the server level they are not database specific objects; however, Sage ERP MAS 500's migration links are database-specific objects (stored in tsmmigratelink). Because linked servers are not database specific, migration links are not company specific. After defining a migration link in one company, the migration links are available in all Sage ERP MAS 500 companies in that database. In environments with multiple Sage ERP MAS 500 databases on the same server, if you created one database per company, linked servers may exist on the machine that are not known to a particular database (company). To get the migration link definition into additional databases requires redefining it in each database. When you save the migration link in another database on the same server, you will be prompted with a message stating that the migration link already exists (because it is at the server level, not the database level). You must overwrite the migration link to save the definition in the current database. An alternative is to name the migration links differently from one another. Using Migration Links in Assisted Company Setup For an illustration of how a migration link is used, see Figure 4 How Migration Links are Used. In ACS, selecting a product version for which migration links exist, results in the lower drop-down list having the available migration links appear. In this example, selecting Sage ERP MAS 90 ABC points to the network server, Tahoe, where the Sage ERP MAS 200 SQL MAS_ABC company resides. After a migration link is selected, step-sensitive help becomes available and the Migrate button becomes available or unavailable based on the availability of a migration for the current step. Sage ERP MAS 500 SDK Data Migrator Guide 9

CHAPTER 2 If your source system is not one of the supported source systems, you will find that ACS can be used for moving your data into Sage ERP MAS 500. By selecting source system Other and version Any, you can use all of the migration steps; however, there will not be an available extract. You can, however, access the staging tables and use Excel to obtain your source data manually. The data you put into the staging tables using Excel will be available to the insert step. Figure 4 How Migration Links are Used For a description of how to define migration links for custom extractions, see Chapter 3 - Data Migrator Customization. 10 Sage ERP MAS 500 SDK Data Migrator Guide

DATA MIGRATOR ARCHITECTURE Role of Assisted Company Setup in Migration Assisted Company Setup (ACS) supports migrations from predefined source systems. These can be out-of-the-box migrations, or custom migrations. The schema related to ACS migration metadata is shown in the figure below. Selecting a migration source on the Migration System tab in the Assisted Company Setup form is allowed if that product is defined as a migration source in tsmmigratesource. The bottom of the figure shown below illustrates the relationship between the tab and the database table. Selecting a valid migration system relays to ACS to check for the migration system for any step. Selecting a Source Name migration link relays to ACS where the data is located. This step, source system, and migration link information is used by the Migrate <Step Name> process. A phase, such as Inventory, can have multiple steps, and each could have a migration from several source systems (for example, Sage ERP MAS 90 and 200). tsmsetupphase SetupPhaseKey tsmsetupstep SetupStepKey tsm M igratestep SetupStepKey MigrateSourceSystem MigrateSourceVersionNo tsmmigratesource MigrateSourceSystem MigrateSourceVersionNo Figure 5 - ACS Migration Schema Sage ERP MAS 500 SDK Data Migrator Guide 11

CHAPTER 2 Migrate <Step Name> Extraction and Insertion The Migrate <Step Name> process is called by ACS to run a particular step's extractions and insertions. The form's options allow for running either the extract or insert process or both. It is here that the reporting option is also specified. The following information is communicated to this process: Migration link Target or current company in Sage ERP MAS 500 Current step Each step can support multiple, serialized extraction and insertion steps. For example, the extraction might consist of two steps and the insertion might consist of one step. The name, type, and sequence number of each step is stored in the tsmmigratestepextract and tsmmigratestepinsert tables. The type of an extract or insert refers to the software component's type (for example, stored procedure or DLL). This, determines how it is called by ACS. For an illustration of the schema metadata that determines the extraction and insert processes, see Figure 6 - Migrate <Step Name> Metadata. By calling DLL routines in a late bound fashion, they can be named in metadata and unknown until they are called. This is the technique Sage ERP MAS 500 uses to call extraction routines, which are written as Visual Basic COM objects exposing a standardized interface expected by this process. For more details, see Migration Calling Architectural Overview, Extraction Architecture Details, and Insert Architecture Details. In addition to extraction and insertion metadata, there is also metadata for migration parameters. 12 Sage ERP MAS 500 SDK Data Migrator Guide

DATA MIGRATOR ARCHITECTURE Migration Parameters Migration parameters help fix extracted data that fails to meet the Sage ERP MAS 500 business rules. For example, the source system may not require the existence of records in foreign key relationships, such as ZIP Codes that do not exist in the ZIP Code table. If the field is not required in Sage ERP MAS 500, you can be prompted to fail the records that have bad references or blank out the bad references. Another commonly needed parameter is for missing general ledger accounts. If Sage ERP MAS 500 requires an account that is not a supported concept in the source system, then a parameter allows you to choose to set the missing general ledger account to the suspense account. Alternatively, the parameter could allow selection of an existing Sage ERP MAS 500 general ledger account. For more information about parameter definitions and usage, see Migration Parameter Behavior and Metadata. tsmsetupstep SetupStepKey tsmmigratestep SetupStepKey MigrateSourceSystem MigrateSourceVersionNo tsmmigratestepextract SetupStepKey ProcessNo tsmmigratestepinsert SetupStepKey ProcessNo tsmmigratestepparam SetupStepKey ParamNo tsmmigratestepparamuse SetupStepKey ParamNo MigrateSourceSystem Migrate SourceVersionNo Figure 6 - Migrate <Step Name> Metadata After insertion is run, if any reporting was requested, the Migration report appears. The report can be used to refer to the staging tables as an aid to correct failed records. Sage ERP MAS 500 SDK Data Migrator Guide 13

CHAPTER 2 NOTE For large data sets, bringing the data to your PC and moving it between Excel and the Staging Table grid can take a significant amount of time. Excel allows only 65536 rows in a spreadsheet. Staging Table Data The extraction routines place data into staging tables. Before the insert process is run, all of the extracted data is available for review. Running insertion removes successful records from the staging tables, leaving only those records that failed the insert step's business rules. Use the tab in the Migrate <Step Name> form to access the step's data. The figure below shows a sample of the tab. When you select a table from the list, its data is brought to your machine and the total number of rows in the table displays. You can add or delete rows, clear all of the staging tables' data, edit value directly in the grid or edit the data in Excel. Returning modified data from Excel immediately puts the changes into the staging table in the Sage ERP MAS 500 database. tsmsetupstepstage tsmsetupstep StageTableName SetupStepKey Figure 7 - Staging Table Data 14 Sage ERP MAS 500 SDK Data Migrator Guide

DATA MIGRATOR ARCHITECTURE Migration Progress Form The Migration Progress form (illustrated in the figure below) provides feedback while extracts and inserts occur. The Migration Progress form also indicates the number of records to process, the number processed, and the number of failed records. On extraction, if there are any data issues, a report is provided to describe the issue. For example, Sage ERP MAS 90 commissions have the concept of a base commission, while Sage ERP MAS 500 does not; therefore, Sage ERP MAS 90 records with nonzero base commissions are reported, informing you that their base commissions will not be brought into Sage ERP MAS 500. During insertion, which is an asynchronous process, the Done button is replaced with the Stop Processing button, allowing you to stop insertion. Extraction is not asynchronous; therefore, Not Responding may appear in the title bar of the Migration Progress form during extraction. Figure 8 - Migration Progress Form NOTE Information is not recorded about all records, but only for records that were requested. This helps increase the insertion performance by avoiding writing data that will not be used. Migration Error Log When the Insert process is running for a migration step, it logs successes and failures as specified in the reporting option and warning flag. If, for example, you request a report of all failed records, the insert step records information about failed records. The report appears after the insertion is finished and contains the following information: Step Name This is located in the report header. Entity ID Depending on the migration step, this indicates the natural key of the entity being reported on. Several different entities may be involved in a migration; therefore, an understanding of them is required to be able to determine the entity ID. For example, during the Sales Tax Code migration, the entity ID results may be similar to the following: Entity ID CA CA OC The first line's entity ID, CA, refers to the sales tax code staging table's natural key (STaxCodeID), while the second line's entity, CA OC, refers to the sales tax class staging table's compound natural key (STaxCodeID, STaxClassID). The pipe character ( ), is used to separate the different columns in the entity ID of compound key entities. Sage ERP MAS 500 SDK Data Migrator Guide 15

CHAPTER 2 Status Indication of failure, success or warning for the reported row. Column Name of the staging table column related to the entry. This column and the Value column are only populated if a failure or warning occurred, making this column useful for reviewing a report for failed records. Value Data in the staging table column referred to in the previous column. For example, if this is a duplicate record, then the entity ID displays here, because it is the value that caused the duplications. Empty columns that require data appear blank here. Comment The reason for the failure or warning. Successful records will not populate this column. Staging Table Architecture Details The use of staging tables in migration provides a location where source system data can be placed before it is validated against the rigorous business rules of the Sage ERP MAS 500 application. Sage ERP MAS 500 demands a highly reliable, consistent set of data that adheres to strict referential integrity, data type, and value range rules. It would be extremely challenging to move data out of an existing system and simultaneously require that it conform to the business rules of Sage ERP MAS 500. Additionally, the Sage ERP MAS 500 databases are highly normalized and provide maximum flexibility. This normalization has a tradeoff it is difficult for a nontechnical person to understand. Because of these challenges, Sage provides staging tables as the target for source system data extraction. Staging tables resemble their Sage ERP MAS 500 counterparts, but are different in a few significant ways: NOTE The third level was removed from the normalization; the customer address and common address related fields were pulled out to keep the abstraction transparent to any populating of the staging tables. This avoids confusion and a need to fully understand our customer address schema. Surrogate key values do not exist in the staging tables. These are created during insertion. Fields that are numerically enumerated values in the Sage ERP MAS 500 permanent tables have been changed to varchar fields (the SQL Server variable character length field type) in the staging tables. For example, if the field in Sage ERP MAS 500 supports values (0, 1, and 2), which represent (Active, Inactive, Deleted), then the staging table equivalent would be a varchar(8) long enough to support the longest string value equivalent of the enumerated value 1, Inactive. By doing this, the entry of any of the six acceptable values is allowed (0, 1, 2, Active, Inactive, and Deleted). It is expected that extractions will populate these fields with the string value equivalents (for example, Active). The values are converted to the corresponding numeric value on insertion. Where it improves understandability, otherwise normalized data is flattened into the parent table. For example, the Sage ERP MAS 500 customer table references a customer address table, which references our common address table. This three-level normalization allows all addresses to be kept in a single table for referral from different entities, adding addition entity-only related attributes to the joining table (in this case, the customer address table). For example, customer addresses contain a reference to a sales person, which is not applicable to vendor address; they more likely relate to buyers. If, in this case, a source system only supports one customer address, there is no need to populate two staging tables. Even in this case, full functionality has not been removed a customer address table is provided for additional addresses related to a customer. Staging tables do not enforce referential integrity, uniqueness, or any other business rule related consistency. Only the natural SQL Server data type restrictions are enforced. 16 Sage ERP MAS 500 SDK Data Migrator Guide

DATA MIGRATOR ARCHITECTURE All Sage ERP MAS 500 staging tables contain three columns used by the migration processes. Any new staging tables you define must contain these columns to be processed in our migration environment: NOTE Successful rows are deleted from the staging table as they are processed. ProcessStatus Indicates the insertion status of the staging table record. 0 Not processed 2 Failed the insertion process. If a parent record's validation fails, often it will have ProcessStatus 2, while its child records have ProcessStatus 0. Child records are not considered because the parent record is known to be bad. RowKey A unique number identifying this row. This is defined as an identity column so that its value cannot be changed. Example: A staging table has three columns. There are two records in the staging table and the permanent table does not allow duplicates: NOTE It is not required that a row exist in tsmmigratesession to utilize the Sage staging tables, but the SessionKey in the staging table must match that passed into the insertion routine to have the correct data considered for insertion. ID Description Effective Date LowPrice Low priced items 01/01/2002 LowPrice Low priced items 01/01/2002 Technically, the first row is good and the second is a duplicate. When the first row is processed, if deletion is attempted based on its ID, both rows are deleted and duplication is not noticed; therefore, a column that is guaranteed to be unique is needed. SessionKey Migration supports multiple users running the same migration step at the same time. To enable migration to differentiate between two users' data in the staging tables, the concept of the SessionKey is available. Table tsmmigratesession contains the information for a particular session. Migration Calling Architectural Overview This section describes the migration interface that is provided through the Assisted Company Setup (ACS) migration processes. Details of the extraction and insertion functionality and related interfaces are provided in the following sections. Migration Interface: dmmigrateintfc dmmigratintfc.dll contains the migration interfaces needed for extraction. Its inclusion in DLL type extractions and insertions is required. The interfaces it contains are: IExtract The extraction COM interface. For more information about this interface, see Extraction Architecture Details. IInsert The insertion COM interface. For more information about this interface, see Insert Architecture Details. IOwnerMigrate COM Interface supported by extraction callers, for example ACS, to enable communication of progress. dmmigratintfc.dll includes several enumerated types for various parameters. Sage ERP MAS 500 SDK Data Migrator Guide 17

CHAPTER 2 Migration Caller Interface: IOwner NOTE Although this interface is required, at this time, only OnProgress is supported (although Sage migrations do not utilize it). OnProgress causes information to be written into the detailed progress grid on the Migration Progress form. A migration caller supports the following interface, allowing called extractions or insertions to respond back through the available IOwner methods. Public Sub OnError (ByVal EventSource As String, ByVal ErrorCode As Long, ByVal Source As String, ByVal Description As String, ByVal HelpFile As String, ByVal HelpContext As Long, ByVal IDofInterfaceWithError As String, pbcancel As Boolean) Public Sub OnFinish (ByVal EventSource As String) Public Sub OnProgress (ByVal EventSource As String, String, ByVal PercentComplete As Long, ByVal ProgressCountHigh As Long) ByVal ProgressDescription As ByVal ProgressCountLow As Long, Public Sub OnQueryCancel (ByVal EventSource As String, pbcancel As Boolean) Public Sub OnStart (ByVal EventSource As String) Migration Interface Enumerated Types ExtractCallReturnValsEnum Extract DLL or stored procedure return values. Constant Value Description UnknownFailure 0 Error trapped but not enumerated. Success 1 Procedure was successful. This does not mean that all data is correct, only that the process was successful in doing its job of attempting to extract data. Extracting zero records can still result in success. GeneralFailure 2 Nonspecific, fatal error. BadParameters 3 Some parameter is in error, such as required but not supplied. VersionError 4 Unsupported product version. ProductError 5 Unsupported product. TempTableError 6 An issue occurred with a temporary table. For example, it could not be created, or was expected to exist and does not. ConnectionError 7 Unable to connect to the Sage ERP MAS 500 database or the source database given the connection and/or connection information. SourceTableNotFound 8 A source system table, expected to exist, does not. SuccessWithInfo 9 Extraction was successful, but data issues were discovered and recorded in the migration error log. 18 Sage ERP MAS 500 SDK Data Migrator Guide

DATA MIGRATOR ARCHITECTURE ExtractSourceType Indicates what type of source system connection is expected, allowing access to heterogeneous data sources. Certain extraction parameters are interpreted according to this value (for more information, see Start Function). UseDatabase, UseLinkServer, and UseODBC_ProvideX are all supported by the Sage ERP MAS 500 extractions. Constant Value Description UseNeither 0 No connection information supplied. UseLinkServer 1 The connection is expected to be through a linked server, defined on the Sage ERP MAS 500 server (can point to any product supported by SQL Server linked servers and supporting SQL syntax). UseDatabase 2 The connection is expected to be to a SQL Server database on the same server as the Sage ERP MAS 500 application database. UseODBC_ProvideX 3 Sage ERP MAS 90 ProvideX ODBC driver connect type. UseConnectString 4 A free form string used to connect to any provider. This is stored encrypted, so passwords can be safely included. InsertCallReturnValsEnum Insertion DLL or stored procedure return values. Constant Value Description UnknownFailure 0 Error trapped but not enumerated. GeneralFailure 2 Nonspecific, fatal error. Success 1 Procedure was successful. This does not mean that all data is correct, only that the process was successful in doing its job of attempting to insert data. BadParameters 3 Some parameter is in error, such as required but not supplied. InsertDuplicateActionEnum Determines what to do when a duplicate is encountered. Constant Value Description DoNotInsert 0 Fail records that are duplicates. ReplaceExisting 1 Replace duplicate record with this record. Sage ERP MAS 500 SDK Data Migrator Guide 19

CHAPTER 2 InsertInvalidGLAcctActionEnum Determines how the occurrence of invalid general ledger accounts should be handled during insertion. Constant Value Description DoNotInsert 0 If the general ledger account field violates a business rule, do not insert this record. This includes bad general ledger accounts or fields with missing general ledger accounts when required. UseSuspenseAcct 1 Use the suspense account in place of the bad value. InsertInvalidReferenceActionEnum Indicates how invalid references in staging table data should be handled upon insertion. Constant Value Description DoNotInsert 0 Fail records that have invalid foreign key references. UseBlankReference 1 Replace invalid foreign key references with a blank reference. This is only done if the foreign key reference is not required. InsertReportOptionEnum Determines what records to log during the insertion process for a migration step. Constant Value Description All 0 Log both records that succeeded and records that failed insertion. None 1 No migration logging on insertion. Good 2 Only log successful records. Bad 3 Only log failed records. InsertWarningActionEnum Determines what records to log during the insertion process for a migration step. Constant Value Description ExcludeWarnings 0 Exclude warnings from the migration log. IncludeWarnings 1 Include warnings on the migration log. This is only applicable if InsertReportOptionEnum is not equal to None. 20 Sage ERP MAS 500 SDK Data Migrator Guide

DATA MIGRATOR ARCHITECTURE Extraction Architecture Details Extraction routines move source system data to the Sage ERP MAS 500 staging tables. There are two primary technical challenges that shaped the architecture developed for migration extracts. First, because the source data can be in different databases, including file-based structures, extraction requires data retrieval from various data sources. Second, without being able to bookmark the current spot in the extraction data, the technique of getting sets of data (of a predefined size) in a looping construct cannot be used. That is, you cannot get the first 100 records, and then get the next 100 until you are done. The implications of each of these issues are discussed below. The discussion of extraction architecture below is also heavily influenced by the supported configurations (for information on supported configurations, see Figure 2 - Supported Configurations). Heterogeneous Data Sources Issue At first glance, having source system data in different data structures seems like a simple problem to solve because OLEDB and ODBC drivers exist for many data sources. These drivers are not available to stored procedures; however, Data Migrator must support both stored procedure and DLL extracts. To support communication to a remote server through stored procedures, infrastructure was created to use linked servers; however, SQL Server's 6.5 compatibility mode does not support linked server query syntax. To resolve this issue, the following is performed in the Sage extract processes when using linked servers: Move to the MASTER database, which supports the OPENQUERY SQL syntax for linked servers because it is in 8.0 compatibility mode. Create a temporary table copy of the source system tables using the link source SQL statement. By putting the data into a temporary table, the location is always known and a database name does not need to be specified to reference it. Return to the Sage ERP MAS 500 application database. These are important considerations when building your own extracts. Regardless of the link type (Linked Server, database located on the Sage ERP MAS 500 server, ProvideX ODBC, or Connection String), Sage s extractions always place the source data into temporary tables and refer to these when populating the staging tables. Sage ERP MAS 500 SDK Data Migrator Guide 21

CHAPTER 2 Getting Extraction Data in Sets Long processes should provide progress feedback to the user. This includes extracting what may be many thousands of records from a source system. Because there is no way of tagging individual source system records, you cannot stop extracting at some record, mark the current position in the data, inform the user of the progress, and then continue picking up where you left off. (Certainly, there are ways to continue, including knowing the source entity's unique key and using some looping structure.) To help address this issue, Sage decided that by providing a COM-based extraction interface, we can inform the user when a lengthy process is about to start and also inform the user of milestones within the extraction. Alternatively, we can create an asynchronous process, but some data connectivity providers are not asynchronous. As a result, Not Responding may appear in the title bar of the active migration window. To make extraction as quick as possible, we decided that all extraction processes will pull all rows at once, in a set-oriented manner. Sage s extractions must support the extraction COM interface expected by ACS. ACS also supports an extract interface for stored procedures; choose either mechanism for your custom extractions. (Technically, the interface is expected by the Migrate <Step Name> process, which is a DLL called by ACS to perform the extractions and insertions.) There are two interface types that must be supported in an extraction environment: the extraction process must support the extraction interface, allowing the caller to start the extraction routine; and the caller must support the migration communication interface allowing the extraction to communicate status back to the caller. Extraction COM Interface: IExtract To support ACS's migration extraction call, an extraction DLL must support the dmmigrationintfc.iextract interface discussed below, while an extraction stored procedure must support the interface discussed in the Register section. Sage ERP MAS 500 extract DLLs written in Visual Basic expose the interface using Visual Basic's Implements statement. Unfortunately, Implements does not support events; therefore, to mimic the ability to receive events, the caller (ACS) passes a handle (to itself) to the extract class as an IOwnerMigrate interface. This interface supplied by ACS allows the extraction object to communicate status back to ACS. Sage ERP MAS 500 has a COM object that exposes the extraction interface expected by ACS. The extraction interface has three public routines, listed below. Public Function Start (oconn As ADODB.Connection, ByRef bcancel As Boolean, ByVal lsessionkey As Long, ByVal scompanyid As String, ByVal esourcetype As ExtractSourceType, ByVal sappsourcename As String, ByVal ssyssourcename As String, ByVal sappdbname As String, ByVal imigratesourcesystem As Integer, ByVal sversionno As String) As ExtractCallReturnValsEnum Public Sub Register(ByVal Callback As IOwnerMigrate) Public Sub UnRegister() 22 Sage ERP MAS 500 SDK Data Migrator Guide

DATA MIGRATOR ARCHITECTURE Start Function The Start function is called to perform the extraction. For information about enumerated values, see Migration Interface Enumerated Types. Parameter oconn bcancel Description A connection to the Sage ERP MAS 500 application database with the current user's connection information. Note: This connection has the following properties: SET ANSI_NULLS ON SET ANSI_WARNINGS ON Returned to the caller if this process was cancelled. Currently not used. lsessionkey The unique key for this user's session, used to identify their data in the staging tables. scompanyid Company ID of the destination company in Sage ERP MAS 500. esourcetype Determines the type of connection to make to the source system. See Migration Interface Enumerated Types. sappsource ssyssourcename sappdbname imigratesourcesystem sversionno If esourcetype = UseDatabase or UseLinkServer, then this is the application database for the source system. If esourcetype = UseConnectString or UseODBC_ProvideX, then this is the decrypted connection string. If esourcetype = UseDatabase or UseLinkServer, then this is the system database for the source system (which may not be applicable). Unused otherwise. Name of the Sage ERP MAS 500 application database. Valid entries from tsmmigratesource.migratesourcesystem: 0 Other 1 Platinum for Windows 2 Sage ERP MAS 200 SQL 3 Sage ERP MAS 200 client/server 4 Sage ERP MAS 90 Note: Only values 2, 3, and 4 are supported by our extractions. Valid entries from tsmmigratesource.migrateversionno. Sage s extractions support the following levels: 3.6, 3.61, and 3.7 in conjunction with the supported migration source systems supported (shown above for tsmmigratesource.migratesourcesystem) that is: Sage ERP MAS 200 client/server Level 3.6 Sage ERP MAS 200 client/server Level 3.61 Sage ERP MAS 200 client/server Level 3.7 Sage ERP MAS 200 client/server Level 3.71 Sage ERP MAS 200 SQL Level 3.6 Sage ERP MAS 200 SQL Level 3.61 Sage ERP MAS 200 SQL Level 3.7 Sage ERP MAS 200 SQL Level 3.71 Sage ERP MAS 90 Level 3.6 Sage ERP MAS 90 Level 3.61 Sage ERP MAS 90 Level 3.7 Sage ERP MAS 90 Level 3.71 Sage ERP MAS 500 SDK Data Migrator Guide 23

CHAPTER 2 Register Register is used by the caller to pass a reference to itself to the extraction object, allowing it to call the IOwner methods mentioned in Migration Caller Interface: IOwner. UnRegister Releases references to caller. Extraction Stored Procedure Interface The following section describes the interface for extraction stored procedures. For information about enumerated values, see Migration Interface Enumerated Types. CREATE PROCEDURE <ProductName><EntityDescription>Ext (@_isessionkey INTEGER, @_icompanyid CHAR(03), @Product SMALLINT, @VersionNo CHAR(20), @_oretval INTEGER OUTPUT) Parameter Description @_isessionkey The unique key for this user's session, used to identify their data in the staging tables. @_icompanyid Company ID of the destination company in Sage ERP MAS 500. @_iproduct Indicates the product to be extracted from. The expected values are listed in Migration Interface Enumerated Types. @_iversionno @_oretval The version number of the migration source system. This is a string because it can have letters in it, for example 5.0e. Integer indicating the extraction return state. Expected values are listed in the enumeration section under Extraction Return Values. For template examples of using the extraction interface, see Chapter 3 - Data Migrator Customization. 24 Sage ERP MAS 500 SDK Data Migrator Guide

DATA MIGRATOR ARCHITECTURE Insert Architecture Details This section discusses the interfaces and coding style of the migration insertion routines. It also discusses why this architecture was chosen. If you are only interested in the insertion interface, see Insert Stored Procedures Interface without missing prerequisites. Background Information and Overview Insertion routines exist to move data from staging or temporary tables into Sage ERP MAS 500 after validating the records against the insert step's business rules. There are two primary technical issues to recognize when considering the architecture developed for migration inserts. First, because it is likely that large sets of data will be processed, do not bring the data to the client machine. Second, because the process may be lengthy and you may want to cancel it (if, for example, the failed record count becomes too large), the architecture needs to support processing data in chunks. Large Data Set Issue As mentioned in the extraction architecture section, long processes should provide progress feedback to the user. Additionally, because the insertion procedures will be taking large sets of data and moving them into Sage ERP MAS 500, the data should not travel more than is necessary. Because the extraction process described above has already put the data into staging tables located in the Sage ERP MAS 500 application database, Sage strongly suggests the use of stored procedures to validate and insert the data into Sage ERP MAS 500, which will avoid bringing the data to the client machine. Data Migrator uses stored procedures for insertion. Insertion Processing Time Inserting data is more involved than extracting data because each record must be validated before performing the actual insertion. Validations can be quite extensive. Due to the relatively long, per-record processing time for an insertion (when compared to the extraction process' per-record processing time), it is preferable to provide useful feedback to the user. Because you may want to cancel the insertion, an asynchronous behavior is necessary. Data Migrator launches the insertion stored procedures in an asynchronous manner using ADO. This technique allows the Migration Progress form to receive your Cancel button click action and interrupt the insertion. To keep you informed of the insertion progress, the insertion stored procedure interface includes a continue flag, which lets the stored procedure return to the caller, but tell it (for example the Migration Progress form) that there are more rows to insert. The interface also includes a cancel flag, which lets the caller tell the stored procedure that the insertion should be cancelled. To provide feedback, a call to an insertion stored procedure will, in general, return some type of status information approximately every 10 seconds. When you examine the example template, you will notice that it compares the stored procedure start time with the current time and works on a subset of rows from the staging tables hopefully a set that it can process within the 10 second limit. The insertion should stop if 10 seconds has transpired, no more rows are available, or a critical error happened. Sage ERP MAS 500 SDK Data Migrator Guide 25

CHAPTER 2 The previous paragraph stated that feedback is provided approximately every 10 seconds in general. When would this not be the case? As mentioned above, the insertion stored procedures support moving data from temporary tables or staging tables. Two things must be true for an insert API to return to the caller before processing all rows: first, the source data must be in staging tables; second, the temporary tables needed by the insert process must be created before the insert process is called. The first requirement is Sage s. If data is placed in staging tables, the data is processed in 10 second chunks. The second requirement is a limitation of SQL Server cursors regardless of where the data reside (staging tables or temporary tables) Sage places the data into temporary tables and creates cursors based on the temporary tables. Creating and dropping temporary tables used by a stored procedure results in the stored procedure being recompiled, which is time consuming. Additionally, cursors cannot remain allocated for temporary tables that are dropped. Cursors also cannot be repeatedly allocated and de-allocated reliably; therefore, if the insert stored procedure's temporary tables are not created by the caller, all records will be processed before returning. All of the ACS calls to the insertion stored procedures use staging tables. Alternatively, you can put data into local temporary table copies of the staging tables. Chapter 4 - API Reference lists the tables used by each API call; the Schema Browser documents each staging table. Stored procedures are often recompiled when temporary tables that they refer to are created. Since ACS calls the insert API stored procedures repeatedly (every few seconds, if they return with their continue flag set to true), performance is increased if the temporary tables are created outside the stored procedures once at the beginning of the calling loop. The list of temporary tables to create for an insert API are kept in metadata in tsmmigratestepinserttable. It is recommended that you use this same technique of creating the temporary tables used by an API when calling the insertion APIs. If you are calling them in a loop, this will significantly increase their performance. Supplying Useful Feedback Supplying useful insertion feedback is a primary goal of the insert APIs. To achieve this, the migration error log contains detailed information about why a record did not meet the business rules. Each error log entry points to a specific record and gives an explicit reason for failing the data value. Isolation of unexpected, catastrophic errors is also a key goal, but presents a technical challenge. Isolation of Unexpected Errors The most efficient way to process large sets of data is by using SQL Server's set-oriented processing. When doing this, however, the risk of failing a set of records, and not knowing exactly which record caused the failure, is increased. To avoid this issue, Sage ERP MAS 500 insertion APIs insert records one at a time. Set-oriented processing is done in certain cases where the per-record processing time is large and the number of records is also large (given that we expected that there may be a large number of records). Currently, these include the following insertions: items, inventory, posted vouchers, and posted invoices. These insertions process one record at a time if the number of records is less than 250. Although this cursorbased processing takes somewhat longer, it helps ensure a successful insertion without excessive requirements (such as memory or log size) on the SQL Server. Because of the tradeoff between performance and single-record processing, Sage conducted performance benchmark tests of all of the migrations to verify their per-record processing times. 26 Sage ERP MAS 500 SDK Data Migrator Guide

DATA MIGRATOR ARCHITECTURE Research determined the manner that the insertion APIs implement cursors; they are defined FOR UPDATE and are allocated against a clustered index on the staging tables' RowKey field. This maximizes the performance achieved when using cursor-based processing. Most insertion APIs create an index on the primary staging table if it is not already defined, although you may want to define a clustered index on your table if you create your own temporary table for the insertion API. Allocating and deallocating cursors is an expensive operation. To avoid this, cursors are only allocated the first time an insert API is called and deallocated when the API is finished. The cursors are allocated against the local temporary table copy of the staging table (which we create automatically if staging tables are used). If, however, the temporary table is not created outside the API, then the cursor cannot be kept open when the API returns to provide inprogress feedback. To avoid the issue of cursor allocation in this scenario, all records are processed before returning to the caller. Other Common Insertion Behaviors In addition to processing data and returning every two seconds, the insertion stored procedures must have some other common behaviors: Based on the reporting option chosen by the user, errors, warnings, and/or successes must be logged. An issue here is that if the reporting option indicates to log only failed records and while processing a particular record, three warnings are noted, the warnings should only be logged if the record insertion actually fails (because those are the only records the user wants to see information about). Records in the staging tables are deleted, if successful. Records that do not meet the business rules are marked as failed. The insertion routines must support having data passed to them in temporary tables, not just from the staging tables. The temporary tables are still expected to be local temporary tables, with the same name and in the same format as the staging tables. If the caller does not use staging tables, then the two second time limit is ignored; processing continues until all records are considered. Insertion routines must be able to retry record insertion under certain conditions. For example, if an insert fails because an invalid foreign key reference exists and the reference is not required (by Sage ERP MAS 500) and you then decide to use the Replace Invalid References with Blanks option, then the invalid reference should be replaced with a blank and the insert retried. Insert Stored Procedures Interface The stored procedure interface provides status and connection information to the insert APIs, while data is supplied in staging tables. The insertion APIs have the interface shown below. The API name is a guideline for how they are named, specific names can be found in the section listing all of the available APIs. For information about enumerated values, see Migration Interface Enumerated Types. Sage ERP MAS 500 SDK Data Migrator Guide 27

CHAPTER 2 PROCEDURE <moduleid>api<entityname>ins (@_ocontinue SMALLINT OUTPUT, @_icancel SMALLINT, @_isessionkey INTEGER, @_icompanyid CHAR(3), @_irptoption INTEGER = 1, -- Default = Print None @_iprintwarnings SMALLINT = 1, -- Default = Print Warnings @_iusestagetable SMALLINT = 1, -- Default = Use @_orecsprocessed INTEGER OUTPUT, @_ofailedrecs INTEGER OUTPUT, @_ototalrecs INTEGER OUTPUT, @_oretval INTEGER OUTPUT) Migration Parameter Behavior and Metadata Parameter @_ocontinue @_icancel @_isessionkey @_icompanyid @_irptoption @_iprintwarnings @_iusestagetable @_orecsprocessed @_ofailedrecs @_ototalrecs @_oretval Description Returned by the insert routine to indicate that there are more records to be processed. Passed in to tell the routine to do any cancel clean up, for example putting a Cancel notice on the report and stop processing. Unique ID of the session, used to obtain only this user's session data from the shared staging tables. Current Sage ERP MAS 500 company ID. The type of report the user wants. The expected value is one of the InsertReportOptionEnum values. For more information, see InsertReportOptionEnum. Indicates that warnings should be included on the report. This is only applicable if the report option is not NONE. The expected value is one of the InsertWarningActionEnum values. For more information, see InsertReportOptionEnum. If true (1), data is obtained from the staging tables; otherwise, it is assumed to already be populated in local temporary table equivalents of the staging tables this has the same name and structure as the staging tables. The number of records that have been considered for insertion. Each subsequent call to this routine adds to the value passed in; it is not reset to zero. It is set to zero on the initial call. The number of records that have failed validation. Each subsequent call to this routine should add to the value passed in; it is not reset to zero. It is set to zero on the initial call. The number of records to be processed. If zero, then a count in the staging table should be made (if using staging tables); otherwise, leave the passed in value. When using staging tables, the first call should pass zero in this value, which tells the stored procedure that it has not been called yet, so it should do the initialization procedures. This is set to zero on the initial call or unexpected results may occur. Insertion stored procedure return status. The expected value is one of the InsertCallReturnValsEnum values. For more information, see InsertCallReturnValsEnum. 28 Sage ERP MAS 500 SDK Data Migrator Guide

DATA MIGRATOR ARCHITECTURE NOTE The information in this section is provided to help you understand parameters and their metadata; it is not meant to discuss how to add or modify parameters. Migration Parameters describes how migration parameters help enhance the migration behavior to dynamically change data values to meet the business rules. Using parameters can make otherwise noncompliant data meet the Sage ERP MAS 500 business rules. Migration parameter metadata are contained in two tables. The use of parameters consists of obtaining the parameters, selecting a response to the parameter, and applying the parameters. If you use the parameters through the Assisted Company Setup (ACS) interface, their implementation is automatic. Using parameters on your own is an unsupported, advanced technique. Although they can be used to provide enhanced insertion functionality, creating and using your own parameters should be done carefully. In ACS, parameters are displayed on the Migrate <Step Name> form (for more information, see Migration Parameters). In ACS, a user selects one of the parameter values, and the parameter is then either applied to the data immediately after extraction, or it is applied during the insert API. The table that contains parameter definitions for the migration steps is tsmmigratestepparam(refer to the Schema Browser for a complete description of the parameter tables). The table that determines if a parameter applies to a given migration source system is tsmmigratestepparamuse, and the table that contains the selections made by a user for particular parameters is tsmmigratestepparamvalue. tsmmigratestepparam's DfltInStgTable column determines if the parameter value should be put into the staging table before the insertion. For example, if the user selects a general ledger account for the FreightInAccount in the Shipping Method step, the account value chosen appears in the staging table before the insert process is run. To be populated on extract, the following must be true about a parameter and its destination column: The parameter must apply to only one staging table column. The final target column in Sage ERP MAS 500 must be required. The parameter must prompt the user for a value that can be applied directly to the column; the user must have selected the value that will go into the column, not a yes/no question indicating that they want a value that is obtained elsewhere. For example, many steps prompt if you want to use the suspense account for missing general ledger accounts that are required. Answering Use suspense, however, does not indicate what the suspense account is; therefore, this will not be populated until insert. (It is possible to enhance ACS to do this.) When parameters are populated into the staging table on extract, they are also rechecked during insertion; therefore, if you add a new row to the staging table and do not specify the values for the extract parameters column, or you delete values from existing rows, the insert repopulates the missing values. The insert APIs use any available values for parameters that exist in tsmmigratestepparamvalue. You can populate data into this table before you run an insert API to have parameters applied during your application of the API. Parameters values should be populated as described in Parameter Control Types. Sage ERP MAS 500 SDK Data Migrator Guide 29

CHAPTER 2 Parameter Control Types Parameters are displayed to the user on a grid in a certain type of control. By displaying the control to the user and in some cases, providing the user a list of acceptable values (described in the next section), the user's selection can be obtained and made available to the migration routines. The possible parameter control types are as follows: Text Box A field allowing free form entry GL Account The SOTAGLAccount control Date The SOTACalendar control Combo Box (both static and dynamic) Static list uses tsmlistvalidation entries, dynamic list uses values specified in the parameter definition metadata Navigator The SOTALookup control Currency The SOTACurrency control Check Box Uses the grid's check box control Every parameter must be one of the types listed above. Based on the type, other columns in tsmmigratestepparam must adhere to certain rules. In particular, the CtrlAttributes column must conform to a strict layout, depending on the control type. By complying to these rules, the parameters are understood and displayed by ACS. Parameter Values There are four parameter types: Invalid Account Option, Invalid Reference Option, Duplicate Option, and Default Value. The Invalid Account Option determines what to do if a general ledger account is not valid, meaning that the account specified does not exist in the general ledger Account list or no account was specified and one is required. The valid values are listed in InsertInvalidGLAcctActionEnum. Similarly, the Invalid Reference Option and Duplicate Options have a set list of values (see InsertInvalidReferenceActionEnum and InsertDuplicateActionEnum). In general, these three options allow you to choose to fail a record when the situation occurs or to correct it using a standard behavior. Use the suspense account or a blank reference, or update the existing record. All three of these parameters are displayed as check boxes. Default value parameters have specific metadata definition rules, depending on the default parameter type. The metadata definition rules are defined in the next section. 30 Sage ERP MAS 500 SDK Data Migrator Guide

DATA MIGRATOR ARCHITECTURE Parameter Metadata Definition Rules This section provides the metadata rules for default type parameter records. Conforming to these rules enables ACS to properly display and pre-fill any selection choices in the parameter grid. You can skip this section if you do not plan on creating your own parameters. Control Type CtrlDflt CtrlAttributes Text Box Any string Not used GL Account Blank or a valid general Not used ledger account without delimiters Date Blank or a valid date Not used Combo Box Dynamic Blank or one of the values from the value list (not one of the strings). The control attributes determines what appears in the combo box. The format is: Text=<string1>{:<string2>: <st ringn>}; Value=<value1>{:<value2>: <valu en>} For example: "Text=Next:Previous:Today's; Value=0:1:2" Combo Box - Static List index of the value you want to display as the default (from tsmlistvalidation) tsmlistvalidation entry for the table and column of interest. The format is: TableName=<tsmListValidation.T ablename value>; ColumnName=<tsmListValidation.C olumnname value> Navigator Blank Navigator information from tsmnavdefcol in the following format: NavID=<NavigatorID>; TableName=<tsmNavDefCol.TableNa me>; IDColumnName=<tsmNavDefCol.Colu mnname>; KeyColumnName=<TableName's key column>; CompanyColumn=<TableName's companyid column, if exists>; WhichDB=< app or sys = db' where TableName is located> Currency Blank or currency amount Not used Check Box 0 or 1 Not used Sage ERP MAS 500 SDK Data Migrator Guide 31

CHAPTER 2 Naming Conventions <>= Indicates one of several values based, perhaps confined to a certain set <stringx>= <valuex>= {:<entry>}= Any string Any integer value Optional string or value lists 32 Sage ERP MAS 500 SDK Data Migrator Guide

Data Migrator Customization 3 This section describes how to perform the following customization tasks in Data Migrator: Call the APIs Modify or extend the existing migration extractions Add code around insertions Add source system extractions Sage MAS 500 SDK Data Migrator Guide 33

CHAPTER 3 Calling the APIs Determine the API Name To call an API directly from SQL code, you must populate the staging tables or local temporary table equivalents, and then call the API. If you plan to use staging tables and call the APIs in a loop to support their progress-reporting capabilities, prepare any other local temporary tables that the API may use. This improves the performance of the API considerably. Note that the call may take considerable time, depending on the amount of data you are inserting. Use the following steps to determine what data you need to populate, what tables must be created, and the name of the API you must call. NOTE To determine the API name, you can also use sp_depends and point to the staging table. For names of the available APIs, see Chapter 4 - API Reference. You can also find the name of the insertion API for a particular Assisted Company Setup step by running the following SQL statement. This gives you a list of the insert APIs available for a particular setup step. SELECT DISTINCT sp.setupphasename, ss.setupstepname, it.* FROM tsmmigratestepinsert it (NOLOCK) JOIN tsmsetupstep ss (NOLOCK) ON ss.setupstepkey = it.setupstepkey JOIN tsmsetupphase sp (NOLOCK) ON sp.setupphasekey = ss.setupphasekey JOIN tsmmigratestepinsert ms (NOLOCK) ON ss.setupstepkey = ms.setupstepkey WHERE sp.setupphasename like '%<setupphasenamepart>%' AND ss.setupstepname like '%<setupstepnamepart>%' Replace <setupphasenamepart> and <setupstepnamepart> with the appropriate phase and step names. Determine the There are two methods for passing data into the insert API as follows: Put the data into the API's staging tables Put the data into local temporary table copies of the API's staging tables Important: Set the @_iusestagetable parameter to indicate which method you are using for passing data. These columns are common to all staging tables and temporary table equivalents: RowKey ProcessStatus SessionKey This is an identity column. Do not populate it; it is incremented automatically. Should be set to zero to indicate that the record has not been processed yet. If you have populated the tsmmigratesession table (recommended) with session information, use the SessionKey from there. This is not required (you can use any value for the SessionKey except NULL) and it may result in collisions with another user running the same API or in inaccurate migration error log information. 34 Sage MAS 500 SDK Data Migrator Guide

DATA MIGRATOR CUSTOMIZATION Example: Use the following SQL statement to generate a list of the insert API's staging tables for the Closed AR Invoices step of the History phase: SELECT DISTINCT sp.setupphasename, ss.setupstepname, it.* FROM tsmsetupstepstage it (NOLOCK) JOIN tsmsetupstep ss (NOLOCK) ON ss.setupstepkey = it.setupstepkey JOIN tsmsetupphase sp (NOLOCK) ON sp.setupphasekey = ss.setupphasekey JOIN tsmmigratestepinsert ms (NOLOCK) ON ss.setupstepkey = ms.setupstepkey WHERE sp.setupphasename like '%Hist%' AND ss.setupstepname like '%AR%' The result set for this example includes StageTableName column values: StgInvoice StgInvoiceAppl StgInvoiceDetl StgSalesComm StgSTaxCodeTran Passing Data to the API Whether or not you use temporary tables to pass data to the API, you should create the temporary tables. The local temporary tables must match the API tables in both name and structure. For example, define the Vendors temporary tables as follows: SELECT * INTO #StgVendor FROM StgVendor WHERE 1 = 0 SELECT * INTO #StgVendAddr FROM StgVendAddr WHERE 1 = 0 SELECT * INTO #StgVendDocTrnsmit FROM StgVendDocTrnsmit WHERE 1 = 0 SELECT * INTO #StgContact FROM StgContact WHERE 1 = 0 The list of staging tables expected by an API is provided in the next chapter under the API entry. Alternatively, you can look in the metadata in tsmsetupstepstage for the staging tables used by the insertion step. To call the API by passing data in temporary tables, create the temporary tables and populate them with data. To pass data directly to the staging tables, leave the temporary tables empty and insert data into the staging tables before calling the API. When the API is finished, all successful rows are deleted from the staging or temporary tables, all unprocessed rows have ProcessStatus of 0, and all failed rows have ProcessStatus of 2. Sage MAS 500 SDK Data Migrator Guide 35

CHAPTER 3 Maximizing API Performance There are three actions that will help improve the performance of the insertion APIs: Avoid audit logging Minimize migration logging Minimize stored procedure recompilation To minimize migration logging, carefully consider what value you specify for @_irptoption. If you specify All, each insert into the Sage ERP MAS 500 entity will cause an additional insert into the migration log. The Sage ERP MAS 500 APIs use local temporary tables for data storage in many instances. Because stored procedures recompile every time temporary tables are created, creating all of the temporary tables used by the API before calling it will often greatly improve the performance of API calls. This is because the API is recompiled for each temporary table that does not exist when needed, and the APIs often repeatedly call other procedures that use temporary tables. If these tables do not exist, the called procedure may recompile every time it is called. To minimize the recompilation of the APIs, Sage ERP MAS 500 creates all of the temporary tables used by an insertion API before the API is called. The temporary tables that must be created are kept in metadata, in table tsmmigratestepinserttable. The local temporary table should be created based on the template table. For example: SELECT * INTO #<TempTableName> FROM <TemplateTableName> The code block below shows how to find the API, staging tables, and temporary tables needed to call the Inventory Item insert API. If you run this on the Sage ERP MAS 500 database, notice that there are temporary tables other than the staging tables that should be created in this example. print '' print 'The API stored procedure name' print '-----------------------------' SELECT ss.setupstepname, sss.processname FROM tsmmigratestepinsert sss (NOLOCK) JOIN tsmsetupstep ss (NOLOCK) ON sss.setupstepkey = ss.setupstepkey WHERE ss.setupstepname = 'Inventory Items' print '' print 'The ' print '------------------' SELECT sss.stagetablename FROM tsmsetupstepstage sss (NOLOCK) JOIN tsmsetupstep ss (NOLOCK) ON sss.setupstepkey = ss.setupstepkey WHERE ss.setupstepname = 'Inventory Items' print '' print 'Temporary Tables to Create before calling the API' print '-------------------------------------------------' SELECT ss.setupstepname, sss.temptablename, sss.templatetablename FROM tsmmigratestepinserttable sss (NOLOCK) JOIN tsmsetupstep ss (NOLOCK) ON sss.setupstepkey = ss.setupstepkey WHERE ss.setupstepname = 'Inventory Items' 36 Sage MAS 500 SDK Data Migrator Guide

DATA MIGRATOR CUSTOMIZATION Return Values If you run the code example on page 36 for the Reason Code insertion API, you will receive the following information: The API is called spciapireasoncodeins The staging table is called StgReasonCode The single temporary table to be created before calling the API is StgReasonCode The output parameters are described in the following table: @_ocontinue @_orecprocessed @_ofailedrecs @_ototalrecs @_oretval True if there are more records to insert. Call the routine in a loop until this is no longer true (as long as no errors have occurred). Set to 1 on the initial call. The number of records that have been considered for insertion. It is the number of records that have been successfuly processed, plus the number of records that have failed processing. Set to 0 on the initial call. The number of records that have been processed and have not met the business rules. Set to 0 on the initial call. The number of records to be processed. Set to 0 on the initial call or unexpected results may occur. The return value from the stored procedure call. Success means that all processed rows were compared to the business rules and inserted or marked failed appropriately. Populating Migration Parameters Migration parameters enhance the migration behavior by dynamically changing data values to meet the business rules. For more information on how migration parameters are used, see Migration Parameters. Some source system migrations have parameters available to them. These are displayed in the Migrate <Step Name> window and the user-selected values are automatically stored in tsmmigratestepparamvalue. You can insert your own parameter values in this table directly and modify the insertion API to read your parameter values and behave accordingly. To insert a value into tsmmigratestepparamvalue, insert a parent record into tsmmigratesession. The sample code below populates the Budget migration's invalid general ledger account parameter to indicate Use suspense account for the current session. DECLARE @MySessKey int SELECT @MySessKey = COALESCE(MAX(MigrateSessionKey) + 1,1) FROM tsmmigratesession SELECT @MySessKey INSERT INTO tsmmigratesession (MigrateSessionKey, CompanyID, LastCompProcessNo, LastCompProcessMode, LastCompProcessTime, SetupStepKey, StartTime, UserID) VALUES (@MySessKey, 'SOA', 0, 1, NULL, 300700, getdate(), 'admin') INSERT INTO tsmmigratestepparamvalue (MigrateSessionKey, ParamNo, ParamValue, SetupStepKey) VALUES (@mysesskey, 1, 1, 300700) Sage MAS 500 SDK Data Migrator Guide 37

CHAPTER 3 Getting API Error Logs Depending on the reporting option you pass to the API, the error log reports errors, warnings, and successes in the migration log table tdmmigrationlogwrk. This table contains data by SessionKey (which is why SessionKey needs to be unique). You can view the table in any viewer. Order it by EntityID and Status to keep all messages for a particular entity together and to keep all parent-child related records in a group. The EntityID field contains the natural key of the staging table being reported on. The parts of multipart natural keys are separated with the pipe character ( ). Purge the log data when you are finished reviewing it. Example of Calling the APIs The following is an example of calling an insert API: -- Put data into the Staging Table for reason codes. We'll arbitrarily use -- 9999 as the SessionKey. INSERT INTO StgReasonCode (Description, ReasonCodeID, ProcessStatus, SessionKey) VALUES ('Already have one', 'Have1Already', 0, 999) INSERT INTO StgReasonCode (Description, ReasonCodeID, ProcessStatus, SessionKey) VALUES ('Too Hot', '2Hot', 0, 999) INSERT INTO StgReasonCode (Description, ReasonCodeID, ProcessStatus, SessionKey) VALUES ('Too Cold', '2Cold', 0, 999) INSERT INTO StgReasonCode (Description, ReasonCodeID, ProcessStatus, SessionKey) VALUES ('Too Big', '2Big', 0, 999) INSERT INTO StgReasonCode (Description, ReasonCodeID, ProcessStatus, SessionKey) VALUES ('Too Small', '2Small', 0, 999) -- -- Declare the API parameters. DECLARE @ocontinue SMALLINT, @icancel SMALLINT, @isessionkey INT, @icompanyid CHAR(3), @irptoption INT, @iprintwarnings SMALLINT, @iusestagetable SMALLINT, @orecsprocessed INT, @ofailedrecs INT, @ototalrecs INT, @_oretval INT -- Set the call parameters. Use Print All option (generally not recommended) SELECT @icancel = 0, @isessionkey = 999, @icompanyid = 'SOA', @iprintwarnings = 1, @irptoption = 0, @iusestagetable = 1, @ocontinue = 1 -- Create the temporary tables used by the API, including the Staging Table. SELECT * INTO #StgReasonCode FROM StgReasonCode WHERE 1 = 0 WHILE (@ocontinue = 1) BEGIN EXEC spciapireasoncodeins @ocontinue OUTPUT, @icancel, @isessionkey, @icompanyid, @irptoption, @iprintwarnings, @iusestagetable, @orecsprocessed OUTPUT, @ofailedrecs OUTPUT, @ototalrecs OUTPUT, @_oretval OUTPUT IF @ocontinue = 1 SELECT @orecsprocessed, @ofailedrecs, @ototalrecs, @_oretval END PRINT 'Final Return Values' SELECT @orecsprocessed, @ofailedrecs, @ototalrecs, @_oretval PRINT 'MIGRATION LOG' SELECT * FROM tdmmigrationlogwrk WHERE SessionKey = 999 ORDER BY EntityID, Status 38 Sage MAS 500 SDK Data Migrator Guide

DATA MIGRATOR CUSTOMIZATION Creating a New Source System Migration Sage has provided a large number of insertion routines to bring data into Sage ERP MAS 500. You can build extractions to make other business management system data available to these insertion routines. To support migration from a system that Sage ERP MAS 500 does not currently support, you would write the extract routines for the new system and add extraction-related metadata; the insertions will automatically be available. In general, the steps to create a new source system migration are as follows: 1 Create the custom extract procedure. 2 Define a migration link for the source data. 3 Add metadata for the extractions. Create the Custom Extract Procedure Data Migrator supports extractions written as DLLs (preferred) or as stored procedures. A custom extract needs to support the expected interfaces and contain code to move the source data into the staging tables. For a review of the extract interfaces, see Extraction COM Interface: IExtract. Declare References When you write an extraction DLL in Visual Basic, select the following references in the Project menu under References. dmmigrateintfc Microsoft ActiveX Data Objects 2.6 Library Sage Data Migrate Extract Common Routines Required. Contains the extraction and insertion interfaces discussed in an earlier communication section (see Migration Calling Architectural Overview). Required. Microsoft ADO objects. Optional. Contains helpful routines, including routines to move data from a data source to a temporary table and a routine to verify that the source table exists. To use these routines you need a valid connection string. Figure 9 - Extract DLL References Sage MAS 500 SDK Data Migrator Guide 39

CHAPTER 3 Create the DLL To create the DLL, create a project with your extraction class and make it MultiUse. In this example, a simple class is created to fill the Reason Code class. Simple Extraction Code Example Figure 10 - Sample Extract DLL Project In the simplest case, you only need to support the expected interfaces. The example class module code below fills in static values into the Reason Code staging table. The example in Sample Extract Visual Basic Code Template provides a template that is closer to the actual implementation of extractions written for the Sage ERP MAS 90 or 200 to Sage ERP MAS 500 migration steps. The primary difference between this example and the next is that this one does not use the common routines that are available to move data from your source system to temporary tables and then into the staging table (by calling a stored procedure that supports your extract code). This example only puts data into the staging table without help from the common routines and without using the connection string information passed to it. Option Explicit Implements IExtract Const kprocessedcol = 16254 ' This definition is actually located in basstringconstants (STRCONST.BAS) ' ' ocaller is a callback hook to the object that instantiated this class. It ' enables call back behavior through pseudo events, which are not supported ' on the "Implements" interface. Private ocaller As IOwnerMigrate Private Sub IExtract_Register(ByVal Callback As IOwnerMigrate) Set ocaller = Callback End Sub Private Function IExtract_Start (oconn As ADODB.Connection, ByRef bcancel As Boolean, ByVal lsessionkey As Long, ByVal scompanyid As String, ByVal esourcetype As ExtractSourceType, ByVal sappsourcename As String, ByVal ssysappsourcename As String, ByVal sappdbname As String, ByVal imigratesourcesystem As Integer, ByVal sversionno As String) As dmmigrateintfc.extractcallreturnvalsenum ' ' Migrate the data into the staging tables ' Dim lreccount As Long Dim ssql As String On Error GoTo ExtractFailed ' It's most likely that your source type will be "Connection String" If (Not dmvalidsourcetype(esourcetype)) Then IExtract_Start = ExtractCallReturnValsEnum.BadParameters 40 Sage MAS 500 SDK Data Migrator Guide

DATA MIGRATOR CUSTOMIZATION Else ' We just put data directly into the staging table ssql = "INSERT INTO StgReasonCode " & vbcrlf ssql = ssql & "(ReasonCodeID, Description, ProcessStatus, SessionKey)" & bcrlf ssql = ssql & "VALUES ('Because', 'Because I said so', 0, " & CStr(lSessionKey) & ")" ssql = ssql & vbcrlf ssql = ssql & "INSERT INTO StgReasonCode " & vbcrlf ssql = ssql & "(ReasonCodeID, Description, ProcessStatus, SessionKey)" & vbcrlf ssql = ssql & "VALUES ('NotThere', 'Not There Yet', 0, " & CStr(lSessionKey) & ")" ssql = ssql & vbcrlf ssql = ssql & "INSERT INTO StgReasonCode " & vbcrlf ssql = ssql & "(ReasonCodeID, Description, ProcessStatus, SessionKey)" & vbcrlf ssql = ssql & "VALUES ('BedTime', 'It is past your bed time', 0, " & CStr(lSessionKey) & ")" ssql = ssql & vbcrlf ssql = ssql & "INSERT INTO StgReasonCode " & vbcrlf ssql = ssql & "(ReasonCodeID, Description, ProcessStatus, SessionKey)" & vbcrlf ssql = ssql & "VALUES ('Appetite', 'It will ruin your appetite', 0, " & CStr(lSessionKey) & ")" oconn.execute ssql lreccount = 4 ' *** Total number of records processed On Error GoTo ExtractFailed ocaller.onprogress App.Title, dmbuildstring(oconn, kprocessedcol), 100, lreccount, lreccount IExtract_Start = dmmigrateintfc.extractcallreturnvalsenum.success End If Exit Function ExtractFailed: Err.Raise Err End Function Private Sub IExtract_UnRegister() Set ocaller = Nothing End Sub Sample Extract Visual Basic Code Template The sample class module code below provides a basic template for the extracts. It uses the common routines provided with Data Migrator. To use the common routines, put the source data into temporary tables and call a supporting stored procedure that moves data from the temporary tables to the staging tables. The supporting stored procedure for this example is shown in the following section. To make this code example work, change ksourcetable1 to point to a table in your source system named SampleReasonCode, with the columns SampleReasonCode and Description. Option Explicit Implements IExtract Const ksourcetable1 = "<some table name in your data source>" Const kextractprocedure = "spsamplecireasoncodeext Const kprocessedcol = 16254 ' This definition is actually located in basstringconstants (STRCONST.BAS) Sage MAS 500 SDK Data Migrator Guide 41

CHAPTER 3 ' ' ocaller is a callback hook to the object that instantiated this class. It ' enables call back behavior through pseudo events, which are not supported ' on the "Implements" interface. Private ocaller As IOwnerMigrate Private Sub IExtract_Register(ByVal Callback As IOwnerMigrate) Set ocaller = Callback End Sub This is the routine ACS calls to run your code. ' This is the routine that ACS will call to run your code Private Function IExtract_Start(oConn As ADODB.Connection, ByRef bcancel As Boolean, ByVal lsessionkey As Long, _ ByVal scompanyid As String, ByVal esourcetype As ExtractSourceType, _ ByVal sappsourcename As String, ByVal ssysappsourcename As String, _ ByVal sappdbname As String, ByVal imigratesourcesystem As Integer, _ ByVal sversionno As String) As dmmigrateintfc.extractcallreturnvalsenum ' ' Migrate the data into the staging tables ' Dim lreccount As Long Dim sresulttext As String Dim eresult As ExtractCallReturnValsEnum Dim vtables As Variant Dim vtable As Variant This is a list of your source system's permanent tables. On Error GoTo ExtractFailed ' A list of your source system s permanent tables. vtables = Array(kSourceTable1) If (Not dmvalidsourcetype(esourcetype)) Then IExtract_Start = ExtractCallReturnValsEnum.BadParameters Exit Function End If This routine copies your source system data to a temporary table of the same name. Note that oconn is Sage ERP MAS 500's application database. ' *** Move source system data to a temp table For Each vtable In vtables ' This routine copies your source system data to a temporary table ' of the same name. Note that oconn is Sage MAS 500 s app db. eresult = dmdatatotemptable(oconn, sappsourcename, esourcetype, vtable) If (eresult <> ExtractCallReturnValsEnum.Success) Then IExtract_Start = eresult Exit Function End If Next ' *** Total number of records to process lreccount = dmrecordcount(oconn, "#" & ksourcetable1, cttable) If you wrote a stored procedure to move the temporary table data to the staging table, this common routine calls it. ' *** Begin extraction transaction oconn.begintrans On Error GoTo RollbackTrans ' *** Extract data to staging table(s). eresult = dmextractdata(oconn, lsessionkey, scompanyid, imigratesourcesystem, sversionno, kextractprocedure) 42 Sage MAS 500 SDK Data Migrator Guide

DATA MIGRATOR CUSTOMIZATION ' *** Commit extraction transaction oconn.committrans On Error GoTo ExtractFailed ocaller.onprogress App.Title, dmbuildstring(oconn, kprocessedcol), 100, lreccount, lreccount IExtract_Start = eresult Exit Function RollbackTrans: oconn.rollbacktrans ExtractFailed: Err.Raise Err End Function Private Sub IExtract_UnRegister() Set ocaller = Nothing End Sub Sample Extract Supporting Stored Procedure Code Template The code sample shown below can be used as a template to guide your creation of stored procedures that support extraction Visual Basic DLLs. This stored procedure is called by the Reason Code Visual Basic sample to load values into the reason code staging table. Note that this code sample is not an example of a standalone extract stored procedure. That would require a different procedure interface. Instead, this stored procedure is called by the extraction DLL code using the common extraction routine that runs stored procedures. if exists (select * from sysobjects where id = object_id('dbo.spsamplecireasoncodeext') and sysstat & 0xf = 4) drop procedure dbo.spsamplecireasoncodeext GO CREATE PROCEDURE spsamplecireasoncodeext (@_isessionkey INTEGER, @_icompanyid CHAR(03), @Product smallint, @VersionNo char(20), @_oretval INTEGER OUTPUT) AS ---------------------------------------------------------------------------- -- NAME: spsamplecireasoncodeext -- -- DESCRIPTION: Extracts Sample Reason Codes into Sage ERP MAS 500. -- -- ASSUMPTIONS: -- *The staging tables are ready to accept data; -- if this process was run twice, the caller is responsible for -- deleting duplicate information before calling again. -- -- COPYRIGHT: Copyright,(C) 2006 by Sage Software, Inc., -- -- INPUT PARAMETERS: -- @_icompanyid Sage ERP MAS 500 company ID. -- @_isessionkey Identity of the session data to add to the staging tables -- @Product Your source product. -- @VersionNo Your source product's version -- Sage MAS 500 SDK Data Migrator Guide 43

CHAPTER 3 -- OUTPUT PARAMETERS: -- @_oretval Return code ---------------------------------------------------------------------------- BEGIN SET NOCOUNT ON --------------------- CONSTANTS AND VARIABLES DECLARATIONS ---------------- -- Return constants DECLARE @RET_UNKNOWN_ERR SMALLINT, @RET_SUCCESSSMALLINT, @RET_FAILURE SMALLINT, @RET_PARM_ERRSMALLINT, @RET_VERSION_ERR SMALLINT, @RET_PRODUCT_ERRSMALLINT SELECT@RET_UNKNOWN_ERR = 0,@RET_SUCCESS= 1, @RET_FAILURE = 2,@RET_PARM_ERR= 3, @RET_VERSION_ERR = 4,@RET_PRODUCT_ERR= 5 -- Supported Migration Systems DECLARE @MIG_PFW SMALLINT, @MIG_MAS_200 SMALLINT SELECT @MIG_PFW = 1, @MIG_MAS_200= 2 -- Other constants DECLARE @SQL_SUCCESS SMALLINT, @FETCH_SUCCESSFUL SMALLINT, @FETCH_PAST_LAST_ROW SMALLINT, @FETCH_ROW_MISSING SMALLINT, @ACTIVE SMALLINT, @NOT_PROCESSED SMALLINT SELECT @SQL_SUCCESS = 0, @FETCH_SUCCESSFUL = 0, @FETCH_PAST_LAST_ROW = -1, @FETCH_ROW_MISSING = -2, @ACTIVE = 1, @NOT_PROCESSED = 0 -- SP Specific variables = NONE -------------------------------- END CONSTANTS AND DECLARATIONS ----------- -- Initialize SELECT@_oRetVal = @RET_FAILURE --------------------------------------------------------------------------- --PARAMETER VALIDATION IF @_icompanyid IS NULL OR LEN(@_iCompanyID) = 0 OR @_isessionkey IS NULL BEGIN SELECT @_oretval = @RET_PARM_ERR RETURN END --***** END PARAMETER VALIDATION ***** --------------------------------------------------------------------------- -- VALIDATE PRESENCE OF TEMP TABLE IF object_id('tempdb..#samplereasoncode') IS NULL BEGIN SELECT @_oretval = @RET_UNKNOWN_ERR SET NOCOUNT OFF RETURN END --------------------------------------------------------------------------- -- Insert Sample Reason Codes into staging table. INSERT StgReasonCode (ReasonCodeID, Description, ProcessStatus, SessionKey) SELECT SampleReasonCode, Description, @NOT_PROCESSED, @_isessionkey FROM #SampleReasonCode WHERE Cancellation_ReasonCode IS NOT NULL IF @@ERROR <> @SQL_SUCCESS BEGIN SET NOCOUNT OFF RETURN END SELECT @_oretval = @RET_SUCCESS SET NOCOUNT OFF END GO 44 Sage MAS 500 SDK Data Migrator Guide

DATA MIGRATOR CUSTOMIZATION Sample Extract Stored Procedure Code Template The code sample below provides the template for a simple extraction stored procedure. IF object_id('spmyreasoncodeextractaddon') IS NOT NULL DROP PROCEDURE spmyreasoncodeextractaddon GO create procedure spmyreasoncodeextractaddon (@_isessionkey INTEGER, @_icompanyid CHAR(03), @Product SMALLINT,@VersionNo CHAR(20), @_oretval INTEGER OUTPUT) AS BEGIN SET NOCOUNT ON --------------------- CONSTANTS AND VARIABLES DECLARATIONS --------------- -- Return constants DECLARE @RET_UNKNOWN_ERRSMALLINT, @RET_SUCCESS SMALLINT, @RET_FAILURE SMALLINT, @RET_PARM_ERR SMALLINT, @RET_VERSION_ERR SMALLINT, @RET_PRODUCT_ERR SMALLINT, @RET_TEMPTABLE_ERR SMALLINT SELECT@RET_UNKNOWN_ERR = 0, @RET_SUCCESS = 1, @RET_FAILURE = 2, @RET_PARM_ERR = 3, @RET_VERSION_ERR = 4, @RET_PRODUCT_ERR = 5, @RET_TEMPTABLE_ERR = 6 -- Other constants DECLARE@SQL_SUCCESS SMALLINT, @FETCH_SUCCESSFUL SMALLINT, @FETCH_PAST_LAST_ROW SMALLINT, @FETCH_ROW_MISSING SMALLINT, @ACTIVE SMALLINT, @NOT_PROCESSED SMALLINT SELECT@SQL_SUCCESS = 0, @FETCH_SUCCESSFUL = 0, @FETCH_PAST_LAST_ROW= -1, @FETCH_ROW_MISSING = -2, @ACTIVE = 1, @NOT_PROCESSED = 0 -- SP Specific variables. -- Initialize SELECT@_oRetVal = @RET_UNKNOWN_ERR --PARAMETER VALIDATION IF @_icompanyid IS NULL OR LEN(@_iCompanyID) = 0 OR @_isessionkey IS NULL BEGIN SELECT @_oretval = @RET_PARM_ERR RETURN END --***** END PARAMETER VALIDATION ***** -- Your code here. SELECT @_oretval = @RET_SUCCESS END Sage MAS 500 SDK Data Migrator Guide 45

CHAPTER 3 Defining a Migration Link For Your Source System Migration links contain information about the location of source system data and optionally contain access authentication information (user name and password). Migration links are specific to a source system and version. A link is for a particular product, such as Sage ERP MAS 90 and a single version of that product; for example, Level 3.61. NOTE Although you can insert data for other source systems (for example, Other version ACCPAC), you cannot use Setup Migration Links to create links for them - this has to be done using SQL. Sage ERP MAS 500 supports a migration link for source system Other and version Any, which is used for any custom migrations. Migration links are used by ACS to pass source system access information to extraction routines. Even if you obtain your source system access information by some other means (for example, hard coding it in your extraction code), you still must create a migration link. This is because ACS uses the link to determine if it will look for available extractions. To define a migration link for source system Other version Any, use Setup Migration Links to enter the link information as you would for a supported link. When you choose this system/ version, the Migration Link form allows you to specify a SQL Server based or connection string based link. This information is stored in an encrypted form in the database, allowing you to store user name/password information; however, linked server migrations are not encrypted. Add Metadata for Your Extractions Each ACS step can be associated with extractions for many source systems. The figure below illustrates where in the ACS schema this association occurs. To add your extractions to a step, add data to tsmmigratestepextract as shown in the example SQL code below, which creates the entry for the first example extraction class code given on page 47. tsmsetupstep SetupStepKey tsmmigratestep SetupStepKey MigrateSourceSystem MigrateSourceVersionNo tsmmigratestepinsert SetupStepKey ProcessNo tsmmigratestepextract tsmmigratesource SetupStepKey ProcessNo MigrateSourceSystem MigrateSourceVersionNo Figure 11 - Adding Custom Extraction Metadata 46 Sage MAS 500 SDK Data Migrator Guide

DATA MIGRATOR CUSTOMIZATION INSERT INTO tsmmigratestepextract (SetupStepKey, MigrateSourceSystem, MigrateSourceVersionNo, ProcessNo, ProcessType, ProcessDesc, ProcessName) VALUES (200400, 0, 'Any', 1, 1, 'Sample Reason Code Extract', 'SampleReasonCodes.clsMyReasonCodes') Adding Functionality to Existing Extractions and Insertions You can add functionality before or after existing extractions and insertions. For example, if you had added columns to a customer's Sage ERP MAS 90 tables, you can add an extraction step immediately after the existing extraction, which can be designed to bring the additional data into a new staging table. Note that it is much easier to add new staging tables than to modify the existing ones, which can require changes to existing extractions and insertions. Note that in the code to add metadata for an extraction in Add Metadata for Your Extractions, the ProcessNo field value was set to 1. You can determine how many processes (extractions or insertions) are run for a step by looking at existing extractions and you can create additional processes to run after the existing ones. Sample Add-on Extraction Metadata The insert statement below adds the stored procedure shown in Sample Extract Stored Procedure Code Template to the list of processes run for the Reason Code step of any Other/ Any system. Because this is process two (ProcessNo 2), it will run after the first process and before the third process (if a third process exists). INSERT INTO tsmmigratestepextract (SetupStepKey, MigrateSourceSystem, MigrateSourceVersionNo, ProcessNo, ProcessType, ProcessDesc, ProcessName) VALUES (200400, 0, 'Any', 2, 3, 'Sample Reason Code Ext AddOn', 'spmyreasoncodeextractaddon') You can do the same thing on the insertion side by adding records to table tsmmigratestepinsert. Sage MAS 500 SDK Data Migrator Guide 47

CHAPTER 3 Adding a Staging Table to a Migration Step If you have made modifications (in this example, it is assumed that you have made additions to the field set, not deletions) to the data structure of Sage ERP MAS 500 for your implementation, you may need additional staging tables for a migration step. These can be added by creating the staging table, following a few simple rules, and adding metadata for the step as shown below. Staging Table Creation Rules Staging tables must have three columns: RowKey, ProcessStatus, and SessionKey, defined in the following manner: CREATE TABLE StgSample ( RowKey INT IDENTITY (1, 1) NOT NULL CONSTRAINT PK_ROWKEY_CL_dbctest PRIMARY KEY CLUSTERED, <your column definitions>, ProcessStatus smallint NOT NULL, SessionKey int NOT NULL) ALTER TABLE StgSample WITH NOCHECK ADD CONSTRAINT DF_Sample_PS DEFAULT (0) FOR ProcessStatus, CHECK (ProcessStatus = 2 or (ProcessStatus = 1 or ProcessStatus = 0)) The ProcessStatus field allows three values. Although the SessionKey is not allowed to be null, there is no referential integrity to the session table, so you can fill it with any value you want. Insert APIs will consider all records with the same SessionKey as the one passed into them. 48 Sage MAS 500 SDK Data Migrator Guide

API Reference 4 NOTE For information on staging table associations, refer to the Assisted Company Setup Help. This chapter lists the APIs that are used to insert data into Sage ERP MAS 500. The APIs use the interface described in Insert Stored Procedures Interface. In the sections that follow, the API lists are grouped by ACS migration phase. For each API, a description and the staging tables used by the routine are provided. An explanation of each staging table and its columns is provided in the Schema Browser. Balances General Ledger Account Balances spglapiglbalancesins Populates General Ledger account history information, including account reference code and currency related history (if the Multicurrency Management module is activated). StgAcctHist StgAcctHistAcctRef StgAcctHistCurr Sage ERP MAS 500 SDK Data Migrator Guide 49

CHAPTER 2 Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Name Association Between Tables Validation Notes StgAcctHistAcctRef N/A N/A N/A Rows are processed by fiscal year and period. Each row must have valid general ledger accounts and have a balance of debits and credits for each period. StgAcctHistCurr N/A N/A N/A Rows are processed by fiscal year and period. Rows must have valid general ledger accounts and have a balance of debits and credits for each period. StgAcctHist N/A N/A N/A Rows are processed by fiscal year and period. Each row must have valid general ledger accounts and balance in each period. StgGLAcctBegBal StgAcctHistCurr GLAcctNo Rows not in the child table are added during migration with zero debits and credits. StgGLAcctBegBal StgAcctHist GLAcctNo Rows not in the child table are added during migration with zero debits and credits. The StgAcctHistCurr staging table must have a balance of debits and credits for each period. If there are any beginning balance records in StgGLAcctBegBal without a record in StgAcctHistCurr, then a row will be added with a zero balance during migration to StgAcctHistCurr for the beginning balance row. The StgAcctHist table must have a balance of debits and credits for each period. If there are any beginning balance records in StgGLAcctBegBal without a record in StgAcctHist, then a row will be added with a zero balance during migration to StgAcctHist for the beginning balance row. 50 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE Inventory Balances spimapiinvtbalins Populates cost tier and bin information, including cost tier dates, quantities and values, and bin location and quantities. Balances for None, Lot, Serial, and Both tracked items with valuation method of Average, Standard, FIFO, or LIFO are inserted. StgCostTier StgWhseBinInvt Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Name StgCostTier StgWhseBinInvt ItemID, WhseID Association Between Tables One or more cost tiers can be associated with one or more bins. If the Track Quantity At Bin check box is cleared in the Set Up Warehouses window, there is one bin named Default. For counting purposes, the warehouse bin table is considered to be the parent table, but a row is required in each table. Validation Notes Each item serial number must be unique. Inventory Balances Actual Cost Method spimapiinvtbalspecificcostins Populates cost tier and bin information, including cost tier dates, quantities, lots, serial numbers, and cost tier dollar values; and bin location, lots, serial numbers, and quantities. Balances are inserted only for actual tracked items. StgCostTier StgInvtBalances Sage ERP MAS 500 SDK Data Migrator Guide 51

CHAPTER 2 Cash Banks Bank Accounts spcmapibankins Populates Common Information bank information. When you set up banks, you can enter basic information, such as branch, ABA routing number, address, and contact information. StgBank spcmapibankacctins Populates bank accounts and their offsets for existing Common Information banks. For each bank, you can define several bank accounts. For each bank account, you define the account number, the general ledger cash account and, if you have Multicurrency Management, a currency. Each account also contains specific information regarding its deposits and check printing capabilities. For more rapid data entry, you can select the general ledger offset accounts for each transaction type (if you use the Cash Management module). The offset account must be a valid account in the General Ledger chart of accounts. You can: Select a default deposit form and specify the next deposit number Specify check printing for any type of account on which checks may be drawn Select a default check form and specify the next check number for each payment method StgCashAcct StgCashAcctOffset Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Column Name Association Between Tables Table StgCashAcct StgCashAcctOffset CashAcctID The child table can have anywhere from zero to many records. 52 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE Tender Types Customers spcmapibankins Customer Classes Creates payment types that are used during cash receipt processing in the Accounts Receivable module. Tender types can include cash, checks, credit cards, coupons, money orders, or drafts. You can enter multiple credit card types to distinguish among credit card suppliers. StgTenderType sparapicustclassins Defines groups of customers. You can divide customers by types of goods or services they purchase, by product lines, by specific markets, or by different divisions of your company; or you can group all customers in one class. General Ledger accounts can be set up for a class, including the various asset, liability, and expense accounts. You can enter the value of the account override segment selected in Set Up AR Options. StgCustClass Customer Custom Fields spclapiuserfieldins Creates custom field values for customers. StgUserField StgUserFieldValue Sage ERP MAS 500 SDK Data Migrator Guide 53

CHAPTER 2 Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Names StgUserField StgUserFieldValue EntityType, UserFldNo Validation Notes Only a fixed number of user fields are allowed for each entity. Customer Items sparapicustomeritemsins Sets up a cross-reference between the identification or part number that your company uses to track a specific item and the customer identification or part number for that item. Set up customer items by entering the customer, your company's item number, and the customer's item number. The customer item allows the system to automatically match the customer number to the appropriate inventory item when an order is entered, and to produce quotes and sales orders referring to the customer number. stgcustitem Customer Payment Terms sparapipaymenttermsins Inserts payment terms, which determine the terms that apply to items purchased or sold. You can define unlimited payment terms to be used during Accounts Payable and Accounts Receivable transaction processing. When defining payment terms, you can specify: How the due date and discount date are computed for an invoice or voucher Whether an invoice or voucher is due after a certain number of days or months, or by a specific date of the month Whether discounts on freight or taxes for specific payment terms are allowed on an invoice or voucher StgPaymentTerms 54 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE Customer Price Groups Customers sparapicustomerpricegroupsins Inserts pricing records for groups of customers or customer addresses. Use customer price groups and pricing information to maintain pricing information for groups of customers, rather than maintaining pricing records for individual customers and addresses separately. StgCustPriceGroup sparapicustomerins Creates customer information. Enter information that tends to stay the same over time, such as customer name, primary address, and telephone information. You can also enter information that changes, such as customer history, customer ship-to and bill-to addresses, customer status information, and memo information. Customer information includes the following: Defaults. Includes statement forms, statement cycle, billing type, and primary sales account for a specific customer. Specify finance charge percent and/or amount. Maintain Customer Classes provides some of this information. Bill To/Ship To. Specify the default bill-to address number and ship-to address number, the primary salesperson, and billing information, such as payment terms and invoice form. Enter a comment to include on an invoice and sales tax schedule (required). Select shipping defaults; for example, ship via, zone, and F.O.B. Maintain Customer Classes provides some of this information. Sales Order Info. Specify the acknowledgement form, shipping label, packing list, closest warehouse, and sales source. Select whether to allow substitutions and/or complete shipments. Set the average number of days it takes for a customer to receive a shipment. Select the shipping priority, which determines the shipping precedence in the event of conflicting shipments. You must have the Sales Order module installed to enable this tab. StgContact StgCustAddr StgCustDocTrnsmit StgCustomer StgCustSTaxExmpt Sage ERP MAS 500 SDK Data Migrator Guide 55

CHAPTER 2 Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Name Association Between Tables StgCustAddr StgCustSTaxExmpt CustID The child table can have anywhere from zero to many records. StgCustomer StgCustDocTrnsmit CustID The child table can have anywhere from zero to many records. StgCustomer StgContact StgCustomer.CustID = StgContact.CntctOwnerID StgCustAddr StgContact StgCustAddr.CustID = StgContact.CntctOwnerID, Name The child table can have anywhere from zero to many records. The child table can have anywhere from zero to many records. Validation Notes N/A There is one document transmittal record for each transaction type for each customer. Rows are processed by fiscal year and period. Each row must have valid general ledger accounts and balance in each period. The StgContact.Name field is the key to the permanent tcicontact.name table. Contacts are related to addresses if the Name fields are the same in each table. StgCustomer N/A N/A Primary contact There is one primary contact directly associated with the customer. The primary contact information is entered into the Name, Title, Phone, PhoneExt, Fax, and EMailAddr fields in StgCustomer. StgCustomer StgCustAddr N/A The default ship-to address and default bill-to address are entered directly in the StgCustomer table. If the StgCustomer.DfltBillToAddrID and StgCustomer.DfltShipToAddrID fields are blank, then these addresses are automatically set to be the same as the primary address. The primary address is obtained from the AddrLine1, AddrLine2, AddrLine3, AddrLine4, AddrLine 5, City, and StateID fields in StgCustomer. StgCustomer N/A N/A Primary Address The primary address is entered directly into the StgCustomer AddrLine1, AddrLine2, AddrLine3, AddrLine4, AddrLine 5, City, and StateID fields. If the DfltBillToAddrID or DfltShipToAddrID field is blank, it will use the primary address record in tarcustaddr in Sage ERP MAS 500. This means that when the primary address is updated, the default bill-to address and/or default ship-to address is automatically updated as well. If these fields are not blank, they will be located in different address records in Sage ERP MAS 500. Updating one address record will not automatically update the other records. This occurs even if the fields have identical entries. 56 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE StgCustomer StgCustAddr CustID, [StgCustomer.DfltBillTo AddrID = StgCustAddr.CustAddrID] StgCustomer StgCustAddr CustID, StgCustomer.DfltShipTo AddrID = StgCustAddr.CustAddrID] Default bill-to address Default ship-to address StgCustomer StgCustAddr CustID For other addresses, the child table can have anywhere from zero to many records. For the default bill-to address, the StgCustAddr.CustAddrID field cannot equal StgCustomer.CustID. This is considered a duplicate record of the address created from the primary address fields specified above. For the default ship-to address, the StgCustAddr.CustAddrID cannot equal StgCustomer.CustID. This is considered a duplicate record of the address created from the primary address fields specified above. N/A Sales Territories General sparapisalesterritoryins Defines sales territories for your company. Use territories for sorting report information, such as sorting by salespersons or region. This information is used to assign a sales territory to a customer address in Maintain Customers. StgSalesTerritory Commission Classes spciapicommclassins Sets up commission classes. Define both a standard calculation base and a standard commission percent for a single commission class. This information is used during the setup and processing of commission plans. Trade discounts can affect the calculation, depending on whether the Include Trade Discounts in Sales check box is selected in the Set Up AR Options window. StgCommClass Sage ERP MAS 500 SDK Data Migrator Guide 57

CHAPTER 2 Processing Cycles spciapiproccycleins Defines processing frequencies (or cycles) that occur within the system. You can then assign the processing cycles to processes that occur with regular frequency, such as statement processing in the Accounts Receivable module and recurring journals processing in the General Ledger module. StgProcCycle Product Categories Reason Codes spciapiprodcategoryins Creates product categories, to which you can later assign inventory and noninventory items. You can organize product categories in a hierarchy with different levels of categories. The number of product categories and levels you can create is limited by system memory, disk space, and the amount of space for displaying category names in the ecustomer Web site or Enter Sales Orders and Quotes. StgProdCategory spciapireasoncodeins Sets up reason codes, which identify why a specific transaction occurred. Use these codes to identify entries for sales transactions during invoice entry and to identify purchase transactions during voucher entry. StgReasonCode 58 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE General Ledger Allocations spglapiallocateins Establishes allocations. Automatic allocations increase efficiency because the system calculates your distributions when these allocations are processed or posted. Sage ERP MAS 500 supports intercompany general ledger allocations if you select an allocation batch type source (such as GL-AJ) in Maintain Target Companies before making intercompany allocations. StgAllocate StgAllocateDetl Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Names StgAllocate StgAllocateDetl StgAllocate.AllocID = StgAllocateDetl.AllocateID Association Between Tables The child table can have anywhere from zero to many records. Journals spglapijournalins Establishes source journals. Source journals contain transactions originating from the same source; for example, the Accounts Receivable module. These journals are identified by source journal codes. In this task you establish and maintain a code for every journal that you use to record transactions. The journal is then linked to the transaction as the source of its entry, even after the transactions are posted to the general ledger. StgJournal Sage ERP MAS 500 SDK Data Migrator Guide 59

CHAPTER 2 General Ledger Accounts Account Segments Budgets spglapiacctsegmentins Inserts actual account segment values to predefined account segments other than the natural account segment. You can assign multiple segment values to a single account segment. StgSegmentCode spglapibudgetsins Sets up account budgets and budget types. You can set up a budget for each account after defining budget types in Set Up GL Options, or after inserting them with this API. Notes: This API can be used to populate only budget types, only budgets (provided the budget types already exist), or both. If a general ledger natural account's normal balance is a debit (DR), enter the budget amount as a positive number. If a general ledger natural account's normal balance is a credit (CR), enter the budget amount as a negative number. StgBudget StgBudgetType Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Name Association Between Tables StgBudgetType StgBudget BudgetTypeID The child table can have anywhere from zero to many records. 60 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE General Ledger Custom Fields spclapiuserfieldins Creates General Ledger custom field values. StgUserField StgUserFieldValue Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Colum Names StgUserField StgUserFieldValue EntityType, UserFldNo Association Between Tables The child table can have anywhere from zero to many records. Natural Accounts spglapinaturalacctins Inserts natural account segments. Before using this API, the account structure, account groups, and account categories must be defined. This API does not support consolidation information. StgNaturalAcct Sales Tax Accounts spglapisalestaxacctin Enters specific tax information for the current company, such as registration number and tax exemption number for each tax code. You can select the Accounts Receivable sales tax account, and the Accounts Payable sales and use tax accounts (provided the AR/AP Use Sales Tax options are selected). You can also specify whether to use the expense account assigned to the item or specify an account to use to record a nonrecoverable tax amount when calculating taxes. Sage ERP MAS 500 SDK Data Migrator Guide 61

CHAPTER 2 You must select the Track Sales Tax on Purchases check box in the Set Up AP Options window, and/or the Track Sales Tax on Sales check box in the Set Up AR Options window to enable entry of the general ledger accounts for the corresponding fields APTaxAcctNo and ARTaxAcctNo. StgSTaxCodeCompany Global Sales Tax Classes Sales Tax Codes spciapistaxclassins Creates tax classes, which are used to group tax codes and can be used in conjunction with tax codes to determine whether an item is taxable or nontaxable. Tax classes are used with tax codes and tax schedules to determine how to calculate taxes. Each item and shipping record contains a sales tax class to indicate the class of taxes to which it belongs, and which class can be used to determine whether the items are subject to tax. Tax classes are shared across modules and companies. StgSTaxClass spciapistaxcodeins Creates tax codes to identify the tax authorities (or jurisdictions) for which you collect taxes. For each sales tax code, you enter a description, determine if the code is taxable by other tax codes, and whether this tax code and tax code amount appear as a separate total on an invoice when printing. You can define an unlimited number of tax codes. The codes you define can become part of one or more tax schedules. You define tax rates for tax codes as they apply to various tax classes. A tax code may include an unlimited number of tax classes. For each tax class associated with a tax code, you can enter the tax rate and recovery percent, indicate whether to calculate Accounts Payable use taxes, select the tax base to use for tax calculation, and whether to calculate taxes for purchases, sales, or both. This API associates existing tax classes with the new tax codes entered here. The association is done through the Sales Tax Subject Classes staging table (StgSTaxSubjClass). Any range-based information is included in the Sales Tax Subject Class Detail (StgSTaxSubjClassDt) staging table, which provides different rates or amounts for different sales amount ranges. 62 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE StgSTaxCode StgSTaxSubjClass StgSTaxSubjClassDt Sales Tax Schedules Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table spciapistaxscheduleins Creates groupings of sales tax codes, referred to as sales tax schedules. To calculate sales tax, a sales tax schedule must be assigned to all Accounts Payable vendors and Accounts Receivable customers; however, the tax schedule can be changed during invoice or voucher entry. Schedules are required if Track Sales Tax on Sales (AR) or Track Sales Tax on Purchases (AP) is selected in the appropriate module's setup options. For each sales tax schedule, you enter an ID, a description, and the applicable sales tax codes. Often, sales tax codes are grouped in a schedule according to geographic areas. For example, a sales tax schedule can include a state, county, and local tax. Later, you assign sales tax schedules to entities (for example, customers or vendors) to indicate the sales taxes they are subject to pay. Notes: Taxes are calculated according to the order that the tax codes are listed in the schedule. When creating sales tax schedules, the taxable tax code sequence numbers should precede the tax-on-tax code sequence numbers. If a tax code in the list is taxable, then the tax codes that follow are included in the tax base. That is, you can have a tax on a tax. Sales taxes are shared across modules and companies. StgSTaxSchdCodes StgSTaxSchedule Child Staging Table Column Names Association Between Tables StgSTaxCode StgSTaxSubjClass STaxCodeID The child table can have anywhere from zero to many records. StgSTaxSubjClass StgSTaxSubjClassDt STaxCodeID, STaxClassID The child table can have anywhere from zero to many records. Sage ERP MAS 500 SDK Data Migrator Guide 63

CHAPTER 2 Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Name Association Between Tables StgSTaxSchedule StgSTaxSchdCodes STaxSchdID The child table can have anywhere from zero to many records. Validation Notes The StgSTaxSchdCodes.STaxCode ID field must contain an existing sales tax code ID. History Closed AP Invoices spapapiapinvoiceins Inserts Accounts Payable invoices that have been posted. The General Ledger module is not affected. StgSTaxCodeTran StgVoucher StgVoucherAppl StgVoucherDetl Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Name Association Between Tables StgVoucher StgVoucherDetl TranNo, TranTypeID The child table can have anywhere from zero to many records. StgVoucher StgSTaxCodeTran StgVoucher.TranNo = StgSTaxCodeTran.DocNo, TranTypeID StgVoucher StgVoucherAppl StgVoucher.TranNo = StgVoucherAppl.ApplyToTranNo, TranTypeID The child table can have anywhere from zero to many records. The child table can have anywhere from zero to many records. Validation Notes N/A The StgSTaxCodeTran table creates both a tcistaxtran record associated with the invoice and a tcistaxcodetran record. N/A 64 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE Closed AR Invoices sparapipostedinvcins Inserts posted and paid Accounts Receivable invoices. The General Ledger module is not affected. StgInvoice StgInvoiceAppl StgInvoiceDetl StgSalesComm StgSTaxCodev Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Name Association Between Tables StgInvoice StgInvoiceDetl TranNo, TranTypeID The child table can have anywhere from zero to many records. StgInvoice StgSTaxCodeTran StgVoucher.TranNo = StgSTaxCodeTran.DocNo, TranTypeID The child table can have anywhere from zero to many records. StgInvoice StgSalesComm TranNo, TranTypeID The child table can have anywhere from zero to many records. StgInvoice StgInvoiceAppl StgInvoice.TranNo = StgInvoiceAppl.ApplyToTran No, TranTypeID The child table can have anywhere from zero to many records. Validation Notes N/A The StgSTaxCodeTran table creates both a tcistaxtran record associated with the invoice and a tcistaxcodetran record. N/A Both memo applications and customer payment applications have records in this table. After inserting the StgInvoice, StgInvoiceDetl, StgSTaxCodeTran, StgSalesComm, and StgInvoiceAppl records, the migration routine searches for tarcustpmt records that match the invoice application records. When records are found, it updates the ApplyFromPmtKey record in the tarinvoiceappl table and the ApplyToInvcKey record in the tarcustpmtappl table. Sage ERP MAS 500 SDK Data Migrator Guide 65

CHAPTER 2 Closed Purchase Orders StgInvoiceAppl StgCustPmt StgInvoiceAppl.ApplyFrom TranID = StgCustPmt.CustPmtNo, ApplyFromTranDate, CustID StgCustPmt StgCustPmtAppl CustPmtNo, ApplyFromTranDate, CustID sppoapipurchordins The child table can have anywhere from zero to many records. The child table can have anywhere from zero to many records. Customer payments in StgCustPmt with the CustPmtNo, ApplyFromTranDate, and CustID fields matching StgInvoiceAppl.ApplyFromTr anid will be associated with those invoice application records; however, payments do not require an invoice or an application. They can be created with an association to the customer only. Only customer payment applications have records in this table. After inserting the StgCustPmt and StgCustPmtAppl records, the migration routine looks for tarinvoice records that match the customer payment application records. When records are found, it updates the ApplyToInvcKey record in the tarcustpmtappl table and the ApplyFromPmtKey record in the tarinvoiceappl table. If the parent payment record for a child paymentapplication record is not found in StgCustPmt, but is found in tarcustpmt in Sage ERP MAS 500, then the child payment application record is considered valid. Enters detail information for both open and closed purchase orders. Standard purchase orders are legal documents that authorize a supplier to deliver ordered goods and submit a bill based on specified terms and conditions. StgPurchaseOrder StgPOLine Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Names Association Between Tables StgPurchaseOrder StgPOLine TranNo The child table can have anywhere from zero to many records. 66 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE Closed Sales Orders spsoapisalesordins Enters detail information for both open and closed sales orders. StgSalesOrder StgSOLine Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. General Ledger Transactions spglapigltransactionsins Inventory History Staging Table Moves posted general ledger transactions into the General Ledger module. StgGlTransaction spimapiinvthistins Moves the records into the primary inventory history tables, including the calendar period and fiscal period history tables. The spimapiinvthistins API call does not affect the General Ledger module. StgInvHist Child Staging Table Column Names Association Between Tables StgSalesOrder StgSOLine TranNo The child table can have anywhere from zero to many records. Sage ERP MAS 500 SDK Data Migrator Guide 67

CHAPTER 2 spimreconcileinvthist Creates additional history information as needed to balance with the inventory cost tiers. Note that even though the spimapilinvthistins API moves history into the primary inventory history table, it does not guarantee that it balances with the inventory cost tiers. The spimreconcileinvhist API will create a balancing transaction. The spimreconcileinvhist API is not a standard insertion API and therefore, does not have the standard API interface. Instead, it supports the following parameters: @icompanyid - CHAR(3) @irecalctype - SMALLINT. Use value 3, which indicates that both the fiscal and calendar period history tables should be recalculated from the timinvthist table (the primary inventory history table). @iadjusthistory - SMALLINT. Indicates that timinvthist should be adjusted for any balance discrepancy. The expected value should be 1. An example of the variable declarations and call to this routine follows: DECLARE @icompanyid CHAR (3),@iRecalcType SMALLINT,@iAdjustHistory SMALLINT,@oRetVal INTEGER SELECT @icompanyid = SOA, @irecalctype = 3, @iadjusthistory = 1 EXECUTE spimreconcileinvthist @icompanyid, @irecalctype, @iadjusthistory, @oretval OUTPUT Inventory Inventory spimapiinventoryins Creates inventory information for a particular item and warehouse combination. In addition, replenishment and stocking parameters can be specified to help manage the inventory's stock in multiple locations. Carefully chosen information prevents both excess inventory in any location and frequent stock-outs. Inventory information includes: Unit cost information Whether back orders are allowed Physical count cycles Preferred bin locations 68 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE You also enter defaults, as needed, for replenishment information that include: Purchase product line Buyer Replenishment formulas, such as demand, safety stock, and lead time formulas IDs Replenishment parameters, such as minimum or maximum stock, replenishment cost, and reorder method StgInventory StgInvtBinList Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Inventory Item Class spimapiinvtitemclassins Sets up item classes. An item class consists of an item class code, a description, and a set of general ledger accounts. Item classes must be set up before items can be created, because each item must be associated with an item class. When you set up item classes, the accounts you enter must exist in the general ledger chart of accounts. These four accounts are required to define an item class: Sales, Returns, Inventory, and Cost of Goods Sold. The remaining accounts are optional. When you set up an inventory item, the item class accounts are the default accounts. StgItemClass Child Staging Table Column Names Association Between Tables StgInventory StgInvtBinList ItemID, WhseID The child table can have anywhere from zero to many records. Sage ERP MAS 500 SDK Data Migrator Guide 69

CHAPTER 2 Inventory Items spimapiitemins Defines the items used in inventory transactions, including sales and purchase orders, and Internet order processing. An item is a product or service sold by a company. There are several item categories but, in general, items are considered either inventory or noninventory items. Inventory items can be purchased and sold, and are stocked in warehouses to be available for transactions. Item information is the same for all warehouses that stock it. Define the following item information: NOTE Substitute items cannot be defined using this API. General identifying information about the item, including cost and valuation Unit price (UOM) definitions Sale and purchasing definitions General ledger accounts for noninventory items Product categories Build-to-order (BTO) kit definitions (as applicable) Use Maintain Items to specify the following: Allow returns Allow drop ship Allow cost override Allow price override Require receipt Require internal delivery Allow decimal quantities Subject to trade discount Include on packing list Apply a landed cost to an item, basing the estimates on a percentage of the item's cost or on a flat amount. (Landed costs parameters are defined in Set Up Landed Cost. Landed cost is an estimate of the actual charges or costs of an item, such as the delivery costs.) Select the stocking, purchasing, selling, and pricing units of measure; and the conversion factors for the units of measure. If the unit of measure for purchase, sales, or price is not the stock unit of measure, the purchase, sales, or price unit of measure is listed as a target unit of measure. You must define a conversion factor. Define the components and quantities needed for assembly into build-to-order (BTO) and assembled kits. You can also specify if customized and partial kits can be returned. 70 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE Select general ledger accounts for miscellaneous item type items. These accounts are used when posting the sale of an item for the cost of goods sold, expense, sales, and returns. If you plan to sell the item through the ecustomer Web site, you can assign the item to product groups to organize merchandise, add a long description of the item, and select an image of the item to appear on the Web site. StgItem StgItemUnitOfMeas StgKitCompList StgProdCatItem Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Name Association Between Tables StgItem StgProdCatItem ItemID The child table can have anywhere from zero to many records. Validation Notes StgItem N/A N/A N/A The three required units of measure (UOM) are stock, price, and sale. These UOMs are entered directly in the StockUnitMeasID, PriceUnitMeasID, and SaleUnitMeasID fields in StgItem. StgItem StgItemUnitOfMeas ItemID The child table can have anywhere from zero to many records. N/A N/A StgVoucher StgVoucherAppl StgItem.ItemID = StgKitCompList.KitItemID The child table can have anywhere from zero to many records. This table is valid only for items with an ItemType of Assembled or Built to Order Kit. Sage ERP MAS 500 SDK Data Migrator Guide 71

CHAPTER 2 Warehouse Bin Warehouses spimapiwhsebinins Sets up bins to use in your warehouses. You can specify volume, weight, and count cycle for a bin. You must assign a type to each bin and each type. Bin types can be: Fixed. A bin used for a specific item you want to store in the same location each time you receive the item. A fixed bin can also be a preferred bin. Multiple fixed bins can be associated with the same item. Random. A bin that is not associated with any item. This bin can be associated only with one item at a time and can have items added only if it is empty or if the item added is the same item that is currently in the bin. Random bins are available only if you select the Track Quantity At Bin check box in the Set Up Warehouses window. A random bin cannot be a preferred bin. Staging. A bin to temporarily hold items that decrease inventory (except for returns), but is not used in transactions (that is, sales, issues, or transfers). A staging bin can contain any item and multiple items simultaneously. Items in a staging bin are considered on-hand for valuation, but are not available for fulfillment. They can be a preferred bin. StgWhseBin spimapiwarehouseins Sets up warehouses. You can set up an unlimited number of warehouses for each company, but you must set up at least one. Warehouses can be designated as shipping, receiving, or transit (an interim holding warehouse for transferring products); however, you cannot use bins, costing, or pricing for a transit warehouse. StgWarehouse 72 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE Items Freight Classes spimapifreightclassins Sets up the delivery methods to use when shipping items. StgFrieghtClass Item Custom Fields spclapiuserfieldins Creates item custom field values. StgUserField StgUserFieldValue Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Names StgUserField StgUserFieldValue EntityType, UserFldNo Association Between Tables The child table can have anywhere from zero to many records. Noninventory Item Class spimapinoninvtitemclassins Sets up noninventory item classes. StgItemClass Sage ERP MAS 500 SDK Data Migrator Guide 73

CHAPTER 2 Noninventory Items spimapiitemins Defines the noninventory items used during transaction processing. You can maintain four types of noninventory items: Miscellaneous items can be purchased, sold, or both Expense items can be purchased only Service items can be sold only Comment enables you to enter comments that appear on transactions StgItem StgProdCatItem Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Product Price Groups spimapiprodpricegroupins Sets up product price group names and descriptions. The pricing rules are set up using the Product Group Pricing API. See Product Group Pricing. StgProdPriceGroup Child Staging Table Column Names Association Between Tables StgItem StgProdCatItem ItemID The child table can have anywhere from zero to many records. 74 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE Purchase Product Line spimapipurchprodlineins Sales Product Line Enters purchase product lines, which help group inventory items on a purchase order to accurately calculate order cycles and meet minimum order quantities. When an item approaches its reorder point, the other items in the purchase product line can also be reviewed to make an efficient purchase from a vendor. You can assign a buyer to a purchase product line and indicate the seasonal start and ending dates. You can further define reorder requirements for a specific warehouse in the Set Up Warehouse Replenishment task. StgPurchProdLine spimapisalesprodlineins Manufacturing Employees Sets up product lines that you can use to group inventory items to analyze for sales purposes. You can allow price overrides and specify whether the product line is subject to trade discounts. You can enter the target gross margin percent, and select the commission class and the override segment for the sales product line. StgSalesProdLine spmfapiemployeeins Enters employee information. Enter the employee ID, employee name, shift on which the employee is assigned, hourly rate, and whether the employee is active. The employee can then be selected in tasks throughout Manufacturing. StgEmployee Sage ERP MAS 500 SDK Data Migrator Guide 75

CHAPTER 2 Operations spmfapioperationins Defines operation codes. Operation codes identify the type of operation to be performed, such as stamping and painting. For each operation code, select the operation cost type (labor, material, outside processing, or other), whether the operation cost type updates work in process, and the work center that runs this operation. StgOperation Routings spmfapiroutingsins Defines the process of producing an individual or multiple finished good items. Each new routing requires a unique routing ID and version ID combination. The production steps and the operations to be performed, such as material, labor, or outside, can also be specified. You can indicate backflush for material and labor steps, which does the following: Material backflushing automatically requisitions material to the job based on the standard material requirement defined for the routing and applies the cost to the work order. Labor backflushing automatically applies labor and burden to the cost of the work order based on the standard routing definitions. StgRoutDetl StgRoutHead StgRoutProd Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Names Association Between Tables StgRoutHead StgRoutDetl RoutingId, VersionID The child table can have anywhere from zero to many records. StgRoutHead StgRoutProd RoutingId, VersionID The child table can have anywhere from zero to many records. 76 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE Tools spmfapitoolsins Defines tooling used in the manufacturing process. StgTools Work Centers Open Orders Purchase Orders spmfapiworkcenterins Sets up work centers used during manufacturing transaction processing. For each work center, select a valid department and facility. Enter rates used for job costing, work-in-process and scheduling information. StgWorkCenter sppoapipurchordins Enters detail information for both open and closed purchase orders. Standard purchase orders are legal documents that authorize a supplier to deliver ordered goods and submit a bill based on specified terms and conditions. StgPurchaseOrder StgPOLine Sage ERP MAS 500 SDK Data Migrator Guide 77

CHAPTER 2 Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Names Association Between Tables StgPurchaseOrder StgPOLine TranNo The child table can have anywhere from zero to many records. Sales Orders spsoapisalesorderins Enters detail information for both open and closed sales orders. StgSalesOrder StgSOLine Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Open Transactions Bank Account Transactions spcmapicashtranins Enters cash transactions for a bank account. A statement is automatically generated for each cash account. StgCashTran Child Staging Table Column Names Association Between Tables StgSalesOrder StgSOLine TranNo The child table can have anywhere from zero to many records. 78 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE Open AP Invoices spapapiapinvoiceins Enters posted, unpaid, or partially-paid Accounts Payable invoices. StgSTaxCodeTran StgVoucher StgVoucherAppl StgVoucherDetl Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Name Association Between Tables StgVoucher StgVoucherDetl TranNo, TranTypeID The child table can have anywhere from zero to many records. StgVoucher StgSTaxCodeTran StgVoucher.TranNo = StgSTaxCodeTran.DocNo, TranTypeID StgVoucher StgVoucherAppl StgVoucher.TranNo = StgVoucherAppl.ApplyToTranNo, TranTypeID The child table can have anywhere from zero to many records. The child table can have anywhere from zero to many records. Validation Notes N/A The StgSTaxCodeTran table creates both a tcistaxtran record associated with the invoice and a tcistaxcodetran record. N/A Open AR Invoices sparapipostedinvcins Enters posted, unpaid, or partially-paid Accounts Receivable invoices. StgInvoice StgInvoiceAppl StgInvoiceDetl StgSalesComm StgSTaxCodeTran Sage ERP MAS 500 SDK Data Migrator Guide 79

CHAPTER 2 Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Name Association Between Tables StgInvoice StgInvoiceDetl TranNo, TranTypeID The child table can have anywhere from zero to many records. StgInvoice StgSalesComm TranNo, TranTypeID The child table can have anywhere from zero to many records. StgInvoice StgSTaxCodeTran StgVoucher.TranNo = StgSTaxCodeTran.DocNo, TranTypeID StgInvoice StgInvoiceAppl StgInvoice.TranNo = StgInvoiceAppl.ApplyToTran No, TranTypeID StgInvoiceAppl StgCustPmt StgInvoiceAppl.ApplyFrom TranID = StgCustPmt.CustPmtNo, ApplyFromTranDate, CustID StgCustPmt StgCustPmtAppl CustPmtNo, ApplyFromTranDate, CustID The child table can have anywhere from zero to many records. The child table can have anywhere from zero to many records. The child table can have anywhere from zero to many records. The child table can have anywhere from zero to many records. Validation Notes N/A N/A The StgSTaxCodeTran table creates both a tcistaxtran record associated with the invoice and a tcistaxcodetran record. Both memo applications and customer payment applications have records in this table. After inserting the StgInvoice, StgInvoiceDetl, StgSTaxCodeTran, StgSalesComm, and StgInvoiceAppl records, the migration routine searches for tarcustpmt records that match the invoice application records. When records are found, it updates the ApplyFromPmtKey record in the tarinvoiceappl table and the ApplyToInvcKey record in the tarcustpmtappl table. Customer payments in StgCustPmt with the CustPmtNo, ApplyFromTranDate, and CustID fields matching StgInvoiceAppl.ApplyFromTra nid will be associated with those invoice application records; however, payments do not require an invoice or an application. They can be created with an association to the customer only. Only customer payment applications have records in this table. After inserting the StgCustPmt and StgCustPmtAppl records, the migration routine looks for tarinvoice records that match the customer payment application records. When records are found, it updates the ApplyToInvcKey record in the tarcustpmtappl table and the ApplyFromPmtKey record in the tarinvoiceappl table. If the parent payment record for a child paymentapplication record is not found in StgCustPmt, but is found in tarcustpmt in Sage ERP MAS 500, then the child payment application record is considered valid. 80 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE Pricing Customer (Contract) Pricing spimapicontractpricingins Sets up customer-specific pricing strategies. You can specify pricing for customers buying a particular inventory item or the inventory items assigned to a product price group. You can maintain an unlimited number of price breaks for each product price group or item based on quantity, monetary amount, weight, or volume; or you can establish a fixed amount for the price discount. You define the structure of the contract price record for both the product price group and the item. Each record contains: An effective and expiration date The discount price method A price base A price break associated with the break type StgCustItemPrice StgCustProdGrpPrc StgPriceBreak Sage ERP MAS 500 SDK Data Migrator Guide 81

CHAPTER 2 Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Matrix Pricing by Product Price Group spimapicpgpricingins Sets up customer group pricing to product group pricing. Price base options include the customer price sheet and the price sheets on the list price, replacement cost, moving average cost, and standard cost. You can enter a discount percent and a price break, depending on the break type. StgPriceBreak StgPriceGroupPrice Child Staging Table Staging Table Association Column Names Association Between Tables StgCustItemPrice StgPriceBreak PricingID The child table can have anywhere from zero to many records. StgCustProdGrpPrc StgPriceBreak PricingID The child table can have anywhere from zero to many records. StgCustProdGrpPrc StgCustItemPrice N/A These tables are not related, even though they are in the same migration. Each table is processed as an individual set of data. If records in each table have the same CustID, CustAddrID, and WhseID, they are associated with the same customer contract. The two tables can each have their own price break information, or share price break information. Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Names Association Between Tables StgPriceGroupPrice StgPriceBreak PricingID The child table can have anywhere from zero to many records. 82 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE Matrix Pricing by Customer Group Price Sheets See Matrix Pricing by Product Price Group. spimapipricesheetins Defines the price sheets (named pricing lists; for example, Customer Prices or Employee Prices) and the price sheet prices. Price sheets contain the base prices a company uses to price sales orders. Because your company may maintain different base prices for different types of customers, you can maintain a list price and up to four additional price types (or sheets) for each item. The costs in each column of the price sheet are entered in the pricing unit of measure. StgPriceSheet StgPriceSheetNames Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Product Group Pricing spimapippgpricingins Enters pricing rules, including price breaks, for a Product Price Group. StgPriceBreak StgProdPriceGroupPrice Child Staging Table Column Names Association Between Tables StgPriceGroupPrice StgPriceBreak PricingID The child table can have anywhere from zero to many records. Sage ERP MAS 500 SDK Data Migrator Guide 83

CHAPTER 2 Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Purchasing Buyers Staging Table sppoapibuyerins Sets up the persons responsible for purchasing items from a vendor for the current company. StgBuyer Purchase Order Custom Fields spclapiuserfieldins Creates purchase custom field values. StgUserField StgUserFieldValue Staging Table Association Child Staging Table Column Names Association Between Tables StgProdPriceGroupPrice StgPriceBreak PricingID The child table can have anywhere from zero to many records. Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Names StgUserField StgUserFieldValue EntityType, UserFldNo Association Between Tables The child table can have anywhere from zero to many records. 84 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE Purchase Order Departments Sales sppoapipurchdepartmentins Sets up departments. Department information consists of address name, department address, contact name, and contact information. Use this information to set up contacts and ship-to addresses on purchase orders and requisitions. StgPurchDepartment Sales Transaction Custom Fields spclapiuserfieldins Creates sales transaction custom field values. StgUserField StgUserFieldValue Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Names StgUserField StgUserFieldValue EntityType, UserFldNo Association Between Tables The child table can have anywhere from zero to many records. Sage ERP MAS 500 SDK Data Migrator Guide 85

CHAPTER 2 Shipping Methods spciapishipmethodins Sets up shipping methods, which define the manner in which items are shipped to customers or how items should be shipped from vendors. When you define shipping methods, you enter a description of the shipping method, specify the general ledger incoming and outgoing freight accounts, and specify the sales tax class. StgShipMethod Sales Organizations Sales Commissions sparapicommplanins Sets up commission plans. Commission plans, along with commission classes, determine the commission paid and the sales revenue credited to each salesperson. You can also enter the sales manager's commission percent, if any. You can assign a salesperson to more than one commission plan, including a default plan. You can also set up a commission plan without assigning it to a specific salesperson. StgCommPlan StgCommPlanCalc StgCommPlanSplit StgSperDfltCommPlan 86 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Name Association Between Tables StgCommPlan StgCommPlanCalc CommPlanID The child table can have anywhere from zero to many records. StgCommPlan StgCommPlanSplit CommPlanID The child table can have anywhere from zero to many records. StgCommPlan StgSperDfltCommPlan CommPlanID, tarsalesperson.sperid = StgSperDlftCommPlan. SperID The child table can have anywhere from zero to many records. Validation Notes N/A N/A After the commission plans are inserted into Sage ERP MAS 500, the StgSperDfltCommPlan table is used to update tarsalesperson.commplank ey. The tarsalesperson file is populated from a previous migration step (Sales Organizations > Salespersons) using the StgSalesPerson table; however, commission information is not available until the Sales Commission Plans step is completed. Sales Teams sparapisalesteamins Creates sales teams and/or adds salespersons to sales teams. Salespeople in a team can be given rights to view and process orders for customers of other salespeople on a team. StgSalesTeam StgSalesTeamMember Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Names Association Between Tables StgSalesTeam StgSalesTeamMember SalesTeamID The child table can have anywhere from zero to many records. Sage ERP MAS 500 SDK Data Migrator Guide 87

CHAPTER 2 Sales Persons Vendors Vendor Classes sparapisalespersonins Enters salesperson information. You can enter a salesperson's status, sales manager, and commission plan. StgSalesperson spapapivendclassins Defines groups of vendors. You can divide vendors by category, such as type of goods purchased or labor versus materials. You can also use vendor classes to differentiate among various business divisions. For example, a company could establish one vendor class for the manufacturing division, one for the spare parts division, and one for the service division. You can assign general ledger accounts to a class, including the various asset, liability, and expense accounts. StgVendClass Vendor Custom Fields spclapiuserfieldins Creates vendor custom field values. StgUserField StgUserFieldValue 88 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Names StgUserField StgUserFieldValue EntityType, UserFldNo Association Between Tables The child table can have anywhere from zero to many records. Payment Terms Vendor Items spciapipmttermsins Sets up payment terms, which determine the terms that apply to items purchased or sold. You can define unlimited payment terms to be used during Accounts Payable and Accounts Receivable transaction processing. StgPaymentTerms spimapivenditemins A vendor item associates an item and its cost information with a vendor. One item can be associated with various vendors by creating a vendor item for each vendor. For each item and vendor combination you can enter the following: Vendor item ID Unit of measure Country of origin Discount method Break type List price Replacement unit cost Cost break information You also can allow vendor back orders and partial packs StgVendItem StgVendItemBreak Sage ERP MAS 500 SDK Data Migrator Guide 89

CHAPTER 2 Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Names Association Between Tables StgVendItem StgVendItemBreak VendID, ItemID The child table can have anywhere from zero to many records. Vendors spapapivendorsins Inserts vendors, their addresses, and document transmittal and contact information. StgContact StgVendAddr StgVendDocTrnsmit StgVendor Staging Table Association Refer to the following table for migration information about the staging tables used in this step, including associations between staging table column data. Staging Table Child Staging Table Column Name Association Between Tables StgVendor N/A N/A Primary contact N/A StgVendor N/A N/A Primary address N/A StgVendor StgVendAddr VendID, StgVendor.DfltPurchAddrID = StgVendAddr.VendAddrID StgVendor StgVendAddr VendID, StgVendor.DfltRemitToAddrID = StgVendAddr.VendAddrID Default purchase address Default remit-to address Validation Notes For the default purchase address, the StgVendAddr.VendAddrID field cannot equal StgVendor.VendID. This would be considered a duplicate record of the address created from the primary address fields specified above. For the default remit-to address, the StgVendAddr.VendAddrID field cannot equal StgVendor.VendID. This would be considered a duplicate record of the address created from the primary address fields specified above. 90 Sage ERP MAS 500 SDK Data Migrator Guide

API REFERENCE StgVendor StgVendAddr VendID For other addresses, the child table can have anywhere from zero to many records. StgVendor StgContact StgVendor.VendID = StgContact.CntctOwnerID StgVendorAddr StgContact StgVendAddr.VendID = StgContact.CntctOwnerID, Name The child table can have anywhere from zero to many records. The child table can have anywhere from zero to many records. StgVendor StgVendDocTrnsmit VendID The child table can have anywhere from zero to many records. N/A The StgContact.Name field is the key to the permanent tcicontact.name table. Contacts can be related directly to the vendor, or to vendor addresses. The StgContact.Name field is the key to the permanent tcicontact.name table. Contacts are related to addresses if the Name fields are the same in each table. There is one document transmittal record for each transaction type for each vendor. Sage ERP MAS 500 SDK Data Migrator Guide 91