Italo Giurizzato Junior

Marcelo, O SP_NFE_PL_006q se refere a versão do aplicativo da SEFAZ, no meu entendimento não tem nada haver com os schemas. O componente ACBrNFe possui um propriedade Salvar em WebServices, por favor atribua o valor True e realize o teste novamente. É para salvar os mesmos arquivos com a palavra soap no nome deles. Post como anexo esses arquivos.

Bom dia, Se tratando de DANFE é sempre bom você informar qual Report e versão do mesmo que esta usando.

Bom dia Rômulo, Ao alimentar o componente devemos alimentar algumas propriedades ou não dependendo o provedor, podemos estudar a possibilidade do próprio componente fazer isso.

Bom dia Allan, Exatamente, o destinatário que deve realizar a manifestação, portanto a última manifestação enviada é a que prevalece e o seu sistema tem que controlar, isso. Por que eu disse que é a última que prevalece, pois em um primeiro momento você pode manifestar dando ciência da operação, ou seja, você esta informando a SEFAZ que realmente comprou a mercadoria e depois quando a mercadoria chegar você manifesta novamente dando: Confirmação da Operação, ou seja, você diz a SEFAZ que a mercadoria foi recebida. Neste caso a sua aplicação em um primeiro momento tem que informar que a nota não foi manifestada, em um segundo momento informar que foi manifestada com o evento: Ciência da Operação e por fim foi manifestada com o evento: Confirmação da Operação.

Bom dia Nishimori, A mensagem de erro é clara o elemento Discriminacao esta vazio e não pode, esse elemento tem que ter um conteúdo, ou seja, a discriminação do serviço realizado.

Bom dia Marcelo, Favor atualizar os fontes e testar novamente.

Bom dia Rômulo, Estamos trabalhando em uma nova versão dos componentes e como não existe mais o DPEC, pois foi substituído pelo EPEC, sendo assim essa função GetPathDPEC não foi implementada na nova versão.

Bom dia, A mensagem de erro é bem clara, você esta informando o ano com 4 dígitos (2015) sendo que é esperado essa informação com apenas 2 dígitos (15). Outra coisa você atualizou os schemas, mas pelo jeito não atualizou os fontes dos componentes, a um mês atrás fiz uma alteração no componente para resolver esse problema. Por favor atualize todos os fontes de todas as pastas.

Bom dia Gilson, Muito obrigado pela colaboração, já esta disponível.

Bom dia SISAD, O programa exemplo ao gerar o XML da NFC-e, este tem que ser salvo com o seguinte nome: <chave>-nfe.xml e não com o nome temp.xml Esse temp.xml se não me falha a memória se refere a um arquivo temporário que é criado para apresentar o retorno do web service.

Bom dia raosistemas, Tome como base o programa exemplo: Na rotina que alimenta o componente temos: (...) // TMDFeTpEmitente = ( teTransportadora, teTranspCargaPropria ); Ide.tpEmit := teTransportadora; (...) deverá ser alterado para: // TMDFeTpEmitente = ( teTransportadora, teTranspCargaPropria ); Ide.tpEmit := teTranspCargaPropria; Ao adicionar os documentos: (...) with infCTe.Add do begin chCTe := '35110803911545000148570010000001011000001018'; (...) no seu caso seria: (...) with infNFe.Add do begin chNFe := 'chave da NFe'; (...) depois temos: (...) tot.qCTe := 2; // indicando que foi adicionado 2 CT-e ao MDF-e (...) ficaria assim: (...) tot.qNFe := 2; // indicando que foi adicionado 2 NF-e ao MDF-e (...) Lembre-se que o MDF-e a principio foi criado para as transportadoras relacionarem os CT-e referentes as mercadorias que fazem parte da carga do caminhão que vai realizar um transporte interestadual, portanto carga fracionada. Mas foi estendido para as empresas que vendem, ou seja, emite NF-e mas realiza o transporte das mercadorias vendidas, cujo transporte é interestadual. Espero ter ajudado.

Bom dia Tatieli, No Form que contem a rotina de cancelamento / Encerramento inclua em uses a unit pcnConversao.

Boa tarde Maxsuel, O componente esta realizando a tarefa de forma correta. O XML que foi assinado, validado e protocolado como autorizado e tem validade jurídica não deve sofrer alterações só porque o mesmo foi cancelado. Lembre-se que o cancelamento agora é por evento e portanto exite um outro XML chamado *-procEventoNFe.xml que contem a solicitação do cancelamento mais a assinatura e o numero de protocolo que acusa que o evento foi registrado e esta vinculado a referida NF-e. Realizamos uma alteração no componente, onde criamos uma propriedade chamada NFeCancelada onde devemos atribuir o valor True e depois mandar imprimir o DANFE. Desta forma o DANFE será impresso com uma Tarja: NF-e Cancelada.

Roger, Puxa vida cara, já é o terceiro post seu com o mesmo questionamento. Por favor vamos seguir as regras do fórum. Vou lhe dar duas dicas: 1. Configuracoes.Arquivos.Salvar := True; 2. só execute o valida, não precisa do GerarNFe e nem do Assinar.

Boa tarde Claudio, Você deve configurar o componente para Offline da seguinte forma: Configuracoes.Geral.FormaEmissao := teOffLine; E na rotina que você alimenta o componente com os dados da venda é necessário também: Ide.tpEmis := teOffLine; mais Ide.dhCont := StrToDateTime(sDataCont+' '+sHoraCont+':00'); Ide.xJust := sJustificativa; Espero ter ajudado.

Boa tarde a todos, O problema é que a SEFAZ pede para que nós geramos o XML sem cedilha, sem vogal acentuada, sem caracteres especiais, mas na hora dela gerar o retorno para nós ela coloca e se tentarmos visualizarmos esses retornos através de um navegador temos estes problemas. Sugiro três alternativas: 1. fazer uma alteração no componente, mais precisamente na linha que ocorre o retorno de um evento, de tal forma que seja substituído no mesmo os caracteres indesejados pelos os correspondentes, por exemplo vogais com acento pelas mesmas vogais sem acento. 2. fazer a o procedimento acima só que na sua aplicação, ou seja, lendo o XML como uma string, realizando a substituição dos caracteres e salvando novamente o XML alterado. 3. em vez de abrir o XML usando um navegador, use o componente para carregar e posteriormente visualizar/imprimir uma visualização gráfica do mesmo, que chamo de DAEvento ou seja Documento Auxiliar de Eventos. Que por sinal muito mais fácil de ser lido e ainda existe a possibilidade de termos em PDF e enviar por e-mail para o cliente.

Roger, Por favor não fique postando a sua duvida em vários tópicos, já lhe respondi no outro. Vamos respeitar as regras do fórum.

Boa tarde Roger, Primeiro você tem que mudar o tpEmis para Offline depois, executar o método Valida, pois este executa o Assinar que por sua vez gera o XML. Desta forma se tudo estiver OK você terá o XML gerado, assinado e validado. Por fim basta imprimir. Como se trata de Offline, não devemos usar o método Enviar, pois este método vai tentar enviar para a SEFAZ. Se você esta emitindo em Offline significa que a SEFAZ não esta operacional, logo não devemos usar o Enviar, correto? Quando os problemas na SEFAZ forem sanados devemos usar o Enviar. ATENÇÃO, não altere o tpEmis este deve continuar como Offline, pois se você alterar para Normal a uma nova chave seja gerada e consequentemente a chave que consta no DANFE NFC-e impresso e entregue ao cliente ficará diferente da chave do XML que foi enviado a SEFAZ. Espero ter ajudado.

Luiz, Esse CT-e é de complementação de valores e não um CT-e Normal. Sendo assim ele não possui o grupo infCTeNorm consequentemente não temos a TAG qCarga. Abra o XML usando um navegador que você vai notar após o grupo <imp> a presença do grupo infCteComp com a TAG chave, chave esta do CT-e que foi complementado. Você deve inicialmente checar se a lista possui elementos para que você possa ler, caso contrario vai ocorrer erro. Por exemplo: if AcbrCte.Conhecimentos.Items[0].Cte.infCteNorm.InfCarga.InfQ.count >0 then Carga := AcbrCte.Conhecimentos.Items[0].Cte.infCteNorm.InfCarga.InfQ.Items[0].qCarga;

Boa tarde Luiz, Por favor post como anexo o XML do CT-e que você esta tentando ler os dados.

Bom dia Tatieli, Segundo o seu MDF-e a UFIni = RS e UFFim = ES sendo assim o o Percurso tem que ser: SC / PR / SP / MG / ES ou SC / PR / SP / RJ / ES você informou apenas SC e PR Lembre-se que o percurso é só de ida e não devemos informar a UF de inicio e a de Fim que no seu caso é RS e ES.

Boa tarde Edson, Você esta configurando desta forma? ACBrNFe1.DANFE.TipoDANFE := tiNFCe;

Boa tarde Lalin, Neste caso é preciso checar se o XML esta sendo gerado segundo um modelo e ao enviar esta sendo configurado o componente com outro modelo, por exemplo o modelo que consta no XML é 65 (NFC-e) mas o componente esta sendo configurado como sendo 55 (NF-e).

Bom dia Lalin, A rejeição diz: Lote So Podera Conter Nf-E Ou Nfc-E, isso me faz concluir que o lote possui 2 ou mais notas, neste caso todas tem que ser do mesmo modelo. ​Não posso enviar um lote contendo NF-e e NFC-e, se o emitente hora emite NF-e (para pessoa jurídica por exemplo) e hora emite NFC-e (para pessoa física por exemplo) tem que gerar e enviar dois lotes caso tenha varias notas de modelos diferentes para serem enviadas.

Bom dia Abrantes, Se você programa em Delphi, não faz sentido você utilizar um outro programa como é o caso do Monitor. O Monitor foi criado para os desenvolvedores que não programam em Delphi. Garanto que você terá menos problemas.