Italo Giurizzato Junior

Boa tarde @João Antônio, Já esta no SVN.

Boa tarde @João Carlos Gielow, Noite 2 coisas: 1. As URLs de homologação são as mesmas de produção e o provedor Betha não tem uma tag no XML que define se a nota esta sendo enviada para o ambiente de homologação ou de produção. 2. Essas URLs estão muito diferentes de outras cidades que são atendidas pelo provedor Betha versão 2.02, veja: [1301852] ; Incluído em 13/03/2023 Nome=Iranduba UF=AM Provedor=Betha Versao=2.02 ProRecepcionar=http://e-gov.betha.com.br/e-nota-contribuinte-ws/nfseWS HomRecepcionar=http://e-gov.betha.com.br/e-nota-contribuinte-test-ws/nfseWS Praticamente todas as cidades que se utilizam o provedor Betha versão 2.02 usam as mesmas URLs da cidade de Iranduba/AM. Por favor verifique isso.

Boa tarde @João Antônio, Muito obrigado pela colaboração, já foi criado a TK-7329 para realizar a alteração.

Boa tarde @Vitor Barbieri, Assim que você tiver as units escritas por favor anexe aqui para que possamos validar e enviar para o SVN, bem como as cidades atendidas por esse provedor.

Boa tarde @prismars, Fiz um teste usando o programa exemplo com os seus XML. Usei o botão Validar XML para testar a carga do XML e sua validação. Em ambos a carga do XML ocorreu com sucesso e os mesmos são validos. Acredito o seu problema seja configuração do componente, alguma configuração esta errada e com isso provocando esse erro.

Bom dia @Marcos Pereda, Acredito que não seja possível. Vamos ter que mudar isso, ou tornar essa propriedade uma propriedade de configuração ou incluir ela na leitura do arquivo INI. Vamos estudar a melhor solução para este caso. Já foi criado a TK-7322 para analise e modificações.

Bom dia @lucasatz, Veja como esta o campo Discriminação: <Discriminacao>[[Descricao=MAO DE OBRA;;VENCIMENTO: 02/08/2025 30,00;;Inscricao estadual tomador: ISENTO;;OBS: S.S. 2QLWQT/10KARDIANPLACA: TDD-8A8120.432 KM][Quantidade=1.0000][ValorUnitario=30,0000][Deducoes=0,00][Descontocondicionado=0,00][DescontoIncondicionado=0,00]]</Discriminacao> <CodigoMunicipio>4204004</CodigoMunicipio> Não seria o caso de trocar a virgula por ponto nos valores?

Bom dia @lucasatz, Não seria melhor implementar esse novo campo para ser utilizado na consulta, mas em vez de alterar o método ConsultarNFSePorRps incluindo um novo campo só para atender esse provedor, usarmos o ConsultarNFSeGenerico?

Boa noite @nenelvida, Já esta no SVN.

Boa noite @Bochnia, Já esta no SVN.

Boa noite @Márcio Baroni, Já esta no SVN a correção.

Boa noite @Anderson Grolli, Já esta no SVN.

Boa noite @Anderson Grolli, Já esta no SVN.

Boa noite @Anderson Grolli, Já esta no SVN.

Boa noite @Anderson Grolli, Já esta no SVN.

Boa noite @willian_delan, Já esta no SVN.

Boa noite @flaviorealtec, Já esta no SVN.

Boa tarde @Desenvolvimento.microline, Na seção Valores, troque o ponto pela virgula em todos os campos, exemplo: de [Valores] ValorServicos=85.00 para [Valores] ValorServicos=85,00 Faça novos testes.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia @Vitor Barbieri, A primeira coisa a saber sobre esse novo provedor é: qual layout ele utiliza (versão 1 da ABRASF, versão 2 ou layout próprio)? Se ele utiliza a versão 1 ou 2 note que temos modelos das units que são necessárias serem criadas. Esses modelos estão na pasta: ...\Fontes\ACBrDFe\ACBrNFSeX\Modelos. Você vai copiar e renomear esses arquivos para: BWSistemas.GravarXml, BWSistemas.LerXml e BWSistemas.Provider Esses 3 arquivos tem que ficar dentro da pasta: ...\Fontes\ACBrDFe\ACBrNFSeX\Provedores Vai ser necessário criar um enumerado para esse provedor (proBWSistemas) na unit ACBrNFSeXConversao. Incluir a chamada ao novo provedor na unit ACBrNFSeXProviderManager com é feito com os demais provedores. Agora se o provedor se utiliza de um layout próprio, tem que ver se ele trabalha com XML ou Json e ai você vai pegar dentro da pasta que consta os arquivos dos provedores (...\Fontes\ACBrDFe\ACBrNFSeX\Provedores) e pegar um provedor de modelo para escrever as units do novo provedor. Em resumo: Criar o enumerado em: ACBrNFSeXConversao Incluir a chamada em: ACBrNFSeXProviderManager Escrever as units: BWSistemas.GravarXml, BWSistemas.LerXml e BWSistemas.Provider (ser o provedor trabalha com Json em vez de GravarXml é GravarJson, LerXml é LerJson). Quanto ao cancelamento se o provedor segue o layout da ABRASF as rotinas estão nas units: ACBrNFSeXProviderABRASFv1 e ACBrNFSeXProviderABRASFv2, se o provedor trabalha com layout próprio a rotina de cancelamento vai ser escrita na unit: BWSistemas.Provider. Espero ter ajudado. Assim que estiver pronto, por favor anexe as units aqui nesse mesmo tópico para que possamos validar e enviar para o SVN. Desde de já muito obrigado pela colaboração.

SEFAZ Virtual RS 04/07/2025 Urgente – Número de protocolo com 17 caracteres na SVRS O retorno de 17 caracteres para o número de protocolo será adotado pela SEFAZ-SP, futuramente (ainda sem previsão), devido ao alto volume de emissão de NFC-e por ano, conforme previsto na Nota Técnica 2025.002 (NT da Reforma Tributária). Equivocadamente, esse retorno entrou em produção para a Sefaz Virtual do Rio Grande do Sul (SVRS) hoje (04/07/2025, entre 13h39 e 14h45), afetando a informação da autorização de uso para parte dos sistemas ERP. A SVRS já fez a correção no WebService de “Consulta Situação” para retornar o número do protocolo com 15 caracteres. Assim, a solução para as NF-e emitidas no horário supracitado é realizar novamente a consulta dos números de protocolo, retornando com o número de 15 caracteres. Sobre o evento de cancelamento, nas próximas horas, será liberada a versão aceitando o pedido de cancelamento com o número do protocolo contendo 15 ou 17 caracteres, considerando que muitas empresas internalizaram o protocolo com 17 caracteres. Contamos com a compreensão de todos. Orientação da Equipe ACBr: Atenção Pessoal, quem guarda no banco de dados o numero do protocolo de autorização do DF-e bem como o numero de autorização dos eventos, deverá realizar uma alteração de tamanho nas tabelas que guardam o numero do protocolo, alterando o tamanho de 15 para 17, não esqueçam de fazer isso.

Coordenação Técnica do ENCAT 04/07/2025 Conformidade Fácil - Validador RTC Encontra-se disponível no portal da SVRS a nova funcionalidade do Projeto Conformidade Fácil: o validador das notas técnicas da Reforma Tributária do Consumo. Nesta transação, qualquer empresa ou integradora de software poderá informar a parte do XML com os campos da tributação apresentados nas notas técnicas da RTC ou mesmo colar o XML completo de um documento fiscal eletrônico e validar se a informação está em conformidade com as regras de validação descritas nas notas técnicas. O componente de validação é o mesmo que é utilizado pelo ambiente de autorização da SEFAZ Virtual, e tem a capacidade de responder se o XML apresentado está correto em relação a qualquer uma das regras previstas nas NTs. A primeira versão atende aos documentos CTe, BPe, NF3e e NFCom, mas muito em breve estará contemplando NFe e NFCe. A etapa 3 prevê a criação de um gerador de XML da reforma tributária e deve ser implantada ainda no mês de Julho. Acesso a ferramenta: https://dfe-portal.svrs.rs.gov.br/Dfe/ValidadorRTC

Boa noite @aslsoftwareltda, Já esta no SVN.

Boa noite @João Antônio, Já esta no SVN.

Boa noite @Anderson Grolli, Já esta no SVN.