Italo Giurizzato Junior

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

Bom dia Jorge, Por favor atualize os fontes e teste novamente, a semana passada fiz algumas alterações, visando corrigir problemas com o canhoto tanto no cabeçalho quanto no rodapé e quanto ao contador de páginas que apresentava uma quantidade total de 2 sendo que na verdade era uma só.

Bom dia Giovani, A consulta da NF-e destinadas é feita na SEFAZ-Virtual Ambiente Nacional, portanto a URL é a mesma para todos os Estados brasileiros. A minha sugestão é você mudar para o método DistribuicaoDFe, tem a mesma função da anterior com mais vantagens, tais como: retornar o XML completo de uma NF-e caso a mesma já tenha sido manifestada. Existe uma promessa da SEFAZ em desativar o ConsultaNFeDest. Sendo assim, mude o quanto antes.

Bom dia Ricardo, Muito obrigado pela colaboração, as suas alterações já estão disponíveis, vou agora verificar o nome dos schemas. Fiz mais algumas alterações, por favor atualize os fontes e teste novamente. Preciso saber se o erro esta ocorrendo na validação do modal ou nos dados do manifesto.

Bom dia Marcelo, Devemos neste caso fazer a correção da informação rejeitada, gerar novamente o XML, assinar, validar e enviar.

Bom dia Ricardo, No caso do MDF-e temos que validar os dados do Modal e depois os dados do MDF-e. O método Validar realiza essas duas validações mas caso ocorra um erro não temos como saber onde exatamente o erro. Fiz uma alteração a fim de apresentar mensagens de erro de validação separadas, para o Modal e para o MDF-e. Por favor atualize os fontes e teste novamente.

Boa noite Emerson, Você tem toda razão, da forma que esta, jamais o valor passado como parâmetro em CNPJ é utilizado.

Boa noite Emerson, Você tem toda razão, da forma que esta, jamais o valor passado como parâmetro em CNPJ é utilizado.

Boa noite Igor, Por favor post como anexo o arquivo INI que você montou com a minha sugestão.

Boa tarde Anderson, Vamos analisar as suas alterações e assim que possível estaremos disponibilizando. Desde já muito obrigado pela colaboração.

João, Como você esta fazendo a leitura do QR-Code, uma vez que ele é uma imagem impressa no DANFE da NFC-e? Na URL do QR-Code como você já deve ter visto contem um campo chamado chNFe que contem a chave da NF-e e nessa chave consta o CNPJ da empresa que emitiu a nota. Se não me falha a memória o CNPJ possui 14 dígitos a começar da posição 7 da chave, ou seja: copy( chave, 7, 14).

Boa tarde Naara, Por favor post como anexo o XML do MDF-e que esta sendo rejeitado.

Boa tarde, Você esta com todos os fontes de todas as pastas atualizados? Até onde sei não existe DACTE Simplificado e sim DANFE Simplificado.

Boa tarde João, A chave de uma NF-e ou NFC-e é padrão nacional, portanto é igual em todos os Estados brasileiros. A URL do QR-Code que é impresso no DANFE da NFC-e, também é padrão nacional. O componente ACBrNFe possui uma rotina que gera essa URL segundo o padrão estabelecido. Vai ocorrer uma reunião do ENCAT nos próximos dias, talvez ocorra alguma alteração no conteúdo da URL do QR-Code. Caso isso venha ocorrer, com certeza o ENCAT vai estipular um prazo para que ocorra essa mudança e assim que nós tivermos em mãos a Nota Técnica que estabelece o prazo e o novo conteúdo da URL, vamos providenciar as alterações no componente.

Boa tarde William, Não utilizo o Fortes Report, trabalho com o Quick Report, mas pela mensagem de erro informando que uma determinada propriedade não foi encontrada, sugiro que você abra o arquivo TXT chamado Property_Does Not Exist que esta dentro da pasta ...\Fontes\ACBrMDFe. Esse arquivo é um passo a passo para resolver o mesmo tipo problema mas no Quick Report, quem sabe você consiga resolver de forma semelhante.

Parabéns a todos, ficou muito bom.

Bom dia Marcelo, É exatamente isso que tem que ser feito.

Boa tarde Nishimori, Mas da forma que você postou me leva a crer que ao deparar com o erro você não tinha ideia do que estava acontecendo.

Boa tarde Jemison, Muito obrigado pela colaboração, vamos avaliar e assim que possível estaremos disponibilizando.

Bom dia Igor, Inclua no arquivo INI o seguinte: [iSSQNxxx] onde xxx é o numero do item vBC=116.85 vAliq=2.5 vISSQN=2.92 cMunFG=434902 cListServ=13.05 indISS=1 indIncentivo=2 (...) // na totalização inclua: [iSSQNtot] vServ=116.85 vBC=116.85 vISS=2.92 dCompet=05/05/2015 Espero ter ajudado.

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.