Marco Moreira

Obrigado pela resposta.

Bom dia, Desculpem a liberdade de reabrir um assunto que já teve várias iterações no fórum sobre o tópico de endereços de schemas com caminho UNC. Contudo são antigos e gostaria de saber se tem alguma novidade sobre; Estou migrando alguns módulos do nosso ERP para o ACBr... Já estou usando o ACBR no NFSe, REINF, GNRe e agora o MDFe. Porém no MDFe estou tendo problemas com os schemas em rede, o que não tive nos outros componentes... já vi no fórum que a solução é deixar os arquivos no local da aplicação ou mapear a unidade. Peço a gentileza que deem uma olhada no print em anexo... E aí vem meu questionamento que o ModalEhValido consegue validar usando XSD e o MDFeEhValida não... Não entendi, como um valida e outro não, já que todos os arquivos XSD estão no mesmo diretório... debugando as funções envolvidas para resolver o endereço, retornam corretamente o nome do arquivo completo... Em resumo só queria saber se tem alguma informação adicional, já que eu não consegui identificar debugando o momento do erro, antes de eu apenas seguir a instrução de mapear a rede ou resolver o diretório da aplicação... Obrigado

Bom dia, Foi disponibilizado o manual com novo leiaute 1.05 da Reinf em http://sped.rfb.gov.br/arquivo/show/5690; Fiz alguns ajustes nos enumeradores do componente para gerar nessa nova versão, mas não desenvolvi a criação do novo evento R-2055, pois não temos essa demanda nos clientes. Mas com essas alterações já é possível a compatibilização com o novo leiaute. Pra variar, ainda não disponibilizaram as novas regras para teste. No teste que fiz em ambiente restrito recebi o erro: MS0092 - Versão do lote inválida. Deve ser utilizada a versão 1.04.00. Segue em Anexo para avaliação a documentação baixada do SEFAZ e os fontes alterados do componente. Leiautes da EFD-Reinf versão 1.5.pdf Pacote XSD Comunicação EFD Reinf v1_05_00.zip Pacote XSD Eventos EFD Reinf v1_05_00.zip pcnConversaoReinf.pas pcnReinfR2099.pas

Boa tarde, Os nossos clientes, que fazem a manifestação, conseguem receber apenas o xml reduzido. Em algumas tentativas recebem também erros de HTTP 503 (indisponibilidade) e de timeout 12002.

Boa tarde, Como relatei acima, aleatoriamente, com configurações que em alguns envios funciona, dá erro em outros. Abaixo print onde simulo várias Guias em fila... sendo enviadas... em uma das gerações tive o erro relatado... Pois na primeira consulta de retorno, recebe 0, sendo assim, não executa as outras tentativas configuradas.

Boa tarde, Neste ponto gera um exceção; Pois na primeira tentativa, onde o arquivo de retorno está apenas com o recibo e por consequência código 0, já gera erro, não executando as tentativas configuradas; Permitindo o código zero que retorna na primeira tentativa, vai continuar o loop para novas consultas...

Boa tarde, Outro tópico com o mesmo problema.

Boa tarde, Durante implementação, em meus testes, recebia aleatoriamente uma exceção vazia. Mesmo problema relatado nos tópicos: Pelo que entendi, dependendo do parâmetro de aguardar para consultar ou gargalo no ambiente do SEFAZ, o componente não recebe nenhum código, o arquivo retorna apenas o numero de protocolo, sem a tags <ns1:situacaoProcess> e com isso, não chega a executar o loop de tentativas gerando uma exceção vazia. Em anexo a correção em ACBrGNREWebServices.pas ACBrGNREWebServices.pas

Boa Tarde, Fiz nova implementação para a questão do Cnpj não sair na impressão da guia do Fortes. Mantive a alteração acima sobre a informacoesComplementares; ACBrGNREGuiasRetorno.pas

Bom dia! Alterei minhas configurações do certificado e comecei a receber esse erro... Aparentemente funciona apenas com as configurações da xsMsXmlCapicom... Conseguiu resolver usando a xsLibXml2 ?

Bom dia, A cidade de Novo Hamburgo, provedor ISSNet, está exigindo o motivo/Justificativa do cancelamento das NFSe, mas mesmo sendo informado na aplicação, o XML não estava levando a Tag e com isso os cancelamentos estão sendo indeferidos pelo fisco... Após análise verifiquei que as condições para geração da TAG para o provedor estavam comentadas.... Após alterar, os cancelamentos foram deferidos pela prefeitura. Segue print do diff e fonte alterado para análise. Obrigado. pnfsNFSeG.pas

Bom dia, Ontem fiz os testes novamente dos eventos da REINF e obtive as respostas esperadas do SEFAZ. Aparentemente está funcionando novamente as consultas de fechamento no ambiente de homologação. Parabéns ao pessoal que contribui com o projeto ACBR pelo ótimo componente desenvolvido e obrigado a todos que responderam esse post!

Boa tarde, Conforme o print abaixo, isso foi a ultima alteração que teve no projeto. Será que colocaram o ambiente de homologação em uma versão antiga? Não pode ser...

Boa tarde, Pois é, esqueci de mencionar que os meus testes foram sempre em produção restrita... Será que alguém tem o contato para abrir um protocolo disso junto ao órgão responsável? Dei uma olhada no site e não encontrei...

Bom dia, Fiz um teste com o programa exemplo e retornou o mesmo erro... Alguém está conseguindo consultar o protocolo?

Buenas, Obrigado por responder, já estava ficando preocupado... Então vamos aguardar.

Bom dia, Estou homologando os fechamentos e reaberturas no sistema, mas hoje comecei a receber o erro MS0008-Parâmetro Protocolo de Fechamento obrigatório não informado ao tentar consultar o R-2099; O protocolo esta salvo, e debugando esta sendo passado ao método de ACBrReinf.Consultar(); Estranho q sexta-feira estava ok. Alguém esta com problema tb?