Painel de líderes

Bom dia a todos, Já esta disponível em nossa biblioteca a Nota Técnica 2019/001 versão 1.10 que trata sobre novas regras de validação. Essa nova versão é uma complementação da anterior que inclusive o seu resumo se encontra aqui. Resumo da NT:  • Criação/Alteração de regras de validação referentes a CST e Código de Benefício Fiscal, corrigindo algumas regras da versão anterior. • Criação de regra de validação correspondente rejeição 927, para informar os números dos itens em ordem sequencial. • Define que a regra de validação referente ao valor máximo da base de cálculo é por modelo de DF-e. Datas previstas para entrada em vigor: 22/07/2019 - Ambiente de Homologação; 02/09/2019 - Ambiente de Produção. Alterações no componente: Nenhuma, visto que essa NT trata de novas regras de validação a serem implementadas pelas SEFAZ-Autorizadoras. Alterações na aplicação do desenvolvedor: Por conta da regra H02-10, a aplicação ao atribuir o numero do item ao campo: Prod.nItem, este tem que ser um numero sequencial, consecutivo e iniciado por 1. Para quem utiliza o ACBrMonitor, não precisa se preocupar, pois o mesmo utiliza um numero sequencial, consecutivo e iniciado por 1 para o numero do item. Novas Regras de Validação: Criada a Regra de Validação H02-10, com o objetivo de informar os números do item em ordem sequencial. Criadas regras de validação a Tributo - ICMS:  Criada a Regra de Validação N12-86, impedindo que se informe o código de benefício fiscal para CST de benefício fiscal, a critério da unidade federada. Rejeição 928: Informado código de benefício fiscal para CST sem benefício fiscal (campo cBenef) [nItem: nnn] Se informado CST e informado código de benefício fiscal: - Verificar se CST possui código de benefício fiscal, conforme tabela de código de benefício fiscal por UF. Observação 1: Implementação a critério da UF e por modelo de DF-e. Observação 2: Tabela de código de benefício fiscal por UF publicada no Portal Nacional da NF-e. Regras que tiveram seu (Campo-Seq) alterado bem como a sua redação: Regra N07-10 agora é N12-97. Rejeição 929: Informado CST de diferimento sem as informações de diferimento [nItem: nnn] Nova Redação: Não informados campos de valores do CST 51 (Diferimento): - modBC (id: N13), pRedBC (id: N14), vBC (id: N15), pICMS (id: N16), vICMSOp (id: N16a), pDif (id: N16b), vICMSDif (id: N16c), vICMS (id: N17). Observações: Implementação a critério da UF. Regra N12-84 agora é N12-85. Rejeição 930: CST com benefício fiscal e não informado o código de benefício fiscal (campo: cBenef) [nItem: nnn] Nova redação: Se informado CST e não informado código de benefício fiscal: - Verificar se CST exige código de benefício fiscal (tag: cBenef), conforme tabela de código de benefício fiscal por UF. Observação 1: Implementação a critério da UF, por modelo de DF-e e por CST. Observação 2: Tabela de código de benefício fiscal por UF publicada no Portal Nacional da NF-e Regra N12-88 agora é N12-94. Rejeição 931: Informado código de benefício fiscal (campo: cBenef) incompatível com CST e UF [nItem: nnn] Nova Redação: Se informado CST e informado código de benefício fiscal: - Verificar código de benefício fiscal está vigente e corresponde ao CST informado, conforme tabela de código de benefício fiscal por UF. Observação1: Tabela de código de benefício fiscal (cBenef) publicada no Portal Nacional da NF-e. Nota: Para itens sem benefício fiscal, a UF poderá exigir a informação da literal “SEM CBENEF” para alguns CST, vide tabela publicada no Portal Nacional da NF-e.

Enviei para o repositório, rev. 17345, com algumas alterações: - Observação não estava sendo mostrada no MDFe em contingência - Aumentei espaçamento antes da impressão das observações - Inseri transparência em alguns textos para não sobrepor a marca d'agua - A URL de consulta será obtida a partir do arquivo ACBrMDFeServicos.ini. Importante: De acordo com o manual do DAMDFE 3.00a: Então alguns dados que eram impressos no modelo anterior foram removidos: - Número do CIOT - Valor da mercadoria - RENAVAM do veículo Caso haja necessidade de incluir novamente essas informações será necessário definir a melhor forma de se fazer isso. Mais uma vez obrigado pela contribuição.

Certamente é problema na ATM. Eles não podem recusar nem pedir pra alterar um XML autorizado.

Vou fazer uma refatoração e ajustar isso no instalador

era o shemas tinhao alterado o caminho da pasta, obrigado

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 17347. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Bom dia Marcos, No manual consta como facultativo, mas existe um observação abaixo dessas regras que diz que a SEFAZ poderá ativar ou desativar essas regras caso ela consiga ou não ter acesso ao sistema da ANTT para poder fazer as devidas validações referente ao RNTRC.

Testado e tudo certinho...

Olá pessoal, Para quem utiliza o ACBrMonitor e necessita emitir um CT-e de Substituição deve incluir no arquivo INI a seção [infCteSub] Vamos a estrutura completa da seção: [infCteSub] chCte= chave do cte a ser substituido (original) indAlteraToma= se informado 1 significa que tem alteração de tomador refCteAnu= chave do cte de anulação caso tenha sido emitido refNFe= chave da nfe de anulação do tomador caso ele tenha emitido refCte= chave do cte de anulação do tomador caso ele tenha emitido (quando o tomador for outra transportadora) ; preencher os campos abaixo se o tomador tenha emitido uma Nota Fiscal comum de papel CNPJ= mod= serie= subserie= nro= valor= dEmi= Exemplo 1: Caso tenha sido emitido um CT-e de Anulação [infCteSub] chCte= chave do CTe a ser substituido (original) indAlteraToma= se informado 1 significa que tem alteração de tomador refCteAnu= chave do CTe de anulação Exemplo 2: Caso o tomador tenha emitido uma NF-e de Anulação [infCteSub] chCte= chave do cte a ser substituido (original) indAlteraToma= se informado 1 significa que tem alteração de tomador refNFe= chave da NFe de anulação emitida pelo tomador Exemplo 3: Caso o tomador tenha emitido uma Nota Fiscal comum de papel [infCteSub] chCte= chave do cte a ser substituido (original) indAlteraToma= se informado 1 significa que tem alteração de tomador ; abaixo dados da Nota Fiscal comum de papel CNPJ= mod= serie= subserie= nro= valor= dEmi= Exemplo 4: Caso o tomador seja uma transportadora e tenha emitido um CT-e [infCteSub] chCte= chave do cte a ser substituído (original) indAlteraToma= se informado 1 significa que tem alteração de tomador refCte= chave do cte emitido pelo tomador quando este é uma outra transportadora

A libxml2.dll que não entende o regex da forma como vem nos schemas oficiais. Se você configurar SSLXmlSignLib como xsMsXML, para usar a depreciada msxml5.dll, deve validar com o schema oficial. Não sei dizer se os schemas oficiais estão fora de algum padrão ou é limitação da libxml2. Em todo caso estou enviando o Schema alterado para o repositório.

Quais são as mudanças dessa nova versão 3.00a? Um breve resumo. Criação do Web Service síncrono de autorização Disciplina as regras para Uso Indevido Definição do QR Code do CT-e: RV´s 850 a 855 ; Definição da Consulta Pública resumida e consulta completa para atores do CT-e identificados pelo certificado digital; Eliminação do retCancCTe na resposta da consulta situação; Criação da tag ICMSST no evento EPEC e alteração da RV 642; RV 841 para informar fretamento no transporte de pessoas; Alteradas RV´s 837, 838, 839, 840: aplicar somente aos tipos Norm / Subst.; Unificação das regras de validação de chave de acesso: 592-596, 507, 610 => 236 701-708 => 842 (Chave do CT-e da ferrovia de origem) 591, 602-605, 508, 504 = > 843 (Chave da NF-e transportada) 544-549, 480, 538 => 844 (Chave do documento anterior) 450-454, 478, 479, 608 => 845 (Chave do CT-e multimodal) 761-768 => 846 (Chave do CT-e anulado) 769-776 => 847 (Chave do CT-e substituído) 777-784 => 849 (Chave CT-e complementado) 816-823 => 856 (Chave do CT-e cancelado referenciado no CT-e OS) 761-772, 615, 766-768 => 857 (Chave do CT-e OS anulados) 769-772, 616, 774-776 => 858 (Chave do CT-e OS substituído) 777-780, 785, 782-784 => 859 (Chave do CT-e OS complementados) RV 848: Validação chave de acesso do CT-e de anulação informado Criação do evento do comprovante de entrega (grifado no MOC em amarelo), RV´s 860, 863, 864, 865, 869, 870 e 871 Criação do evento de cancelamento do comprovante de entrega (grifado no MOC em amarelo), RV´s 866 RV do cancelamento associada ao comprovante de entrega: 862 RV de validação da IE do tomador na EPEC: Dispensa de validação da IE do tomador quando autorização de um CT-e EPEC RV para implementação a critério da UF para o responsável técnico: 867 Previsão de RV de implementação futura para o responsável técnico: 868 Exclusão da tag pICMSInterPart do leiaute do CT-e e CT-e OS (ver anexo I Leiaute). Em nossa biblioteca você encontram os 3 Manuais (Visão Geral, Layout e DACTE) da versão 3.00a clique aqui para ter acesso.

Bom dia. Notei que ainda não haviam incluído na impressão do MDFe o QR-Code (FR) e realizei a alteração. Agradeço se puderem adicionar no SVN. Segue anexo fonte, e um dos fr3 que já realizei a alteração (apenas com a inclusão do QR-Code). Pretendo realizar outras modificações no meu FR3, e quando concluir posso disponibilizar caso seja de interesse de outros. ACBrMDFeDAMDFEFR.pas DAMDFe_Retrato.fr3

O ACBrBancoBanese não estava de acordo com o Manual do banco, inclusive no cálculo do digito verificador do nosso número, então fiz algumas mudanças no mesmo. Fiz os testes e homologuei a remessa e os boletos junto ao banco. A homologação foi feita com sucesso. Seguem as alterações realizadas e o arquivo ACBrBancoBanese.pas com as alterações realizadas. Seria bom subir o pas não? function TACBrBancoBanese.CalcularDigitoVerificador( const ACBrTitulo: TACBrTitulo ): String; var ADigitoNossoNumero : string; begin Modulo.CalculoPadrao; Modulo.MultiplicadorFinal := 13; Modulo.Documento := ACBrTitulo.NossoNumero; Modulo.Calcular; AdigitoNossoNumero :=IntToStr(Modulo.DigitoFinal); Result:= AdigitoNossoNumero; end; // NÃO LEVAVA EM CONTA A AGÊNCIA NO DOCUMENTO (AAANNNNNNNN) E PARA QUE MultiplicadorFinal:= 13 ? // TROCADO POR function TACBrBancoBanese.CalcularDigitoVerificador( const ACBrTitulo: TACBrTitulo ): String; begin Modulo.CalculoPadrao; Modulo.Documento:= PadLeft(ACBrTitulo.ACBrBoleto.Cedente.Agencia, 3, '0') + RightStr(ACBrTitulo.NossoNumero, 8); Modulo.Calcular; Result:= IntToStr(Modulo.DigitoFinal); end function TACBrBancoBanese.MontarCampoNossoNumero ( const ACBrTitulo: TACBrTitulo ) : String; begin ACBrTitulo.NossoNumero := IntToStrZero( StrToIntDef((Trim(ACBrTitulo.NossoNumero)+Trim(CalcularDigitoVerificador(ACBrTitulo))),0) ,Self.TamanhoMaximoNossoNum); Result := ACBrTitulo.NossoNumero; end; // ACBrTitulo.NossoNumero:= ... MODIFICA O NOSSO NÚMERO, ACRESCENTANDO O DIGITO AO MESMO. // E SE VC PRECISAR CHAMAR A FUNÇÃO UMA SEGUNDA VEZ (PARA GRAVAR O NOSSO NRO MONTADO POR EXEMPLO) VAI BUGAR // PORQUE VC ESTARÁ CRIANDO UM NOVO NOSSONUMERO (AGORA COM O DIGITO) PARA CALCULAR UM NOVO DIGITO // TROCADO POR function TACBrBancoBanese.MontarCampoNossoNumero ( const ACBrTitulo: TACBrTitulo ) : String; begin result:= IntToStrZero( StrToIntDef((Trim(ACBrTitulo.NossoNumero)+Trim(CalcularDigitoVerificador(ACBrTitulo))),0) ,Self.TamanhoMaximoNossoNum); end; function TACBrBancoBanese.CalcularCampoASBACE(const ACBrTitulo: TACBrTitulo): string; ANossoNumero := Copy(Trim(ACBrTitulo.NossoNumero), 1, ACBrTitulo.ACBrBoleto.Banco.TamanhoMaximoNossoNum); // TROCADO POR ANossoNumero := MontarCampoNossoNumero(ACBrTitulo); ACBrBancoBanese.pas

Bom dia a todos, 18/06/2019 Comunicado sobre as datas de implantação da versão 3.00a Comunicamos que foi publicado a versão 3.00a do Manual de Orientação do Contribuinte do CT-e/CT-e OS e seus anexos. Reforçamos que esta nova versão prevista para entrar em homologação a partir do dia 22 de Julho de 2019 e em produção a partir do dia 26 de Agosto de 2019, contempla a atualização do schema do CT-e, criação do Evento Comprovante de Entrega dentre outras modificações. Relativamente à definição dos padrões do QRCode previstos no arquivo XML do CT-e, cuja especificação das configurações para impressão no DACTE estão detalhadas no Anexo II – Manual de Especificações Técnicas do DACTE, serão implementadas a partir de 07 de Outubro de 2019, quando entrará em vigor a obrigatoriedade de exibição do QRCode no layout do DACTE. Da mesma forma, as RV G238 a G243 e N135 a N140 passarão a ser aplicadas em 02/09/2019 no ambiente de homologação e somente em 07 de Outubro de 2019 no ambiente de produção.

Bom dia, Fiz 2 correções para a leitura do XML do provedor Agili, segue units alteradas. pnfsLerListaNFSe.pas pnfsNFSeR.pas

Boa tarde Fátima, Se o tomador do serviço é do exterior não tem como informa-lo no grupo de informações do contratante, pois nesse grupo só podemos informar o CNPJ ou CPF do mesmo.

Olá pessoal, Para quem utiliza o componente ACBrCTe e necessita emitir um CT-e de Substituição deve alimentar os seguintes campos: Vamos a estrutura completa: with infCTeNorm.infCteSub do begin chCte := chaveCTeOriginal; indAlteraToma := tiNao ou tiSim; // Se atribuir tiSim significa que foi alterado o tomador // Para tomador contribuinte do ICMS tomaICMS.refNFe := chaveNFe; // NF-e de anulação emitenta pelo tomador // ou informações da Nota Fiscal comum de papel emitida pelo tomador tomaICMS.refNF.CNPJCPF := sCNPJCPF; tomaICMS.refNF.modelo := sModelo; tomaICMS.refNF.serie := iSerie; tomaICMS.refNF.subserie := iSubSerie; tomaICMS.refNF.nro := iNumero; tomaICMS.refNF.valor := vValor; tomaICMS.refNF.dEmi := DataEmissao; // ou a chave do CT-e emitido pelo tomador quanto este for uma transportadora tomaICMS.refCte := ChaveCTeTomador; // caso tenha sido emitido o CT-e de Anulação informar a chave do mesmo no campo abaixo refCteAnu := ChaveCTeAnulacao; end; Exemplo 1: Caso tenha sido emitido um CT-e de Anulação with infCTeNorm.infCteSub do begin chCte := chaveCTeOriginal; indAlteraToma := tiNao ou tiSim; // Se atribuir tiSim significa que foi alterado o tomador // CT-e de Anulação informar a chave do mesmo no campo abaixo refCteAnu := ChaveCTeAnulacao; end; Exemplo 2: Caso o tomador tenha emitido uma NF-e de Anulação with infCTeNorm.infCteSub do begin chCte := chaveCTeOriginal; indAlteraToma := tiNao ou tiSim; // Se atribuir tiSim significa que foi alterado o tomador // Para tomador contribuinte do ICMS tomaICMS.refNFe := chaveNFe; // NF-e de anulação emitenta pelo tomador end; Exemplo 3: Caso o tomador tenha emitido uma Nota Fiscal comum de papel with infCTeNorm.infCteSub do begin chCte := chaveCTeOriginal; indAlteraToma := tiNao ou tiSim; // Se atribuir tiSim significa que foi alterado o tomador // Informações da Nota Fiscal comum de papel emitida pelo tomador tomaICMS.refNF.CNPJCPF := sCNPJCPF; tomaICMS.refNF.modelo := sModelo; tomaICMS.refNF.serie := iSerie; tomaICMS.refNF.subserie := iSubSerie; tomaICMS.refNF.nro := iNumero; tomaICMS.refNF.valor := vValor; tomaICMS.refNF.dEmi := DataEmissao; end; Exemplo 4: Caso o tomador seja uma transportadora e tenha emitido um CT-e with infCTeNorm.infCteSub do begin chCte := chaveCTeOriginal; indAlteraToma := tiNao ou tiSim; // Se atribuir tiSim significa que foi alterado o tomador // chave do CT-e emitido pelo tomador quanto este for uma transportadora tomaICMS.refCte := ChaveCTeTomador; end;

Boa tarde Christiano, Neste ultimo XML o campo CRT continua com o valor 1, tem que ser 2 ou 3.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Felipe, Não precisa alterar nenhuma propriedade de configuração, apenas atualize todos os fontes de todas as pastas e reinstale a suíte ACBr usando o ACBrInstall_Trunk2 com a opção apagar arquivos antigos marcada.

Estamos ai ..

Muito obrigado!!! Utilizando este funcionou perfeitamente!!! Vou atrás agora da versão do FastReport para me manter atualizado, mas por hora me ajudou muito! Grato a todos pela ajuda!

Boa tarde... resolvi da seguinte forma.... Quando o transporte eh feito por transportadora terceirizada, preencho os dados do veículo na tag 'prop' with rodo.veicTracao.prop do begin CNPJCPF := ''; RNTRC := ''; xNome := ''; IE := ''; UF := ''; tpProp := ''; end; e NÃO informo o RNTRC em nenhuma outra tag.

Sua pasta de Schemas está desatualizada.

Bom dia, Não sei se tem alguma relação, mas na imagem o nosso numero está diferente em alguns campos. Está '19200002' e '19/200002'. Tem essa barra aí no meio. É certo isso?

Olá, A forma de alteração você deve implementar no seu sistema com as opções disponíveis. A Tag que deve ser presenciada é a tPag<> dentro dos detalhes do pagamento: 1=Dinheiro 02=Cheque 03=Cartão de Crédito 04=Cartão de Débito 05=Crédito Loja 10=Vale Alimentação 11=Vale Refeição 12=Vale Presente 13=Vale Combustível 15=Boleto Bancário 90=Sem Pagamento; 99=Outros.

Bom dia Ricardo, Procurando por essas propriedades notei que elas estão presentes para o DANFE feito em Fast Report. Caso queira colaborar com o projeto e implementar no DACTE, DAMDFE e DANFSE aos moldes do DANFE ficaremos gratos.

Bom dia Luiz, No componente ACBrCTe temos uma propriedade chamada DACTE, esta contem o componente de impressão, ou seja, o ACBrCTEDACTEFR ?

Sim a versão que vem com o Delphi, vou testar e retorno.

Olá Fabrício. Então, o veículo é de terceiros, porém com contrato de agregado, desta forma, junto a ANTT, o registro é feito em nome do emitente (devido ao contrato)

Ítalo muito obrigado, funcionou corretamente depois de colocar da forma como vc sugeriu.

Vou Manter o tópico pra informar a todos que o ambiente de homologação esta dando rejeição 203 (Emissor não habilitado), o ambiente de produção funciona perfeitamente, estou a 2 dias tentando no ambiente de homologação mdfe goiás sem sucesso.

Pois é, busquei ajuda em uma loja que vende produtos da bematech e a primeira coisa e o técnico me falou é que essa impressora é uma bomba.

Boa tarde, Realizei as outras alterações (praticamente refiz) do leiaute do DAMDFe, contudo tenho apenas como testar o modal rodoviário. (Caso alguém trabalhe com outros modais, e queira testar, ou disponibilizar XMLs de outros modais para que eu faça o teste de impressão, só informar). DAMDFe_3a.fr3

Boa tarde! Tenta por aqui: https://dfe-portal.svrs.rs.gov.br/Mdfe

A 16º Firebird Developers Day - (FDD) ocorrerá no dia 3 de Agosto, em Piracicaba - SP. Este evento é o maior evento sobre banco de dados Firebird no mundo (em número de participantes). Uma chance que os desenvolvedores brasileiros tem de se aprofundar nos mais variados assuntos relacionados ao SGBDR, trocar experiências e ter contato direto com especialistas do Brasil e do exterior. O Projeto ACBr estará presente! Conheça pessoalmente as vantagens de ser membro do SAC ACBr. Saiba os preços de aquisição e renovação da sua licença Delphi. Compre ingressos para o Dia do ACBr com preço promocional! Visite nosso Stand na Firebird Developers Day para receber um cupom de desconto exclusivo!

Meu arquivo estava realmente desatualizado. Baixei novamente e inclui nele o QR-Code. Neste arquivo apenas inclui a informação do QR-Code, pois foi a minha necessidade imediata para disponibilizar para os clientes. Estou verificando as demais alterações para alterar os outros modelos. DAMDFe_Retrato.fr3

@BigWings, erro meu, você está certo. Eu citei que havia feito conforme o DANFCe em EscPos mas está diferente. O EscPos gera o valor a pagar com o vNF. Alterei para ficar igual. A ideia é justamente essa, deixar igual ao EscPos, que busca o valor da tag, em vez de fazer conta e correr risco de deixar a soma diferente do XML. Anexei com essa alteração. Obrigado. ACBrNFeDANFEFRDM.pas

Boa tarde a todos, O componente ACBrCTe tem uma propriedade de configuração chamada: GerarInfCTeSupl que pode receber os seguintes valores: fgtNunca = não vai gerar no XML o grupo InfCTeSupl que contem a string do QR-Code; fgtSomenteProducao = só gera se o componente estiver configurado para o ambiente de Produção; fgtSomenteHomologacao = só gera se estiver configurado para o ambiente de Homologação fgtSempre = vai gerar no XML o grupo InfCTeSupl. O valor padrão é fgtNunca, mas a partir do dia 22/07/2019 para realizar testes no ambiente de homologação essa propriedade deve estar com o valor fgtSomenteHomologacao. E a partir do dia 26/08/2019 para o envio em ambiente de produção a propriedade devera esta com o valor fgtSomenteProducao ou fgtSempre. Quando se tornar obrigatório em ambos ambientes iremos remover essa propriedade de configuração do componente.

Boa tarde a todos, O componente ACBrMDFe tem uma propriedade de configuração chamada: GerarInfMDFeSupl que pode receber os seguintes valores: fgtNunca = não vai gerar no XML o grupo InfMDFeSupl que contem a string do QR-Code; fgtSomenteProducao = só gera se o componente estiver configurado para o ambiente de Produção; fgtSomenteHomologacao = só gera se estiver configurado para o ambiente de Homologação fgtSempre = vai gerar no XML o grupo InfMDFeSupl. Essa propriedade em breve vai deixar de existir, uma vez que a exigência em ambos os ambientes já foi ativada pela SEFAZ.

O Instalador não compila em 64 bits... isso deve ser definido no seu projeto... @Juliomar Marchetti, os DCUs de 64 bits não deveriam seriam gerados em uma pasta separada ?

Apliquei modificações que devem atender a sugestão... Mas preservei uma funcionalidade, que acho importante... O programador, poder introduzir um valor na calculadora, antes de Chamar o Execute... Exemplo: procedure TfrExtenso.Button1Click(Sender: TObject); begin ACBrCalculadora1.Valor := 123; ACBrCalculadora1.Execute; end; commit: 17052

Segue projeto completo testado no meu código de beneficiário para inclusão, alteração, baixa e consulta de boletos no web service caixa. Projeto testado em Delphi 10.2, para Delphi 7 ou inferior é necessário substituir a função Hash e SHA256! Certifique-se que seu código de beneficiário está liberado na sua agência para o uso de Web Service. Preencha os campos sendo a primeiro boleto Numero 1. Seja feliz! Agradeço a contribuição de todos e espero que possa ajudar! CAIXA SOAP WSDL.rar

Olá pessoal, eu gostaria de tirar uma dúvida em relação as nomenclaturas descritas abaixo referente ao CTE. Está correto o significado das nomenclaturas abaixo? - Emitente....: Quem gera o CTE; - Tomador....: Quem paga o frete; - Remetente.: Quem esta enviando a mercadoria; - Destinatário: Quem receberá a mercadoria; - Expedidor...: Aquele que entregar a carga ao transportador para efetuar o serviço de transporte; - Recebedor..: Aquele que deve receber a carga do transportador; O expedidor se assemelha muito com o remetente e o recebedor com o destinatário, isso confunde um pouco. Att. Carlos Fitl.

Bom dia Luan, Por favor siga as regras do fórum, para questões novas, tópico novo. Este tópico se refere a nomenclatura de arquivos do CT-e. Respondendo a sua duvida, no meu entendimento, quando temos uma data ou período, bem como o horário ou faixa de horário que vai ocorrer a entrega devemos preencher os campos do grupo complemento. caso contrario devemos apenas informar a dPrev.

Olá Italo, Tenho uma dúvida em questão a data de entrega do CT-e, estou utilizando o Emissor de Teste de SP para tirar algumas dúvidas a respeito de informações do XML que não estão especificados na documentação do CT-e; A minha dúvida é a seguinte; Nas tags do Modal tem a seguinte Tag <dPrev>2015-02-25</dPrev> no qual se refere a data de previsão de entrega. E na tag <compl> tenho as seguintes informações com data prevista de entrega; <Entrega> <noPeriodo> <tpPer>4</tpPer> <dIni>2015-03-02</dIni> <dFim>2015-02-06</dFim> </noPeriodo> <comHora> <tpHor>1</tpHor> <hProg>01:02:03</hProg> </comHora> </Entrega> A minha dúvida é a seguinte, qual a diferença entre as duas datas, Data Prevista de Entrega e Previsão de Entrega?

Tomador - somente especificar quando for um terceiro que não seja os outros. Expedidor - é o que entrega a carga a ser transportada, quando não for o remetente. Uma empresa de logisitica ou outra transportadora entregar a carga. Recebedor - mesmo caso do expedidor, é quem receberá a carga. Se você transportar e entregar até outra transportadora ou empresa, esta será o recebedor. O antigo consignatário da mercadoria deverá ser colocado no TOMADOR.

Boa tarde Guarasemini Veja o que foi postado neste link: http://www.forumweb.com.br/foruns/topic ... or__st__40

Muito bom, tava precisando dessa explicação também vlw

Beleza Italo, mais claro que isso não tem. Muito obrigado. Att. Carlos Fitl.