Painel de líderes

Bom dia Everton, Uma pequena correção, o programa exemplo do componente ACBrCNAB se encontra também no Branches na pasta: ...\Exemplos\ACBrCNAB\Delphi Felipe, o ACBrBoleto gera um arquivo texto a ser enviado para o banco referente a cobrança, por outro lado o ACBrCNAB tem como objetivo a gerar um arquivo texto a ser enviado também para o banco, mas referente a pagamentos.

Bom dia a todos. Acabei de corrigir e enviar ao SVN, na revisão 17188. O fato de as versões mais novas do Delphi e o Lazarus não acusarem o erro é que gerou essa confusão. O pior é que eu testei justamente nas versões que não dão problema. Esse comportamento foi alterado na versão XE4 para aceitar tanto $ENDIF como $IFEND como terminador do $IF ou $ELSEIF. Para quem quiser mais informação, veja: http://docwiki.embarcadero.com/RADStudio/Rio/en/Legacy_IFEND_(Delphi)

Boa tarde Rafael, Vou efetuar os testes e depois retorno com o feedback, obrigado!

Na verdade eu estava informando o campo nref sem necessidade. Grato pelo auxilio pessoal!!

Teu XML tem o grupo NFRef gerado, mas em branco: <NFref></NFref> Isso causa o erro de validação. Verifique a sua rotina, se está chamando o método ide.NFRef.Add ou ide.NFRef.New sem preencher os dados da nota. Se não há documento a referenciar você não deve chamar esse método.

Ok. Resolvido. Grato Felipe!

warobert Obrigado! fui ate lá (ACBrDFeHttpIndy.pas) e a galera do acbr já fez correção para svn., ai só baixei novamente e instalou perfeitamente. Obrigado a todos!

Bom dia, Claudiomir. Aqui foi normal, verifique sua conexão ou proxy:

Situação resolvida. Obrigado mais uma vez Felipe.

Já emiti as NFe usando a função GerarCodigoDFe, sem problema. Obrigado a vocês.

Bom dia, Rafael Alves de Souza. Veja o tópico abaixo:

Thiago Cocati Tive o mesmo problema e fiz a correção nas linhas indicadas alterando o {$endif} para {$ifend}, faça isso nas linhas indicadas, e resolverá até subirem a correção para svn. D:\ACBR\Fontes\ACBrDFe\ACBrDFeHttpIndy.pas(44) Error: E2029 $IFEND expected but $ENDIF found D:\ACBR\Fontes\ACBrDFe\ACBrDFeHttpIndy.pas(62) Error: E2029 $IFEND expected but $ENDIF found D:\ACBR\Fontes\ACBrDFe\ACBrDFeHttpIndy.pas(157) Error: E2029 $IFEND expected but $ENDIF found D:\ACBR\Fontes\ACBrDFe\ACBrDFeHttpIndy.pas(242) Error: E2029 $IFEND expected but $ENDIF found Erro ao compilar o pacote "ACBr_DFeComum.dpk". Sem mais, com a correção ficaria assim: {$IF CompilerVersion >= 33}System.Net.HttpClient,{$IFEND} Wanderson Robert

Bom dia. Alterações já estão no svn. Att.

obrigado @Juliana Tamizou foi exatamente isso.. como eu gostaria de ter lido este topico... ontem mais cedo... tinha evitado de ter perdido o dia inteiro... Obrigado pelas respostas. Assunto encerrado

Boa tarde Rodrigo, Muito obrigado pela colaboração, ainda hoje vou enviar para o repositório.

Bom dia! O ACBrMonitorPLUS segue "rigorosamente" o cumprimento das Notas Técnicas e Manuais. CRT - CÓDIGO DO REGIME TRIBUTÁRIO 1 = SIMPLES NACIONAL 2 = SIMPLES NACIONAL – EXCESSO DE SUBLIMITE DE RECEITA BRUTA 3 = REGIME NORMAL CST – Código situação tributária informada no grupo de tributação do produto para empresas que estão no regime normal (CRT=3) CSOSN – Código de Situação da Operação no Simples Nacional informado no grupo de tributação do produto, para empresas que estão operando no SIMPLES NACIONAL - (CRT=1) Logo se CRT=1 a tag formada no XML será CSOSN e não CST. Se a empresa está no Regime Normal o CRT deve "obrigatoriamente" ser = 3.

Bom dia! Você está emitindo para uma empresa do Simples Nacional? A impressão que dá é que vc está passando tags para o ICMS no Regime Normal (<CST>), mas a empresa está configurada no componente para o Simples Nacional (<CSOSN>)

Ola, já passei por isso certa vez e resolvi alterando o CRT da empresa. Experimente colocar o 1 (Simples nacional). De acordo com o CRT as regras de ICMS mudam e causam isso ai.

Bom dia. Recentemente tive que implementar no CNAB 400 do Banco do Brasil a opção para geração da remessa indicando Sacador/Avalista. Segue em anexo implementação para avaliação. ACBrBancoBrasil.pas

Olá pessoal, Quem atualizou os fontes e reinstalou a Suite ACBr, pode ser que esteja recebendo essa mensagem de erro no momento que vai gerar a NF-e / CT-e / MDF-e / BP-e. Porque esta mensagem esta aparecendo para alguns e para outros não? Simples, quando o XML é gerado com base em alguns dados do documento fiscal é gerado a chave do mesmo. Essa mensagem de erro é devido a uma validação que foi implementada na função que gera a chave. Essa validação visa garantir que a sua Nota (por exemplo) não seja rejeitada pela regra de validação B03-10 que consta na Nota Técnica 2019/001. Como vocês podem ver na imagem acima, a aplicação dessa regra é obrigatória, ou seja, todas as SEFAZ-Autorizadoras devem implementar essa regra. Ela será implementada no dia 01/07/2019 no ambiente de Homologação e no dia 02/09/2019 no ambiente de Produção. A validação que foi implementada ao gerar a chave é exatamente a descrita na regra, ou seja, o valor de cNF não pode ser igual a nNF e a nenhum dos números listados na regra. Por curiosidade resolvi pegar o Manual da NF-e mais antigo que tenho (Março de 2009) veja o que esta escrito na definição do campo cNF: O Manual deixa claro que o numero atribuído a cNF tem que ser um numero aleatório. Portanto quem costuma atribuir a cNF o mesmo numero atribuído a nNF esta fazendo errado e agora não vai ter perdão, pois se insistir a SEFAZ não vai aceitar a nota. Mas a regra B03-10 da Nota Técnica 2019/001 não se refere apenas a NF-e / NFC-e? Sim, mas tenham certeza que essa regra de validação em breve vai ser implementada para os demais DF-e - Documentos Fiscais Eletrônicos. Alguém duvida disso? O que devo fazer para que a minha aplicação não pare com a mensagem de erro: Código Numérico inválido, Chave não Gerada ? Muito simples, vou dar como exemplo o fragmento de código da minha aplicação: Como é hoje, note que eu já gerava o código como sendo um numero aleatório: NotaFiscalVenda := (DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := Random(99999999) + 1; // +1 para garantir que não seja zero Como vai passar a ser, para ter uma garantia maior ainda: NotaFiscalVenda : =(DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := GerarCodigoDFe(NotaFiscalVenda); A função GerarCodigoDFe esta definida na Unit ACBrDFeUtil, logo você vai ter informar essa Unit em Uses do seu Form. Note que ela recebe como parâmetro o numero da nota, pois a função vai gerar o código aleatoriamente e vai validar o mesmo e pela regra o código não pode ser igual ao numero da nota. De forma semelhante você terão que fazer o mesmo nas suas aplicações que emitem CT-e, MDF-e e BP-e. É preferível fazer essa correção na aplicação agora do que receber dezenas ou até centenas de ligações de clientes que não estão conseguindo autorizar os seus documentos na SEFAZ. Fica ai a dica.

function GerarChaveAcesso(AUF: Integer; ADataEmissao: TDateTime; const ACNPJ: String; ASerie, ANumero, AtpEmi, ACodigo: Integer; AModelo: Integer): String; var vUF, vDataEmissao, vSerie, vNumero, vCodigo, vModelo, vCNPJ, vtpEmi: String; begin // Se o usuario informar um código maior que zero validar o mesmo // if ACodigo > 0 then if ValidarCodigoDFe(ACodigo, ANumero) then raise EACBrDFeException.Create('Código Numérico inválido, Chave não Gerada'); // Se o usuario informar um código inferior ou igual a -2 a chave não será gerada // if ACodigo <= -2 then raise EACBrDFeException.Create('Código Numérico inválido, Chave não Gerada'); // Se o usuario informar 0 ou -1; o código numerico sera gerado de maneira aleatória // if ACodigo = -1 then ACodigo := 0; if ACodigo = 0 then ACodigo := GerarCodigoDFe(ANumero); // Se o usuario informar -2; o código numerico sera ZERO // // Pela Regra B03-10 que consta na NT 2019/001 versão 1.00 as notas vão ser // rejeitadas se o cNF for igual a zero. // if ACodigo = -2 then // ACodigo := 0; vUF := Poem_Zeros(AUF, 2); vDataEmissao := FormatDateTime('YYMM', ADataEmissao); vCNPJ := PadLeft(OnlyNumber(ACNPJ), 14, '0'); vModelo := Poem_Zeros(AModelo, 2); vSerie := Poem_Zeros(ASerie, 3); vNumero := Poem_Zeros(ANumero, 9); vtpEmi := Poem_Zeros(AtpEmi, 1); vCodigo := Poem_Zeros(ACodigo, 8); Result := vUF + vDataEmissao + vCNPJ + vModelo + vSerie + vNumero + vtpEmi + vCodigo; Result := Result + Modulo11(Result); end; Essa funcao, se eu mando um numero aleatorio = 54251212 está abortando a geracao da chave. penso que teria que que ser : if ACodigo > 0 then if not ValidarCodigoDFe(ACodigo, ANumero) then raise EACBrDFeException.Create('Código Numérico inválido, Chave não Gerada'); Essa funcao está usando em um repeat until, que espera o result true...

Estou criando um relatório em tempo de execução que irá verificar o DataType de um column de um grid e, caso seja um equivalente a ponto flutuante (ftFloat, ftExtended, ftBCD, ftCurrency, ftFMTBcd e ftSingle) irá gerar um RLDBResult com este campo. O problema é que campos no tipo (ftFMTBcd e ftSingle) o RLDBResult não calcula os valores, permanece valor 0, vide print: http://prntscr.com/o3vkjr. Alguém por ventura teria enfrentado este problema e conseguiu uma solução?

Substitua a sua rotina WriteLn pelo componente PosPrinter, com ele você terá o controle bem mais fácil sobre a formatação de caracteres, alinhamento, entre outros recursos.

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

Boa tarde Rick, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Jhonlenon, Primeiramente se deixássemos você emitir notas como costuma emitir (cNF = nNF) todos os seus clientes iriam passar a ter as notas rejeitadas pela SEFAZ a partir do dia 02/09/2019. O motivo é muito simples a SEFAZ vai rejeitar notas cujo valor de cNF seja igual a nNF. as notas que você emitiu antes da atualização dos fontes dos componentes tem o cNF = nNF, como você vai fazer para carregar o XML para poder imprimir novamente o DANFE ou enviar um evento? Muito simples, veja abaixo como é a definição da função LoadFromFile: function LoadFromFile(const CaminhoArquivo: String; AGerarNFe: Boolean = False) ; Boolean; Notou que o LoadFromFile tem 2 parâmetros, sendo que o segundo se for True o componente vai gerar novamente o XML e como no seu caso os valores de cNF e nNF são iguais vai ocorrer o erro. Pois bem, basta não informar o segundo parâmetro, assim esse assume o valor False que faz com que o XML não seja gerado novamente. Simples assim.

O que eu fiz aqui agora foi pegar o XMLAssinado e mandar imprimir depois que recebo ele e tirar da opção de enviar o imprimir assim consegui imprimir porem não traz o numero da NFS-e emitida mas pelo menos tem informações no danfe agora; O Danfe do FastReport que não consegui usar sempre da erro no CreateDataSet

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

Bom dia. Fica em Fontes\ACBrComum\ Att.

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

Bom dia, EvertonGoncalves Você pode utilizar o demo na pasta exemplos do ACBr para tirar todas as suas dúvidas. \ACBr\Exemplos\ACBrBoleto\

Bom dia, Roberto Fermino. Veja o tópico abaixo:

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 17187. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Boa tarde ALA, Qual é o problema da sua aplicação gerar um código aleatório e armazena-lo juntamente com os demais dados da nota? Na rotina que lê as informações do banco de dados e passa para o componente, tem uma linha que lê numero da nota da tabela e passar para nNF, correto? Qual seria a dificuldade de ler o código que obviamente estar armazenado em outro campo e atribuir a cNF?

Boa tarde a todos, Bom apesar de não ter nenhum comunicado no site oficial da prefeitura de campinas ou no provedor IssDsf.. o erro parece que estava por lá. não fiz nenhuma alteração significativa no sistema e agora de uma hora para outra a nota foi gerada... então esta tudo certo por aqui...

Boa tarde, Como essa questão de imprimir o QR-Code no DANFSE é uma ou outra cidade que tem, não foi implementado. No meu entendimento deveria ser feito um DANFSE especifico com o QR-Code, pois não podemos colocar no padrão, pois por padrão não existe o QR-Code no DANFSE.

Li há alguns dias, aqui mesmo no fórum, que o componente ACBr geraria esse código aleatório. Caso afirmativo, como alterar meu código para se adequar a essa futura exigência e se isto já é possível a partir de agora.

ewbCore é uma unit do projeto Delphi-EmbeddedWB. Nenhuma unit do ACBr atualmente faz uso de units desse outro projeto. É bem provável que seja algum problema local na sua máquina. Talvez arquivos alterados localmente.

Em primeiro lugar, o arquivo que você anexou não tem nenhuma alteração da versão que está no SVN agora. Não entendi se você o anexou por engano ou não... Mas se você deseja que uma alteração seja analisada, é necessário mandar o arquivo com a alteração. Em segundo lugar, o Guia prático da EFD ICMS IPI descreve que a questão não é a simples apresentação do registro C495 e sim que você não pode informar o Registro C425. Veja o que está na página 98, no primeiro parágrafo debaixo do subtítulo "Registro 495: Resumo mensal de ..." (o grifo é meu): Assim, do meu ponto de vista, a validação do componente que você menciona está correta: if Assigned( RegC001.RegistroC495 ) then begin if (DT_INI >= EncodeDate(2014,01,01)) and ( FBloco_0.Registro0000.UF = 'BA') then Check(False, 'A partir de 01/01/2014, os contribuintes situados na Bahia obrigados a este registro devem apresentar o registro C425.'); Então não podemos removê-la. Você é que deve remover a geração dos registros C495 dos que estão da Bahia.

Enviei o arquivo errado, segue em anexo o correto. ACBrDFeXsLibXml2.pas

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

O Manual diz que o número atribuído a cNF tem que ser um numero aleatório, e não um número que possa ser descoberto por terceiros, o que seria o seu caso. A finalidade é evitar fraudes e uso indevido por terceiros mal intencionados. Pode ser que o SEFAZ não rejeite a chave de acesso por enquanto, mas acredito que possa ser futuramente passível de rejeição por estar usando um número fixo e previsível.

Realmente haveria mensagem de inconsistência por conta da combinação CRT/CST. O que me assustou foi a alteração do xml pelo monitor. De qualquer forma, esta anotado, rsrs. Muito obrigado à todos.

Bom, é sua opinião vou respeita-la. Porém de igual forma a sua nota seria rejeitada e as schemas NÃO SÃO GERADAS pelo ACBr ele apenas segue a instrução. Esta composição de CRT e CST/CSOSN foi incluída na geração 2.0 da NFe algo pelos meados de 2010, já foi assunto muito discutido no passado.

bom dia Dercide, Ao efetuar a leitura do retorno ao alimentar o nosso número está entrando na função CalcularTamMaximoNossoNumero(), evento esse disparado na função LerRetorno240() onde preenche o nosso número formatado, nesse momento ainda não carregou a conta e acaba por gerar a exception da imagem 1 para resolver o meu problema efetuei as alterações de acordo com a imagem 3. o detalhe é que o retorno que utilizo é CNAB240.

obrigado.. já efetuei a criação de um novo tópico..

Fechando o tópico. Obrigado por reportar e para nova dúvida, abra novo tópico.

Bom dia! Realmente ficou comprovado que o escritório de Contabilidade que é externo à empresa, possui uma aplicação que fica rodando como robô que dispara pesquisas e manifestações a cada 5 minutos... o que contraria as regras e notas técnicas da SEFAZ, infelizmente nem todos seguem as boas práticas de programação, mas enfim, problema foi esclarecido e o cliente ficou ciente do que estava acontecendo. Desde já fica meu agradecimento @Italo Jurisato Junior Márcio M. Camilo

Boa tarde pessoal, Mais um super palestrante confirmou presença no Dia do ACBr 2019, Thulio Bittencourt, clique aqui e saiba mais. Att. E ainda tem mais, Também contaremos com a presença de William Duarte, mais um ótimo palestrante a nos prestigiar . Clique aqui e conheça mais. Att.

Por que disseram que ia mudar pra melhor, com certeza, quer dizer que ia mudar pra melhor, já tava bão, disse que ia mudar ele pra melhor, num tava muito bão, tava meio ruim também, tava ruim, agora parece que piorou!