italo.giurizzato.junior

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.

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, 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?

Bom dia Vitor, No meu entendimento, um documento assinado e protocolado pela SEFAZ, não deve ser mais alterado. Dai a idéia de se criar o encerramento e o cancelamento como sendo eventos vinculados ao documento anteriormente enviado. Temos então dois XML: 1. MDF-e 2. Evento Portanto temos duas imagens desses XML em papel: 1. DAMDFE 2. Evento Se você carregar o XML do MDF-e em seguida carregar o XML do Evento e por fim Imprimir o Evento, a folha impressa vai conter alguns dados do MDF-e e mais os dados do Evento indicando se é de Encerramento ou Cancelamento. A minha sugestão é imprimir duas vias do DAMDFE, uma segue viagem com a carga e a outra fica na trasportadora para ser "grampeado" com o Evento Impresso de Encerramento. Por outro lado, após a emissão do MDF-e se por erro ou cancelamento do envio da carga, devemos efetuar o cancelamento do MDF-e, neste caso após imprimir o Evento de Cancelamento devemos "grampear" com o respectivo DAMDFE. Espero ter ajudado.

Bom dia mmcamilo, Se você realiza uma consulta anterior ao dia 28, ocorre o retorno, logo o componente esta funcionando. Normalmente esse tipo de erro 999 - Falha não Tratada ou Erro não Catalogado é problema na SEFAZ. A dica é entrar em contato com eles e expor o problema.

Bom dia jperim, Da forma que você montou esta correta. Veja este outro exemplo: Supondo que o campo a ser alterado é xBairro. Note que existe dentro do grupo rem 2 campos com o mesmo nome, um esta dentro do grupo enderReme e o outro dentro do grupo locColeta, ambos os grupos dentro do grupo rem. Você concorda que se você informar rem como sendo o grupo alterado a SEFAZ não vai saber quais dos dois xBairro que esta errado? Sendo assim se o xBairro que esta errado é da coleta devemos informar como grupo o locColeta.

Bom dia Edilson, Se você atribui zero ao campo Ide.cMDF, isso faz com que o componente gere um código aleatório para compor a chave. Por outro lado se você atribuir um numero diferente de zero, o componente vai utilizar esse numero para compor a chave. Nas minhas aplicações, ao salvar as informações no banco de dados, gero um numero aleatório. Depois utilizo esse numero para atribuir ao campo Ide.cMDF. Veja bem, o numero atribuido é aleatório mas gerado pela minha aplicação e armazenado no banco de dados juntamente com as demais informarções a serem utilizadas para gerar o XML do MDF-e. É exatamente isso que o nosso colega Wislei faz. Outra coisa, tenho também no banco de dados a chave completa gerada pelo componente.