Painel de líderes

@EMBarbosa, obrigado pelo Retorno. Aqui utilizamos Vb6. Essa DLL será de grande utilidade, além de ser mais um produto no portfólio ACBR.

Existe no ACBr, mas é um componente pra Delphi e Lazarus. Estamos terminando um refactoring nesse componente. Depois de terminar vamos implementar a DLL.

Olá pessoal, Para quem ainda não sabe estou promovendo um Refactoring no componente ACBrNFSe. Ele praticamente foi reescrito do zero e infelizmente teremos algumas quebras de código quando ele for liberado. Mas vamos falar de coisas boas. Hoje temos que disponibilizar para os nossos clientes além do executável, DLLs, os famosos arquivos INI, o arquivo Cidades.ini e os arquivos INI dos provedores. Pois bem, isso acabou. Os arquivos INI referente aos provedores se transformaram em Unit, ou seja, fazem parte do fonte do componente. O conteúdo do arquivo Cidades.ini migrou para o arquivo ACBrNFSeServicos.ini que é transformando no ACBrNFSeServicos.res através do BAT: Compila_RES. O arquivo ACBrNFSeServicos.res é incorporado ao executável, logo vocês só vão precisar distribuir o executável e as DLLs para os seus clientes. O que vocês acharam dessa mudança? Ainda não esta 100%, em função das diferenças dos provedores, mas criei um novo método chamado Emitir que tem por finalidade gerar o XML do RPS, assinar se necessário, gerar o Lote e assinar se necessário, enviar, aguardar o retorno do XML da NFSe. Independente do serviço que o provedor se utiliza para recepcionar o XML do RPS. Vou dar um exemplo: O provedor 4R que segue a versão 2 do layout da ABRASF implementou somente o método EnviarLoteRpsSincrono para recepcionar o RPS, sendo que no Manual da ABRASF versão 2 estão previstos os métodos: EnviarLoteRps, EnviarLoteRpsSincrono e GerarNfse. Por outro lado o provedor ISSJoinville que também segue a versão 2 do layout da ABRASF implementou somente o método EnviarLoteRps. Se vocês tem clientes cujas cidades utilizam o provedor 4R e tem clientes em Joinville, ou vocês tem duas aplicações ou a aplicação tem uma tela de configuração para definir qual método a ser utilizado. O método Emitir vem para tentar resolver esse problema da seguinte forma: se o provedor for 4R ele vai se utilizar do método EnviarLoteRpsSincrono automaticamente, agora se for ISSJoinville vai usar o EnviarLoteRps. Desta forma não precisamos de nos preocuparmos com qual o método devemos usar para enviar o RPS para o webservice. Acredito que vai ficar muito bom e pratico. O que vocês acham? Muita coisa já foi feita e muito mais precisa ser feito. Para que vocês tenham uma ideia foi criado 32 Units, ou seja, uma para cada provedor que segue a versão 1 do layout da ABRASF, mais 53 Units para os provedores que seguem a versão 2 do layout da ABRASF e mais 19 Units para os provedores que tem o seu próprio layout. Até o final deste mês de outubro estarei disponibilizando o programa exemplo compilado para que vocês possam fazer mais testes. Em breve vou explicar como vão ser os testes e como reportar os resultados. Antes que eu esqueça, esse Refactoring visa poder incluir a emissão da NFS-e no ACBrMonitor Plus e a criação do ACBrLibNFSe (DLL). Um forte abraço a todos.

Bom dia, segue alguns esclarecimentos: O que é CSC? O CSC corresponde a um código de segurança alfanumérico de conhecimento apenas da Secretaria da Fazenda do Estado do emitente e do próprio contribuinte. O processo de fornecimento de CSC é feito por meio de página web específica da Secretaria de Fazenda do Estado de cada Contribuinte Emissor; Por meio desta página o contribuinte deve poder solicitar novo CSC, consultar CSC válidos e revogar CSC. A critério da UF poderá o CSC ser fornecido também por Web Service, segundo especificações técnicas padronizadas nacionalmente. Pra que serve? O CSC é o código para a geração do hash contido na tag qrCode da NFC-e. Ele deve ser gerado em cada cada ambiente para emissão das notas em homologação e produção. Logo, CSC's gerados em produção não são válidos para NFC-e's enviadas para o ambiente de homologação, e vice-versa. Quais rejeições são validadas considerando o CSC? As rejeições que são validadas utilizando o CSC são: 462: Rejeição: Código Identificador do CSC no QR-Code não cadastrado na SEFAZ 463: Rejeição: Código Identificador do CSC no QR-Code foi revogado pela empresa 464: Rejeição: Código de Hash no QR-Code difere do calculado Como resolver: 462: Realize o cadastro do CSC para o ambiente de envio da NFC-e; 463: O CSC informado se encontra revogado, informe um CSC ativo ou gere um novo CSC para o ambiente de envio da NFC-e; 464: O hash gerado na tag qrCode (cHashQRCode) não é compatível com o hash calculado pela Sefaz. Após a concatenação de todos os valores (chNFe, nVersao, tpAmb, cDest (caso haja), dhEmi, vNF, vICMS, digVal, cIdToken e CSC ), gerar o SHA1 e informá-lo como valor do parâmetro cHashQRCode; Outras rejeições relacionadas à autorização de NFC-e - O que é validado e Como resolver em caso de rejeição: 394 - Rejeição: Endereço do site da UF da Consulta via QRCode diverge do previsto Tag qrCode: informe a tag qrCode da NFC-e 395 - Rejeição: Endereço do site da UF da Consulta via QRCode diverge do previsto Url de consulta para o qrCode: verifique a url informada para a consulta observando cada ambiente. 396 - Rejeição: Parâmetro do QR-Code inexistente Parâmetros de qrCode não informados: informe os parâmetros na tag qrCode. Obs.: O parâmetro cDest é obrigatório em caso de NFC-e com a tag 'dest'; 397 - Rejeição: Parâmetro do QR-Code divergente da Nota Fiscal Chave de acesso da NFC-e: verifique se a chave de acesso da NFC-e é a mesma informada na tag qrCode (chNFe) Tipo de Ambiente: verifique se o tipo de ambiente informado é na NFC-e é o mesmo informado na tag qrCode (tpAmb) Código do destinatário (não obrigatório): verifique se o código do destinatário informado é na NFC-e é o mesmo informado na tag qrCode (cDest) Data de emissão (hexadecimal): verifique se a data de emissão informada na NFC-e é a mesma informada na tag qrCode (dhEmi) Valor Total NFC-e: verifique se o valor total informada na NFC-e é o mesmo informada na tag qrCode (vNF) Valor Total ICMS: verifique se o valor total do ICMS informada na NFC-e é o mesmo informada na tag qrCode (vICMS) Digest Value: verifique se digest value informado na NFC-e é o mesmo informada na tag qrCode (digVal) 398 - Rejeição Parâmetro nVersao do QR-Code difere do previsto Número da versão diferente do previsto: informe a versão correta (100) 399 - Rejeição: Parâmetro de Identificação do destinatário no QR-Code para Nota Fiscal sem identificação do destinatário NFC-e com identificação do destinatário (dest) sem a informação do parâmetro do qrCode (cDest): informe o valor do cDest para a tag qrCode Erros comuns na autorização de NFC-e: 395: URL de consulta diferente da definida pela Sefaz. verifique os links de consulta abaixo; 397: um dos parâmetros dos qrCode são inválidos. Geralmente este erro é causado por erro na geração dos dados em hexadecimais; 462: CSC informado na tag qrCode não se trada do CSC gerado para o ambiente de envio da NFC-e. Acontece geralmente quando foi informado um CSC para o ambiente de produção e está tentando autorizar a NFC-e em ambiente de homologação, mesmo que tenha o mesmo cIdToken. Outra possibilidade é informar na tag qrCode (cIdToken) inexistente para o ambiente; 464: O código hash informado na tag qrCode (cHashQRCode) não é válido. Este hash deve ser gerado conforme especificação definida no Manual de Padrões Padrões Técnicos do DANFE-NFC-e e QR Code, observando a concatenação dos campos + o CSC, para posteriormente ser gerado o SHA1 da string. Links Úteis: Serviços de Administração de CSC (homologação/produção) https://homolog.sefaz.go.gov.br/nfe/services/v2/CscNFCe?wsdl https://nfe.sefaz.go.gov.br/nfe/services/v2/CscNFCe?wsdl Geração de CSC (homologação/produção) https://homolog.sefaz.go.gov.br/nfeweb/jsp/SolicitarCertificadoCSC.jsf https://nfe.sefaz.go.gov.br/nfeweb/jsp/SolicitarCertificadoCSC.jsf Consulta NFC-e http://homolog.sefaz.go.gov.br/nfeweb/jsp/ConsultaDANFENFCe.jsf http://nfe.sefaz.go.gov.br/nfeweb/jsp/ConsultaDANFENFCe.jsf Validação de SHA / HEXA http://www.nfe.se.gov.br/portal/portalNoticias.jsp?jsp=barra-menu/servicos/validadorSHA1HEXA.htm Normas Técnicas https://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=tW+YMyk/50s=

Prezados colegas, tivemos algumas reclamações referente ao ambiente de homologação com o comportamento instável para a autorização de nfes e nfces. Hora retornava alguma rejeição, hora retornava outra, e hora autorizada a nota para o mesmo xml, comportamento este que não é aceitável para os serviços de alta confiabilidade como os serviços providos pela Sefaz. Preparamos uma nova versão do sistema e será disponibilizado hoje no período vespertino que deve sanar esta instabilidade. Sobre a dificuldade de autorização de NFCes, analisarei todos os casos pontualmente caso ainda estejam com problemas, vamos rastrear todas as requisições que eventualmente receber a rej 397. Agradeço pela atenção e peço desculpa pelo transtorno em nome da SEFAZ, mesmo o ambiente de homologação sendo propício a este tipo de comportamento.