Italo Giurizzato Junior

Boa tarde Graça, Já esta disponivel as alterações e implementações para a impressão de eventos do CT-e. Favor atualziar os fontes e e ver como usar a impressão através do programa exemplo, botão [imprimir Evento]. Testei com o evento de cancelamento funcionou 100%, como não tenho o XML do CT-e e o de evento de CC-e não consegui realizar o teste neste caso. Se você tiver e poder postar como anexo ou enviar para mim por e-mail fico agradecido. Não testei o envio por e-mail e nem a geração do PDF do evento. se puder realizar esses testes agradeço. Fico no aguardo do seu retorno.

Boa tarde Maiko, A versão 2.00 entra em obrigatoriedade no dia seguinte da data final de vigência da versão 1.04 e esta informação esta na Nota técnica 2013/013, basta baixa-la e ler. Dica, página 5. Outra dica, o componente ACBrCTe, já esta preparado para a versão 2.00

Boa tarde Rodrigo, Obrigado pela colaboração. Os schemas que você esta utilizando é o que esta disponivel junto com o programa exemplo ou é outro? Se for outro, favor anexar aqui no forum.

Boa tarde Professor, Primeiro não existe uma chave com tudo zero. Segundo, pesquise no fórum já existem relatos sobre esse problema, e como realizar os testes, uma vez que esse problema esta ocorrendo no ambiente de homologação.

Boa tarde Rigotti, Favor atualizar os fontes e testar novamente.

Bom dia Graça, Fico feliz por estar funcionando. Se tudo der certo vou disponibilizar até o final desta semana a impressão do evento usando o Quick Report. Iniciei os trabalhos para o CT-e, assim que concluir, vou partir para o MDF-e, depois posso criar também para a NF-e, destar forma tiamos mais uma opção para a NF-e.

Bom dia Rigotti, Em qual fonte a linha esta comentada? Qual comando você utiliza para carregar o XML para o componente?

Bom dia Roberto, Muito obrigado pela colaboração, até o final da tarde de hoje já vai estar disponivel.

Boa noite Graça, Você esta utilizando os schemas da pasta: ...\Exemplos\ACBrMDFe\Delphi\Schemas\v100 Arquivo zipado: PL_MDFe_100a_pre (correcao) ?

Boa tarde sesistemas, A propriedade dhEmi é do tipo TDateTime e no XML devemos sempre informar a Data e Hora de Emissão sendo assim quando formos alimentar a respectiva propriedade devemos utilizar o Now em vez do Date, pois este útimo nos retorna somente a Data. Ide.dhEmi := Now; em vez de Ide.dhEmi := Date;

Boa tarde Rômulo, Vou checar as suas alterações assim que possível vou disponibilizar. Muito obrigado pela colaboração.

Boa tarde Graça, A versão 1.00a foi liberada para o ambiente de homologação em 29/10/2013, o previsto era para 01/11/2013 e o de produção esta previsto para 01/12/2013. Acredito que o ambiente de homologação não esteja mais aceitando a versão 1.00, somente a 1.00a. Sendo assim temos que nos focar no erro com relação a TAG: <veicTracao>, se possível poste como anexo, o XML gerado na versão 1.00a, de preferencia com os fontes recem atualizados.

Boa tarde Rodrigo, Já inclui, até o final da tarde de hoje vou disponibilizar inclusão. Muito obrigado pela colaboração.

Graça, Acredito que o problema seja na sua maquina, pois em casa e aqui na empresa, a compilação foi realizada de ambos os componentes foi realizada com sucesso.

Bom dia Mauricio, Já tentou realizar testes com uma maquina 32 bits? Outro teste é: incluir proBHISS na lista: if not (FProvedor in [proGovBr, proSimplISS, proAbaco, proISSNet, pro4R, proFiorilli, proProdata, proThema, proVirtual, proPVH, proBHISS]) Fonte: ACBrNFSeWebServices.pas Procedure: OnBeforePost

Bom dia Graça, Enviei para o SVN algumas alterações no componente ACBrMDFe. Favor atualizar todos os fontes, inclusive da pasta PCN2. É bem provavel que seja necessário recompilar o pacote do PCN2 e depois o pacote do ACBrMDFe. Pois foram incluidas novas propriedades ao componente.

Bom dia Tallys, O XML e o mecanismo de comunicação com o WebService é totalmente diferente do padrão ABRASF. A minha sugestão é desenvolver um componente para esse provedor e não realizar alterações no ACBrNFSe afim de atender esse provedor.

Bom dia sesistemas, Com base no seu XML e na mensagem, veja: Mensagem: Rejeicao: Data de entrada em contingencia posterior a data de emissao. XML: (...) <dhEmi>2013-11-22T00:00:00</dhEmi> (...) <dhCont>2013-11-22T17:02:06</dhCont> (...) A mensagem é clara e mostra o que você esta fazendo de errado. Note Data e Hora de Emissão: 22/11/2013 as 00:00:00, Data e Hora de Contingência: 22/11/2013 as 17:02:06 Se o inicio da contingência foi as 17 horas e você esta emitindo as 00 horas, concorda que esta errado. A Data e Hora de Contingência sempre tem que ser anterior a Data e Hora de Emissão. Manual do CT-e versão 1.04c, página 35, Regra de validação G004c.

Bom dia Datilas, A principio não existe problema nenhum em criar uma nova propriedade. Inclusive já propus varias vezes a criação de novas propriedades. O problema que eu vejo é que quando se cria uma nova propriedade ela só aparece no Object Inspector depois que você reinstala o componente novamente ou abra o pacote de instalação do mesmo e o compile novamente. Uma solução, o Grupo IPI não deve ser gerado no XML quando o documento fiscal for a NFC-e, correto? Sendo assim, em vez de você criar uma nova propriedade que diz se é ou não para gerar o grupo IPI, porque não checar o modelo de documento fiscal? Se o modelo for 65, ou seja, NFC-e não gera, caso contrario gera.

Boa noite Adilson, Se a versão do seu Quick Report não for a 5, favor abrir o pacote de instalação e remover: QR5RunD7 deixando a linha da seguinte forma: {$IFDEF VER150} vcljpg, visualclx; {$ENDIF} // D7

Boa noite Datilas, Estamos estudando uma forma diferente de resolver esse problema sem a necessidade de incluir uma propriedade nova no componente.

Boa tarde Elaine, Como você fez o Download do XML através do site, isso explica algumas coisas, como por exemplo as TAGs que mencionei no post anterior. Dentro do grupo <CTeDFe> temos o grupo <procCTe> onde vou chamar a atenção de 3 coisas: 1. Você informou o local de entrega, lembre-se só devemos informar esses dados quando o local de entrega for diferente do endereço do destinatário, e no seu caso são iguais. 2. A SEFAZ esta retornando a versão errada no grupo <protCTe> esta aparecendo versão 1.00 sendo que o correto é 2.00, logo isso é um erro da SEFAZ. 3. A versão do aplicativo da SEFAZ é SP-CTe-14-11-2013, isso mostra que tem muita coisa para ser corrigida, pois hoje é 22/11/2013, ou seja, faz uma semana que eles alteraram as aplicações deles. Depois temos o grupo <procEventoCTe> note que a versão também esta errada o correto é 2.00 e não 1.00 Dentro deste grupo temos o grupo <retEventoCTe> que também esta com a versão errada e não esta retornando o código do Orgão esta aparecendo apenas: <cOrgao /> E as NOVE cartas de correções que você enviou para esse CT-e estão todas relacionadas nesse retorno. Sugestão: Entrar em contato com a SEFAZ relatando esses problemas, de numero de versões erradas e a falta do código do Orgão no grupo de retorno do evento e não esquecer de mencionar que ao realizar uma consulta no site aparece o evento de EPEC em vez de CC-e e outra coisa só esta aparecendo o primeiro evento, ou seja a primeira CC-e, sendo que você enviou 9 esta faltando mostrar as outras 8.

Idez, Não, o que eu quiz dizer é quando o CTe é do tipo normal apenas informamos que é o Remente e o Destinatário. Quando se trata de Redespacho ou Redespacho Intermediario não há necessidade de informar quem é o Remente e ou Destinatário, mas por outro lado informamos o Expedidor e ou Recebedor.

Boa tarde Elaine, Acredito que deve ser as mudanças que a SEFAZ esta realizando. Inclusive tem mais coisas estranhas: <retCTeConsultaDFe ???? <CTeDFe> ???? Essas TAGs não existem no manual.

Boa tarde Idez, Se o CT-e for do tipo Normal, não há necessidade de informar o Expedidor ou Recebedor, apenas o Remetente e o Destinatário. Normalmente informamos o Expedidor e/ou Recebedor quando se trata de Redespacho ou Redespacho Intermediário.