NFSe - Provedor Betha - nova URL cidade Criciúma-SC

xpec · Sexta as 14:17

2 hours ago, Levi Diorginis da Silva said:

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>

Sua dica deu certo, consegui consultar notas utilizando a versão 2.02 modificando o wsdl.

Diogo Loff · Sexta as 14:24

Galera eu tenho um pouco de opnião forte sobre o que esta aqui sendo discutido e não me entendam mal.

Assim esta sendo misturado versão 2 com versão 1. Pelos testes que fiz o componente do ACBr na versão 2 mesmo sem antes da atualização esta funcionando, versão 1 não.

Falando sobre o meu caso de uso, não posso usar a 2, pois não tenho parte dos campos necessários para atender o modelo 2, então preciso continuar no 1.

Como meu limite com os clientes é hoje e também já consegui contato com a betha vou ajustar na versão 1 como imagino ser o correto e estarei enviando para vocês mais tarde, espero até o final do dia o fonte com a correção para quem deseja usar na versão 1.

E estou vendo uma falta de comunicação com o pessoal do ACBr pois até agora pelos comentarios não conseguiram entender que tem gente aqui falando de versão 1 e versão 2. Ainda ficam questionando as URLS, o meu segundo post aqui dentro eu trago exatamente o documento da prefeitura com as novas URLs para Versão 1 e para Versão 2, e ainda esta sendo discutido URLs aqui, o problema não é URLs e sim XML mal formado que esta dando erro, porque por algum motivo a Betha mudou "coisas" e simplemente não divulgou.

Em breve espero ainda hoje mando o fonte qui fiz para versão 1 a quem interessar.

MiguelBento · Sexta as 14:28

Como membro pró, estou sentindo desamparado pela equipe do acbr. Sempre com um estamos resolvendo...

Alexandre de Paula · Sexta as 14:34

2 minutos atrás, MiguelBento disse:

Como membro pró, estou sentindo desamparado pela equipe do acbr. Sempre com um estamos resolvendo...

Bom dia @MiguelBento,

Estamos atuando nesta ocorrencia conforme você pode acompanhar neste mesmo tópico em algumas mensagens atrás (

)

A caso é que as alterações do provedor não são claras e nós não temos credenciais para teste. Com isso o processo se torna mais lento.

O Italo passou todas as informações para configuração e dependemos da resposta de vocês para validar se está funcionando ou não.

Fiquem a vontade para informar aqui ou em outros tópicos os resultados que estão obtendo com os ajustes. Podem nos procurar nos canais do Discord também.

Levi Diorginis da Silva · Sexta as 14:36

12 minutos atrás, xpec disse:

Sua dica deu certo, consegui consultar notas utilizando a versão 2.02 modificando o wsdl.

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.

Gabriel Herdt · Sexta as 14:46

17 horas atrás, xpec disse:

Independente da versão utilizada, alguém conseguiu emitir ou cancelar alguma nota fiscal com essa nova url?

Já citei aqui.

betha já informou que a versão a ser usada é a 1.0 pois ela atende todas questões legais, exemplo substituição tributária.

se sua empresa emite com substituição tributária nao pode usar versão 2.02.

charleshorr · Sexta as 14:48

Acabei de conversar com o pessoal da prefeitura e consegui validar a nota fiscal só mudando a url, a betha voltou a validar no modo antigo porem na nova url, poderiam fazer um teste?

xpec · Sexta as 14:55

6 minutes ago, Gabriel Herdt said:

Já citei aqui.

betha já informou que a versão a ser usada é a 1.0 pois ela atende todas questões legais, exemplo substituição tributária.

se sua empresa emite com substituição tributária nao pode usar versão 2.02.

Sim a betha informou isso e sua citação não respondeu minha pergunta. O grande problema é que não funciona o que eles colocaram no ar, nem emitir nem cancelar, tem que fazer gambiarra pra funcionar.

Tom E Mi · Sexta as 15:03

7 minutos atrás, xpec disse:

Sim a betha informou isso e sua citação não respondeu minha pergunta. O grande problema é que não funciona o que eles colocaram no ar, nem emitir nem cancelar, tem que fazer gambiarra pra funcionar.

Para mim autorizou. Na versão 1 só mudando url.

geovanesilveira · Sexta as 15:03

Com o ACBr atualizado agora e sem nenhuma modificação, fiz os seguintes testes (diretamente do meu programa em ambiente de produção):

ACBrNFSeX (versão 1.0)

Modifiquei o ACBrNFSeXServicos.ini para o seguinte:

[4204608]
Nome=Criciuma
UF=SC
Provedor=Betha
ProRecepcionar=https://nota-eletronica.betha.cloud/rps/ws/recepcionarLoteRps
ProConsultarSituacao=https://nota-eletronica.betha.cloud/rps/ws/consultarSituacaoLoteRps
ProConsultarLote=https://nota-eletronica.betha.cloud/rps/ws/consultarLoteRpsV110
ProConsultarNFSeRps=https://nota-eletronica.betha.cloud/rps/ws/consultarNfsePorRpsV110
ProConsultarNFSe=https://nota-eletronica.betha.cloud/rps/ws/consultarNfseV110
ProCancelarNFSe=https://nota-eletronica.betha.cloud/rps/ws/cancelarNfse

e ao enviar recebo o erro:

Erro de Validação: Content for element '{http://www.betha.com.br/e-nota-contribuinte-ws}EnviarLoteRpsEnvio' is incomplete according to the DTD/Schema.
Expecting: {http://www.w3.org/2000/09/xmldsig#}Signature.

olhando no site, o RPS nem chegou la

ACBrNFSeX (versão 2.02)

Modifiquei o ACBrNFSeXServicos.ini para o seguinte:

[4204608]
Nome=Criciuma
UF=SC
Provedor=Betha
Versao=2.02
ProRecepcionar=https://nota-eletronica.betha.cloud/rps/ws/recepcionarLoteRps
ProConsultarSituacao=https://nota-eletronica.betha.cloud/rps/ws/consultarSituacaoLoteRps
ProConsultarLote=https://nota-eletronica.betha.cloud/rps/ws/consultarLoteRpsV110
ProConsultarNFSeRps=https://nota-eletronica.betha.cloud/rps/ws/consultarNfsePorRpsV110
ProConsultarNFSe=https://nota-eletronica.betha.cloud/rps/ws/consultarNfseV110
ProCancelarNFSe=https://nota-eletronica.betha.cloud/rps/ws/cancelarNfse

e ao enviar recebo o erro:

Project ... raised exception class EACBrDFeException with message 'Serviço %s não implementado para este provedor.

porém, olhando no site, o RPS chegou e a nota fiscal está cadastrada e autorizada

fiz o teste no 2.02 mas não usamos e, segundo relatos de outros usuário, a propria Betha diz que para Criciúma precisa ser o 1.0

ACBRNFSe (versão 1.0)

Modifiquei o Cidades.ini para:

[4204608]
Nome=Criciuma
UF=SC
Provedor=Betha
ProRecepcionar=https://nota-eletronica.betha.cloud/rps/ws/recepcionarLoteRps
ProConsultarSituacao=https://nota-eletronica.betha.cloud/rps/ws/consultarSituacaoLoteRps
ProConsultarLote=https://nota-eletronica.betha.cloud/rps/ws/consultarLoteRpsV110
ProConsultarNFSeRps=https://nota-eletronica.betha.cloud/rps/ws/consultarNfsePorRpsV110
ProConsultarNFSe=https://nota-eletronica.betha.cloud/rps/ws/consultarNfseV110
ProCancelarNFSe=https://nota-eletronica.betha.cloud/rps/ws/cancelarNfse

e ao enviar recebo o erro:

Prestador de serviA o nA o estA  registrado no sistema.
Favor entrar em contato com a Prefeitura para maiores informaA A es.

olhando no site, o RPS nem chegou la

Everton M Gava · Sexta as 15:16

1 hora atrás, Roberto Rohden disse:

bom dia, estava com esse erro tambem para resolver o cnpj do prestador tive que mandar assim:

<CpfCnpj>

<Cnpj>72268998000110</Cnpj>

</CpfCnpj>

e tem mais outroi erro no xml esta mandando ns3: na tag enviarloterpos tem que tirar

Fizemos isso ai e não conseguimos sucesso. Precisamos emitir na versão 1.0. A versão 2.02 não contempla todas as regras de negócio

Levi Diorginis da Silva · Sexta as 16:23

1 hora atrás, Tom E Mi disse:

Para mim autorizou. Na versão 1 só mudando url.

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.)

Gabriel Herdt · Sexta as 16:58

2 horas atrás, Roberto Rohden disse:

bom dia, estava com esse erro tambem para resolver o cnpj do prestador tive que mandar assim:

<CpfCnpj>

<Cnpj>72268998000110</Cnpj>

</CpfCnpj>

e tem mais outroi erro no xml esta mandando ns3: na tag enviarloterpos tem que tirar

Obrigado pela info, fiz isso, tirei o ns3.
Fiz debug pra ver link conectado, esta no novo.
E contínuo recebendo retorno: E260 CNPJ/CPF do prestador do serviço não informado. Informe o CNPJ/CPF do prestador do serviço.

Diogo Loff · Sexta as 17:02

Fala ja resolvi aqui isto, to terminando ultimos testes para ver se ficou correto as alterações na unit Betha.Provider.

Agora somente vou testar com outro municipio que é a URL antiga para ver se continua compativel, tenho ambiente aqui por exemplo de Cocal do Sul, mais um pouco devo retornar aqui pra galera.

Diogo Loff · Sexta as 17:11

Galera saiu de boa aqui com as alterações que um desenvolvedor da Betha me orientou a fazer.

Versão 1.0 nenhuma modificação em regras do sistema foi necessário, somente vou testar agora Cocal do Sul e mando a solução para quem desejar.

Italo Giurizzato Junior · Sexta as 17:15

Boa tarde @Diogo Loff,

Foi necessário fazer alguma alteração no fonte do componente ou somente a alteração no arquivo ACBrNFSeXServicos.ini para conseguir emitir com sucesso?

Diogo Loff · Sexta as 17:19

2 minutos atrás, Italo Giurizzato Junior disse:

Boa tarde @Diogo Loff,

Foi necessário fazer alguma alteração no fonte do componente ou somente a alteração no arquivo ACBrNFSeXServicos.ini para conseguir emitir com sucesso?

Italo no fonte do componente no Betha.Provider, e é exetamente no mesmo local que venho falando ontem para vocês já no meu segundo post dei a letra.

Eu to um pouco indignado com a equipe do ACBr pois parece que ninguem leu meu post, e mesmo assim eu sendo um zero a esquerda em XML consegui corrigir aqui, logo mando a solução. Creio que se tivessem lido o que coloquei e respondido, provavelmente a solução tinha saido no mesmo dia, bastava dar um insite de como entender o schema e saber o que ajustar.

Depois que a pessoa da Betha falou para mim o que era no schema entendi a diferença entre um e outro, e aposto que vocês do ACBr que trabalham com isto diáriamente já teriam notado, mas blz, só uma critica, antes que alguem venha dar carteirada de que se fosse PRO teria resolvido mais rapido.

Italo Giurizzato Junior · Sexta as 17:38

Boa tarde @Diogo Loff,

Não é má vontade em resolver, o problema é que uns fizeram testes na versão 1 e outros na versão 2 e todos colocando os seus retornos e acabou ficando confuso qual versão o provedor e ou a cidade vão utilizar.

Nos testes que realizei não se fez necessário nenhuma alteração no código do componente, pode ser que se eu usar as credenciais de um prestador da referida cidade o webservice do provedor venha acusar mais alguma coisa.

Por favor anexe a unit alterada para que possamos validar.

Desde já muito obrigado pela colaboração.

Toda critica é bem vinda.

Diogo Loff · Sexta as 17:41

SOLUÇÃO PARA EMISSÃO VERSÃO 1:

Anexo arquivo Betha.Provider, basicamente tratei a questão do NS3 envolvido em várias rotinas, todas estão funcionando com exceção do CANCELAMENTO, se alguem ai se prontificar a me ajudar agradeço, só falta resolver esta.

Testes realizados com CRICIÚMA que é o novo e com COCAL DO SUL que é o velho. Basicamente se resume a função nova que criei chamada function TACBrNFSeProviderBetha.AdicionaNS3: String; ali eu chumbei a cidade de CRICIÚMA talvez não seja a melhor opção, acredito que o ACBr possa ter parâmetros esdpecificos que talvez poderiam ser usados para ter esta diferênciação, porem quem vai dizer isto é somente o pessoal do ACBr, poderiam dar este caminho para nós.

Sobre o ambiente de testes quando ativa HOMOLOGAÇÃO, o mesmo não esta levando em conta a regra do SIMPLES NACIONAL então e você enviar uma NF de testes e der erro que a aliquota não é a correta, porque a empresa é do simples e trabalha diferente se quiser testar envia com o exemplo que a propria mensagem vai dar. Outro erro é do CNAE quando ativo a homologação lá no site o cadastro da empresa fica com o CNAE em branco ai se você manda CNAE vai dar erro, então mande sem.

Não testei em produção, produção será o CLIENTE que vai testar, e só segunda-feira vou trocar a versão.

Sobre o cancelamento esta dando um erro. E se entrar no portal da Betha lá dentro a nota continua valida sem estar cancelada. Preciso de ajuda ai.

O Fonte anexo é de uma versão do ACBR de 05.03.2025, não vou ainda atualizar o fonte, pois visto que aqui ninguem resolver o problema então tomem cuidado ao aplicar a correção, se o fonte de vocês for diferente dará problemas provavelmente, então talvez recomendo que façam manualmente comparando as linhas alteradas onde tem a chamada da função nova. Não irei dar solução para versão 2 para quem por ventura precise, pois nem meu sistema é preparado para esta versão.

Confgurações no arquivo ini

[4204608]
Nome=Criciuma
UF=SC
Provedor=Betha
ProRecepcionar=https://nota-eletronica.betha.cloud/rps/ws/recepcionarLoteRps
ProConsultarSituacao=https://nota-eletronica.betha.cloud/rps/ws/consultarSituacaoLoteRps
ProConsultarLote=https://nota-eletronica.betha.cloud/rps/ws/consultarLoteRps
ProConsultarNFSeRps=https://nota-eletronica.betha.cloud/rps/ws/consultarNfsePorRps
ProConsultarNFSe=https://nota-eletronica.betha.cloud/rps/ws/consultarNfse
ProCancelarNFSe=https://nota-eletronica.betha.cloud/rps/ws/cancelarNfse
HomRecepcionar=https://nota-eletronica.betha.cloud/rps/ws/recepcionarLoteRps
HomConsultarSituacao=https://nota-eletronica.betha.cloud/rps/ws/consultarSituacaoLoteRps
HomConsultarLote=https://nota-eletronica.betha.cloud/rps/ws/consultarLoteRps
HomConsultarNFSeRps=https://nota-eletronica.betha.cloud/rps/ws/consultarNfsePorRps
HomConsultarNFSe=https://nota-eletronica.betha.cloud/rps/ws/consultarNfse
HomCancelarNFSe=https://nota-eletronica.betha.cloud/rps/ws/cancelarNfse

Betha.Provider.pas

Agora que eu dei a solução aqui, veja se faz um favor pra mim e viabiliza aquela customização que a mais de 3 anos reclamo da impressão da NFSe principalmente para Chapecó que falta um campo e o PANDA sempre se nega a customizar, please. Fazer uma troca mutua ai.

5 minutos atrás, Italo Giurizzato Junior disse:

Boa tarde @Diogo Loff,

Não é má vontade em resolver, o problema é que uns fizeram testes na versão 1 e outros na versão 2 e todos colocando os seus retornos e acabou ficando confuso qual versão o provedor e ou a cidade vão utilizar.

Nos testes que realizei não se fez necessário nenhuma alteração no código do componente, pode ser que se eu usar as credenciais de um prestador da referida cidade o webservice do provedor venha acusar mais alguma coisa.

Por favor anexe a unit alterada para que possamos validar.

Desde já muito obrigado pela colaboração.

Toda critica é bem vinda.

Agora que eu dei a solução aqui, veja se faz um favor pra mim e viabiliza aquela customização que a mais de 3 anos reclamo da impressão da NFSe principalmente para Chapecó que falta um campo e o PANDA sempre se nega a customizar, please. Fazer uma troca mutua ai.

Diogo Loff · Sexta as 18:04

ATENÇÃO SOBRE O CANCELAMENTO:

Esta funcionando sim, porem com um detalhe, o código de cancelamento "ERRO DE EMISSÃO" que é o unico que a betha aceita, no ambiente antigo por o código é 0, agora no ambiente novo esta código 1. Não vou modificar ainda pode ser erro deles, acabei de mandar um e-mail para o contato de lá para verificar esta questão, se for somente isto. Digamos que agora seja realmente assim, a solução seria fazer algo semelhante que fiz aqui, colocar em algum lugar se for tal parâmetro que indique que é ambiente novo mandar 1 no lugar de 0.

Acho que agora podemos dormir o final de semana tranquilos.

Italo Giurizzato Junior · Sexta as 19:10

Boa tarde a todos,

Façam uma cópia de suas alterações e depois, atualizem todos os fontes de todas as pastas, reinstalem o ACBr e façam os testes.

Notem que foi disponibilizado um novo Schema para a cidade de Criciúma/SC, ele esta na pasta: ...\Exemplos\ACBrDFe\Schemas\NFSe\Betha\1.00 com o nome de: nfse_betha_v01.xsd (favor não alterar o nome pois o componente procura por esse nome).

Fiz também uma alteração no arquivo ACBrNFSeXServicos.ini, acrescentei esta linha:

Params=SubVersao:1

Pois as demais cidades que ainda não migraram para esse novo webservice vai continuar funcionando.

As cidades que já migraram vai precisar alterar o arquivo ACBrNFSeXServicos.ini da mesma forma que foi feito para a cidade de Criciúma/SC.

Fico no aguardo de um retorno de vocês.

Diogo Loff · Sexta as 19:27

Ficou interessante a alteração @Italo Giurizzato Junior era isto ai mesmo que eu imaginava, infelizmente aqui não poderei atualizar para fazer testes pois segunda sai nova versão do sistema e eu tenho ainda uma customização no ACBr que é aquele caso de Chapeco e a DANFE que não quebra direito onde já relatei em outros posts, mas o sempre o PANDA responde e se nega a ajustar dizendo que é algo especifico meu.

Mas pelo seu código vejo que esta bem correto e vai funcionar.

Semana que vem onde começamos uma nova versão ai temos até dia 25/08 para liberar, eu vou atualizar o ACBr com tempo e do meu retorno, mas como vc fez vai funcionar com certeza, esta exatamente como meu código só que desta vez parâmetrizado dentro dos padrões do componente.

MiguelBento · Sexta as 19:29

Esta disponivel a LIB Ja?

Alexandre de Paula · Sexta as 19:50

20 minutos atrás, MiguelBento disse:

Esta disponivel a LIB Ja?

Estamos providenciando a compilação. Aviso assim que realizada.

Adriano Luiz de Souza · Sexta as 20:05

Boa Tarde ! Agradeço ao empenho de todos. Estou acompanhando o tópico desde terça-feira. Impressionante o deserviço que a Betha proporciona a seus clientes e parceiros com a suas péssimas política de comunicação com envolvidos.

Enfim, estava mexendo no fonte do Diogo para testar em produção quando o Ítalo disponibilizou no acbr as correções.

Versão Abrasf 1.0

Situação: Executando em produção, quando informado o vencimento no XML agora é retornado o seguinte erro:

Erro(s):
Código : X800
Mensagem: Erro de Validação: --> 1824 - Element '{http://www.betha.com.br/e-nota-contribuinte-ws}DataVencimento': '11/08/2025' is not a valid value of the atomic type 'xs:dateTime'.

Correção:
---------

Se tirar o vencimento do XML essa validação passa.

---------------------

Para não ficar longa mensagem, vou colocar cada situação em uma resposta diferente

Obrigado a todos

Adriano

2 horas atrás, Diogo Loff disse:

SOLUÇÃO PARA EMISSÃO VERSÃO 1:

Anexo arquivo Betha.Provider, basicamente tratei a questão do NS3 envolvido em várias rotinas, todas estão funcionando com exceção do CANCELAMENTO, se alguem ai se prontificar a me ajudar agradeço, só falta resolver esta.

Testes realizados com CRICIÚMA que é o novo e com COCAL DO SUL que é o velho. Basicamente se resume a função nova que criei chamada function TACBrNFSeProviderBetha.AdicionaNS3: String; ali eu chumbei a cidade de CRICIÚMA talvez não seja a melhor opção, acredito que o ACBr possa ter parâmetros esdpecificos que talvez poderiam ser usados para ter esta diferênciação, porem quem vai dizer isto é somente o pessoal do ACBr, poderiam dar este caminho para nós.

Sobre o ambiente de testes quando ativa HOMOLOGAÇÃO, o mesmo não esta levando em conta a regra do SIMPLES NACIONAL então e você enviar uma NF de testes e der erro que a aliquota não é a correta, porque a empresa é do simples e trabalha diferente se quiser testar envia com o exemplo que a propria mensagem vai dar. Outro erro é do CNAE quando ativo a homologação lá no site o cadastro da empresa fica com o CNAE em branco ai se você manda CNAE vai dar erro, então mande sem.

Não testei em produção, produção será o CLIENTE que vai testar, e só segunda-feira vou trocar a versão.

Sobre o cancelamento esta dando um erro. E se entrar no portal da Betha lá dentro a nota continua valida sem estar cancelada. Preciso de ajuda ai.

O Fonte anexo é de uma versão do ACBR de 05.03.2025, não vou ainda atualizar o fonte, pois visto que aqui ninguem resolver o problema então tomem cuidado ao aplicar a correção, se o fonte de vocês for diferente dará problemas provavelmente, então talvez recomendo que façam manualmente comparando as linhas alteradas onde tem a chamada da função nova. Não irei dar solução para versão 2 para quem por ventura precise, pois nem meu sistema é preparado para esta versão.

Confgurações no arquivo ini

[4204608]
Nome=Criciuma
UF=SC
Provedor=Betha
ProRecepcionar=https://nota-eletronica.betha.cloud/rps/ws/recepcionarLoteRps
ProConsultarSituacao=https://nota-eletronica.betha.cloud/rps/ws/consultarSituacaoLoteRps
ProConsultarLote=https://nota-eletronica.betha.cloud/rps/ws/consultarLoteRps
ProConsultarNFSeRps=https://nota-eletronica.betha.cloud/rps/ws/consultarNfsePorRps
ProConsultarNFSe=https://nota-eletronica.betha.cloud/rps/ws/consultarNfse
ProCancelarNFSe=https://nota-eletronica.betha.cloud/rps/ws/cancelarNfse
HomRecepcionar=https://nota-eletronica.betha.cloud/rps/ws/recepcionarLoteRps
HomConsultarSituacao=https://nota-eletronica.betha.cloud/rps/ws/consultarSituacaoLoteRps
HomConsultarLote=https://nota-eletronica.betha.cloud/rps/ws/consultarLoteRps
HomConsultarNFSeRps=https://nota-eletronica.betha.cloud/rps/ws/consultarNfsePorRps
HomConsultarNFSe=https://nota-eletronica.betha.cloud/rps/ws/consultarNfse
HomCancelarNFSe=https://nota-eletronica.betha.cloud/rps/ws/cancelarNfse

Betha.Provider.pas 24.26 kB · 1 download

Agora que eu dei a solução aqui, veja se faz um favor pra mim e viabiliza aquela customização que a mais de 3 anos reclamo da impressão da NFSe principalmente para Chapecó que falta um campo e o PANDA sempre se nega a customizar, please. Fazer uma troca mutua ai.

Agora que eu dei a solução aqui, veja se faz um favor pra mim e viabiliza aquela customização que a mais de 3 anos reclamo da impressão da NFSe principalmente para Chapecó que falta um campo e o PANDA sempre se nega a customizar, please. Fazer uma troca mutua ai.

Essa validação antes não era feita:

Erro(s):
Código : E166
Mensagem: Regime Especial de Tributação não informado para optante do simples nacional..
Correção: Quando a empresa prestadora do serviço for optante pelo simples nacional informe "05" MEI ou "06" ME/EPP.

Agora tem que informar o Regime Especial de Tributação quando se é simples. Colocando 05 ou 06 como sugere ali passa. Colocando 09 que é o Simples Nacional já não passa no Schema

Editado Sexta as 20:08 por Adriano Luiz de Souza

Entrar

Sobre nós...

NFSe - Provedor Betha - nova URL cidade Criciúma-SC

Recommended Posts

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

Italo Giurizzato Junior

jacke venson

Levi Diorginis da Silva

Posted Images

Sobre nós...

Informação Importante