Diego Foliene

Olá pessoal! No dia 20/12/2023 foi divulgada a Nota Técnica 2023/005 que institui o evento de Insucesso da Entrega para NF-e (não confundir com o Insucesso na entrega para o CT-e que é descrito AQUI) Resumo da Nota Técnica. Esta nota técnica discorre sobre os eventos de Insucesso de Entrega da NF-e(tpEvento=110192) e Cancelamento do Insucesso na Entrega da NF-e(tpEvento=110193), ambos acobertados pelo Ajuste SINIEF 58/2022 de 09 de dezembro de 2022. A implementação dos novos eventos permitem ao emissor da NF-e, quando a entrega da mercadoria não envolver um CT-e, registrar por meio de um evento fiscal na respectiva NF-e os motivos que impediram a entrega. O objetivo dessa implementação é substituir a ressalva que atualmente é aposta no verso do DANFe seguindo o § 3º da cláusula décima do Ajuste SINIEF 07/05 que obriga o emitente do documento fiscal a armazenar o DANFe impresso contendo no verso justificativa Insucesso da Entrega. Com a criação desses eventos, o emissor vai poder vincular o evento eletronicamente na NF-e e não mais precisará armazenar o DANFe em papel. Datas para Implantação. Implantação para Homologação: 13/05/2024. Implantação para Produção: 24/06/2024. Webservice de Evento e Obrigatoriedade. Assim como os demais eventos já existentes, os novos eventos de Insucesso na Entrega e Cancelamento do Insucesso na Entrega serão recepcionados pelo Ambiente Nacional e não pela Sefaz respectiva do estado. A implementação desta NT é facultativa, portanto, os interessados podem praticar os prazos que julgarem conveniente posterior as datas de implantação descritas nos respectivos ambientes. Evento "Insucesso na Entrega da NF-e". Função: Evento para indicar o insucesso na entrega da carga pelo emitente da NF-e. Autor do Evento: O autor do evento é o emissor da NF-e. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor da NF-e. Modelo: Nota Fiscal eletrônica – NF-e (modelo 55) Código do Tipo de Evento: 110192 (Este evento exige NF-e autorizada) Leiaute Mensagem Entrada Os campos que valem destaque no leiaute da mensagem de entrada são: tpEvento: Código do evento, 110192 - "Insucesso na Entrega da NF-e". nSeqEvento: Sequencial do evento para o mesmo tipo de evento, pode ter valores entre 1 a 99. Para informar um novo evento de "Insucesso na Entrega da NF-e" para uma mesma NF-e, o evento anterior deverá estar cancelado. dhTentativaEntrega: Data e hora da tentativa de entrega. nTentativa: Número da tentativa de entrega que não teve sucesso. tpMotivo: Motivo do Insucesso. Pode ter os valores 1 - Recebedor não encontrado, 2 - Recusa do recebedor, 3 - Endereço inexistente ou 4 - Outros. xJustMotivo: Justificativa do motivo do insucesso, usar somente se tpMotivo = 4. latGPS: Latitudade do ponto de entrega.. longGPS: Longitude do ponto de entrega. hashTentativaEntrega: Hash SHA-1, no formato Base64 correspondente a concatenação da chave de acesso da NF-e + Base64 de imagem capturada na tentativa da entrega. dhHashTentativaEntrega: Data e hora da geração do hash da tentativa de entrega. Leiaute da mensagem de retorno Os campos que valem destaque no leiaute da mensagem de retorno são: dhRegEvento: Data e hora de registro do evento. nProt: Número do protocolo do evento. Evento "Cancelamento Insucesso na Entrega da NF-e". Função: Evento para indicar o cancelamento do evento de insucesso na entrega da carga pelo emitente da NF-e. Autor do Evento: O autor do evento é o emissor da NF-e. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor da NF-e. Modelo: Nota Fiscal eletrônica – NF-e (modelo 55) Código do Tipo de Evento: 110193 (Este evento exige NF-e autorizada) Leiaute da mensagem de entrada Dentre os campos que vale destaque temos: nProtEvento: número do protocolo de autorização do evento de insucesso que será cancelado. Leiaute da mensagem de retorno dhRegEvento: Data e hora de registro do evento. nProt: Número do protocolo do evento. LEIA A NOTA TÉCNICA NA INTEGRA AQUI E como fica o ACBr? Como é possível observar, a nova NT trás adição de dois novos eventos. Dito isso modificações serão necessárias nos fontes do ACBr para implementação dos mesmos. Já foi criada uma TK em nosso backlog e as modificações estarão disponíveis em tempo hábil para que possam realizar a implementação.

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-4897

Por favor, disponibilizem o arquivo alterado com as informações do provedor IPM para análise.

Boa tarde! Obrigado por reportar, foi criada a #TK-4894 para análise do caso e parecer do consultor responsável.

Se o certificado é A1, faça um teste usando as configurações de OpenSSL. Neste tópico tem elas explicadas. Também é importante verificar se está usando o certificado do prestador de serviços e se não precisa solicitar acesso ao ambiente de homologação para o provedor.

Boa tarde! Contribuição enviada ao SVN na Rev-31679. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Boa tarde! Contribuição enviada ao SVN na Rev-31678. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Olá pessoal! Como é possível observar em URL por UF utilizada QR-Code NFCe, a URL para geração de QR-Code na NFC-e para o estado do Rio de Janeiro foi atualizada hoje, dia 19/12/2023. Informamos que a alteração já foi disponibilizada em nosso SVN na Rev-31672, por isso, basta atualizar seus fontes e reinstalar o ACBr para que o componente passe a utilizar a nova URL. Para aqueles que utilizam Monitor e Lib, em breve uma nova compilação será disponibilizada englobando a alteração. Caso haja necessidade de atualização antes de nova compilação ser liberada, também é possível baixar o arquivo ACBrNFeServicos.ini deste LINK e fazer a substituição.

Boa tarde. Você precisa preencher no componente, as propriedades de autenticação utilizadas pelo provedor.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia! Por favor, atualize seus fontes e reinstale o ACBr. Conforme o @Alexandre de Paula informou, na Rev-31663 isso foi alterado.

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-4880

Bom dia! Esta e outras contribuições foram enviadas ao SVN. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Boa tarde! Criada a #TK-4876 para tratativa do caso e parece do consultor responsável.

Olá pessoal! Alguns provedores utilizam a mesma URL para o ambiente de homologação e o ambiente de produção, diferenciando os ambientes através de uma tag ou informação adicionada no arquivo para identificar o ambiente. No entanto, recebemos recentemente algumas contribuições indicando que o provedor Betha está atualizando as URLS em algumas cidades, passando a utilizar a mesma URL para ambos os ambientes, mas sem diferenciar no arquivo. Nosso amigo @Arimateia Jrnos chamou a atenção para a seguinte informação: Em suma, se a cidade utiliza o provedor Betha e trocou para a seguinte URL: https://nota-eletronica.betha.cloud/rps/ws você deve seguir os passos descritos em Ajuda > Módulo do Contribuinte > Ambiente de Homologação para "desligar" o ambiente de produção e "ligar" o ambiente de homologação.

Bom dia. Se você abrir a unit ACBr\trunk2\Fontes\ACBrDFe\ACBrNFSeX\Provedores\PadraoNacional.GravarXml.pas e procurar por regEspTrib, vai achar esta linha mostrando como é preenchido: Result.AppendChild(AddNode(tcStr, '#1', 'regEspTrib', 1, 1, 1, FpAOwner.RegimeEspecialTributacaoToStr(NFSe.RegimeEspecialTributacao), DSC_REGISSQN)); Então você abre a ACBr\trunk2\Fontes\ACBrDFe\ACBrNFSeX\Provedores\PadraoNacional.Provider.pas e procura por RegimeEspecialTributacaoToStr para ver quais são os valores válidos para conversão. function TACBrNFSeProviderPadraoNacional.RegimeEspecialTributacaoToStr( const t: TnfseRegimeEspecialTributacao): string; begin Result := EnumeradoToStr(t, ['0', '1', '2', '3', '4', '5', '6'], [retNenhum, retCooperativa, retEstimativa, retMicroempresaMunicipal, retNotarioRegistrador, retISSQNAutonomos, retSociedadeProfissionais]); end; No seu caso, você não está usando um valor válido, ele não está sendo convertido, está ficando em branco e por isso está causando erro na validação de schema.

Olá pessoal! Foi publicado orientação de como escriturar no SPED EFD Contribuições para aqueles que anteciparem a emissão da NFCom para antes de Julho/2024, antes da liberação de um novo programa validador:

Olá pessoal! Conferindo no painel Situação SVC, é possível observar que a Sefaz do Mato Grosso está com a contingência ativada desde às 04h45 do dia 16/12/2023, com previsão de permanecer ativa até o dia 18/12/2023 às 10h00. Para usar o ACBr em contingência durante este período, siga as orientações deste tópico:

Uma dúvida que não deveria existir. Olá pessoal. É inerente e instintivo para todos nós desenvolvedores, que ao integrar com alguma coisa nova, procuremos fazer todo o processo em homologação primeiro para só depois partir para produção. No entanto, a falta de padronização da Nota de Serviço pode acabar gerando certa confusão neste quesito, impondo um obstáculo para quem pretende começar uma homologação. Como funciona a homologação para Nota de Serviço? Podemos dividir a forma como funciona a homologação para as notas de serviço em 4 categorias: Provedores que possuem um ambiente de homologação diferente do ambiente de produção. A forma mais semelhante a outros documentos fiscais eletrônicos que todo desenvolvedor está acostumado, um ambiente de homologação e um ambiente de produção separados. E como eu sei quais são os provedores cuja homologação é dessa forma? Você pode observar no facilmente no arquivo INI os provedores que tem URLs diferentes para o ambiente de homologação e de produção. Veja um exemplo: [1100031] Nome=Cabixi UF=RO Provedor=Pronim Versao=2.03 ProRecepcionar=http://nfse.cabixi.ro.gov.br/nfse.portal.integracao/services.svc HomRecepcionar=http://nfse.cabixi.ro.gov.br/nfse.portal.integracao.teste/services.svc Provedores que utilizam a mesma URL para ambos os ambientes, mas que usam uma informação identificar o ambiente. Nesse caso, o arquivo é enviado para a mesma URL, mas no arquivo é acrescentado uma tag ou informação específica para dizer ao provedor que o arquivo está sendo enviado em homologação e não em produção. E como eu sei quais o provedores cuja homologação é dessa forma? No inicio do arquivo ACBrNFSeXServicos.ini tem uma instrução identificando quais são os provedores. Provedores que não possuem ambiente de homologação, mas disponibilizam um método para teste. Neste caso, é apenas disponibilizado um modo de envio específico, no qual o arquivo é enviado para o ambiente de produção mesmo, o arquivo passa pelas validações, devolve as rejeições caso haja algum erro e em caso de sucesso, a NFS-e não é gerada. E como eu sei quais os provedores cuja homologação é dessa forma? Os provedores que tem este método são identificados na aba "Teste" do programa exemplo do componente nativo. São eles ISSDSF, NFSeBrasil, Siat e ISSSaoPaulo. Provedores que usam a mesma URL e os ambientes são controlados via painel. Recebemos uma contribuição de membros da comunidade sobre o provedor Betha estar atualizando seus serviços de forma que a URL para os ambientes de homologação e de produção sejam a mesma e ao invés de enviar informação no XML identificando se o envio foi em produção ou em homologação, isso será controlado via painel. Para mais detalhes, veja o tópico Dica para quem emite NFSe para as cidades que usam o provedor Betha. E como eu sei quais os provedores cuja homologação é dessa forma? Por enquanto, temos apenas informação de o provedor Betha estar agindo desta forma, veja o tópico indicado acima para mais detalhes. Provedores que não possuem ambiente de homologação. Nesses casos, de fato não há outra maneira a não ser testar em produção mesmo. E como eu sei quais os provedores que não tem ambiente de homologação? Caso não haja informação de um ambiente de homologação disponível, será exibida a seguinte mensagem ao tentar emitir uma NFS-e em homologação. E o Padrão Nacional, como funciona? Como é possível observar no arquivo ACBrNFSeXServicos.ini, o Padrão Nacional se encaixa na categoria de provedores que possui ambiente de homologação separado do de produção. [PadraoNacional] ProRecepcionar=https://sefin.nfse.gov.br/sefinnacional ProConsultarDFe=https://adn.nfse.gov.br/contribuintes HomRecepcionar=https://sefin.producaorestrita.nfse.gov.br/SefinNacional HomConsultarDFe=https://adn.producaorestrita.nfse.gov.br/contribuintes No entanto, um detalhe importante é que para utilizar o ambiente, seja de produção ou de homologação, o prestador de serviços precisa ser um MEI ou a cidade precisa ter aderido completamente ao Padrão Nacional.

Boa tarde! Por favor, qual é a URL de produção?

Boa tarde! Contribuição enviada ao SVN na Rev-31605. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Boa tarde! Por favor, pode confirmar onde conseguiu está informação e executar os passos descritos neste tópico abaixo para realizar um teste com este link? Peço que faça este procedimento, pois obtive o seguinte resultado ao testar com o programa exemplo do componente nativo com a seguinte configuração que coincide com a que está no SVN. [3170701] ; Atualizado em 21/11/2023 Nome=Varginha UF=MG Provedor=Betha Versao=2.02 ProRecepcionar=http://e-gov.betha.com.br/e-nota-contribuinte-ws/nfseWS HomRecepcionar=http://e-gov.betha.com.br/e-nota-contribuinte-test-ws/nfseWS Como não tenho dados válidos, a rejeição era esperada, mas o fato de receber ela por si só, indica que está havendo a comunicação com o web service.

Boa tarde! Contribuição enviada ao SVN na Rev-31602. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.