Régys Silveira

Desde que os xml estejam sendo gerados corretamente em teoria não. O que ocorre é que se você enviar um xml mal formado ele vai ser barrado no webservice, se o teu app for barrado muitas vezes eles bloqueiam tudo, inclusive os corretos. Existe uma nota técnica explicando isso.

Se está tudo atualizado e coisa de path, uma outra coisa pode ser que o arquivo esteja em conflito, verifique se todos os arquivos estão marcados com o tick verde, se não tem algum conflito e o tortoise não atualizou, dai pode ocorrer isso ai.

Tente reduzir o valor da propriedade IntervaloAposComando, isso pode ajudar.

a UF do emitente e PR tem certeza que está utilizando o webservice do PR?

Blza já foi atualizado sim.

é claro que o atendimento de MG vai negar até a alma que não foi culpa deles. hehe

Ou seu ACBr está desatualizado o arquivo ACBrUtil.pas, ou você tem dois ACBr na mesma máquina.

Não, ele vai querer o arquivo do paf que tem as movimentações do ECF no período, somente isso.

Ele sempre vai incrementar o contador, mas sua dúvida é quanto ao valor ou contador?

Como te expliquei antes a consulta é feita baseado na UF que você configura no Monitor, se tentar checar chaves de outros estados realmente vai dar o erro.

Os XMLs apenas atulizam as verificações, não tendo nada a ver com a codificação o componente, caso você tenha feito alguma alteração no componente, favor submeter aqui no forum para avaliarmos e disponibilizarmos.

Sim é isso mesmo, sempre que é gerado um XML quando validado ele é submetido aos schemas que regem as validações, isso evita que o webservice recebe XMLs mal formados ou com informações fora do padrão.

A sim, o NFeMonitor vai consultar com base nos teus dados, procurando no webservice do estado configurado no monitor. Provavelmente é por isso que ela retorna que não está na base. Para fazer como você quer ai só fazendo mesmo a consulta pelo site, fazendo a consulta diretamente ao webservice pela sua linguagem ou utilizando um projeto externo para isso.

Então, aqui está normal, a coisa está nos teus conflitos, você deve mecheu nos arquivos que deram conflito e o SVN está esperando você resolvê-los. Faça o seguinte tente atualizar novamente, vai mostrar os conflitos, clique com o botão direito em cada um deles e clique em "Resolve with theirs". Ou exclua os arquivos que deram conflito e depois de excluídos faça novamente a atualização. Sempre que alterar algum arquivo você tem que resolver o conflito, porque senão o SVN vai manter o arquivo anterior e vai dar erros, como está acontecendo contigo.

Você está utilizando o componente correto, ou está utilizando o ACBrNFe?

Efetuei os testes de compilação geral aqui e esta tudo OK. Precisamos de mais informações, qual o arquivo que você tenta abrir ao dar o erro?

Você precisa programar primeiro, veja no exemplo como fazer isso.

Você pode utilizar o comprovante não fiscal, veja o exemplo de como fazê-lo no ECFTeste.

No ambiente de produção está funcionando, o negócio parece ser somente para a homologação. Meus cliente já foram atualizados e está tudo funcionando ok. Como sempre parece que o "estagiário" esquecer de setar o servidor de homologação, hehe.

eles liberaram um pacote novo corrigindo o EAN na sexta-feira se não me engano.

Com certeza sim, basta ler a ER e ver nos exemplos, o ACBr implementa componentes e métodos para praticamente tudo que existe nela.

Baixe o projeto e veja dentro da pasta exemplos, temos demos explicativos para cada componente.

Atualizou os schemas para os últimos liberados no site do portal da nf-e?

A imagem que você anexou está muito desfocada, não tem como ver nada.

Copie o erro do compilador ou a tela com um printscreen para ver melhor o que está acontecendo. Quanto ao midas.dll você registrou o que está na pasta system32 e windows? Estas duas pastas estão dentro da variável PATH do windows, por padrão elas devem estar, mas existem softwares que sobrescrevem o path e bagunçam tudo?