.

Sobre a Melhoria.

A Primary Key (PK), ou Chave Primária dos documentos fiscais (Tabelas SF1 e SF2), desde a criação do Protheus  é composta pelos campos: 

F1_FILIAL + F1_DOC + F1_SERIE + F1_FORNECE + F1_LOJA + F1_FORMUL  para Documentos Fiscais de Entrada, e

F2_FILIAL + F2_DOC + F2_SERIE + F2_CLIENTE + F2_LOJA  para Documentos Fiscais de Saída.

Estes campos representam as informações Filial +  Número do Documento + Série + Código do Cliente/Fornecedor + Loja, e no caso dos Documentos Fiscais de Entrada + Fomulário Próprio. Esta identificação única dos documentos fiscais tinha como base a legislação nacional brasileira da época.

Porém, com as mudanças do Governo na legislação, passou a ser previsto a reinicialização da numeração do documento fiscal por período de apuração para os setores de Comunicações e Energia Elétrica embasado nas legislações do Convênio ICMS 115/03 e da Nota Fiscal Eletrônica, ambos tornando legal este procedimento à todos os contribuintes nacionais que operam nestes setores. 

Esta alteração na legislação gerou dificuldade aos clientes Protheus que operam nos setores de Comunicações e Energia Elétrica para reiniciarem os numeradores de seus documentos de saídas, normalmente a cada mês, e aos demais clientes Protheus para entrarem com estes documentos no sistema, pois em ambos os casos há violação da chave primária das tabelas, hora, emitindo os documentos de saída, hora recebendo os documentos emitidos pelas prestadoras de serviços de telecomunicação ou energia elétrica caso o fornecedor emita documentos fiscais em períodos diferentes com a mesma numeração e série não sendo possível a inserção dos dados no sistema.

Exemplo:

Existindo a nota fiscal de número 000000001, série 1, fornecedor 000001, loja 01, data de 01/02/2012,  já gravada no Protheus.

Ao tentar inserir uma nota fiscal com os mesmos dados, o que é previsto pela legislação, porém em outra data, (mês ou ano) o sistema impede a gravação dos dados e acusa duplicidade nas informações, pois já possui esses dados salvos

Tanto na emissão quanto no recebimento dos documentos, esta violação da chave primária era contornada através de uma solução sistêmica que possibilitava a inserção de caracteres como "." (PONTO) somado a série do documento com o proposito de distinguir a PK e possibilitar a emissão e ou entrada do documento no sistema.

Para uma solução efetiva deste problema seria necessário uma alteração acrescentando mais campos a chave primaria das tabelas SF1, SF2 e todas as demais tabelas relacionadas a estas, contudo, esta alteração causaria um impacto muito grande nos códigos fontes, exigindo um grau elevado de codificação tanto no código padrão como nos códigos customizados por clientes.

A TOTVS procurou uma forma de alterar a chave primaria das tabelas de forma a minimizar o máximo possível a codificação das customizações de nossos clientes, promovendo assim uma solução que encontra-se um equilíbrio ideal entre custo x beneficio, haja visto que a alteração da legislação afeta de forma direta os clientes que operam nos setores de Comunicação e Energia Elétrica, mas também de forma indireta todos os demais clientes podem receberem documentos fiscais deste setor com dados que violam a chave primaria atual.

Detalhes da solução:

A solução refere-se em  alterar a chave primária dos documentos fiscais através da modificação do conteúdo gravado nos campos _SERIE e similares, das tabelas dos documentos fiscais e todas as demais tabelas relacionadas a partir destas.

Foram mantidos os mesmos campos na chave  (Número do documento + Série + Cliente/Fornecedor + Loja), porém, uma identificação única passa a ser gravada nos campos _SERIE, com o conteúdo no formato: SSSMMAAAAEEEEE onde:

SSS      = Serie Do Documento Fiscal

MM       = Mês da emissão do documento         

AAAA   = Ano da emissão do documento Fiscal

EEEEE = Espécie do Documento Fiscal

Exemplo do novo conteúdo: “UNI122014NFCEE”

Para tornar tal alteração possível, tomamos algumas medidas com relação a estrutura do sistema:

Campos _SDOC

Foram criados novos campos, “_SDOC”, para armazenar a série real dos documentos fiscais.

A utilização deste campo, varia de acordo com a funcionalidade, um exemplo seria na impressão de relatórios e demais documentos impressos.

Poderá ser utilizado também na construção de filtros, para que a busca possa ser feita com o conteúdo REAL da série.

Estes campos _SDOC serão gravados no mesmo momento em que os campos _SERIE forem gravados.

Para cada campo _SERIE no sistema, foi criado um respectivo _SDOC, baseado na nomenclatura do original.

Exemplo:

Tabela SD2 

 ! Os novos campos, têm as mesmas características dos campos _SERIE atuais, tamanho, título, descrição, etc.

Grupos de Campo 

Foram criados 2 novos grupos de campos (SXG):

094 - Utilizado nos campos _SERIE atual para vincular à todas as tabelas do ERP que tenham relação com a Série do Documento Fiscal; 

Obs. Estes campos terão seu tamanho alterado para o tamanho da Série Oficial do referido país somado a quantidade de posições necessárias para criar o identificador de controle da duplicidade, passando a ser utilizado somente como relacionamento interno no sistema;

095 - Este grupo de campos será atribuído aos novos campos denominados _SDOC, pois caso haja a necessidade de uma alteração futura, todos estes já estarão amarrados ao mesmo grupo.

Índices (SIX)

Foram criados novos índices utilizando os campos _SDOC. Estes índices são uma réplica dos indicies que continham os campos _SERIE, e serão utilizados para filtros e consultas. Os índices que possuem o campo _SERIE, não estarão mais disponíveis para realização de consultas ou filtros quando a melhoria for  implantada pelo usuário, as consultas do sistema serão feitas através dos índices que contenham os campos _SDOC;

Picture

A Picture dos campos _SERIE e _SDOC, passam a ser !!!, com isso todas as Classes e objetos gráficos do ADVPL obedecerão essa PICTURE para manipulação, edição e visualização destes campos mesmo que o novo conteúdo “UNI122014NFCEE” seja gravado nos campos com o novo tamanho de 14 posições, esta solução possibilita que todos os códigos fontes não necessitem ser reescritos ao referenciar os campos.

Exemplo:

A quem se destina esta Melhoria.

• A todos os clientes que operam no setor de Comunicações, Energia Elétrica e que se enquadram na legislação do Convênio ICMS 115/03 e necessitam reiniciar o numerador dos documentos fiscais de saída a cada período de apuração;
  
  
• A todos os clientes que necessitam inserir documentos fiscais de entrada emitidos por um mesmo fornecedor que já tenha emitido o mesmo numero de documento para o usuário e receba a mensagem de violação da chave primária ao tentar incluir o documento de entrada no Protheus.

Sobre a Legislação...

O Convênio ICMS 115/03 é o dispositivo legal, a nível nacional, que dispõe sobre a uniformização e disciplina a emissão, escrituração, manutenção e prestação das informações dos documentos fiscais emitidos em via única por sistema eletrônico de processamento de dados para contribuintes prestadores de serviços de comunicação e fornecedores de energia elétrica.

Para maiores informações consulte os Links disponíveis na internet sobre as legislações

http://www1.fazenda.gov.br/confaz/confaz/convenios/icms/2003/CV115_03.htm

http://www1.fazenda.gov.br/confaz/confaz/ajustes/2005/AJ_007_05.htm

Pré-Requisitos.

•  Estar atualizado com o release 12.1.009 ou superior do Protheus 12 (Dicionário de dados e RPO.);
  
  
• Ter revisado todos os códigos fontes das customizações que tenham relação com documentos fiscais de entrada e saída conforme o tópico CUSTOMIZAÇÕES, O QUE DEVE SER ANALISADO E ALTERADO, deste documento.
  

Restrições.

• A Melhoria não se encontra disponível para ativação em clientes que utilizam o módulo SIGATMS. A disponibilidade para atender estes clientes está prevista para o ano de 2016. Entre em contato com a TOTVS para receber mais informações. 
  

Utilização.

A ativação desta Melhoria é opcional, portanto medidas foram tomadas para que usuários que não desejem utiliza-la, não sejam afetados pelas alterações realizadas.

Sendo assim, o sistema terá um comportamento diferente para cada modelo de dicionário de dados:

Dicionário padrão anterior a versão 12.1.009  

Os campos _SERIE ainda terão o tamanho 3, e os campos _SDOC não existirão na base de dados, portanto a gravação ocorre da maneira NORMAL, sem alteração no conteúdo nos campos _SERIE

Dicionário padrão superior ou igual a versão 12.1.009

Nos dicionários 12.1.009 em diante, os campos _SDOC passam a existir, portanto teremos duas situações diferente neste caso:

• Se a Melhoria NÃO for ativada através do programa UpdSerieNF, os campos _SERIE do grupo de campos 094 “Id de Controle dos Documentos Fiscais” (SXG) ainda estarão no tamanho 3. Neste caso a gravação será feita nos 2 campos simultaneamente, porém com o mesmo conteúdo

          Exemplo: F1_SERIE = “UNI” e F1_SDOC = “UNI”

• Se a Melhoria for ATIVADA através do programa UpdSerieNF, os campos _SERIE do grupo de campos 094 “Id de Controle dos Documentos Fiscais” (SXG) serão alterados para o   tamanho 14. Neste caso a gravação será feita nos 2 campos simultaneamente, porém a nova chave será gravada nos campos _SERIE

          Exemplo: F1_SERIE = “UNI122015NFCEE” e F1_SDOC = “UNI”

Importante

Vale lembrar que após a atualização do dicionário de dados para a versão 12.1.009 ou superior, os 2 campos de série SEMPRE serão gravados simultaneamente, independente da ativação da melhoria.

Passo a Passo para a Ativação.

• Ler as instruções deste manual e montar o plano para ativação conforme as necessidades em que se enquadra;
  
  
• Caso haja a necessidade de adequar as customizações, re-codificar conforme as instruções do manual;
  
  
• Caso existam tabelas de usuário que necessitem se relacionar diretamente com os documentos de entrada e saída, adequar-las conforme este manual;
  
  
• Agendar uma janela com tempo suficiente para a Ativação;
  
  
• Verificar o release do Protheus em uso, caso necessário providenciar a atualização através do compatibilizador UPDDISTR

             Importante!

            Antes de processar o UPDATE, faça um backup da sua base de dados e aplique em modo exclusivo, seguindo todas as orientações da documentação disponível no TDN.

             http://tdn.totvs.com/pages/viewpage.action?pageId=181965468

• Certifique-se de que não haja usuários logados no sistema e execute o programa UpdSerieNF

•  Após a ativação através do programa UpdSerieNF compilar as customizações adequadas ao novo modelo;
  
  
• A melhoria já esta ativada e pronta para entrar em produção.
  
  

Com a Ativação desta melhoria, qual será a nova chave primária (PK) das tabelas SF1 e SF2 (Documentos Fiscais de Entrada e Saída)?

Após a ativação da melhoria, os campos  _SERIE das tabelas do tópico Lista de Tabelas e Campos Tratados tem o seu tamanho alterado de 3 para 14 e passam a conter 4 informações concatenadas nesta ordem: Série + Mês + Ano + Espécie do Documento Fiscal.

 Exemplo de conteúdo: “UNI122014NFCEE”.

Com isso é importante ressaltar que nas tabelas SF1/SD1 e SF2/SD2, embora não tenham sido acrescentados NOVOS campos a chave primária destas tabelas, novas informações foram inseridas na chave primária, e neste caso para se relacionar com elas será necessário utilizar a seguinte chave de relacionamento:

FILIAL + NÚMERO DO DOCUMENTO + SÉRIE + MÊS DA EMISSÃO + ANO DA EMISSÃO + ESPÉCIE DO DOCUMENTO + CÓDIGO FORNECEDOR / CLIENTE + LOJA

Lembre-se:

Não será necessário alterar nos códigos fonte das customizações, instruções como DbSeek() , MsSeek(), Chaves em Whiles, WHERE ou JOINs em querys de relacionamento,  pois os ÍNDICES quem contem os campos _SERIE das tabelas já possuem as informações da nova chave primária. 

Uso de Rotinas Automáticas do Protheus em Customizações.

Em construções onde a operação que envolve a rotina automática for INCLUSÃO, é possível enviar na posição de array do campo _SERIE apenas a série real do documento, por exemplo: "UNI", pois as rotinas de gravação dos documentos trata a gravação correta do ID de controle nos campos _SERIE e a série real no campo _SDOC.

Em construções onde a operação que envolve a rotina automática for ALTERAÇÃO ou EXCLUSÃO, o conteúdo do campo _SERIE, deverá ser enviado com o ID COMPLETO (série+mês de emissão+ano de emissão+espécie do documento) , pois essa informação de chave é necessária para o posicionamento correto de qual documento será alterado ou excluído.

Exemplo:

Utilização dos campos _SERIE do DICIONÁRIO PADRÃO em Customizações.

Todos os campos _SERIE do dicionário padrão são tratados pela função SerieNFId(), caso a customização utilizar operações de visualização, edição ou geração de registros nas tabelas tratadas na melhoria, o usuário pode fazer uso dos recursos da função.

Para detalhes quanto ao uso da função SerieNFId() e quais tabelas e campos são tratados no sistema consulte os tópicos: Funcionamento da Função SerieNFId() e Lista de Tabelas e Campos Tratados no Sistema.

Atenção! A função SERIENFID() NÃO deve ser utilizada em campos que NÃO Constam na Lista de Tabelas e Campos Tratados no Sistema

Customizações, o que deve ser analisado e alterado.

Cada forma de desenvolvimento em um RDMAKE, Customização ou Ponto de Entrada, é muito particular, o que nos impede de termos uma visão singular e um padrão definido como proposta. Nos concentramos neste tópico em apresentar exemplos de possíveis situações e sugestões de como adequar cada situação.

Tenha em mente que antes de ativar a nova funcionalidade, TODAS as customizações deverão ser analisadas e previamente alteradas caso haja a necessidade.

TABELAS DE USUÁRIO

Caso possua tabelas de usuário que se relacionem com as tabelas tratadas na lista deste manual, você pode alterar os campos que se referem a série do documento fiscal para o mesmo padrão adotado para a melhoria (Campo _SERIE Tamanho 14, Picture "!!!" ) e criar um novo campo para armazenar a série real do documento fiscal.

Este modelo é opcional no caso de sua customização NÃO se relacionar com as tabelas do sistema, caso opte por ele, códigos onde o campo do usuário grava o conteúdo dos campos padrão _SERIE  ex: ZZZ_SERIE := F1_SERIE não necessitarão de alteração em instruções como dbSeek(), Whiles,  JOINs, WHEREs F1_SERIE = ZZZ_SERIE, e também as DIALOGs que utilizam classes  e objetos gráficos do Protheus não necessitarão de alterações pois obedecerão a PICTURE !!! do campo, mesmo que o tamanho e conteúdo do campo sejam maiores, poupando assim um esforço maior de reescrita do código em alguns casos.

É importante ressaltar é que as tabelas de usuário que necessitam se relacionar com as tabelas tratadas pela melhoria necessitam ter os campos e ou informações que satisfaçam a nova chave primaria (PK) dos documentos fiscais de entrada e saída. a saber:  

FILIAL + NÚMERO DO DOCUMENTO + SÉRIE + MÊS DA EMISSÃO + ANO DA EMISSÃO + ESPÉCIE DO DOCUMENTO + CÓDIGO FORNECEDOR / CLIENTE + LOJA

O QUE DEVE SER ALTERADO

• O tamanho dos campos _SERIE do sistema foi alterado para 14, logo, qualquer campo de usuário que seja gravado com o conteúdo destes, deve ser alterado também para 14 para poder receber o conteúdo completo, em casos de posicionamento isso é obrigatório, ou a tabela NÃO será capaz de se relacionar com as tabelas padrão do sistema;
  
  
• Verificar Filtros que buscam documentos fiscais em sua aplicação levando em consideração que terão vários documentos semelhantes com o mesmo número, série, cliente/fornecedor e loja, o uso do ID de Controle distinguirá cada um deles nesta situação;
  
  
• Verificar as rotinas automáticas que gravam as tabelas da lista de tabelas e campos deste documento, consulte o tópico Rotinas Automáticas;
  
  
• Relatórios, arquivos TXT, XML,Consultas que apresentam a série do documento fiscal a partir dos campos padrão do sistema constantes na lista, utilizar a função SerieNfId() para tratar a visualização destes processos.
  
  
  
  

Funcionamento da Função SerieNfId().

Importante!

Lembrando que esta função só terá efeito para as tabelas PADRAO do sistema, não podendo ser utilizada em tabelas CUSTOMIZADAS.

E as tabelas a serem utilizadas, deverão estar posicionadas no registro desejado, a função não faz nenhum tipo de posicionamento, somente retorna o conteúdo, tamanho, demais características, dos registros posicionados.

A função SerieNFId() é responsável pela manutenção dos campos _SERIE, tanto na gravação, visualização, ou retorno de propriedades:

LISTA DE PARÂMETROS.

cAlias       -> Alias da tabela do campo _SERIE

bOpcao    -> 1 - Gravação (sempre gravará 2 campos o _SERIE e o correspondente _SDOC quando existir no dicionário de dados)

                      2 - Visualização (Retorna o conteúdo gravado nos campos _SERIE ou _SDOC

                      3 - Retorna uma string com  o nome do campo série a ser utilizado Exemplo: F1_SERIE ou F1_SDOC

                      4 - Retorna a chave de pesquisa ID ou serie Real para utilizar em validações dbSeek() ANTES da gravação dos dados editados

                      5 - Retorna o Criavar do campo _SDOC em casos onde o campos _SERIE já esteja com tamanho 14 para gravar o novo modelo

                      6 -  Retorna o TamSX3 do campo _SDOC em casos onde o campos _SERIE já esteja com tamanho 14 para gravar o novo modelo

                      7 -  Retorna o RetTitle do campo _SDOC em casos onde o campos _SERIE já esteja com tamanho 14 para gravar o novo modelo

cCpoOrig -> String contendo o nome do campo da serie Original da tabela padrão Exemplo: F1_SERIE

dEmissao -> Data de Emissão do Documento Fiscal (OPCIONAL Usar somente com opção "1" - Gravação e "4" - Validação)

cEspecie  -> Espécie do Documento Fiscal (OPCIONAL Usar somente com opção "1" - Gravação e "4" - Validação )

cSerieGrv -> Variável Conteúdo da Serie do documento fiscal  a ser gravada (OPCIONAL Usar somente com opção "1" - Gravação e "4"  - Validação)

cNewIdPai-> Campo da série original da tabela PAI ao gravar a tabela FILHO, o foco da utilização é herdar o ID gravado na tabela pai para as tabelas filho sem a necessidade de compor o ID novamente,

Exemplo: F1_SERIE = "UNI122014ESPEC", D1_SERIE, F3_SERIE, FT_SERIE com o mesmo conteúdo 

Exemplos de uso da função utilizando cada opção.

OPÇÃO 1 - GRAVAÇÃO -  Uso em rotina de gravação do campo série utilizando a função SerieNfId(), substituir a gravação direta do campo F1_SERIE onde a função gravará os 2 campos F1_SERIE e F1_SDOC

Neste exemplo, a gravação direta do campo F1_SERIE foi substituída pela utilização da função com a opção 1

Foram passadas as variáveis dDtEmissao, cEspecie e cSerie, e a função se encarrega de montar o ID e realizar a gravação nos campos F1_SERIE e F1_SDOC simultaneamente

OPÇÃO 2 - VISUALIZAÇÃO – Rotina de geração de um arquivo magnético onde a serie do documento fiscal faz parte do layout da obrigação.

 A opção 2 retorna o CONTEÚDO do campo que possui o valor da série REAL, ou seja a série de tamanho 3.

Esta opção pode ser utilizada em relatórios, arquivos magnéticos, ou em qualquer momento em que o conteúdo da série real tenha de ser apresentado.

OPÇÃO 3 – Nome do Campo - Exemplo de substituição de Query em filtro de uma Pergunte com parâmetro Série utilizando a função SerieNfId() com a opção 3

O usuário digita a série real nos parâmetros MV_PAR14 e MV_PAR15, porém a busca deve ser feita no campo onde ela foi gravada, e a opção 3 retorna qual o campo contém a série real.

OPÇÃO 4 – NOVO ID ou SERIE  – Retorna o novo ID ou a Serie Real do documento fiscal conforme o cenário utilizado pelo usuário através da passagem dos parâmetros dEMISSAO, cSERIE e cESPECIE 

Utilizar esta opção quando for necessário montar um ID, para que não haja a necessidade de montar manualmente Exemplo  (validar a inclusão de documento na tabela ANTES da gravação do mesmo.

OPÇÃO 5 – CriaVar – Em caso de necessidade de se obter o CriaVar() do campo que contenha a serie real do documento fiscal mesmo estando com o novo formato de gravação do ID de Controle ativo.

OPÇÃO 6 – TAMSX3()[1]- Exemplo de substituição da função TamSX3()[1] para obter o tamanho do campo Série real, utilizar somente quando houver a necessidade de obter o tamanho da serie real em qualquer cenário de configuração.

OPÇÃO 7 – RetTitle - Exemplo para obter o LABEL do campo _SDOC estando o cliente utilizando o novo formato de gravação do Id de Controle ou não.

Como são tratados os campos _PREFIXO (Financeiro) com a ATIVAÇÃO da Melhoria.

Embora os campos _PREFIXO herdem a série do documento fiscal quando os títulos financeiros são gerados a partir do documento fiscal, estes NÃO sofrerão alterações por conta da nova funcionalidade, devido à complexidade e o impacto desta alteração no modulo SIGAFIN.

Existem diversos campos que utilizam várias informações, entre elas o prefixo, para poder gravar uma chave composta, tornando assim impraticável as alterações do tamanho e características dos campos _PREFIXO

A solução adotada, foi a utilização de uma função auto incremental no momento da gravação dos campos _PREFIXO (SOMA1)

Quando um documento fiscal de entrada e ou saída for incluído gerando títulos financeiros vinculados aos documentos fiscais, haverá uma verificação se já existe essa mesma chave nas tabelas SE1 ou SE2.

Se não houver duplicidade, o sistema fará a gravação normalmente, sem qualquer alteração de como já é feito hoje.

Se encontrar títulos já existentes com a mesma chave, aplicará a função auto incremental SOMA1() no momento da gravação evitando assim a colisão na inclusão do novo título e o seu conteúdo também será gravado nos seus pares F1_PREFIXO e F2_PREFIXO para que a relação seja mantida.

Exemplo:

Existindo na base o seguinte título na SE2:

Ao incluir um documento fiscal de número 000007, série AAA, fornecedor 3, loja 1, o numerador

SOMA1(“AAA”) permitirá a gravação do novo título desta forma:

O campo F1_PREFIXO do documento fiscal incluído estará “AAB” e o campo série F1_SERIE e ou F1_SDOC na tabela SF1 estará “AAA”

Este é um exemplo de como os campos ficarão gravados no banco após a implantação da solução. O exemplo mostra a inclusão de 2 documentos fiscais de entrada com o mesmo número e serie em datas diferentes gerando títulos financeiros na tabela SE2.

ATENÇÃO!

Quando se procura um título financeiro (SE1/SE2) vinculado a uma NF a partir de uma nota fiscal (SF1/SF2), NÃO utilizar como parte da chave, o campo _SÉRIE (F1_SERIE / F2_SERIE) para posicionar nas tabelas SE1 ou SE2, isso é um ERRO, pois segundo a possibilidade aberta nos parâmetros MV_1DUPREF e MV_2DUPREF é possível que outro conteúdo seja gravado nos campos E1_PREFIXO e E2_PREFIXO. 

Da mesma forma ocorre quando se procura uma nota fiscal que esteja vinculada a um título a partir de um título financeiro (SE1/SE2) usando o campo E1_PREFIXO / E2_PREFIXO como parte da chave de busca.

Quando a ATIVAÇÃO da funcionalidade entrar em vigor o tamanho dos campos atuais de série será alterado para 14 posições e o prefixo continuará com 3 posições, fazendo com que essa relação não tenha mais efeito

Portanto os códigos fonte customizados que possuem esta relação precisam ser conforme o exemplo abaixo:

Posicionamento utilizando a tabela SE1 para posicionar a tabela SF

Código INCORRETO:

Deverá ser substituído por:

Exemplo 2:

Posicionando uma nota fiscal a partir de um título financeiro

Deverá ser substituído por: 

Obs. A ordem 1 do índice da tabela SF2 contém o campo F2_SERIE e não o campo F2_PREFIXO, logo deverá ser substituída por uma query:

Reinicializar o Número do Documento quando se utiliza o controle de número pela tabela SD9 - MV_TPNRNFS = 3.

Quando o cliente, usuário do Protheus se enquadra na legislação que determina a reinicialização da numeração do documento fiscal por período de apuração para os setores de Comunicações e Energia Elétrica,  Convênio ICMS 115/03  e o mesmo também utiliza o controle de numeração dos documentos fiscais realizado pela tabela SD9 (Identificado quando o parâmetro MV_TPNRNFS = 3), será necessário reiniciar a numeração dos documentos fiscais através da rotina MATA470A - "Reiniciar Numeração dos Documentos Fiscais controlados pela tabela SD9" localizada no menu do modulo SIGAFAT.

O reinicio do numerador se dará através da seleção da série desejada. A cada vez que o numerador de uma determinada série for reiniciado os registros desta série na tabela SD9 serão EXCLUÍDOS gerando um novo controle do numerador para o período.  

Lista de Tabelas e Campos Tratados no Sistema.