mbbortolini
-
Total de ítens
217 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por mbbortolini
-
-
Pessoal depois de muita insistência com a SEFAZ-RS, agora pouco me responderam, segue a resposta :
CitarRecebemos a seguinte resposta da equipe técnica.
Verificamos que 3 dos 8 servidores estão com alguma dificuldade de fechar conexões TLS1.2, o que explica a intermintência relatada pelos contribuintes.
Até que o problema seja identificado vamos retirar estes 3 servidores do balanceamento, evitando que os contribuintes sejam atendidos por eles.
Então esperamos que da mesma forma como o erro passou a aparecer o mesmo seja eliminado.
Porém pode ocorrer um pouco de demora na emissão, visto que é quase a metade dos servidores disponíveis.
Mas poderemos tomar aquela
mais tranquilos hoje 
[]s
-
3
-
-
Em 18/07/2019 at 12:28, Leandro_Silva disse:
Bom dia, conseguiu fazer essa consulta usando esses componentes ?
Leandro, com está a sua implementação ?
Não é o mesmo caso, mas estou implementando o consumo da API da Safe2Pay, consegui fazer GET e POST com os componentes indy(idHTTP) e rest(RestClient) neste caso a autenticaçaõ deve ir no header de comunicação e graças a dica do colega @Projeto6 consegui fazer com o RESTClient e com o idHTTP fiz da seguinte forma :
idHttp.Request.CustomHeaders.Clear; idHttp.Request.CustomHeaders.AddValue('NOME_CHAVE','STR_CHAVE');Para o POST o que me ajudou muito além do Postman foi o https://webhook.site/ aqui neste eu consigo ver como o html chega no server, pois eu estava com dificuldades de geração do meu JSON.
Se precisar de ajuda o que sei aprendi na última semana mas posso dar uma força.
-
4 minutos atrás, BigWings disse:
A recomendação do manual é que quando há tentativa de transmissão no modo normal e há erro de comunicação de qualquer tipo, você deve emitir outra NFCe, com nova numeração, em contingência off-line, e marcar a primeira para cancelamento ou inutilização.
realmente, o meu problema é a numeração.
Agora sim faz sentido usar Cancelamento por substituição.
Obrigado @BigWings pela luz
-
1
-
-
continuando...
Nestas duas chaves a diferença é o tag TpEmiss (e o digito verificador)Então qual nota é válida, a que processou na SEFAZ (chave1) ou a que o cliente levou impressa (chave2) ?
Solução 1 :
No retorno de duplicidade temos o seguinte retorno :
Citar539-Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso [chNFe:43190507885188000141650010001331131041390949][nRec:431069695732058]
Seria possível quebrar o retorno pegar a chave que retornou e executar uma consulta na tentativa de recuperar o XML,
Problema : a nota em contingência que o cliente levou, a qual tem uma chave e ao consultar nunca será válida. Ao meu ver isso seria fraude passível de penalizações LOGO SOLUÇÃO 1 é INVÁLIDA.
Solução 2 :
Com o retorno acima, pegar a chave da duplicidade e executar o evento de Cancelamento Por Substituição, aqui temos uma explicação do que é.
Eu ainda não implementei este evento, estou ainda fazendo análise do caso.
Mas aí me deparei com as rejeição para o referido evento :
Citar- Rejeição 910: Chave de Acesso NF-e Substituta inválida
- Rejeição 911: Chave de Acesso NF-e Substituta incorreta
- Rejeição 912: NF-e Substituta inexistente
- Rejeição 913: NF-e Substituta Denegada ou Cancelada
- Rejeição 914: Data de emissão da NF-e Substituta maior que 2 horas da data de emissão da NFe a ser cancelada
- Rejeição 915: Valor total da NF-e Substituta difere do valor da NF-e a ser cancelada
- Rejeição 916: Valor total do ICMS da NF-e Substituta difere do valor da NF-e a ser cancelada
- Rejeição 917: Identificação do destinatário da NF-e Substituta difere da identificação do destinatário da NF-e a ser cancelada
- Rejeição 918: Quantidade de itens da NF-e Substituta difere da quantidade de itens da NF-e a ser cancelada
- Rejeição 919: Item da NF-e Substituta difere do mesmo item da NF-e a ser cancelada
- Rejeição 920: Tipo de Emissão inválido no Cancelamento por Substituição
O que me preocupa é a Rejeição 912 pois a contingência não foi transmitida, logo não vai existir
Problema : ainda estou montando ambiente para verificar o caso, assim que tiver resultado posto aqui.
-
1
-
Senhores, estou enfrentando o mesmo problema, conforme já constatado a maldita instabilidade de internet é o que vem causando isso.
Caso é o seguinte :
- Cliente emitindo NFCe (RS) e em algum momento do dia a conexão de internet se torna instável;
- No log do sistema é possível ver o erro retornado ao executar o serviço de autorização na webservice : 12002 - Time Out;
- No meu tratamento, esse erro é encarado como demora na resposta, logo continuarei invocando o serviço de autorização, no entanto o erro 12002 fica recorrente as vezes por vários minutos até conseguir executar a autorização;
- No entanto em alguns casos após várias tentativa e muitos retornos 12002, o weservice responde diferente, em algum desses momentos a internet de instável passou a falecida ai o retorno é 12007 "O nome do servidor não pode ser resolvido" opa, ai pra mim no meu modesto intendimento isso quer dizer que a internet está OFF, e neste caso, mudo o tipo de emissão para OFF-LINE imprimindo a NFCe em contingência e guardando para posterior transmissão. Até ai nada de anormal.
- Mas aí tem a transmissão da contingência, ai temos Duplicidade, detalhe, com DIFERENÇA NA CHAVE, mas e ai o que isso quer dizer ? conforme já constatado anteriormente, em algumas das transmissões a nota chegou na SEFAZ e foi processada, mas eu não obtive, nem o retorno, nem o XML.
- Na emissão OFF-LINE a recomendação é alterar somente o TIPO de emissão e informar data e motivo da contingência, logo a numeração não é alterada.
Ao meu ver isso é o que resulta na Duplicidade com diferença na chave pois vejam as chaves abaixo
43190507885188000141650010001331131041390949 - Chave da nota emitida na SEFAZ
43190507885188000141650010001331139041390944 - Chave da nota em contingência a ser transmitida, a qual recebeu o retorno de duplicidade -
Resposta da SEFAz - RS sobre o questionamento quanto a aplicação da regra :
CitarTranscrevo abaixo a regra de validação 878. Essa nota diz que a NFC-e deve ser rejeitada se o link informado para consulta estiver incorreto.
Essa definição está na página 73 da Nota Técnica 2016.002. A Nota Técnica pode ser consultada no Portal da NF-e, no link http://www.nfe.fazenda.gov.br/portal/principal.aspx , menu “Documentos / Notas Técnicas”.
Essa regra de validação é opcional por estado. Isso significa que cada estado pode decidir se aplica ou não essa regra de validação.
Os estados de AC, AM, ES, MA, MG, MS, MT, PR, PE, RJ, RN, RO, RS, SE e TO não vinham aplicando essa regra. Esses estados mudaram seu posicionamento, e decidiram começar a aplicar a regra.
Para esses estados, essa regra começou a ser aplicada no ambiente de homologação no dia 22/04, e vai ser aplicada no ambiente de produção a partir do dia 20/05.
Portanto, se as suas NFC-es começaram a ser rejeitadas no ambiente de homologação a partir do dia 22/04, então isso quer dizer que seu sistema estava informando um link para consulta incorreto, no arquivo XML.
No RS, o link informado na tag “qrCode” deve ser https://www.sefaz.rs.gov.br/NFCE/NFCE-COM.aspx (acompanhado da função CDATA).
E o link informado na tag “urlChave” deve ser www.sefaz.rs.gov.br/nfce/consulta
-
1
-
-
11 minutos atrás, charles.libano disse:
Atualizei os fontes para a rev. 16943.
Rodei o Compila_RES.bat (deu o erro Error Could not open input file ACBrNFeServicos.rc)
Abri meu projeto. Dei build.
Rodei e o erro persiste.
Falta fazer algo?
Obrigado.
Charles
@charles.libano executa somente o ACBrNFeServicos.rc (duplo click, compilador do delphi(BRCC32 se encarregará de resolver a questão e transformar o ACBrNFeServicos.ini no ACBrNFeServicos.RES.
Pra conferir a alteração abra o ACBrNFeServicos.RES e verifique a URL na seção do seu estado.
-
1
-
-
2 horas atrás, Juliana Tamizou disse:
Bom dia.
Algum de vocês testou estas alterações em ambiente de produção?
Att.
@Juliana Tamizou, creio que a regra esteja ativa somente em homologação, caso contrário todos meus clientes estariam rejeitando.
No caso estou falando especificamente da SEFAZ-RS
-
1
-
-
Senhores, a alteração em AcbrNFeServicos.ini
dever ser a seguinte :
DE
CitarPARA
Citar -
Obrigado @MFincotto pelo retorno, no entanto não satisfeito com a causa, fui mais afundo. (já estou me preparando pra quando meu guri chegar na idade dos porquês
)
Causa de tudo isso :
Maldita regra de validação ZX03-20 incluída na NT 2016-002 v1.61 (NT sem fim).
Nesta NT a regra diz que :
CitarEndereço do site da UF para a Consulta por chave de acesso difere do previsto.
Observação1: URLs, por UF, utilizadas para consulta por chave de acesso acesse: http://nfce.encat.org/consumidor/consulte-nota/
Observação2: regra de validação opcional por UF
Observação3: regra de validação vigente a partir de 01/04/2019.Em Observações1 em consulta a URL no endereço http://nfce.encat.org/consumidor/consulte-nota/ temos a seguinte URL, no caso RS :
Rio Grande do Sul www.sefaz.rs.gov.br/nfce/consulta Até aqui tudo em conformidade, mas note que que acessar a URL você será direcionada para https://www.sefaz.rs.gov.br/NFCE/NFCE-COM.aspx mas isso não é mistério, redirecionamento de URL é normal.
Mas e ai ? E a regra ??? Então para sanar a rejeição devemos alterar a URL para uma que não está prevista na NT.
Só que, não para por aqui, vocês tentaram consulta o QrCode gerado ? Aqui não deu :
Solicitei informações ao SEFAZ e irei aguardar posicionamento, mas já estou deixando um versão pronta caso entre a validação em produção.
Mais uma vez obrigado @MFincotto
-
1
-
-
Boa noite pessoal, estou com o mesmo perrengue aqui. Já vi que alterando o INI vai funcionar, mas debugando o componente pude notar que quando vai montar a URL, o nome do do serviço passado para a função está sendo alterado.
em ACBrDFe.pas é chamada a procedure LerServicoChaveDeParams com os seguinte parâmentros :
NomeSessao 'NFCe_RS_H'
NomeServico 'URL-ConsultaNFCe'
Versao 2
URL ''Ocorre que na linha 454 e 455 este código monta a Chave e ChaveBase com a versão junto :
ChaveBase := UpperCase(NomeServico + '_'); Chave := ChaveBase + FloatToString(VersaoAtual,'.','0.00');ficando assim :
Chave 'URL-CONSULTANFCE_2.00'
ChaveBase 'URL-CONSULTANFCE_'abaixo, na linha 448 existe o seguinte código :
Citarif Versao > 0 then
URL := FPIniParams.ReadString(NomeSessao, Chave, '') <<< entra aqui, uma vez que QrCode = v2
else
URL := FPIniParams.ReadString(NomeSessao, NomeServico, '');Assim a minha condição está lendo o INI com os seguintes parâmetros :
NomeSessao 'NFCe_RS_H' e Chave 'URL-CONSULTANFCE_2.00'
Logo o INI está assim :
CitarURL-QRCode=https://www.sefaz.rs.gov.br/NFCE/NFCE-COM.aspx
URL-ConsultaNFCe=https://www.sefaz.rs.gov.br/NFE/NFE-NFC.aspx
URL-ConsultaNFCe_2.00=http://www.sefaz.rs.gov.br/nfce/consultagerando o XML com a referida inconsistência.
Baseado nisso temos :
1 - Alterar o INI;
2 - O estagiário da SAFAZ aplicou a validação hoje, uma vez que ontem emiti sem problemas.
3 - Hoje é em homologação e amanhã será o de produção ???
-
Em 11/10/2018 at 17:41, William F. L. disse:
Olá pessoal, estou com alguns clientes recebendo o seguinte erro "Falha ao interpretar o XML "xmlParseDoc"", tanto para certificados A1 e A3, porém esse erro surgiu sem motivo aparente.
No fórum existem pelo menos uma dúzia de postes com o mesmo erro, li quase todos mas não obtive resultado.
Já tentei diversas coisas:
- Preenchi notas com acento e sem acento
- Atualizei os fontes e os schemas
- Limpei tudo e reinstalei
Observações:
O componente já está configurado para retirar acentos e espaços!
@William F. L. verifique se as DLLs(libXML2 e XMLSec) estão atualizadas nestes clientes,
-
1
-
-
3 horas atrás, DSilva disse:
Bom dia,
Estou tendo dificuldade em gerar o xml no amb. homologação para o MS, apare esse erro ''Rejeicao: Falha no esquema XML'', não consegui identificar uso os componentes no pdv e ja atualizados hoje e os esquemas tb.
nunca tive esse tipo de problema, estou usando as configurações que o estado MS exige.
fuso horario Cuiabá pq é uma hora a menos.
cryWinCrypt
httpWinHttp
libWinCrypt
xsLibXml2
-----------
LT_TLSv1_2
verssão 4.0 qrcod v2.00
se alguém esta emitindo em MS por favor me ajuda, obrigado.
segue anexo o xml gerado.
@DSilva o XML parece estar válido conforme a validação do SEFAZ-rs, a não ser pelo CNPJ, o qual não é do RS.
Por se tratar de NFCe e como a mensagem de erro que você reportou não tem muitos detalhes, revise os seguintes itens :
- schemas atualizados da v 4.0;
- DDLs atualizadas, isso costuma dar problemas com o TLS v1.2;
- verificar se windows do pc está com todas as atualizações em dia, incluindo a do protocolo TLS 1.2;
- se não me falhe a memória, para Win XP não ha atualização que instale o protocolo TLS 1.2 (logo não funciona para NFe 4.0);
-
1
-
-
46 minutos atrás, Antonino disse:
Olá, pra emitir uma NFe é necessário o número do token CSC ou não precisa?
Não, CSC somente é necessário para emissão da NFCe - Nota Fiscal de Consumidor Eletrônica modelo 65, que é diferente da NFe - Nota Fiscal Eletrônica modelo 55.
Citarse não precisar, como é feito o envio?
Veja o demo do ACBr em ...ACBr\trunk2\Exemplos\ACBrDFe\ACBrNFe
Citarse não precisar, como é feito o envio?
Configurando corretamente o componente, veja exemplo anterior;
CitarPorque um cliente não tem o número CSC e o contador dele falou que não é necessário pra emissão da NFe. Então como é feito o envio?
Veja respostas anteriores.
-
2
-
-
Em 02/10/2018 at 17:19, anderson.belino disse:
Boa tarde,
Estou com um cliente do para on de sempre que tento cancelar uma nota tenho o seguinte retorno
Não foi possível realizar o procedimento requisitado com a nota selecionada.
Erro: Evento inválido. Erro: URL para o serviço "NfeInutilizacao" não encontrada na sessão "NFCe_SVRS_P" no arquivo "ACBrNFeServicos"já verifiquei dentro do arquivos.res e existe o url para NfeInutilizacao4.00 conforme a baixo
NfeInutilizacao_4.00=https://nfce.svrs.rs.gov.br/ws/nfeinutilizacao/nfeinutilizacao4.asmx
alguém já passou por isso ou pode me dar um help;.
@anderson.belino ao que me consta a inutilização é diferente de cancelamento.
Inutilização é quando um número ou faixa de números da nota não foi utilizado.
Antigamente era comum os contadores "pularem" alguns números de notas nos blocos no final de cada fechamento contábil, para que se precisassem fazer notas de ajustes ou alguma outra elas seguissem na mesma sequencia de números do mês em questão ai quando não precisavam mais destas notas elas era inutilizadas no bloco mesmo, creio que foi por isso que a inutilização foi criada. Para a nossa realidade pode ser que por um problema técnico o sistema não seguiu a sequencia de numeração e assim é necessário fazer a inutilização destes números.
Cancelamento a partir da 2013 é um evento, e deve ser enviado par o WS como tal através da função ACBrNFe1.EnviarEvento com tpEvento := teCancelamento.
logo os Serviços são diferentes
Reveja seu processo, qualquer dúvida há o demo do ACBr para consulta.
-
1
-
-
Em 28/09/2018 at 10:19, mzsistemas disse:
Bom dia,
Quando tento executar o exemplo do NFCe, está dando um erro de Access Violation. Já coloquei as DLLs juntamente ao executável, porém, não executa, não consigo saber o que é. Na máquina do desenvolvimento executa normalmente, porém, quando coloco em outro computador ocorre este erro. Em anexo tem a imagem do erro. Alguém sabe dizer o que pode ser?
Veja se não há DLLs desatualizadas nas pastas do windows.
Certifique-se que estas DLLs estejam em apenas um local.
- Se win 32 em "C:\Windows\System32" OU na pasta do exe.
- se win 64 em "C:\Windows\SysWOW64" OU na pasta do exe.
-
2
-
Em 28/08/2018 at 09:56, thiagosantanna10 disse:
Ok já atualizei, fiz novamente o teste e deu o mesmo erro.
Falha na validação dos dados da nota: 11016
1824 - Element '{http://www.portalfiscal.inf.br/nfe}qrCode': 'http://nfcehomolog.sefaz.pe.gov.br/nfce-web/consultarNFCe?p=26180808118879000182650010000110169000110163|2|2|27|3.00|7854477A5650354B36666571466B544D30363346335444593637343D|1|2320983BDE6E255E94602AB07B3A3E15412AC14B' is not a valid value of the local atomic type.
Vou debugar por aqui, e também estou esperando a resposta da SEFAZ-PE que pegou os XMLs para averiguar.
Obg Pela força @BigWings@thiagosantanna10 conseguiu resolver ?
Tive agora pouco o mesmo problema, e estava aqui neste tópico buscando a solução, e eis que na tentativa consegui resolver:
Certificar que o schema seja o último, configurar NFe versão 4.0 e qrcode 2.0
Solução : atualizar as dlls libXML (trunk2\DLLs\XMLSec)
No meu caso funcionou 100%;
-
1
-
3
-
-
@Alessandra.imofficer esse assunto foi bastante recorrente esta semana no fórum, tem bastante postagens sobre o assunto, mas vamos lá.
A partir de 03/09/2018 torna-se obrigatório a informações de todos os campos de fatura (nFat, vOrig, vDesc e vLiq).
Certifique-se que seu componente e seus schemas estejam atualizados.
Marque no componente conforme encontra-se neste tópico, ao qual você também comentou a mesma dificuldade.
-
10 horas atrás, Anderson Pagezine Zerovox disse:
Estou usando o ACBrNFeDANFeRL - mas os arquivos " .fr3" não surtem efeito na impressão. Aonde alterar as propriedades dos documentos, pois sai cortado. Aqui em laboratório esta normal, mas em 2 clientes apresenta a falha na impressão (corte a direita). O que pode ser? Já tentei uma série de coisas e não encontro a solução. Estou utilizando Aplicação própria via componente
Anderson, veja a configuração da impressora no componente do ACBrDanfeFr, pra mim sempre que saiu cortado foi pq a impressora não estava definida no componente.
CitarACBrDANFEFR1.Impressora := nomedaimpressora
-
1
-
1
-
-
@Sergio Tucano Clemente Da Silva Filho não entendi a necessidade de gerar uma outra nota para a contingência.
Eu faço da seguinte forma :
1 - geraNFce
2 - Transmite normal
3 - Retornou 100, processa devidas gravações e impressões
Senão:
4 - Trato contingência, mas somente se os retornos contiverem as seguintes mensagens :
Citar('não pôde ser estabelecida')
('endereço do servidor não pôde ser resolvido');
('nome do servidor não pode ser resolvido');
('Requisição não enviada');Pois como o colega Roberto falou, não tem como ter certeza onde ocorreu o problema de comunicação, e com estes retornos até hoje não tive problema.
Assim, altero o tipo de emissão, data hora de contingência e justificativa.
5 - Guardo xml para transmissão.
Mas tudo isso da mesma nota, pois só dou o número da nota na hora de emitir, não de gravar a venda no banco de dados.
-
16 horas atrás, Helton Sampaio disse:
Sim, minha duvida é em relação ao código de rejeição.
Atualmente pelo componente ACBrNFe geração do arquivo XML só ocorre se a inutilização(cStat ) retornar 102(Sucesso) ou 563 (Já existe pedido de Inutilização com a mesma faixa de inutilização).
Porém recebo o retorno 256 (Uma NF-e da faixa já está inutilizada na Base de dados da SEFAZ).
O componente não deveria gerar o arquivo ao receber o cstat 256 também?
As rejeições parecem sinônimos;
Retorno 563 - quando enviado pedido de utilização para uma faixa que já existe pedido de inutilização seria, a meu ver, semelhante à duplicidade com mesma chave na NFe.
Ex.: enviar duas vezes a inutilização para as faixas incial 50 final 52.
Retorno 256 - quando uma das notas da faixa informada já está inutilizada.
Seguindo o exemplo anterior : enviar a inutilização para as faixas incial 50 final 52, e posteriormente enviar para inicial 52 e final 55, note que o 52 ficou nas duas faixas.
Para consultar inutilização pode se usar os seguintes passo :
Citar1) Acesse o site da nota fiscal eletrônica: http://www.nfe.fazenda.gov.br/ e clique o link Consultar Inutilização, no tópico Serviços mais acessados,
2) Informe o CNPJ do Emitente, o Ano de Inutilização e o código de verificação para confirmar a numeração de nota inutilizada.
Mais info em :
http://tdn.totvs.com/pages/releaseview.action?pageId=192104220
-
-
1 hora atrás, juniobelmiro disse:
Desde que foram feitas as atualizações dos fontes para atender a NFe 4.00 estou tendo vários problemas com clientes de máquinas win 7.
Fiz o ajuste orientado no fórum "TACBrNFe.SSL.SSLType := LT_TLSv1_2" mas mesmo assim o problema continua.
Alguém tem alguma ideia ou dica que possa me ajudar?
Veja este tópico :
Creio que a solução apresentada pelo @Felipe E. Resende Mesquita seja o que você procura.
-
2
-
-
)
ERRO 12175 AO CONSULTAR MDFe
em ACBrMDFe
Postado
Pessoal, segue uma resposta aceitável para o que estava acontecendo, para todos que são atendidos pela SEFAZ-RS :
De qualquer forma, para NFe 4.0 pode ficar marcado somente TLS 1.2.