rluispaulo7

Bom dia, Caue! Aqui meus clientes estão conseguindo emitir normalmente a nota 5124/5902 com todos os itens indTot = 1, e no valor a receber somente com a soma dos itens 5124, ou seja, o valor líquido da NF-e é maior que o valor a receber. Segue uma publicação de um amigo meu que é contador e entende muito sobre este assunto. Ele contador de uma fábrica que tem parceria com vários fornecedores neste esquema de produção terceirizada. https://www.linkedin.com/posts/edvaldo-marciano-de-o-junior-a2b248ba_regularização-das-operações-de-industrialização-activity-7368764663511007233-yqdo Também vou portar um trechos de um XML aprovado em produção. Pode ser que o ambiente de homologação da SEFAZ esteja "bugado". Luis Paulo

Bom dia, senhores analistas de sistemas, programadores, e demais sofredores! Hoje tudo de volta ao normal com a regra YA03-10. Notas emitidas normalmente usando indTot = 1 em todos os itens, como sempre fiz há 17 anos. Vai entender... Logo, eu acho que tópico finalizado. Agradeço à todos pela ajuda. Luis Paulo

Panda, conversando com um amigo que é contador há mais de 30 anos e entende muito desse tipo de nota 5124/5902, chegamos à conclusão que nesse caso os 2 CFOP's devem estar na mesma nota, e o valor líquido da nota deve ser mesmo a soma dos itens 5124. Os itens 5902 devem estar na mesma nota com a tag indTot = 0. Resumindo: 5124 indTot = 1 e 5902 indTot = 0. Desta forma funciona e atende a legislação. Luis Paulo

O correto é somar. É a mesma lógica de fazer notas separadas por CFOP. Emitindo uma única nota com os mais de 1 CFOP, deve-se somar tudo no valor líquido, incluindo descontos (que é muito raro em industrialização). Mas a regra YA03-10 matou quem faz este tipo de nota. Onde eu consegui separar em 2 notas - com muitas reclamações -, deu certo, mas tem aqueles que querem industrialização e retorno na mesma nota, daí do jeito que sempre foi, não funciona (todos os itens com indTot = 1.

Nada feito, Panda. A regra YA03-10 começou hoje na base de produção de SP e também na base de homologação. Até sexta-feira passada estava tudo normal. Mas hoje, nada feito. Há 17 anos eu emitia estas notas 5124/5902 da mesma forma: o campo Total.ICMSTot.vProd e Total.ICMSTot.vNF somando todos os itens 5124 e 5902, e na parte de Cobr.Fat.vLiq e Cobr.Dup.vDup apenas a soma dos itens 5124 (que são os valores a receber). Tentei essa forma que está no artigo que eu citei usando indTot = 1 em todos os itens, mas nada feito. Luis Paulo

Complementando o que eu disse: 14. Com relação ao preenchimento dos campos “Valor total dos produtos” e “Valor total da nota”, lembramos que o artigo 40 da Portaria CAT nº 162/2008 determina que “aplica-se à NF-e e ao DANFE subsidiariamente a disciplina relativa à Nota Fiscal, modelo 1 ou 1-A”. https://legislacao.fazenda.sp.gov.br/Paginas/RC2144_2013.aspx

Leandro, eu usei a tag do item Prod.IndTot := itSomaTotalNFe quando for o CFOP 5124, e Prod.IndTot := itNaoSomaTotalNFe quando CFOP 5902. Funciona, porém o valor líquido da nota fiscal fica apenas com a soma dos itens 5124, ignorando os itens CFOP 5902. Eu não creio isto estar correto. Essa nova regra de validação parece não levar em conta este caso de nota conjugada 5124/5902. O valor líquido deve ser a soma de todos os itens (5124 e 5902), e o faturamento da nota apenas a soma dos itens 5124. Eu sou contador, e afirmo que não estão corretas as nossas saídas. Eu não vejo outra saída. Luis Paulo

Estou com o mesmo problema quando é nota com 2 CFOP's, que no meu caso é 5124 e 5902. Pedi para os meus clientes emitirem notas separadas, porém tem empresas que só aceitam na mesma nota. Isto aqui deve resolver, mas eu não concordo desta forma, pois o valor do 5902 deve sim compor o valor líquido da nota.

Juliomar, bom dia! Me desculpe a demora para o feedback. Fiz vários testes com as novas untis que você disponibilizou. Funciona, porém após o retorno da SEFAZ é necessário atribuir as propriedades do retorno e usar acionar novamente a função GerarXML do componente ACBrNFe. Se apenas salvar o XML montado após o retorno, a tag <infProt> não vem com o "Id" na frente, mesmo com todos os dados do protocolo carregados no componente. Em suma: funciona, não da forma esperada, mas carregando o componente com os dados de retorno e gerando o XML novamente, funciona. Muito obrigado pela ajuda. Acredito que pode fechar este tópico. Luis Paulo

Agora que eu vi as units. Obrigado, Juliomar! Vou fazer os testes e retorno.

Então. Os meus clientes são muito tranquilos. Com eles é de boa. O problema é o cliente deles que não conseguem importar o XML para dentro do ERP deles. Daí ficam enchendo que não vão comprar mais por causa do XML. Blá blá blá. Fica ruim pra mim com os meus clientes.

Que eu tive problemas são 3, mas só um usuário do sistema ERP do cliente me ajudou: o sistema da Omie. Quando o XML vai apenas com o início do grupo de protoloco <infProt>, não importa. Dá erro. Quando eu baixo o XML da SEFAZ-SP ou ambiente nacional de forma manual com o certificado, vem certo <infProt Id="Id999999999999">. O ERP da Omie importa. O pior é zombaria dos usuários dos outros ERPs: - Só o seu XML que não importa. Falam isto para os meus clientes. É complicado. Uma "boa alma" de uma empresa de SP que me ajudou.

Juliomar, fiz a alteração no pcnNFeW.pas conforme imagem anterior. Recompilei o componente, e na compilação do meu aplicativo só passa nesse bloco quando eu uso a funções ACBrNFe1.NotasFiscais.GerarNFe ou ACBrNFe1.NotasFiscais.Items[I].GerarXML com o campo ACBrNFe1.NotasFiscais.Items[I].NFe.procNFe.nProt preenchido. No momento de gerar o XML antes de enviar à SEFAZ, por motivos óbvios, não temos o número do protocolo, então a execução não passa por esse bloco. Depois da nota emitida, carregando o XML para o componente ACBrNFe, também não passa por esse bloco, e a tag <InfProt> vem com todos os dados do protocolo, porém, sem a informação que eu preciso <InfProt Id="ID9999999999999">. Então eu uso LoadFromFile do ACBrNFe com a nota aprovada e todos os dados do protocolo, porém passando o nProt numa nova geração de XML. Aparentemente funcionou. No ambiente de homologação, tudo ok. Em anexo um exemplo da forma que eu fiz para que <InfProt Id="ID9999999999999"> funcione. Foi uma solução que eu consegui no susto,então eu não tenho como avaliar se está resolvido. Agradeço por me mostrar o caminho. Obrigado mesmo! O meu arquivo de exemplo. Luis Paulo Exemplo.pas

Obrigado, Juliomar. Mas será que só eu estou com este problema? rs Eu fiz esta modificação no pcnNFeW.pas para teste. Não funcionou. Como eu não sou expert no código fonte do ACBr pode ser que não seja somente isto.

A versão do pcnNFeW.pas que eu uso agora: Aqui que deve estar o pulo do gato. Eu acho que é aqui que NÃO gera a tag [infProt Id=""] para ficar desta forma:

Complementando: uso Delphi Athens 12.1 com o componente ACBrNFe.

PCN, Juliomar. Minha rotina de consulta à SEFAZ-SP carregando o XML já autorizado, que o ACBrNFe salva na pasta PatchNFe no envio: nfePrincipal.NotasFiscais.LoadFromFile('C:\XML\35240856051378000179550010000052861588618869-nfe '); nfePrincipal.Consultar; if (nfePrincipal.WebServices.Consulta.cStat = 100) then begin Chave:= nfePrincipal.WebServices.Consulta.NFeChave, Protocolo:= nfePrincipal.WebServices.Consulta.Protocolo, DataHoraRecibo:= nfePrincipal.WebServices.Consulta.DhRecbto); end;

Olá, bom dia! Eu pesquisei aqui no fórum e não encontrei a respota de como obter preenchida a tag <infProt Id= que deve retornar após a emissão da NF-e ou consulta. Na SEFAZ-SP o retorno vem com sem a tag preenchida. Já na consulta do ambiente nacional está ok. Isto tem dificultado a importação do XML em outros sistemas. Retorno da emissão e da consulta na SEFAZ-SP usando o ACBrNFe (uso desde 2009). Retorno da consulta do portal nacional com a tag <infProt> preenchida (consulta manual usando certificado digital). Como vocês têm resolvido? Depois de 15 ano usando o ACBrNFe é a primeira vez que tenho um problema difícil de resolver. Muito obrigado. Luis Paulo

No caso do CST 00 não é pra dar problema. Conferiu a alíquota interna do Estado de destino? Pode estar aí o problema. Se for produto importado, é 4% a alíquota interestadual, senão depende do Estado de origem (7% ou 12%). No caso do CST 60, posso estar enganado, mas acredito que não haja partilha do ICMS, afinal, já foi retido na fonte. Quando é venda de produto sujeito a ST no Estado de destino, o CST é 10 (tudo depende do destino), diferente de quando a operação de venda é dentro do Estado do emitente. Verifique isso também. Eu tenho clientes RPA que compram do fornecedor com a retenção do ST, e na venda fora do Estado, dependendo do produto, uso CST 00 com a partilha. CST 60 fora do Estado para consumidor final é raro.

O emitente é RPA? Tanto o CST 00 quanto 0 CST 60 estão com o mesmo problema?

Nesse caso, tem que seguir a NT 2020.05.

Para quem está tendo problema com venda fora do Estado para não contribuinte do ICMS, sendo o emitente Simples Nacional, a solução é muito simples: não destacar / calcular os campos referentes à partilha do ICMS, ou seja, basta zerar tudo. Até ontem a nf-e era aprovada normalmente, hoje não mais. Aqui a empresa emitente é Simples Nacional, vende fora do Estado para não contribuintes do ICMS e ainda produtos importados. O meu CSOSN é 2 102. Zerei todo o cálculo e funcionou. Att. Luis Paulo

Bom dia! Eu consegui resolver esse erro atualizando o ACBr que está na versão 16895 e atualizando a minha pasta de Schemas com os arquivos disponíveis nas pastas do ACBr (..\Exemplos\ACBrDFe). Tanto para notas com CST00 ou CST60 estão funcionando perfeitamente agora. Luis Paulo Rodrigues

Bom dia! Ambiente de Produção aqui em SP com o mesmo problema. Parece ser a SEFAZ mesmo. Ontem o ambiente de contingência nacional estava habilitado, hoje não mais. Vamos aguardar. Estou tentando contato com a SEFAZ e verificando o tempo todo se a contingência está habilitada. Não é problema no componente ACBrNFe!

Bom dia! Também estou com o mesmo problema. Acredito não ser problema na aplicação, e sim na SEFAZ-SP.