fabiojrmoraes

Também não adiantou. Creio que deva ser algum problema com a SEFAZ PR.

Sim. Mas o problema não é este. Com ou sem a tag vItem a mensagem de erro é a mesma. Agradeço.

Boa tarde Estou com um problema em uma emissão de uma nota de débito que é uma nova modalidade incluída na Reforma Tributária. O arquivo XML é validado sem problemas no validador da SEFAZ/RS, e além disso, consegui enviar sem problemas pela SEFAZ/SP. Agora, na SEFAZ aqui do Paraná estou com a seguinte rejeição: 564: Total do Produto / Servico difere do somatorio dos itens. [vProd informado: 106.07, vProd calculado: 0.0] Olhei todas as tag's, e não consigo identificar a inconsistência. Se alguém puder dar uma ajuda... Segue o XML anexo. att. Fábio nfe.xml

Resolvido. Removi a parte do evento de MDF-e. Obrigado.

Desculpe pelo equívoco, a opção de ACBRXMLDocument foi sim marcada na instalação dos componentes. Para ter certeza, fiz o update, e reinstalei tudo novamente, mas o erro continua...

Sim, o svn está atualizado, mas não estou utilizando o ACBrXMLdocument...

Boa tarde Após carregar um arquivo xml de uma CT-e válida via NotasFiscais.LoadFromString, e tentar visualizar a impressão via NotasFiscais.Imprimir, estou tendo a seguinte mensagem de erro: Extra content at the end of the document. Reparei que acontece com os XML's que tem o evento da MDF-e autorizada. Não sei se tem algo haver, mas... Se alguém puder ajudar, agradeceria. att. Fábio

Erro do contador. rs Pode concluir o tópico. Obrigado.

Boa tarde Alguém poderia ajudar caso esteja passando pela mesma situação. No ambiente de homologação da NF-e, no PR, ao tentar autorizar uma nota, estamos com a seguinte rejeição: 974=> CNPJ do responsavel tecnico diverge do cadastrado Estranho que no ambiente de produção funciona sem problemas. Verificamos o cadastro também na receita, e está tudo certo com o CNPJ da empresa de software. att. Fábio

Bom dia Estou fazendo uma consulta de uma chave NFC-e que não existe. Em vez de me retornar o código 217 (Não consta na base de dados da SEFAZ) está me retornando 704 (NFC-e com Data-Hora de emissão atrasada) Será que é algum problema na SEFAZ aqui do Paraná? att. Fábio

A rejeição está acontecendo no Estado do PR. Mas consegui a solução: Devemos informar além das tags citadas, algumas outras: Assim a NFC-e foi autorizada sem problemas.

Boa tarde Fizemos a implementação de pagamento via PIX em nosso sistema, mas ao tentar autorizar a NFC-e, estamos com a seguinte rejeição: Nao informados os dados da operacao de pagamento por cartao de credito / debito Não entendi, pois aparentemente a tag de pagamento está sendo preenchida corretamente: Se alguém puder dar uma luz, agradeço. att. Fábio

Olá. Estou com o mesmo problema? Conseguiu alguma solução?

Beleza. Obrigado pela explicação. Agora está mais claro!

Boa noite Não sei se estou no fórum correto, mas preciso de uma ajuda sobre autorização/impressão TEF e autorização/impressão da NFC-e. Ao finalizar um pedido, antes de abrir uma transação TEF, os dados do Pedido, baixa de estoque, geração de financeiro, etc, já devem estar gravados no banco de dados? Sei que uma transação TEF deve estar autorizada antes da emissão da NFC-e,pois a NFC-e requer os dados da autorização do TEF. Tenho essa dúvida, pois no meu caso aconteceu um problema onde foi autorizado e impresso o comprovante do TEF, mas como houve um problema (uma queda de energia), os dados do Pedido foram perdidos e o cliente ficou com o comprovante TEF sem o pedido no sistema. Agradeço a atenção.

Boa tarde Estamos tentando homologar nosso cliente que fica na cidade de São José/SC. Estamos com uma dificuldade onde não estamos conseguindo autorizar via webservice uma nota de serviço onde não estamos conseguindo encontrar motivo para tal rejeição. Emitindo uma outra nota via https://nfse-saojose.atende.net/, com as mesmas características desta que estamos tentando enviar via webservice, a mesma foi autorizada sem problemas. Fizemos o download do XML desta nota emitida pelo site, e comparamos com o nosso emitido pelo nosso sistema. O grande problema é que estamos tentando emitir esta nota pelo código de serviço 702, onde temos um valor de dedução do imposto (o total a nota é R$ 1.000,00) onde deduzimos R$ 500,00, ou seja, vamos tributar em cima de R$ 500,00 com a alíquota de 3% do ISS, resultando em um valor de R$ 15,00 de imposto. Essa nota esta sendo emitida com a tag situacao_tributaria=4, ou seja, com dedução e retida na fonte. E no momento do envio, temos a seguinte rejeição: Motivo: 00055 - Valor da soma (DEDUÇÃO + ISSRF) é superior ao valor tributável. 00039 - Valor do ISSRF para o serviço prestado não está preenchido corretamente. Arquivo XML autorizado da nota feita pelo site Arquivo XML recusado por emissão via webservice O que não estamos entendendo, é como uma nota, com um XML praticamente igual, foi autorizado via site, e o comportamento via webservice está sendo totalmente outro. Se alguém puder nos ajudar a tentar resolver esta questão, ficaríamos agradecidos, pois tentamos ajuda da IPM, e até agora nada...

Boa tarde tudo bem? Esse seu procedimento de emissão via API v2 engloba também o BOLECODE (QR Code) ? Agradeço. Fábio

Entendi Antônio Agradeço imensamente a ajuda! att. Fábio

Bom dia Antônio, tudo bem? Estou no inicio da implementação do BOLECODE do Itaú, e tenho algumas dúvidas, e se puder responder, agradeceria. Como essa imagem do QRCode para pagamento via PIX é disponibilizada para a inserção nos boletos? É retornada através do registro do arquivo de remessa com esse novo código de ocorrência (71) ? att. Fábio

Bom dia companheiro, tudo bem? Estou também no inicio para a implementação do boleto com o QRCode e verifiquei através da sua dúvida que você já está na caminhada, e possivelmente já resolveu o seu caso. Se puder me ajudar, agradeceria, pois tenho algumas dúvidas. As informações para gerar o QRCode no boleto são retornadas de qual maneira? Você deve gerar essa Location via API para gerar a imagem do QRCode a ser inserida nos boletos? Agradeço. att. Fábio

Olá. Estou com um problema parecido. Conseguiu resolver, e se sim, como?

Boa tarde Estou com o mesmo problema. Foi resolvido? Se foi resolvido, qual foi o procedimento? att.

Boa tarde Tive que fazer uma alteração para que as margens de impressão da NFC-e sejam salvas corretamente. No arquivo fonte estava salvando na chave errada: with DFE.Impressao.NFCe.Emissao.DANFCe do begin Ini.WriteFloat( CSecDANFCe, CKeyDANFCeMargemInf , MargemInf ); Ini.WriteFloat( CSecDANFE, CKeyDANFCeMargemSup , MargemSup ); Ini.WriteFloat( CSecDANFE, CKeyDANFCeMargemDir , MargemDir ); Ini.WriteFloat( CSecDANFE, CKeyDANFCeMargemEsq , MargemEsq ); Ini.WriteFloat( CSecDANFE, CKeyDANFCeLarguraBobina , LarguraBobina ); end; Para: with DFE.Impressao.NFCe.Emissao.DANFCe do begin Ini.WriteFloat( CSecDANFCe, CKeyDANFCeMargemInf , MargemInf ); Ini.WriteFloat( CSecDANFCe, CKeyDANFCeMargemSup , MargemSup ); Ini.WriteFloat( CSecDANFCe, CKeyDANFCeMargemDir , MargemDir ); Ini.WriteFloat( CSecDANFCe, CKeyDANFCeMargemEsq , MargemEsq ); Ini.WriteFloat( CSecDANFCe, CKeyDANFCeLarguraBobina , LarguraBobina ); end;

Reiniciar a cada impressão sem chance né? Isso se torna totalmente inviável, principalmente para o usuário que está do outro lado. Enquanto não for solucionado, permaneço utilizando uma versão anterior. att. Fábio

Boa tarde O problema está na chamada da função ImprimirDANFE, que por algum motivo, está passando a chave anterior. [ENVIO] Versao=PR-v3_4_1 TpAmb=2 VerAplic=PR-v3_4_1 CStat=103 XMotivo=Lote recebido com sucesso CUF=41 NRec=411000002885296 DhRecbto=15/12/2017 16:36:10 TMed=1 Recibo=411000002885296 Autorizado o uso da NF-e [RETORNO] Versao=PR-v3_4_1 TpAmb=2 VerAplic=PR-v3_4_1 NRec=411000002885296 CStat=100 XMotivo=Autorizado o uso da NF-e CUF=41 [NFE128799] Versao=PR-v3_4_1 TpAmb=2 VerAplic=PR-v3_4_1 CStat=100 XMotivo=Autorizado o uso da NF-e CUF=41 ChNFe=41171200502754000140650010001287991001287990 DhRecbto=15/12/2017 16:36:10 NProt=141170000882248 DigVal=dD2oXZ3Py2y6ehSpa8Uyed9ekmw= NFe.ImprimirDANFE("C:\ACBrMonitorPLUS\Retorno\Arquivos\41171200502754000140650010001287981001287984-nfe.xml") OK: Danfe Impresso com sucesso Como dito anteriormente, a versão anterior funciona sem problemas. att. Fábio