Italo Giurizzato Junior

Bom dia Luana, Notei que no arquivo de envio do Lote, na assinatura o valor do atributo URI esta vazio. Acabei de fazer um teste e ele é preenchido com o numero do lote. Favor atualizar novamente os fontes e caso você venha fazer um novo teste com a sua aplicação, certifique-se que ela esteja usando o arquivo ISSFortaleza.ini que esta na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI

Bom dia Patrick Chegou a abrir o arquivo Cidades.ini e procurar pelo provedor SigISS? O que você acha de acrescentar a cidade desejada aos moldes da que já se encontra no arquivo e que se utiliza do mesmo provedor?

Bom dia, Na prefeitura pode esta igual, mas e no provedor esta igual? Vi casos onde o provedor exige a IM sem formatação, mas no cadastro do provedor estava com formatação.

Bom dia Mesquita, Configurando o SSLLib com o valor libOpenSSL você fica livre do Windows, pois ela independe da versão do SO ou atualização do mesmo.

Bom dia Rauber, Favor configurar o programa exemplo para salvar os arquivos Soap. Faça uma nova consulta e anexe os arquivos Soap gerados ao realizar as consultas.

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

Bom dia Junior, O primeiro passo seria criar um novo arquivo IPM.ini para a cidade que exige assinatura e nele marcar o que deve ser assinado. Depois realizar os testes com o programa exemplo.

Bom dia Fabiano, Se tratando do provedor AssessorPublico esta muito fácil acrescentar novas cidades atendidas por esse provedor. Abra o arquivo Cidades.ini procure pelo nome do provedor, você vai encontrar uma cidade que já consta. Depois basta acrescentar as cidades que você sabe que são atendidas pelo mesmo provedor e incluir aos moldes da que já existe. Só toma cuidado com relação as campos NomeURL_H e NomeURL_P, pois mudam de uma cidade para outra. O que deve ser informado nesses campo é preciso ter em mãos as URLs de homologação e produção de cada uma delas.

Bom dia ALA, Para a cidade de Sete Lagoas se não me falha a memória você tem que usar o arquivo INI chamado: Actconv202 - Sete Lagoas.ini Se faz necessário renomear esse arquivo para: Actconv202.ini E o arquivo: Actconv202.ini renomeia para: Actconv202 - Geral.ini

Bom dia, Vai ser necessário verificar junto a prefeitura ou ao provedor de que forma esta no cadastro deles a Inscrição Municipal. Me recordo de casos onde o provedor existe que seja enviado a IM sem formatação (pontos) mas no cadastro do provedor estava com formatação.

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

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 Udenilson, Desculpe pela demora, mas acabo de enviar uma possível solução para o problema. Favor atualizar os fontes e faça novos testes.

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.

Boa tarde Reinaldo, Não mudou nada para 01/09. O que esta agendado para essa data é a ativação de algumas regras de validação. A presença ou não da tag <indIntermed> no XML é outra coisa. A principio a referida tag não precisa estar presente no XML caso o valor de indPres seja igual a 1. Último paragrafo do item 1 (página 5 da NT 2020/006 versão 1.20). * Os campos B25c (indIntermed) e o grupo de intermediador (infIntermed) YB01 estarão disponíveis a partir 05/04/2021 em produção, porém, a validação ocorrerá somente a partir do dia 01/09/2021.

Bom dia Roberto, Segundo a NT versão 1.20 no que se refere ao ambiente de homologação o prazo é: até 03/05/2021. Isso significa que algumas SEFAZ podem habilitar as regras antes da data limite.