Italo Giurizzato Junior

Boa tarde Vinício, Vamos as correções: Ao gerar o Evento: 1. em cOrgao informar o código 35 uma vez que você vai utilizar o SVC-SP, correto? 2. em vTPrest informar o valor total da prestação que no seu teste o CT-e é 1000 e foi informado zero no EPEC; 3. em vCarga informar o valor da carga que no seu teste o CT-e é 100 e foi informado zero no EPEC; 4. em UFIni informar a UF Inicial que no seu teste o CT-e é MG e não foi informado no EPEC; 5. em UFFim informar a UF Final que no seu teste o CT-e é MG e não foi informado no EPEC; E aproveitando de uma lida na NT 2013/004 do CT-e, mais precisamente o item 2, que contem uma orientação de preenchimento do EPEC.

Leo, Eu não conheço o Fast Report, caso contrario poderia até lhe ajudar. Você pode sim realizar alterações no DACTE, desde que os dados obrigatórios estejam presentes. O DACTE que vem junto com o componente procura ser o mais fiel possível com o manual.

Boa tarde Leo, No Manual do CT-e quando o documento originário for uma NF-e devemos simplismente informar a chave da mesma. No Manual do DACTE quando o documento originário for uma NF-e devemos imprimir a chave da mesma. Quando o documento for uma NF (papel) ou outro tipo de documentos devemos imprimir: CNPJ/CPF Emitente, Série/ Número do Documento. E para todos os tipos de documentos devemos imprimir qual é o tipo do documento listado no quadro Documentos Originários. Lembrando que a chave da NFe contem o CNPJ do Emitente o Número e a Série, logo atende tudo o que esta no Manual do DACTE.

Boa tarde, Andei verificando algumas coisas, mas acredito que vou ter que refazer o DACTE.

Bom dia Luiz, Sim, você já leu o post #42 do Diego? Esta no inicio desta página.

Bom dia a todos, Sérgio, recebi o seu e-mail contendo os arquivos. Na minha casa consegui gerar um XML, assinar e validar com a tag vTotTrib sem nenhum problema. Favor verificar se o schema: leiauteNFe_v3.00.xsd contem a definição da tag vTotTrb. Se não tem, substitua pelo mesmo arquivo que encontra-se dentro da pasta: ...\Exemplos\ACBrNFe2\Delphi\Schemas Quanto a geração de todos os dados do destinatário vai ser necessário fazer uma alteração no pcnNFeW. Essa alteração é simples um IF já resolve o problema. Entre hoje e amanhã vou estar disponibilizando essa alteração.

Bom dia Robinho, Desculpe, mas acredito ter respondido as suas duas perguntas no post anterior. Recapitulando: Uma mercadoria só pode circular se a mesma estiver acobertada por uma nota fiscal ou seja NF-e. Como a transportadora esta apenas realizando um serviço de transporte, logo ela tem que emitir um documento próprio ou seja o CT-e, para acobertar a mercadoria. Só que no CT-e não discriminamos as mercadorias e sim a NF-e que por sua vez discrimina as mercadorias. Se eu vou emitir um CT-e Globalizado que se refere a varias NF-e, conclu-o que devemos discriminar todas as NF-e que fazem parte do CT-e Globalizado, caso contrario varias mercadorias ficariam sem um documento de transporte que as acoberta-se. Neste caso a fiscalização poderia entender que a transportadora esta realizando o serviço sem emitir o CT-e, algo semelhante a vender um produto sem nota. Quanto a forma de fazer esse tipo de CT-e, acredito que esta claro no Boletim Técnico, lendo atentamente ele, notamos que, o que muda é a maneira de infomar o Remetente e o Destinatário dependente de quem é o tomador do serviço o resto não muda nada.

Boa tarde Augusto, Antes de você enviar o CTe para sefaz, execute o comando abaixo: ACBrCTe.Conhecimentos.Valida; Copia o XML gerado para outra pasta e depois envia. Desta forma você tera o XML antes do envio e depois do envio. Sugestão: ACBrCTe.Conhecimentos.Valida; (...) // incluir aqui o comando para copiar o XML gerado para outra pasta. ACBrCTe.Enviar(Lote);

Boa tarde Renemelo e Graça, Verificando os seus XMLs notei algo em comum. O grupo <infMunDescarga> existem varios e com cidades diferentes. Me parece que devemos colocar todos os CT-e dentro de um unico grupo ou seja a primeira cidade de descarga. Quando o caminhão chega a essa cidade e descarrega uma parte da carga, devemos encerrar esse MDF-e e fazer outro informando o proximo municipio de descarga e os CT-e restantes. E assim por diante. Tente simular isso o que foi dito e postem um retorno.

Boa tarde EFV, A mensagem de erro esta clara esta faltando o grupo com as informações sobre os documentos originários, ou seja, esta faltando o grupo infNF ou infNFe ou infOutros. Devemos informar apenas um dos 3 citados acima e ele fica dentro do grupo <rem>. Por favor tenha sempre em mãos o Manual versão 1.04c do CTe, ele contem a estrutura do XML informando quais grupos / TAGs que são obrigatórias e as que são opcionais.

Boa tarde Sandro, Calma rapaz, esses schemas são para a versão 2.00 do CTe, não temos ainda nem sequer o ambiente de homologação liberado para essa versão. Você tem que utilizar os schemas da versão 1.04

Boa tarde Vinício, Leia a NT 2013/008 são 2 páginas e trata sobre o uso do EPEC. Muito estranho isso que você postou "ao salvar ele já está gerando o evento do EPEC, automaticamente". Se você alimentar o componente e informar o tipo de emissão teEPEC e mandar executar o comando: ACBrCTe1.Conhecimentos.Valida; Isso já é o suficiente para que o componente gere o XML, Assina e valida o mesmo. Mas não é para ocorrer o envio do evento ou gerar o XML do evento. De qualquer forma fiz uma ateração na unit ACBrCTeUtil, por favor atualize os fontes, leia a NT mencionada acima e realize novos testes.

Boa tarde a todos, Desculpe, inicio de mês corrido, hoje sem falta vou estudar o problema.

Boa tarde Michel, Obrigado pela colaboração. Já esta disponivel a atualização do schema e da unit.

Boa tarde Graça, O grupo <prop> que encontra-se dentro do grupo <veicTracao> e <veicReboque> é opcional e só devemos informar quando o veículo não pertencer à empresa emitente do MDF-e. Por favor post como anexo o último XML gerado que é rejeitado. De preferencia sem o grupo <prop>.

Bom dia a todos, No que diz respeito a chave, não importa se é da NFe ou CTe, temos um campo que a SEFAZ chama de código que nas primeiras versões era de 9 digitos, agora é de 8. A SEFAZ recomenda que esse código seja um número aleatório, muitos desenvolvedores acabam atribuindo a esse código o mesmo numero do documento fiscal. Esta errado não, mas também não é o correto, por dois motivos: 1. a chave não tem um código de seguraça. 2. o numero do documento é de 9 digitos e o código de 8, logo no futuro essa aplicação vai ter que sofrer alterações. Concordo com a resposta do Juliomar e dou uma outra dica. A unica informação da chave que seria impossível recuperar no caso de perda é o código, pois bem, como estamos falado da chave do CT-e, ao salvar os dados do mesmo no banco de dados, podemos gerar utilizando o Randomize o código aleatório de 8 digitos e salvar o mesmo junto com os demais dados em um campo chamado CodigoCTe. Pronto desta forma você consegue compor a chave sem nenhum problema quando houver a necessidade. No meu sistema alem do campo CodigoCTe tenho também um outro campo chamado ChaveCTe onde armazeno a chave completa. O CodigoCTe é salvo junto com os demais dados antes da emissão do CTe, neste momento o campo ChaveCTe recebe vazio. Após a emissão do CTe atualizo o registro, em especial o campo ChaveCTe. Como você pode ver com dois campos a mais na sua tabela fica resolvido o problema.

Boa tarde udenilson, Manda para mim por e-mail o fonte: ACBrNFSeWebServices.pas quero checar o seu fonte.

Boa tarde Elazar, Desculpe, não faz nenhum sentido a alteração que você fez. Pois a lógica da função GerarChaveCTe é usada para gerar a chave do CTe na versão 1.03 Já a lógica da função GerarChave é usada para gerar a chave da NFe, CTe (versão 1.04 e 2.00). Da forma que os fontes estão escritos, o componente gera o XML do CTe em conformidade com o manual. A minha aplicação faz mais de 2 anos que esta emitindo CT-e em ambiente de produção. E temos o ACBrNFeMonitor que utiliza o componente ACBrCTe e esta gerando o XML sem nenhum problema.

Boa tarde Carlos, Fica dificil resolver o seu problema sem saber qual é o erro que esta ocorrendo quando você tenta imprimir o DACTE. Seja mais claro, por favor.

Luiz, A mensagem de erro retornada é: Nao foi possivel localizar o Certificado Digital, configurado para assinar os arquivos gerados pela prefeitura. Observe se os parametros estao corretamente configurados na tela de parametros ou contate o administrador do Sistema! Acredito, que o problema esta no webservice do provedor. Note que na primeira linha da mensagem se refere aos arquivos gerados pela prefeitura. Entre em contato com o provedor e passe essa mensagem de erro.

Boa tarde Graça, No grupo <prop> deixe somente a tag RNTRC. Tanto do veiculo tração quando do reboque.

Carlos, Você já questionou sobre esse assunto em outro tópico. Se atente as regras do fórum.

Boa tarde Carlos, Se não me falha a memória esse método foi criado para o provedor IssDSF, logo ele não funciona para os demais provedores.

Luiz, Todos os fontes estão atualizados?

Leandro, Se não me falha a memória devo ter pego esse trecho de código de um exemplo que há um bom tempo foi postado no antigo fórum. A rotina por sinal se referia a NF-e, como os comandos são os mesmos acabei fazendo igual. A minha aplicação para emissão de CTe foi feita a mais de 2 anos, tem coisas que preciso parar analisar o porque eu coloquei. Não me recordo de tudo. Mas essas 2 linhas são para realizar uma consulta na SEFAZ utilizando o numero do recibo de entrega de lote. O componente possui duas formas de ser utilizado, principalmente os comandos que estabelecem a conexão com os webservices. As linhas que você postou é a segunda forma, que nos permite ter um controle maior, ou seja tratar de forma mais eficiente os retornos, evitando assim as telas exceções que os comandos ( primeira forma) do componente gera quando algo esta errado.