Painel de líderes

Olá pessoal, Foi publica a NT 2020/001 do MDF-e e ela já se encontra em nossa biblioteca. Resumo: O projeto MDF-e Integrado tem como objetivo a disponibilização, pelas Secretarias de Fazenda, de uma infraestrutura digital de documentos, legislações e processos voltados para a simplificação da emissão de documentos fiscais eletrônicos de transporte e integração, dentro de um ecossistema digital, que permite às Empresas Transportadoras de Cargas (ETC), Transportadores Autônomos de Cargas (TAC), ANTT, Administradores de Meios de Pagamentos e as próprias Secretarias de Fazenda, o aperfeiçoamento dos seus processos e compartilhamento de informações entre todos estes atores, a partir de um único documento e infraestrutura já consolidada e em uso por todos os envolvidos. Diante desse desafio, as Secretarias de Fazenda e o ENCAT, vêm nos últimos meses e em parceria com os diversos atores intervenientes, adotando uma série de ações estruturantes voltadas para superação das dificuldades atuais enfrentadas pelos órgãos de controle e geração de um ambiente operacional mais eficiente e competitivo, a exemplo das ações descritas abaixo: Aprovação de legislação nacional que normatizou o compartilhamento dos MDF-e dos 27 estados com os órgãos reguladores de transportes; Aprovação de legislação nacional que normatizou a obrigatoriedade de emissão do MDF-e em todas as operações de transporte, sejam elas intermunicipais ou interestaduais; Implantação da plataforma digital e registro de eventos eletrônicos que permitem ao transportador confirmar a entrega da mercadoria ao destinatário, possibilitando assim, a redução do prazo para o recebimento do frete por parte do caminhoneiro; Aprovação de legislação criando a Nota Fiscal Fácil (NFF), que permitirá aos contribuintes que operam com vendas de mercadorias e transportadores autônomos emitirem seus respectivos documentos fiscais de forma simplificada e a partir do seu próprio smartphone, conforme legislação publicada no D.O.U. do dia 19/12/2019 (Ajuste SINIEF No. 37 de 13 de dezembro de 2019); Publicação dessa NT, que estrutura o MDF-e de forma a possibilitar, entre outros benefícios: Geração automática do CIOT, pelo Sistema MDF-e, tanto para as modalidades TAC-Independente como TAC-Agregado; Automação do processo de fiscalização do Piso Mínimo do Frete (Tabela do Frete), nos termos da Resolução ANTT nº 5.849 de 16 de julho de 2019. Geração de informações para facilitar a negociação de direitos de recebimentos de fretes, por parte do TAC, junto a instituição financeira onde possui conta corrente, sem a interferência de atravessadores. Com essa NT temos: - Alterações de schema e regras de validação do MDF-e - Alterações no schema do modal rodoviário no grupo infANTT - Criação do evento de Pagamento da operação de transporte Portanto teremos um evento novo, criação do grupo Produto Predominante <prodPred> na parte geral do MDF-e, alteração no grupo informações do contratante, inclusão dos campos <xNome> e do <idEstrangeiro>, no modal rodoviário foi criado o grupo informações do pagamento do frete <infPag>. Novas Regras de Validação: Se modal rodoviário e indicador de pagamento for a prazo (tag:indPag=1): O grupo de informações a prazo deve ser informado (grupo:infPrazo). Implementação Obrigatória. Gera a Rejeição: 724. Se modal rodoviário, o grupo produto predominante deve estar informado (grupo: prodPred). Implementação Obrigatória. Gera a Rejeição: 725. Se modal rodoviário e MDF-e possuir apenas um DF-e transportado no grupo infDoc: O grupo de informações da carga lotação (infLotacao) deve estar informado. Implementação Facultativa. Gera a Rejeição: 726. Se modal rodoviário e informado grupo de pagamento, rejeitar se CNPJ/CPF do responsável pelo pagamento estiver inválido. Implementação Obrigatória. Gera a Rejeição: 727. Se moda rodoviário e informado grupo de pagamento, rejeitar se CNPJ do IPEF estiver inválido. Implementação Obrigatória. Gera a Rejeição: 728. Vai ocorrer alterações no componente? Sim Vai ocorrer alterações nos schemas? Sim Vou ter que adequar a minha aplicação? Sim Prazos: Ambiente de Homologação: 09/03/2020 Ambiente de Produção: 06/04/2020

Bom dia Filipe. Realmente, essa dependência não ficou legal. Por isso eu alterei para outra classe específica do Fortes. Muito obrigado pela contribuição. Fiz a implementação baseada nela com essa alteração mencionada. Subi as alterações para o SVN na Revisão 18748. Pelo que vi está tudo certo. Mas especial devido a minha alteração, queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Os Componentes do ACBr ainda não funcionam em Android... Use A1 e evite muita dor de cabeça com o A3 Cuidado com o uso do Delohi Community... verifique antes, se a licença dele, permite o uso para o porte de sua empresa e cenário de desenvolvimento

Olá pessoal, Alguém já imaginou ou tem a necessidade de imprimir o boleto em uma impressora térmica? Pois bem, o @guilhermekm teve a necessidade, arregaçou as mangas e implementou um novo layout chamado lTermica80mm. Guilherme, muito obrigado pela colaboração, já esta disponível no repositório. Quero também agradecer ao @Doug Dela Bite pelos ajustes feitos na implementação do Guilherme, muito obrigado Douglas. Abaixo o Preview e a impressão do boleto feita em uma Epson TM-T20X. Esse layout esta disponível apenas para o Fortes Report, portanto convido aos mestres em Fast Report a fazerem o mesmo que o Guilherme e Douglas. Estou aguardando o layout para o Fast! Compatibilizei o LFM do Lazarus com o DFM do Delphi, sendo assim é para funcionar sem nenhum problema no Lazarus / Fortes Report. Veja aqui o tópico original:

Bom dia... Ao processar os arquivos de retorno do BB, padrçai CNAB400, todos os comando 85 ( inclusão de negativação ) e 86 ( exclusão de negativação ) estavam vindo como toRetornoOutrasOcorrencias. Analisei o código e percebi que o ACBR estava processando essa opção somente no cnab240... fiz as alterações necessárias e testei.. tudo funcionando.. segue em anexo a unit alterada.. sds, ACBrBancoBrasil.pas

Bom dia Srs. Fazendo a implementação do contribuições para 2020, utilizando um arquivo com informações do registro 1010 (Processo Referenciado – Ação Judicial) seu registro filho 1011 (Detalhamento das Contribuições com Exigibilidade Suspensa) não estava totalizando no bloco 9900 gerando erro de estrutura ao validar o arquivo pelo aplicativo do governo. Para conseguir o mesmo fiz essa implementação conforme imagem abaixo ACBrSpedPisCofins.pas

Boa tarde William, O caso está sendo analisado e tratado pela nossa equipe de Suporte Técnico e daremos sequência no atendimento através da plataforma. Caso seja verificado que a situação afeta a comunidade ACBR, postaremos a resolução aqui no fórum.

Para constar e futura referência: um problema relacionado a essa opção ("Deixar somente a pasta libXX") foi solucionado no início desse mês.

Se tiver o Log da DLL ou do ACBrSAT... ache a resposta do SAT, referente a esse XML... Ela estará em uma longa String em BASE64... Copie essa String e decodifique nesse site: https://www.base64decode.org/ Verifique após a conversão se o XML realmente tem esses erros... Se tiver, pode ser necessário acionar o fabricante...

Certo Ítalo, os XMLs dos EVENTS não estão sendo criados na pasta EVENTO conforme configurado em DFe->Diretórios. Eu dei um jeito aqui de fazer, copiando os arquivos pois o cliente já está usando o BP-e em Produção. Mas, sobre os protocolos, eu não quis dizer mesmo que um substitui o outro não! Na verdade, realmente nenhum pode substituir, eles vão sendo gerado conforme eventos! Enfim, de qualquer forma, pra mim, se continuar do jeito que está, está bom, pois já pronta a rotina e funcionando OK! Mais uma vez, obrigado pela atenção! VLW ACBr!

DataC, sugiro usar a configuração que eu postei, com OpenSSL e 1.2, assim uso em WinXP e Win7, independente de atualizações.

Ceto. Mas no caso de não conseguir atualizar o Winodws pode-se usar libOpenSSL com LT_TLSv1_2 sem problema após a desativação dos outros protocolos?

Bom dia Se abrir o seu arquivo anexo, pode notar que tem 240 e 400 colunas respectivamente. Mas o problema pode estar na quebra de linha gerada pelo Linux... Experimente abrir o arquivo no NotePad++ e Converter para formato Windows, tente exportar após essa alteração.

Mais um ajuste... a rotina CodMotivoRejeicaoToDescricao não estava buscando corretamente o código no padrão 400... ACBrBancoBrasil.pas

Olá, ao gerar alguns CTes cujo destinatário é do exterior, em alguns casos eu obtinha rejeição de validação do schema, pois o município e UF do endereço do destinatário estavam em branco. Após algumas pesquisas encontrei esse tópico aqui no fórum, e ele trata do mesmo problema que estou enfrentando: https://www.projetoacbr.com.br/forum/topic/38258-utilização-de-typed-constants-nos-componentes/?tab=comments#comment-251004 O tópico é antigo, de 2017 e não teve nenhum comentário. Apliquei a solução que foi proposta na época e funcionou corretamente. Declarar as constantes apenas com o nome e valor, sem a tipagem. Resolvi alterar os arquivos PCN dos documentos fiscais e colocar aqui, caso se ache a correção satisfatória eles podem ser mesclados no SVN. As constantes necessárias para determinação da cidade/uf do exterior eram desse modo: CMUN_EXTERIOR: Integer = 9999999; XMUN_EXTERIOR: String = 'EXTERIOR'; UF_EXTERIOR: String = 'EX'; Após a alteração ficaram desse modo: CMUN_EXTERIOR = 9999999; XMUN_EXTERIOR = 'EXTERIOR'; UF_EXTERIOR = 'EX'; pcnBPe.pas pcnNF3e.pas pcnNFe.pas pcteCTe.pas pmdfeMDFe.pas pnfsNFSe.pas

Bom dia Italo, Infelizmente isso é bem verdade, é de longe o SEFAZ que mais dá problemas. Estamos com alguns chamados abertos lá sobre este assunto. Obrigado

Bom dia a todos, Hoje dia "09/01/2020" fiz novamente a atualização do Fortes Report e deu tudo certo. Obrigado a todos att Claudio

Muito estranho eu só tenho uma Epson e uma Elgin e a propriedade EspacoEntreCupons funcionou corretamente para mim. Vou ver com o pessoal do ACBr para fazer um teste la para mim. Enquanto isso poderia postar o log e sua config.

Thank you very much!

Olá, Desde versões anteriores da NFe o SEBRAE disponibilizou um layout .TXT para Importação e Exportação de NFe no Emissor Gratuito SEBRAE. O ACBr sempre manteve atualizado as versões destes layouts, permitindo gerar a NFe no modelo do Sebrae e também importar NFe para o ACBr através do mesmo layout. Quando entrou em produção a versão 4.0 da NFe, o ACBr atualizou o layout com os novos campo para manter as funcionalidades, visto que até então o SEBRAE não havia disponibilizado o novo layout. Porém, nos últimos meses o SEBRAE disponibilizou o layout NFe 4.0 ( http://emissores.sebrae.com.br/manual/nfe.html ), então para compatibilizar a versão SEBRAE com a versão já disponível no ACBr precisamos realizar algumas modificações no layout atual do ACBr. Segue abaixo o link do Manual atualizado no ACBr, com os campos alterados em destaque VERDE. E também a imagem comparativa com as linhas alteradas. svn:svn.code.sf.net/p/acbr/code/trunk2/Doctos/Manuais/Layout_TXT_NFe_NFCe_4_00.pdf Para quem utiliza o layout SEBRAE com ACBr, favor atualizar os fontes do ACBr e também a sua Aplicação se necessário.

Bom dia César, Primeiramente desculpa pela demora na analise na sua contribuição. Muito obrigado, já se encontra no repositório.

@Antonio Carlos L O emitente pode emitir uma nota de devolução de sua própria nota de venda sem problemas.

essa é fácil é simples va no relatório. se você trabalha com fastreport abra o relatório que você usa como DANFSEPadrao.fr3 ou DANFSEPadraoGINFES.fr3 por exemplo vá no campo das retenções federais no danfsepadrao.fr3 o nome do objeto é memo102 , dê dois cliques e adiciona a formula :[<Servicos."ValorPis">+<Servicos."ValorCofins">+<Servicos."ValorInss">+<Servicos."ValorIr">+<Servicos."ValorCsll">]

Nesse caso, provavelmente estão faltando atualizações de segurança no Windows Tem que rodar o Windows Update até todas as atualizações ficarem em dia

Olá pessoal, Sei que todos estão muito atarefados com seus programas por aí... Maaaasssss.... Precisamos de sua atenção para uma alteração nos componentes!!! Atualmente temos uma falta de padronização nas unidades de medidas das margens das impressões dos documentos fiscais. Cada impressão Report tem margens medidas com um formato. Isso não está bom. Note a tabela a seguir com as unidades de medidas das margens atual: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) cm cm nd X NFC-e mm mm X X NFC-e (A4) cm mm X X SAT mm X X X CT-e (Evento) cm nd X X CT-e (A5, Retrato) nd nd X X CT-e (Inut, Inut Retrato) nd nd X X GNR-e nd nd nd X MDF-e (Retrato, Evento) cm nd X X NFS-e cm nd X X BP-e X X X X Legenda: mm – milímetros cm – centímetros nd – O componente poderia, mas não está atualizando as margens do report X – Não possui impressão nesse formato ou não interage com as margens. Nota: Os modelos em ESCPOS que existem não consideram as propriedades de margem. Afinal, não faz muito sentido mesmo. Como podem ver na tabela acima, muitos componentes não estão atualizando as margens. Isso significa que mesmo que configure uma margem, ela será simplesmente ignorada. Então a ideia é fazer com que esses componentes imprimam de acordo com a configuração. Além disso, queremos evitar qualquer possível confusão e por isso vamos padronizar as unidades de medidas. A unidade de medida escolhida foi milímetros (mm). Alguns dos motivos foram: A unidade de medida mm funciona bem tanto para impressões grandes (por exemplo A4) como para bobinas (80 mm); As pessoas estão acostumadas com mm porque é a unidade padrão de todos os geradores de relatório usados atualmente (Fast Report, Fortes Report, LazReport ...); Devido ao ponto anterior, usar mm vai nos poupar código de conversão de unidades; Mesmo que tivéssemos escolhido centímetros (cm), haveria quebra de compatibilidade por causa do SAT e NFC-e; Quando as alterações vão entrar em vigor? A previsão é que dia 14 de outubro, as alterações sejam enviadas ao SVN. Acreditamos que isso dá tempo suficiente, para conseguirmos avisar a todos e para que todos possam se preparar. As alterações já foram enviadas ao SVN. Veja nota no fim desse post. O que eu preciso verificar no meu aplicativo? A primeira coisa é verificar se você tem configuração de margem (seria bom que tivesse). Em caso afirmativo, como você está armazenando? Em que unidade está armazenando? cm ou mm? Vai ser necessário fazer alguma conversão? Verifique como você deseja manter a configuração? De posse das informações acima, faça um teste imprimindo todos os documentos que você usa. Isso vai ajudar você a prevenir qualquer problema antes de enviar o executável para o cliente. Sugerimos você a imprimir tanto antes como depois das alterações no componente. Assim você vai ter algo para comparar as impressões e ajustar as margens caso necessário. O que eu preciso fazer caso use o ACBrMonitor Plus? A nossa ideia é minimizar o impacto para quem usa o ACBrMonitor. Vamos colocar as informações o próximo post logo abaixo. Se ficarmos atentos a essas alterações, as impressões vão seguir o mesmo padrão e ninguém mais vai precisar se confundir. Atualização- 17/10/2019 As alterações já foram enviadas ao SVN. Agora todos os reports seguem o mesmo padrão: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) mm mm mm X NFC-e mm mm X X NFC-e (A4) mm mm X X SAT mm X X X CT-e (Evento) mm mm X X CT-e (A5, Retrato) mm mm X X CT-e (Inut, Inut Retrato) mm mm X X GNR-e mm mm mm X MDF-e (Retrato, Evento) mm mm X X NFS-e mm mm X X BP-e X X X X Caso encontre algum problema, queira por favor criar um novo tópico.

Bom dia galera... Muito obrigado pelo rápido retorno!!! Consegui resolver o problema, o que eu fiz: - Copiei as DLL do XMLSec para a pasta onde está localizado o aplicativo. - Entrei na subpasta e copiei as DLL 32 bits para a pasta do aplicativo. Realmente o problema estava na incompatibilidade entre a arquitetura do aplicativo e as DLL's.

Sim, basta vincular novamente informando o certificado correto a ser utilizado. Att Cristiano Abbud