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

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.

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.

Elisângela, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

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.

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

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.

Bom dia, Obrigada pelo interesse em contribuir com o projeto, sugiro realizar a alteração e anexar o pas modificado. Att.

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.

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

Bom dia @Minas Software Referente ao problema inicial, que ótimo que deu certo,seria interessante citar oque foi feito para beneficiar a comunidade. Para manter o foco, criei um novo tópico para esta situação Att.

Correção, o problema ocorre apenas com ftFMTBcd. O ftSingle faltou adicionar ao Case rsrs

Bom dia, Obrigada pela contribuição, adicionada para análise. Att.

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

Boa tarde Josafar, Por favor leia essa noticia: Código Numérico inválido, Chave não Gerada Ela trata sobre a NT, inclusive tem a função que gera o código aleatoriamente conforme a SEFAZ sempre exigiu.

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.

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

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.

Fechando o tópico. Para nova dúvida, crie novo tópico.

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

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

Por favor, continue em: https://www.projetoacbr.com.br/forum/topic/51855-reparando-acbrdfehttpindy/

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