DNATech :: 🔧 **AUTOMAÇÃO DE PROCESSOS NO TOTVS PROTHEUS - Datasul/Protheus – Parte Final: Metadados, Engenharia e Valorização Profissional**
_Créditos da imagem: ChatGPT
Ao iniciar um projeto de importação de dados do DATASUL para o TOTVS Protheus, minha primeira opção foi utilizar o [**MILE – Model Integrator Layout Engine**] (https://centraldeatendimento.totvs.com/hc/pt-br/articles/360028814432-Framework-Linha-Protheus-MILE-Model-Integrator-Layout-Engine), ferramenta robusta fornecida pela TOTVS para integração de dados via layouts configuráveis.
No entanto, nem sempre a solução mais poderosa é a mais adequada ao contexto.
❌ Por que não usei o MILE?
Apesar do MILE ser ideal para importação de arquivos CSV com cabeçalho, meu cenário era diferente:
1. Os arquivos CSV não tinham cabeçalhos, mas os metadados estavam definidos separadamente em um arquivo externo:
🔗 [`fulltablesdefinition.txt`](https://raw.githubusercontent.com/naldodj/naldodj-DataSul2TotvsProtheus/refs/heads/main/datasul2Protheus/tablesdefinition/fulltablesdefinition.txt)
2. Ao analisar os metadados, notei que alguns campos possuíam múltiplas ocorrências por linha.
Exemplo:
```
Field Name Data Type
cdn_event_fp char[30]
val_calcul_efp deci-2[30]
```
Isso significa que uma única linha no CSV representa 30 registros no Protheus, que precisariam ser quebrados linha a linha (registro replicado por linha). Algo que o, no MILE, seria muito complicado e trabalhoso de implementar.
### 📊 A ESTRUTURA DE METADADOS (`fulltablesdefinition.txt`)
O arquivo [`fulltablesdefinition.txt`](https://raw.githubusercontent.com/naldodj/naldodj-DataSul2TotvsProtheus/refs/heads/main/datasul2Protheus/tablesdefinition/fulltablesdefinition.txt) contém a definição técnica de cada tabela e seus campos exportados do DATASUL.
🧱 Estrutura do arquivo:
```
Table: nome_da_tabela
Field Name Data Type Flg Format
```
Cada bloco descreve uma tabela (`Table:`) e seus campos. Para cada campo, temos:
```
| Campo | Significado |
| ---------- | ------------------------------------------ |
| Field Name | Nome do campo no DATASUL |
| Data Type | Tipo e dimensão (`char[30]`, `deci-2[15]`) |
| Flg | Flags de controle (ex.: `m` = múltiplo) |
| Format | Máscara de formatação |
```
### 🔁 Campos com \[n] (Repetições)
A principal complexidade está nos campos com repetição, como:
```
cdn_event_fp char[30]
val_calcul_efp deci-2[30]
```
Ou seja, uma única linha no CSV representa 30 eventos que precisam ser quebrados em 30 registros para a tabela destino no Protheus.
A Solução: Criação da Própria “Engine” de Processamento
Decidi construir minha própria "engine" de importação:
📦 [`DataSul2TotvsProtheus.tlpp`](https://github.com/naldodj/naldodj-DataSul2TotvsProtheus/blob/main/src/DataSul2TotvsProtheus.tlpp)
Essa engine interpreta os metadados, realiza o unfolding dos dados repetidos, aplica validações, normalizações e conversões — tudo orientado pelo .ini.
O processo foi modelado da seguinte forma:
Leitura do arquivo .ini** para mapear campos, estruturas, regras e tabelas auxiliares
Interpretação do arquivo fulltablesdefinition.txt** para identificar metadados e repetições
Tratamento especial para campos TypeReplicate=row**, como no caso da tabela SRD, onde a estrutura define que:
```
[movto_calcul_func]
TypeReplicate=row
```
Cada evento de cálculo no CSV gera um novo registro na tabela de destino (`SRD`) do Protheus.
💼 O Lado Humano do Projeto
Nem tudo foi código.
Fui contratado por um terceiro (via consultoria homologada TOTVS), que me disse:
“Preciso que importe os dados do DATASUL para o Protheus. Aqui estão os CSVs.”
Questionei a ausência dos cabeçalhos. Recebi o arquivo de metadados. Optei por não usar o MILE e implementei a solução sob medida.
Implementei, testei, entreguei. Porém… não recebi.
O terceiro brigou com o segundo (a consultoria oficial). Resultado: o segundo não o pagou. E, consequentemente, eu também fiquei sem pagamento.
Fui procurado diretamente pela consultoria e pela TOTVS. Expliquei minha posição:
“Não fui contratado para ceder o código-fonte, e sim a solução. Mas darei todo o suporte necessário.”
Eles respeitaram minha decisão, reconheceram meu esforço e pagaram corretamente.
O sistema foi utilizado sem que o código fosse entregue, mas com meu apoio técnico assegurado.
Para garantir isso, adicionei um trecho de proteção no código:
lActivate := DTS2PTProc():Execute("dna.tech.DataSul2Protheus.DNAChkAuth")
if (!lActivate)
break
endif
Não interfere na lógica de importação, mas foi fundamental para assegurar que meu trabalho fosse valorizado.
✅ Conclusão
📌 Às vezes, a melhor solução técnica não é a ferramenta oficial.
📌 Às vezes, proteger seu trabalho é tão importante quanto entregá-lo.
📌 E sempre, transparência e ética fazem a diferença no final.
🚀 Finalizo aqui essa série sobre como foi possível automatizar a migração de dados do DATASUL para o Protheus, respeitando a integridade dos dados e valorizando o conhecimento técnico e humano envolvidos.
Se você trabalha com integração, migração, ou quer evoluir processos no TOTVS Protheus, essa série pode servir como guia — ou inspiração.
\#TOTVS #DNATech #Protheus #ERP #DataMapping #Automação #MigraçãoDeDados #INIfile #Metadados #Consultoria #ValorizaçãoProfissional #Framework #Desenvolvimento
Comentários
Postar um comentário