Italo Giurizzato Junior

Joabe, Pelo que vi a URL esta correta. Desculpa mas não entendi: " Já consutando pela url dentro do cdata abre a nota normalmente na sefaz , mas pelo sistema da esse erro " A nota não foi rejeitada? Como ela esta aparecendo normalmente no site da SEFAZ?

Boa tarde a todos, Joabe no caso de MT o componente esta usando o seguinte endereço: http://www.sefaz.mt.gov.br/nfce/consultanfce Fernando no caso de RS é: https://www.sefaz.rs.gov.br/NFCE/NFCE-COM.aspx Ambos ambiente de produção. Agora é preciso saber junto a SEFAZ qual é o endereço correto, para que possamos fazer as devidas correções.

Boa tarde Daniel, Favor atualizar os fontes e testar novamente.

Bom dia, Primeiramente peço para que não post como texto fragmentos de códigos ou arquivos e sim post como anexo. Se para deixar mais claro o problema coloque somente a TAG em questão. Segundo, a validação não altera o XML apenas o submete ao validador. Terceiro, não sei qual é o seu código, mas vai ai uma dica que pode resolver o problema: AlimentarComponente; <== Procedure definida em sua aplicação que tem por finalidade alimentar o componente com os dados pertinentes ao MDF-e que vai ser gerado. ACBrMDFe.Manifestos.Assinar; ACBrMDFe.Manifestos.Validar;

O componente não faz calculo e não busca nada em lugar algum. Você que tem que passar mastigado as informações para o componente.

Bom dia Lauro, Quando fiz os testes e alterações no componente ACBrNFSe, usei o provedor Ginfes. O provedor Ginfes não possui em seu Web Services as funcionalidades: GerarNFSe, EnviarLoteRpsSincrono e SubstituirNFSe. Outro detalhe importante é que o Ginfes requer que somente o RPS seja assinado o Lote não. Por outro lado o provedor SystemPro segundo a Unit que foi criada para ele (Trunk) só tínhamos as funcionalidades: ConsultarNFSe, CancelarNFSe e GerarNFSe. Como os testes que fiz foi usando o Ginfes e este não possui o GerarNFSe essa funcionalidade não foi testada, logo pode conter erros. Esta semana vou checar essa funcionalidade e tentar corrigir os erros que eu conseguir identificar.

Bom dia Marcelo, Sei que o link se refere a NF-e mas o problema é o mesmo. A cidade de Pindamonhangaba utiliza o provedor Ginfes. Quando eu realizei testes para corrigir erros visando a migração do componente ACBrNFSe para o Trunk2 o provedor utilizado foi justamente o Ginfes. Dentro da pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI encontra-se o arquivo Ginfes.INI mais atual. Recomendo que você faça uma atualização de todos os fontes de todas as pastas e realize novos testes. Observação: os testes que realizei foi com o componente configurado como Capicom.

Bom dia Dércio, Os componentes ACBrNFe, ACBrCTe, ACBrMDFe e ACBrNFSe se utilizam das classes definidas em ACBrDFe. Logo a função Assinar utilizada pelos 4 componentes é a mesma. Temos duas função Assinar, uma para o Capicom e outra para o OpenSSL. O problema é que alguns provedores requerem que tanto o RPS quanto o Lote sejam assinados e quando a função Assinar é chamada para assinar o Lote ela detecta que o XML esta assinado ( assinatura do RPS ) logo não assina o Lote. Como dito essas duas funções (Capicom e OpenSSL) ão utilizadas pelos demais componentes, sendo assim as alterações nelas devem ser cercadas de cuidados para não gerar efeito colateral. Já promovi algumas alterações no Assinar do Capicom e segundo os meus testes consegui um Lote assinado com RPS também assinado. É preciso fazer o mesmo com o OpenSSL e realizar testes com os demais componentes para detectar eventuais efeitos colaterais.

Bom dia Marcelo, O erro: Suporte de Canais Seguro tem haver com o certificado. Alguns certificados não são suportados pelo Capicom e OpenSSL sendo preciso fazer uma exportação do mesmo para que fique compatível. Qual certificado você esta usando e o componente esta configurado para utilizar o Capicom ou OpenSLL?

Bom dia Lauro, A forma correta é: ACBrNFe.DistribuicaoDFe( nEstado, sCNPJ, sUltNSU, '' ); Onde: nEstado é o código da UF do destinatário, ou seja quem esta fazendo a consulta; sCNPJ é o CNPJ do destinatário; sUltNSU se refere ao último NSU retornado na última consulta, se tratando da primeira consulta devemos informar '0'. O quarto parâmetro devemos informar uma string vazia. Para mais detalhes sobre o terceiro e quarto parâmetro desse método favor consultar o manual do ACBrNFe que encontra-se dentro da pasta: ...\Doctos\Manuais

Bom dia Rubens, Se você se refere ao ACBrNFeMonitor, a resposta é: não será alterado para atender as novas Notas Técnicas. Motivo: O ACBrNFeMonitor se utiliza dos componentes do repositório Trunk por outro lado o ACBrMonitor Plus se utiliza dos componentes do repositório Trunk2. Já faz uns 6 meses que a equipe ACBr não faz mais alterações, correções ou melhorias nos componentes do Trunk, somente Trunk2. Para quem programa em Delphi já passou da hora de migrar para o Trunk2. Para quem se utiliza do Monitor também já passou da hora de migrar para o ACBrMonitor Plus.

Bom dia a todos, Retificação: é a TAG pICMSInter que segundo os novos schemas devemos informar com somente 2 casas decimais e os valores aceitos são: 4.00, 7.00 ou 12.00. Portanto Ivan o seu XML esta errado, pois você informou 18.00 em pICMSInter. Fernando, no seu XML você esta informando "Normal" para indFinal (Indica operação com Consumidor Final) altere para "Consumidor Final" e tente novamente.

Bom dia, Sendo assim, sugiro você manter todos os fontes de todas as pastas atualizados diariamente. Quanto a TAG CEST ela já esta implementada no componente a um bom tempo, assim que a Nota Técnica foi publicada nós atualizamos o componente com o acréscimo dessa TAG. Para alimenta-la basta: Prod.CEST := <informar aqui o CEST do produto>; Espero ter ajudado.

Bom dia Cláudio, Exatamente, agora o DACTE esta disponível em Fast e Fortes Report.

Boa tarde Ivan, Os seus Schemas não estão atualizados, pois se estivessem a sua nota não seria validada. Conforme os novos schemas o percentual de pICMSUFDest tem que ter no máximo 2 casas decimais e o seu XML contem 4 casas.

Boa tarde João, Entendi, vou verificar.

Boa tarde, O que você quer dizer com: atualizar no meu sistema ? Você programa em Delphi ? Usa o componente ACBrNFe ? Já esta usando os fontes do Trunk2 ?

Boa tarde Carlos, Se o seu evento é rejeitado acusando que o tpEvento informado é invalido, isso significa que a SEFAZ ainda não implementou esse evento. É preciso entrar em contato com a SEFAZ para saber uma posição deles quanto a esse evento.

Boa tarde Rodrigo, Você deve atualizar todos os fontes de todas as pastas diariamente. Pois a qualquer momento podemos enviar para o repositório uma correção, melhoria ou adição de algo novo. Por exemplo a uns 10 minutos enviei para o repositório novos Schemas de eventos de pedido de prorrogação de remessa para industrialização.

Boa tarde Cadilo, Note que no XML que ocorre o erro ao tentar ler o seu conteúdo da versão esta entre apostrofe e não entre apas conforme é orientado pelos manuais e notas técnicas. Consta: versao='3.10' em vez de versao="3.10" Bem como os conteúdos dos atributos xmlns (namespace). Segundo o Manual versão 5.0 da NF-e página 13 o item 3.2.1.2 trata sobre a declaração de namespace: O documento XML deverá ter uma única declaração de namespace no elemento raiz do documento com o seguinte padrão: <enviNFe xmlns=”http://www.portalfiscal.inf.br/nfe”> (exemplo para o XML de envio de Lote de NF-e) E o arquivo que ocorre o erro tem 3 namespace portanto esta fora do padrão.

Cardilo, Pode até ser, mas faça um teste, edit esse XML removendo o que tem a mais e tenta ler ele novamente.

Nilton, Alterar o Layout padrão do ACBr é muito mais fácil para contemplar uma nova TAG, você não concorda? Agora alterar o Layout da Secretaria é mais complicado principalmente quando esta ainda não divulgou o novo Layout contemplando a nova TAG. Se você possui esse novo Layout vai nos ajudar em muito essa alteração. Observação: em nenhum momento eu disse que o ACBrMonitor Plus só vai atender somente um Layout. Eu apenas lhe sugeri que mudasse, pois todos os que o utilizam o Layout padrão do ACBr já podem testar em ambiente de homologação as novas TAGs.

Bom dia, A sua aplicação que precisa fazer esse controle.

Bom dia Cardilo, O problema é que a TAG nfeProc gerada pela SEFAZ quando baixamos o XML pelo Site, não segue o padrão, logo ocorre esse problema. Ela tem ter apenas dois atributos: versao e xmlns conforme exemplo abaixo: <nfeProc versao="3.10" xmlns="http://www.portalfiscal.inf.br/nfe"> e não isso: <nfeProc xmlns="http://www.portalfiscal.inf.br/nfe" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.portalfiscal.inf.br/nfe procNFe_v3.10.xsd" versao="3.10">

Bom dia Wilson, Primeiro a TAG CEST é opcional, logo se você não alimentar a propriedade CEST a TAG não será gerada no XML. Segundo, essa TAG deve ser informada quando a venda é interestadual para um consumidor final. Terceiro, se mesmo assim a TAG não for gerada, o que vai ocorrer? Simples, como a regra que valida essa informação na SEFAZ não vai ser implantada amanhã (01/12/2015) e sim em uma data futura, a nota vai ser autorizada. Mas o quanto mais rápido você fazer com que a nota tenha essa informação melhor, pois quando a SEFAZ começar a validar os seus clientes não vão ter problemas.