Painel de líderes

Bom dia a todos, 18/06/2019 Comunicado sobre as datas de implantação da versão 3.00a Comunicamos que foi publicado a versão 3.00a do Manual de Orientação do Contribuinte do CT-e/CT-e OS e seus anexos. Reforçamos que esta nova versão prevista para entrar em homologação a partir do dia 22 de Julho de 2019 e em produção a partir do dia 26 de Agosto de 2019, contempla a atualização do schema do CT-e, criação do Evento Comprovante de Entrega dentre outras modificações. Relativamente à definição dos padrões do QRCode previstos no arquivo XML do CT-e, cuja especificação das configurações para impressão no DACTE estão detalhadas no Anexo II – Manual de Especificações Técnicas do DACTE, serão implementadas a partir de 07 de Outubro de 2019, quando entrará em vigor a obrigatoriedade de exibição do QRCode no layout do DACTE. Da mesma forma, as RV G238 a G243 e N135 a N140 passarão a ser aplicadas em 02/09/2019 no ambiente de homologação e somente em 07 de Outubro de 2019 no ambiente de produção.

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

Quais são as mudanças dessa nova versão 3.00a? Um breve resumo. Criação do Web Service síncrono de autorização Disciplina as regras para Uso Indevido Definição do QR Code do CT-e: RV´s 850 a 855 ; Definição da Consulta Pública resumida e consulta completa para atores do CT-e identificados pelo certificado digital; Eliminação do retCancCTe na resposta da consulta situação; Criação da tag ICMSST no evento EPEC e alteração da RV 642; RV 841 para informar fretamento no transporte de pessoas; Alteradas RV´s 837, 838, 839, 840: aplicar somente aos tipos Norm / Subst.; Unificação das regras de validação de chave de acesso: 592-596, 507, 610 => 236 701-708 => 842 (Chave do CT-e da ferrovia de origem) 591, 602-605, 508, 504 = > 843 (Chave da NF-e transportada) 544-549, 480, 538 => 844 (Chave do documento anterior) 450-454, 478, 479, 608 => 845 (Chave do CT-e multimodal) 761-768 => 846 (Chave do CT-e anulado) 769-776 => 847 (Chave do CT-e substituído) 777-784 => 849 (Chave CT-e complementado) 816-823 => 856 (Chave do CT-e cancelado referenciado no CT-e OS) 761-772, 615, 766-768 => 857 (Chave do CT-e OS anulados) 769-772, 616, 774-776 => 858 (Chave do CT-e OS substituído) 777-780, 785, 782-784 => 859 (Chave do CT-e OS complementados) RV 848: Validação chave de acesso do CT-e de anulação informado Criação do evento do comprovante de entrega (grifado no MOC em amarelo), RV´s 860, 863, 864, 865, 869, 870 e 871 Criação do evento de cancelamento do comprovante de entrega (grifado no MOC em amarelo), RV´s 866 RV do cancelamento associada ao comprovante de entrega: 862 RV de validação da IE do tomador na EPEC: Dispensa de validação da IE do tomador quando autorização de um CT-e EPEC RV para implementação a critério da UF para o responsável técnico: 867 Previsão de RV de implementação futura para o responsável técnico: 868 Exclusão da tag pICMSInterPart do leiaute do CT-e e CT-e OS (ver anexo I Leiaute). Em nossa biblioteca você encontram os 3 Manuais (Visão Geral, Layout e DACTE) da versão 3.00a clique aqui para ter acesso.

Bom dia, consegui homologar, realmente o numero do posto de atendimento era o que faltava, o gerente da conta dizia que não existia essa informação, mas coloquei como vc passou, e a homologação foi "simplesmente aprovada" hehe, muito obrigado

Boa tarde José, Já fiz os ajustes, ainda hoje estarei enviando para o repositório.

Oi pessoal, o tópico acabou ficando um pouco confuso porque está tratando de assuntos diferentes. Como a @Juliana Tamizou já dividiu o tópico, vamos continuar o assunto sobre o ACBrMonitor fechar sozinho nesse aqui: Vamos fechar esse tópico, considerando que foi reportado que o problema do e-mail foi resolvido.

Obrigado. Resolvido.

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]". Favor leia as regras do fórum.

Bom dia, Ronny Lucas Eu acredito que esse erro acontece, por você ter mais de uma pasta do Fortes no disco desatualizada. Apague as duas e baixe a mais recente como mostra no link abaixo:

Valeu Juliomar, resolvi o prolema vendo esse vídeo:

Boa tarde Italo Jurisato Junior , obrigado pela ajuda, fiz como você falou e deu certo...mudei logo o codigo na NF-e antes da validação pra deixar já OK..pode encerrar o tópico pra mim ta resolvido

Boa tarde, Obrigada pela contribuição, adicionada para análise. Att.

Ola pessoal depois de muito tempo tivemos um tempo de da continuidade aos testes no componente de consulta spc. Bom já conseguimos ter uma versão experimental do componente baseado na documentação do spc brasil. No caso pegamos a documentação da cdl manaus na nossa cidade. Queríamos duas ajudas importantes: 1 - Para doação do componente que estamos criando para o acbr tem algum regra de padronização? Por ser um componente TCP os commit recomendariam se basear em algum componente especifico? 2 - Fizemos a leitura do xml de retorno e talvez não esteja de uma forma tão profissional como esperado pelos padrões do acbr. Se alguém poder nos ajudar com a analise do retorno e poder nos sugerir uma forma de melhor ou mais fácil. Estou anexando algumas fotos do componente e padrões que estamos usando e o arquivo de retorno que estamos precisando de ajuda. O arquivo prot-282754218.xml e o retorno que estamos precisando de ajuda. Eu tinha criado esse tópicos a tempos atrás com essa ideia rs; Demo rodando e funcional com as seguintes funções: - Consulta e leitura do retorno. - Baixar as tabelas que são necessária para enviar o motivo de exclusão e inclusão no spc. - Rotina de inclusão do cliente no spc. - Rotina de exclusão do cliente no spc. Pacote instalado no delphi Tokyo Pasta separada com exemplos, fontes e pacotes Rotina de consulta ja meio no padrão do acbr - 20190530162535-ped-sta.xml prot-282754218.xml

Boa tarde Felipe Resende, Tudo bem. Não tentei instalar novamente, mais irei fazer isso que vc sugeriu.

Portaria CAT 102, de 14-11-2018 (DOE 15-11-2018) Dispõe sobre a emissão do Bilhete de Passagem Eletrônico - BP-e e do Documento Auxiliar do Bilhete de Passagem Eletrônico - DABPE, o credenciamento de contribuintes e dá outras providências O Coordenador da Administração Tributária, tendo em vista o disposto no Ajuste SINIEF-1/17, de 07-04-2017, no artigo 67, § 1º, da Lei 6.374, de 01-03-1989, e no inciso XII do artigo 212-O do Regulamento do Imposto sobre Operações Relativas à Circulação de Mercadorias e sobre Prestações de Serviços de Transporte Interestadual e Intermunicipal e de Comunicação - RICMS, aprovado pelo Decreto 45.490, de 30-11-2000, expede a seguinte portaria: Artigo 1º - Na emissão do Bilhete de Passagem Eletrônico - BP-e, modelo 63, instituído pelo Ajuste SINIEF-1/17, de 07-04-2017, deverão ser observadas, além das disposições do referido Ajuste, o disposto nesta portaria. CAPÍTULO I DO CREDENCIAMENTO E DESCREDENCIAMENTO Artigo 2° - Para a emissão do BP-e, o contribuinte deverá estar previamente credenciado pela Secretaria da Fazenda. § 1° - O credenciamento a que se refere o “caput” poderá ser: § 2° - O estabelecimento será considerado credenciado a emitir o BP-e a partir da data de habilitação no ambiente de produção do BP-e da Secretaria da Fazenda. § 3º - O credenciamento efetuado nos termos desta portaria poderá ser alterado, cassado ou revogado de ofício, a qualquer tempo, no interesse da Administração Tributária. Artigo 3° - Na hipótese de credenciamento voluntário, o contribuinte deverá: I - para ter acesso ao ambiente de testes do BP-e da Secretaria da Fazenda do Estado de São Paulo: II - para solicitar o credenciamento como emissor de BP-e: Parágrafo único - O contribuinte credenciado nos termos deste artigo poderá, a qualquer tempo, solicitar o credenciamento de outros estabelecimentos de sua titularidade mediante procedimento previsto nos incisos I e II. Artigo 4º - O contribuinte poderá solicitar o descredenciamento de seu estabelecimento para emissão de BP-e, desde que o respectivo estabelecimento não esteja sujeito a obrigatoriedade de emissão de BP-e. § 1º - O descredenciamento poderá ser solicitado por meio do sistema de credenciamento do BP-e. § 2º - O deferimento do pedido será informado ao contribuinte por meio eletrônico, podendo ser verificado na consulta referida no artigo 5º. Artigo 5º - A Secretaria da Fazenda disponibilizará consulta na internet, na página do BP-e do portal da Secretaria da Fazenda, que permita a qualquer interessado verificar se determinado estabelecimento está credenciado a emitir BP-e. CAPÍTULO II DA OBRIGATORIEDADE DE EMISSÃO DE BP-e Artigo 6º - O BP-e será emitido em substituição aos seguintes documentos fiscais, observado o disposto no Regulamento do ICMS: I - Bilhete de Passagem Rodoviário, modelo 13; II - Bilhete de Passagem Aquaviário, modelo 14; III - Bilhete de Passagem Ferroviário, modelo 16; IV - Cupom Fiscal Bilhete de Passagem emitido por equipamento Emissor de Cupom Fiscal - ECF. § 1º - Os estabelecimentos que, em 31-12-2018, já estiverem inscritos no Cadastro de Contribuintes do ICMS: § 2º - Os estabelecimentos que vierem a ser inscritos no Cadastro de Contribuintes do ICMS a partir de 01-01-2019 deverão emitir BP-e, em substituição aos documentos relacionados nos incisos do “caput”, a partir da data de sua inscrição, ficando vedada a emissão do respectivo documento em papel. § 3º - A partir de 01-01-2019, não serão concedidas novas autorizações de uso de equipamento ECF. § 4º - Para atender à obrigatoriedade de emissão de BP-e, os contribuintes deverão solicitar credenciamento de seus estabelecimentos, exceto se já estiverem credenciados de ofício a emitir BP-e. § 5º - Não se aplica a obrigatoriedade de emissão de BP-e ao Microempreendedor Individual - MEI, de que trata o artigo 18-A da Lei Complementar federal 123/06, de 14-12-2016. CAPÍTULO III DA EMISSÃO DO BP-e e DO DOCUMENTO AUXILIAR DO BILHETE DE PASSAGEM ELETRÔNICO - DABPE Artigo 7° - O BP-e e o Documento Auxiliar do Bilhete de Passagem Eletrônico - DABPE deverão ser emitidos conforme as disposições do Ajuste SINIEF-1/17 e observado o leiaute estabelecido em Ato COTEPE. Parágrafo único - Se o adquirente concordar, o DABPE poderá ter sua impressão substituída pelo seu envio em formato eletrônico ou pelo envio da chave de acesso do BP-e correspondente por correio eletrônico. CAPÍTULO IV DA ESCRITURAÇÃO DO BP-e Artigo 8° - O BP-e deverá ser escriturado conforme o disposto no artigo 215 do Regulamento do ICMS. Parágrafo único - O contribuinte obrigado a efetuar a Escrituração Fiscal Digital - EFD deverá registrar o BP-e no arquivo digital correspondente ao período de apuração em que tiver ocorrido a emissão do documento. Artigo 9º - No caso de cancelamento ou substituição do BP-e, poderá ser estornado o débito do imposto, desde que, cumulativamente: I - o valor da prestação tenha sido devolvido ao adquirente ou por ele aproveitado; II - conste no BP-e as informações da identificação do passageiro; III - o BP-e tenha sido regularmente escriturado, com débito do imposto, no livro fiscal próprio; IV - o evento correspondente tenha sido devidamente registrado com a justificativa da ocorrência e homologado; V - seja elaborado, no final do período de apuração, demonstrativo dos bilhetes sem embarque, cancelados e substituídos. Parágrafo único - Tratando-se de cancelamento, exige-se que o evento correspondente tenha sido devidamente registrado antes do início da prestação do serviço. CAPÍTULO V DA CONSULTA AO BP-e Artigo 10 - Após a concessão da Autorização de Uso do BP-e, a Secretaria da Fazenda disponibilizará consulta ao BP-e na internet, na página do BP-e do portal da Secretaria da Fazenda, pelo prazo previsto no artigo 202 do Regulamento do ICMS. Parágrafo único - A consulta a que se refere este artigo poderá ser efetuada mediante informação da chave de acesso do BP-e ou através da leitura do QR code impresso no DABPE. Artigo 11 - Esta portaria entra em vigor na data de sua publicação.

Credenciamento Para informações sobre o Credenciamento clique aqui e acesse nossa sessão de Requisitos Fiscais por UF .

Felipe, no link que me mandou só consigo alterar o horário em 5 minutos para mais ou para menos, no meu caso, são anos de diferença. Já estou em modo intervenção, utilizei o tools, mas não consegui alterar, Agradeço desde já a ajuda

pode ser que essa versão ainda não tenha suporte a esse comando...

se tu deu um nome fixo para ele será isso agora se deixar para criar conforme a nota ele vai gerar um pdf para cada xml

Não sei se pode ter mudado, mas a princípio a ABRASF não aceita utilizar esse campo. Abraços.

Olá bom dia Italo Obrigado por responder .. pior que o xml de retorno da NFS-e convertida está sem os dados do endereço do Prestador.. e os XMLs de exemplo informados no arquivo de auxilio a integração também vou tentar entrar em contato com o Provedor deles para ver Obrigado.

Bom dia, Verifica junto ao provedor se o usuário e senha utilizado pelo seu cliente para emitir notas via site, pode ser utilizado para emitir via webservice. Eu acredito que o usuário e senha é diferente.

Bom dia, Você tem que emitir um MDF-e constando as duas notas sendo que o local de descarregamento é MS. E outro MDF-e constando apenas uma nota sendo que o local de descarregamento é MT.

Bom dia Michel, O erro de Código Numérico invalido, chave não gerada é pelo fato de você estar atribuindo a cNF o mesmo numero de nNF, sendo que não pode. Por favor leia a noticia:

Bom dia, Que esquisito, acontece em qualquer impressora? Att.

Bom dia todos, 19/06/2019 Implantações da Consulta QR Code e do WS Sincrono de MDF-e Foram implantados na SEFAZ Virtual RS os serviços de consulta QR Code e Recepção Síncrona de MDF-e no ambiente de homologação. As empresas já podem testar conforme especificado no MOC 3.00a, as URL´s dos serviços contam no menu Serviços deste portal. Obs: A consulta QR Code pelo smartphone poderá apresentar erro de certificado digital, o usuário poderá clicar em avançado e pedir para acessar mesmo assim, ou instalar o certificado raiz brasileira v2 em seu dispositivo pelo link: http://acraiz.icpbrasil.gov.br/credenciadas/RAIZ/ICP-Brasilv2.crt. Só será necessário baixar a primeira vez. Esta foi uma mudança feita pelo próprio ITI, responsável pelo ICP-Brasil, na forma como as raízes são baixadas pelos navegadores de smartphone. Até o final da semana que vem vamos disponibilizar as alterações necessárias no componente ACBrMDFe para que seja possível o envio de MDF-e no modo Síncrono.

Já consegui. O que me ajudou foi isso aqui: https://github.com/nfephp-org/sped-common/blob/master/src/Signer.php Se quiser ajuda é só falar.

dá uma olhada que eu acho que foi mudado recente esse código

Tem que achar os dados pois ai só tem link de uma noticia que não leva a local algum tente conseguir isso

Não aproveite tópicos. crie um seu para fazer a pergunta . Sobre a situação creio que não tenha problemas

só lembrando, não programe igual fosse trabalhar com uma aplicação desktop tem que ter um servidor com as regras de negócio e o unigui consome esses processos.

Eduardo. chegou a enviar uma remessa pra ver se validava junto ao banco? teria que olhar no log senão foi por causa de algum post especifico geralmente colocamos o link do post assim vai ficar fácil de identificar, mas não trabalho com banrisul

A mudança parece fazer sentido... mas convém testar em alguns outros DFe's, como NFe, NFCe, CTe, etc...

Por favor Desabilite o envio em segundo Plano, e faça um novo testes...

Infelizmente a versão oficial dos schemas disponibilizados não permite a visualização do status atual da manifestação. Porém... Se observarmos o software gratuito da SEFAZ, percebemos que ao "baixar" uma nota já vem o status atual da manifestação. Mesmo se a manifestação do destinatário tenha sido realizada em outro software. Isso acontece pois o software gratuito utiliza uma versão mais recente dos schemas (v.135). Nessa versão existe uma tag chamada: cSitConf. (se olhar a nota técnica até existe a menção dessa tag) Mas como essa não é uma versão oficial, digo, disponibilizada pela SEFAZ. Creio que ACBr não irá utilizar. De qualquer forma vou deixar aqui o link para download desses schemas. Com uma simples alteração na unit pcnRetDistDFeInt você adiciona uma nova property e na sequencia pode ler o valor desse campo. Nessa versão infelizmente o método DistribuicaoDFePorChaveNFe não funciona. (Mas é possível contornar isso alterando algumas linhas) --Se for DistribuicaoDFePorChaveNFe utiliza 1.02 caso contrário, utiliza a 1.35 v1.35.zip

Obrigado pela resposta mano. Me informaram que não precisa passar esses 3 campos quando a comunicação é por troca de arquivo.

Se foi desvinculado e em seguida solicitado o bloqueio, basta agora pressionar o reset pra que o aparelho volte "zerado".

Boa tarde @Juliana Tamizou Obrigado pela atenção... Sem problema de mudar a abordagem...só queria que as rotinas de leitura do retorno de 240 e 400 posições tratassem o nosso número da mesma forma.... Aguardo uma posição....

Boa tarde, Adicionado para análise, porém creio que essa abordagem podem haver problemas devido a quantidade livre para uso na verdade serem 8. Att.

Boa o tarde, O seu problema não tem nada haver com o que esta sendo tratado nessa postagem. O seu problema é referente ao certificado.

Boa tarde, Sim, o ACBrMonitorPlus já tem recursos para atender o eSocial. veja esta sessão do manual. https://acbr.sourceforge.io/ACBrMonitor/ComandosdoObjetoeSocial.html Att.

Boa tarde, Obrigada pela contribuição, adicionada para análise. Att.

Boa tarde Gabryel, Pelo que entendi, você quer carregar o XML de um evento e-Social e depois ler as informações contidas nesse XML através da leitura dos campos, correto? Pois bem, isso não é possível ser feito porque não foi implementado uma rotina que "popula" os campos ao ler o XML. A ideia do LoadFromFile deste componente é ler o XML e deixar disponível para o envio. Mas você pode analisar as alterações feitas nas Units: pcesTabelas (function TTabelas.LoadFromString(const AXMLString: String): Boolean;) e pcesS1060 (function TEvtTabAmbiente.LerXML: Boolean;) Algo semelhante você vai ter que fazer para os eventos que você desejar. No caso do evento 1030 as alterações deverão ser feitas nas units pcesTabelas e pcesS1030. Fique a vontade em fazer essa implementação. Toda ajuda é bem vinda o projeto.

Realizados ajustes e correções nos componentes: 1. Em TRetConsultaArquivoBlocox foi acrescentado FSituacaoOperCod e FSituacaoOperStr, e retirado FMensagem (que não é utilizado). Essa alteração é devido ao retorno estar diferente do layout. 2. Para algumas propriedades foi utilizado {$IFDEF VER300}AnsiString{$ELSE}String{$ENDIF}. Isso é porque estou compilando no Delphi 10, e devido ao tamanho do arquivo de estoque, com String fica limitado. 3. Incluído "ExtairArquivo" em "TDownloadArquivoBlocoX", para descompactar e salvar o conteúdo do XML. 4. Correções na leitura de algumas tags de retorno em "pcnRetEnvBlocoX". 5. Nos "TratarResposta" em "ACBrBlocoX_WebServices", foi alterado de: FPRetWS := Trim(ParseText(SeparaDados(FPRetornoWS, '..Response'))); Para: FPRetWS := Trim(ParseText(SeparaDados(FPRetornoWS, '..Result'))); Essa alteração é útil para abrir o retorno quando o mesmo é salvo em arquivo. Exemplo utilizando '...Response', o conteúdo extraído é: <ConsultarHistoricoArquivoResult><?xml version="1.0" encoding="utf-8"?> <RespostaConsultarHistoricoArquivo> <SituacaoOperacaoCodigo>0</SituacaoOperacaoCodigo> <SituacaoOperacaoDescricao>OK</SituacaoOperacaoDescricao> <Recibo>...</Recibo> <Eventos> <Evento> <DataHora>2019-06-13T14:52:53</DataHora> <Codigo>0</Codigo> <Descricao>Arquivo recepcionado, arquivo aguardando processamento</Descricao> </Evento> <Evento> <DataHora>2019-06-13T14:57:29</DataHora> <Codigo>2</Codigo> <Descricao>Erro no processamento do arquivo</Descricao> <Motivo>Erro ...</Motivo> </Evento> </Eventos> </RespostaConsultarHistoricoArquivo></ConsultarHistoricoArquivoResult> Exemplo utilizando '...Result', o conteúdo extraído é: <?xml version="1.0" encoding="utf-8"?> <RespostaConsultarHistoricoArquivo> <SituacaoOperacaoCodigo>0</SituacaoOperacaoCodigo> <SituacaoOperacaoDescricao>OK</SituacaoOperacaoDescricao> <Recibo>...</Recibo> <Eventos> <Evento> <DataHora>2019-06-13T14:52:53</DataHora> <Codigo>0</Codigo> <Descricao>Arquivo recepcionado, arquivo aguardando processamento</Descricao> </Evento> <Evento> <DataHora>2019-06-13T14:57:29</DataHora> <Codigo>2</Codigo> <Descricao>Erro no processamento do arquivo</Descricao> <Motivo>Erro ...</Motivo> </Evento> </Eventos> </RespostaConsultarHistoricoArquivo> Em anexo para novas validações. Luciano. ACBrBlocoX.zip

Precisei criar uma função para validar o número de Chassis de veículos (VIN). Segue o código como contribuição. Talvez possa ser incluído no ACBrValidador. function ValidaChassis(Chassis:string): boolean; var i,Soma,Numero,Resto: integer; Digito:string; function NumeroDaLetra(Letra:string):integer; begin if Letra = 'A' then result := 1 else if Letra = 'B' then result := 2 else if Letra = 'C' then result := 3 else if Letra = 'D' then result := 4 else if Letra = 'E' then result := 5 else if Letra = 'F' then result := 6 else if Letra = 'G' then result := 7 else if Letra = 'H' then result := 8 else if Letra = 'I' then result := 9 else if Letra = 'J' then result := 1 else if Letra = 'K' then result := 2 else if Letra = 'L' then result := 3 else if Letra = 'M' then result := 4 else if Letra = 'N' then result := 5 else if Letra = 'O' then result := 6 else if Letra = 'P' then result := 7 else if Letra = 'Q' then result := 8 else if Letra = 'R' then result := 9 else if Letra = 'S' then result := 2 else if Letra = 'T' then result := 3 else if Letra = 'U' then result := 4 else if Letra = 'V' then result := 5 else if Letra = 'W' then result := 6 else if Letra = 'X' then result := 7 else if Letra = 'Y' then result := 8 else result := 9; end; begin if length(Chassis) <> 17 then raise Exception.Create('Número do Chassis deve tger 17 caracteres'); Soma := 0; for i := 1 to 17 do begin if ((Chassis >= '0') and (Chassis <= '9')) then Numero := StrToInt((Chassis)) else Numero := NumeroDaLetra(Chassis); case i of 1,11: Soma := Soma + Numero * 8; 2,12: Soma := Soma + Numero * 7; 3,13: Soma := Soma + Numero * 6; 4,14: Soma := Soma + Numero * 5; 5,15: Soma := Soma + Numero * 4; 6,16: Soma := Soma + Numero * 3; 7,17: Soma := Soma + Numero * 2; 8 : Soma := Soma + Numero * 10; 9 : Soma := Soma + Numero * 0; 10 : Soma := Soma + Numero * 9; end; end; Resto := Soma Mod 11; if Resto = 10 then Digito := 'X' else Digito := IntToStr(Resto); result := Digito = Chassis[9]; end;

Não é possível emitir nenhum documento DFe com o ACBrFramework e o mesmo foi descontinuado.

o responsave da conta diz que nao tem DV na agencia, É o numero do posto de atendimento. Foi dessa forma que o pessoal da SICREDI me passou. Mas beleza, siga as orientações conforme eles e passarem. ACBrBancoSicredi.Pas function TACBrBancoSicredi.CalcularDigitoVerificador(const ACBrTitulo: TACBrTitulo String; begin Modulo.CalculoPadrao; Modulo.Documento := ACBrTitulo.ACBrBoleto.Cedente.Agencia + PadLeft(ACBrTitulo.ACBrBoleto.Cedente.AgenciaDigito, 2, '0') + PadLeft(ACBrTitulo.ACBrBoleto.Cedente.CodigoCedente, 5, '0') + FormatDateTime('yy',ACBrTitulo.DataDocumento) + ACBrTitulo.CodigoGeracao + RightStr(ACBrTitulo.NossoNumero,5); Modulo.Calcular; Dercide.

Boa tarde Lucimauro, Sim, mas a mudança é pequena, foi acrescentado uma tag que vai conter a string do QR-Code. Algo semelhante o que já ocorre com a NFC-e. Logo o DAMDFE vai ser alterado também, pois além do código de barras ele vai passar a ter também o QR-Code.

Suas sugestões foram disponibilizadas nos fontes do Projeto ACBr. Obrigado pela contribuição!