Italo Giurizzato Junior

Bom dia Fábio, Por favor abra o fonte ACBrProvedorGinfesV3, veja o conteudo da function: GetLinkNFSe. Se a cidade em questão não esta implementada, basta implementar de forma semelhante as demais.

Boa tarde Leandro, Por favor, anexe somente os fontes que foram adicionados e ou alterados. Fica mais facil para podermos analisarmos e realizar o merge. Desde já muito obrigado.

Boa tarde Victor, Você se refere aos fontes do DANFSE feito em Quick Report, correto? Se sim, a resposta é não, eu pelo menos não tenho nenhuma maquina com a versão 3.0 do Quick Report instalada para poder disponibilizar os fontes nesta versão. E aproveitanto esta postagem, que comunicar que amanhã dia 10/03/2014 vou disponibilizar uma nova Unit que faz a leitura do XML de um RPS ou NFS-e. Essa nova unit visa deixar mais compacta e mais claro o código, pois os nossos colaboradores estavam criando uma procedure nova para cada provedor, agora vai bastar incluir o nome do provedor a uma das listas. Uma vez que temos provedor que se utiliza ainda da versão 1.00 e outros já utilizam a versão 2.00 do layout da ABRASF. Obviamente ficando de fora os provedores já implementados que não seguem o ABRASF. Peço a compreenção de todos, pois algo pode não funcionar de primeira, mas com o retorno de vocês, podemos lapidar essa unit. Desde já muito obrigado e até segunda-feira.

Boa tarde Plenosoft, Como você esta configurando o componente para que o mesmo gere a NFC-e na versão 3.10? Se possível post como anexo o XML.

Boa tarde Adelson, Note que ao informar um documento originário, ou seja, o documento emitido pelo remetente da carga, ele pode ser: 1. Uma NF-e; 2. Uma NF comum (papel) 3. Um outro tipo de documento, por exemplo uma declaração, uma carta remessa de mercadoria, etc. É importante realizar testes com os 3 tipos. Um detalhe importante, quando o emitente já esta obrigado a emitir NF-e, não podemos colocar os dados dessa NF-e como se fosse uma NF comum de papel, a SEFAZ vai refeitar a nota. A solução é informar a chave da NF-e. O que eu quero saber é com qual tipo de documento originário você esta tendo problema e em qual ambiente e qual é a mensagem de rejeição.

Boa tarde Michaelolimpio, Muito obrigado, desculpe, eu tinha feito a alteração conforme o nosso colega Tiago, mas não tive tempo de disponibilizar ontem. Mas agora foi.

Boa tarde Farnetani, A propriedade ID recebe automaticamente a chave que é gerada pelo componente, é essa propriedade que vai fornecer o conteudo para o atributo Id ao gerar o XML. Favor abrir com o Internet Explorer o XML de uma NF-e, note que o atributo Id contem a chave, veja este exemplo: <infNFe versao="2.00" Id="NFe13140104326492000160550020000000031713576652"> A chave que esta em negrito e em vermelho é gerado automaticamente pelo componente e é armazenado na propriedade ID o componente por sua vez, ao gerar o XML acrescenta o texto: NF-e como prefixo da chave e o resultado é o conteudo do atributo Id que esta em negrito. Se ao alimentar o componente, você atribuir qualquer coisa a propriedade ID, vai fazer com que o componente não gere a chave, em alguns casos provocando erro.

Bom dia Farnetani, Conforme a legislação, o XML a ser disponibilizado para o destinatário (no caso da NF-e) tem que estar assinado e protocolado, os seja tem que possuir as TAGs referentes ao grupo de informações do protocolo. Só assim podemos dizer que o XML é um documento fiscal eletrônico valido juridicamente, uma vez que ele esta assinado digitalmente e possui o protocolo de autorização da SEFAZ autorizadora. A disponibilização do XML assinado e protocolado deve ser realizada assim que o emitente da NF-e obter da SEFAZ o protocolo de autorização. A legislação que me refiro é o Ajuste SINIEF 07/2005 Mais precisamente: Paragrafo 7 do inciso terceiro da cláusula sétima. Outra coisa importante, no caso da emissão da NF-e o XML deve ser disponibilizado para o destinatário da mercadoria e para a transportadora quanta esta for responsavel pelo transporte da mercadoria.

Boa noite Jairo, O componente ACBrCTeDACTeQR utilizado para gerar o DACTE foi feito em Quick Report. Se a versão do Quick Report que você tem instalado no Delphi for posterior a 3.0, basta alterar o arquivo ACBr.inc Usando o Bloco de Notas abra o ACBr.inc que se encontra na pasta ...\Fontes\ACBrComum, procure pela diretiva QReport_PDF, ela deve estar comentada, descomente e compile a aplicação utilizando a opção Build. Isso vai fazer que ele passe a gerar o DACTE em PDF.

Boa noite Tiago, Muito obrigado pela colaboração, vou alterar e enviar para SVN.

Boa noite Jairo, O mais importante você esqueceu, qual é o problema que esta ocorrendo ao gerar o DACTE em PDF?

Rigotti, Se possível, post como anexo o XML da NFS-e.

Boa tarde Adelson, Só para termos um Norte. Versão do CT-e: 2.00 Emissão em Ambiente de Homologação, informando como documento originário uma NF-e, funcionando sem problemas, ou seja obtendo o protocolo de autorização. Emissão em Ambiente de Produção, informando como documento originário uma NF-e, o CT-e é rejeitado, pelo simples fato da NF-e não existir. Isso confere? Se sim, o problema esta na SEFAZ, o jeito é entrar em contato com eles por e-mail e explicar de forma detalhada o que esta ocorrendo.

Marcelo, Inclui nos fontes e já encontra-se disponivel para todos. Muito obrigado pela colaboração.

Rigotti, Ao imprimir ou cancelar você esta carregado o XML da NFS-e ou do RPS? É preciso carregar o da NFS-e.

Boa tarde Rafa, Todas as versões que constam da function GetVersaoNFe possui o ponto e não virgula. É bem provavel que o Windows ou o Delphi esteja configurado para trocar o ponto pela virgula.

Boa tarde Daniel, Fonte atualizado e disponibilizado.

Boa tarde Jairo, O nome da propriedade ficou como sendo dEmi para manter compatibilidade com a versão 2.00 Você deve configurar o componente utilizando as propriedades ModeloDF e VersaoDF.

Boa tarde Vitor, O Evento Encerramento sem vai existir, uma vez que a carga chega a seu destino, somos obrigado a encerrar o MDF-e. Quando emitimos o MDF-e, estamos informado a SEFAZ que a carga vai ser transportada. Ao Enviar o Evento de Encerramento, estamos informado a SEFAZ que a carga chegou ao seu destino. Favor atualizar os fontes, implementei um propriedade chamada MDFeEncerrado que funciona de forma semenhante a MDFeCancelada.

Boa tarde Rigotti, Ontem fiz uma alteração na Unit do provedor Tecno e hoje fiz outra alteração visando resolver o problema do fechamento em duplicidade da TAG Nfse. Favor atualizar os fontes e testar novamente.

Boa tarde Dalvan, O erro ocorre na validação do XML antes do envio ou trata-se da rejeição do webservice do provedor ao receber o XML?

Boa tarde Marcelo, Se possível post como anexo os 2 XML, o gerado pelo componente e o gerado pelo software da prefeitura.

Boa tarde HetoAndrade, Infelizmente não tenho como enviar o EXE para você, pois o teste que realizei, foi utilizando um modulo do meu ERP.

Boa tarde, Isso porque você esta comparando arquivos errados. Você esta comparando o arquivo de envio de lote com o arquivo RPS. Compare o exemplo fornecido pela prefeitura com o arquivo <lote>-env-lot.xml que esta dentro da pasta Ger.

Boa tarde Asterix, Você já tentou carregar primeiro o XML da NFS-e e depois executar o comando de enviar e-mail?