leomcl

Boa noite pessoal. Estou com dúvida em qual comando do ACBrTEFD chamar após já ter exibido o qrcode para pagamento do PIX na tela, mas se o cliente quiser cancelar a operação antes de pagar. No manual do SiTEF diz: Eu não consegui entender, pelo fonte, qual procedimento do ACBrTEFD eu devo chamar nesse caso. Alguém saberia me informar? Obrigado.

Bom dia, senhores. Atualizei meus fontes ACBr ontem, 18/11/20, adicionei a seguinte linha no exemplo "Exemplos\ACBrTEFD\NaoFiscal\Delphi": ACBRTEFD1.TEFCliSiTef.Restricoes := '{DevolveStringQRCode=1}'; Aí está exibindo o qrCode PIX. Segue vídeo abaixo mostrando o mesmo funcionando: Como testei com CliSiTEF da Software Express, foi preciso instalar o módulo CardSE e habilitar o PIX, conforme manual fornecido pela própria Software Express. No vídeo, a frase que aparece "You lie, in faith, etc..." é o qrcode, portanto, buscando o campo 584, consegue-se pegar a URL do qrcode, embora nesse caso do CliSiTEF não vejo necessidade disso. Fica a dica, caso seja útil para mais alguém. Att, Leandro

Bom dia, Juliana. Sim, o ajuste que o Ítalo mandou. Só que a SEFAZ MG está fora do ar para emissão de NFCe. A correção dele só funciona quando a SEFAZ está ao menos lenta, mas nem isso está mais. Parou totalmente. Agora, o que amigo acima disse é que ele foi nas Casas Bahia, e outro tinha dito que tinha ido no McDonalds, nesse momento em que a SEFAZ estava parada, e lá emitiram a NFCe normalmente. Talvez o colega possa mandar uma foto da NFCe para vermos se tem algum detalhe que nos fugiu. Obrigado, Leandro

Que estranho. Em outro grupo, uma pessoa foi no McDonalds e também recebeu uma NFCe normalmente. Parece que os grandes não estão tendo problemas. Muito estranho. Você consegue ver na NFCe das Casas Bahia se foi emitida em MG mesmo? att, Leandro

Obrigado, Ítalo, ficou 100%. XML's ok. Leandro

Boa tarde, Ítalo. Mas na hora de gravar a parte de procNFe no XML assinado, vai gravar com os namespaces ou sem eles? Não ficaria errado gravar com eles? Att, Leandro

Bom dia, senhores. Eu também tinha feito essa alteração nos meus fontes semana passa, mas voltei atrás, pelo seguinte: além de alterar nessa função rCampo, também tem que alterar onde salva o retorno no XML da nota, pois sem isso vai salvar com os xmlns errados. Aí não sei se a nota vai ter valor fiscal, dessa forma, e se os sistemas contábeis/terceiros vão conseguir ler esses XML's. Enfim, se forem usar assim, é preciso que verifiquem outros detalhes para não terem problemas futuros. att, Leandro

Bom dia, senhores. Hoje enviando NFCe's para MG (que está em contingência), ela está autorizando, mas o XML está vindo num formato um pouco diferente, e parece que o ACBr não consegue lê-lo. Anexei um XML de antes de problema e um de hoje. Haveria alguma solução ou é aguardar a SEFAZ normalizar totalmente mesmo? Obrigado, Leandro 9259-pro-lot - ANTES DA CONTINGENCIA.xml 12509-pro-lot - HOJE DURANTE A CONTINGENCIA.xml

Bom dia, senhores. Hoje enviando NFCe's para MG, ela está autorizando, mas o XML está vindo num formato um pouco diferente, e parece que o ACBr não consegue lê-lo. Anexei um XML de antes de problema e um de hoje. Haveria alguma solução? Obrigado, Leandro 12509-pro-lot - HOJE DURANTE A CONTINGENCIA.xml 9259-pro-lot - ANTES DA CONTINGENCIA.xml

Ítalo, Deu certo o que você fez. Obrigado. Ainda não está funcionando o cancelamento, mas é problema lá no lado do GovBr, não nosso, já que o XML está batendo 100% com o modelo que me passaram. Leandro

Obrigado, Ítalo. Vou testar e dou retorno.

Sim, por que eu ajustei essas tags debugando o componente, só para ver se passava no webservice deles, mas não passou. De qualquer forma, depois que enviei a mensagem aqui, tentei validar a assinatura do XML deles no site da receita, e deu assinatura inválida. Já a do ACBr deu que era válida. Vou aguardar resposta deles sobre isso. O que eu gostaria de saber mesmo é se consigo fazer o componente não gerar o xmlns e gerar o id e URI só configurando pelo proninv2.ini (pois no xml que enviei eu fiz ajuste nessas tags via debug do Delphi). Segue anexo XML que o ACBr gera se eu não fizer o ajuste manual (Debug) que falei acima. Obrigado,201900000001249-ped-can-gerado-ACBr-sem-debugar.xml Leandro

Bom dia, Ítalo. A novela do cancelamento de NFSe dessa prefeitura ainda continua. O envio funciona, mas o cancelamento não. Me mandaram um XML de exemplo, que assinaram com meu próprio certificado, e eu tentei gerar pelo ACBr igual, mas a assinatura não bateu. Achei estranho. O que tive que fazer foi tirar via código (debugando) o xmlns e incluir o id e o URI, pra bater com o deles. Segue anexo os XML's, se puder dar uma olhada. Talvez o fato de eu ter mexido nessas tags (tirado o xmlns e colocado o valor do FURI=123) tenham influenciado na assinatura. Ou não teria nada a ver? Se sim, gostaria de saber se pelo ProninV2.ini eu conseguiria configurar o ACBr para não gerar a tag xmlns e gerar as tags "id" e "URI", ou só via alteração do componente eu conseguiria isso. Desde já agradeço a ajuda, Leandro 201900000001249-ped-can-Modelo GovBr.xml 201900000001249-ped-can-gerado-pelo-ACBr.xml

Sim, o .ini que te mandei é pra desenvolvimento, por isso está https. Leandro

Carlos, Segue meu pronimv2.ini. Com ele estou emitindo normal em homologação, só não consigo cancelar. Uso o método ACBrNFSe1.EnviarSincrono() Leandro Pronimv2.ini

Carlos, Qual método vc usa para enviar? É o Enviar síncrono? Mude o seguinte no proninv2.ini: UseCertificado = 1 RPS = 1 Coloque https ao invés de http nos endereços de Montes Claros e tente de novo. Leandro

Bom dia, Ítalo. O erro da tag foi corrigido, obrigado. Falta uma pequena correção no PronimV2.ini, no endereço de homologação de Montes Claros/MG agora é https, não mais http, se quiser alterar no repositório. ; Montes Claros/MG RecepcaoLoteRPS_3143302=https://notateste.montesclaros.mg.gov.br/NFSe.Portal.Integracao.Teste/Services.svc Quanto ao erro ao cancelar, continua retornando: O pedido de servico deve conter assinatura digital vinculada a certificado digital padrao ICP Brasil, nao revogado e nao expirado Como se a assinatura estivesse no local errado do XML. Enfim, já mandei o xml pro técnico da prefeitura e estou aguardando retorno deles. Obrigado, Leandro

Bom dia, Ítalo. Eu não tinha testado o cancelamento, e quando fui testar, percebi que o mesmo não está funcionando, mesmo colocando "Cancelar=1" no Proninv2.ini. Debugando, percebi que, ao assinar a tag "Pedido" do XML de cancelamento, o ACBr não fecha a tag CancelarNfseEnvio do XML, gerando um erro no componente. Coloquei algumas linhas conforme print anexo, só para passar, e o erro parou, embora o cancelamento não tenha sido aceito na prefeitura (isso estou discutindo com os técnicos dele ainda). Enfim, se puder ver qual o local correto para colocar essa correção pra gente, eu agradeceria. Estou anexando o .pas também, se for útil. Obrigado, Leandro ACBrDFeSSL.pas

Isso mesmo, Ítalo, eu estou fazendo últimos testes aqui, mas resolveu, usando o envio síncrono. Eu usava a função Gerar, que gera o RPS direto, e la não funcionou. Obrigado, Leandro

Pessoal, Pesquisando mais sobre o assunto, percebi que esse negócio de assinar a transmissão realmente faz parte do padrão Abrasf v2, conforme o seguinte link: https://admin.montesclaros.mg.gov.br/upload/financas/files/nfegov/NFSE-NACIONAL_Manual_De_Integracao.pdf Página 14. Então, imagino que outro provedor também já utilize isso. Se sim, o ACBr já deve ter essa funcionalidade para esse outro provedor. Qualquer ajuda é bem vinda. Leandro

Só para constar, mudei no ProninV2.ini a linha UseCertificado para 1, e agora o erro mudou para: Pedido de servico nao assinado. O pedido de servico deve conter assinatura digital vinculada a certificado digital padrao ICP Brasil, nao revogado e nao expirado. Já mudei várias propridades de 0 para 1 mas nada deu certo. Obrigado.

Bom dia, senhores. Hoje a prefeitura de Montes Claros não está aceitando mais os RPS mesmo mudando pra https. No comunicado abaixo, falam que será necessário o certificado tanto para assinatura quanto para transmissão dos RPS: https://financas.montesclaros.mg.gov.br/pagina/alteracao-endpoint-homologacao-nfse-nova-data-06-05-2019 O erro retornado agora é: Erro Interno: 12044 Erro HTTP: 0 URL: https://nota.montesclaros.mg.gov.br/NFSe.Portal.Integracao/Services.svc Falha Recebendo Dados. Erro:Erro: 12044 - C=BR, O=ICP-Brasil, OU=Secretaria da Receita Federal do Brasil - RFB, CN=AC LINK RFB No ACBr eu consigo fazer essa autenticação do certificado na transmissão também? Será que é isso é o que está faltando? Obrigado, Leandro

Obrigado, Datilas. Vou tentar fazer o tratamento como você sugeriu. att, Leandro

Não consegui não, Hélio. att, Leandro

Bom dia, pessoal. No RJ, a Sefaz não aceita nota com cfop 5929/6929 referenciando NFCe. Você tem que fazer uma NFe para o cliente, não NFCe, nesse caso. O problema é que para NFe não se pode imprimir o DANFE em impressorinhas não-fiscais, a não ser em vendas fora do estabelecimento. E nos PDV's NFC-e's como em supermercados e postos de combustível, tem-se apenas as impressorinhas não-fiscais naquele local. Uma alternativa seria colocar uma impressora A4 lá nos PDV's, ou em um ponto próximo deles. Acho inviável isso, no caso de postos de combustível, onde mal cabe a impressorinha não-fiscal lá no meio da pista. Outra alternativa seria: quando pedirem NFe, imprima na impressora do escritório do estabelecimento. Mas postos de combustível, em sua maioria, fecham o escritório às 18hs e o posto continua funcionando. Enfim, gostaria de saber dos colegas do RJ como estão lidando com esse cenário. Desde já agradeço, Leandro