Italo Giurizzato Junior

Boa tarde Graça, Favor atualizar todos os arquivos do Branches e refaça os testes com as alterações que fiz.

Boa noite Graça, Você tem o XML de envio que não ocorreu erro com o HTTPReqResp1 ?

Boa noite Gean, Não seria mais fácil da seguinte forma? var i: Integer; begin i := ACBrNFe1.NotasFiscais.Count;

Boa noite André, O arquivo em anexo não consta a alteração.

Boa noite Sidnei, Muito obrigado pela colaboração, já enviei para o repositório.

Boa noite Lucas, Será que o numero que esta sendo informado não se refere a uma nota que já foi emitida e depois cancelada.

Boa tarde André, Sim devemos fazer os ajustes primeiro no TnfseNaturezaOperacao.

Boa tarde Solivan, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde Renesul, Você sabe se esse provedor segue o layout da ABRASF?

Leonardo, Se a rede possui um Proxy devemos configurar o componente com os dados do Proxy. Com o proxy desabilitado funciona e com ele habilitado não funciona, de duas ou uma, você esta configurando o componente de forma errada ou o proxy esta bloqueando o acesso a internet. Verifique se no proxy é necessário liberar alguma porta ou URL.

Bom dia ALA, Vamos as regras de negócio que consta no Manual do CT-e versão 3.00 - página 42 Regra: G46 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e Tipo de Serviço for DIFERENTE de Redespacho Intermediário ou Serviço Vinculado a Multimodal: - O grupo de Documentos Transportados (infDoc) deve ser informado. O que temos dentro do grupo <infDoc>? Os grupos <infNF> (Este grupo deve ser informado quando o documento originário for NF), <infNFe> (nformações das NF-e) e <infOutros> (Informações dos demais documentos). Note que os 3 são CG que significa que no CT-e só pode ter um dos 3 tipos e a ocorrência é de 1-n que significa que pelo menos UM documento deve ser informado (páginas 169, 171 e 173). Voltando a regra G46 você só não vai gerar o grupo <infDoc> se o seu cliente emitir um CT-e cujo tipo de serviço for Redespacho Intermediário, neste caso ele esta transportando uma carga de uma transportadora A para uma transportadora B ou presta serviço vinculado a Multimodal (https://www.bsoft.com.br/voce-sabe-o-que-e-cte-multimodal-e-cte-vinculado-a-multimodal/). Espero ter ajudado.

Bom dia Alex, O problema deve estar no tamanho da informação, no caso do TAF tem que ter 12 dígitos e no NroRegEstadual tem que ter 25 dígitos.

Bom dia Roberto, No caso do CT-e OS com tpServ = 6 (Transporte de Pessoas) temos duas situações. 1. Fretamento "coletivo", neste caso temos a empresa X que realiza o transporte dos funcionários da empresa Y. É a empresa Y que vai pagar pelo transporte, logo é ela que é o tomador, sendo assim no grupo <toma> devemos informar os dados da empresa Y. 2. Fretamento "individual", neste caso temos a empresa X que realiza o transporte de pessoas e são estas que vão pagar pelo transporte, logo cada uma dessas pessoas são tomadores, sendo assim no grupo <toma> devemos informar os dados de cada pessoa. Como só podemos informar apenas UM tomador, logo a empresa X deverá emitir um CT-e OS para cada pessoa. Veja a descrição da tag <toma> -> "Informações do Tomador/Usuário do Serviço" Agora no que se refere a emitir um CT-e OS para cada dia de transporte não sei lhe informar com exatidão, uma vez que no Manual não temos nenhuma informação que diz que tem que ser diário ou pode ser mensal. Acredito que nem a SEFAZ ou um Contador será capaz de responder essa pergunta.

Bom dia Helio, Segundo a página 155 do Manual do CT-e versão 3.00 temos 3 tags: cMunFim, xMunFim e UFFim. Elas se referem ao código IBGE do Município, nome do Municipio e a UF do mesmo. Note que na descrição da tag consta: "do término da prestação" No meu entendimento a primeira transportadora prestou o serviço de transportar a mercadoria do Município A - SP até o Município B - SP. A segunda transportadora vai prestar o serviço transportando a mercadoria do Município B - SP até o Município C - RS. Sendo assim a primeira transportadora deve informar nas tags mencionadas acima que se referem ao término da prestação o Município B - SP. Entendo que nem sempre o local de término da prestação é o mesmo de entrega. Espero ter ajudado.

Bom dia Graça, Favor atualizar os fontes do Branches. Fiz uma correção na Unit: ACBrANeDocumentos.pas

Bom dia Leonardo, Não se ofenda pela minha pergunta, mas tenho que fazer, visto que outros já cometeram esse erro. Você não colocou no proxy as informações para o envio de e-mail, tais como usuário, senha, etc.

Bom dia Diego, O tag <mod> do MDFe só aceita o valor 58 e você informou o valor 01.

Bom dia Arturo, O XML de envio de evento esta faltando o numero de protocolo de autorização do MDF-e. Veja: <descEvento>Encerramento</descEvento> <nProt/> <dtEnc>2017-09-09</dtEnc> <cUF>41</cUF> <cMun>4113700</cMun> Se no comando do Monitor esta sendo informado o numero do protocolo, então existe um erro no Monitor que não esta considerando essa informação.

Boa noite Alex, Veja o erro: <rodoOS> <TAF>123456789</TAF> <NroRegEstadual>32165497</NroRegEstadual> <veic> <placa>KYH8757</placa> <RENAVAM>482176881</RENAVAM> <UF>RJ</UF> </veic> </rodoOS> Ou você informa o TAF ou o NroRegEstadual os dois não pode.

Boa noite ALA, Desculpa, mas é sempre bom ter em mãos o Manual do CT-e, pois nele temos muita coisa. Ao emitir um CT-e é preciso informar pelo menos um documento originário, emitido pelo remetente da carga. O documento originário pode ser uma NF-e ou Outros (Declaração, Carta Remessa de Mercadoria, etc). Cuidado, se o remetente da carga é obrigado a emitir NF-e, para este não podemos informar um documento originário como sendo Outros, o CT-e vai ser rejeitado pela SEFAZ. Caso o CT-e tenha mais de UM documento originário, lembre-se que todos tem que ser do mesmo tipo, ou seja, todos tem que ser NF-e ou Outros, se misturar o CT-e vai ser rejeitado.

Boa noite Leonardo, Você esta configurando no componente o proxy? Se você tem um proxy na sua rede é preciso configurar o componente, caso contrario não vai funcionar.

Boa tarde Graça, Isso ocorre quando colocamos os dois componentes na mesma Unit. A solução é bem simples, veja como eu fiz na minha aplicação. case DM_CTA.ParamDFeVersaoDF.AsInteger of 1: ACBrCTe.Configuracoes.Geral.VersaoDF := pcteConversaoCTe.ve200; 2: ACBrCTe.Configuracoes.Geral.VersaoDF := pcteConversaoCTe.ve300; end; Desta forma deixa claro que o valor ve200 se refere ao tipo TVersaoCTe e não outro.

Boa tarde Arturo, Favor anexar o XML referente ao envio do Evento.

Boa tarde Eduardo, O XML que você anexou não esta protocolado. Já o PDF mostra que o mesmo foi, logo você anexou o XML incompleto. Outra coisa quando um MDF-e é encerrado o XML do mesmo não é alterado, visto que o encerramento é um evento vinculado ao MDF-e e tem a sua própria impressão. Se não me falha a memória o componente de impressão do DAMDFE possui uma propriedade que ao atribuir o valor True é apresentado a mensagem MDF-e Encerrado. Sendo assim, a impressão ou não dessa mensagem depende dessa propriedade e quem deve atribuir o valor True ou False a mesma é a sua aplicação.

Boa tarde Arturo, O comando esta errado: MDFe.EncerrarMDFe("42170202959017000104580010000000011248668580", "09/09/2017", "4100905", "02959017000104", "1") O parâmetro em negrito se refere ao código IBGE do município onde ocorreu o último descarregamento, só que código informado se refere ao código do município de carregamento. O correto seria: <cMunDescarga>4113700</cMunDescarga> Uma vez que o MDF-e que você anexou só possui um único município de descarregamento. MDFe.EncerrarMDFe("42170202959017000104580010000000011248668580", "09/09/2017", "4113700", "02959017000104", "1")