Levi Diorginis da Silva
-
Total de ítens
6 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Tudo que Levi Diorginis da Silva postou
-
NFSe - Provedor Betha - nova URL cidade Criciúma-SC
Levi Diorginis da Silva replied to jacke venson's tópico in ACBrNFSe
Boa tarde! Você está utilizando integração direta via WebService ou está usando o componente do ACBr? Pergunto porque aqui também conseguimos emitir com a Betha na versão 1.0 apenas trocando a URL, mas não tivemos nenhum retorno da nota — nem número, nem protocolo. A nota foi realmente gerada (confirmamos no portal da prefeitura), mas via WebService não houve resposta, o que complica pra fazer o acompanhamento ou cancelamento. Caso você também esteja usando WebService direto, seria ótimo saber se teve o retorno normalmente. (Se for via ACBr, acredito que o cenário possa ser um pouco diferente na forma como o componente trata a resposta.) -
NFSe - Provedor Betha - nova URL cidade Criciúma-SC
Levi Diorginis da Silva replied to jacke venson's tópico in ACBrNFSe
Opa, boa notícia aqui também! Descobrimos que estávamos usando a URL nova com HTTP para a versão 2.02, enquanto para a versão 1.0 já estávamos usando HTTPS. Por isso, só na 2.02 aparecia aquele erro de 301 Moved Permanently. Testamos agora usando HTTPS também na 2.02, e funcionou! Ainda não tivemos nenhuma nota autorizada, mas agora os erros são de regra de negócio (ou seja, chegaram na Betha e estão sendo validadas corretamente), então já é um ótimo sinal. Resumo até aqui: Versão 2.02 com WSDL antigo + URL nova via HTTPS: está funcionando normalmente! (dentro do esperado, do que testamos) Versão 1.0 com WSDL antigo + URL nova: ainda estamos com problema, a nota é autorizada mas não há retorno com o código de protocolo, então ficamos sem como consultar ou cancelar depois. -
NFSe - Provedor Betha - nova URL cidade Criciúma-SC
Levi Diorginis da Silva replied to jacke venson's tópico in ACBrNFSe
Bom dia, Ítalo, Nós não utilizamos o ACBr, mas estamos integrando diretamente com a Betha via WebService e também estamos enfrentando os mesmos problemas. E sim, para essas novas URLs, não há mais separação entre os endereços de produção e homologação. Ambas usam a mesma URL, e o ambiente (produção ou homologação) é definido internamente no sistema da Betha para cada contribuinte, através de um parâmetro de configuração. Ou seja, não é mais possível que um mesmo emissor utilize produção e homologação ao mesmo tempo, pelo menos pelo que conseguimos entender até agora. Referências: fonte: https://iss.ajuda.betha.cloud/e-nota-cloud/ajuda/outros-conteudos/web-service/ https://iss.ajuda.betha.cloud/e-nota-cloud/ajuda/modulo-contribuinte/ambiente-de-homologacao/ Como comentei na resposta anterior: mesmo com a URL nova, não conseguimos emitir utilizando a versão 2.02 — recebemos um erro estranho (301 Moved Permanently). Aparentemente, o suporte à nova versão ainda está inconsistente.
-
NFSe - Provedor Betha - nova URL cidade Criciúma-SC
Levi Diorginis da Silva replied to jacke venson's tópico in ACBrNFSe
Outro detalhe importante: ao usar o WSDL antigo e apenas mudar o endereço para a nova URL, conseguimos emitir nota somente na versão 1.0. Quando tentamos a emissão na versão 2.02, o retorno foi um erro, no mínimo, irônico — mesmo estando já na nova URL: <html> <head> <title>301 Moved Permanently</title> </head> <body> <center> <h1>301 Moved Permanently</h1> </center> </body> </html> -
NFSe - Provedor Betha - nova URL cidade Criciúma-SC
Levi Diorginis da Silva replied to jacke venson's tópico in ACBrNFSe
Nós não utilizamos o ACBr — fazemos integração direta via WebService com a Betha. As novas URLs não oferecem um WSDL válido, então não conseguimos importar as operações, schemas e classes automaticamente. Passamos quase um dia tentando configurar tudo manualmente. Por curiosidade (ou só por desencargo de consciência), no dia seguinte testamos usar o WSDL antigo, mas apontando para o endereço novo — e para nossa surpresa, a emissão funcionou: a nota foi autorizada pela prefeitura. No entanto, não recebemos o retorno esperado. A resposta foi diferente da que o endpoint antigo costumava fornecer — a classe de retorno não foi preenchida corretamente. Ou seja, a nota foi emitida, mas sem o protocolo de retorno que normalmente usamos para guardar localmente, consultar status ou realizar o cancelamento. Como atendemos mais de um município e não sabíamos se a nova URL funcionaria para todas as cidades, implementamos um if usando o código do município de Criciúma para testar especificamente com a URL nova. -
NFSe - Provedor Betha - nova URL cidade Criciúma-SC
Levi Diorginis da Silva replied to jacke venson's tópico in ACBrNFSe
Estamos enfrentando um problema semelhante aqui. Fizemos a integração via WebService direto com a Betha e, usando a URL antiga, o serviço responde normalmente — ou seja, o WSDL está acessível, os métodos SOAP são expostos corretamente, e conseguimos consumir o serviço normalmente. No entanto, ao tentar emitir uma nota para um emissor da cidade de Criciúma, o retorno é de que o CNPJ não tem autorização ou acesso ao serviço — aparentemente porque a cidade já migrou obrigatoriamente para a nova URL da Betha Cloud. Ao utilizar a nova URL: https://nota-eletronica.betha.cloud/rps/ws/recepcionarLoteRps?wsdl Nos deparamos com uma série de erros diferentes, por exemplo: There was an error downloading 'https://nota-eletronica.betha.cloud/rps/ws/recepcionarLoteRps?wsdl/$metadata'. The request failed with HTTP status 405. Metadata contains a reference that cannot be resolved: '...recepcionarLoteRps?wsdl'. The content type application/json;charset=UTF-8 of the response message does not match the content type of the binding (application/soap+xml; charset=utf-8). ... Internal Server Error","message":"Could not create message from InputStream: Unable to internalize message Tentamos de várias formas, inclusive: Baixamos os .xsd disponibilizados aqui: https://iss.ajuda.betha.cloud/e-nota-cloud/ajuda/outros-conteudos/web-service#--download-do-schema-do-xml Convertendo os .xsd em classes e adaptando nossa aplicação Como também percebemos ao analisar os arquivos .xsd, eles definem apenas a estrutura dos dados (XML), mas não trazem as operações/métodos SOAP — que normalmente estariam no WSDL, e o WSDL da nova URL parece mal configurado ou até incompatível com ferramentas padrão de consumo. Se alguém conseguiu emitir via essa nova URL usando WebService direto (fora do ACBr), seria ótimo compartilhar detalhes do fluxo.
