EliasCesar

Foram identificados casos de fraude em que, usando engenharia social, golpistas instalam um proxy na maquina do lojista (ou no servidor do PDV) capaz de interceptar a resposta dos endpoints de criação de cobranca Pix (`/cob` e `/cobv`). Com isso, conseguem manipular o campo "pixCopiaECola" devolvido pela API do PSP, substituindo por um código falso que aponta para a conta do fraudador. O resultado: o cliente escaneia o QR gerado pelo PDV, paga normalmente, mas o dinheiro vai para outra conta. O lojista não recebe nada e só percebe o problema depois. --- ## O que foi feito ### O componente ACBrPIXCD recebeu uma camada extra de validação que é executada automaticamente após a criação de cobrancas (`CriarCobrancaImediata` e `CriarCobranca`). A validação verifica a integridade e a coerência do `pixCopiaECola` devolvido pelo PSP antes que o código chegue ao PDV ou seja exibido ao cliente. Essa proteção se aplica apenas a PSPs que utilizam o padrão Bacen (campo `IsBacen = True`). --- ## Como desativar, se necessário ### A validação é controlada pela propriedade ValidarCopiaECola do componente TACBrPixCD. Por padrao ela vem **habilitada**. Se a validação estiver gerando falsos positivos no seu PSP (erro ao criar cobrança sem motivo aparente de fraude), você pode desliga-la: - No Object Inspector (design time) Localize o componente ACBrPixCD1 no formulário, expanda suas propriedades e defina: ValidarCopiaECola = False - Por codigo (run time) ACBrPixCD1.ValidarCopiaECola := False; * IMPORTANTE: Desative a propriedade apenas como medida temporária de diagnostico. Recomendamos que você informe o caso ao nosso suporte no DISCORD para que o problema de compatibilidade seja corrigido. Manter a validação ativa e a forma mais segura de proteger seus clientes. --- ## Como atualizar ## Basta atualizar o componente ACBrPIXCD pelo SVN(trunk2). --- ## Duvidas e problemas ## Abra um tópico no Fórum informando: - Nome do PSP utilizado - Anexe logs (nível mais alto) - A mensagem de erro recebida (se houver) Com essas informações conseguimos verificar se e um caso de incompatibilidade com o PSP ou se a validação detectou uma adulteração real.

Olá @Alcindo de Almeida Neto Tivemos uma contribuição que provavelmente ja resolve também o seu caso: Assim que essa alteração for implementada no componente, atualizaremos também a API e volto avisar aqui.

Fechando o tópico, pois após as orientações o XML foi gerado corretamente. Conforme citado pelo Diego, seria necessário se credenciar Referente ao município de São Valentim do Sul, continuaremos tratando no outro tópico.

Olá, @Nicolas Cardoso Fizemos uma alteração para enviar ao XML o conteúdo informado nas configurações de NFSe da empresa. Por favor, faça um novo teste.

Olá @Nicolas Cardoso, Acredito que até segunda-feira esse problema já estará resolvido.

Que bom que deu certo! Obrigado por reportar. Fechando, Para novas dúvidas, abrir um novo tópico, por favor.

Olá @Alcindo de Almeida Neto Fizemos um ajuste. Por favor, faça um novo teste.

Olá @VEXCOM Sistemas - Valtair, Foi verificado que esse município utiliza o provedor Tinus. E esse provedor realmente não implementa a consulta por faixa, que é utilizada pela ACBrAPI para sincronização. Porém o enpoint /sincronizar deve ser usado APENAS em um dos casos: Status da NFSe está processando/erro, mas está autorizada na prefeitura; Status da NFSe está autorizada, mas está cancelada na prefeitura. Caso não seja nenhuma dessas situações, a rotina ConsultarNFSe deve te atender sem problemas: https://dev.acbr.api.br/docs/api/#tag/Nfse/operation/ConsultarNfse

Olá @Alcindo de Almeida Neto, A atualização dos municípios da ACBrAPI é independente das atualizações do componente. Então não ocorrerá instantaneamente. Ela depende de um build à parte. Porém tentamos manter sempre atualizados sim. Hoje pela manhã já foi atualizado, se vc estava esperando alguma atualização específica, por favor faça um novo teste.

Segue tbm a collection que estou usando pra testar: ACBr API.postman_collection.json

Olá @Nicolas Cardoso Efetuei um teste aqui, utilizando seu json. Testei no ambiente sandbox (URL: https://hom.acbr.api.br) Deixei o cadastro da loja da mesma maneira indicada: E aqui não ocorreu o erro informado, veja: Ao baixar o XML da DPS (GET /nfse/:id/xml/dps), é possível verificar que o campo foi gerado com sucesso, veja: Se possível, faça um teste em ambiente sandbox, pra verificarmos se ocorrerá o mesmo erro, por favor.

Criada task para análise da contribuição: ACBR-9152.

Criada tarefa para análise e implementação: ACBR-8975. Obrigado pela contribuição @LeoDoreto

Olá @itamarluiz Obrigado pela contribuição e pela iniciativa Analisamos a sugestão, mas optamos por não adicionar o método ao componente, pois mantemos os métodos estritamente alinhados às especificações da API. Essa abordagem poderia ser utilizada sem problemas do lado da aplicação. Agradecemos a colaboração e fique à vontade para continuar enviando sugestões!

Olá @arpa_sistemas Criei uma task para análise e implementação das alterações: ACBR-8910 Muito obrigado pela contribuição!

Olá @infonacci Alteração disponível no SVN, rev: 44338 Muito obrigado pela contribuição -- ACBrNFSeXWebservicesResponse -- [-] Alteração no método "Clear()" para limpar a propriedade "DataCanc". por: infonacci

Olá @infonacci, Muito obrigado pela contribuição Foi criada uma tarefa para análise: ACBr-8801

Opa, criada tarefa para validação: ACBR-8740.

Olá @Marcos Pereda O componente já está apto pra trabalhar com o Pix Automático. No nosso demo do ACBrPIXCD você consegue testar todos os endpoints relacionados a ele. Nesse tópico vc encontra mais detalhes sobre o assunto:

Como utilizar o componente ACBrSmartTEF O componente ACBrSmartTEF foi desenvolvido para facilitar a integração com o SmartTEF, permitindo, entre outras coisas, criar, consultar e cancelar ordens de pagamento de forma simples e padronizada. O exemplo incluído nos fontes do ACBr demonstra todas as principais funcionalidades e como configurar corretamente o componente. Configuração inicial Na aba “Configuração”, você deve informar os parâmetros necessários para comunicação com o SmartTEF: Seção Smart TEF GW-Token-Integrador → Token fornecido pelo SmartTEF para o integrador CNPJ Integrador → CNPJ do integrador cadastrado GW-Token-Loja → GW-Token específico da loja CNPJ Loja → CNPJ da loja vinculada JWT-Token-Integrador → Token JWT Seção Proxy (opcional) Permite configurar acesso via proxy caso a rede exija autenticação. Seção Log Define o arquivo e o nível de log (Ex: “Muito Alto” para depuração detalhada). Após preencher os dados, clique em Salvar Parâmetros para gravar as configurações no arquivo SmartTEFTeste.ini. Ordens de Pagamento Na aba Endpoints > ERP > Ordens de Pagamento, é possível criar novas ordens: Tipo Pagamento: CREDIT, DEBIT, PIX, VOUCHER, OUTROS. Parcelas: número de parcelas da venda (Apenas para Credito) Valor: valor total da operação Tipo Ordem: NRM (Será criado um card para todos os terminais), CRD_UNICO (A ordem será enviada APENAS para um terminal específico) Tipo Juros: F_CLIENT, F_STORE. ID Usuário: Id do usuário logado no terminal (Enviado APENAS caso o tipo seja CRD_UNICO). Serial POS: número de série do terminal (Enviado APENAS caso o tipo seja CRD_UNICO). CPF/CNPJ e Nome: dados opcionais do cliente Ao clicar em Criar, a aplicação enviará a requisição e exibirá no Log das Operações o JSON de retorno. Ordens de Impressão Na aba ERPs > Ordens de Impressão, é possível gerar comandos de impressão para comprovantes, definindo: Tipo Ordem: NRM (Será criado um card para todos os terminais), CRD_UNICO (A ordem será enviada APENAS para um terminal específico) Print Id: Id da impressão ID Usuário: Id do usuário logado no terminal (Enviado APENAS caso o tipo seja CRD_UNICO). Serial POS: número de série do terminal (Enviado APENAS caso o tipo seja CRD_UNICO). Arquivo: Arquivo de imagem enviado para impressão Log das Operações O painel lateral exibe todas as etapas executadas pelo componente: Leitura e gravação da configuração Comunicação com a API SmartTEF Respostas JSON das ordens criadas, consultadas, canceladas, etc. Demais Funcionalidades Além dessas principais funcionalidades, também é possível Listar Terminais, Usuários, Consultar Lojas... Comunicação com a API SmartTEF Respostas JSON das ordens criadas, consultadas, canceladas, etc. Equipamentos homologados para uso do SmartTEF em Produção: Rede: Laranjinha Positivo L400, N960K Cielo: LIO 2, LIO ON, AXIUM DX8000 Getnet: P2, P3, N910, A8, AXIUM DX8000 Stone: A8, P2, L400 Sipag: AXIUM DX8000, P2, X990 Sicredi: FLEX 405 (Clover) PagBank: P2, A930, GPOS780 SafraPay: P2, A8, L300 Vero: L300, N950, P2 CAIXA: FLEX 405 (Clover) Bin: FLEX 405 (Clover) Clover: FLEX 405 Phoebus: L300, A910, A920 Fonte: https://www.smarttef.com.br/ Veja também: https://linktr.ee/POS.SmartTEF

Olá @Paulo Vale O caso do Mercado Pago é um pouco delicado. Eles entraram em contato conosco e solicitaram para que a gente desativasse esse PSP no nosso componente ACbrPIXCD. Por isso no momento ele não está funcional.

Já utilizei impressão de etiquetas com Argox em rede, mapeadas com o 'net use'. O comando no cmd era algo como: 'net use LPT1 \\[PC_SERVIDOR_IMPRESSORA]\[IMPRESSORA_COMPARTILHADA]' Dessa forma era possível configurar no componente ACBrETQ a porta LPT1, e a impressão era enviada corretamente à impressora conectada na máquina servidor.

Boa noite @Everson Souto Tente fazer a instalação marcando essa opção:

Olá @paulosilva0306 Você precisa adicionar a diretiva de compilação FMX no seu projeto. Veja que ele não está usando o uses que deveria no seu print:

O certificado dessa maneira deve ser lido com sucesso. A chave será necessário descriptografar pra passar.