Adriano Luiz de Souza

Pois é também acho isso. Eu mudei no muque o RPS que gera e acrescentei esse texto ali que dizem que falta. Pedi pro cliente importar o RPS manualmente vamos ver o que dá

Exatamente. Como nos outros clientes. Só nesse está empacado.

Sim o XML dos outros clientes é igual. Abaixo o print com o exemplo betha x o que foi transmitido em outro cliente Realmente não tem o que eles indicam que está faltando mas o do cliente foi autorizada sem precisar disso que eles indicam que está faltando. Eu sinceramente acredito que não tem relação. Eu vi aqui em outras situações no próprio fórum do ACBr que esse é um erro genérico. Pode ser uma infinidade de coisas. Eu tenho suspeita que tenha alguma relação com o código da atividade do serviço que é basicamente a única coisa que muda em relação aos outros clientes. Mas vou ser obrigado a fazer o que eles dizem. Aproveitando o gancho: podem me indicar onde posso mudar para que atenda esse requisito ? Tem algum propriedade ou tenho que cravar no fonte ? Obrigado Adriano Eu localizei a formação

Sim. Mas ficou pendente em 1 cliente. Erro(s): Código : E160 Mensagem: Arquivo em desacordo com o XML Schema. : [null]. Correção: Consulte o Manual da NFS-e para saber quais são as versões de XML Schema suportadas pelo sistema. Pedi pro cliente entrar em contato com a prefeitura que respondeu que o XML não está de acordo e apontaram que na tag lote deve passar dessa forma: <LoteRps xmlns="" Id="LOTE_2401">. Está faltando o xmlns="". Isso não explica porque os outros clientes a nota passa e nesse aí não passa. Recebi essa resposta hoje e mais tarde eu posto os resultados Att Adriano

Já tem bastante tempo que migrei para o ACBRNFSeX. Obrigado pela dica

Então nao tem relação com os endereços

Acredito que você tenha que atualizar os endereços dos webservices no acbrCidades.ini. Se não me engano esse foi o erro que deu quando atualizei na sexta e comecei a me envolver com esse problema

Esse arquivo não funcionou. Deu um outro erro referindo que o tipo de dado não tinha sido reconhecido. Aí vi que estava xs:string ao invés de xsd:string. Feita a correção no arquivo passou normalmente e validou a nota Obrigado Ítalo Att Adriano nfse_betha_v01.xsd

Este tópico que você cita é em relação ao RPS que é impedido de ser enviado se tiver que validar aquela tag pelos schemas. Este tópico aqui é referente ao processamento do RPS pela Betha após ter sido enviado driblando a validação do schema. Existe uma relação mas são situações distintas. Obrigado pela atenção Att Adriano

Bom Dia ! Ainda sobre as mudanças promovidas pela betha na migração para a AWS percebi que após o processamento do RPS e seu XML da NFSe gerado há diferenças significativas envolvendo o link de acesso da NFSe e o parcelamento: O link de acesso não vem mais em nenhuma TAG. Anteriormente a 21/07/2025 essa informação vinha na TAG <OutrasInformacoes> O XML agora no AWS não tem mais essa TAG no retorno Outra mudança é em relação aos vencimentos. Mesmo enviando no RPS ele não vem no XML da NFSe gerado pelo RPS. NFSe gerada antes de 21/07/2025 (Inclusive em datetime como Ítalo colocou no Schema) RPS enviado após a alteração XML NFSe novo gerado. TAG gerada vazia Enfim, isso é para ficar o registro de todas essas mudanças. Certamente vai gerar transtornos em nossos clientes que podem não entender porque essas informações agora não estão mais como eram antes. Resta a nós aguardar que essa informação chegue lá na Betha já que os canais de comunicação não são nenhuma "Brastemp" Esses XML's foram obtidos no próprio portal da Betha. Não são do pós processamento do componente ACBrNFSeX Att Adriano

Bom Dia a Todos ! Ainda há problemas no processamento do RPS da Betha em Criciúma 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'. Em princípio o XML está sendo preenchido corretamente. Tentei trocar no xsd para date mas também não resolveu. O erro só ocorre quando é enviado <Parcelas> Alterei o fonte de forma que não fosse validado o schema e o RPS foi processado Foi citado que existe uma forma do schema não ser validado. Não encontrei essa propriedade no componente. É algum parâmetro no .ini ? Obrigado Adriano

De fato... tirando essa data de vencimento o RPS é validado. No caso ele acaba mandando a vista e não preenche a tag <parcelas> Tentei mexer no schema nfse_betha_v01.vsd trocando <xsd:element name="DataVencimento" type="xsd:datetime" minOccurs="0" maxOccurs="1"/> para <xsd:element name="DataVencimento" type="xsd:date" minOccurs="0" maxOccurs="1"/> mas ainda assim o erro na validação persiste. Fica para segunda-feira Um bom final de semana a todos Sim, cocal também tenho uns artifícios inusitados como colocar um certa observação com uns códigos orientados pela prefeitura para que a nota possa ser aceita. Exemplo: Porte: ME / Enquadramento: Variavel, ENQUADRAMENTO: / PORTE. Se não colocar isso na observação, nao passa Pelo visto nunca ouviram falar de tags para tratar esse tipo de coisa

Pior que me parece igual No caso o que estou gerando está a esquerda. O preenchimento das tags me parece igual. Acho que está faltando algo no Schema Att Adriano

Vou fazer o teste. Obrigado

Por fim agora resolveram validar o CNAE. No cliente que eu estava fazendo a emissão em produção tinha essa informação errada no cadastro, repetindo o mesmo código da lista de atividade de serviço. Código : E33 Mensagem: Código CNAE inexistente. Correção: Consulte a legislação vigente para saber o código CNAE que deverá ser informado. No caso apenas apaguei o código errado e passou essa validação

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

Bom dia a todos ! Primeiramente parabéns pela classe desenvolvida. É um XML bem complexo para ser mapeado e de dificil entendimento para nós desenvolvedores por se tratar de um nicho muito específico. Poucas pessoas conseguem nos tirar dúvidas sobre as informações contidas nele. Para melhorar ainda mais a classe, um cliente me reportou que estava importando errado o peso e a quantidade de volumes. O problema tem relação com a quantidade de casas decimais do XML. Os campos que se referenciam ao peso tem 5 casas decimais enquanto a quantidades de volumes é um número inteiro. A confusão com as casas decimais deve ter sido provocado por no XML da DI não exibir o separador decimal dos campos numéricos. O cliente me confirmou que o peso da mercadoria importada via aérea foi de 38kg bruto e 26kg líquido distribuídos em 4 volumes. XML DI No arquivo .\ACBr\Fontes\ACBrDFe\ACBrDI\PCNDI\pcnDIR.pas foram alteradas as seguintes linhas para correção da leitura dos valores 146: tcDec2 para tcDec5 313 e 314: tcDec2 para tcDec5 370: tcDec2 para tcInt Feito as alterações foi importada a informação corretamente Em anexo o fonte corrigido Atenciosamente Adriano pcnDIR.pas

Funcionou perfeitamente.

Bom Dia ! Houve mudança de provedor na cidade de Porto Belo/SC de Betha para IPM no ACBrNFSeXServicos.ini precisa atualizar a informação do provedor na cidade [4213500] Nome=Porto Belo UF=SC Provedor=IPM Obrigado

Apenas para complementar entrei em contato com o suporte questionando esse response da API porque na prática é um erro pois a nota não é incluída e não é uma configuração que dependa de ser feita no sistema. Eles se limitaram a dizer que o tratamento da situação deve ser feita no sistema

Bom dia a todos ! Ao implantar a NFSe em um cliente de uma cidade que utiliza o provedor Bauhaus me deparei com essa situação: Na prefeitura o CNPJ do emissor necessita estar em ambiente de produção quando utiliza o webservice mesmo já tendo emitido NFSe em produção pelo site da prefeitura. O problema é que esse retorno não é vem tratado como um erro, retornando o numero da NFSe que a cada tentativa de envio se incrementa mas não retorna o link de consulta. Se consultar no site ela não existe. O retorno da API é: {"DadosNfse":{"Numero":11,"Competencia":202303,"DataEmissao":"2023-03-02","Mensagem":"ATENÇÃO! AMBIENTE DE TESTE PARA VALIDAÇÃO DE INTEGRAÇÃO."}} Fiz uma alteração na procedure TratarRetornoEmitir no Bauhaus.Provider.pas para tratar essa situação e gerar um erro no retorno do componente. Como não gera um erro não achei uma outra maneira de tratar isso. Foi incluído a parte em azul do código abaixo if Assigned(jNfse) then begin with Response do begin NumeroNota := jNfse.AsString['Numero']; if AnsiPos('AMBIENTE DE TESTE', jNfse.asstring['Mensagem'] ) > 0 then begin Sucesso := false; NumeroNota := ''; AErro := Response.Erros.New; AErro.Codigo := Cod999; AErro.Descricao := ACBrStr(jNfse.asstring['Mensagem']); AErro.Correcao := 'ENTRAR EM CONTATO COM A PREFEITURA PARA PEDIR A MUDANÇA PARA AMBIENTE EM PRODUÇÃO DO CNPJ DO EMISSOR'; end; end; end; Um abraço e bom trabalho Att Adriano Bauhaus.Provider.pas

Boa Tarde ! Fiz a alteração no ACBrNFSeXServicos.ini do provedor da cidade Tijucas/SC de Betha para IPM. A versão utilizada em Tijucas é a IPM 1.01 [4218004] Nome=TijucasACBrNFSeXServicos.ini UF=SC Provedor=IPM

Bom Dia ! Poderiam incluir outra cidade no ACBrNFSeXServicos.ini as informações referentes para emissão na cidade de Tubarão/SC do NFSeX através da Prefeitura Moderna ? [4218707] ; Atualizado em 18/11/2022 Nome=Tubarao UF=SC Provedor=Bauhaus ProRecepcionar=* ProGerarNFSe=https://api-nfse-tubarao-sc.prefeituramoderna.com.br/ws/services/gerar ProConsultarNFSe=https://api-nfse-tubarao-sc.prefeituramoderna.com.br/ws/services/consultar ProCancelarNFSe=https://api-nfse-tubarao-sc.prefeituramoderna.com.br/ws/services/cancelar ProSubstituirNFSe=https://api-nfse-tubarao-sc.prefeituramoderna.com.br/ws/services/substituir Obrigado Att Adriano

Bom Dia ! Poderiam incluir no ACBrNFSeXServicos.ini as informações referentes para emissão na cidade de Içara/SC do NFSeX através da Prefeitura Moderna ? [4207007] ; Atualizado em 18/11/2022 Nome=Icara UF=SC Provedor=Bauhaus ProRecepcionar=* ProGerarNFSe=https://api-nfse-icara-sc.prefeituramoderna.com.br/ws/services/gerar ProConsultarNFSe=https://api-nfse-icara-sc.prefeituramoderna.com.br/ws/services/consultar ProCancelarNFSe=https://api-nfse-icara-sc.prefeituramoderna.com.br/ws/services/cancelar ProSubstituirNFSe=https://api-nfse-icara-sc.prefeituramoderna.com.br/ws/services/substituir Obrigado Att Adriano

Sim svn://svn.code.sf.net/p/acbr/code/trunk2 Vou fazer mais umas tentativas com outros XML de outros provedores e depois posto aqui Att Adriano