Alexandre Felippeto Henzen

É um serviço que roda no nosso servidor nuvem...

Descobri pelo portal da prefeitura que o lote foi rejeitado devido a data de emissão, porque Manaus tem fuso horário. Existe algo no ACBr que já trate essa situação de fuso horário?

Ao consultar o lote no portal da prefeitura de Manaus/AM está retornando o erro: "E403 - Lote de RPS recebido e foram detectados erros ao processar" Consulta: <ConsultarLoteRpsEnvio> <Prestador> <Cnpj>47358779000185</Cnpj> <InscricaoMunicipal>55252601</InscricaoMunicipal> </Prestador> <Protocolo>3069C92E22A237F5AC30FCA2ABEBA904</Protocolo> </ConsultarLoteRpsEnvio> Retorno: <ConsultarLoteRpsResposta> <ListaMensagemRetorno> <MensagemRetorno> <Codigo>E403</Codigo> <Mensagem>Lote de RPS recebido e foram detectados erros ao processar.</Mensagem> <Correcao>Recuperar a relação dos erros</Correcao> </MensagemRetorno> </ListaMensagemRetorno> </ConsultarLoteRpsResposta> Tentei emitir em ambiente de homologação e me retornou outro erro: "E50 - Inscricao Municipal do prestador inválida", sendo que os dados estão corretos. Será que é necessário habilitar o ambiente de homologação pra esse prestador? Não consigo falar no provedor e nem nessa prefeitura, alguém teria algum contato? 8-env-lot.xml 8-env-lot-soap.xml 8-rec.xml 8-rec-soap.xml CC4827793AC6B6B79B3BACD5CF73B490-con-lot.xml CC4827793AC6B6B79B3BACD5CF73B490-con-lot-soap.xml CC4827793AC6B6B79B3BACD5CF73B490-lista-nfse-con-lot.xml CC4827793AC6B6B79B3BACD5CF73B490-lista-nfse-con-lot-soap.xml

Bom dia @Italo Giurizzato Junior Sobre Campo Largo, teve mudança da IPM recente sobre o layout, está sendo tratado pelo ACBr neste tópico: Estou aguardando o pessoal liberar esta correção de Campo Largo para dar sequencia, no momento estou sem emitir pra Campo Largo.. Sobre Pinhais, na verdade não tive erros... Atualizei a URL no meu ACBrNFSeXServicos.ini sim e uma emissão para Pinhais funcionou normal.. Conforme comentário anterior, liguei para a IPM no (47) 3531-1500 (opção 3 Fiscal, opção 3 Paraná, opção 1 Nota Fiscal) e a atendente confirmou a URL de pinhais sem o &cidade=padrao. Se quiser ligar la e re-confirmar, assim ficará mais claro para mandar a alteração adiante ou não.

Então @Juliana Tamizou Meu problema na verdade era de Campo Largo, onde a IPM atualizou do layout 1.00 para o 1.01 dia 04/12/2023 conforme o atendente no 47 3180-0578. Vi que o pessoal está já tratando este assunto aqui neste tópico: Liguei para a IPM novamente no (47) 3531-1500 (opção 3 Fiscal, opção 3 Paraná, opção 1 Nota Fiscal) e a atendente confirmou a URL de pinhais sem o &cidade=padrao. Verifiquei alguns logs, e após retirar a URL confirmei emissão de sucesso para Pinhais de alguns clientes meus sem problemas. Resumindo, não tive erro pra Pinhais no inicio da minha resposta, mas sim Campo Largo. Porém mudei URL Pinhais e funcionou normalmente. Desculpem a confusão..

Assim que possível retorno @Juliana Tamizou!!

Bom dia @Italo Giurizzato Junior Atualizei os componentes e um cliente teve o seguinte erro ao enviar uma nota para Pinhais: 00304 - Atividades encerradas para o municí­pio prestador do serviço. Em contato com a IPM, eles me perguntaram a URL, eu passei a que estava no .ini do ACBr, que é a mesma informada acima pelo @Dercide Alvarez acima, eles me informaram que a correção é tirar o final ali &cidade=padrao Ficando a URL apenas : https://pinhais.atende.net/atende.php?pg=rest&service=WNERestServiceNFSe Ainda não consegui realizar testes com esta alteração...

Verifiquei sim, acredito que resolve nosso problema também. Assim passo o layout 6 e o uso continua o que já é hoje. Tem previsão para ficar disponível no svn?

Olá entrei em contato com o banco DAYCOVAL e peguei um manual mais atualizado E como citado ali em cima continua na mesma posição o nosso número 63 com 10 digitos: Segue em anexo o manual SET/2023 que consultei: Manual M. 707 - Banco Daycoval Set-23.pdf

Em contato com o Sefaz de MG (31) 3069-6601 - opção 5 - opção 3, falei com a atendente Maria e a mesma me informou que já foi identificado o problema no portal deles em relação a rejeição 719 e estão trabalhando para resolver.

Se trata de uma nota de exterior então eu posso deixar essa tag vazia.

O de ficar nulo está correto, pois foi emitida uma nota em abril praticamente igual e deu certo. CLISOL_10661_IMPRESSA.xml

Alguém pode me ajudar com essa rejeição da NFe 719? A tag <idEstrangeiro/> está declarada no xml. CLISOL_11337_ABERTA.xml

Olá realizamos algumas verificações quanto as credenciais... Observamos que para registrar um boleto a credencial usada é somente a X-ITAU-APIKEY e o token gerado anteriormente. Então as credenciais/certificado são usadas mesmo somente na geração do TOKEN. Pode me confirmar se essa informação está correta? Se sim, seria um problema com o token gerado pela API?

Boa tarde, fiz uma alteração na forma de passar os certificados para o componente e consegui gerar o token, porém não consigo registrar o boleto. Porque recebo 403 Authentication Failed. Segue meu Arqlog alterei o CLIENT_ID para tirar as informações sensíveis. A forma comentada é como passava antes e forma não comentada é como consegui gerar o token: No BoletoWS.RetornoBanco.CodRetorno chega como 0; No BoletoWS.RetornoBanco.Msg chega como 'HTTP_Code=403 Authentication Failed' No BoletoWS.RetornoBanco.HTTPResultCode chega como 403 ArqBoletoWS.log

Não, o certificado não possui nenhum tipo de senha, temos 4 certificados aqui. Um arquivo ".CRT", ".KEY", ".PFX", ".CSR"; Key e Csr foi gerado pelo cliente e os demais retornados pelo ITAU junto do client id e client secret: Pelo postman consigo gerar os tokens de produção passando o ".CRT" e o ".KEY": Porém pelo postman não consegui registrar um boleto, tive o: Com autenticação do tipo bearer token.

Olá temos alguma novidade sobre esse cenário?

É importante ressaltar também que no postman conseguimos gerar o acesstoken do itau: Passamos o certificado fornecido o .CRT e foi possível fazer a requisição no postman

Olá boa tarde, estamos ativando o primeiro cliente em produção utilizando o ITAU via API para registro de boletos. Estamos tendo problemas quanto a autenticação ao tentar autenticar sem o certificado recebemos o seguinte json: que não é considerado no tratamento da mensagem do ACBr Seguindo um pouco mais ao preencher o "ACBrBoleto.Configuracoes.WebService.ArquivoCRT" com o meu .CRT que foi fornecido pelo ITAU O retorno que eu tenho é esse: Informações adicionais: Scope := 'boletoscash-boletos-consulta_titulo'; Ambiente: Produção WebService.VersaoDF := 'V2'; ArqBoletoWS.log

O nosso cliente de MG emitiu várias notas de produtos que foram autorizadas com chave e protocolo, mas ao consultar a NFe no portal nacional e no portal de MG, não constam; o que pode ter acontecido? SITUAÇÃO NÚMERO CHAVE PROTOCOLO RECIBO CANCELADA 4740 31230707204011000302550010000047401751298570 131235476048988 310012099460208 IMPRESSA 4741 31230707204011000302550010000047411720587519 131235475279348 310012100833096 CANCELADA 4742 31230707204011000302550010000047421710455137 131235476055492 310012104657075 IMPRESSA 4743 31230707204011000302550010000047431505002077 131235476147248 310012105261294 IMPRESSA 4744 31230707204011000302550010000047441502949178 131235476232618 310012105560653 IMPRESSA 4745 31230707204011000302550010000047451204088600 131235479869075 310012135326457 IMPRESSA 4746 31230707204011000302550010000047461514539845 131235479884214 310012135385285

Enviamos novamente a nota e o portal aceitou retornando a consulta com o protocolo.

O xml da nota foi enviado e retornou o recibo com sucesso. Ao consultar exibe "105 - Lote em processamento"; a nota foi emitida as 09:51 e até agora as 15:30 vem exibindo essa mensagem de retorno. Consultei no portal do Sefaz nacional e no portal do RS e não consta a nota. Existe alguma maneira de tratar esse retorno pra saber se realmente ocorreu problema e poder enviar a nota novamente?

Poderia informar em qual versão saiu essa atualização Ítalo na NFSex

Consegui entrar em contato com o pessoal da prefeitura, me falaram que está fora do ar mesmo

Também estou com problema...