Do Integrator para o ERP Voalle — Guia Completo de Migração de Dados

Este documento explica, em linguagem acessível e com mapeamento técnico coluna a coluna, como cada informação do sistema Integrator é reorganizada durante a migração para o ERP Voalle. O objetivo é que qualquer pessoa que conheça o Integrator consiga entender onde seus dados "pousam" no novo sistema — e um analista consiga reproduzir ou depurar qualquer transformação.

Não migrado: fotografias (fotografias_local) e arquivos (arquivos) não são migrados nesta versão dos scripts (bloco 99_Anexos.sql completamente comentado).

Para quem vem do Integrator, o processo de migração opera assim:

INTEGRATOR (legado)
   Dados exatamente como estão hoje no sistema

         | Cópia dos dados para o servidor Voalle
         v

CONNECTOR (área intermediária)
   Os dados são reorganizados e enriquecidos.
   É aqui que acontecem todas as transformações:
   unificação de tabelas, mapeamentos, cálculos de valor.

         | Consolidação — importação para o ERP
         v

ERP VOALLE
   Os dados chegam no formato final,
   prontos para serem usados no sistema.

Ideia central: o Integrator armazena informações de forma fragmentada — cada tipo de dado em uma tabela separada. O ERP Voalle adota uma visão unificada. O melhor exemplo é a Conexão: no Integrator ela está espalhada por 10+ tabelas; no ERP é um único registro.

No Integrator, a tabela empresas guarda as filiais e unidades do provedor (CNPJ, regime tributário, endereço). No ERP Voalle isso se chama Local (companies_places).

Integrator:  empresas  |  codemp = '01'  |  nome_emp = 'Provedor Sede'
                  |
                  v
ERP Voalle:  Local  |  erp_code = 'Integrator_CP_01'  |  razao_social = 'Provedor Sede'

Script: Cadastros/01.01-Locais.sql

No Integrator, grupo_clientes agrupa clientes por categorias (ex: Residencial, Empresarial). No ERP viram Grupos de Pessoas, com o mesmo propósito.

Script: Cadastros/03.01-GrupoPessoas.sql

No Integrator, grupos_servicos categoriza os planos de internet (ex: Fibra, Rádio, TV). No ERP viram Grupos de Serviços.

Script: Cadastros/04.01-GruposServicos.sql

No Integrator, a forma de cobrança é definida em forma_cobrancas, com as regras de juros e multa em conf_boletos e o banco em bancos. No ERP tudo isso se une em um único Tipo de Cobrança.

Script: Cadastros/02.02-TiposCobranca.sql

Três grupos são criados automaticamente pelo script — não existem como tabela no legado, são inseridos fixos na migração:

Script: Cadastros/08.02-GrupoIPs.sql

Os endereços IP do legado vêm de 5 origens diferentes, cada uma com um prefixo distinto:

Script: Cadastros/08.03-IPs.sql

No Integrator, os equipamentos de autenticação ficam em nas_radius (servidores RADIUS) e radios (access points que funcionam como NAS). No ERP viram Concentradores.

Um concentrador de migração padrão (MIG_999) é inserido diretamente no ERP para receber conexões que não tiverem concentrador identificado no legado.

Script: Cadastros/08.04-Concentradores.sql

As OLTs do Integrator (olt_fibra) viram Pontos de Acesso no ERP, com o fabricante mapeado pelo código codtolt.

Um ponto de acesso padrão (MIG_999) é criado para conexões sem OLT identificada.

Script: Cadastros/08.05-PontodeAcesso.sql

Condomínios do Integrator são mantidos como entidade separada no ERP.

Script: Cadastros/08.07-Condominios.sql

Esta é uma das grandes unificações da migração. No Integrator existem cinco tabelas de cadastro de pessoas completamente separadas. No ERP Voalle todas se tornam registros na mesma entidade Pessoa, diferenciadas apenas por flags e situação.

Script: Operacional/03.02-Pessoas.sql (bloco Clientes)

Script: Operacional/03.02-Pessoas.sql (bloco Fornecedores)

No Integrator, contatos_cliente guarda pessoas de contato vinculadas a um cliente (ex: gerente, técnico, cônjuge). No ERP viram Pessoas com vínculo de contato.

Script: Operacional/03.02-Pessoas.sql (bloco Contatos)

No Integrator, prospect são clientes em potencial que ainda não assinaram um plano. No ERP viram Pessoas com situação Prospect.

Script: Operacional/03.02-Pessoas.sql (bloco Prospects)

No Integrator, usuarios são as contas de acesso ao sistema (atendentes, técnicos, gerentes). No ERP viram Pessoas com flag de colaborador.

Script: Operacional/03.02-Pessoas.sql (bloco Usuários)

Além do cadastro principal, os contatos adicionais de cada cliente são migrados para pessoas_comunicacao. Cada registro em contatos_cliente pode gerar múltiplos meios de contato no ERP.

Script: Operacional/03.03-Comunicacoes.sql

O endereço de cobrança é migrado separadamente do endereço principal. O script busca primeiro em endereco_cli com tipo 'COBRANÇA'; se não encontrar, usa o endereço do próprio cadastro do cliente.

Script: Operacional/03.04-Enderecos.sql

No Integrator, servicos_cli é a tabela central de serviços contratados. Cada linha representa um plano assinado por um cliente e tem um codsercli único.

servicos_cli:
  codsercli = ABC123  |  codcli = 100001  |  serviço = Internet 100MB Fibra
  codsercli = DEF456  |  codcli = 100001  |  serviço = Telefone VoIP

O cliente 100001 tem 2 planos → 2 linhas em servicos_cli → 2 codsercli distintos.

O script 05.01-Contratos.sql cria 1 contrato no conector para cada codsercli:

codsercli ABC123, codcli 100001  →  contrato  CNT_100001_ABC123
codsercli DEF456, codcli 100001  →  contrato  CNT_100001_DEF456

O codsercli também é gravado no campo Observações do contrato no formato:

codsercli.: (nro_plano) - ABC123

Mapeamento de situação (codest → situacao):

O script 05.02-ItensContrato.sql adiciona os itens a cada contrato. Um único codsercli pode gerar vários itens no ERP:

Um plano de "Internet + Telefone + TV" no Integrator vira 1 contrato com 3 itens no ERP.

O script 05.03-ValoresDosContratos.sql aplica as regras de negócio e calcula o valor final de cada item (descontos, tolerâncias, valor mínimo, etc.).

A pergunta central: "Esses planos saem no mesmo boleto?"

Se dois ou mais codsercli do mesmo cliente atenderem todos os critérios abaixo, eles são unificados em 1 único contrato no ERP:

Atenção — boleto_separado e nf_separado: no Integrator o valor padrão desses campos é 'N' ou vazio/nulo. Apenas quando explicitamente marcado como 'S' o plano é excluído do agrupamento. Campos nulos ou vazios são tratados como "pode agrupar".

Antes do agrupamento:

Contrato A  →  codsercli ABC123  |  cliente 100001  |  cobrança BB001  |  vence dia 10
Contrato B  →  codsercli DEF456  |  cliente 100001  |  cobrança BB001  |  vence dia 10

Depois do agrupamento:

Contrato UNIFICADO  |  cliente 100001  |  NOVO erp_code (diferente de todos os originais)
  Item 1: Internet 100MB Fibra   (veio do codsercli ABC123)
  Item 2: Telefone VoIP          (veio do codsercli DEF456)

O cliente recebe 1 único boleto com ambos os serviços.

O script 11.01-Agrupar_Planos.sql executa os seguintes passos internamente:

1. Identifica todos os grupos de contratos que compartilham a mesma chave (codcli + codcob + dia_vencimento + situacao)
2. Cria a tabela connector.migraco_integrator_de_para_contratos mapeando cada erp_code original para o novo código unificado
3. Atualiza todas as tabelas do connector que referenciam contratos (faturas, títulos, conexões, encaminhamentos etc.) para apontar para o novo código
4. De todos os contratos que seriam agrupados, apenas 1 sobrevive fisicamente — o que tem o maior id interno. Ele recebe um erp_code novo, diferente de todos os codsercli originais
5. Os demais contratos são deletados do connector
6. O valor de desconto total é somado no contrato sobrevivente

Consequência crítica para rastreamento: após o agrupamento, o campo Observações do contrato unificado contém apenas o codsercli do contrato eleito como principal (maior id interno). Os demais codsercli do grupo não ficam registrados nas Observações. Para rastrear todos os codsercli que foram agrupados, use a tabela connector.migraco_integrator_de_para_contratos — veja seção 6.6.

O que NÃO agrupa (permanece como contrato separado no ERP):

O histórico de movimentações do plano no Integrator (historico_cliente) é migrado como eventos do contrato no ERP.

Script: Operacional/05.04-EventosContratos.sql

Após a migração e o agrupamento, há 3 formas de localizar a origem de um contrato no ERP:

Durante o Passo 1 (script 05.01-Contratos.sql), o codsercli é gravado nas Observações:

codsercli.: (nro_plano) - ABC123

Este campo sobrevive ao agrupamento no contrato eleito como principal (maior id). Os demais codsercli do grupo não aparecem nas Observações do contrato unificado.

A tabela connector.migraco_integrator_de_para_contratos é criada pelo script 11.01 e mapeia cada erp_code original para o código do contrato destino no ERP:

SELECT * FROM connector.migraco_integrator_de_para_contratos
WHERE erp_code_origem = 'Integrator_CNT_100001_ABC123';
-- retorna o erp_code do contrato unificado onde ABC123 foi absorvido

Esta é a única forma de rastrear codsercli que não ficaram no campo Observações.

O campo numero_contrato no ERP é preenchido com codcli-nro_plano do legado:

100001-1   →  primeiro plano do cliente 100001
100001-2   →  segundo plano do cliente 100001

Útil para localizar o contrato diretamente na tela do ERP sem precisar do erp_code.

Após o agrupamento, dois scripts de Ajustes Finais complementam as regras de contrato:

Esta é a transformação mais visível para quem vem do Integrator: dados que ficavam em 10 ou mais tabelas chegam ao ERP como 1 único registro de Conexão.

Para saber "como esse cliente está conectado", era necessário consultar:

servicos_cli      → qual o codsercli do cliente
login_radius      → login e senha PPPoE
ip                → endereço IP, MAC address, tipo de interface
interfaces_radios → tipo de conexão (PPPoE, DHCP, Hotspot)
radios            → qual rádio AP conecta o cliente
nas_radius        → qual NAS/RADIUS gerencia a autenticação
onu_fibra         → número de série da ONU, login/senha de gestão, SSID Wi-Fi
olt_fibra         → qual OLT atende aquela ONU
pon_slot          → porta PON dentro da OLT
slot_olt          → slot da OLT
condominios       → se a conexão é em um condomínio
endereco_cli      → endereço de instalação

Tudo isso se torna 1 registro na tabela de Conexões por cliente.

Script: Operacional/08.07-Conexoes.sql

Dois tipos de conexão migrados:

Pontos de Acesso (OLTs e APs):

• olt_fibra → Ponto de Acesso tipo OLT (prefixo OLT_)
• radios / nas_radius → Concentrador / Ponto de Acesso tipo Rádio
• MIG_999 → Ponto de acesso padrão criado para conexões sem OLT/AP identificado

O financeiro de recebimento opera em dois níveis no Integrator:

faturas           → boleto/agrupador: 1 fatura pode conter vários títulos
contas_rec        → título individual a receber por cliente (codcrec)
detalhe_faturas   → de-para entre faturas e contas_rec (N:N)
descontos         → descontos aplicados por codcrec
juros_contas_rec  → juros e multa cobrados por codcrec
razao             → registro contábil vinculando contas_rec/contas_pag a mov_bancario
mov_bancario      → movimentação bancária real (data e banco do recebimento/pagamento)

O recebimento de um boleto fica registrado tanto na faturas (status Q/B) quanto na contas_rec (data_bai preenchida, valor_pag >= valor_lan). São dois níveis distintos que o ERP também preserva.

Por que dois registros de recebimento? O Integrator registra a baixa no nível do boleto (faturas) e no nível do título (contas_rec). O ERP preserva essa separação: faturas_recebidas é o recebimento do boleto como documento; contas_recebidas é o recebimento de cada título individual que compõe aquele boleto.

Faturas com parcelamento = 'S' (renegociações/parcelamentos) são migradas separadamente com tratamento específico.

Equipamentos do legado (patrimonio) são migrados como Patrimônios no ERP. O script migra dois grupos: equipamentos alocados a clientes e equipamentos disponíveis em estoque.

Script: Operacional/09.02_Patrimonios.sql

No Integrator, o atendimento ao cliente é dividido em ocorrencias (chamados gerais) e ordem_servico (ordens de serviço técnicas). No ERP viram Solicitações Vinculadas.

Script: Operacional/10.05-Solicitacoes_vinculos.sql

Todo o histórico de comunicação e notas de atendimento é migrado como Relatos. Seis origens diferentes alimentam essa entidade:

Script: Operacional/10.06-Relatos.sql

Os encaminhamentos internos de ocorrências são migrados como Encaminhamentos no ERP.

Script: Operacional/10.07-Encaminhamentos.sql

Cada registro migrado ganha um código de rastreamento composto por um prefixo de origem + o código original do legado.

Para contratos agrupados: após o agrupamento (script 11.01), os erp_codes individuais (CNT_codcli_codsercli) são substituídos por um novo código unificado. O rastreamento só é possível pelo campo Observações do contrato. Consulte também a tabela connector.migraco_integrator_de_para_contratos.

Scripts 02.XX — limpeza de dados do legado (TRIM em todas as tabelas).

Esta etapa é executada depois de toda a consolidação padrão — quando os dados já estão no ERP Voalle. São correções e complementos exclusivos para migrações do Integrator que resolvem diferenças estruturais entre os dois sistemas: coisas que o fluxo genérico não cobre porque só fazem sentido no contexto do Integrator.

Todos os scripts verificam automaticamente se a base é uma migração Integrator (via tabela connector.prefixos_migrados). Se não for Integrator, o script é ignorado sem executar nada.

Visão geral dos scripts ativos:

Scripts comentados (não executam): 01.01, 01.02, 01.08, 02.02, 07.02 — preservados para referência futura ou restritos a ambientes específicos.

Por que existe: O Integrator guarda a alíquota de ICMS como um número solto em cada serviço (ex: 7.00, 12.00, 0.00). O ERP Voalle não aceita alíquotas soltas — cada serviço precisa estar vinculado a um registro na tabela de alíquotas cadastradas. Sem esse ajuste, os serviços migrados ficam sem classificação fiscal de ICMS.

O que faz:

1. Lê todas as alíquotas distintas presentes nos serviços migrados do legado
2. Cria um registro na tabela de alíquotas do ERP para cada valor novo encontrado (ex: cria "Outros (Regime Normal) — 7%")
3. Vincula cada serviço/produto migrado à alíquota correspondente
4. Serviços sem alíquota no legado recebem o id=4 como padrão

Tabelas afetadas no ERP:

• erp.service_product_icms_aliquots — novas alíquotas inseridas
• erp.service_products — campo service_product_icms_aliquot_id atualizado em todos os serviços migrados

Por que existe: Produtos físicos que são "vendáveis" (podem ser vendidos avulso, não apenas como item de contrato) precisam ter dados fiscais completos para emissão de NF-e. O Integrator não exige esse nível de detalhe. Sem esse script, produtos migrados sem ICMS causariam erro ao tentar emitir NF.

O que faz: Para produtos vendáveis sem ICMS preenchido após a migração, aplica valores fiscais padrão de segurança:

Tabelas afetadas no ERP:

• erp.service_products — campos fiscais atualizados apenas em produtos vendáveis sem ICMS preenchido

Por que existe: O Integrator organiza as naturezas financeiras (plano de contas) em uma árvore hierárquica com códigos no formato 1.01.02 — onde 1.01.02 é filha de 1.01, que é filha de 1. Após a carga, o campo parent_id que representa essa hierarquia pode não estar preenchido, deixando todas as naturezas no mesmo nível sem estrutura de árvore.

O que faz: Reconstrói automaticamente a hierarquia lendo o código de cada natureza e preenchendo o parent_id correto:

Código "1"       → parent_id = NULL (raiz)
Código "1.01"    → parent_id = natureza com código "1"
Código "1.01.02" → parent_id = natureza com código "1.01"

Tabelas afetadas no ERP:

• erp.financers_natures — campo parent_id reconstruído para toda a árvore de naturezas migradas
• maintenance.financers_natures_vinculate_parent_id — tabela temporária de apoio (removida ao final)

Por que existe: No Integrator, os contatos de clientes têm um campo de tipo/cargo com valores como FINANCEIRO, TECNICO, COMERCIAL, ADMINISTRA. No ERP Voalle esse conceito se chama "Função CRM" e usa uma codificação própria. Sem esse ajuste, todos os contatos migrados ficam sem função definida.

O que faz: Aplica o mapeamento abaixo em todos os contatos migrados:

Tabelas afetadas no ERP:

• erp.people_contacts — campo crm_function_id atualizado nos contatos migrados

Por que existe: O Integrator tem seu próprio módulo de disparo de e-mail com servidores SMTP e templates para boletos, avisos de bloqueio etc. Esses dados precisam migrar para que o ERP continue enviando e-mails pelos mesmos servidores e com os mesmos templates — evitando que o cliente precise recadastrar tudo manualmente.

O que faz:

1. Servidores SMTP: importa cada servidor de e-mail do legado (remetente, login, senha, endereço do servidor, porta — fixada em 587)
2. Templates de e-mail: importa cada modelo (assunto, conteúdo, remetente) vinculando ao servidor correspondente

Não duplica: verifica existência antes de inserir.

Tabelas afetadas no ERP:

• erp.email_services — servidores SMTP do legado
• erp.email_models — templates de e-mail do legado

Por que existe: Quando o cliente tem múltiplas filiais (locais de faturamento), cada filial precisa ter sua própria série fiscal de NF para que a numeração seja independente por CNPJ emissor. O processo padrão de migração cria as séries de forma genérica — este script garante a correta separação por local.

O que faz:

1. Identifica todas as combinações de local + operação financeira + série fiscal existentes
2. Renomeia séries genéricas adicionando o código do local (ex: NF-001 → NF-001 [FIL01])
3. Cria novas séries fiscais para locais que ainda não têm série própria (cópia da série original)
4. Cria o sequencial de numeração para as novas séries
5. Corrige os vínculos entre operações financeiras e séries — garante que cada local use a série do seu próprio local
6. Remove vínculos incorretos (operação de um local apontando para série de outro local)

Tabelas afetadas no ERP:

• erp.invoice_series — séries renomeadas e novas séries por local inseridas
• erp.invoice_serie_sequences — sequenciais criados para novas séries
• erp.financial_operations_company_places — vínculos operação + local + série corrigidos

Por que existe: É muito comum no Integrator que clientes não tenham CPF/CNPJ cadastrado. Se essa pessoa já existe no ERP Voalle com o mesmo nome e com CPF/CNPJ preenchido (cadastro anterior à migração), o processo de migração gera um registro duplicado — a mesma pessoa aparece duas vezes no ERP. Este script resolve isso de forma segura e com auditoria completa.

O que faz:

1. Identifica pessoas migradas sem documento que têm um "gêmeo" no ERP com mesmo nome e com CPF/CNPJ
2. Valida que a pessoa duplicada não tem contratos ativos, títulos a receber nem contas a pagar (segurança para não perder dados)
3. Marca a pessoa duplicada como deletada, registrando o motivo e o id da pessoa original nas observações
4. Redireciona todos os vínculos de contato (people_contacts) para a pessoa original (com documento)
5. Remove contatos que ficariam duplicados após a unificação

Este script não é destrutivo — preserva histórico completo em tabelas de auditoria no schema maintenance. Toda alteração fica registrada e pode ser rastreada.

Tabelas afetadas no ERP:

• erp.people — deleted = TRUE nas pessoas duplicadas sem documento
• erp.people_contacts — redirecionados para a pessoa com documento
• maintenance.migracao_itengrator_unificacao_pessoas_sem_documento — histórico de auditoria
• maintenance.migracao_itengrator_unificacao_pessoas_sem_documento_bkp_people_contacts — backup dos contatos

Por que existe: No Integrator, o campo imprime_nf = 'N' em um serviço significa que aquele contrato não deve gerar Nota Fiscal — o faturamento vai para o agrupador CIS (Comunicação de Informações de Serviços) em vez do agrupador padrão com emissão de NF. A migração padrão não distingue isso automaticamente: todos os contratos chegam com o agrupador padrão.

O que faz:

1. Busca no legado todos os serviços com imprime_nf = 'N'
2. Localiza os contratos correspondentes no ERP — tanto pelo erp_code direto quanto pela tabela de DE/PARA de contratos (connector.migraco_integrator_de_para_contratos), cobrindo também os contratos que foram agrupados
3. Atualiza o agrupador de faturamento (contract_configuration_billings) para a operação CIS
4. Atualiza também a capa do contrato (contracts.operation_id)
5. Registra um evento de auditoria no contrato documentando a alteração

Tabelas afetadas no ERP:

• erp.contract_configuration_billings — financial_operation_id alterado para CIS
• erp.contracts — operation_id atualizado
• erp.contract_events — evento de auditoria inserido
• maintenance.migracao_integrator_depara_contract_configuration_billings_imprime_nf_N — histórico permanente

Por que existe: No Integrator, planos com tipo_pag = 'A' são cobrados anualmente, não mensalmente. A migração padrão cria todos os contratos como mensais. Sem este ajuste, o ERP tentaria gerar faturas mensais para contratos que deveriam ser faturados uma vez ao ano.

O que faz:

1. Busca no legado todos os serviços com tipo_pag = 'A'
2. Localiza os contratos correspondentes no ERP
3. Atualiza o tipo de faturamento para anual (billing_type = 2) e o tipo de fatura para avulsa (invoice_type = 1)
4. Remove os meses de faturamento mensal eventualmente cadastrados
5. Insere o mês correto de faturamento anual conforme o mês de vencimento registrado no legado

Tabelas afetadas no ERP:

• erp.contracts — campos billing_type e invoice_type
• erp.contract_billing_month — mês de faturamento anual corrigido
• maintenance.migracao_integrator_planos_anuais + migracao_integrator_planos_anuais_depara — histórico

Por que existe: O Integrator armazena a configuração técnica detalhada das OLTs (equipamentos de fibra óptica): quais slots existem, quantas portas PON cada slot tem, qual VLAN de dados e de voz está configurada em cada porta, gemport etc. Essas informações não entram no fluxo padrão de migração de conexões — precisam de um script específico.

O que faz: Para cada OLT migrada, monta um JSON estruturado com a configuração completa de cada slot e porta e grava no ponto de acesso correspondente no ERP, incluindo o número total de slots e portas.

Se ocorrer qualquer erro (ex: tabela legada inexistente na versão do cliente), o script registra uma notificação mas não interrompe a migração.

Tabelas afetadas no ERP:

• erp.authentication_access_points — campos configuration (JSON), slots_number, ports_number
• maintenance.migracao_integrator_authentication_access_points_configuration — histórico

Por que existe: O Integrator tem um módulo de desconto por adimplência — um desconto automático para clientes que pagam em dia. Esse desconto fica registrado no legado e precisa ser transferido para as faturas correspondentes no ERP, garantindo que o valor apresentado ao cliente esteja correto.

O que faz: Busca no legado os descontos vinculados a cada fatura e atualiza os campos de desconto por adimplência na fatura do ERP, marcando que o desconto deve ser aplicado conforme configuração do contrato.

Tabelas afetadas no ERP:

• erp.financial_receivable_titles — campos contract_discount_value e contract_discount_use_contract nas faturas (p_is_receivable = TRUE)

Por que existe: Uma fatura (FAT) no ERP pode ter vários títulos abaixo dela — um por agrupador de faturamento do contrato. O script 03.01 muda o agrupador de alguns contratos para CIS depois de as faturas já terem sido criadas. Isso deixa os títulos dessas faturas apontando para o agrupador antigo — desatualizados e incorretos para a geração de cobrança.

O que faz:

1. Identifica todas as faturas migradas cujos títulos estão desatualizados (agrupador mudou após a criação)
2. Salva o histórico completo dos títulos antigos como ocorrência de auditoria na própria fatura
3. Deleta (soft-delete) os títulos desatualizados
4. Recria os títulos distribuindo os valores proporcionalmente entre os agrupadores de faturamento atuais
5. Ajusta arredondamentos de centavos para garantir que a soma dos títulos bata com o valor total da fatura
6. Se uma fatura ficar com valor inconsistente após a recriação, desfaz as alterações nela individualmente (rollback por fatura) e registra o caso para revisão manual
7. Registra eventos de auditoria em todas as faturas e títulos processados

Este é o script de maior impacto desta etapa — toca diretamente em dados financeiros de cobrança. Por isso valida consistência antes e depois de cada fatura e tem mecanismo de rollback individual. Faturas não alteradas por inconsistência ficam registradas em maintenance.migracao_integrator_undo_receivable_titles para revisão manual.

Tabelas afetadas no ERP:

• erp.financial_receivable_titles — títulos deletados e recriados
• erp.financial_receivable_title_occurrences — ocorrências de histórico e evento de recriação inseridos
• erp.financial_receivable_title_hashs — hashes dos novos títulos
• maintenance.migracao_integrator_refazer_titulos_abaixo_das_faturas — backup das faturas processadas
• maintenance.migracao_integrator_undo_receivable_titles — faturas com inconsistência (não alteradas)

Por que existe: As matrizes de atendimento do Integrator (categorias de abertura de chamado) são migradas para o ERP para preservar o histórico das solicitações. Porém, após a migração, essas matrizes do legado devem ser inativadas para que a interface do ERP exiba apenas as matrizes ativas do novo ambiente, sem poluição com registros obsoletos que não fazem mais parte do processo do cliente.

O que faz: Localiza todas as matrizes que vieram da migração (identificadas pelo erp_code com prefixo do cliente) e marca como deletadas.

Tabelas afetadas no ERP:

• erp.solicitation_category_matrices — deleted = TRUE nas matrizes migradas do legado

Esta seção detalha o mapeamento exato entre as colunas do Integrator, a camada intermediária (connector) e o destino final no ERP Voalle. O campo Coluna ERP Voalle indica a tabela e coluna exata onde o dado persiste após a consolidação.

Fonte: legado.empresas Destino: connector.locais → erp.companies_places Script: Cadastros/01.01-Locais.sql

Fonte: legado.grupo_clientes Destino: connector.grupos_pessoas → erp.people_groups Script: Cadastros/03.01-GrupoPessoas.sql

Fonte: legado.grupos_servicos Destino: connector.grupos_servicos → erp.service_product_groups Script: Cadastros/04.01-GruposServicos.sql

Fonte: legado.forma_cobrancas + legado.bancos + legado.conf_boletos Destino: connector.tipos_cobranca → erp.financial_collection_types Script: Cadastros/02.02-TiposCobranca.sql

Fonte: Nenhuma — inseridos estaticamente Destino: connector.grupos_ips → erp.authentication_ip_groups Script: Cadastros/08.02-GrupoIPs.sql

Destino: connector.ips → erp.authentication_ips Script: Cadastros/08.03-IPs.sql

Mapeamento de colunas (erp.authentication_ips):

Fonte: legado.nas_radius + legado.radios Destino: connector.concentradores → erp.authentication_concentrators Script: Cadastros/08.04-Concentradores.sql

Fonte: legado.olt_fibra Destino: connector.pontos_acesso → erp.authentication_access_points Script: Cadastros/08.05-PontodeAcesso.sql

Fonte: legado.condominios + legado.tipo_ponto_roteamento Destino: connector.condominios → erp.authentication_access_points (type=5) Script: Cadastros/08.07-Condominios.sql

Fonte: legado.clientes + legado.observacoes Destino: connector.pessoas → erp.people Script: Operacional/03.02-Pessoas.sql (bloco Clientes)

Fonte: legado.fornecedores Destino: connector.pessoas → erp.people Script: Operacional/03.02-Pessoas.sql (bloco Fornecedores)

Fonte: legado.contatos_cliente Destino: connector.pessoas → erp.people Script: Operacional/03.02-Pessoas.sql (bloco Contatos)

Fonte: legado.prospect Destino: connector.pessoas → erp.people Script: Operacional/03.02-Pessoas.sql (bloco Prospects)

Fonte: legado.usuarios Destino: connector.pessoas → erp.people Script: Operacional/03.02-Pessoas.sql (bloco Usuários)

Fonte: legado.contatos_cliente Destino: connector.pessoas_comunicacao → erp.communications_people Script: Operacional/03.03-Comunicacoes.sql

Fonte: legado.endereco_cli (tipo COBRANÇA) → fallback: legado.clientes Destino: connector.enderecos → erp.people_addresses Script: Operacional/03.04-Enderecos.sql

Fonte: legado.servicos_cli + legado.clientes + legado.vencimentos + legado.forma_cobrancas + legado.bancos Destino: connector.contratos → erp.contracts Script: Operacional/05.01-Contratos.sql

Mapeamento de situação (codest → situacao):

Destino: connector.itens_contrato → erp.contract_items Script: Operacional/05.02-ItensContrato.sql

Fonte: legado.servicos_cli + legado.servicos

Fonte: legado.servicos_cli_extras + legado.servicos_extras

Fonte: legado.terminal_voz

Fonte: legado.pacotes_sc + legado.pacotes

Fonte: legado.historico_cliente Destino: connector.contratos_eventos → erp.contract_events Script: Operacional/05.04-EventosContratos.sql

Fonte: legado.login_radius + legado.ip + legado.onu_fibra + legado.olt_fibra + legado.pon_slot + legado.interfaces_radios + legado.condominios + legado.endereco_cli + legado.clientes Destino: connector.conexoes → erp.authentication_contracts Script: Operacional/08.07-Conexoes.sql (bloco PPPoE/Hotspot)

Script: Operacional/08.07-Conexoes.sql (bloco IP Fixo)

Fonte: legado.faturas + legado.contas_rec + legado.bancos + legado.servicos_cli + legado.clientes Destino: connector.faturas → erp.financial_receivable_titles (origin=8) Script: Operacional/06.01-Faturas.sql

Fonte: legado.faturas (status != 'D', parcelamento='N') + legado.contas_rec + legado.detalhe_faturas + legado.mov_bancario + legado.descontos + legado.juros_contas_rec Destino: connector.faturas_recebidas → erp.financial_receipt_titles Script: Operacional/06.02-FaturasRecebidas.sql

Fonte: legado.contas_rec + legado.detalhe_faturas + legado.faturas + legado.imp_contas_rec + legado.det_nota_fiscal Destino: connector.contas_receber → erp.financial_receivable_titles Script: Operacional/06.03-ContasReceber.sql

Fonte: legado.contas_rec WHERE valor_lan <= valor_pag AND data_bai IS NOT NULL + legado.mov_bancario + legado.descontos + legado.juros_contas_rec Destino: connector.contas_recebidas → erp.financial_receipt_titles Script: Operacional/06.04-ContasRecebidas.sql

Fonte: legado.contas_pag + legado.bancos + legado.det_contas_pag Destino: connector.contas_pagar → erp.financial_payable_titles Script: Operacional/06.05-Contas_Pagar.sql

Fonte: legado.contas_pag WHERE valor_pag > 0 + legado.razao + legado.mov_bancario Destino: connector.contas_pagas → erp.financial_paid_titles Script: Operacional/06.06-Contas_Pagas.sql

Destino: connector.lancamento_caixa_banco → erp.financial_postings Script: Operacional/07.03-LancamentosCaixaBanco.sql

Dois tipos de lançamento são migrados:

Fonte: legado.razao (tipo CPA) + legado.mov_bancario + legado.bancos

Fonte: legado.mov_bancario (tipo CR, sem lançamento CPA correspondente)

Fonte: legado.movimentos_pat (atual='S') + legado.patrimonio + legado.produtos + legado.servicos_cli Destino: connector.patrimonios → erp.patrimonies Script: Operacional/09.02_Patrimonios.sql

Fonte: legado.ocorrencias + legado.ordem_servico Destino: connector.solicitacoes_vinculadas → erp.assignment_links Script: Operacional/10.05-Solicitacoes_vinculos.sql

Destino: connector.relatos → erp.reports Script: Operacional/10.06-Relatos.sql

Campos comuns a todos os relatos: erp.reports.assignment_id (vínculo à ocorrência), erp.reports.person_id (autor), erp.reports.title, erp.reports.description, erp.reports.beginning_date, erp.reports.final_date.

Fonte: legado.encaminhamentos + legado.ocorrencias + legado.usuarios + legado.cargos Destino: connector.encaminhamentos → erp.assignment_person_routings Script: Operacional/10.07-Encaminhamentos.sql

Fonte: legado.bancos + legado.forma_cobrancas + legado.conf_boletos Destino: connector.caixas_bancos → erp.bank_accounts Script: Cadastros/02.01-CaixasBancos.sql

Também é inserida uma conta genérica BA_MIGRACAO (Caixa Interno) para lançamentos sem banco identificado no legado.

Fonte: legado.servicos, legado.servicos_simples, legado.pacotes, legado.servicos_extras, legado.servicos_adicionais Destino: connector.servicos → erp.service_products Script: Cadastros/04.02-Serviços.sql

O script popula connector.servicos em 5 blocos distintos:

Campos migrados:

Fonte: legado.plano_cta Destino: connector.naturezas_financeiras → erp.financers_natures Script: Cadastros/04.03-NaturezasFinanceiras.sql

Fonte: connector.servicos × connector.locais (cross-join) Destino: connector.servicos_regras_faturamento → erp.service_billing_configurations Script: Cadastros/04.04-RegrasFaturamento.sql

Este script não lê o legado diretamente — gera uma regra de faturamento para cada combinação de serviço × local já carregado no connector.

Fonte: connector.servicos (pai e filho) + legado.servicos_tv + legado.servicos_tv_ex Destino: connector.servicos_compostos → erp.service_compositions Script: Cadastros/04.05-Composicoes.sql

Itens de TV (legado.servicos_tv, legado.servicos_tv_ex) também são incluídos como filhos do pacote de TV correspondente.

Fonte: legado.dados_pop Destino: connector.centro_de_resultados → erp.financial_cost_centers Script: Cadastros/06.01-CentroDeResultados.sql

Fonte: legado.categorias + legado.sub_categorias Destino: connector.grupos_produtos → erp.service_product_groups Script: Cadastros/09.01-GrupoProdutos.sql

Também é inserido um grupo genérico SPG_MIG_999_P para produtos sem categoria mapeável no legado.

Fonte: legado.produtos Destino: connector.produtos → erp.service_products (type=1 — Produto) Script: Cadastros/09.03-Produtos.sql

Fonte: legado.cargos Destino: connector.equipe → erp.teams Script: Cadastros/10.02-Equipes.sql

Também é inserida uma equipe genérica TM_MIG_999 para solicitações sem equipe mapeável.

Fonte: legado.oco_padrao + legado.tipo_orden_s Destino: connector.tipos_solicitacao → erp.incident_types Script: Cadastros/10.03-TiposSolicitacoes.sql