Matheus Rossi

Segue anexo o arquivo mensagens.txt, se isso ajudar, mas acredito que possa ser alguma diferenciação entre os comandos AT do componente em relação ao modem talvez? Apesar que pesquisei sobre isso, existe um padrão para esse comandos, que são utilizados por esses modens correto? Se alguém puder ajudar, pois ainda não consegui receber nenhuma mensagem através do componente, mas se coloca o chip em um celular, o app de mensagens SMS recebe normalmente. mensagens.txt

Estou realizando testes em um modem ZTE MF823L, envia mensagens normalmente, mas ao chamar o método ListarMensagens retorna sempre "00 mensage(ns) encontrada(s).", sendo que enviei vários SMS de outros números. Isso em qualquer opção: Todas, Somente Lidas ou Somente Não Lidas. Alguém já passou pelo mesmo problema, mesmo que utilizando outro modem, e conseguiu achar a solução?

Boa noite! Melissa você conseguiu resolver? Estou com a mesma dificuldade...

Boa tarde Italo! Utilizo o Fast. Vou fazer as alterações no componente e assim que tiver pronto posto o fonte. Obrigado!

O arquivo XML de NFSE retornado pelo provedor BETHA, formata o campo Discriminação dos Serviços entre chaves e colchetes, e além do valor atribuído a esse campo ao gerar o RPS, também no retorno é adicionado várias informações entre colchetes como Valor do Unitário, Valor do Serviço, Qtde, sendo assim fica difícil a leitura para maioria dos usuários e clientes. Tem como formatar igual a impressão disponível direto pelo sistema da BETHA (os campos são organizados em uma tabela)? Ou se existir alguma outra forma de deixar esse campo apenas com o que realmente é atribuído ao gerar o RPS.

Boa noite Ítalo! Acredito que o Betha na versão 2.0 (Bethav2) não está totalmente funcional, então segui a orientação que você escreveu em outro post, de utilizar a versão 1.0 (Betha), agora está funcionando perfeitamente. Obrigado pela ajuda.

Boa tarde Ítalo! O arquivo 1-env-lot.xml anexado no início do post, no validador de assinatura da RFB resulta em uma das assinaturas inválida. O arquivo modificado com as assinaturas válidas que você solicitou é exatamente onde não consigo chegar. Mesmo gerando o LOTE assinando somente o RPS, não consegue validar. Nos testes que realizei, o problema não está no conteúdo da TAG SIGNATURE. A assinatura somente não é validada no arquivo XML do LOTE (anexo no começo do post arquivo 1-env-lot.xml), já no arquivo XML do RPS a assinatura é validada corretamente (anexo no começo do post arquivo 3517100629277300017556000000000020001-rps.xml). No momento não faço ideia do que preciso fazer pra resolver, mas vou continuar tentando até achar a solução, qualquer ajuda é muito bem vinda. Obrigado mais uma vez pelo retorno.

Obrigado Ítalo pela atenção. Sua explicação ajudou a esclarecer uma parte do problema, mas ainda continuo tentando entender o por que a assinatura fica inválida no arquivo XML do LOTE, no qual possui as TAGS adicionais <ListaRps>, <LoteRps>, <EnviarLoteRpsEnvio> em relação ao arquivo XML do RPS que por sua vez a assinatura é válida. Esse problema estou até o momento procurando a solução, se tiver outras sugestões agradeço.

Fiz outro teste no validador da RFB removendo as TAGS: <ListaRps> <LoteRps> <EnviarLoteRpsEnvio> A validação ocorreu com sucesso. O que não consigo compreender é por que retirando essas TAGS a assinatura é válida, seria erro de estrutura do XML de LOTE? Comparei essas TAGS (removidas) e está exatamente como especificado no XML de exemplo do provedor Betha. Estou tentando achar o problema, mas se esgotaram as tentativas até o momento. Pesquisei dentro do fórum do ACBR e em outros fóruns, mas sem sucesso em todas as tentativas.

Recentemente comecei utilizar o provedor Betha, mas estou tendo problema na assinatura digital do arquivo XML do LOTE, o retorno do provedor acusa a seguinte falha: Arquivo enviado com erro na assinatura. No XML do RPS a assinatura é validada corretamente. No arquivo XML do LOTE, comparei a TAG SignatureValue e verifiquei que os valores são diferentes quando entre a assinatura do LOTE e o RPS. E quando manda assinar somente o RPS a assinatura do arquivo XML do RPS fica válida e a do arquivo XML do LOTE (referindo-se a mesma assinatura na TAG do RPS) fica inválida. Segue abaixo o link para validar a assinatura dos arquivos que estão em anexo, sendo que um é o arquivo XML do LOTE e o outro o RPS (lembrando que nesses arquivos está habilitado a assinatura do LOTE e do RPS, mas em qualquer situação que manda assinar, o LOTE fica com assinatura inválida e o RPS válida). https://www.receita.fazenda.gov.br/Aplicacoes/SSL/ATBHE/Assinadoc/ValidadorAssinaturas.app/valida.aspx 1-env-lot.xml 3517100629277300017556000000000020001-rps.xml

Também estou passando exatamente pelo mesmo problema com provedor Betha na cidade de Monte Alto/SP. Segue anexo arquivo XML do lote. Em anexo também imagem da validação da assinatura feita no site da RFB, resultando em assinatura válida. 1-env-lot.xml

Boa tarde. Alguém chegou implementar?

Bom dia! Estou com o mesmo problema ao utilizar a impressora MP4200TH via rede, o IP da impressora está informado corretamente, também fiz o teste com todas as opções de página de código e não imprime. Utilizando diretamente a DLL em outras opções do nosso sistema imprime normalmente. Alguém passou pelo mesmo problema e tem alguma sugestão? Agradeço desde já a atenção de todos do fórum.

O problema persiste, deve ser algum erro nos fontes que alimenta os .fr3, não consegui identificar, quem colaborou na implementação do componente pode resolver com certeza. Instalei o componente do Fortes Report, resolveu e funcionou perfeitamente.

Qualquer um dos quatros fr3 disponíveis. Se usar o demo ocorre exatamente o mesmo problema, inclusive no primeiro post esqueci de mencionar que também duplica as linhas, por exemplo, no primeiro boleto sai certo, no próximo vai duplicando as instruções de abatimento, juros, mora, etc e assim sucessivamente até o último boleto. Vou tentar descobrir nos fr3 se tem algo de errado.