C4Dev

Olá @Italo Giurizzato Junior O RPS esta enviando com 4 casas decimais o campo alíquota: Percebi que aqui na unit ACBrNFSeXGravarXml ele envia sempre com 4 casas: FFormatoAliq := tcDe4; if FpAOwner.ConfigGeral.Params.TemParametro('Aliquota2Casas') then FFormatoAliq := tcDe2; FDivAliq100 := False; Esse parâmetro como ele deveria ser informado? Fiz o teste em debug enviando com duas casas, e enviou corretamente. No aguardo.

@Italo Giurizzato Junior Conegui realizar o envio ao WS, porém o único prolema que vejo é que ele aceita somente 2 casas decimais, e o Acbr esta enviandpo 4.

Bom dia Pessoal. Alguma atualização sobre este provedor, porque não estou conseguindo emitir para castanhal. O retorno na lista esta chegando vazio. <?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body></soap:Body></soap:Envelope> No aguardo.

Funcionou @Italo Giurizzato Junior. Obrigado.

Bom dia @Diego Foliene. Algum retorno sobre esse caso?

Bom dia, tudo bem? Tem alguma novidade quanto esse caso?

Bom dia. Nós estamos usando a v2. O que eu percebi, é que o código de retorno esta fora do esperado pelo Acbr. No caso a verificação que existe é esta, para uma eventual exceção : if HTTPResultCode >= 300 then Porém existe casos que o HTTPResultCode vai ser menor que 300, que é nessa situação que estamos. O BANCOOB esta retornando como 207 Creio que não podemos fazer essa verificação direta para o status >= 300, porque por mais que a faixa de retorno 200-300 seja de resposta bem sucedida, podemos ter retorno de rejeição em meio a isso, como o 207 ou outros. Verificando aqui as alterações feitas no Acbr, encontrei a do dia 21/06, que foi justamente alterado isso. O tópico relacionando foi este: Att; Maiquel.

Boa tarde; Estamos com problema na lista de retorno dos boletos sicoob. Não sei se teve alguma alteração por parte do Acbr ou da Sicoob, mas agora com o componente atualizado, não esta mais retornando a lista de Rejeição; ARetornoWS.JSON:=ACBrBoleto.ListaRetornoWeb[i].JSON; ARetornoWS.Rejeicao.Campo:=ACBrBoleto.ListaRetornoWeb[i].ListaRejeicao[0].Campo; ARetornoWS.Rejeicao.Codigo:=ACBrBoleto.ListaRetornoWeb[i].ListaRejeicao[0].Codigo; ARetornoWS.Rejeicao.Versao:=ACBrBoleto.ListaRetornoWeb[i].ListaRejeicao[0].Versao; ARetornoWS.Rejeicao.Mensagem:=ACBrBoleto.ListaRetornoWeb[i].ListaRejeicao[0].Mensagem; ARetornoWS.Rejeicao.Ocorrencia:=ACBrBoleto.ListaRetornoWeb[i].ListaRejeicao[0].Ocorrencia; ARetornoWS.Rejeicao.Valor:=ACBrBoleto.ListaRetornoWeb[i].ListaRejeicao[0].Valor; Estes valores estão retornando todos vazios e o erro em questão que vem no Json não é mais apresentado. Json de resposta abaixo. Vejaque o erro vem dentro da tag status. { "resultado":[ { "status":{ "codigo":400, "mensagem":"Já existe boleto cadastrado com número 49-8 para o beneficiário." }, "boleto":{ "numeroContrato":999950, "modalidade":1, "numeroContaCorrente":259841, "nossoNumero":888, "seuNumero":"122226A", "especieDocumento":"DM", "dataEmissao":"2024-07-02T00:00:00-03:00", "valor":5.5, "dataVencimento":"2024-08-01T00:00:00-03:00", "dataLimitePagamento":"2024-08-11T00:00:00-03:00", "tipoDesconto":0, "valorMulta":0, "valorJurosMora":0, "numeroParcela":1, "aceite":true, "pagador":{ "nome":"teste", "numeroCpfCnpj":"03888888000400", "endereco":"teste 80", "bairro":"Centro", "cidade":"teste", "cep":"89700000", "uf":"SC" }, "identificacaoBoletoEmpresa":"88", "tipoJurosMora":3, "tipoMulta":0, "identificacaoEmissaoBoleto":2, "identificacaoDistribuicaoBoleto":2, "codigoProtesto":2, "numeroDiasProtesto":7, "gerarPdf":false, "codigoCadastrarPIX":1 } } ] } No aguardo. Agradeço.

Boa tarde amigos! A cidade de Corupá (SC) trocou de provedor de Betha para IPM; Segue seção para substituir no arquivo INI: [4204509] Nome=Corupa UF=SC Provedor=IPM ProRecepcionar=http://sync.nfs-e.net/datacenter/include/nfw/importa_nfw/nfw_import_upload.php HomRecepcionar=http://sync.nfs-e.net/datacenter/include/nfw/importa_nfw/nfw_import_upload.php ProLinkURL=http://sync.nfs-e.net/datacenter/include/nfw/nfw_imp_notas.php?codauten=%CodVerif% HomLinkURL=http://sync.nfs-e.net/datacenter/include/nfw/nfw_imp_notas.php?codauten=%CodVerif% Params=ParametroExtra:eletron=1 Já alterei aqui e fiz os testes em produção, emiti e cancelei 2 NFs com sucesso. Obrigado pela atenção e aguardo para subirem essa alteração.

Bom dia Italo. Utilizamos o Fast.

Sim, esta é a impressão da prefeitura. A nossa esta desta forma: Estarei enviando o xml para veriricação para o e-mail dos consultores. Obrigado.

Olá; Contabilidade esta nos cobrando referente a impressão do DANFSe, que segundo eles, precisa esta em acordo ao que o SOFTPLAN imprime. Segundo eles, a informação do código de atividade é obrigatório, porém esta informação vem do provedor, nós somente enviamos o idCnae, e na NFSe processada, é reotornado esse código de atividade. Olhando na SoftPlan.LerXml.pas, percebi que a descrição da atividade esta ignorada, sendo assim não conseguimos imprimir com estes dados. Alguém já relatou isso, pode ser feito de outra maneira, ou teremos que implementar? Agradeço.

bom dia! Beleza, se precisar de algo que eu faça aqui para testar, só avisar.

Tenho acesso ao curso, repassei todas as dependências e tudo está instalado Também não uso o Fortes, pois não gero nenhuma impressão. No caminho normal, onde o documento não tem erro de schema, autoriza certinho.

Sim, mesmo com a 1.1.1 ocorre AV. O Linux é o Ubuntu 20.04.6 LTS. Não tem ambiente gráfico, só pelo terminal. O que é estranho é que ele valida o schema e joga a mensagem no terminal: Só que essa mensagem não retorna no componente porque dá o erro de access violation.

Sim, eu também estou usando a 1.1.1

Olá. Estou implementado o evento de Ator Interessado, e me deparei com a Rejeição: <cStat>828</cStat> <xMotivo>Rejeicao: Nao permitido informar o campo tipo de autorizacao</xMotivo> De acordo com a NT, no caso de Autor do Evento ser "3 - Empresa Transportadora", não deve ser enviado a tag tpAutorizacao. Mas pelo que vi no componente está aceitando apenas 0 e 1, não sendo possível não enviar a tag. Segue print do manual sobre a rejeição: Também em anexo o XML de envio e retorno feitos em homologação. 2024000002-eve.xml 2024000002-ped-eve.xml

@Italo Giurizzato Junior @valter_kettner Estava passando pelo mesmo problema aqui neste município. Entrei em contato com a prefeitura e consegui contato com o responsável pela área de tributação da prefeitura. O que me informou a URL correta, fiz o teste e deu certo. Segue abaixo as linhas para serem alteradas no arquivo INI: [4310207] Nome=Ijui UF=RS Provedor=Pronim ProRecepcionar=http://ijui.govbr.cloud/nfse.portal.integracao/services.svc Reparem que é somente http (sem s), e no caso a prefeitura estava divulgando o endereço com https.

Estou com o mesmo problema aqui na cidade Ijuí (RS), fiz a alteração no arquivo da URL que consta no site da prefeitura, porém ao se comunicar com o servidor recebo XML vazio e o erro 404. Já tentei alterar versão 2.02 e 2.03, porém ocorre o mesmo problema para das 2 versões. Alguém descobriu o que pode ser?

Mascarei só os paths, nome de usuário e senha, de resto testei com os dados que enviei aí.

Olá Daniel! Entendo que o erro acontece porque os dados não estão corretos, mas o meu problema é que estes erros no Windows retornam para o usuário. Já no Linux está retornando com Access Violation. Veja esse trecho do meu código: No Linux perceba que acontece um Access Violation Já no Windows o erro retorna corretamente para o usuário: Em resumo, meu problema não está na autorização do documento e sim no exception que acontece no Linux, impedindo que retorne o erro da validação para o usuário.

Bom dia Daniel! O path do schema está correto e eles estão atualizados. Esse exemplo que mandei são dados aleatórios, não me preocupo em autorizar o documento e sim na validação do schema. Se compilar o projeto que te enviei no Windows, ele vai retornar o erro de schema. Porém o que eu preciso é no Linux, e quando executa pelo Linux, ele não retorna o erro da validação do schema e sim erro de Segmentation fault. Como postei acima, o erro acontece na function TDFeSSLXmlSignLibXml2.TentaPegarMensagemErroDetalhada. Se vc compilar o projeto anexo aqui, vai verificar que quando é pelo windows, ao emitir ele retorna erros, já pelo linux, como dá o erro de Segmentation fault, não retorna nada em erros ou alertas. SandBox.zip

Estou enfrentando um problema na validação do schema da NFS-e no Linux. A princípio parece o mesmo problema citado aqui: Porém como o tópico foi criado a algum tempo, achei melhor abrir um novo tópico. O erro de Segmentation fault acontece na TDFeSSLXmlSignLibXml2, na função TentaPegarMensagemErroDetalhada function TDFeSSLXmlSignLibXml2.TentaPegarMensagemErroDetalhada(const MsgErroAtual: string): String; var prtUltimoErroXml: xmlErrorPtr; begin Result := ''; prtUltimoErroXml := xmlGetLastError(); if (prtUltimoErroXml <> nil) then begin Result := MsgErroAtual+ ' --> ' + IntToStr(prtUltimoErroXml^.code) + ' - ' + prtUltimoErroXml^.message; end else Result := MsgErroAtual; end; Porém no terminal, mostra a mensagem da validação da validação Se compilar no Windows, valida normalmente. Anexo criei um exemplo onde o problema acontece. Desde já agradeço. SandBox.zip

Obrigado.

@Italo Giurizzato Junior Testei o ajuste e ficou correto, pode subir a alteração. Att, Maiquel