Rejeição <cStat>852</cStat>

[Otavio Benini]

boa noite, companheiros

no dia 25/06 emiti algumas nfe's de venda em ambiente de testes e tudo correu legal

hoje, depois de testar outras notas exceto vendas, resolvi testar mais uma nfe de venda e eis que surgiu o problema

anexos 2 xml's: da nfe e da rejeição

as tags <fat> e <dup> foram preenchidas normalmente, mas hoje rejeição cStat=852 (!?)

na NT 2016.002.v151 a msg de n. 857 é "Rejeição: Número da parcela inválido ou não informado"

no dia 25 passou legal, inclusive sem a tag  <fat>, que é como faço hoje na versão 3, e também omitindo <fat> e <dup>

também, hoje, a tag cEAN que era informada vazia <cEAN/>  e foi aprovada em 25/06, tive que preencher 'SEM GTIN'

estranhas essas inconsistências.

alguma luz ?

obrigado

Otavio Benini

 

 

35180760497708000121550010000004051000004058-nfe.xml

351000120596202-pro-rec.xml

[Otavio Benini]

complementando informações:

antes de emitir hoje atualizei o ACBr

depois do post testei omitindo <fat>, <dup> e <pag> mas foi rejeitado

testei omitindo <fat> e <dup> e foi aceita - o senão desta condição é que seria preciso relatar valores e vencimentos no campo de observações juntamente com outras informações e torna-lo um "balaio de gato", extenso - os clientes estão acostumados a ler essa informação no DANFE

a tag <pag> deveria ser obrigatória apenas para o modelo 65 NFC-e, conf. anotação no schema "leiauteNFe_v4.00.xsd", embora na NT versão 1.51 mencione a exigência para ambos os modelos 

Editado 5 Julho, 2018 por Otavio Benini
[Enter] indevido

[Amarildo de Matos]

Bom dia

 

<cobr>
      <fat>
        <nFat>405</nFat>
        <vOrig>8690.36</vOrig>
        <vLiq>8690.36</vLiq>
      </fat>
      <dup>
        <nDup>405/1</nDup>
        <dVenc>2018-10-01</dVenc>
        <vDup>8690.36</vDup>
      </dup>
    </cobr>
    <pag>
      <detPag>
        <tPag>15</tPag>
        <vPag>8690.36</vPag>
      </detPag>
    </pag>

 

Onde tem 

1) nDup tem de ser sequencia,001,002,003.. entao no caso acima ficaria assim:

2) no detPag , esta falta indPag, so nao informa indPag quando for tipo 90 sem pagamento

3) O Sefaz esta com um bug, que esta exigindo que tenha vDesc mesmo zerado em fat

Abaixo vou colocar o xml, meu que ja foi validado

<cobr>
        <fat>
          <nFat>NF 4024</nFat>
          <vOrig>850.00</vOrig>
          <vDesc>0.00</vDesc>
          <vLiq>850.00</vLiq>
        </fat>
        <dup>
          <nDup>001</nDup>
          <dVenc>2018-07-18</dVenc>
          <vDup>850.00</vDup>
        </dup>
      </cobr>
      <pag>
        <detPag>
          <indPag>1</indPag>
          <tPag>01</tPag>
          <vPag>850.00</vPag>
        </detPag>
        <detPag>
          <tPag>90</tPag>
          <vPag>150.00</vPag>
        </detPag>
      </pag>

 

<dup>
        <nDup>001</nDup>
        <dVenc>2018-10-01</dVenc>
        <vDup>8690.36</vDup>
      </dup>

 

 

Isso ai.. agora, esperar pelo sefaz solucionar o caso do vDesc.

 

[Otavio Benini]

obrigado, Amarildo

mas a Sefaz de São Paulo tá com bug nessas críticas, ao menos no ambiente de Homologação

semana passa emiti notas em Homologação sem informar <fat> e com o n. completo da duplicata - e foi aceito !!

o xsd determina "n.da duplicata" e aceita até 60 dígitos

testei agora uma nota com 1 duplicata:

nDup = 001; vFat = valor + 0,001 e vDesc = 0,001 - isso obrigou o ACBr a criar a tag vDesc = 0,00 e então foi aceito !

mas <vDesc> em <fat> não é campo obrigatório, não precisaria ser informado 0,00

também na semana passada as tags cEAN e cEANTrib estavam vazias e foi aceito

 

quem pode acionar a SEFAZ para correção desses bugs ?

 

Otavio Benini

[Amarildo de Matos]

Olha.. otavio.. acredito que temos de rezar nesse caso.. de eles se resolverem e arrumarem esses bugs.. ai.. mas o pior de tudo, como vamos dizer ao cliente, que o problema é o sefaz.. para eles, seremos sempre nos programadores..

 

[Juliana Tamizou]

Boa tarde.

Este tópico está inativo a algum tempo e por isso será fechado, caso necessário favor criar um novo tópico.

Att.