andremuriae

Bom dia, Com o código atual da unit "iiBrasil.Provider", a operação de cancelamento para o município de Limeira/SP, está retornando o erro "EI34 - Token não gerado ou inválido", mesmo estando com token válido. Analisando a documentação do provedor disponível em https://limeira.iibrasil.com.br/dev/dev_dashboard.php#dev_ws_notafiscal$$ZDMxMTJkMGExZmQ3MjhhNDc1ODJmYmQ1OWI4NDA2NTZaRE14TVRKa01HRXhabVEzTWpoaE5EYzFPREptWW1RMU9XSTROREEyTlRZek5qRT0=$$li_361_3$$3 é possível observar que eles possuem uma regra de Regex necessária para a geração da integridade. Construi uma solução nessa unit com a implementação do método "PrepararCancelaNFSe" que manipula o arquivo XML de cancelamento a ser enviado para o provedor. Com essa ação a nota de cancelamento foi autorizada corretamente sem devolver o erro de integridade. Na ocasião fiz uma comparação da hash gerada com essa implementação x hash gerada pelo modelo em php disponibilizado pelo provedor e as duas ficaram idênticas. Encaminho o arquivo em anexo para apreciação dos moderadores. iiBrasil.Provider.pas

Exatamente @C4Dev. O problema é que paramos por ai ne... Não tem como nem testar um retorno. Pelo que entendi conseguiremos apenas em JAN/2026.

Obrigado @Italo Giurizzato Junior

Bom dia Italo. Esse foi exatamente o ponto que eu questionei ao IPM, por e-mail, por mais ou menos três vezes; o motivo deles estarem exigindo os dados de IBSCBS de fora do infDPS. Só consegui "aprovar" o xml parseado com eles quando preenchi essas tags corretamente e com os valores calculados. Tomei rejeições tanto de schema, por não ter as tags, quanto de regra de negócio por mandar vazia/zerada ou com valores incompatíveis com o contexto do DPS. Por esse motivo que abri essa thread aqui informando que o provedor estava exigindo dessa forma e que era necessário ajustar para adequar às regras deles. Após muita insistência eles me responderam, por e-mail, isso: "Sua solicitação (593610) foi atualizada. Para adicionar mais comentários, responda a este e-mail. Bom dia, A partir do ano que vem o mesmo será sim calculado de forma automática nas emissões, neste período ainda de testes e implementações as tags devem ser enviadas com valor para as validações. " Para mim não faz muito sentido, mas é uma regra interna deles, assim como aprovar o nosso xml com uma rejeição nesse período de testes. @Gandalf bom dia. Formato próprio. O preenchimento deve ser realizado preenchendo as propriedades do componente do acbr que já estão preparadas para isso, exceto para o ponto que estou conversando com o Ítalo que o provedor está exigindo de forma atípica.

Boa tarde Ítalo. Conferi novamente aqui e as tags que adicionei no ajuste foram: pRedutor, vBC, pIBSUF, pRedAliqUF, pAliqEfetUF, pIBSMun, pRedAliqMun, pAliqEfetMun, pCBS, pRedAliqCBS, pAliqEfetCBS, vTotNF, vIBSTot, pCredPresIBS, vCredPresIBS, vDifUF, vIBSUF, vDifMun, vIBSMun, pCredPresCBS, vCredPresCBS, vDifCBS e vCBS. Todas elas constam no último modelo RTC disponibilizado pela RFB em https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/rtc/anexovi-leiautesrn_rtc_ibscbs-v1-01-02.xlsx/view Após realiza esse ajuste e enviar um XML com os dados preenchidos, consegui chegar no ponto que o manual do IPM afirma ser o satisfatório para a implementação da reforma tributária: Sem esses ajustes ocorrem diversos erros alegando justamente a ausência dessas tags. Eu também achei contraditório o provedor pedir para enviar tags que, segundo o padrão da reforma, deveriam ser retornadas por eles preenchidas, contudo me parece ser uma regra do provedor para o envio, pelo menos nessa fase de testes.

Bom dia, No último código disponibilizado no Trunk2 a unit "IPM.GravarXml" não está gerando o grupamento <IBSCBS> dentro das tags nf, o que gera a seguinte rejeição ao tentar realizar um envio: "00337 - Ao preencher os tributos do IBS/CBS na tag /nfse/IBSCBS, as alíquotas também devem ser preenchidas na tag /nfse/nf/IBSCBS" Em contato com o provedor, fui informado que o XML de envio deve contemplar as tags <IBSCBS> nos dois locais, ou seja, temos que enviar tanto os dados de IBSCBS de dentro dos limites da DPS quanto os dados de IBSCBS de fora do limite da dps, com a base de cálculo e valores, como no exemplo abaixo: Realizei os ajustes na unit em questão e após isso consegui a validação do XML no padrão da reforma tributária: Disponibilizo em anexo a unit para apreciação e validação da possibilidade de incorporação no fonte oficial. IPM.GravarXml.pas

Claro. Segue em anexo ACBrNFSeXServicos.ini

Boa tarde, A URL de produção do município de Saquarema/RJ (3305505) não está comunicando. Fiz os testes alterando para http://saquarema.govbr.cloud/NFSe.Portal.Integracao/Services.svc, mantendo as outras configurações idênticas, no arquivo ACBrNFSeXServicos.ini e consegui realizar o envio e o cancelamento para o município corretamente. OBS.: A URL de homologação também não está acessando. Seria possível ajustar no arquivo do projeto?

Boa tarde Renato, Primeiramente obrigado pelo feedback e pela atenção. Não me parece que o problema seja a ausência de TAGS, entre as duas versões. É bem verdade que na versão dois foram geradas novas TAGS como a <soapenv:Header/>, mas não acredito que esse seja o causador do problema. O que verifiquei, entre as duas estruturas, é que o padrão do envelope SOAP está diferente, como por exemplo o prefixo nfse e sis em diversas TAGS, além da referência de explicitação de xmls em algumas. Estou encaminhando em anexo os prints com os comparativos realizados, entre os XML SOAP de envio, produzido com as duas versões (1 e 2) do componente. Lembrando que o XML a esquerda (versão 1 do componente) está sendo recebido pelo provedor/cidade em ambiente de homologação sem nenhum problema/rejeição. Desde já obrigado.

Boa tarde, Estou recebendo uma rejeição do provedor SimplISS, município de João Monlevade/MG, quando realizo o envio de uma NFS-e utilizando o novo componente do ACBRNFSe (ACBrNFSeX). Utilizando o mesmo XML de envio estou recebendo a seguinte rejeição: ">Arquivo enviado fora da estrutura do arquivo XML de entrada - campo(s) obrigatório(s) faltando ( EnviarLoteRpsEnvio )". O problema é que o envio com a primeira versão do ACBrNFSe(versão 1 antiga) o envio está ocorrendo normalmente. Comparei visualmente os dois arquivos de envio, com o soap, e observei diferenças estruturais entre o arquivo produzido entre as duas versões. OBS.: É importante mencionar que estou utilizando o ambiente de homologação do provedor em questão. Vou anexar os arquivos na seguinte estrutura: 8-env-lot-soap_ACBR01.xml = arquivo SOAP de envio produzido com ACBrNFSe versão 1; 8-rec-soap_ACBR01.xml = arquivo SOAP de retorno com ACBrNFSe versão 1; 9-env-lot-soap_ACBR02.xml = arquivo SOAP de envio produzido com ACBrNFSeX versão 2; 9-rec-soap_ACBR02.xml = arquivo SOAP de retorno com ACBrNFSeX versão 2. Sabem me dizer se há algum problema com a versão ACBrNFSe para o provedor/cidade? Conseguem me ajudar? 8-env-lot-soap_ACBR01.xml 8-rec-soap_ACBR01.xml 9-env-lot-soap_ACBR02.xml 9-rec-soap_ACBR02.xml