Italo Giurizzato Junior

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.

Bom dia Márcio, Você mesmo pode criar um para o provedor ProData se baseando nos demais e pegando as informações da Unit do respectivo provedor. Só tem um problema, esse provedor requer que o RPS e o Lote seja assinado e como já foi dito aqui em vários outras postagens o componente ainda não esta realizando a assinatura do Lote quando o RPS esta assinado.

Bom dia João, Por favor anexe a Unit alterada. Quanto a consulta é interessante configurar o componente para salvar os arquivos Soap, desta forma fica mais fácil tentar descobrir o problema.

Bom dia Alexandre, Não, em função das novas TAGs e Grupos que serão necessários informar a partir de amanhã.

Bom dia João, Você esta enviando a nota para o ambiente de produção, correto? A nota esta sendo rejeitada: Falha no Schema XML do lote de NFe. Pois bem toda vez que ocorre esse tipo de rejeição significa que a nota possui alguma TAG ou grupo que não existe na rotina de validação da SEFAZ. No seu caso é a TAG CEST que costa no arquivo TXT CEST=1300100 Não informe e você vai ver que a nota vai ser autorizada. Essa TAG só será implementada amanhã dia 01/12/2015 depois do meio dia conforme a Nota Técnica 2015/003 versão 1.30.

Bom dia Régys, Será que o comando NFe.CartadeCorrecao não esta gerando de forma correta o XML de envio? Desculpa se eu estiver escrevendo besteira, mas não seria interessante que esse comando simplesmente fosse um alias do EnviarEvento?

Bom dia, A minha sugestão é você mudar de ConsultaNFeDest para DistribuicaoDFe. O DistribuicaoDFe é muito melhor, mais rápido e quando foi disponibilizado esse novo método a SEFAZ informou que o ConsultaNFeDest não iria mais existir.