Marcio Cenci

Olá. Também utilizo FastReport e estou utilizando este mesmo DACTE_Retrato. Após atualizar para este layout venho enfrentando: * Chield do Documentos Originários cortando na tela (igual mostrado acima). *O número de páginas não indicando corretamente, (indica página 1/3) quando a impressão é de apenas 2 páginas. OBS: Em média 80 documentos (NFe) vinculados ao CT-e para ser impresso. Após tentar fazer o ajuste do @windsoft ref ao DoublePass, notei que as páginas impressas passaram para as 3 (como o indicador de número de páginas apresentava anteriormente), e o grupo de Documentos Originários não está mais sendo impresso sobre outro grupo como antes. Acabei desistindo após tentar ajustar por várias vezes, mas não obtive sucesso ainda.

O mesmo problema ocorreu - ontem e hoje - com alguns dos meus clientes, tanto no MDF-e quanto no CT-e e NF-e. Porém foi solicitado o fechamento e abertura o sistema novamente e tanto a emissão quanto o Encerramento (MDF-e) voltaram a funcionar (em todos os casos).

Estou tendo este mesmo retorno, estou a 1 hora encima desse problema e nada de conseguir identificar se houve alguma NT ou algo do tipo.

Estou exatamente com o mesmo problema, os domínios próprios não estão mais enviando com o ACBrMail da Trunk2. Não estou conseguindo identificar o outro tópico, se possível repassar o tópico.

Boa tarde, Estou com o problema ocorrendo também a semana toda. Porém só ocorre em clientes com Windows 7 e com o Internet Explorer com versão inferior à 11. Até então mudando a configuração no IE 9 estava resolvendo o problema (Deixando marcado o TLS 1.0 e o SSL 2.0 apenas). Porém como nem tudo são flores na vida, os clientes em grande maioria utilizam os sistemas bancários, e adivinha? o TLS 1.1 e 1.2 são marcados ao acessarem a página do banco e automaticamente a aplicação deixa de enviar os documentos (NF-e e CT-e). Resolvi "fuçar" um pouco mais em um cliente com windows 7 e atualizei o IE para o 11, todas as opções TLS estavam marcadas por padrão(1.0, 1.1, 1.2). FUNCIONOUUU.... PORÉM COM RESALVAS: O SSL 2.0 não pode estar marcado (por padrão após atualizar acaba trazendo desmarcado o SSL 2.0 ). Pesquisei a respeito e caí na página 18 do manual da 3.0, uso do SSL 3.0 e TLS 1.2 : http://www.cte.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=bx74pJ8hXaM= Espero ter ajudado (se este for a única solução só será trabalhoso atualizar cliente por cliente).

Bom dia Italo, Já havia implementado desta maneira que me citou e deu certo sim, o objetivo de consultar pelo recibo seria justamente em pegar de uma única consulta a autorização de todos os CT-e(s) que foram autorizados no lote que foi enviado ao SEFAZ. Só o que irá mudar para mim é que desta maneira o tratamento das consultas deveram se tornará unitário. Obrigado Ítalo.

Olá Hoje, ao tentar transmitir um CT-e que por algum motivo não conseguiu-se o retorno da confirmação da autorização, tenho uma rotina que tenta enviar o CT-e e na sequência faz a leitura do retorno: Duplicidade de CT-e [nRec:999999999999999] para assim ter o número do recibo e reconsultar e autorizar o documento. Após esse início de semana ter sido um "pouco tanto conturbado" em virtude de lentidão no sefaz, notei que minhas rotinas estavam com algum problema pois meus tratamentos não estavam surtindo o efeito esperado. Estudando sobre o problema e lendo a última Norma Técnica 2016/001, me deparei com uma situação que me deixou um pouco preocupado. O Retorno mudou, no lugar do [nRec] começou a retornar o [nProt]. Rejeição: Duplicidade de CT-e [nProt:342160000089398][dhAut:2016-11-07T16:46]. (Pode isso Arnaldo!) Pergunta: Alguém consegue me dar uma luz(auxílio) de como posso conseguir o retorno sendo que agora não possuo mais o nRec em mãos ? Desde já agradeço.

Quando se tem o número do Recibo pode pegar o retorno da seguinte maneira: CTe.WebServices.Recibo.Recibo := NÚMERO DO RECIBO; CTe.WebServices.Recibo.Executar; Na sequencia fazer a leitura dos dados no loop no caminho similar a : CTe.WebServices.Recibo.CteRetorno.ProtCTe.Items.nProt; Espero ter ajudado.

Estou com o mesmo problema. Clientes não podendo continuar viagem por causa do MDF-e que não está encerrando e também não está transmitindo:[ 35->Falha no processo de validacao MDF-e ]. E não encontro o motivo desta rejeição. Ocorrendo no ambiente de Homologação e em Produção, a rejeição ocorre utilizando também o software emissor gratuito do SEFAZ. Se alguém descobrir o motivo, favor postar com urgência..

capicom

Boa noite Juliomar, obrigado pelo retorno.. mas poisé.. até então eu já havia verificado estas rejeições, porém o modal é o mesmo para todos, a não ser que esteja validando pela FINALIDADE estando NORMAL ou COMPLEMENTO DE VALORES. Abraço

Boa noite a todos, No sistema de emissão de CT-e, permito a geração de vários CT-e(s) e o envio dos mesmos em uma única vez (lote). Há uma situação em clientes que estou tendo um retorno de rejeição, sendo que através dos conhecimentos que foram feitos e que ocorrem o retorno eu identifiquei que quando há CT-e com a [ Finalidade = Normal ] e outro CT-e com [ Finalidade = Complemento de Valores ] no mesmo lote, os CT-es de complemento são Autorizados porém os CT-e(s) Normal está retornando a [ Rejeição: Versao informada para o modal nao suportada. ]. Para ser mais exato, estou a 3 dias em pesquisa para achar algo sobre se esse problema é realmente pela situação de conter CT-e de diferentes Finalidades no arquivo do lote, porém é apenas este o motivo identificado do retorno, e transmitindo os CT-es por Finalidade está autorizando 100%. Se alguém puder me ajudar sobre este retorno, ou se realmente não vou ter o que fazer e mandar lote separando por Finalidade. Desde já. agradeço. Em anexo o lote e o retorno. 423000004610200-pro-rec.xml 250-env-lot.xml