Painel de líderes

Olá pessoal, O componente ACBrPagFor passou por um Refactoring. A motivação para esse Refactoring é tornar o componente mais fácil e prático no que se refere a implementar novos bancos bem como realizar manutenção no código sem correr o risco de gerar um efeito colateral nos bancos já implementados. Antes tínhamos apenas uma unit responsável por gerar o arquivo txt de remessa para todos os bancos. Isso gerava riscos na implementação e manutenção dos bancos existentes. Agora temos uma unit que gera o arquivo segundo o layout estabelecido pela Febraban e units separadas para cada banco. Assim, podemos alterar a procedure do registro ou do segmento que não segue a risca o layout da Febraban de um banco específico sem afetar outros. Desta forma dezenas de IF e CASE utilizados para identificar o banco em questão e gerar o txt corretamente, agora não existem mais. Desta forma temos um código muito mais limpo de ser lido e compreendido. Além disso foram removidas as propriedades de configuração: CNPJ e VersaoLayout que se encontravam em Configuracoes.Geral, pois estavam sem nenhuma utilidade. Agora no lugar delas temos as propriedades de configuração: Empresa e UsarDadosConfig. Novas Propriedades de Configuração: Propriedade Tipo Valor Padrão Descrição Empresa Grupo Dados da Empresa TipoInscricao TTipoInscricao tiIsento Determina o tipo de Inscrição da Empresa que pode ser: tiIsento, tiCPF, tiCNPJ, tiPISPASEP ou tiOutros. NumeroInscricao string Numero da Inscrição da Empresa conforme o tipo. Convenio string Numero do Convenio da Empresa estabelecido com o Banco. Nome string Razão Social da Empresa. Conta Grupo Dados da Conta AgenciaCodigo Integer 0 Numero da Agencia que a Empresa tem Conta. AgenciaDV string Digito Verificador da Agencia. ContaNumero Int64 0 Numero da Conta. ContaDV string Digito Verificado da Conta DV string Digito Verificado geral utilizado por alguns bancos. TipoConta Integer 0 Tipo de Conta, utilizado por alguns bancos. Endereco Grupo Dados do Endereço Logradouro string Nome do Logradouro do Endereço da Empresa. Numero string Numero ou código do Logradouro (veja a "obs." abaixo) Complemento string Complemento do Endereço. Cidade string Nome da Cidade. CEP Integer CEP do Endereço da Empresa. Estado string Sigla do Estado. UsarDadosConfig Boolean False Se True o componente vai utilizar as informações de configuração para serem utilizadas ao gerar o arquivo de remessa, caso contrario o desenvolvedor terá que alimentar diretamente os campos do componente. Observação: o tipo do campo Numero do logradouro do Endereço foi alterado de Integer para string pois a cidade de Bauru utiliza o formato xx-yy onde xx se refere ao numero da quadra em que a rua se encontra e o yy o numero do imóvel. Pasta dos fontes: Outro ponto importante é a localização das Units que compõe o componente: Pasta Descrição ACBrPagFor Pasta raiz dos fontes do componente. Bancos Pasta que contem as units dos bancos: (PagFor.NomeBanco.GravarTxtRemessa, PagFor.NomeBanco.LerTxtRetorno, PagFor.NomeBanco.Provider). Base Pasta que contem as units de classes, conversão e parâmetros. Provider Pasta que contem as units bases de geração e leitura do arquivo txt bem como a interface com as units de cada banco. Modelos Pasta que contem as units que podemos utilizada como modelo para quando for implementar um novo banco: (PagFor.Modelo.GravarTxtRemessa, PagFor.Modelo.LerTxtRetorno, PagFor.Modelo.Provider). Situação atual: Hoje o componente já conta com os seguintes bancos implementados: BancoCECRED, Banco do Brasil, Bradesco, HSBC, Itaú, Safra, Santander e Sicredi. Desafios a frente: Implementar e testar novos bancos melhorar a leitura do arquivo de retorno e extrair as ocorrências para que sejam apresentadas de forma clara e objetiva para que o desenvolvedor possa realizar os ajustes necessários Para que isso ocorra, contamos com a colaboração de todos.

Olá pessoal! Estamos fazendo uma limpeza nos componentes DFe e removendo lixo. Estamos removendo a propriedade FAX dos componentes de impressão DFe. Essa propriedade não é necessária e ainda por cima fere o MOC. Quando isso será comitado no SVN ? A previsão é 14/06/2022 as 12:00 commit at revision : 25851 Como isso me afeta? Depois da propriedade ser removida, você talvez não receba erros de compilação. Mas se você tentar executar a aplicação com uma propriedade inválida, pode ocasionar uma "violação de acesso" (Access Violation ou AV). O que eu preciso fazer? Se você tem qualquer componente de impressão DFe alocado em um Form ou DataModule, precisa abrir o form e remover a propriedade. Lembrando, que as impressões das informações são extraídas do XML, portanto, verifique no documento fiscal em questão a propriedade respectiva que você deseja alimentar "fone" caso não utilize ainda, verifique os schemas do projeto DFe especifico. Ao abrir o form, será apresentada uma mensagem como a abaixo, dizendo que a propriedade é inválida e não existe. Basta clicar em "Ignore" (ignorar) para que ela seja removida do DFM. Portanto, a sugestão é abrir todos os forms e ignorar todos os alertas que informarem que a propriedade FAX não existe mais. Mas eu tenho muitos forms e datamodules com vários componentes de impressão DFe. O que eu faço? Infelizmente não temos nada no ACBr para isso e o Delphi (e Lazarus) ainda não possuem ferramenta para validação do dfm. Então, tente usar uma ferramenta que faz validação dos dfm, como essa aqui: https://github.com/ahausladen/DFMCheck

Conforme aviso publicado no portal da NFe, o SVAN(SEFAZ Virtual do Ambiente Nacional) o qual autoriza a NFe para o estado do Maranhão, passará por manutenção entre as 13:00 e as 18:30 do dia 11/06/2022. Os contribuintes do MA deverão realizar a emissão em contingência por meio da SVC-RS, a SEFAZ Virtual de Contingência do RS. Fonte: https://www.nfe.fazenda.gov.br/portal/informe.aspx?ehCTG=false&Informe=4DkRp4SPAgM= Créditos: Obrigada @Ramon loureiro pelo alerta At.

Tem mais alguma ACBrLib junto ao exemplo ? no .exe ou em alguma outra pasta ? se tiver pode remover, mantenha ACBrLib x86 versão stdcall somente na pasta x86. Esta com os fontes do programa exemplo atualizado ? Você baixou também a pasta Comum no SVN ? Fiz um teste aqui com a mesma versão ACBrLib, rodando sem problemas:

Tudo bem! Irei migrar para o novo componente e realizar novos teste! Obrigado pelo retorno.

Olá Realizei o procedimento de revert conforme indicado e agora instalou perfeitamente. Obrigado abs

Boa tarde, Sempre use o método ConfigLerValor e ConfigGravarValor para alterar as configurações da lib, esses métodos já vai fazer a criptografia na escrita e descriptografia na leitura de forma automática para os campos necessários. https://acbr.sourceforge.io/ACBrLib/MetodosdeConfiguracao18.html

Você precisa primeiro configurar o ACBrMonitor para o layout simplificado. O campo verProc informado no seu arquivo INI não é para informar Layout. [evtComProd] [ideEvento] indRetif=1 perApur=2022-05 indGuia=1 tpAmb=1 procEmi=1 verProc=S01_00_00 <---- ISSO ESTÁ INCORRETO. AQUI NÃO É O LAYOUT DO eSocial Veja onde fazer isso:

Achei o problema. É que o usuário precisa estar criptografado no arquivo ini, e quando usei o programa de teste o usuário não foi salvo criptografado. Qual comando na lib posso usar para criptografar o usuário no ini usando a biblioteca LIB?

Eu até tentei trocar o valor, mas com certeza não coloquei 600, devo ter colocado 1. Não tenho como realizar o teste essa semana, mas segunda eu testo e posto o resultado aqui. Obrigado pela ajuda.

Bom dia! Tive sucesso ao utilizar o emulador da porta COM da EPSON, emulei a porta e fiz a implementação da verificação do status da impressora e me retorno se a gaveta estava aberta. Status := vACBrPosPrinter.LerStatusImpressora; Onde me retornou stGavetaAberta. Obrigado @Victor H. Gonzales - Panda !

Olá @doidopb GAP são esses 'cortes' na lateral da etiqueta, que possibilitam o sensor da impressora identificar o tamanho de cada etiqueta. Alterando o parâmetro "Origem" o problema foi resolvido?

@Daniel Simoes boa noite, Obrigado pela atenção. Notei a existência do GerarQRCodeDinamico também e inclusive faço uso dele. Detalhe é que nos testes do BB (só para homologação) o GerarQRCodeDinamico do ACBr não funciona. Pelo menos, não consegui usar. Quando o BB recebe uma requisição da criação de um Pix em Homologação ele gera informação totalmente diferente daquilo que Vc enviou na solicitação (criação). Os dados: MerchantName, MerchantCity e PostalCode são Eles que decidem e não a tua requisição. O nome do Recebedor que deveria ser Daniel (quem fez a solicitação), por exemplo. Eles alteram e tratam como se fosse: EMPRORT AMBIENTAL ou ALAN GUIACHERO (desculpe a caixa alta, mas, é assim que retorna o dado) Aqui um exemplo: 00020101021226870014br.gov.bcb.pix2565qrcodepix-h.bb.com.br/pix/v2/fffd7a08-8b7d-4559-8cc0-7118d374d1425204000053039865802BR5920ALAN GUIACHERO BUENO6008BRASILIA62070503***63044871 ou 00020101021226920014br.gov.bcb.pix2570qrcodepix-h.bb.com.br/pix/v2/cobv/ce0a57a8-d66e-448d-a0df-9b7c9352daea52040000530398654042.005802BR5925EMPRORT AMBIENTAL 6008BRASILIA62070503***630442BB E, com um detalhe. Vc nunca sabe se vem o Alan ou a Emprort (além de outros que Eles utilizam) Repetindo. Lembrando que isso é só para Homologação. Quando em Produção, se Vc enviar Daniel vai voltar Daniel como recebedor. A encrenca é que para simular o Pagamento (opção muita boa criada pelo BB) Vc precisa do copia e Cola exatamente como eles retornam. E, pra isso ocorrer, obrigatoriamente, é necessário usar o EndPoint https://api.hm.bb.com.br/pix/v1/cobqrcode/ E, também não pode usar GerarQRCodeDinamico do ACBr como copia e cola. Tem de usar o retorno que vem do json deles na opção textoImagemQRcode. Só reforçando mais uma vez. Estou sugerindo isso para os Colegas que irão iniciar a programação para o PSP B Brasil. Para Mim, isso não vai me afetar pq já estou com minha aplicação em produção e rodando nos Clientes. Inclusive, agradeço de coração a mão na roda que é o ACBr pra Nós, facilitando muito nossa vida. Só estou tentando auxiliar os Colegas que iniciarem a Programação e no momento que precisar fazer os testes de pagamento não ter que gerar esses testes diretamente em Produção.

@renanl23 a configuração para TLS 1.2 está habilitada, conforme abaixo:

Vou ver com o pessoal da prefeitura, pois no manual está dizendo que é 7 posições, más um exemplo que peguei deles diz que é 9. Confuso isso.

Nem todos os provedores disponibilizam ambiente e url de homologação. Confirme com provedor se existe para este município, senão vai ser necessário fazer seus testes em produção.

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

Saudações Digitais comunidade ACBr! Chegando mais novidades por aqui !!! Confira o ACBrPIXCD Nosso time de desenvolvedores não para... Estamos muito animados com mais esse lançamento... O componente para integração direta com PIX, que tem por objetivo tornar transparente a integração com os diversos PSPs existentes no mercado. O que é PIX ? Ahh.. essa é chover no molhado.. mas se você acabou de chegar de Marte, então veja esse vídeo O que é PSP ? São Prestadores de Serviços de Pagamento... No geral, podemos dizer que os Bancos são PSPs... mas podem haver Fintechs atuando como PSPs... Definir quem será o PSP recebedor, é definir para onde irá o dinheiro, quando você fizer uma operação de recebimento por PIX... Todos os PSPs, devem implementar a API padrão do Banco Central, para permitir a integração com as diversas Aplicações Comerciais, e soluções de Software do mercado. https://github.com/bacen/pix-api Ou seja, a Aplicação Comercial fala com cada um dos PSPs (e nunca diretamente com o Banco Central)... Apenas os PSPs, falam com o Banco Central Quais são os custos envolvidos ? Todo recebimento de transação PIX, pode gerar um custo, que é cobrado pelo PSP recebedor (seu Banco ou Fintech)... Alguns PSPs cobram uma porcentagem do valor transacionado, limitado a um valor máximo... Exemplo: 1,5% do Valor transacionado, mas limitado ao valor máximo de R$ 10,50. Alguns PSPs cobram um valor fixo por transação, independente do valor transacionado... Exemplo: R$ 0,90 por transação.. Alguns Bancos, como o C6 Bank, oferecem um número de transações gratuitas no mês, além de preço muito competitivo, veja esse artigo Além dos custos do PSP, se você usar alguma solução de integração, como TEF, ou Hub de Pagamentos Digitais, podem ocorrer custos de uso dessa plataforma... Qual a diferença receber o PIX via TEF, Hub de Pagamentos ou direto pelo PSP ? Usar TEF ou um Hub de Pagamentos Digitais, pode lhe dar mais autonomia na hora de configurar ou mudar de PSP.. pois isso será feito, pelo portal dessas soluções.. porém incorrerá em custos.. Sendo assim, a diferença está nas formas de contratação do serviço do PIX as quais tem variação de custos quando via TEF e quando é feito de forma direta. Outro ponto é a implementação dos fluxos a serem desenvolvidos dentro da sua Aplicação, de forma a garantir o recebimento das transações.. Veja abaixo, os cenários possíveis... Mas observe que em ambos, haverá a cobrança da Taxa do PIX por parte do PSP (conforme descrito acima) Usando o TEF: Se o seu cliente já possui TEF integrado no seu sistema... definitivamente será mais simples implementar PIX pelo TEF... Pois nesse caso, basta solicitar ao seu Distribuidor TEF, acrescentar a conexão do PIX no TEF, informando as credencias de acesso, do cliente... Nesse cenário, não haverá cobrança adicional, pois o seu cliente já está pagando pelo TEF... Então, com uma única integração, você poderá atender a Pagamentos por Cartão de Crédito/Débito, além de PIX e Carteiras Digitais Usando um Hub de Pagamentos: Se você precisa atender clientes que exigem muita configuração e ajuste e em diversos PSPs, pode ser mais simples contar com uma plataforma de Hub de Pagamentos, como a ShiPay... Pois nesse caso, toda a configuração de um novo PSP, será feita no Painel da plataforma, e o recebimento fica transparente para o usuário na Automação Comercial Direto com o PSP O ACBrPIXCD fala direto com o PSP escolhido, sem intermediários, por isso elimina custos. Mas pode ser difícil configurar vários PSPs, pois os processos mudam muito de uma instituição para outra. Esse é o cenário ideal, se o seu cliente ainda não possui TEF, e não pretende mudar de PSP com frequência. Pois você se conectará diretamente ao PSP, sem a necessidade de contatar serviços adicionais... Para que serve o componente ACBrPIXCD ? O componente foi desenvolvido para auxiliar a integração da sua Aplicação Comercial com os serviços PIX disponíveis pelo PSP, por exemplo: Criação de cobranças; Cancelamentos de cobranças; Estornos de pagamentos; Consultas... Ou seja, o ACBrPIXCD, implementa consulta aos EndPoints dos PSPs, definidos pela Documentação da API do Banco Central... Para cada PSP, teremos um componente específico, pois existem mudanças significativas, na forma como os PSPs implementam a API do Banco Central, principalmente quanto a segurança... Você deverá conectar o componente ACBrPIXCD a um componente de ACBrPSP*, para ter uma comunicação funcional da API PIX... Quais PSPs já estão integrados ao componente ACBrPIXCD? Atualmente já temos a integração completa com o PSP Banco do Brasil e a fintech Shippay. Também já iniciamos a implementação dos PSPs: Itaú e Santander e estamos trabalhando para em breve contarmos com vários outros PSPs. E claro, sua contribuição é muito bem vinda, então se ficou com vontade de estudar o código e ajudar o Projeto a crescer, ficaremos muito felizes! Como posso entender como funciona o componente ACBrPIXCD? Assim como todos os componentes ACBr, o ACBrPIXCD possui uma aplicação exemplo(demo) que pode ser baixada via svn, assim como o próprio componente. Nesse exemplo procuramos demonstrar separadamente a forma de utilização das principais funcionalidades do PIX. Além disso, para facilitar ainda mais, também demonstramos um fluxo de pagamento, simulando uma venda real. Abaixo está uma das telas do nosso demo (em Lazarus) para exemplificar: Porém, sempre a melhor maneira de entender o funcionamento de qualquer um dos componentes da nossa suíte será: "Use a força, leia os fontes" rs

Verifique a legislação do Estado, há divergências entre as UF, em regra, a tributação ocorre sobre itens "supérfluos", mas isso vai de Estado para Estado.

Se o regime é Cumulativo como descrito em outro tópico! Não deve ser informado os registros de entrada! No regime cumulativo só devem ser informados os registros de saída!

O registro 0500 identifica as contas contábeis utilizadas pelo contribuinte em sua Escrituração Contábil. Nesse caso será indicado as contas do próprio plano de contas da empresa, cadastrado no sistema e certamente enviado pelo contador.

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