dantemartins

ACBrNFSeXWebservicesResponse.pas ISSSaoPaulo.Provider.pas

a url do WS de Jaguarão/RS está com um erro, que a cada atualização tenho que corrigir, está com "https://https://", tem que remover um. Abaixo o bloco corrigido: [4311007] Nome=Jaguarao UF=RS Provedor=Pronim ProRecepcionar=https://sistemas.jaguarao.rs.gov.br/NFSe.Api/NotaNacional

As alterações que fiz são as seguintes conf. arquivos patch anexos. ACBrNFSeXWebservicesResponse.patch ISSSaoPaulo.Provider.patch

Entendi que nossos casos são distintos, mas acho estranho ninguém se manifestar, parece que ninguém usa o componente com esse município ou se usa, já resolveu e "dane-se os outros" (rs). Tento no Dsicord também, mas sem retorno. Sei que tem consultoria paga, e se eu quiser atenção deveria assinar o serviço, mas tento dentro de minhas possibilidades contribuir com o projeto.

No meu caso nem recebo retorno, nosso sistema é para Recintos Aduaneiros, a prestação se serviços é de Armazenagem e movimentação de carga (11.04.01 e 1.04.02). Está tendo suporte da prefeitura?

A única thread sobre Barueri que encontrei foi essa. Tentei enviar um RPS em homologação e recebi o protocolo do envio, faço a consulta do protocolo e recebo mensagem que não foi possível encontrar dados com os parâmetros utilizados. A implementação pra reforma tributária já está completa para Barueri?

Como ocorreu um caso e o arquivo de retorno não foi salvo, me leva a conclusão que o erro do e-mail veio na lista de erros mesmo, pois o salvamento de retorno só ocorre quando passa com Erros.Count = 0, ao menos com o ISSSaoPaulo. Deixei configurado para salvar os arquivos do WS, os soup, para caso ocorra novamente. Após o tratamento do retorno nessa situação a propriedade Sucesso vem como true, mas no final do Emitir muda pra false por conta do erro. Tenho a impressão que lá do lado do ISSSaoPaulo é que está enviando um alerta como erro e quebra o processo, mas como fazer eles corrigirem isso?

Situação do Cliente, onde manda 20 RPS por lote (aceita até 50), um RPS estava com um e-mail inválido, gerou na resposta uma mensagem de erro, a análise de erro é "Response.Sucesso := (Response.Erros.Count = 0);", invalidando todo o lote. As mensagens de erro retornam com a identificação do RPS com erro, mas o componente TNFSeEventoCollectionItem não tem campo para isso. Incluindo será possível verificar no tratamento rps a rps qual está com erro/alerta e atualizar todo o lote, ficando apenas o rps com problema pendente de reenvio. Como comentei, um cadastro de Cliente estava com um e-mail inválido gerando um erro de que não seria enviado o e-mail, mas a nota foi gerada. 100% do lote gerou NF, mas por conta do erro no e-mail todo o processamento foi cancelado. Até agora não vi outro Provedor que trate dessa forma, eu posso alterar o componente para sanar o problema, e esse novo campo não irá afetar o processo de ninguém, espero que aceitem o código. O grande problema é o valor que vem em "NFSe.WebService.Emite.Sucesso", pois sempre é validado "Erros.Count = 0". São Paulo é um município que deve ter muita gente usando o ACBr, acho pouco provável que nunca ninguém passou por esse problema. Posso estar falando besteira, pois não consigo debugar já que não tem ambiente de homologação, alguém pode ajudar?

Fiz os ajustes para o correto tratamento armazenando o retorno na coleção Resumos como em outros provedores. Essa é uma alteração válida? Como posso passar meu código para análise e possível aprovação?

Cliente situado no município supracitado me procurou informando que a prefeitura não vai mudar para o novo padrão da Pronim, a prefeitura informou que continuará usando o padrão ABRASF 2.02. Até consegui configurar o componente pra gerar nesse padrão, só que o código do 2.02 já está gerando tags como CodigoNbs, onde os schemas 2.02 da Pronim não aceitam. Não encontrei no site da prefeitura qualquer material explicativo de como usar seu serviço de emissão de NFS-e, só existe link para entrar no painel, só se lá dentro existam os materiais. Se alguém tem Cliente em Jaguarão e já está com isso resolvido dá um socorro. A prefeitura voltou a aceitar os rps no formato antigo por hora.

Atualmente estou usando apenas o componente ACBrNFSeX, antes usava apenas o ACBrNFSe, esse último está "marcado como deprecated", indicando utilizar o novo. No instalador quando seleciono o componente ACBrNFSe automaticamente todas as dependências são marcadas, mas se seleciono só o ACBrNFSeX somente ele fica marcado. Tentei instalar dessa forma, começou compilando synapse, comum, diversos... achei que era apenas bug visual e que iriam ser compiladas todas as dependências, mas não... Faltou o OpenSSL, marquei ele e repeti a instalação, faltou o DFeComum, esse quando marquei, marcou o Integrador e o TCP também, aí sim instalou o ACBrNFSeX. É um "defeito" pouco percebido, pois imagino que a maioria instala a suite toda, mas mapeei as dependências para instalar apenas o NFS-e novo, se alguém tiver o interesse de ver como corrigir o instalador vai poupar tempo de algum novato.

Após uma nova atualização percebi que para São José dos Pinhais já foi corrigido, mas para Dionísio Cerqueira/SC continua como Betha, segue como estou utilizando para esse caso: [4205001] Nome=Dionisio Cerqueira UF=SC Provedor=PadraoNacional Versao=1.01

Já faz algum tempo que os municípios de São José dos Pinhais/PR e Dionisio Cerqueira/SC mudaram para PadraoNacional e toda vez que atualizo minha cópia dos fontes tenho que conferir e ambos ainda estão com valores anteriores, ISSSJP e Betha respectivamente. Imagino que outras cidades também mudaram e continuam sem atualização, mas essas são duas que tenho certeza que mudaram na prática mas não foram atualizadas no INI.

Utilizei o código disponibilizado pelo Wesley Lamb, mas tive que fazer adaptações. Uma delas é a ordem da tag pAliq, é alterado o método da PadraoNacional, isso corrige pra betha e quebra a PadraoNacional, criei uma validação baseado no provedor instanciado. A requisição estava sempre gerando para homologação, corrigi para pegar o ambiente correto. No mais parece ter funcionado, a nota foi processada com erro, algo com código de serviço, apesar de estar enviando corretamente o sistema está recusando, a prefeitura (Dionisio Cerqueira/SC) abriu chamado na Betha.

Pior que tem gente lá no Discord informando que conseguiu... É para outro município, mas sendo Betha tem que funcionar para todos.

Em Betha,GravarXml.pas tem isso: procedure TNFSeW_BethaAPIPropria.Configuracao; begin inherited Configuracao; //PrefixoPadrao := 'dps'; end; E em Betha.Provider.pas tem: function TACBrNFSeXWebserviceBethaAPIPropria.GerarNFSe(const ACabecalho, AMSG: string): string; var Request: string; begin FPMsgOrig := AMSG; Request := RemoverDeclaracaoXML(AMSG); Request := RetornarConteudoEntre(Request, '<DPS xmlns="http://www.sped.fazenda.gov.br/nfse" versao="1.01">', '</DPS>', False); // '<dps:DPS xmlns:dps="http://www.sped.fazenda.gov.br/nfse" versao="1.01">', // '</dps:DPS>', False); // Request := '<dps:RecepcionarDpsEnvio>' + // '<dps:DPS versao="1.0">' + // Request + // '</dps:DPS>' + // '</dps:RecepcionarDpsEnvio>'; Request := '<RecepcionarDpsEnvio>' + '<DPS versao="1.0">' + Request + '</DPS>' + '</RecepcionarDpsEnvio>'; Result := Executar('http://www.betha.com.br/e-nota-dps-service/RecepcionarDps', Request, [], ['xmlns:dps="http://www.betha.com.br/e-nota-dps"']); end; Onde comentei o código que gerava as tags com "dps:", mas ainda assim, agora passou a retornar HTTP Code 404, se fosse 400 eu até entenderia. Na pagina da Betha a URL Base está como "https://nota-eletronica.betha.cloud/dps", mas no Service.ini está "https://nota-eletronica.betha.cloud:443/dps/ws". Sigo na investigação, pois o Cliente está a uma semana sem emitir notas.

Debugando consegui entender parcialmente como está funcionando para a Betha, mas tem um detalhe que possa ser a causa do que faz com que a Betha recuse o DPS, todas as tags estão com prefixo "dps:". <dps:tpAmb>2</dps:tpAmb> <dps:dhEmi>2026-01-09T15:24:51-03:00</dps:dhEmi> <dps:verAplic>v12.1</dps:verAplic> <dps:serie>00001</dps:serie> <dps:nDPS>6620</dps:nDPS> <dps:dCompet>2026-01-09</dps:dCompet> <dps:tpEmit>1</dps:tpEmit> <dps:cLocEmi>4205001</dps:cLocEmi> <dps:prest> <dps:CNPJ>XXXXXXXXXXXXXXXXXX</dps:CNPJ> <dps:regTrib> <dps:opSimpNac>1</dps:opSimpNac> <dps:regEspTrib>0</dps:regEspTrib> </dps:regTrib> </dps:prest> O retorna da requisição é a seguinte: <RecepcionarDpsResposta> <listaMensagens> <mensagem> <codigo>E001</codigo> <mensagem>cvc-complex-type.2.4.a: Foi detectado um conteúdo inválido começando com o elemento 'dps:indDest'. Era esperado um dos '{"http://www.betha.com.br/e-nota-dps":tpOper, "http://www.betha.com.br/e-nota-dps":tpEnteGov, "http://www.betha.com.br/e-nota-dps":xTpEnteGov, "http://www.betha.com.br/e-nota-dps":indPessoas}'.</mensagem> <correcao>Verifique a estrutura do XML</correcao> </mensagem> </listaMensagens> </RecepcionarDpsResposta>

Posso estar enganado, mas acho que no ACBrNFSeX não está implementado os métodos próprios deles, não são os mesmos que o PN. Acredito que, o que tem codificado é o layout próprio antigo e um ABRASF 2.02, eu ainda não descobri se tem alguém emitindo com a Betha no novo layout deles.

Eu ia comentar que estou enviando via PN para Santana do Livramento/RS, alterei o INI.

É, não sou eu que fiz algo errado, pois o proprio App de exemplo recebe o mesmo retorno. Erro(s): Código : 1002 Mensagem: Versão do Schema XML Incorreto. A versão 2 (campos do IBS/CBS) somente é aceita pelo endereço específico; consulte o endereço no manual de WebService.

Tentando usar o componente ACBrNFSeX para validar um RPS já na versão 2.0, entendi a parte de descomentar as linhas do .ini, recompilar o .res e reinstalar os componentes. Consegui passar pela validação via schema o próprio componente, mas ao enviar sempre retorna erro de versão do XML. Estou usando o método Enviar com o modo meTeste, nessa situação o retorno é: 1002 Versão do Schema XML Incorreto. A versão 2 (campos do IBS/CBS) somente é aceita pelo endereço específico; consulte o endereço no manual de WebService.

Pra mim aqui, mesmo usando a imagem acbrmono.bmp que vem no demo dá a mensagem de que não é um bmp monocrmatico e não manda a impressão. Gostaria de imprimir uma imagem que está em um componente FMX.Graphics.TImage na propriedade Bitmap (TBitmap), com fundo branco e texto preto.

Obrigado pelo retorno Antonio, não é meu caso, precisava usar num projeto FMX mesmo.

Olá Nelson, você tratou a imagem ou adaptou o método que verfíca se a imagem é monocromática ? Qual a solução para não cair na excessão "Imagem não é BMP Monocromática" ?

Não sei se fiz algo errado mas o ACBrBoleto é só para VCL correto ? Alguém já tentou portar pra usar em projetos FMX ? Se sim teve dificuldades ? Por hora percebi que TObjectList e TPicture precisam ser substituídos, isso apenas para compilar usando o componente no projeto, nem to falando as funcionalidades.