luisclaudio_jr

Boa tarde. Também tive esse problema. Alguém ai tem uma ideia pratica pra resolver isso? seja por aplicação ou outra ideia? Meu problema hoje é a quantidade de usuarios do software, querendo ou não temos que entrar em todas maquinas e instalarmos manualmente essas cadeias, hoje temos que fazer em mais de 600 maquinas.. quando acontecem essas coisas é complicado. Alguém conhece outra forma sem ser essa? Agradeço desde já.

Automatico não. Você tem que ir atrás de uma das agencias regularizadoras pela ANTT pra geração de CIOT. como RODOCRED, pamcard, E-frete. Ai a partir disso vc terá que integrar com eles pra ser gerado um numero, Esse numero você pode colocar no seu manifesto. OBS: Dizem por ai que logo a antt estará validando e bloqueando as emissões de manifestos para terceiros que sejam TAC e necessitam de ciot.

Não sei se isso tem alguma coisa haver, mas desde ontem estou enfrentando em todos os clientes erro de duplicidade de evento ao encerrar, alguém ta passando por algo semelhante? ele encerra normal, mas dá o problema da duplicidade. Chegou a ver na sefaz, se o seu encerramento por acaso não foi concretizado? OBS: Não mexemos em nenhum fonte da acbr, mesmo codigo de um mês atras funcionava normal e agora de ontem pra cá começou esse problema. Obs2: ocorreu em uns 30 clientes diferentes

Ola dentro do FR3, segue , DACTE30.fr3

Boa Tarde , tem mais um detalhe no meu caso, tive que alterar o tipo da variável intNr_Nota na procedure PageHeader1OnBeforePrint para string ; procedure PageHeader1OnBeforePrint(Sender: TfrxComponent); var intNr_Nota : string; // Está como -> Integer mudei para string ; begin end;

Bacana bsoft.. também temos o entendimento que o problema acontece apenas em SP e criamos um chamado também. Resta apenas aguardarmos

Bom dia amigos. Desde ontem, meus clientes de SP tem reclamado que não conseguem cancelar os ctes sem ter que voltar uma hora no relógio para que possam fazer o cancelamento, da uma mensagem de que a data do evento não pode ser maior que a processada. Caso mudem o relógio funciona perfeitamente. Mais alguém tem passado por isso?

Verifique se os schemas estão no 3.0

Sempre será o valor da mercadoria, afinal ele é o unico dado que importa pra seguradora pra poder cobrar o cliente em cima do valor do risco, pra eles não importa o valor do cte.

Infelizmente a AT&M ainda não subiu o serviço em produção, nessa nova versão está operando apenas os testes.

Bom dia. Para fins de conhecimento, recentemente andei recebendo emails da AT&M, porto seguro e outros, sobre uma legislação da ANTT na qual diz que deverá ser necessário no MDF-e 3.0 o numero de protocolo de averbação nacional, que vai ser fornecido pelas empresas de seguro (via atm ou outra empresa), e pasmem, passará a vigorar agora dia 01/10 a exigência disso, infelizmente a AT&M e as outras empresas estão terminando agora esse processo, sobrando para nós, pouco tempo pra se adaptar isso.

Notei que aqui acontece o mesmo problema, porém é algo que ocorre esporadicamente e se tentar fazer o reenvio acaba indo.. Vou analisar essa função

Se são dois casos, realmente pode ser algo da sefaz. Até então meus clientes estão oks que utilizam o RS.

Bom dia. Isso ja ocorreu comigo, meu cliente não pagou os impostos e o governo bloqueou a Inscrição estadual, assim ele não poderia emitir mais. Verifique também se não mudou a IE do teu cliente, em alguns estados quando há mudanças de endereços eles refazem a IE também. Pode verificar no sintegra a inscrição dele: www.sintegra.gov.br Espero ter ajudado.

Não sei te dizer, aconteceu comigo isso uma vez, nos envios de ctes e eu instalei essas cadeias e passou a funcionar corretamente.

Boa tarde, Tudo beleza? Tem que instalar umas cadeias de certificação. Eu uso essas, instala na maquina, coloca todas elas como certificação de raiz confiável. AC-Certisign-RFB-G5.cer AC-Raiz-V5.cer AC-RFB-V4.cer CADEIA DE CERTIFICADO RAIZ CONFIAVEL MG.crt CTEFAZENDAPRGOVBR.p7b

Pode enviar o XML original?

Bom dia amigo. Vamos analisar os itens. Emitente é aquele emite o cte, certo? Portanto a transportadora. Então se analisarmos o erro ele está dizendo que seu cliente não está autorizado a emitir cte para esse modal. O que deve ser feito, o contador deve solicitar a sefaz o credenciamento em ambiente de produção e homologação desse estado, para que possa estar emitindo. Verifique, que alguns contadores as vezes credenciam errado as empresas, acabam fazendo pra NF-e ao invés de CT-e. Outro caso também, é que alguns estados exigem que enviem uns 10 ctes em homologação pra depois ir pra produção.

Chegou a testar fora do acbr? Já peguei um caso desse, que era problema do cartão e do leitor.. Faz um teste fora pra ver.

Resolvido, Amigo Valeu mesmo, como estamos com XE e D7 e a partir de sua dica descobrimos o problema em Environment Options ; apontando caminho errado pra versão Valeu Obrigado Pela força JR

Boa Tarde, Colegas Atualizei ontem a Noite (8/5/2017) os Fontes , para Delphi 7 (ainda estamos migrando),. porem ao compilar TNFeStatusServico.TratarResposta: Boolean; não esta localizando a rotina: SeparaDadosArray FPRetWS := SeparaDadosArray(['nfeStatusServicoNF2Result'], ['NfeStatusServicoNFResult'], ['nfeResultMsg'],FPRetornoWS ); Alguém sabe aonde posso localiza-la grato Junior

Valeu parceiro, resolveu aqui...

Bom dia.. Desculpe minha ignorância, mas em que momento teria que utilizar isso? é Obrigatório?

Estou tendo esse problema também, estranho que isso ocorre em apenas um cliente. Notei também que ele é o único que no nome do certificado não vai o CNPJ.. normalmente os outros vem assim RAZÃOSOCIAL:CNPJ esse é o único e ele apresenta o erro em qualquer estação..

Paulo,você fez aquele passo da instalação da cadeia de certificados na pasta raiz? da ICP brasil? Em todos os meus clientes após fazer isso funcionou na hora, independente do sistema operacional ou service pack.