O Registro 51
O Registro 51 é relativo às operações de nota fiscal com IPI, deve ser gerado para as operações de entrada e saída e contém informações totalizadas, tais como CNPJ do fornecedor/destinatário, Inscrição Estadual do fornecedor/destinatário, Valor Total da nota fiscal, dentre outros.
Diferentemente dos registros 10 e 11, cada arquivo magnético pode conter mais de 01 (um) Registro 51, um para cada nota fiscal de entrada e/ou saída da empresa. Sua formatação deve ser feita de acordo com a Tabela 01.
 

Tabela 01: Formato do Registro 51 conforme convênio do Sintegra

O Registro 51 e o seu Sistema Gerencial
Até agora abordamos o Registro 51 apenas do ponto de vista teórico, conforme apresentado na documentação oficial dos convênios que regulamentam o Sintegra. Mas como implementar tudo isso na prática? O que o Registro 51 representa para o meu aplicativo gerencial?

Tipicamente para armazenar as informações das operações de entrada e saída de notas fiscais em um sistema gerencial, utiliza-se um sistema de tabela Master-Detail.
A tabela Master (daqui por diante referenciada como tabela de “NOTAS_FISCAIS”) armazena as informações totalizadas das notas fiscais, como valor total dos produtos, valor total do IPI, CFOP, CNPJ do fornecedor/destinatário e etc.
A tabela Detail (daqui por diante referenciada como tabela de “ITEM_NOTA_FISCAL”) armazena as informações relativas a cada item constante das notas fiscais, como código de produto, quantidade, preço, alíquota, sub-total e etc.
Sendo assim, as informações relativas ao Registro 51 estão presentes na tabela de NOTA_FISCAL, ou seja, na tabela onde estão armazenadas as informações totalizadas das operações de entrada e saída de notas fiscais.
Para fazer o cadastro das informações no sistema, deve-se então criar telas de cadastro de entrada e saída de nota fiscal, como mostrados na Figura 01 e Figura 02 respectivamente.
 

Figura 01: Tela de Entrada de Nota Fiscal no sistema gerencial Tk-ERP

Figura 02: Tela de Saída de Nota Fiscal no sistema gerencial Tk-ERP

As telas criadas devem permitir o cadastro de todas as informações necessárias ao Sintegra. No entanto, antes de serem gravadas no banco de dados, tais informações devem ser previamente validadas, de forma a evitar problemas futuros.
Em um próximo artigo abordaremos em detalhes a validação de campos específicos do Sintegra como o CNPJ, Inscrição Estadual dentre outros.

A seguir estão listados os principais campos referentes ao Registro 51 que devem ser validados no momento do cadastro. São eles:
        1. CNPJ do Destinatário/Fornecedor – Deve conter um valor de CNPJ/CPF válido calculado conforme algoritmo próprio de validação. Caso o destinatário/fornecedor seja isento do CNPJ o campo deve ser preenchido com o CPF. Caso se trate de operação com o exterior, o campo não deve ser preenchido.
        2. Inscrição Estadual do Destinatário/Fornecedor - Deve conter um valor de Inscrição Estadual válido calculado conforme algoritmo próprio de validação, ou caso o destinatário/fornecedor seja isento do Inscrição Estadual (exemplo empresas no exterior) o campo deve ser preenchido com a String “ISENTO”
        3. UF - Deve conter um valor de Unidade da Federação válido, ou caso se trate de operação com o exterior, o campo deve ser preenchido com a String “EX”.
        4. CFOP – O valor do campo de Código Fiscal de Operação e Prestação obedece a uma lógica que envolve as informações de Unidade da Federação da tabela de INFORMANTE (abordada no artigo 06. O Registro10, Registro Mestre do Estabelecimento) e a UF do destinatário/fornecedor a que a nota se refere. Caso o informante e o destinatário/fornecedor sejam da mesma UF, os CFOPs válidos para entrada iniciam-se em 1 e para saída, em 5. Caso o informante e o destinatário/fornecedor sejam de UF distintas, os CFOPs válidos para entrada iniciam-se em 2 e para saída, em 6. Caso se trate de operação com o exterior, os CFOPs válidos para entrada iniciam-se em 3 e para saída, em 7.

Como nem todos os usuários de sistema são necessariamente contribuintes do IPI, faz-se necessário, disponibilizar na tela de “Cadastro de Informante” um campo para configuração, onde o usuário irá informar se sua empresa é ou não contribuinte do IPI, conforme Figura 03.
A configuração deste campo irá determinar posteriormente se o sistema deverá ou não fazer chamadas ao registro 51 da Sintegra32dll.dll.

OBS: Para maiores informações sobre o cadastro de informante, verifique os artigos “06.O Registro10, Registro Mestre do Estabelecimento” e “07.O Registro11, Dados Complementares do Informante”.
 

Figura 03: Tela de cadastro de informante. Configuração determina se cliente é ou não contribuinte do IPI.

O Registro 51 e o Banco de Dados
Segue abaixo uma proposta de estrutura da tabela de “NOTA_FISCAL” para armazenar as informações relativas ao Registro 51 e alteradas através da tela de Cadastro de Entrada de Nota Fiscal e Cadastro de Saída de Nota Fiscal mostradas nas Figura 01 e Figura 02 respectivamente.
Note que os valores marcados em negrito são referentes aos campos do Registro 51, aproveitando a estrutura da tabela de notas fiscais proposta no artigo anterior intitulado “08.O Registro50, Total de Nota Fiscal quanto ao ICMS”.
É muito importante que no momento do cadastro das informações do Registro 51, seja feita a validação dos campos citados, antes que os mesmos sejam salvos definitivamente no banco de dados. Caso contrário, poderão surgir erros durante a geração ou validação do arquivo magnético.
 

CREATE TABLE "NOTA_FISCAL"
(
"COD_NOTA_FICAL" INTEGER,
"CNPJ_DF" VARCHAR(20),
"IE_DF" VARCHAR(20),
"DATA_ER" TIMESTAMP default 'now',
"UF_DF" CHAR(2),
"MODELO" CHAR(2),
"SERIE" VARCHAR(10),
"NUM" VARCHAR(10),
"CFOP" VARCHAR(4),
"EMITENTE" CHAR(1),
"VALOR_TOTAL" NUMERIC(15, 2),
"BASE_ICMS" NUMERIC(15, 2),
"VALOR_ICMS" NUMERIC(15, 2),
"VALOR_ISENTO_ICMS" NUMERIC(15, 2),
"VALOR_OUTRAS_ICMS" NUMERIC(15, 2),
"ALIQUOTA_ICMS" NUMERIC(15, 2),
"SITUACAO" VARCHAR(1),
"TIPO" VARCHAR(1),
"VALOR_IPI" NUMERIC(15, 2),
"VALOR_ISENTO_IPI" NUMERIC(15, 2),
" VALOR_OUTRAS_IPI" NUMERIC(15, 2),
PRIMARY KEY ("COD_NOTA_FISCAL")
);
 

Listagem 01: Proposta de estrutura da tabela de “NOTA_FISCAL” para armazenar as informações relativas ao Registro 51.

Algumas observações a respeito da estrutura proposta na Listagem 01 incluem:
    • Os campos com abreviação “_DF” dizem respeito ao destinatário/fornecedor.
    • Os campos com abreviação “_ER” dizem respeito a emissão/recebimento.
    • A escolha dos tamanhos de cada campo não deve levar em conta apenas o valor presente na tabela do Sintegra, pois alguns campos podem conter máscaras de formatação e caso as informações sejam armazenadas com a sua máscara de formatação serão necessários espaços extras, a exemplo do campo de CNPJ que costuma ser armazenado com pontos, barras e traços.
    • O campo “tipo” apesar de não estar presente na tabela do registro 51, deve ser adicionado de forma facilitar o uso de uma única tabela para armazenar registros de entrada e saída. Seu valor deve ser de “E” para entrada e “S” para saídas, ou algo equivalente.

Além das alterações na tabela de “NOTA_FISCAL”, é necessário alterar também a tabela de cadastro de informante para armazenar se o cliente é ou não contribuinte do IPI, conforme mostrado em negrito na Listagem 3.
Note que os valores marcados em negrito são referentes aos campos do Registro 51, aproveitando a estrutura da tabela de casdastro de informante proposta nos artigos anterior intitulados “06.O Registro10, Registro Mestre do Estabelecimento” e “07.O Registro11, Dados Complementares do Informante”.
 

CREATE TABLE "INFORMANTE"
(
"COD_INFORMANTE" INTEGER NOT NULL,
"CNPJ" VARCHAR(14),
"INSC_EST" VARCHAR(14),
"NOME_CONTRIBUINTE" VARCHAR(35),
"MUNICIPIO" VARCHAR(30),
"UF" CHAR(2),
"FAX" VARCHAR(10),
"CONTRIBUINTE_IPI" "BOOLEAN_INT",
PRIMARY KEY ("COD_INFORMANTE")
);
 

Listagem 03: Alteração da estrutura da tabela de “INFORMANTE”.

O tipo “BOOLEAN_INT” utilizado no campo “CONTRIBUINTE_IPI” não é um tipo nativo do Interbase, mas sim um tipo derivado, criado através da criação de um Domain conforme mostrado na Listagem 04.

CREATE DOMAIN "BOOLEAN_INT" AS SMALLINT
DEFAULT 0
CHECK (VALUE IN (0,1)) NOT NULL;

Listagem 04: Domain “boolean_int” criado no interbase, aceita somente inteiros não nulos com valor 0 (zero) ou 1 (um).

Neste caso, quando o cliente não for contribuinte do IPI o campo CONTRIBUINTE_IPI conterá o valor 0 (zero). Quando o cliente for contribuinte do IPI o campo CONTRIBUINTE_IPI conterá o valor 1 (um).
 

O Registro 51 e a Sintegra32dll.dll
A declaração da função Registro 51 na Sintegra32dll.dll é mostrada abaixo:

Function Registro51(CNPJ, Insc_Est, Data_Emissao_Recebimento, UF, Serie, Nro, CFOP, Valor_Total, Valor_IPI, Isenta_IPI, Outras_IPI, Brancos, Situacao: ShortString): ShortString; ; stdcall; external 'SIntegra32Dll.DLL';

Na declaração mostrada acima vemos que a função Registro 51 da Sintegra32dll.dll contém uma variável do tipo ShortString para cada campo do Registro 51 mostrado na Tabela 01.
A função mostrada tem retorno do tipo ShortString, que pode assumir dois tipos de valores: valores em caso de haver erro nos parâmetros de entrada, e valores em caso de não haver erro nos parâmetros de entrada.
 

Valores de retorno da função em caso de erro:
    • '-0 Função Inicia_Sintegra não chamada'
    • '-1 Data de Emissão/Recebimento Inválida (AAAAMMDD) :: ' + Data_Emissao_Recebimento
    • '-2 CNPJ ou CPF Inválido :: ' + CNPJ
    • '-3 Inscrição Estadual Inválida :: ' + Insc_Est
    • '-4 Unidade da Federação Inválida :: ' + UF
    • '-5 Situação do Documento Fiscal quanto ao Cancelamento Inválida :: ' + Situação
    • '-6 Número da Nota Fiscal Inválido :: ' + Nro
    • '-7 Data de Emissão/Recebimento Inválida (AAAAMMDD) :: A Data está fora do período indicado no Registro10 :: ' + 'Data: ' + Data_Emissao_Recebimento + ' Período: ' + Periodo_Str;

Caso não haja erro nos parâmetros de entrada da função, o retorno será uma variável do tipo ShortString contendo o Registro 51 devidamente formatado conforme o padrão da Tabela 01 exemplificado abaixo:
 

‘51’ + CNPJ + Insc_Est + Data_Emissao_Recebimento + UF + Serie + Nro + CFOP + Valor_Total + Valor_IPI + Isenta_IPI + Outras_IPI + Brancos + Situacao;

Gerando o Registro 51 com a Sintegra32dll.dll
Como já foi visto, o processo de geração dos registros em geral passa por basicamente 3 etapas, que são descritas a seguir:
Primeiramente devemos selecionar do banco de dados somente os registros que serão utilizados para a geração do registro. Neste caso devem ser selecionados os registros da tabela de NOTA_FISCAL, que tiverem o valor do campo Data_ER dentro do período solicitado pelo usuário.
Além disso, só devem ser selecionados os registros que tiverem os código de modelo conforme os modelos possíveis de serem adicionados ao Registro 51, conforme descrito em detalhe no artigo “04. Definindo por onde começar”.
Por fim os registros devem ser ordenados pelo campo DATA_ER, conforme a lógica de ordenação “inter-registros” descrita em detalhes no artigo “05. Estrutura do Arquivo Magnético”.
É importante ressaltar, que antes de realizar os passos acima, devemos consultar a tabela de cadastro de informante para saber se o contribuinte é ou não contribuinte do IPI. Pois o processo de geração do Registro 51 descrito acima deve ser executado somente se o campo CONTRIBUINTE_IPI = 1.

//Registro51 - Registros de Total de Nota Fiscal Quanto ao IPI
function TSIntegra_ListFrm.sRegistro51(var Err_Msg: string; var qnt_ok, qnt_erro: integer): boolean;
  var
    TempStr, num_nf: string;
begin
  Result := True;

  if QrySintegra_info['contribuinte_ipi'] = 1 then //testa se contribuinte do IPI
  begin
    with QrySintegra do
    begin
      Close;
      UnPrepare;
      SQL.Clear;

      SQL.Add('SELECT * FROM pedidos WHERE ');
      SQL.Add('(datahora_emissao BETWEEN :datahora_ini AND :datahora_fim) AND (');
      SQL.Add('(modelo_nf = ''01'') OR');
      SQL.Add('(modelo_nf = ''1A''))');
      SQL.Add('ORDER BY datahora_emissao');

      ParamByName('datahora_ini').asdatetime := DataHora_Inicial;
      ParamByName('datahora_fim').asdatetime := DataHora_Final;
      Prepare;
      Open;
      ...

Listagem 02: Query de seleção de registros da tabela de “NOTA_FISCAL” para geração Registro 51.

Em segundo lugar, deve ser feito o loop nos resultados retornados pela execução da Query da Listagem 02 passando os parâmetros para a Sintegra32dll.dll, informando para cada parâmetro, o campo respectivo do banco de dados, como mostrado abaixo.

...
if RecordCount > 0 then
begin
  while not EOF do
  begin
    TempStr := Registro51(Fields.FieldByName('cnpj_df').AsString, //CNPJ
    Fields.FieldByName('ie_df').AsString, //Insc_Est
    datetostr(Fields.FieldByName('data_er').AsDateTime), //Data_ER
    Fields.FieldByName('uf_df').AsString, //UF,
    Fields.FieldByName('serie').AsString, //Serie
    Fields.FieldByName('num').AsString, //Nro
    Fields.FieldByName('cfop').AsString, //CFOP
    formatcurr('0.00', Fields.FieldByName('valor_total').AsFloat), //Valor_Total
    formatcurr('0.00', Fields.FieldByName('valor_ipi').AsFloat), //Valor_IPI
    formatcurr('0.00', Fields.FieldByName('valor_isento_ipi').AsFloat), //Isenta_IPI
    formatcurr('0.00', Fields.FieldByName('valor_outras_ipi').AsFloat), //Outras_IPI
    ' ', //Brancos
    Fields.FieldByName('situacao').AsString //Situacao
    );...

Listagem 03: Loop para chamada da função Registro51 da Sintegra32dll.dll passando registros retornados pela Query de seleção da Listagem 02.

E finalmente, após a passagem dos parâmetros, devemos testar o retorno da sintegra32dll.dll para saber se a geração do registro transcorreu normalmente ou se houve algum erro, como mostrado na Listagem 04.
Em caso de erro, apresentamos na tela o erro e todas as informações passadas para a sintegra32dll.dll como parâmetros. Caso contrário, procede-se o salvamento do retorno formatado do Registro 51 no arquivo magnético de destino (.txt).

...
//Executa o tratamento da string temporária testando se houve erro
//Caso haja erro, executa o log das informações inconsistentes no RichEdit
if not Trata_SIntegra_Str(TempStr) then
begin
  …
  Err_Msg := Err_Msg + #13 +
  ' Cod_Pedidos: ' + Fields.FieldByName('cod_pedidos').AsString + #13 +
  ' CNPJ: ' + Fields.FieldByName('cnpj_df').AsString + #13 +
  ' IE: ' + Fields.FieldByName('ie_df').AsString + #13 +
  ' Emissao: ' + datetostr(Fields.FieldByName('data_er').AsDateTime) + #13 +
  ' UF: ' + Fields.FieldByName('uf_df').AsString + #13 +
  ' Serie: ' + Fields.FieldByName('serie').AsString + #13 +
  ' Nro: ' + Fields.FieldByName('num').AsString + #13 +
  ' CFOP: ' + Fields.FieldByName('cfop').AsString + #13 +
  ' Valor Total: ' + Fields.FieldByName('valor_total').AsString + #13 +
  ' Valor IPI: ' + Fields.FieldByName('valor_ipi').AsString + #13 +
  ' Isenta IPI: ' + Fields.FieldByName('valor_isento_ipi').AsString + #13 +
  ' Outras IPI: ' + Fields.FieldByName('valor_outras_ipi').AsString + #13 +
  ' Brancos: ' + ' ' + #13 +
  ' Situacao: ' + Fields.FieldByName('situacao').AsString;
end
...

Listagem 04: Tratamento e Log do retorno da função Registro50 da Sintegra32dll.dll chamados na Listagem 03.
 

O código mostrado foi retirado e adaptado do demo de geração do Sintegra com banco de dados disponível para download em:
http://www.igara.com.br/downloads/sintegradll/projeto_sintegra32dll_v4.zip

Perguntas e Repostas sobre o Registro 51
As dúvidas relativas ao registro 51 são muito parecidas com as dúvidas relativas ao registro 50, uma vez que ambos são registros do “tipo 50”. Na verdade, se você já conseguiu gerar corretamente o registro 50, provavelmente não vai encontrar problemas ao tentar gerar o registro tipo 51.

1. Como informar uma Nota Fiscal com mais de uma alíquota e/ou CFOP?
Deve ser informado um Registro 50 para cada alíquota. E os valores dos campos 11 (valor total), 12 (base de cálculo do ICMS) e 13 (valor do ICMS), correspondendo à soma dos itens que compõem o mesmo, de tal forma que a soma dos valores dos campos monetários informados nos diversos registros 50, referentes à mesma nota fiscal, correspondam ao valor total da mesma.

2. Por que o Validador informa que não existe um Registro Tipo 50 correspondente?
Pode está acontecendo uma das situações abaixo:
a. registro tipo 50 existe, mas os campos comuns aos dois tipos de registros (CNPJ, Modelo, Série, Subsérie, Número da NF, CFOP e alíquota), não foram informados da mesma forma nos registros tipo 50 e no 54.
b. o Registro tipo 50 realmente não existe. Neste caso deve ser informado pelo menos um registro tipo 50 correspondente.

3. Por que o programa Validador rejeita o registro de entrada (campo 04) informando que o mesmo se encontra fora do período informado no Registro 10 (campos 08 e 09)?
Porque não foi informada a data de entrada, e sim a data de emissão. Ou então, a entrada realmente pertence a outro período. Ex: nota fiscal emitida em 30.03 e recebida em 02.04 deve ser incluída no arquivo do mês de abril.

Por enquanto é só. Para maiores informações sobre o Registro consulte o manual do convênio do sintegra disponível em www.sintegra.gov.br.
Não perca a próxima edição quando continuaremos os estudos a respeito dos registros do Sintegra e veremos a geração do Registro 53.

As telas apresentadas fazem parte do Sistema Tk-EPR da TKS Software.

Este artigo foi baseado nas informações contidas nos seguintes documentos disponíveis para download na internet:
Convênio ICMS 020 de 2000.doc, Convênio ICMS 31 de 1999.doc, CONVÊNIO ICMS 057 de 1995.doc, Convênio ICMS 069 de 2002.doc, CONVÊNIO ICMS 078 de 1997.doc, Convênio ICMS 142 de 2002.doc, convenio_icms_018_de_2004.doc, convenio_icms_019_de_2004.doc, convenio_icms_020_de_2004.doc, Decreto 11614 de 2004.doc, manualdoconvenio57-95 C 76-03.RTF
 

Victory Fernandes é Engenheiro Mestrando em Redes de computadores, e desenvolvedor sócio da TKS Software - Soluções de Automação de Processos e Softwares Dedicados e Administrador do projeto Sintegra32dll.dll ( www.sintegrafacil.com.br ). Pode ser contatado em victory@igara.com.br , ou através dos sites www.igara.com.br  - www.victory.hpg.com.br