Re-coding

What it is: Assigning new codes to records that already exist and are already used in the DB.

When it is done: Normally re-coding is needed when more than one business needs codes to be aligned, or before two or more businesses merge. Sometimes it is only necessary to re-code only one table for internal needs.

When to start moving: Agree on a time and date of the re-coding and eventually the merger, with the technician. For example, if the 2 companies merge on January 1st, start thinking about preparing the re-coding files at least one month before.

How much time it takes to re-code: This depends on the size of the DB, how many tables need to be re-coded, and if the tables that need to be re-coded were originally coded in an organized manner. Normally, it should take about a day.

If the re-codification is due to two or more businesses merging, the following tables need to be checked, and if necessary, re-coded:

• VAT fiscal registers – SEZFISIVA : TfrmTABSezionaliFiscaliIVA

• PDA - TABFW : TfrmTABPalmari

• PDA Models - MODFW : TfrmTABModelliPalmari

• PDA Printers - PRINTFW : TfrmTABModelliStampantiPalmari

• PDA configurations – PALMCONFIGS : TfrmTABConfigurazionePalmari

• Types – TIPI : TfrmTABTipiDA

• Models – MODELLI : TfrmTABModelli

• Payment Systems – GETTON : TfrmTABGettoniere

• Banknote Readers - LETTORI : TfrmTABLettori

• Coin validators - VALIDATORI : TfrmTABSelettoriMoneta

• Counters - TABCONT : TfrmTABContatori

• RCS Events - DECODE_RCS : TfrmTAB

• Typical Master/Slave Configurations - CONFMASTSLAVE : TfrmTABConfMasterSlave

• Spirals/drums archive - SPIRALI : TfrmTABSpirali

• Models grouping table - RAGMODPRVG : TfrmTABRaggruppamentoModelli

• VM installation/withdrawl/replacement reasons archive - TBL_CAU : TfrmTABCausaliInstallazione

• VAT rates – ARCHIVA : TfrmTABAliquoteIVA

• Payment terms - CONDPAG : TfrmTABCondizioniDiPagamento

• Collection accounts archive - AGGINC : TfrmTABAggiornamentoIncassi

• Banks - BANCHE : TfrmTABBanche

• Customers' accounting categories - CATCONCLI : TfrmTABCategorieContabiliClienti

• Accounting offsets - CONTROP : TfrmTABContropartiteContabili

• Assets fiscal categories - CATFISCESP : TfrmTABCatgorieFiscalCespiti

• Assets movement reasons - CAUMOVCES : TfrmTABCausaliMovimentazioneCespiti

• IRPEF Deduction (Tax on the personal income) - RITENUTEIRPEF : TfrmTABRitenuteIRPEF

• Payment methods- TIPGETT : TfrmTABmetodiPagamento

• Accounting entries – MASTRICONTABILI : TfrmTABMastriContabili

• Geographical macroareas - MACROGEOAREA : TfrmTABMacroAreeGeo

• Geographical areas - GEOAREA : TfrmTABAreeGeografiche

• zone - ZONE : TfrmTABZone

• City councils (COM declarations) - COMUNI : TfrmTABComuni

• POI categories – CAT_POI : TfrmTABCategoriePOI

• Selling PoS price list – TABLIS : TfrmTABListiniPV

• Standard price list for Vending Machine – STDLISTINI : TfrmTABListiniStandard

• Consumpton contracts – MASTER_CONTRATTI : TfrmTABMasterContracts

• Branches - FILIALI : TfrmTABFilali

• Staff- AGENTI : TfrmTABAgenti

• Activities/Categories - ATTIVITA : TfrmTABAttivita

• Statistical Groupings - GRUPPOSTATISTICO : TfrmTABgruppistatistici

• Carriers - VETTORI : TfrmTABVettori

• Sellers archive - VENDIT : TfrmTABVenditori

• Brands - MARCHE : TfrmTABMarche

• Health Care (HC) - USSL : TfrmTABUSSL

• Intervention refusal reasons - MOTIVI : TfrmTABMotiviRifiutoInterventi

• Accessories type - TIPOACCE : TfrmTABTipologiaAccessori

• Accessories - ACCEDIST : TfrmTABAccessoriTUTTI

• Vega Web categories - CATWEB : TfrmTABCodiciCategorieVegaWeb

• Business Functions - FUNZIONI_AZIENDALI : TfrmTABFunzioniAziendali

• Configuration of wireless communications - CONFCOMWIR : TfrmTABConfigurazioniComunicazioniWireless

• Customer's hierarchy for statistical data collection of operations offices - GERCLIRILSTAT : TfrmTABGerRacStatSO

• Customer's category for statistical data collection of Operating Office - CATCLIRILSTAT : TfrmTABCatxRacStatSO

• Types of doc./Note - TIPIDOCUMENTO : TfrmTABTipiDocumento

• "Other" Intervention requests reasons - TABCHIAALTRO : TfrmTABMotChiaTAltro

• Money Equipment – DOTAZIONI : TfrmDotazioni

• Registered offices - CTBCONT : TfrmTABClientiContabili

• Operating offices - CLIENTI : TfrmTABClientiOperativi

• PoS list - UNOPV : TfrmTABPuntiVendita

• Machine archive – DISTRIB : TfrmTABDistributori

• WEB category / Opertaing office association - CLIWEB : TfrmTABCategoriaPerCliente

• Electronic Cash System grouping - RAGGSISTINCEL : TfrmTABRaggruppamentoSistemiIncassoElettronici

• WEB category/PoS association - UPVCWEB : TfrmTABCategoriePerPV

• Breakdowns reported / verified - TABGUAS : TfrmTABGuasti

• Technical functions - MANTIPI : TfrmTABFunzioniTecniche

• Components/Assistance interv. - MANINT : TfrmTABInterventiManutenzione

• Source of defectiveness - ORIGDIFETTO : TfrmTABOrigDifetti

• Defectiveness - TBLDIFETTI : TfrmTABDifetti

• Definition of internal production - TABGUAS : TfrmTABLavorazioniInterne

• Supplier Type - TIP_FORNITORI : TfrmTABTipologiaFornitori

• Suppliers archive - FORNIT : TfrmTABFornitori

• Suppliers price list - LISTINI_FORNITORI : TfrmTABListiniFornitori

• Warehouses - MAGAZZ : TfrmTABMagazzini

• Reasons - CAUSALI : TfrmTABCausaliMovimentiMagazzino

• Categories - CAT_PROD : TfrmTABCategorieProdotti

• U/M - UNIMIS : TfrmTABUnitaDiMisura

• Fiscal categories of products / spare parts - CATFISPROD : TfrmTABCategorieFiscalProdottiRicambi

• Statistical macro-groupings - MACROR_STATM : TfrmTABMacroraggruppamentostat

• Statistical groupings - RAGGRSTATPROD : TfrmTABgruppistatistici

• Product hierarchy - GERARCHIA : TfrmTABGerarchieProdotto

• Goods group - GRUPPOMERCE : TfrmTABGruppoMerce

• Product class - CLASSEPRODOTTI : TfrmTABClasseProdutto

• MRP analysis categories - CATMRP : TfrmTABCategorieMRP

• Barcodes - MAA02 : TfrmTABCodiciABarreProdotti

• Spare parts archive - PRODOTTI : TfrmTABRicambi

• Categories of complaints / commercial calls - CAT_RECL : TfrmTABCategorieReclami

• Complaints / Solutions /commercial calls archive - RECLAMI : TfrmTABReclami

• Vehicle Models - AUTOMOD : TfrmTABModelliAutomezzi

• Interventions - AUTOINT : TfrmTABInterventiAutomezzi

• Mechanics - TABMECC : TfrmTABMeccanici

• Fuel Cards Archive - TESSERECARBURANTE : TfrmTABTessereCarburante

• Infractions Type - AUTOINFRAZIONI : TfrmTABInfrazioniAutomezzi

• Vehicle purpose - TDEST_AUTO : TfrmTDestUsoAuto

• Vehicles - AUTOMEZZ : TfrmTABAutomezzi

• Roles - RUBRICA_INCARICHI : TfrmRubricaIncarichi

• Delivery notes issue reasons - DDT CAUSBOL : TfrmTABCausaliDDT

• Questions - DOMANDE_VI : TfrmTABDomandeVI

• Causes - CAUSE_VI : TfrmTABCauseVI

• Weights - PESI_VI : TfrmTABPesiVI

• Competitor Groups – GRUPPICONCORRENTI : Competitors groups

• Competitors – CONCORR : TfrmTABConcorrenti

• Contact procedure – CONTATTI : TfrmTABContatti

• Definition of Next Commercial Actions  – PROSSIME_AZIONI : TfrmTABProssimeAzioni

• Telemarketing results – RISULT : TfrmTABRisultatiContattiCommerciali

• Activity Structure Type - TIPOATTIVITACLIENTE : TfrmTABTipoStrutturaAttCli

How to start re-coding

To indicate which codes will substitute the old ones an excel file should be prepared which includes the following:

• a column for the old code
• a column for the new code
• a column for a description

To align codes from multiple businesses consider the following:

• there should be NO duplicate codes
• the same code cannot identify two different registrations
• make sure to pay attention to the differences between 0 and O as they are two different characters. If an O is inserted in the place of a 0, the code will be imported with the O, exactly how you write it in the excel spreadsheet.
• you can merge more codes into one single code (for example: two similar models with different codes could become the same model)

An example of re-coding

A simple example of re-coding the archive MODELS:  

Before the technician re-codes...

All of the PDAs need to be emptied and NEED to remain in the office until re-coding is completed. Once completed THEY ALL NEED TO BE REFILLED.

In the case that the re-coding concerns only one subset of the tables, it may not be necessary to have all of the PDAs reenter the office. This would obviously only be the case if the tables being re-coded are not managed on the PDAs.

If the code on the PDA is a variation, make sure to diversify the code on the PDA as well.

Merging

What it is: when two databases are merged together to become one database 

es: Suppose we have the following two data bases:

• Database A
• Database B

The database B enters into database A.

Prerequisites 

• The databases should both be using THE SAME version of Vega
• For Italy: verify if there are duplicates between the ID master of the two businesses. If they are duplicated, it is necessary to give a new ID master to the duplicates of the business that is entering. When choosing the new ID master, verify that the ID does not exist at all, not even in the receiving database.
• For countries outside of Italy: Verify the distributors archive. There could be ECS codes that are identical. If this problem is present, it needs to be resolved BEFORE starting the merge.
• The start of the calendar MUST be the same (this way the routes are recalculated correctly).

What can be merged

It is possible to import the following into the receiving database (A):

• Only the tables and the master data/price lists
• History (PASDST, STOINC, SMERCE ecc.)
• Other archives (DETRIF, RIGRIF, TESTRIF, TSTDOCUM, DETDOCUM ecc.)

Importing the tables means that only the master data is imported, so to see the statistics and the history of the database B it will all need to first be inserted into database B.

Importing the tables + history/other archives obviously requires a lot more work compared to just importing the master data, but it permits having all of the old statistical data of the entering DB (B). On the other hand, if it is an acquisition, it means to find the previous historical data modified because it will also contain the data of the incoming company with values that are theoretically not within that of the recipient DB. 

Before starting the merge...

• It would be best if all of the data of the entering DB (B) were generated and elaborated (it is necessary if not importing the history, while it is optional if doing a TOTAL import)
• it is necessary to ask the client:
  1. if they want to import only the master data or also the historical data and eventually other archives (clarifying the reasons why we tend not to import anything more than the master data / price lists)
  2. if they want to import the LEDGER ENTRIES archive (only the open ones, or include the closed ones as well)

Agree on the date for the merge...

The date for the merge needs to be decided, just as for the re-coding, some time before. If the merge is after re-coding , it could be possibile to do one immediately after the other.

If it is known that the 1st of Jan. the businesses will be merging, try to have the re-coding and merge done at least a month before, although it is better if it can be done even sooner. During the period between the re-coding and the merge, it is advised to activate the Replica Module to keep the entering DB from making any modifications to the tables that have already been re-coded. Evaluate using the Replica Module for a temporary time period with the sales person that follows the client.

How long does a merge take?: depends on the connection, the size of the DB and if there are any hitches (ex: duplicate codes). Normally it calls for about one full day.

When one DB enters into another

Database A (receiving): can continue to work normally

Database B (entering): you cannot insert anything, consider it as FROZEN

If the re-coding is done following a merge, DB B PDAs that are on the field will download to DB A: if they also download using a different access point, the data on the PDA must also be set.

If the merger takes place simultaneously with a re-coding, the PDAs must all be downloaded to DB B before re-coding and then recharged directly on the DB A.