Italo Giurizzato Junior

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.

Acredito que vai ser atualizado sim para o layout da secretaria. Mas eu no seu lugar mudaria a rotina que gera o arquivo TXT para o layout do ACBr.

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, Foi realizadas somente alterações no Layout próprio do ACBr.

Werner, Atualiza os fontes.

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.

Bom dia, Você abriu o XML usando um navegador? Se sim, percebeu que a nota não possui nenhum item.

Bom dia Maxsuel, Esse tipo de rejeição ocorre quando alguma TAG ou grupo é informado e a SEFAZ não esta preparada para processar a nota com essa informação a mais. Tente não incluir o QR-Code no XML, ou seja atribua o valor False a propriedade que defini que o QR-Code será incluído no XML. Se a nota for processada com sucesso, esta ai o problema, a SEFAZ-PI ainda não implementou as novas mudanças no ambiente de homologação.

Bom dia Leonardo, Você pode alterar para o tempo que você julgar necessário, dica, crie uma tabela de configuração, desta forma para cada cliente você pode definir um tempo mais adequado. Outra coisa informar 10 ou 15 segundo não significa que o componente sempre vai esperar esse tempo e sim estamos definindo um tempo limite máximo de espera. Caso a resposta venha em 2 segundos o componente não vai ficar aguardando o restante para prosseguir.

Bom dia Sérgio, Se o erro é de validação a nota não é enviada e podemos concluir 2 coisas: 1. A informação passada para a TAG esta errada, por exemplo, tamanho minimo ou máximo, formato da informação, entre outros. 2. O schema usado para validar esta errado, desatualizado por exemplo. Por outro lado se o erro é uma regeição retornada pela SEFAZ, podemos concluir 2 coisas: 1. A informação passada para a TAG esta errada, mas passou pelo validador do componente, por exemplo foi informado um CNPJ com 14 dígitos, mas tem um dos dígitos errado, deixando essa informação inválida. O validador do componente só checa se o CNPJ possui 14 dígitos. 2. Existe um erro no validador da SEFAZ que esteja provocando a rejeição.

Bom dia Heto, A ideia do Cidade.INI é fazer com que o arquivo pnfsConversao.pas não precisa mais ser alterado quando uma cidade muda do provedor A para o provedor B. Favor alterar apenas o arquivo Cidades.INI e testar. Quanto a criar uma propriedade para informar em qual pasta encontram-se os arquivos INI já esta nos meus planos, neste caso peço um pouco mais de paciência que isso será feito.

Bom dia Miriane, Recentemente os valores usados para a Natureza de Operação usados no componente ACBrNFSe foram renomeados: Como era: TnfseNaturezaOperacao = ( noTributacaoNoMunicipio, noTributacaoForaMunicipio, noIsencao, noImune, noSuspensaDecisaoJudicial, noSuspensaProcedimentoAdministrativo, noNaoIncidencia, noTributacaoNoMunicipio51, noTributacaoNoMunicipioSemISS52, noNaoTributa58, noSimplesNacional59, noTributacaoNoMunicipio61, noTributacaoNoMunicipioSemISS62, noTributacaoForaMunicipio63, noTributacaoForaMunicipioSemISS64, noNaoTributa68, noSimplesNacional69, noNaoTributa78, no50, no53, no57, no60, no67, no70, no79, //Itajai/SC noISSDevidoItajai, noISSDevidoOutroMunicipio, noISSFixo, noISSRetido, noOperacaoImune, noISSDevidoItajaiSN, noISSDevidoOutroMunicipioSN, noMEISN, noEscritorioContabilSN, noISSRetidoSN, noOperacaoImuneSN Como é agora: TnfseNaturezaOperacao = ( no1, no2, no3, no4, no5, no6, no7, no50, no51, no52, no53, no54, no55, no56, no57, no58, no59, no60, no61, no62, no63, no64, no65, no66, no67, no68, no69, no70, no71, no72, no78, no79, no101, no111, no121, no201, no301, no501, no511, no541, no551, no601, no701 ); Portanto se antes você alimentava da seguinte forma: ACBrNFSe1.NotasFiscais.Items[0].NFSe.NaturezaOperacao := noTributacaoNoMunicipio; Agora passa a ser da seguinte forma: ACBrNFSe1.NotasFiscais.Items[0].NFSe.NaturezaOperacao := no1;

Bom dia Walter, O arquivo INI do Ginfes é padrão para todas as cidades com exceção de Fortaleza/CE. Verifique se todos os arquivos de todas as pastas estão atualizados.

Bom dia Claudio, Segundo o Manual versão 2.00a do CT-e - página 147 o grupo valePed poderá ser informado independente do Indicador de Lotação, ou seja, não importa se é ou não Lotação podemos alimentar esse grupo. Pelo menos na coluna observação não consta nada que diz o contrario. Mas no Manual versão 1.01 do DACTE página 18 e 19 temos respectivamente os modelos de DACTE - Carga Lotação e DACTE - Carga Fracionada. Somente no modelo de Carga Lotação os dados referente Vale Pedágio são impressos. Podemos concluir 2 coisas: 1. No Manual versão 2.00a do CT-e esta faltando na coluna Observação a informação que o vale pedágio só deve ser informado quando for Lotação como é o caso do grupo Veículo e Motorista. 2. No Manual versão 1.01 do DACTE deixa claro que se tratando de Lotação o vale pedágio tem que ser informado e impresso e quando for Carga Fracionada o vale pedágio é opcional. Me recordo que no DACTE feito e Quick Report um dos usuários do componente alterou para que o Vale Pedágio fosse impresso em ambos os casos.