BigWings

Fiz teste pelo demo e a consulta funcionou normalmente: Por favor descreva melhor o problema com o retorno da consulta e seu ambiente de desenvolvimento e testes.

Provavelmente é o mesmo problema, a configuração incorreta da propriedade VersaoDF do componente. Se estiver ve200 vai causar esse erro.

Tem razão, alterei apenas as da SVRS, RS usa um webservice diferente. Aguarde que... Aparentemente ainda não estão validando a URL em produção, mas deve mudar também, está sendo verificado se a alteração caso feita agora em produção não vai causar problemas.

Bastava atualizar, o ACBrNFeServicos.res já está atualizado no repositório. Então faça o revert pelo Tortoise, depois reinstale o ACBr usando o ACBrInstall_Trunk2.exe, depois recompile a sua aplicação e teste. Também veja se não deixou um arquivo ACBrNFeServicos.ini desatualizado no diretório da aplicação. Não houve alteração nesse grupo, os endereços de consulta são diferentes por UF, em cada grupo [NFCe_XX_H] onde XX é a UF.

Aparentemente foi identificado o problema. Enviei correção para o repositório, rev. 16943. Seria de grande ajuda se todos pudessem atualizar os fontes e realizar os testes.

Se você já tem a URL correta basta fazer a alteração no ACBrNFeServicos.ini e testar. Se a NFCe for autorizada com a nova URL anexe o arquivo aqui para ser enviado ao repositório.

O token requerido pela API não é token fornecido pela SEFAZ, você precisa fazer o cadastro da empresa no site https://deolhonoimposto.ibpt.org.br/ para obter ele.

O bloco K já está implementado no ACBrSpedFiscal.

Provavelmente é falta de atualização das cadeias de certificado. Verifique o link abaixo: http://www.sefaz.am.gov.br/noticias/ExibeNoticia.asp?codnoticia=18328

Na minha interpretação houve somente substituição da regra de validação N33-10 pelas regras N12-82 (CST 60) e N12a-60 (CSOSN 500). Então cada UF pode ativar a regra para CST 60 e não para 500 e vice versa, ou nenhuma ou ambas...

O componente não faz nenhuma crítica quando a modalidade de frete na geração dos dados do transportador, basta que esses dados sejam informados.

Sim, correto. Provavelmente houve, o projeto ACBrMonitorConsole realmente tem erro de compilação.

Que saiba esse projeto não está utilizável. Consegue compilar o projeto ACBrMonitorPLUS.lpi?

Geralmente esse erro é por incompatibilidade de arquitetura entre o exe e as DLLs. Então verifique se está copiando as DLLs corretas, 32 ou 64 bits, de acordo com a arquitetura do seu executável. Também verifique se está copiando para a pasta correta, de preferência para a pasta do executável para evitar conflito com outras aplicações. Se copiar para a pasta do sistema, use: - DLLs de 32 bits em Windows 32 bits: C:\Windows\system32 - DLLs de 32 bits em Windows 64 bits: C:\Windows\SysWOW64 - DLLs de 64 bits em Windows 64 bits: C:\Windows\system32

Experimente trocar o trecho acima para: ACBrNFe1.WebServices.Retorno.Recibo := ACBrNFe1.WebServices.Enviar.Recibo; ACBrNFe1.WebServices.Retorno.Executar; Ou você pode simplesmente usar o método ACBrNFe1.Enviar(nLote, bImprimir, bSincrono) que faz todo o processo.

Veja pelo debug como está a propriedade ACBrNFe1.Configuracoes.WebServices.Ambiente no momento do envio do evento.

Essa nota técnica e todas as outras você encontra no portal da NFe: http://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=tW+YMyk/50s=

O erro no tópico é de validação local então o ambiente de envio não faz diferença. A não ser que esteja tendo um erro diferente, nesse caso sugiro procurar outro tópico (tem vários já abertos de erros de rejeição por falha de schema) ou abrir um novo.

Veja que está enviando em homologação e não produção.

Não. Na NFe 4.00 foram alterados os valores para o campo modFrete, veja a NT 2016.002 v1.61:

Vejo que o XML mudou após a configuração, não está mais sendo gerada a tag vICMSSubstituto. A rejeição agora provavelmente é por causa da tag pST, tente informar ela zerada.

Anexe o XML gerado.