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)
Remembering that the re-coding is preparation for the merge, keep in mind some registrations of one DB are identical to the one of the other DB only with the same configurations.
- One reason for purchase with the code AA can be re-coded with the code AC in the other DB only if the characteristics (stock=increase etc.) are the same.
- A model with the code 01 could be re-coded with the A1 if the other DB has a description which makes it apparent that it is the same model and if the macro-type (TIP_FLAG) and the characteristics (reference quantity etc.) are the same.
An example of re-coding
A simple example of re-coding the archive MODELS:
|Business A||Note||Business B|
|Cod. Mod.||New code||Model Desc.||Cod. Mod.||Model Desc.|
|ASTR||ASBL||Astro Blue||to do before the last row||ASBL||Astro Blue|
|BLU3||BRBL||Brio 3 blu||BRBL||Brio 3 Blu|
|BRI3||BR30||Brio 3 Zanussi||LB02||Blu LB 2000|
|2000||LB02||Blue LB 2000||to merge into one code||BR30||Brio 3 Zanussi|
|LB20||LB02||Blue LB 2000||MAD7||Iarp Maddy|
|MADD||MAD7||Iarp Maddy 7||SNAK||Snakky|
|ASTG||ASTR||Astro Grani||to do as a result of the first row||ASTR||Astro grani|
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.
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.
- 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:
- 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)
- 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.