fernandocompels

Eu me recordo que nos meus testes (há algum tempo) eu havia tentado e não havia conseguido também. Porém, na época eu estava informando o "vPag" com a "diferença" que não iria ser paga, isto é, com um valor "diferente" de "0.00". Tente fazer conforme comentado pelo Leonardo. Informe o "vPag" com o valor "0.00". Mesmo que a soma dos valores das tags "vPag" não bata com o valor da tag "vNF", pode ser que autorize.

Exatamente... Eu pensei em fazer assim também, porém como já existe uma opção com a descrição "sem pagamento", preferi proceder com a abordagem de separar em duas notas, visto que nesta abordagem todas as informações enviadas serão verdadeiras... Há algum tempo obtive a informação de que é "válido" "misturar" várias naturezas de operação em uma única nota e informar na tag "natOp", a natureza mais "relevante". De fato a SEFAZ permite essa operação. Basta fazer uma nota com vários itens cujos CFOPs destes sejam distintos (desde que a finalidade seja a mesma) e verás que a nota será autorizada. Talvez este seja um começo de uma mudança onde este tipo de situação não seja mais permitido. Como disse anteriormente, "começo a desconfiar que este seja o processo "correto" e que agora a SEFAZ está validando para que as notas sejam transmitidas assim."

Rapaz... Me deparei com tal "nova dificuldade" essa semana também. Até então a nota de retorno de remessa (com o CFOP 5902/5903) eu estava preenchento a tag "vPag" com o mesmo valor da tag "vNF", porém agora tive que alterar para que fique "travado" o valor zerado quando a tag "tPag" for 90. Porém, ainda assim a orientação que estou passando (e que não "trava" a emissão das notas fiscais) aos meus clientes é separar em duas notas. Já faz um tempo considerável desde que isto tem sido um "problema", sendo assim começo a desconfiar que este seja o processo "correto" e que agora a SEFAZ está validando para que as notas sejam transmitidas assim.

O problema não é o schema... O schema está correto! O validador da SEFAZ irá validar somente o schema e irá retornar que está "tudo certo", porém ao transmitir irá retornar rejeição.

Mas eu fiz esses testes... Olhe no exemplo que anexei acima.

A única solução que encontrei até o momento foi essa... Há a possibilidade em que nos itens cujo CFOP seja 5902 / 5903, a tag "indTot" seja preenchida com "0", isto é, sem somar a tag "vProd" desses itens na tag totalizadora "vProd" de modo que assim a tag "vNF" bata com a tag "vPag". Porém, não sei se isto é fiscalmente / legalmente válido.

Bom dia. Na situação específica foram os seguintes CFOPs: 5124 - Industrialização efetuada para outra empresa; 5902 - Retorno de mercadoria utilizada na industrialização por encomenda; 5903 - Retorno de mercadoria recebida para industrialização e não aplicada no referido processo; A finalidade da segunda nota, foi definida como "normal" também, mas não sei se está certo. É um caso a ser pensado. A grosso modo é uma "devolução" mesmo... Principalmente, nas matérias-primas com o CFOP 5903, pois as matérias-primas não foram utilizadas no processo produtivo (esse caso acontece quando o cliente manda mais matérias-primas do que o necessário para produção do produto). Veja o XML que foi rejeitado (antes de separar em duas notas)... (...) <det nItem="1"> <prod> <cProd>123</cProd> <cEAN/> <xProd>ABC</xProd> <NCM>XXXXXXXX</NCM> <CFOP>5124</CFOP> <uCom>PC</uCom> <qCom>600.0000</qCom> <vUnCom>12.4350000000</vUnCom> <vProd>7461.00</vProd> <cEANTrib/> <uTrib>PC</uTrib> <qTrib>600.0000</qTrib> <vUnTrib>12.4350000000</vUnTrib> <indTot>1</indTot> </prod> <imposto> <vTotTrib>0.00</vTotTrib> <ICMS> <ICMS51> <orig>0</orig> <CST>51</CST> </ICMS51> </ICMS> <IPI> <cEnq>109</cEnq> <IPINT> <CST>55</CST> </IPINT> </IPI> <PIS> <PISAliq> <CST>01</CST> <vBC>7461.00</vBC> <pPIS>1.6500</pPIS> <vPIS>123.11</vPIS> </PISAliq> </PIS> <COFINS> <COFINSAliq> <CST>01</CST> <vBC>7461.00</vBC> <pCOFINS>7.6000</pCOFINS> <vCOFINS>567.04</vCOFINS> </COFINSAliq> </COFINS> </imposto> </det> <det nItem="2"> <prod> <cProd>1234</cProd> <cEAN/> <xProd>ABCD</xProd> <NCM>YYYYYYYY</NCM> <CFOP>5902</CFOP> <uCom>KG</uCom> <qCom>1224.0000</qCom> <vUnCom>13.0000000000</vUnCom> <vProd>15912.00</vProd> <cEANTrib/> <uTrib>KG</uTrib> <qTrib>1224.0000</qTrib> <vUnTrib>13.0000000000</vUnTrib> <indTot>1</indTot> </prod> <imposto> <vTotTrib>0.00</vTotTrib> <ICMS> <ICMS40> <orig>0</orig> <CST>50</CST> </ICMS40> </ICMS> <IPI> <cEnq>123</cEnq> <IPINT> <CST>55</CST> </IPINT> </IPI> <PIS> <PISNT> <CST>08</CST> </PISNT> </PIS> <COFINS> <COFINSNT> <CST>08</CST> </COFINSNT> </COFINS> </imposto> </det> <det nItem="3"> <prod> <cProd>1234</cProd> <cEAN/> <xProd>ABCD</xProd> <NCM>YYYYYYYY</NCM> <CFOP>5903</CFOP> <uCom>KG</uCom> <qCom>40.8000</qCom> <vUnCom>13.0000000000</vUnCom> <vProd>530.40</vProd> <cEANTrib/> <uTrib>KG</uTrib> <qTrib>40.8000</qTrib> <vUnTrib>13.0000000000</vUnTrib> <indTot>1</indTot> </prod> <imposto> <vTotTrib>0.00</vTotTrib> <ICMS> <ICMS40> <orig>0</orig> <CST>50</CST> </ICMS40> </ICMS> <IPI> <cEnq>123</cEnq> <IPINT> <CST>55</CST> </IPINT> </IPI> <PIS> <PISNT> <CST>08</CST> </PISNT> </PIS> <COFINS> <COFINSNT> <CST>08</CST> </COFINSNT> </COFINS> </imposto> </det> <total> <ICMSTot> <vBC>0.00</vBC> <vICMS>0.00</vICMS> <vICMSDeson>0.00</vICMSDeson> <vFCPUFDest>0.00</vFCPUFDest> <vICMSUFDest>0.00</vICMSUFDest> <vICMSUFRemet>0.00</vICMSUFRemet> <vFCP>0.00</vFCP> <vBCST>0.00</vBCST> <vST>0.00</vST> <vFCPST>0.00</vFCPST> <vFCPSTRet>0.00</vFCPSTRet> <vProd>23903.40</vProd> <vFrete>0.00</vFrete> <vSeg>0.00</vSeg> <vDesc>0.00</vDesc> <vII>0.00</vII> <vIPI>0.00</vIPI> <vIPIDevol>0.00</vIPIDevol> <vPIS>123.11</vPIS> <vCOFINS>567.04</vCOFINS> <vOutro>0.00</vOutro> <vNF>23903.40</vNF> <vTotTrib>0.00</vTotTrib> </ICMSTot> </total> (...) <cobr> <fat> <nFat>1</nFat> <vOrig>7461.00</vOrig> <vLiq>7461.00</vLiq> </fat> <dup> <nDup>1</nDup> <dVenc>2018-07-23</dVenc> <vDup>2487.00</vDup> </dup> <dup> <nDup>2</nDup> <dVenc>2018-08-06</dVenc> <vDup>2487.00</vDup> </dup> <dup> <nDup>3</nDup> <dVenc>2018-08-21</dVenc> <vDup>2487.00</vDup> </dup> </cobr> <pag> <detPag> <tPag>15</tPag> <vPag>7461.00</vPag> </detPag> <detPag> <tPag>90</tPag> <vPag>16442.40</vPag> </detPag> </pag>

Caro Ricardo. Até então eu estava seguindo essa metodologia para a emissão de algumas notas fiscais. Inclusive notas fiscais de retorno de industrialização, onde em uma única nota fiscal era retornado o produto produzido (contemplando o serviço prestado) e as matérias-primas utilizadas no processo de industrialização. Desde ontem, quando entrou em produção a atualização contemplada pela NT 2016.002 1.50 eu não consigo mais referenciar os pagamentos dessa forma visto que eu voltei a receber a rejeição "865" (Total dos pagamentos menor que o total da nota). Obs: Nesta NT foi adicionada a exceção de número 2 à regra: Pelo que entendi depois de vários testes, se e somente se eu tiver um único "detPag" cujo "tPag" seja "90", a rejeição não acontece. Sendo assim, estou separando as notas fiscais de retorno de industrialização em duas. Uma com o produto produzido (contemplando o serviço prestado) cujo "tPag" pode ser "01, "02", "03", "04", "05", "10", "11", "12", "13", 15", "99" e o "vPag" é o valor que o cliente vai efetivamente pagar. Uma outra com as matérias-primas utilizadas no processo de industrialização cujo "tPag" é "90" e o "vPag" é o valor que o cliente não vai pagar Você tem alguma outra ideia de como posso escriturar a nota fiscal nesta situação? Desde já, agradeço sua atenção! É válido ressaltar que o "tPag" "14" foi removido nesta NT e por consequência a rejeição 867 (Grupo duplicata informado e forma de pagamento não é Duplicata Mercantil) também foi removida. Obs.: Essa NT era prevista para entrar em vigor 16/05. Porém, houve a NT 2016.002 1.51 que alterou os prazos para 04/06... Mas a SEFAZ só começou a validar no dia 07/06.