ncc.star

Boa tarde Italo. Não estou conseguindo anexar os arquivos para você avaliar. Vou lhe enviar via e-mail. Eu alterei na linha 1886. Da forma que estava antes, caso a unidade fosse M3 ou Unidades, estava só colocando em uma variável o último valor. Agora eu alterei para ele somar os valores e também para listar as unidades.

Olá Italo. Veja se dessa forma seria o correto então:

Oi Italo. Eu não tenho QuickReport, então não tenho como fazer os testes. Mas de acordo com o exemplo que eu postei, o correto seria estar detalhado então cada <infQ>?

Ok, sem problemas. É que eu achei que talvez tivesse passado despercebido.

Bom dia Italo. Chegou a verificar se o problema que eu relatei e corrigi procede?

Bom dia. Aproveitando o gancho, hoje ocorreu de um cliente gerar um CT-e com duas NF-e, sendo que essas duas NF-e possuem fardos como tipo de medida. Acontece que cada nota tem um tipo de fardo (como pode ser visto no fragmento de XML). Um fardo de 560 e outro de 496. Porém no dacte FR3 no campo Quant. Vol. está aparecendo apenas a quantidade do último fardo (496). O correto não seria somar todas as quantidades de fardos, totalizando neste campo 1056 volumes? Se for isso, já anexei a correção. ACBrCTeDACTEFRDM.pas

Bom dia Italo. Algum tempo depois que o CIOT tornou-se obrigatório eu estudei várias documentações. Alguns clientes meus estavam solicitando uma integração no sistema. Naquela época eu percebi que cada operadora tinha requisitos diferentes. Apesar de todas operadoras permitir emitir o CIOT de forma gratuita (é lei), somente quem paga pode fazer integração via webservice. Então, de todos os clientes, apenas 1 optou por pagar e fazer a integração. Talvez a e-frete permita fazer integração via webservice de forma gratuita, porém não tenho certeza. O CIOT é um padrão nacional, porém cada operadora integra nesse padrão, podendo fazer da maneira que bem entender. Com isso eu pensei de usar como base o componente de emissão da NFS-e, que dependendo da cidade o layout é diferente. Eu peguei o componente da NFS-e e tentei adapta-lo para o CIOT, porém eu deveria ter começado do zero e feito um componente inteiramente novo. O problema que meu tempo era curto e também não tinha conhecimento para isso. Eu também não tirei os “excessos” do componente, ficando bastante coisa da NFS-e junto. Enfim, apesar de o componente não ter ficado 100%, ele está funcional. Meu cliente está usando ele a um bom tempo não apresentando maiores problemas. Eu não disponibilizei para download porque é necessário refazer e melhorar ele. Mesmo assim, eu repassei para algumas pessoas que solicitaram aqui, que dariam continuidade, porém até agora não recebi nenhum feedback. A integração que eu fiz foi com a Repom, algumas dificuldades que eu tive: * Não é possível enviar um CIOT em homologação. Quem altera se está ou não em homologação é a operadora. Se eu pedir para entrar em homologação, o meu cliente tem que parar de emitir em produção. Isso complica porque não consigo fazer testes sem atrapalhar o meu cliente. * Diferente da NF-e ou do CT-e, é necessário enviar “em partes” o XML, ou seja, tenho de enviar o contratado, depois os veículos, depois o motorista e depois o contrato. Isso foi recomendação da Repom, porque se não fizesse assim daria muito problema e seria difícil descobrir onde estaria o problema. * Quando ocorre um problema no XML, por exemplo, se eu mandar um campo string com uma quantidade maior de caracteres do que o permitido, o sistema da Repom não trata isso. O retorno é simplesmente um erro, mas que não indica onde é o erro. Nesses casos tem que entrar em contato com o suporte da Repom e eles levam o dia inteiro pra descobrir onde está o problema. * Cadastro de rotas - Cada CIOT que é enviado tem que enviar qual rota e trajeto que o veículo vai seguir. A Repom usa a informação da rota para calcular as praças de pedágio, valores de combustíveis no trajeto, etc. Uma rota pode ter vários trajetos. É possível integrar isso via WebService, porém eu achei que se torna muito complexo para desenvolver e para o usuário usar, visto que eu trabalho com rotas no meu sistema, mas a rota é informada no CT-e e o CIOT é gerado depois do CT-e. Caso tiver alguma informação de rota errada é necessário cancelar o CT-e. Se tiver uma rota nova, é necessário enviar uma solicitação via webservice e aguardar 15 minutos para o operador da repom cadastrar a rota manualmente. Creio que essa informação de rota é um requisito da Repom apenas e não do CIOT. Devido essa complexidade eu não integrei a rota via webservice. O meu cliente criou no sistema as rotas que ele usa na Repom e antes de fazer o CT-e ele consulta e informa a mesma rota no sistema. Caso tiver uma rota nova ele liga na Repom e solicita eles cadastrarem. Talvez agora eles já estejam fazendo via sistema Web da Repom. * Obrigatoriedade de informar o NCM da mercadoria - Também acho que isso é apenas a operadora que solicita. Como esse campo não é informado no CT-e, fiz uma “gambiarra” para poder informar isso pra Repom. * Eventos do Contrato (valores) - Quando a empresa entra em produção tem que cadastrar na Repom os códigos para cada evento que enviar. Exemplo, para enviar o INSS eu tenho de dizer pra Repom que sempre vai a string INSS como um código. Isso vale para o valor do frete, IRRF etc. * Número de Eixos - Outro campo que também acho que é só requisito da operadora. É usado para eles calcularem quanto de pedágio vai ter no trecho. * Os relatórios de cálculo de imposto, depois de fazer a integração via webservice não podem mais ser visualizados no site da Repom, somente via sistema, ou seja, tive de fazer 1 ou 2 relatórios novos para que tivesse os mesmos dados que a Repom tinha. * A documentação deles também tinha falhas e o suporte deles também deixou a desejar, complicando muitas vezes coisas que seriam simples. Um exemplo de falha na documentação era que no layout pedia para informar a UF, nome da cidade e CEP, porém o suporte pediu para que essas informações não sejam enviadas porque dava erro. Isso é o que eu lembro, foi meio conturbado fazer essa integração. Vou lhe enviar o que eu fiz para você analisar.

Você carregou no PR e descarregou em SP? Ou alguma transportadora levou a carga até SC e aí você transportou pra SP?

Veja se ajuda:

Olá. Fiz uma alteração hj no arquivo fr3 do boleto justamente por causa de um problema na impressão do campo código do beneficiário. Verifica se resolve

Estava homologando o boleto com o banco Bradesco e descobri inconsistências na impressão do campo Agência/Código do Benificiário. No arquivo BoletoFR.fr3 1) O memo CedenteAgencia2, estava no lugar do CNPJ do Benificiário e vice versa. 2) Ao invés de imprimir o que pedia o manual estava imprimindo o código do cedente. Estava imprimindo o campo <Titulo."CodCedente"> apenas para o banco 104. Porém eu creio que deva fazer isso para todos os bancos, visto que cada banco tem uma forma de imprimir esse campo que está definido na classe do banco. Segue em anexo para análise. BoletoFR.rar

Oi Juliomar. Eu não alterei o FR3 porque estes campos não são obrigatórios imprimir (não estão no layout de impressão previsto no manual), porém tem alguns clientes meus que estão solicitando. att.

Segue em anexo arquivo corrigido. ACBrMDFeDAMDFEFRDM.rar

Correto, é isso mesmo, veja nesse link:

Olá _asseinfo, não sei também o que justificou a mudança, creio teremos de ver com o italojjr. rrodrigoffernandes, a principio basta que o manifesto esteja com o protocolo de autorização. Testei aqui e não tive problemas.

Não sei se foi proposital ou não, mas na revisão 7102, em ACBrManifestos.pas estava assim: function TManifestos.LoadFromFile(CaminhoArquivo: string; AGerarMDFe: Boolean = True): boolean; Agora foi alterado para function TManifestos.LoadFromFile(CaminhoArquivo: string; AGerarMDFe: Boolean = False): boolean; então, para gerar a chave do manifesto, quando carregar o arquivo defina o valor True, exemplo: ACBrMDFe1.Manifestos.LoadFromFile(ArquivoXML,true);

Olá. Fiz uma alteração no ACBrMDFeDAMDFEFRDM, eu adicionei duas tabelas, para poder imprimir as informações do percurso e municípios de carregamento. Segue em anexo para avaliação. obrigado.

Olá Rômulo. Veja o manual do CT-e, pg 38: d) Validação de Regras de Negócio do CT-e Regra G015 - Se ambiente de Autorização SVC: - Não aceitar tipo de CT-e diferente de 0 (Normal) Ou seja, em SVC você só pode emitir CT-e do tipo normal.

Pra mim aconteceu esse erro e era só porque em um campo obs foi informado o caractere | precedido de um espaço em branco.

Usa o DACTE_1_04.fr3

Ok. Muito obrigado!

Olá. Pra simplificar pro usuário fiz uma rotina que lê o XML do CT-e e popula uma TreeView. Aqui tem um exemplo de como fazer para popular a TreeView: http://www.edesoft.com.br/artigos/142-xnl-no-radstudio-xe2 Procura aqui no fórum também, eu lembro que teve um usuário que publicou uns print do sistema dele, que fez da mesma maneira.

Bom dia Juliomar. Mais uma correção em anexo, agora na procedure que eu tinha implementado: procedure TdmACBrCTeFR.CarregaDocumentoAnterior; Estava dando erro quando era CT-e subcontratado com documentos em <docAnt><emiDocAnt> de dois ou mais CNPJ diferentes. Também simplifiquei o código, reaproveitando o código para o CT-e 1.04. ACBrCTeDACTEFRDM.rar

Acho que este tópico está no lugar errado, mostaert deve ter confundido MDF-e com MFD.

Quanto a série e o número da nota fiscal é firula. Uma meia dúzia de transportadoras querem isso porque o embarcador reclama que pela chave da nota fica difícil de conferir. Como isso não está em NT eu só alterei as linhas 523 e 525 no ACBrCTeDACTEFRDM.pas para poder recuperar estes dados no DACTE, porém eu não alterei isso no DACTE fr3 padrão do ACBR, somente no DACTE fr3 da minha aplicação. A única alteração que eu fiz no DACTE fr3 padrão do ACBR foi a propriedade RowCount do MasterData5, de 3 para 4 pois quando um CT-e tinha 4 veículos atrelados só estava aparecendo 3.