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

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 Everton, Esse componente não esta 100% é preciso fazer correções e melhorias, outra coisa, não tem todos os bancos implementados nele.

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.

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\

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

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

Vou verificar, aparentemente o erro se deu no módulo do Sintegra. Porém não consegui localizar. Obrigado pela dia.

da uma olhada ai nesse link tem bastante coisa https://www.projetoacbr.com.br/forum/search/?q=conjugada

Favor anexar o Log gerado pelo Instalador

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?

Foi o que também entendi, pois fica difícil controlar numeração para maquinas diferentes. Vou procurar mais informações, mas acredito que deve ter uma séria para cada máquina de venda embarcada, como era nas ECF. Grato.

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...

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

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 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..

Visulizar Arquivo Consulta SAT - WebService Este aplicativo utiliza o Componente ACBrSATWS do Projeto ACBr, permite realizar consultas em lote de CFe transmitidos via SAT para SEFAZ SP. Este componente utiliza recursos do WebService disponibilizado pela SEFAZ, pode ser útil para recuperar XMLs de CFe de um determinado período. Autor José M. S. Junior Enviado 18-06-2019 Categoria Utilitários - PRO  

Bom dia Henrique, Como está utilizando um CFOP relacionado a Combustível precisa informar o código relacionado ao Sistema SIMP (http://www.anp.gov.br/simp) . Veja em detalhes na página 80 do Manual de Especificações. https://portal.fazenda.sp.gov.br/servicos/sat/Downloads/Especificacao_SAT_v_ER_2_26_04.pdf

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

Bom dia a todos, Alguns desenvolvedores relataram problemas com os eventos, mais precisamente aqueles que carregam o XML do evento gerado pelas suas próprias aplicações. Detectamos que a SEFAZ sem querer querendo, resolveu utilizar códigos para novos eventos, códigos estes usados por outros eventos de outros tipos de Documentos Fiscais Eletrônicos. Como exemplo o código do evento Cancelamento por Substituição da NFC-e é o mesmo do evento de Encerramento do MDF-e. A função que converte o código em um enumerador acaba pegando o primeiro que ela encontra na lista, retornando um enumerador que não tem nada haver. A solução encontrada foi criar uma função de conversão para cada tipo de Documento Fiscal Eletrônico. Antes tínhamos a função StrToTpEvento, agora temos: StrToTpEventoNFe, StrToTpEventoCTe, StrToTpEventoMDFe e StrToTpEventoBPe. A função original: StrToTpEvento foi renomeada para StrToTpEvento_Old, função esta que não devemos mais utilizar pelo problema descrito acima. Pelo fato dela ter sido renomeada, quem a utiliza diretamente em alguma unit com certeza vai ocorrer erro de compilação. Para resolver esse problema, basta trocar o nome da função para a correspondente e se necessário incluir no uses uma das seguintes units: pcnConversaoNFe ou pcteConversaoCTe ou pmdfeConversaoMDFe ou pcnConversaoBPe. Observação: isso se você utiliza a função StrToTpEvento em alguma unit da sua aplicação, caso contrario não precisa se preocupar. Outra alteração que foi feita e que pode provocar uma exceção durante a execução da sua aplicação diz respeito ao código do documento fiscal. Desde o inicio nos manuais o ENCAT nos orienta a atribuir ao código do documento fiscal um numero aleatório, mas tem muitos desenvolvedores que simplesmente atribui o mesmo numero do documento fiscal. Exemplo da NF-e: O código do documento fiscais é o campo cNF que acaba recebendo o mesmo valor do numero do documento fiscal que é o campo nNF. Foi publicado a Nota Técnica 2019/001 que esta em anexo, nela temos a regra B03-10 que vai passar a comparar esses dois campos (cNF e nNF). A data de inicio dessa validação nas SEFAZ é: 01/07/2019 - Ambiente de Homologação e 02/09/2019 - Ambiente de Produção. A principio essa regra é valida somente para a NF-e e NFC-e, mas com certeza vai se estender para os demais tipos de documentos fiscais eletrônicos. Logo resolvemos incluir na função que gera a chave do documento a mesma validação a ser executada na SEFAZ, desta forma se os valores informados nos campos referente ao código e numero passarem pelo nosso validador, com certeza a sua nota não vai ser rejeitada na SEFAZ, quando essa regra for ativada. Vale lembrar que a regra B03-10 será obrigatória em todas as UF. Lembre-se, ao tentar emitir uma nota se aparecer a seguinte mensagem: Código Numérico inválido, Chave não Gerada, isso significa que o numero informado como código é exatamente igual ao numero do documento fiscal, no caso da NF-e /NFC-e (cNF = nNF). O valor de nNF tem que ser um numero sequencial. O valor de cNF tem que ser um numero aleatório. Na unit ACBrDFeUtil, criamos a função abaixo: function GerarCodigoDFe(AnDF: Integer): integer; Nela passamos como parâmetro o numero do documento fiscal, ou seja, o numero da nota (por exemplo) e ela gera aletoriamente e retorna o código para ser atribuído ao campo código (cNF, se tratando da NFe/NFCe). Essa função além de gerar o código aleatoriamente conforme orientação do ENCAT já valida conforme a regra B03-10. Observação: a função que gera a chave é utilizada pelos componentes: ACBrNFe, ACBrCTe, ACBrMDFe e ACBrBPe, logo a função que gera o código pode ser utilizada pelos desenvolvedores de qualquer um desses tipos de documentos fiscais. Prevenir é melhor do que remediar. NT2019_001 v1.00 - Regras de Validacao.pdf

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!