Italo Giurizzato Junior

Olá Pessoal, Boas novas, o componente ACBrNFe já esta pronto para gerar o QR-Code na versão 3.00 que é utilizado na NFC-e. Essa nova versão esta documentada na Nota Técnica 2025/001 que além da versão 3.00 do QR-Code também temos a resposta síncrona para lote com somente 1 (uma) nota. Com relação ao modo de envio síncrono já faz um bom tempo que o componente dispõe dessa funcionalidade, na verdade desde julho/2013. Lembrando que o envio em modo síncrono esta condicionado a somente uma nota por lote, ou seja, envio unitário. Vale também ressaltar que hoje podemos realizar um envio unitário em modo assíncrono, mas em breve não vai mais ser possível, somente no modo síncrono. Tanto a versão 3.00 do QR-Code quanto a obrigatoriedade do modo síncrono para o envio unitário de NF-e segue o seguinte cronograma: Ambiente de homologação 02/06/2025 e produção 01/09/2025. Mantenham os fontes do ACBr atualizados e reinstalados. Fiquem atentos aos Papos Pro que são realizados todas as terças e quintas no Discord.

@eraldocg, Com a versão 2.02 e com as URLs antigas você consegue emitir as notas? Através de um navegador eu não consegui abrir as URLs antigas, por outro a nova URL de homologação referente a versão 2.03 abre. No arquivo ACBrNFSeXServicos.ini temos o seguinte: [2507507] ; Atualizado em 04/05/2023 Nome=Joao Pessoa UF=PB Provedor=SisPMJP ;Versao=2.02 ;ProRecepcionar=https://sispmjp.joaopessoa.pb.gov.br:8443/sispmjp/NfseWSService ;HomRecepcionar=https://nfsehomolog.joaopessoa.pb.gov.br:8443/sispmjp/NfseWSService Versao=2.03 ProRecepcionar= HomRecepcionar=https://serem-hml.joaopessoa.pb.gov.br/notafiscal-abrasfv203-ws/NotaFiscalSoap

Olá Pessoal, Boas novas, temos mais um provedor implementado, ele trabalha com layout próprio e o seu nome é Smart4. No momento temos a informação que ele atende a cidade de Paulo Afonso/BA. Caso vocês saibam de mais cidades atendidas por esse provedor, por favor nos informe a cidade e a URL de produção. Algumas informações sobre o provedor: ------------------------------------ Informações sobre o provedor: Smart4 - Versão: 1.00 - Layout: Próprio Autenticação Não requer Certificado Digital Requer Login/Senha Não requer Chave de Acesso Não requer Chave de Autorizacao Não requer Frase Secreta Serviços Disponibilizados Não permite o envio de Lote em Modo Assíncrono Permite o envio de Lote em Modo Síncrono Não permite o envio Unitário em Modo Síncrono Não permite Consultar a Situação do Lote Permite Consultar o Lote Permite Consultar o Rps Não permite Consultar a NFS-e Não permite Consultar uma Faixa de NFS-e Não permite Consultar Serviço Prestado Não permite Consultar Serviço Tomado Permite Cancelar NFS-e Não permite Substituir NFS-e Não permite Gerar Token Não permite Enviar Evento Não permite Consultar Evento Não permite Consultar DF-e Não permite Consultar Parâmetros Não permite Consultar Sequencia de Rps Não permite Consultar Link da NFS-e Não permite Consultar NFS-e por Chave Particularidades Permite mais de um serviço Não permite o envio da tag OutrasInformacoes no Rps ------------------------------------

Boa tarde @Marcio Patyk, Não concordo com essa alteração, pois o dia que essa cidade deixar de utilizar esse provedor com certeza não vamos nos lembrar de remover essa condição do código do componente. No arquivo ACBrNFSeXServicos.ini temos: ; SubVersao é do tipo numerico e pode conter a sub versão do Envelope Soap utilizado por uma ; determinada cidade. (ex: SubVersao:1) Apesar do Params SubVersao foi criado inicialmente para contornar situações onde uma determinada cidade tem um Envelope Soap diferente das demais atendidas pelo mesmo provedor, não vejo problema em utilizar para a situação que você esta enfrentando com o provedor Thema.

Boa tarde @eraldocg, Temos informações de um outro desenvolvedor que a prefeitura mudou para a versão 2.03 Por favor entre em contato com a prefeitura para saber se realmente mudou de versão ou não.

Bom dia @lucasatz, Entendi. A correção da URL já esta no SVN.

Olá Pessoal, Foi publicado ontem (28/03/2025) Notas Técnicas especificas para cada modelo de Documento Fiscal Eletrônico referente a Reforma Tributária. Notas Técnicas publicadas para o BP-e, CT-e, NF3-e e NF-e/NFC-e, esta faltando a publicação da NT referente a NFCom. Em uma leitura rápida não ocorreu grandes alterações. Somente a NF-e/NFC-e que trazia um grupo referente a Compras Governamentais, este grupo agora esta presente nos demais DF-e. Outro ponto a se destacar é quanto aos prazos de liberação dos ambientes de homologação e produção. Ambiente de homologação que antes estava previsto para 01/09/2025 passou para 01/07/2025. E o ambiente de produção estava previsto para 31/10/225 passou para 01/10/2025. Com essa alteração de datas os desenvolvedores passaram a ter 3 meses em vez de 2 para adequar suas aplicações e fazerem os testes. No que se refere a NFS-e também foi publicado uma nova NT que traz algumas modificações no layout sendo que uma delas é a inclusão do grupo de Compras Governamentais. Infelizmente essa NT não traz datas de inicio do ambiente de homologação (produção restrita como eles chamam) e do ambiente de produção. A única informação que consta é que em janeiro/2026 as NFS-e devem já atender a reforma tributária, ou seja, já deve constar os novos grupos e campos. Com essas novas modificações nos layouts dos DF-e vamos ter que rever tudo o que foi feito e fazer as alterações necessárias. Pessoal, agora mais do que nunca devemos manter os fontes do ACBr atualizados e reinstalados se possível diariamente. Vamos fazer novos Papo Pro no Discord relatando as mudanças e em qual etapa estamos na adequação dos componentes. Não percam os Papo Pro eles são de extrema importância para que vocês fiquem informados.

Bom dia @lucasatz, A URL de homologação é a mesma de produção isso esta correto? Como o webservice sabe que você esta enviando em homologação ou produção?

Bom dia @lucasatz, Você chegou a testar com as URL que o manual sugere? Eu tentei abrir elas pelo navegador e não abre.

Boa tarde Sandro, Os dados populados no componente para gerar o XML, são os dados do RPS. A impressão do DANFSE é com base no XML da NFS-e que é retornado pelo webservice do provedor. Ao limpar o componente e carregar o XML da NFS-e, a rotina de leitura faz alguns tratamentos como por exemplo a quebra de linha. Isso foi feito para que esse tratamento não precisasse ser aplicado nos geradores de DANFSE escritos em Fortes Report, Fast Report e FPDF. Dai a importância de carregar o XML da NFS-e.

@Diego Reckziegel, Já esta no SVN.

Bom dia @lucasatz, Já esta no SVN.

Bom dia @Diego Reckziegel, Muito obrigado pela colaboração, já foi criado a TK-6819 para realizar a alteração.

Bom dia @joao vitor bogo, Já esta no SVN.

Boa tarde @joao vitor bogo, Já esta no SVN.

Boa tarde @João Antônio, Já esta no SVN.

Boa tarde @João Antônio, Já esta no SVN.

Boa tarde @Márcio Baroni, Muito obrigado pela colaboração, ainda hoje estarei enviando a correção para o SVN.

Boa tarde @joao vitor bogo, Muito obrigado pela colaboração, já foi criado a TK-6803 para realizar a alteração.

Bom dia @Marcelo Freework, Complementado os questionamentos do nosso amigo @Juliomar Marchetti. Você tentou emitir uma nota e ocorreu erro 500, conforme a primeira imagem. No XML do RPS mais precisamente na tag Discriminacao ou nome do Tomador ou endereço do mesmo, não tem caracteres de quebra de linha ou & (e comercial) ? Ao enviar o mesmo RPS pela segunda vez ocorreu a mensagem de erro conforme a segundo imagem, correto? Foi checado se a Inscrição Municipal do prestador esta correta, ou seja, não houve alteração?

Bom dia @Sandro Andre Reghelin, Fiz um teste com o XML da nota de numero 133 que você anexou, veja o resultado:

Olá pessoal, Informamos que propriedade dos componentes responsável por salvar o arquivo XML -procEventoNFe.xml em disco foi alterada! Entendendo melhor... Os componentes possuem algumas propriedade de configuração destinadas a determinar se os XMLs gerados devem ser salvos em disco ou não, são elas: Configuracoes.Arquivos.Salvar -> Determina se os XMLs dos Documentos Fiscais devem ser salvos (Por padrão o valor da propriedade é True). Configuracoes.Arquivos.SalvarEvento -> Determina se os XMLs de Processamento de Eventos devem ser salvos (Por padrão o valor da propriedade é False). Configuracoes.Geral.Salvar -> Determina se os XMLs auxiliares, ou seja, XML de envio e de retorno do webservice devem ser salvos (Por padrão o valor da propriedade é True). Configuracoes.WebServices.Salvar -> Determina se os XMLs auxiliares, ou seja, XML de envio e de retorno do webservice exatamente como são enviados e retornados sem nenhum tratamento devem ser salvos (Por padrão o valor da propriedade é False). Notem que existe uma propriedade de configuração especifica para eventos, sendo assim achamos por bem mudar a condição que determina se o XML de Processamento de Evento vai ser salvo em disco ou não. Antes era usado como condição a propriedade Configuracoes.Arquivos.Salvar e agora vai ser utilizada a propriedade Configuracoes.Arquivos.SalvarEvento. Como mostrado acima a propriedade SalvarEvento tem como valor padrão False, sendo assim se faz necessário alterar o seu valor via código ou no Object Inspector caso o desenvolvedor queira que o XML de Processamento do Evento seja salvo em disco. A motivação dessa mudança é utilizar a propriedade de configuração correta para a situação em questão que é determinar se o XML de Processamento do Evento deve ser salvo em disco ou não.

Boa noite @Sandro Andre Reghelin, Obrigado, vou usa-los para realizar os testes.

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.