DNATech :: 🔧 **AUTOMAÇÃO DE PROCESSOS NO TOTVS PROTHEUS – Parte 2: O Papel do Arquivo .INI na Migração de Dados**

_Créditos da imagem: NaldoDJ

🔧 **AUTOMAÇÃO DE PROCESSOS NO TOTVS PROTHEUS – Parte 2: O Papel do Arquivo .INI na Migração de Dados**

Quando falamos de migração automatizada de dados entre sistemas legados, como o **DATASUL**, e o **TOTVS Protheus**, o segredo do sucesso está em algo muitas vezes invisível: a **inteligência embarcada nos arquivos de configuração `.ini`**.

### 🧩 O que é o arquivo `[datasul2protheus.ini](https://github.com/naldodj/naldodj-DataSul2TotvsProtheus/blob/main/datasul2Protheus/doc/datasul2protheus.doc.ini)`?

Esse arquivo `.ini` não é apenas um conjunto de parâmetros: **ele é o cérebro de toda a automação**.
Nele estão definidos:

---

### ⚙️ Principais Sessões e Funções

#### 🔹 `[General]`

Define parâmetros globais da automação:

* `CompanyCode=99`: empresa destino no Protheus
* `TablesEncodeUTF8=1`: indica se os CSVs estão em UTF-8
* `IncProcFastMode=1`: ativa modo de processamento otimizado

#### 🔹 `[Tables]`

Define caminhos e arquivos de referência:

* `TablesData=\tables\`: pasta com os CSVs exportados do Datasul
* `TablesDefinition=\tablesdefinition\fulltablesdefinition.txt`: metadados das tabelas do Datasul

#### 🔹 `[TablesImport]`

Relaciona cada **tabela do Protheus** (alias como `SRA`, `SRB`, etc) a seu respectivo **arquivo CSV do Datasul**.
Exemplo:

```ini
SRA=funcionario
SRB=depend_func
SRF=period_aqst_ferias
```

---

### 🧠 Como as regras são definidas?

Cada seção `[TABELA]` (como `[SRA]`, `[SRB]`, `[SRF]` etc) define:

| Parâmetro             | Descrição                         |
| --------------------- | --------------------------------- |
| `IndexKey`            | Chave de busca no Protheus        |
| `AddIndex`            | Índices criados na temp table     |
| `AskUpdate`           | Se atualiza registro existente    |
| `ChkFilial`           | Valida filial no dado importado   |
| `TCSQLUpdateTable`    | Se usa SQL direto ou Lock         |
| `bTargetIgnoreFields` | Campos ignorados na importação    |
| `Transform`           | Funções de conversão/normalização |

---

### 🔄 Mapeamento e Transformações

O `.ini` também mapeia **campo a campo** entre os sistemas. Exemplo:

```ini
RA_MAT = cdn_funcionario
RA_ADMISSA = dat_admis_func
RA_SALARIO = val_salario_atual
```

E para transformar valores, temos instruções como:

```ini
[RA_ADMISSA]
Transform={|RA_ADMISSA|if(valType(RA_ADMISSA)=="D",RA_ADMISSA,CToD(""))}
```

Ou seja, **as validações, normalizações, e regras de negócio** estão encapsuladas diretamente no `.ini`, sem depender do código-fonte.

---

### 🧮 Exemplo prático: Funcionário (SRA)

A tabela `SRA` importa o cadastro de funcionários. Veja algumas regras:

* `IndexKey=RA_FILIAL+RA_MAT`
* Converte `RA_CATFUNC` através da `TabelaCategoriaFuncionarioRA_CATFUNC.ini`
* Ignora campos com `TypeReplicate`
* Valida se o campo `RA_CODUNIC` está vazio e gera dinamicamente, se necessário.

---

### 🧠 Conclusão

O `.ini` **centraliza a lógica de importação, simplifica manutenção, promove reuso e garante conformidade com as regras do sistema de destino**.
Assim, migrar dados de maneira automática, segura e escalável deixa de ser um caos técnico e passa a ser um processo transparente e estruturado.

---

No próximo post, vamos mostrar **como os campos auxiliares, tabelas auxiliares e transformações avançadas** são utilizadas para garantir uma migração limpa e sem retrabalho.

Se está envolvido em migração ou integração com o Protheus, essa série é pra você!

\#TOTVS #DNATech #Protheus #Automação #MigraçãoDeDados #ERP #DataMapping #INIfile #Transformações

---

Torne-se um Sponsor: 🥊(дави)={0.5x[(Налдо)+(Алине)]}🥊