Italo Giurizzato Junior

Boa tarde Juliano, Existe um campo chamado OutrasInformacoes, mas ele faz parte do layout da NFS-e e não do RPS. Lembre-se que o componente gera o XML do RPS e envia para o webservice e este processa e se estiver tudo OK retorna o XML da NFS-e. Sendo assim o campo: OutroasInformacoes só é gerado pelo webservice com informações, provavelmente definidas pela prefeitura. Vale lembrar que nos Documentos Auxiliares como por exemplo: DANFE, DACTE, DANFSE, etc só deve constar informações que constam no XML. Espero ter ajudado.

Alessandro, Você tem os schemas da nova consulta e do download para poder validar o XML antes do seu envio?

Boa tarde Fabio, Quem passou essa informação que é a empresa de medicina do trabalha que tem que gerar os eventos e enviar? Eu não tenho muito conhecimento sobre o e-social, mas se é essa empresa que realmente tem que enviar, acredito que ela vai ter que ter uma procuração eletrônica de cada cliente dela para que ela possa usar o certificado dela para enviar os eventos, sendo assim basta somente o certificado da empresa de medicina do trabalho. Não sei se ficou claro.

Haroldo, Quais funções necessárias e em qual Units se faz necessário para funcionar utilizando o componente?

Boa tarde, Você esta com todos os fontes de todas as pastas atualizados?

Boa tarde Julio, Muito obrigado pela colaboração, tive que fazer uma correção você misturou os códigos IBGE das cidades guatambu e Guarapuava. Ainda hoje estarei enviando para o repositório.

Amaro, Ainda hoje vou disponibilizar uma alteração, quem sabe resolve o problema.

Boa tarde Haroldo, Desculpe mas não entendi o porque dos arquivos do Megasoft. Quanto ao provedor RLZ seria interessante você testar o que foi implementado e caso tenha alguma coisa errada e puder nos ajudar com a correção ficarei grato.

Boa tarde Marcos, Altere o arquivo INI do provedor para: [RetornoNFSe] Texto1=<listaNfs xmlns="https://www.esnfs.com.br/xsd">%DadosNFSe%</listaNfs>

Boa tarde Marcos, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Alexandro, Como as informações sobre o serviço consta no XML?

Boa tarde Amaro, Somente a tag referente a data de vencimento ocorre o erro ao ler o XML?

Boa tarde Alessandro, Anexa o XML (soap) de envio e de retorno desse ultimo teste.

Bom dia Márcio, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Amaro, O tipo tcDatHor (que já existe) não resolveria o problema?

Bom dia, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Arce, A versão 2.5 entra em vigor quando? É preciso compatibilizar o programa exemplo com essas mudanças.

Bom dia Bruno, Note que no retorno (*-can.xml) temos a confirmação do cancelamento. É preciso verificar da onde esta vindo essas mensagens de erro. Acredito eu que a origem é da consulta que é realizada em seguida para obter o XML da nota com o grupo referente ao cancelamento. Verifique se fora esses 4 XML se não foi gerado mais 4 XML referente ao pedido de consulta e o seu respectivo retorno.

Bom dia, Muito obrigado pela contribuição, ainda hoje estarei enviando para o repositório.

Bom dia a todos, Fizeram testes usando o programa exemplo do componente ACBrReinf?

Bom dia Alessandro, Favor atualizar os fontes e faça novos testes.

Bom dia, No envio Síncrono, no retorno já temos o resultado do processamento. Lembrando que nesse modo só podemos enviar somente uma nota por vez. Já no envio assíncrono, o que temos no retorno é o recibo que atesta que o webservice recebeu o nosso lote de notas, sendo assim se faz necessário uma consulta pelo recibo para saber o resultado do processamento do referido lote. No modo assíncrono o lote pode ter até 50 notas. Com relação ao tempo é preciso verificar como esta a configuração do Monitor. Tenha em mente o seguinte: No modo síncrono, o XML é gerado, assinado, validado, enviado para SEFAZ, esta o processa e retorna o resultado, se foi autorizado, o XML é atualizado, ficando agora assinado e protocolado, portanto com validade jurídica. No modo assíncrono, o XML é gerado, assinado, validado, enviado para SEFAZ, esta retorna o numero do recibo de entrega do lote, uma consulta pelo recibo é feita, a SEFAZ retorna se o lote ainda esta em processamento ou não, se ainda estiver uma nova consulta é feita, se já foi processado e autorizado o XML é atualizado, ficando assinado e protocolado. Podemos definir um tempo de espera entre o envio e a primeira consulta, podemos definir quantas consultas serão realizadas e também o tempo de espera entre uma consulta e outra. Supondo que você tenha definido 5 segundos e para obter o resultado final foi necessário realizar 5 consultas. Temos 5 segundos antes da primeira consulta, mas 5 segundos entre cada consulta, temos no total 25 segundos.

Boa tarde Ramalho, O erro que esta ocorrendo significa que o seu XML não esta correto, deve estar faltando tag, ou tag com grafia errada, etc. Vou ser sincero com você, esquece a sua rotina de gerar o XML e use o componente por completo. Garanto a você que a sua aplicação vai ficar pronta antes do esperado. O tempo que você esta perdendo em fazer a rotina para gerar o XML e depois descobrir porque o XML esta invalido, você já teria feito a rotina para alimentar o componente com os dados pertinentes ao evento (no programa exemplo existe uma para cada evento) e testado o seu envio.

Boa tarde, Favor anexar também o XML de pedido de evento referente ao cancelamento gerado pelo Monitor.

João, Então eu acho que deve ser algum problema no webservice do Reinf.