Painel de líderes

Olá pessoal, Quero comunicar o nascimento do mais novo membro da família ACBr. Estou falando do ACBrGTIN. Esse componente tem como objetivo realizar uma consulta na SEFAZ, onde é informado somente o GTIN do produto a ser consultado (também conhecido como código EAN) e temos como resposta informações cadastradas pelo "Dono da Marca" na GS1. Essas informações podem ser: o tipo do GTIN (que pode ser 8, 12, 13 ou 14) a descrição do produto o código NCM código do CEST. Infelizmente nem sempre teremos um retorno completo. Isso porque nem todas as empresas "Dono da Marca" cadastram os seus produtos na GS1 e muitas que cadastraram não autorizaram a divulgação dos dados. Neste caso podemos ter as seguintes rejeições: 9494: GTIN inexistente no Cadastro Centralizado de GTIN (CCG); 9495: GTIN existe no CCG com situação inválida. Solicitar ao dono da marca que entre em contato com a GS1; 9496: GTIN existe no CCG, mas dono da marca não autorizou a publicação das informações. Entrar em contato com o dono da marca; 9497: GTIN existe no CCG com NCM não cadastrado; 9498: GTIN existe no CCG com NCM inválido; Dica de uso do componente: Utilize ele ao cadastrar novo ou atualizar um produto na sua aplicação. Nunca, jamais mesmo, use o componente no momento da venda. Consta na NT 2022/001 versão 1.00 referente ao WS de Consulta do GTIN (página 6) a seguinte informação: Serão mantidos controles para identificar as situações de “uso indevido”, no consumo excessivo do Web Service em um curto espaço de tempo. As novas tentativas poderão ser rejeitadas com o erro “656–Rejeição: Consumo Indevido” Informação Importante: A Equipe ACBr esta trabalhando para disponibilizar o programa exemplo, bem como o pacote para o Lazarus e uma nova versão do ACBrInstall que permite a instalação no Delphi do novo componente: ACBrGTIN.

Olá Pessoal, Ao incluir uma nova cidade no arquivo ACBrNFSeXServicos.ini ou até mesmo alterar o provedor e ou URLs de ambiente de produção ou homologação de uma cidade devemos seguir os passos abaixo: 1. Salvar o arquivo ACBrNFSeXServicos.ini; 2. Executar o Compila_RES que se encontra na mesma pasta; 3. Reinstalar o ACBr; 4. Compilar a aplicação com a opção Build; 5. Realize os testes sempre usando o programa exemplo; 6. Criei um tópico no fórum incluindo a alteração ou inclusão feita para que possamos avaliar e enviar para o SVN. Se não seguir os passos acima a alteração realizada no ACBrNFSeXServicos.ini não será reconhecida pelo componente ACBrNFSeX. Toda contribuição é sempre bem vinda.

Parte 1 - Resumo da NT A versão 1.00 da NT 2022.001 foi foi publicada em 31/05/2022. Ela descreve a utilização dos WS de consulta das informações junto a SEFAZ Virtual do RS (SVRS), de forma a automatizar o processo de consulta da validade desta informação do GTIN. Se a informação não for válida, isso causará rejeição do DFe. Além das consultas gratuitas diretamente junto a SVRS, o GS1 também disponibiliza um Webservice (WS) pago que trazem informações mais completas e não tem as limitações do uso do WS da SVRS. Quando a validação terá inicio? Cronograma Homologação Produção Implantação da etapa 1 04/07/2022 12/09/2022 Implantação da etapa 2 06/03/2023 12/06/2023 Etapa 1 Regras I03-30, I12-60, U01-30, 9I03-10 e 9I12-10 Etapa 2 Regras 9I03-20, 9I03-30, 9I03-40, 9I12-20 e 9I12-30 Células com fundo verde: regras estão implementadas e seguirão implementadas, sem nenhuma alteração • Células com fundo vermelho: regras serão implementadas na etapa 2 • Todas as demais células: regras serão implementadas na etapa 1 O que muda na minha aplicação? Se seu cliente tiver um cadastro correto, as mudanças não deverão causa um grande impacto. Afinal ele já estará com o GTIN cadastrado corretamente e não receberá rejeição. Mas como sabemos que a realidade é geralmente bem diferente, o ideal é que sua aplicação comece a fazer a validação dos cadastros de forma semelhante ao que provavelmente você já faz para outras informações. Como sempre preocupada em trazer facilidades a nossa comunidade, a equipe ACBr está preparando os ajustes necessários para que a consulta aos WS da SVRS seja feita por meio de nossos componentes. Fique atento aos nossos canais que em breve tem novidade por ai! Parte 2 - Entendendo em Detalhes Afinal, o que é o GTIN ? O GTIN, sigla de “Global Trade Item Number” é um identificador para itens comerciais desenvolvido e controlado pela GS1, antiga EAN/UCC. Os GTINs, anteriormente chamados de códigos EAN, são atribuídos para qualquer item (produto ou serviço) que pode ser precificado, pedido ou faturado em qualquer ponto da cadeia de suprimentos. O GTIN é utilizado para recuperar informação pré-definida e abrange desde as matérias primas até produtos acabados. GTIN é um termo “guarda-chuva” para descrever toda a família de identificação das estruturas de dados GS1 para itens comerciais (produtos e serviços). Os GTINs podem ter o tamanho de 8, 12, 13 ou 14 dígitos e podem ser construídos utilizando qualquer uma das quatro estruturas de numeração dependendo da aplicação. O GTIN-8 é codificado no código de barras EAN-8. O GTIN-12 é mais utilizado no código de barras UPC-A, o GTIN-13 é codificado no EAN-13 e o GTIN-14 no ITF-14 CNP – Cadastro Nacional de Produtos, a fonte das informações tanto da SVRS quanto da GS1 O Cadastro Centralizado de GTIN (CCG) é um banco de dados contendo um conjunto reduzido de informações dos produtos que possuem o código de barras GTIN em suas embalagens, e funciona de forma integrada com o Cadastro Nacional de Produtos da GS1, que é o cadastro mantido pela organização legalmente responsável pelo licenciamento do respectivo código de barras. Os produtos em circulação no mercado que possuem GTIN e que são informados nos documentos fiscais eletrônicos, NF-e e NFC-e, terão suas informações validadas no CCG, de acordo com o cronograma previsto na legislação. Portanto, os donos das marcas dos produtos que possuem GTIN deverão manter atualizados os dados cadastrais de seus produtos junto ao Cadastro Nacional de Produtos (em cnp.gs1br.org/), de forma a manter atualizado o Cadastro Centralizado de GTIN. Se tanto a SVRS quanto o GS1 usam a mesma fonte de dados, porque existem 2 WS diferentes? Ambas trarão a informação mínima exigida pela legislação, mas o WS do GS1 traz informações adicionais, além de não ter as retrições do WS da SVRS. Veja o comparativo a seguir: SVRS GS1 Requer Certificado Digital X Limite de Consultas Baixo (Controle de Consumo indevido) Retorno Código GTIN Tipo do GTIN Descrição do Produto NCM Código CEST Código GTIN Tipo do GTIN Descrição do Produto NCM Código CEST Marca Dados de Classificação do Produto Peso Bruto Unidade de Medida do Peso Bruto URL da foto do produto GTIN de nível inferior Qtd de itens contidos Gratuito Variado conforme relação da empresa com o GS1 (podendo ser 0)

Bom dia, Estou implementando a cidade de Júlio de Castilhos provedor Pronim, segue ACBrNFSeXServicos.ini com as configurações da cidade... ACBrNFSeXServicos.iniACBrNFSeXServicos.res Tomei a liberdade de compilar o ACBrNFSeXServicos.res para facilitar. Desde já agradeço, Atenciosamente, Gabriel Bobello

Obrigado pela observação, Italo. Por enquanto, devido ao atendimento de algumas emergências, colocamos um panel bloqueando a tela, apenas para evitar que o usuário clique apressadamente onde não deve. Assim que possível, iremos estudar melhor o assunto. Já anotei aqui sua resposta. Pode fechar o tópico, e obrigado a todos pelas explicações.

Sim, Mas olha o que o suporte deles responderam Tenta realizar na Tag exigibilidade o >511< , pois foi dessa forma que foi enviado as outras notas emitidas anteriormente, é da importação do sistema anterior. Isso que o suporte mencionou foi notas feitas por importação de arquivo, que não tenho certeza que envia essa informação. Mas obrigado...vou tentar resolver com eles e caso tenha alguma atualização aviso por aqui

Boa tarde. Já deu uma olhada neste topico?

o campo <cProdANVISA> é o campo GERISTRO no .xls da uma olhada aki: https://www.gov.br/anvisa/pt-br/assuntos/medicamentos/cmed/precos

Boa tarde Italo, certo vou fazer os testes e te retorno.

não. tem que revisar o código e ver se é possível

Olá, bom dia ! Veja se este tópico te ajuda:

ok. brigaduuuuu

Resolvi o problema estava na base de calculo, não tive retorno mas agradeço.

Boa noite, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-2816

Componente foi refatorado para facilitar a inclusão de novos idiomas. As alterações já estão disponíveis no SVN: - Refatoração do componente ACBrExtenso: Rev. 25884 - Ajustes nos demos: Rev. 25885

Bom dia, No manual que você anexou não existe nenhuma parte onde diz como deve ser montado a ficha de compensação, por isso eu disse para você anexar o manual de confecção da ficha de compensação, geralmente as instituição bancárias tem esse manual, dizendo o que cada campo da ficha de compensação, tamanhos mínimos, papeis, etc. Esse manual que você mandou basicamente é para gerar a remessa / retorno (cnab) não trata em si da ficha de pagamento/compensação. Referente a essa propriedade que existe no manual que é referente ao campo livre, que no manual na página 21 refere-se a "Seu número da Operação", essa propriedade para composição do campo livre ela é mapeada no componente como lhe passei acima no item 3.14 das peculiaridades, isso não gerando problemas para compensação/pagamento da ficha. Alterar essa propriedade que esta em produção isso irá gerar um impacto negativo, isso será declinado, pois isso irá impactar em todas as linhas digitáveis de quem já utiliza, e só resolver o seu caso e os próximos. Como eu disse na sexta feira as 15horas, a propriedade foi removida da ficha de compensação, ficando apenas na linha digitavel, no lugar foi impresso o número da conta bancária, esse que é utilizado na geração da remessa.

Estou anexando um exemplo de boleto gerado direto pelo Internet Banking... Veja que a Linha Digitável não consta o Código de Beneficiário (que é o Código de Cedente), mas é impresso no campo abaixo do Vencimento.. Na Linha Digitável consta este código de operação, conforme manual...

https://www.gnre.pe.gov.br:444/gnre/v/guia/digitar

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

Nesta quarta-feira falaremos sobre o ACBrPIXCD, não perca e aproveite para sanar todas as suas dúvidas.

Você baixou o Lazarus 64 bits, e está tentando compilar a aplicação, com um Perfil de Build de 32 bits... Sugiro usar o Lazarus em 32 bits... caso contrário você terá muita dificuldades, em achar todas as Bibliotecas externas em 64 bits