Italo Giurizzato Junior

Bom dia Sérgio, Muito obrigado pela colaboração, já inclui na minha lista de tarefas.

Bom dia Alex, Faça um teste usando o programa exemplo. Na aba Certificado em SSLLib atribua o valor libWinCrypt. E na aba WebService em SLLType atribua o valor LT_TLSv1_2

Bom dia ALA, Favor anexar o XML de envio do lote de rps que o provedor aceitou sem nenhum problema e outro que esta apresentando o problema. Só assim vamos saber o que foi alterado.

Bom dia, Foi aplicado uma possível correção e envidado para o repositório. Se alguém estiver com problemas na impressão do DACTE feito em Fortes Report, favor atualizar os fontes e faça novos testes.

O serviço de transporte de cargas existe para concretizar uma operação comercial que envolve a necessidade do deslocamento/entrega de uma mercadoria. São dois processos distintos, porém intrinsicamente relacionados, seja nas operações envolvendo extensas cadeias de suprimentos (B2B/B2G), devidamente documentadas por NF-e, como, também, nas operações destinadas ao consumidor final (B2C), documentadas por NFC-e. São nos documentos fiscais que registram vendas de mercadorias onde encontramos as informações indispensáveis ao planejamento, armazenamento, programação da entrega e emissão dos documentos de transportes: quem vendeu a mercadoria, a quem se destina, seu valor, quantidade, forma de acondicionamento, GTIN, NCM da mercadoria, entre outras. Em um mundo conectado como o que vivemos, um simples atraso na obtenção dessas informações ou erro na transposição desses registros para os documentos de transportes, trazem prejuízos e custos adicionais para os transportadores, além de comprometer a qualidade e a eficiência da entrega. Foi a partir do claro entendimento da importância e indivisibilidade entre esses dois processos, que o ENCAT, as Secretarias de Fazenda, a Receita Federal, órgãos reguladores representados pela ANTT, ANTAQ e ANAC, além das empresas do segmento de transporte, colaborativamente, desenvolveram e implementaram um conceito que é muito maior que a emissão de um simples documento. Construíram um abrangente ecossistema, único no mundo, que conecta, em tempo real, absolutamente todos os atores da cadeia logística: desde a produção, distribuição, até o consumidor final. Este extraordinário insight, trazido a partir do MDF-e, permitiu que diversos fatos que ocorrem fora da cadeia de transportes, mas que são extremamente importantes para qualidade e eficiência da prestação do serviço, sejam “sincronizados” automaticamente com as transportadoras e demais atores do segmento, em milésimos de segundos após a sua ocorrência. É como se fosse mágica, dizem seus usuários! Um exemplo bastante atualizado, se aplica ao processo que permite ao emitente ou destinatário da NF-e, isso vai depende se a modalidade de contratação é CIF ou FOB, registrar seu consentimento para que o transportador realize o download do arquivo XML da NF-e, visando a automação do processo de emissão do MDF-e/CT-e, de forma alinhada com as diretrizes do sigilo fiscal e a novíssima legislação de acesso a dados. Outro benefício disponibilizado é a possibilidade de rastreabilidade da carga, a partir de registros de passagens capturados nas praças de pedágio e câmeras OCR de leitura de placas, já instaladas pelas prefeituras e Polícia Militar dos municípios de percurso do transporte, que quando integradas ao ONE - Operador Nacional dos Estados, são automaticamente repercutidas nos documentos fiscais de transporte e mercadorias, entre muitos outros processos que aumentam a segurança do motorista e da carga, sem nenhuma cobrança de tarifa adicional para seus usuários. Não foi uma jornada trivial, foram necessários muitos anos para se chegar ao estágio de excelência e amadurecimento atuais, que exigiram confiança mútua, engajamento e elevados investimentos, não só dos transportadores conectados ao ecossistema, como dos órgãos de governo, federais e estaduais, envolvidos na implantação do Sistema Público de Escrituração Digital – SPED, instituído pelo Decreto 6.022 de janeiro de 2007. Atualmente, apesar da complexidade do sistema tributário brasileiro, os documentos fiscais eletrônicos do Brasil são reconhecidos internamente e internacionalmente como um dos melhores do mundo, uma vez que, além de cumprem sua função de obtenção de informações para o desenvolvimento de políticas públicas de Estado, proporcionam um ambiente robusto e preparado para os desafiadores cenários trazidos pela atual economia colaborativa e conectada, além de possibilitar diferenciais competitivos ao core de negócios de todos os atores da cadeia de suprimentos. ENCAT: Inovação é a nossa marca. Se você não viu nossos posts anteriores sobre este tema, publicados nas redes sociais do ENCAT e Portal de DF-e, não deixe de acessar nossas publicações nos canais descritos abaixo: 1) MDF-e: O Suporte Digital da Transformação dos Serviços de Transporte no Brasil (01/04/2021) Twetter: http://www.encat.org/?p=1760 Facebook: Encat Brasil Portal DF-e SVRS: https://dfe-portal.svrs.rs.gov.br/MDFE/Noticias/229 Ative suas notificações e fique atento para nossas próximas publicações. COORDENAÇÃO TÉCNICA DO ENCAT 06/04/2021

Lançado há 10 anos atrás, a partir da publicação do Ajuste SINIEF 21/2010, o Manifesto Eletrônico de Documentos Fiscais (MDF-e) é mais um projeto de sucesso do ENCAT. Desenvolvido conjuntamente pelas equipes de especialistas de transportes das Secretarias de Fazenda, Receita Federal do Brasil, Agencia Nacional de Transportes Terrestres, transportadores e players de tecnologia que atuam na área de desenvolvimento de software de documentos fiscais, esse documento se consolidou como um importante instrumento de transformação digital dos contribuintes do segmento de transportes. Atualmente o MDF-e é muito mais que um documento fiscal, pois possibilita a integração de diversos processos que envolvem todos os atores da cadeia logística de transporte, de forma integrada com as informações das mercadorias que originaram a contratação dos serviços de transportes, sejam eles rodoviários, aquaviários, aeroviários, ferroviários ou multimodais. Autorizado sem a cobrança de tarifas para seus usuários, de forma centralizada na Sefaz Virtual do Rio Grande do Sul, no ambiente da PROCERGS, o MDF-e é utilizado por mais de 5 milhões de transportadores habilitados que emitem 6 milhões de documentos/mês, todos processados em milésimos de segundos, 24 horas por dia, 7 dias por semana, permitindo um ambiente de negócio seguro e estável para todos os atores envolvidos. COORDENAÇÃO TÉCNICA DO ENCAT 01/04/2021

Bom dia Maurício, Já enviei para o repositório a sua contribuição. Detalhe importante: 1. o componente ACBrCNAB que se encontrava no repositório Branches agora se encontra no Trunk2. 2. no Trunk2 ele se chama ACBrPagFor. Eu sugiro que você faça uma cópia dos seus fontes do antigo componente ACBrCNAB, atualize todos os fontes de todas as pastas, reinstale a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada e na lista de componentes procure por ACBrPagFor e marque ele para ser instalado. Faça novos testes. As outras alterações que você disse que ainda vai enviar, por favor, aplique no novo componente, faça os testes e anexe aqui as units alteradas. Desde já muito obrigado pela compreensão e colaboração.

Eliezer, Já esta no repositório a sua contribuição.

Bom dia Marcos, Desculpe pela demora, mas já esta no repositório a sua contribuição.

Bom dia Gutierres, Favor atualizar os fontes e faça novos testes. Note que fiz uma alteração no arquivo INI do provedor.

Bom dia Eliezer, Muito obrigado pela colaboração, já inclui na minha lista de tarefas.

Bom dia Gilberto, Não existe isso de forçar um pagamento ou ser membro do ACBr "Pago". Me diz, a quanto tempo que você não atualiza os fontes do ACBr? A anos que comentamos no fórum que o Certificado A3 gera mais problemas do que solução para o seu cliente. Você sabia que o certificado A1 nem precisa ser instalado na maquina que vai ser utilizada para emitir as notas? Uma vez que o A1 é um arquivo, é possível salvar ele na mesma pasta do seu executável ou até mesmo ser armazenado no banco de dados. Você vai me dizer que o A1 tem validade de 1 ano e o A3 de 3 anos, tudo bem. Mas faça as constas de quanto tempo você demora resolvendo problemas com o A3 e com o A1, vai notar que o A1 os problemas são mínimos. Você sabia que o A3 se utiliza de uma DLL do Windows que possui um Bug, Bug este que deleta o certificado do cartão? Por fim, ficaremos honrados caso você venha fazer parte do ACBr SAC, pois além de estar contribuindo com o Projeto ACBr, vai ter a sua disposição toda a equipe de Consultores e Moderadores para esclarecer as suas duvidas. E dependendo do plano que você aderir poderá participar do nosso chat, onde todas as terças, quartas e quintas-feiras você poderá participar do nosso Papo Pró. Onde os Consultores, Moderadores e especialistas tem um papo descontraído com os desenvolvedores. Fica ai a dica.

Boa tarde Claudio, E o sistema que vocês desenvolvem também é custo zero para os seus clientes? Com certeza não é. Assim caminha a humanidade. Paciência.

Leandro, Para que uma aplicação baixe o XML de uma nota de serviço emitida por um prestador contra o seu CNPJ, você concorda que o WebService da empresa contratada pela prefeitura desse prestador tem que ter um serviço que permita essa ação? No meu entendimento se o WebService não tem esse serviço essa baixa se torna impossível. Vamos pegar por exemplo os provedores que seguem a versão 1 do layout da ABRASF, onde temos o serviço de consulta a NFS-e. Para realizar essa consulta precisamos informar o CNPJ e a Inscrição Municipal do prestador de serviço. Mesmo que você consiga fazer essa consulta usando o certificado digital do tomador e que o pedido de consulta não precisa ser assinado digitalmente. A consulta seria muito trabalhosa, pois você precisa saber o CNPJ e a IM de todos os seus prestadores de serviço. E portanto não saberia se tem alguém emitindo nota contra o seu CNPJ sem o seu consentimento. Que ao meu ver é muito mais importante do que simplesmente baixar o XML da nota.

Boa tarde Leandro, Esta sendo feito um grande Refactoring no componente ACBrNFSe. Dentro de 1 ou 2 meses vamos lançar um novo componente para emissão de NFS-e. Isso foi decidido por conta das inúmeras quebras de código nas aplicações. Logo os dois componentes vão coexistir por algum tempo, para que você possa migrar a sua aplicação para o novo componente. Uma informação importante, esta documentado no Manual da ABRASF versão 2 os serviços de consulta a NFSe por faixa, por serviço prestado e por serviço tomado. Só que existem provedores que seguem a versão 2 do layout da ABRASF que não implementou esses serviços de consultas em seus WebServices. Neste caso a consulta a NFSe por serviço tomado que seria algo semelhante a Distribuição de DF-e, não vai funcionar.

Bom dia Renata, A UF informada no CT-e é a mesma informada na configuração do componente?

Bom dia Mauricio, Já inclui na minha lista de tarefas. Outra coisa importante o componente ACBrCNAB que se encontrava no Branches, componente este destinado a gerar arquivos no padrão CNAB 240 para pagamento de fornecedores, títulos e tributos, agora se encontra no Trunk2 e o ACBrInstall_Trunk2 tem o campo para você marcar e assim ele instala no Delphi. Só que o seu nome mudou, agora ele se chama ACBrPagFor.

Bom dia a todos, Um CT-e de Anulação tem vida curta, ou seja, após a sua emissão devemos emitir o CT-e de Substituição. Outra coisa importante, o CT-e de Anulação só é emitido quando o tomador não for contribuinte ou tenha enviado o Evento de Prestação de Serviço em Desacordo. Se o tomador do serviço é contribuinte e tenha emitido uma NF-e de Anulação de Valores, a transportadora emite somente o CT-e de Substituição. É preciso ler muito sobre esse assunto para poder implementar corretamente o CT-e de Anulação e de Substituição e orientar muito bem o usuário do sistema para que ele não faça kaka.

Bom dia, Os nomes dos campos no componente seguem a mesma nomenclatura do manual. Te aconselho a abrir a Unit pcteCTeR.pas e procurar pelo nome do campo desejado. Assim fica mais fácil de achar o que deseja. Por exemplo o CFOP do CT-e: (*B02*)CTe.Ide.cUF := Leitor.rCampo(tcInt, 'cUF'); (*B03*)CTe.Ide.cCT := Leitor.rCampo(tcStr, 'cCT'); (*B04*)CTe.Ide.CFOP := Leitor.rCampo(tcStr, 'CFOP'); <=== é essa linha que lê a tag <CFOP> do XML e armazena o seu valor no campo CFOP. (*B05*)CTe.Ide.natOp := Leitor.rCampo(tcStr, 'natOp'); Acredito que você esteja carregando um XML por vez, ou seja: ACBrCTe1.Conhecimentos.Clear; ACBrCTe1.Conhecimentos.LoadFromFile(xNomeDoXml); Logo para obter o CFOP do CT-e carregado temos: xCFOP := ACBrCTe1.Conhecimentos.Items[0].CTe.ide.CFOP; Simples assim.

Boa tarde Gutierres, Vou verificar.

Bom dia Mauricio, Verifique junto ao provedor se a URL: WSDL=http://191.252.58.191:83/wsdl/INFSe É exclusiva para a cidade de Trindade do Sul, ou se pode ser utilizada por outras cidades? Essa URL é de produção ou homologação ou é a mesma para ambos os ambientes?

Almeida, Os seus arquivos INI estão desatualizados, favor deletar os INI que você fez alteração e atualizar todos os fontes de todas as pastas. Reinstale a suíte ACBr e por fim realize novos testes.

Bom dia Halisson, Já enviei para o repositório a sua contribuição, muito obrigado.

Bom dia Sandro, Já enviei para o repositório a correção.

Bom dia Gutierres, Favor atualizar os fontes e faça novos testes.