Páginas filhas
  • DSERTSS2-10367 DT NFSE - Castanhal-PA - Controle de Lote.


01. DADOS GERAIS

Produto:

TSS

Linha de Produto:

Linha Protheus

Segmento:

Serviços

Módulo:NFS-e
Função:- nfse_gen01.prx
- TSSProcNfse.prw
País:Brasil
Ticket:Não há.
Requisito/Story/Issue (informe o requisito relacionado) :
DSERTSS2-10367


02. SITUAÇÃO/REQUISITO

Para o município de Castanhal até o ano passado funcionou normal, depois que virou o ano eles receberam primeiro a rejeição inicial L1 - O Lote já foi recebido anteriormente. O próximo numero do lote 202200000000001.
O cliente entrou em contato com o provedor da prefeitura e tiveram o retorno via e-mail com esses 2 pontos:1)  Toda virada de exercício o número do Lote e o número do RPS voltam para o número 1, alterando apenas o ano inicial. Ex: 202200000000001. Ano que vem seria 202300000000001
2) Caso ainda exista alguma nota fiscal do exercício anterior a ser enviada o número do Lote ficaria 202200000000001 e o número da nota fiscal continuaria a sequencialidade do exercício anterior: Ex: 202100000000345. Lote:202200000000002, Rps: 202100000000346 e assim sucessivamente.

  • Com base neste e-mail, verificado que o TSS envia o número do RPS colocando o ano conforme a data de transmissão, ou seja os RPS que o cliente havia gerado com emissão/competencia dia 31/12/2021, ao realizar a transmissão agora em 2022 o TSS colocou o ano de 2022 no número do RPS, porém o correto seria 2021 para este caso.

Desta forma pode ocorrer a rejeição L11(Conversão de RPS não permitida. É necessario converter os RPS em ordem de numeração. O proximo RPS esperado é de N 202200000000001). Pois ao virar o ano, cliente estava com o número de RPS 00000000350 e o TSS gravou o ano de 202200000000350, porém a prefeitura espera que seja enviado 202100000000350 para o número do RPS.

  • Sobre o item 1 foi realizado teste com a alteração do parâmetro MV_NFEIDLT para o TSS zerar a contagem do lote para as novas transmissões de 2022, porém desta forma o sistema passa a não completar as transmissões devido já possuir os lotes transmitidos anteriormente, a nota fica parada na TSSTR1 e ocorre a mensagem de erro de chave duplicada na tabela SPED055 abaixo no console.log do TSS:

THREAD ERROR ([88252], IPC_ONDEMAND, THIS)  05/01/2022 16:48:54
SPED055: DB error (Insert): -37 File: SPED055 - Error : 2601 (23000) (RC=-1) - [Microsoft][SQL Server Native Client 11.0][SQL Server]Não é possível inserir uma linha de chave duplicada no objeto 'dbo.SPED055' com o índice exclusivo 'SPED055_UNQ'. O valor de chave duplicada é (000003, 000000000000013, F  , 99000000397                                , 0).

03. SOLUÇÃO

Ajuste para rejeição de lote permanecer o mesmo número de lote, não ter erro de chave duplicada e tratamento da numeração do lote na mudança de ano.

04. DEMAIS INFORMAÇÕES

  • Para realizar o controle de numeração de lote houve a necessidade de utilizar os parâmetros:
  • MV_NFSEIDL: Controla o número do lote corrente
  • MV_NFSEIDR: Controla o próximo número de lote.

05. ASSUNTOS RELACIONADOS

  • Não há.