Italo Giurizzato Junior

Bom dia a todos, Por favor atualizem os fones e façam novos testes, fiz uma correção na função: TipoCargaToStr, pois ela estava retornando uma string contendo a descrição do tipo da carga em vez dos valores 1, 2, ...

Bom dia Thiago, Por favor não misture as coisas, esse tópico esta sendo tratado sobre a unit pcnConversãoCIOT. Se você pesquisar vai descobrir que existe um tópico em Noticias que trata sobre essa resolução.

Bom dia Cleonir, Esse tópico esta sendo tratado a unit pcnConversaoCIOT. Por favor vamos seguir as regras do fórum, tópico novo para assunto novo.

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

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

Bom dia Eduardo, Se você achou um tópico que diz que quando o CT-e é de Redespacho intermediário devemos informar o Expedidor como você conclui que ele nunca deve ser informado? Fora o Emitente do CT-e temos o Remetente, Destinatário, Expedidor e Recebedor. Quem são essas "pessoas"? Remetente é uma pessoa física ou jurídica que entrega a carga a uma transportadora para ser transportada. Destinatário é uma pessoa física ou jurídica que vai receber a carga. Expedidor é uma transportadora que expediu a carga para outra transportadora. Recebedor é uma transportadora que recebeu a carga de outra transportadora. Quando devemos informar essas "pessoas" em um CT-e? Um CT-e cujo tipo de serviço for normal ( tpServ = 0 ) devemos informar somente o Remetente e o Destinatário, nesse tipo de serviço a transportadora vai pegar a carga com o Remetente e levar até o Destinatário. No caso de redespacho temos 2 transportadoras envolvidas para realizar toda a tarefa, a primeira pega a carga com o Remetente e a segunda entrega a carga ao Destinatário. A transportadora 1 vai emitir um CT-e normal ( tpServ = 0 ), informar o Remetente, o Destinatário e o Recebedor (segunda transportadora). A transportadora 2 vai emitir um CT-e de redespacho ( tpServ = 2 ), informar o Remetente, o Destinatário e o Expedidor (primeira transportadora). No caso de redespacho intermediário temos 3 transportadoras envolvidas para realizar toda a tarefa, a primeira pega a carga com o Remetente e a terceira entrega a carga ao Destinatário. A transportadora 1 vai emitir um CT-e normal ( tpServ = 0 ), informar o Remetente, o Destinatário e o Recebedor (segunda transportadora). A transportadora 2 vai emitir um CT-e de redespacho intermediário ( tpServ = 3 ), informar o Expedidor (primeira transportadora) e o Recebedor (terceira transportadora). A transportadora 3 vai emitir um CT-e de redespacho ( tpServ = 2 ), informar o Remetente, o Destinatário e o Expedidor (segunda transportadora). Como você pode ver, se devemos informar ou não e quando informar tudo depende da situação. Para complementar leia o artigo:

Bom dia Gleryston, Correção feita e enviada para o repositório. Vou fechar o tópico.

Boa tarde Gleryston, Muito obrigado, vou fazer a devida correção e enviar para o repositório, assim que possível.

BigWings, Muito bem observado: 1 - Prestador de serviço de transporte 2 - Transportador de Carga Própria 3 - Prestador de serviço de transporte que emitirá CT-e Globalizado OBS: Deve ser preenchido com 2 para emitentes de NF-e e pelas transportadoras quando estiverem fazendo transporte de carga própria. Deve ser preenchido com 3 para transportador de carga que emitirá à posteriori CT-e Globalizado relacionando as NF-e.

Boa tarde BigWings, Você tem razão, por se tratar de mesma UF de descarregamento o mais pratico é emitir um só MDF-e e encerrar ele quanto o caminhão estiver vazio.

Augusto, Notei agora que se a cidade não for Mirassol é executado o método Enviar caso contrario é o Gerar. Esse tipo de abordagem para mim esta errada. O seu maior problema é o seguinte, nas linhas que contem o Items[0] você faz referencia a classe GerarNFSe que tem haver com o Gerar e não com o Enviar. Esta ai o seu erro. Quando ocorre um erro não necessariamente no envio do lote, mas sim não consulta por exemplo ele cai ai e vai checar o retorno, mas esse retorno que esta sendo checado é do Gerar e não do Enviar. Logo na lista de retorno do GerarNFSe não existe nenhum item. Você deve separar as coisas. Você deve ter um tratamento para o Enviar e outro para o Gerar.

Boa tarde Sergio, Experimente gerar o MDF-e cujo tpEmit=3 informando o grupo de NF-e que deve ser as mesmas do CT-e também emitido Globalizado.

Boa tarde a todos, Infelizmente o manual não deixa claro quais são os valores permitidos para essa tag, o jeito é entrar em contato com o eFrete e questiona-los.

Boa tarde Cesar, Acabei de testar usando o programa exemplos dos componentes ACBrCTe e ACBrMDFe configurados para acessar a SEFAZ-RS e não ocorreu nenhum erro. A única diferença é que eu estou usando o libWinCrypt em vez de libOpenSSL.

Boa tarde Augusto, Quanto a violação de acesso é preciso descobrir se esta ocorrendo no componente ou na sua aplicação. Pelo que entendi não é sempre que ocorre, ai fica difícil de descobrir. O Ginfes é meio problemático, quando não é uma coisa é outra com problema. Será que a violação de acesso não esta ocorrendo logo nas 3 primeiras linhas do seu except? Tem (..).Items[0].(...), não seria interessante checar se essa lista realmente possui itens?

Boa tarde Kebe, Se as cidades de descarregamento pertencem a mesma UF, a principio você vai emitir apenas 1 MDFe e enviar um único evento de encerramento informando a uf e o código do município do ultimo descarregamento. A não ser que a UF em questão exija que seja feito de forma diferente. Por exemplo: O Caminhão é carregado em Araraquara/SP vai até São Carlos/SP descarrega uma parte da carga, depois vai até Campinas/SP descarrega uma outra parte da carga, por fim vai até São Paulo/SP e descarrega o restante. Podemos emitir o MDF-e numero 1 com a carga total com destino a São Carlos/SP. Emitir o MDF-e numero 2 com a carga que vai restar em função do primeiro descarregamento, com carregamento em Araraquara/SP e com destino a Campinas/SP. Emitir o MDF-e numero 3 com a carga que vai restar em função do segundo descarregamento, com carregamento em Araraquara/SP e com destino a São Paulo/SP. Quando o motorista avisar que a carga destinada a São Carlos/SP foi descarregada, a transportadora envia o evento de Encerramento do MDF-e 1. Quando o motorista avisar que a carga destinada a Campinas/SP foi descarregada, a transportadora envia o evento de Encerramento do MDF-e 2. Quando o motorista avisar que a carga destinada a São Paulo/SP foi descarregada, a transportadora envia o evento de Encerramento do MDF-e 3. Espero ter ajudado. Para mais informações sobre o MDF-e te aconselho a ler a Cartilha do MDF-e, ela esta disponível no Portal do MDF-e. https://dfe-portal.svrs.rs.gov.br/Mdfe

Boa tarde Orlando, Se a transportadora estiver transportando carga lotação mas o caminhão é da empresa e o motorista é funcionário via CLT, a mesma ainda tem que informar o CIOT? A empresa que você se refere é a transportadora ou a proprietária do caminhão? O funcionário é da empresa proprietária do caminhão? Se é o que estou imaginando temos ai uma subcontratação do serviço. Quando uma empresa que não é transportadora contrata um TAC ela terá que gerar o CIOT? Se a empresa não é transportadora ela não vai gerar o CIOT, acredito eu que neste caso a geração fica a cargo do TAC. Segundo consta na Nota Técnica 2020/001 do MDF-e Integrado, deixa claro que o sistema MDF-e vai gerar o CIOT automaticamente, mas como isso e quando vai ocorrer não deixa claro. Eu acredito que alterações estão sendo feitas no MDF-e, não só no layout do XML, mas também no webservice da SEFAZ visando a integração com a ANTT e os IPEFs e consequentemente resultando na geração automática do CIOT entre outras coisas.

Boa tarde Cesar, Tente mudar a configuração de SSLXmlSignLib para xsLibXml2.

Boa tarde Elisson, Altere essa configuração para: E SSLType escolha a opção LT_TLSv1_2.

Boa tarde Nilton, Acho que você esta fazendo confusão, veja no caso do cancelamento. Se o evento de cancelamento for homologado, a situação do CT-e para efeito de consulta situação passará para “101 – Cancelamento homologado” e o retorno do status do evento será cStat=135. Quando enviamos o evento de cancelamento o status do evento é 135 que diz que o evento foi registrado e vinculado ao CT-e. Por outro lado se você consultar a situação do CT-e que foi cancelado o seu status vai ser 101 que diz que ele esta cancelado. Você esta confundindo a palavra homologado com o ambiente de homologação. Onde se lê Cancelamento homologado, entenda-se que o Cancelamento foi aceito. Já a Denegação não é um evento. Lembre-se que ao enviar um CT-e para SEFAZ, podem ocorrer 4 situações distintas: 1. O CT-e ser autorizado 2. O CT-e ser denegado 3. O CT-e ser rejeitado 4. Ocorrer um erro de conexão com a SEFAZ, neste caso não sabemos se o CT-e foi Autorizado, Denegado ou Rejeitado.

Edson, Eu entendo da seguinte forma, uma coisa é o webservice estar preparado para recepcionar um XML do MDF-e contendo os novos grupos/campos, outra coisa é ele aplicar as regras de validação. Sendo assim, eu recomendo que o XML seja enviado com os novos grupos/campos se for o caso.

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

Deivid, O erro de validação também ocorre com o programa exemplo?

Edson, Se tratando do CIOT, você chegou a ver esse artigo? Quanto aos grupos novos do MDF-e que são opcionais, chegou a ler as regras de validação que se encontram na Nota Técnica? Elas esclarecem alguns pontos.

Bom dia Antônio, Pesquisando na unit pnfsNFSeW_ISSDSF.pas Encontrei: // "A" a receber; "R" retido na Fonte FTipoRecolhimento := EnumeradoToStr( NFSe.Servico.Valores.IssRetido, ['A','R'], [stNormal, stRetencao]); Gerador.wCampo(tcStr, '', 'TipoRecolhimento', 01, 01, 1, TipoRecolhimento, ''); Concluo que se atribuirmos o valor stRetencao ao campo IssRetido a tag <TipoRecolhimento> vai ser gerado com o valor "R".