Italo Giurizzato Junior

Bom dia, Esta errado essa configuração. Você leu o tópico que eu lhe recomendei? Você esta usando os Schemas da pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\Schemas\SilTecnologia Sendo que o correto é usar os Schemas da pasta: ...\Exemplos\ACBrDFe\Schemas\NFSe E marcar a opção para que o componente monte automaticamente o Path dos Schemas.

Bom dia Filippe, A mensagem de erro significa que o componente esta tentando converter uma string em um numero inteiro e não esta conseguindo, pelo simples fato de que essa string contem caracteres diferentes de dígitos. Se faz necessário debugar para saber a linha exata que ocorre o erro. Pode ser uma informação errada que você passou para o componente ou até mesmo o componente esteja errado.

Bom dia Daniel, Esse problema começou do nada? Se sim, pode ser problema no provedor.

Bom dia Osmar, Se o problema começou do dana, pode ser um problema no provedor.

Bom dia Diego, Esse teste você fez com o programa exemplo ou com a sua aplicação? Se foi com a sua aplicação, verifica que na pasta que esta o EXE não consta o arquivo ACBrCTeServicos.ini, caso afirmativo delete ele.

Bom dia @PrimeSoftware, Já inclui na minha lista de tarefas para implementar o provedor Elmar. TK-5258

Bom dia @[email protected], A final de contas o seu problema é o cancelamento ou a consulta? Você criou o tópico relatando um problema com o cancelamento, agora você quer um exemplo de consulta? Como você usa o componente, junto aos fontes do ACBr temos uma pasta chamada Exemplos e nela você vai encontrar o programa exemplo do componente ACBrNFSe (já que é esse que você utiliza na sua aplicação). Basta você executar o Delphi, abrir o programa exemplo, compilar, configurar ele e fazer os testes. Configurando ele para salvar os arquivos Soap você tem o XML de exemplo seja de consulta ou de cancelamento ou de envio para você fazer os testes no Postman. Outra coisa, o programa exemplo tem um botão para exemplificar cada método seja ele de envio ou de consulta ou de cancelamento. É salvo no disco os XMLs de envio e de retorno, logo não se faz necessário você usar o Postman para analisar o retorno. Se você esta com todos os fontes atualizados, basta instalar os componentes usando o ACBrInstall depois fazer os testes com o programa exemplo do componente antigo (ACBrNFSe) e depois com o programa exemplo do componente novo (ACBrNFSeX). Desta forma você vai ver como é montado o XML de pedido de cancelamento no componente antigo e como é no novo.

Bom dia @johni, O componente ACBrNFSeX já esta preparado desde o dia 08/03/2024. Você esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou o ACBr? Se sim, recompilou a sua aplicação?

Bom dia @Eduardo Wendel, A chave do CT-e substituído que se encontra no CT-e substituto é: [infCteSub] chCte=33240309059609000100570010002514431002514431 indAlteraToma=1 O numero do CT-e substituído é 251443 e não 248723 Na chave temos essa informação em vermelho, veja: 33240309059609000100570010002514431002514431 Outra coisa importante, a chave do CT-e esta vulnerável, você esta atribuindo o numero do CT-e ao código do mesmo, veja como esta a chave: 33240309059609000100570010002514431002514431 Em vermelho temos o numero do CT-e com 9 dígitos e em azul temos o código do CT-e com 8 dígitos. O numero do CT-e tem que ser um numero sequencial, por outro lado o código do CT-e tem que ser um numero aleatório. E você esta deixando-os iguais, isso esta errado. Da forma que você esta fazendo um concorrente dessa transportadora vai precisar apenas descobrir qual é o digito verificador que é o ultimo digito da chave para ter acesso aos dados do CT-e, desta forma ele vai descobrir para quem essa transportadora transporta, ou seja, quem são os remetentes, os destinatários qual é o tomador de cada serviço e o valor cobrador, desta forma o concorrente poderá entrar em contato com essas empresas e oferecer um valor de prestação menor e acabar "roubando" essas empresas dessa transportadora. Acredito que não seja isso que você deseja, sendo assim altere isso o mais rápido possível.

Bom dia @shztec, Vou fechar este tópico pois me parece que o assunto principal dele foi sanado.

Bom dia @shztec, Qual a tag de ISS retido você se refere? Na versão 1 do layout da ABRASF temos as tags: IssRetido para informar se o ISS foi ou não retido, ValorIss onde informamos o valor do ISS e ValorIssRetido onde informamos o valor do ISS retido, por fim temos a tag ValorLiquidoNfse cujo valor é calculado segundo a formula: (ValorServicos - ValorPIS - ValorCOFINS - ValorINSS - ValorIR - ValorCSLL - OutrasRetençoes - ValorISSRetido - DescontoIncondicionado - DescontoCondicionado). Na versão 2 do layout da ABRASF temos as tags: IssRetido para informar se o ISS foi ou não retido e ValorIss onde informamos o valor do ISS. Não existe a tag ValorIssRetido e a tag ValorLiquidoNfse esta presente no layout da NFS-e e não do RPS. Como dito na minha postagem anterior a referida cidade se utiliza do provedor Infisc cujo webservice trabalha com a versão 2.01 do layout da ABRASF. Então as tags referente ao ISS são as que eu descrevi acima no que se refere a versão 2.

Bom dia @guga_galvao, O componente ACBrNFe não dispõe de nenhum método que carregue e extrai as informações das tags desse XML.

Boa tarde @[email protected], No tópico abaixo se refere a cidade de Jundiaí/SP que também é atendida pelo provedor Ginfes. Ao ler o tópico você vai notar que o desenvolvedor esta passando pelo mesmo problema que você esta passando, ou seja, ao consultar uma nota cancelada no XML da NFS-e retornado não consta nenhuma informação sobre o cancelamento e o componente acaba entendendo que a nota não esta cancelada. Eu estou notando que o provedor Ginfes esta promovendo diversas alterações em seus sistemas para atender o compartilhamento das notas com a Receita Federal e estão fazendo uma kaka atrás da outra. Tenha em mente o seguinte: O componente gera e envia o XML do RPS e os XMLs de pedido de consultas e de cancelamento. Os XMLs retornados são gerados pelo webservice do provedor, isso inclui o XML da NFS-e que é retornado pelas consultas solicitadas. O componente não tem culpa que o provedor ao gerar o XML da NFS-e gera sem as informações de cancelamento caso a nota esteja cancelada.

Boa tarde @[email protected], Configuracoes.WebServices.Salvar := True Isso faz com que o componente salve em disco os arquivos Soap tanto de envio quanto de retorno.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Bom dia @[email protected], Uma informação importante: Já faz alguns meses que o provedor Ginfes vem promovendo alteração no layout do pedido de cancelamento. Não sei lhe informar se essa alteração ocorreu para todas as cidades ao mesmo tempo ou se esta ocorrendo uma por uma. Mas a verdade é que o provedor alterou o layout do pedido de cancelamento e os ajustes necessários para atender essa mudança foi realizado somente no componente novo. Como já foi dito diversas vezes aqui no fórum, no Discord, em Papo Pro no Discord que todas as alterações, correções, melhorias, implementação de novos provedores estão sendo feitas somente no componente novo. Escrevi um tópico aqui no fórum (link abaixo) passando algumas informações que julgo importante em uma tomada de decisão no que se refere a troca do componente antigo pelo novo, vale a pena ler.

Olá Pessoal, Muitos desenvolvedores ainda utilizam o componente antigo (ACBrNFSe) para emitir as NFS-e e noto uma resistência em mudar para o novo (ACBrNFSeX). Resistência essa pelo desconhecido, pelo tempo, uma vez que já dissemos que muitas coisas mudaram do antigo para o novo. Ai vem a grande pergunta, devemos ou não migrar para o componente novo? A resposta é: Sim. Vou listar alguns motivos: 1. O código do novo componente ficou muito mais limpo, consequentemente a sua manutenção e correção se tornou muito mais fácil. 2. A implementação de novos provedores também ficou muito fácil. Por exemplo, se o provedor segue a versão 1 ou 2 da ABRASF é possível implementar em apenas 1 hora. Se ele tem um layout próprio em 1 ou 2 dias. 3. O componente novo atende todos os provedores do antigo e vários provedores novos. Ou seja, o componente novo é mais completo. 4. No componente novo foi utilizado novas units (rotinas) para a leitura e escrita do XML. Estas são mais rápidas em relação as utilizadas pelo componente antigo. Ou seja, o componente novo é mais rápido que o antigo. 5. O novo componente foi disponibilizado em 24/05/2021. Dessa data em diante não demos mais manutenção no antigo. Assim diversas correções e melhorias vem sendo aplicadas somente no componente novo. 6. Por fim, mas não menos importante a emissão da NFS-e Padrão Nacional que só existe no componente novo. Acredito ser conhecimento de todos que desde de 01/09/2023 o prestador de serviço que é MEI (Micro Empreendedor Individual) é obrigado a emitir as suas notas segundo o layout da NFS-e Padrão Nacional. Caso você desenvolvedor venha amanhã conquistar um cliente novo que é MEI, será obrigado a usar o componente novo, uma vez que o antigo não tem essa possibilidade. Temos cidades que já estão aderindo ao projeto da NFS-e Padrão Nacional. Essa adesão pode se dar de duas formas: 1. Aderir somente ao compartilhamento das notas com a Receita Federal. 2. Além de aderir o compartilhamento, aderir também a emissão da NFS-e segundo o Padrão Nacional. Como funciona a emissão da NFS-e nessas duas situações? Na primeira situação quando a prefeitura adere somente o compartilhamento, o prestador de serviço que não é MEI continua emitindo as suas notas através do provedor contratado pela prefeitura e esta por sua vez compartilha a nota com a Receita Federal. Na segunda situação quando a prefeitura adere o compartilhamento e a emissão, o prestador de serviço que não é MEI passa a emitir suas notas através da API da Receita Federal. Algumas cidades estão migrando por etapas como é o caso de Porto Alegre/RS que até o momento somente os prestadores que são Simples Nacional foram migrados, ou seja, devem emitir suas notas segundo o Padrão Nacional, os que não são Simples Nacional devem aguardar mais um pouco portanto devem continuar a emitir as suas notas pelo provedor contratado pela prefeitura. A Receita Federal esta conversando com todas as prefeituras, mostrando as vantagens delas de pelo menos aderir o compartilhamento. Uma das cidades que vai aderir o compartilhamento é Uberlândia/MG e que esta mudando de um provedor com layout próprio para outro que segue a versão 2 do layout da ABRASF, segundo funcionários da prefeitura com o layout da ABRASF fica muito mais fácil realizar o compartilhamento. Detalhe, esse novo provedor de Uberlândia/MG não existe no componente antigo. Depois de tudo que foi exposto acima, você vai continuar com o componente antigo? Não deixe para amanhã o que você deve fazer agora.

Boa tarde @m5sistemas, Em ambas as situações a configuração são as mesmas no que se refere ao: SSLLib, CryptLib, HttpLib, XmlSignLib e SSLType ?

@rogeraomg, Faça o seguinte teste: Abra a unit BHISS.Provedir e procure pela procedure PrepararEmitir. No final dela temos a montagem do XML de envio do serviço GerarNfseEnvio. Faça a alteração abaixo: '<InscricaoMunicipal>' + OnlyAlphaNum(Emitente.InscMun) + '</InscricaoMunicipal>' + Ou seja troque o OnlyNumber por OnlyAlphaNum. Salve a alteração, feche o Delphi, reinstale o ACBr e faça um novo teste.

Boa tarde @Ricardo Timm Bonsembiante, Esse erro não tem nada haver com o ACBrMonitor. Eu não sei qual é o comando que você executou, mas uma coisa é certa ao tratar o retorno era esperado que no retorno consta-se uma lista com uma ou mais notas, mas infelizmente não foi retornado. Exemplo: Você envia um RPS para o webservice, ao consultar surge esse erro, o que pode ter ocorrido? Simples, o RPS foi rejeitado, ele contem informações erradas logo ele não foi convertido em uma NFS-e e consequentemente a NFS-e não foi retornada dai o erro. Precisamos dos XML de envio e de retorno para analise, sem eles não tem como lhe dizer com absoluta certeza o que ocorreu.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Boa tarde @PrimeSoftware, Checando a unit EL.GravarXml temos: itemServico := FormatarItemServico(NFSe.Servico.ItemServico[i].CodLCServ, FormatoItemListaServico); Result[i].AppendChild(AddNode(tcStr, '#', 'CodigoServico116', 1, 5, 1, itemServico, '')); Result[i].AppendChild(AddNode(tcStr, '#', 'CodigoServicoMunicipal', 1, 20, 1, NFSe.Servico.ItemServico[i].CodServ, '')); Observe que o conteúdo do campo: CodLCServ passa por um processo de formatação, mas o campo: CodServ não passa, logo o que for informado nesse campo vai constar no XML. Na imagem que você anexou, foi destacado a tag CodigoServicoMunicial com a informação 407 e pelo o que eu entendi o correto seria 4.07, sendo assim, basta atribuir o "4.07" ao campo CodServ.

Boa tarde @PrimeSoftware, Pelo que descobri esse provedor diz que usa a versão 2.02 do layout da ABRASF. Segundo o manual deixa claro que você deve gerar o XML de envio de lote, renomear o XML com o CNPJ do prestador, ou seja, 12345678000123.xml (por exemplo), depois entrar no portal e importar o arquivo XML. Favor verificar se é isso mesmo.

Boa tarde Osmar, Se a ultima atualização ocorreu em outubro de 2023, os teus fontes estão muito mas muito desatualizados. Se tratando de NFS-e, é aconselhável no mínimo atualizar uma vez por semana.