Protótipos
Referenciado por: Análise para Importação de CEPs (Layout DNE) |
Será desenvolvido um programa a ser gravado em "totalicommerce/utilitarios" para ler os arquivos do DFE e gerar um arquivo com script de inclusão dos registros.
No PostgreSQL esse arquivo deve ser baseada em uma exportação de tabela com o comando COPY.
No Oracle a inclusão dos dados deve se dar com comandos de INSERT por causa dos possíveis conflitos com as versões de client.
Requisitos para a implementação
- Sistema deve permitir que se informe o diretório onde estão localizados os arquivos.
- Sistema deve mostrar na tela o nome dos arquivos para qual ele está preparado.
- Sistema deve importar os arquivos:
- DNE_GU_BAIRROS.TXT
- DNE_GU_<UF>_LOGRADOUROS.TXT
- DNE_GU_LOCALIDADES.TXT
- DNE_GU_FAIXAS_CEP_LOCALIDADE.TXT
- Sistema não pode importar se estiver faltando algum arquivo.
- Versão do layout do DNE é 1.9.
Limitações e Escopo da implementação
Essa implementação será executada somente internamente pelo desenvolvimento da Totali, não terá afrescos na sua interface.
Criação da nova tela Ferramenta para Importação de CEPs (DNE)
Essa implementação será executada somente internamente pelo desenvolvimento da Totali, não terá afrescos na sua interface.
Figura 1 ? Tela de Importação de CEPs DNE
Regras para atualização do cliente
Para atualizar a base de CEPs do sistema é necessário fazer alguns tratamentos delicados.
Não se pretende nessa análise definir 100% como isso deve ser feito, apenas se dará um norte para que se inicie a programação.
Primeiro trabalho é importar os dados "DNE_GU_LOCALIDADES.TXT", "DNE_GU_FAIXAS_CEP_LOCALIDADE.TXT", "DNE_GU_BAIRROS.TXT" e "DNE_GU_<UF>_LOGRADOUROS.TXT" em tabelas temporárias.
No PostgreSQL será necessário gerar um dump dessas tabelas para importá-la nos clientes.
No Oracle fazer o insert nessas tabelas temporárias deve ser parte do script.
Além disso, sugere-se que o script criado por esse programa execute as seguintes etapas:
- Fazer um backup da TT_END (relação com TT_MUN), TT_MUN, TT_LOG, TT_BAI e demais tabelas ou registros modificados, de modo que seja possível restaurar os dados mediante scripts - esses scripts não precisarão ser feitos na tarefa).
- Desabilitar (ou droppar no caso do PostgreSQL) as FKs que apontam para a TT_MUN.
- Apagar as relações.
- Apagar registros da TT_LOG, TT_BAI e TT_MUN.
- Importar os dados das tabelas temporárias de Localidades e Faixas na TT_MUN.
- Importar os dados da tabela temporária de bairro na TT_BAI referenciando corretamente a TT_MUN pelos campos "Sigla da UF do Bairro" e "Chave da Localidade do Bairro no DNE" do arquivo.
- Importar os dados da tabela temporária de logradouros na TT_LOG referenciando pelos campos "Sigla da UF", "Chave da Localidade no DNE" e "Chave do Bairro Inicial no DNE".
- Buscar através da relação antiga antiga entre a TT_END e TT_MUN qual será a nova relação.
Todos os registros que referenciavam uma TT_MUN precisam continuar referenciando a TT_MUN após a migração. - Tratar a relação com a TT_MUN das demais tabelas também.
Figura 2 ? MER do relacionamento das tabelas
Descobrir a TT_MUN correta
Será necessário criar uma tabela com o código da TT_MUN antiga e o código da TT_MUN nova.
Para isso, atentar para as seguintes regras:
Primeiro pelo código do IBGE.
Se na relação antiga entre a TT_END e a TT_MUN o Código do IBGE já podia ser encontrado, existe grande chance de ser o código certo.
Segundo pela faixa de CEP.
Comparar pela faixa de CEP inicial e final.
Em ambas as formas, um fator que pode ajudar no processo e a comparação da descrição do município.
Exemplo Prático 1 (São Paulo-SP)
Avaliando o caso de São Paulo.
Atualmente no banco de dados ele está assim:
Figura 3 ? Exemplo de São Paulo
No arquivo de logradouros ele estará assim:
DBRSP08841200009668São Paulo S Paulo MC SPM3550308
No arquivo de faixas de CEP ele estará assim:
DSP262608841200009668São Paulo 02 01 01000001/05999999 DSP262608841200009668São Paulo 02 02 08000000/08499999
No banco deve ficar 2 registros igual ao que está no arquivo de faixas.
No sistema, onde está referenciando o CODIGO 10812, 10813 e 10814 deve referenciar o novo registro da faixa de CEP entre "08000" e "08499" e descrição.
Exemplo Prático 2 (Itacoatiara-AM)
Avaliando o caso de Itacoatiara que ganhou uma faixa de CEP.
No banco ela está assim:
Figura 4 ? Exemplo de Itacoatiara
No arquivo de logradouros ele estará assim:
DBRAM00195300000233Itacoatiara Itacoatiara MC AM 1301902
No arquivo de faixas de CEP ele estará assim:
DAM040400195300000233Itacoatiara 01 01 69100000/69109999
Sistema deve gerar um registro simples na TT_MUN, porém, com a faixa correta.
Nesse caso, o sistema deve encontrar pelo código do IBGE e descrição.
Exemplo Prático 3 (Município sem faixa de CEP)
Municípios sem faixa de CEP vêem com o CEP no próprio arquivo de logradouros.
Não tendo necessidade de buscar o arquivo de faixas de CEP.
DBRAC09676800000001Acrelândia 69945000Acrelândia MN ACR1200013 DBRAC00001900000002Assis Brasil 69935000Assis Brasil MN ACR1200054 DBRAC00002700000003Brasiléia 69932000Brasiléia MN ACR1200104
Importante: Importar cidade em maiúsculo e sem acento.
Exemplo Prático 4 (Vila Gandhi-PR)
Não serão importadas localidades que não sejam municípios, ou seja, que não tenham código do IBGE. Para NF-e é necessário Código do IBGE.
Código IBGE do Município vem no espaço 155 / 161 do arquivo de logradouros.
A localidade Vila Gandhi que existe atualmente no sistema não será mais criada na TT_MUN.
Base atual:
Figura 5 ? Exemplo de Vila Gandhi
Arquivo de logradouros:
DBRPR09060300006816Vila Gandhi 86142000Vl Gandhi DN05865300006496PR
Resultado: Nenhum registro importado.
Se o sistema tiver alguma referência para essa localidade está errado o cadastro.
O sistema deve localizar pela faixa de CEP e UF já do cadastro atualizado.
Se tiver mais de um resultado deve-se optar pelo primeiro.
Layout de Integração
O layout de integração dos arquivos se encontram em:
\\ttadm\Anexos_PRJ\Totali\CEP_2011\LEIAUTES_GU.doc