Este tópico apresenta as novas etapas de eliminação e anonimização dos dados para ambientes que possuem a integração entre o Linx POS com o Linx Reshop LGPD.

Eliminação de dados ou anonimização

No HF008 do Linx POS 7.7.1SPK3, a stored procedure(*) de eliminação e anonimização dos dados de pessoa física, gravará os dados de sua execução e problemas que ocorrem durante a execução do log, com o objetivo de diagnosticar os possíveis problemas causados durante o processo.

Os logs serão gravados na tabela LJ_LGPD_LOG do banco de dados.

(*) stored procedure LX_LJ_LGPD_TRATAMENTO, que executará as seguintes funções:

  1. CPF: Informar o número do CPF do cliente que pode ser informado em formato de texto com 11 caracteres.
  2. Tratamento: Ação que deve ser executada pela procedure tendo as opções de realizar a exclusão usando o valor "1", ou anomalização usando o valor "2".

A partir do HF008 do Linx POS 7.7.1SPK3, ao entrar no Linx POS, será verificado se existem solicitações pendente de eliminação e anonimização cuja data prevista já chegou, executando automaticamente a solicitação.

Em síntese, foram aplicadas as seguintes melhorias no sistema:

  • Diariamente o sistema deve eliminar os dados pessoais referentes a pessoas que solicitaram eliminação ou anonimização que ficarem retidos no momento do processamento da solicitação, mas que a data prevista para eliminação ou anonimização chegou.
  • Os dados de pessoa física existentes em pedidos finalizados, devem ser mantidos até pelo mesmo prazo determinado no parâmetro utilizado no processo de eliminação e anonimização para pedidos pendentes de serem faturados.

Aplicado uma melhoria no HF008 do Linx POS 7.7.1SPK3 para quando entrar no sistema, haja uma verificação das solicitações recebidas de eliminação e anonimização na tabela LGPD_SOLICITACAO_RECEBIDA, processando-as quando houver.

Sendo elas:

  • Pelo menos uma vez ao dia, o sistema irá verificar todas as solicitações de eliminação ou anonimização recebidas do Linx ERP e tratá-las automaticamente, guardando o resultado do processamento da solicitação para posterior envio ao Linx ERP.
  • Se ocorrerem eventuais inconsistências durante o tratamento da solicitação, deverão continuar pendentes, para processá-las posteriormente.
  • Mais de um terminal de Linx POS não pode pegar a mesma solicitação para processar ao mesmo tempo.

Implementação no HF008 do Linx POS 7.7.1SPK3, para que não sejam eliminados ou anonimizados os dados cuja hipótese de pendências por vários motivos, dá o direito ao estabelecimento mantê-los, para evitar problemas do não cumprimento de obrigação legal ou contrato ou problemas operacionais.

Sendo assim, foram criados os parâmetros que controlam a manutenção dos dados do cliente em função de hipóteses de tratamento:

LGPD_DIAS_OBRIGA_FISCAL

LGPD: dias para manter os dados de pessoa física necessários para obrigação acessória, conteúdo padrão = 1827.

O objetivo principal é manter os dados necessários para os arquivos do Menu Fiscal (PAF-ECF). Em futuro próximo, também irá tratar o PAF-NFC-e e, no próximo ano, o PAF-DAF.

LGPD_TEXTO_OBRIGA_FISCALTexto a ser utilizado quando o dado for retido em função do parâmetro acima. Conteúdo padrão = 'Dados mantidos por obrigação legal acessória'.
LGPD_DIAS_AUTORIZAR_NF

LGPD: dias para manter os dados de pessoa física necessários para nota fiscal ou CF-e ainda não autorizados. O conceito é que deve haver uma proteção para não comprometer a autorização do documento, sem deixar de eliminar dados de documentos que nunca serão autorizados (lixo no banco de dados). Conteúdo padrão=7 (uma NF-e tem o prazo de 7 dias para ser autorizada).

LGPD_TEXTO_AUTORIZAR_NFTexto a ser utilizado quando o motivo da retenção for em função do parâmetro acima.
LGPD_DIAS_PEDIDO_PEND

LGPD: dias para manter os dados de pessoa física relacionados a pedidos pendentes, inclusive quanto a reservas (tabela LOJA_RESERVA).

Conteúdo padrão = 31 dias (provavelmente, entregas aguardando mais de um mês não serão finalizadas nunca).

LGPD_TEXTO_PEDIDO_PENDTexto a ser utilizado quando o motivo da retenção for em função do parâmetro acima.
LGPD_DIAS_CONSERTO_PENDLGPD: dias para manter os dados de pessoa física relacionados a consertos pendentes (LOJA_CONSERTO). Conteúdo padrão = 31 dias.
LGPD_TEXTO_CONSERTO_PENDTexto a ser utilizado quando o motivo da retenção for em função do parâmetro acima.
LGPD_DIAS_ENVIO_ERP

LGPD: dias para manter os dados de pessoa física para envio ao ERP, para garantir que ETL e Datasync tenham tempo de subir as informações ou até um possível reenvio em caso de problema.

Conteúdo padrão = 1 dia. Não é normal que ocorra a retenção por esse motivo, uma vez que o consumidor pediu para encerrar seu relacionamento com as rede de lojas.

LGPD_TEXTO_ENVIO_ERPTexto a ser utilizado quando o motivo da retenção for em função do parâmetro acima.

No ETL 3.1.10.16 e no Datasync 5.3.24, de acordo com as solicitações eliminação ou anonimização da LGPD, os dados de um cliente varejo cadastrado não sejam enviados para as lojas pertinentes à solicitação, foram feitas implementações no Linx ETL para quando um cliente varejo estiver sinalizado como bloqueado no ERP, para efeito de LGPD, para certa loja, seus dados cadastrais não devem ser enviados para a loja e também para determinadas lojas, seus dados podem ser enviados às demais lojas.

Para isto, foi aplicada melhoria no mapeamento das views W_ETL_LGPD_CLIENTES_VAREJO e W_ETL_PROP_CLIENTES_VAREJO para obter êxito no sincronismo do cadastro de clientes. 

Obs.: A regra foi alterada para sincronismo por filial.