Italo Giurizzato Junior

Bom dia Sérgio, Não esta mais disponível para download a unit que você fez alteração. Por favor anexe novamente as units alteradas para que possamos analisar.

Boa tarde, Os Schemas da NF-e que se encontram em nosso repositório, não haverá a necessidade de realizar essa troca de Schemas no dia 01/09/2021. Como já foi dito o ENCAT fez uma lambança não só com a NT mas também com os Schemas. Use os nossos Schemas e esqueça até que eles resolvam nos 45 minutos do segundo tempo acrescentar mais alguma coisa.

Boa tarde Junior, Vou passar para os mestres em assinatura digital para analisarem a possibilidade.

Olá Pessoal. As regras de validação YA02-60 (que trata sobre o meio de pagamento <tPag>), YA06-10 (que trata sobre a bandeira do cartão <tBand>), B25c-10 (que trata sobre o indicativo do intermediador <indIntemed>), YA02a-10 e YA02a-20 (que tratam da descrição do meio de pagamento <xPag>) conforme consta na página 4 - Tabela de Histórico de Alterações e Cronograma, essas regras só vão ser ativadas nas seguintes datas: Ambiente de Homologação: Até 03/05/2021 - Isso significa que dependo da UF as regras podem ser ativadas antes da data prevista. Ambiente de Produção: 01/09/2021 A regra YA02-50 (que não permite o uso do valor 99 para tPag) não existe no ambiente de produção e vai ser eliminada do ambiente de homologação até 03/05/2021. Os Schemas que contemplam todas as versões dessa NT já se encontram no repositório, é extremamente importante que vocês atualizem todos os fontes de todas as pastas e consequentemente atualizem os Schemas em seus clientes. O componente ACBrNFe já esta pronto também, mas no momento não temos noticias que alguma SEFAZ já ativou as regas mencionadas acima. Se alguém esta com problema de rejeição de notas em função das regras no ambiente de homologação, favor postar no fórum para que possamos disponibilizar os fontes que atende as novas regras.

Bom dia Mauricio, Já enviei para o repositório a alteração da URL no arquivo INI do provedor.

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.