Sage X3: Functional pre/post-requisites for the migration of a folder to V7

Spanish localization

For the migration of a folder in Spanish legislation, please contact your Spanish customer service to know more about the dedicated migration process.

Pre-requisites to the migration process

The migration pre-requisites of a folder are specified here below. Generally speaking, the first step, highly recommended, is to check that the data to migrate are consistent.. Indeed, when it comes to a folder with many entries, and which may have undergone maintenance operations, some data may no longer be consistent with the others (especially in the presence of specific developments).

This operation will detect any problem concerning data that may generate errors during the migration procedure, which makes it necessary to restart it.

It is also recommended to purge a certain number of temporary tables whose migration may be time-consuming (for instance the query table).

Post-requisites to the migration process

Business processes:

The processes used in version 6 must be revalidated using the Process recoding function (ARECOPRO). This validation is necessary to make the processes consistent with version 7.

The process validation must be carried out:

• after each folder validation,
• after each copy of a process from a folder to another.

Financials

Automatic journals

New automatic journals are available in version 7 and some automatic journals from version 6 have been modified. 
You must thus launch the automatic journal comparison utility to compare the migrated folder and the Sage X3 folder.

Long and short titles for data available for each legislation

Some setup functions now exist specifically for each legislation. Concurrently with this adaptation, the fields for the long and short titles have been made mandatory in the user connection language. Upon modification of the value of a field with this type of data, if the long or short title is not available in the connection language, it must be entered.
The concerned functions used in the Financials modules are the document types (GESGTE), the journal codes (GESJOU), the payment attributes (GESCDA), the payment entry types (GESTPY), the reports (GESTED), the payment methods (GESTAM), the bank files (GESTFB), the tax codes (GESTVT), the tax rules (GESTVB), the early discounts/late charges (GESTDA), the customer and supplier invoice types (GESTSV and GESTPV).

Report group

In version 7, the functions used to manage the declarations to the tax or administration agencies have been grouped in a new "Declarations" menu and reorganized by topic and then by legislation.
The reports associated with these functions have also been reorganized accordingly, therefore the group they are attached to (via the local menu 97) has been forced to match this new structure.
If some special customer features related to the attached group must be kept after migration, it will be necessary to modify the report group of the report.

Fields that indicate a file path

The new volume management method in version 7 and the use of a web browser rather than a fat client implies that the fields that specify a file generation path now function differently. This concerns parameter values as well as some fields of certain functions.
Parameters that contain a path are now only used when the destination is of Server type. They must thus contain a path related to the selected volume (or just a volume), expressed with the appropriate syntax.
For example, the EXPCASPAY parameter must contain [CASH] so that the files can be generated in the CASH volume.
These parameters should therefore be updated so that they contain the volumes or relative paths, in compliance with the new syntax.
As to function fields, the 'ENERGY setup' (GESNRY) and 'ACCENTFIL setup' (GESFAE) functions are concerned. These two functions contain a field which must contain a path for the selected volume (or just a volume), in case of a Server type of generation.

Fixed Assets

Entry types

In version 7, the accounting entry types (GESTPE) setup has been modified. The entry types have been recoded in the standard setup and it is now possible to enter one entry type and one journal code by legislation.
Therefore it is recommended to check their setup.

Distribution

Legislations

In version 7, the management of some functions integrates the legislation concept.

• Records that have a filter on the legislation have this legislation code in the new key.
• Records that do not have a legislation filter have an empty legislation code. These records are considered to be in multi-legislation.
• The group information is conserved as a filter.
• The long and short titles are kept. If these titles are empty in some records, the user must manually enter those titles when updating them.

Below, a list with functions managed by legislation and they corresponding key modified on the table associated with the object.

Miscellaneous tables

• Miscellaneous tables no. 1, 2, 3, 6, 15 and 304 are migrated as new objects.
• Tables that have a filter on the legislation have this legislation code in the new key.
• Tables that do not have a legislation filter have an empty legislation code. These tables are considered to be in multi-legislation.
• An old miscellaneous table that has a group information will keep this group information in the new object as a filter. All the other standard information of this miscellaneous table are transferred into the new object table.
• All the non-standard fields added during the miscellaneous tables setup (A1, A2, N1, N2 fields) are transferred into the new object table (they will not be displayed in the new object).

Below, the table showing the relation between miscellaneous tables used in V6 and functions for the management of objects in V7.

Delivery types and return types

The migration process must assign:

• a delivery type in the SDHTYP field to all the existing deliveries.
• a return type in the SRHTYP field to all the existing returns.
  The delivery type and return type to be used come from the reference folder. Only the types that have a legislation managed in the destination folder or an empty legislation are copied from the reference folder.
  The same process is used for the following general parameters, with their values by legislation: SDHTYPNOR, SDHTYPLND and SDHTYPCSO.
   The user has the possibility to configure the data at two different levels depending on the way in which the migration is performed:
• the migration is performed at the same time as the folder validation: the configuration must be correctly made in the reference folder, with the expected type codes (type tables and general parameters).Otherwise, the system will use the default types delivered in the standard setup.
• the migration is performed after the folder validation: the configuration must be correctly made in the destination folder, with the expected type codes (type tables and general parameters). Otherwise, the system will use the default types copied from the reference folder.
• When the delivery type and return type tables are filled, and the general parameters SDHTYP* are defined, the system populates the deliveries and the returns according to the following processes :
• for each delivery:
• the system checks the general parameter that corresponds to the delivery category,
• if no value is defined, the system selects the first delivery type in the alphabetical order that corresponds to both the delivery legislation and the delivery category,
• if nothing is found, the system selects the first delivery type in the alphabetical order that has an empty legislation and that corresponds to the delivery category,
• for each return:
• the system selects the first return type in the alphabetical order that corresponds to both the return legislation and the return category,
• if nothing is found, the system selects the first return type in the alphabetical order that has an empty legislation and that corresponds to the return category,

CRM mass mailing

• The WORDPATH parameter (Users/Parameters/CRM/DEF/WORDPATH) no longer exists because the creation mode for Microsoft Word has changed.
• The mailing report table (OMMRPT) only contains the Crystal reports templates. Upon migration, the following process is used:
• All the records that idenfity the Microsoft Word templates are deleted.
• The Type field (TYPTPL) is deleted.
• The Language field is filled with the default language of the folder.
• The report code field (MAGTPL) now identifies the 'Report code' record.
• A new field contains the Crystal report name. This hidden field is filled at the same time as the previous field is.
• The short and long descriptions are filled with the report code.
• A new key is created with the language code: Language code + report code.
• The Mass mailing XML table (MAILXML) contains two new fields: the Short description and Long description fields with the XML code for mass mailing.

Import/export templates

• The delivery type is added in the SDHFL import template.
• The new import templates, which come from the object creation to replace miscellaneous tables, are added: TAM (Payment methods), TEC (Transaction nature), TED (Report code), TPV (Supplier invoice types), TRE (Return types), TSC (Statistical rule), TSD (Delivery types), TSO (Order types), TSV (Sales invoice types), TVB (BP tax rule), TVI (Tax level).

Reports

• Elements linked to the SDD are added to the invoices report (SBONFAC*).
• Elements linked to delivery types and return types are added to the BONLIV*, BONRETLIV, SDELIVERY*, SRETURN* reports.