Produto

Sincroniza produtos por unidade (loja), preços, custos, saldos de estoque e propriedades logísticas entre o RPInfo e o RuB.

Identificação na Agenda de Execuções

• Nome do Job: Produto
• Grupo: RPInfo
• Chave do Job: rpinfoPRODUTO
• Endpoints:
  • v2.9 (padrão): /v2.9/produtounidade/listaprodutos/{lastId}/unidade/{cnpj}/detalhado
  • v3.2: /v3.2/produtounidade/listaprodutos/{lastId}/unidade/{cnpj}/detalhado, com suporte a /dataHoraManutencao/{dd-MM-yyyy HH:mm:ss}

Funcionamento Geral

O job consulta os produtos por unidade (loja), identifica ofertas, atualiza saldos de estoque (inclusive itens pesáveis), mapeia vida útil, calcula dias de venda (DDV), associa produtos pai e utiliza a tabela rpinfo_produto_depara para de-para de códigos.

Regra de De/Para e Produto Filho como Embalagem no RuB

No RPInfo, é comum que embalagens fechadas, caixas, fardos ou variações de um item possuam códigos de produto próprios (conhecidos como produtos filhos). No RuB, esses itens podem ser representados não como novos produtos cadastrais, mas sim como uma embalagem alternativa (EmbalagemLoja) associada a um produto principal (produto pai).

Esse comportamento é viabilizado através da tabela de mapeamento rpinfo_produto_depara:

1. Mapeamento de Origem e Destino:

   • produto_origem: Código do produto retornado pelo ERP RPInfo (produto filho / embalagem).
   • produto_destino: Código do produto pai no RuB ao qual a embalagem pertence.
   • qtd: Quantidade de unidades que compõem a embalagem (ex.: uma caixa com 12 unidades tem qtd = 12).

2. Como o Produto Filho Vira Embalagem:

   • Ignora Cadastro Principal e Estoque: Ao detectar que o item possui registro em rpinfo_produto_depara, o job ignora a criação ou atualização cadastral do produto principal (Produto) e o saldo de estoque (Estoque), evitando que o código filho sobrescreva as propriedades do produto pai.
   • Registro na Embalagem da Loja (EmbalagemLoja): O código do item é convertido para o produto_destino e o valor retornado pelo ERP é registrado como uma embalagem do produto pai:
     • preco_emb: Recebe o preço total do lote retornado pela API para o produto filho.
     • qtd: Recebe a quantidade de unidades da embalagem (dePara.getQtd()).
     • preco_un: É calculado automaticamente dividindo o preço do ERP pela quantidade de unidades (preco / qtd). Para itens pesáveis (Balanca = "P"), o valor unitário é ajustado dividindo por 1000.
     • É emitido o registro de interface embalagem_loja associando a quantidade e os preços calculados diretamente ao produto pai.

3. Controle via rpinfoProcessarPrecoProdutoFilho:

   • Em certos clientes, não se deseja que a importação de produtos filhos atualize ou sobrescreva os preços de embalagens no RuB.
   • O parâmetro avançado rpinfoProcessarPrecoProdutoFilho (Processa preços dos produtos filhos com De/Para, padrão true) permite controlar esse comportamento:
     • Ativado (true, padrão): Mantém o processamento de preços e embalagens para os produtos filhos com De/Para.
     • Desativado (false): Interrompe o processamento antes da gravação de EmbalagemLoja para qualquer item que possua registro em rpinfo_produto_depara, impedindo atualizações indevidas nos preços de embalagem do produto pai.

Fluxo de Execução

graph TD
    A["Job Produto Agendado por Loja (CNPJ)"] --> B{"Versão Endpoint?"}
    B -- "v2.9" --> C["GET /v2.9/produtounidade/listaprodutos/{lastId}/unidade/{cnpj}/detalhado"]
    B -- "v3.2" --> D["GET /v3.2/produtounidade/listaprodutos/{lastId}/unidade/{cnpj}/detalhado (ou dataHoraManutencao)"]
    C --> E["Processar Lote de Produtos"]
    D --> E
    E --> F["De-Para de Código (rpinfo_produto_depara)"]
    F --> G["Mapear Preços, Custos e Estoques (jobProdutoProcessarEstoque)"]
    G --> H["Calcular DDV (dias_venda) e Vida Útil (rpinfoCampoVidaUtil)"]
    H --> I["Compor codigo_preco (formatoCodigoPreco) e Identificar Ofertas"]
    I --> J["Extrair Curvas ABC e Nós Dinâmicos 'Extras'"]
    J --> K[("Salvar Produto e Propriedades no RuB")]

Atualização do Dígito Verificador (DV)

O Dígito Verificador (DV), também tratado como código de preço externo, é utilizado para compor as etiquetas de gôndola e validar a consistência dos preços durante as rotinas de auditoria em loja.

O RuB gera esse código a partir da máscara configurada no parâmetro avançado formatoCodigoPreco (por exemplo: ${Preco}-${PrecoVenda2}-${PrecoVenda3}). O cálculo resolve dinamicamente as variáveis de preços do produto, aplica validações de consistência para preços promocionais e formata cada segmento com preenchimento de zeros à esquerda respeitando a quantidade mínima configurada.

Fluxo Geral de Cálculo

graph TD
    A["Início: Carga de Produto ou Atualização de Desconto"] --> B["Obter Máscara Configurada (formatoCodigoPreco)"]
    B --> C{"Máscara Configurada?"}
    C -- "Não" --> D["Não Gera Dígito Verificador"]
    C -- "Sim" --> E["Identificar Variáveis da Máscara (${campo})"]
    E --> F["Para cada Variável"]
    F --> G["Buscar Valor nos Dados do Produto / ERP"]
    G --> H["Avaliar se Preço é ou Não Promocional"]
    H --> I["Formatar com 3 Dígitos (000)"]
    I --> J["Substituir Variável na Máscara"]
    J --> K{"Existem Mais Variáveis?"}
    K -- "Sim" --> F
    K -- "Não" --> L["Gravar Dígito Verificador (codigo_preco) no RuB"]

Como é Decidido se o Preço é ou Não Promocional

graph TD
    A["Variável (${campo})"] --> B{"Chave Configurada?"}
    B -- "Não" --> C["Tratar como Preço Regular"]
    B -- "Sim" --> D{"Variável ou Sinônimo = Chave?"}
    D -- "Não" --> C
    D -- "Sim" --> E{"Desconto < Preço Regular?"}
    E -- "Sim" --> F["Manter Preço Promocional"]
    E -- "Não" --> G["Neutralizar Desconto (000)"]
    F --> H["Retornar Valor"]
    G --> H
    C --> H

Regras de Composição do Código

1. Resolução de Variáveis: O sistema percorre as tags no padrão ${nomePropriedade} ou @{nomePropriedade} presentes na máscara configurada. Os valores são buscados nos dados cadastrais do produto, nos nós da resposta do ERP ou nas propriedades extras já gravadas.
2. Decisão de Preço Promocional: Para determinar se uma variável da máscara deve ser tratada como preço de desconto e passar pela validação de consistência contra o preço regular, o RuB avalia os seguintes critérios em sequência:
   • Verificação de Chave Configurada: Se a chave rpinfoDescontoPropriedadeParaPreco estiver vazia (não configurada), o mecanismo não será aplicado e nenhuma variável passará pela validação de desconto ou neutralização.
   • Correspondência Direta: Estando a chave preenchida, verifica se a variável informada na máscara (ex.: preco_desconto) é idêntica ao valor configurado em rpinfoDescontoPropriedadeParaPreco.
   • Resolução de Sinônimos: Caso o nome não coincida diretamente, consulta o de-para de sinônimos entre as chaves JSON do ERP e as propriedades extras. Se o sinônimo mapeado for igual ao configurado em rpinfoDescontoPropriedadeParaPreco, a variável é reconhecida como preço promocional.
   • Preço Regular / Faixa Normal: Se a variável não corresponder ao parâmetro nem diretamente nem por sinônimo (ou se a chave estiver vazia), ela é tratada como preço regular ou faixa de venda normal, mantendo seu valor original sem passar por neutralização.
3. Validação de Ofertas vs. Preço Regular:
   • Para as variáveis identificadas como preço promocional, o RuB busca o preço regular indicado em chaveDoPrecoNormal (padrão: Preco).
   • Oferta Válida (preco_desconto < precoRegular): O preço promocional é considerado vantajoso e utilizado na composição.
   • Oferta Inválida (preco_desconto >= precoRegular): Se o valor promocional for igual ou maior que o preço normal (ou estiver ausente), o componente promocional é neutralizado e definido como zero (000 por padrão).
4. Formatação com Zeros à Esquerda: Cada segmento de preço é formatado com preenchimento mínimo de caracteres numéricos definido pela configuração avançada rpinfoQuantidadeMinimaCharsCodigoPreco (padrão 3 dígitos) para valores regulares. Quando o preço resultar em zero (como em ofertas ausentes ou neutralizadas), a formatação respeita a quantidade mínima configurada em rpinfoQuantidadeMinimaCharsCodigoPrecoZero (padrão 3 dígitos). Por exemplo, mantendo o padrão de 3 dígitos, R$ 5,90 torna-se 590 e R$ 0,00 torna-se 000.
5. Gravação no RuB: A máscara resultante da interpolação de todas as variáveis é gravada na propriedade codigo_preco e no Dígito Verificador Externo do produto.

Compartilhamento com a Integração de Descontos

A rotina de geração do Dígito Verificador da integração de Produto é a fonte única de verdade para a chave de auditoria de preços. Quando o job de Descontos importa novas promoções, seleciona a melhor oferta ou realiza a limpeza de promoções expiradas, ele executa essa mesma lógica centralizada para manter o Dígito Verificador externo do produto sincronizado.

Consistência de Auditoria entre Produto e Desconto:

Ao neutralizar ofertas com valor igual ou superior ao preço regular (000), o produto mantém a mesma chave de verificação de quando não há promoção ativa. Isso evita que divergências cadastrais no ERP gerem etiquetas inconsistentes ou falsos positivos nas rotinas de auditoria de gôndola.

Importância de rpinfoDescontoPropriedadeParaPreco:

Se a chave rpinfoDescontoPropriedadeParaPreco estiver vazia (não configurada), o mecanismo de identificação de preço promocional e neutralização de ofertas não será aplicado. Para que a validação comparativa de desconto e a neutralização em 000 ocorram, essa configuração avançada deve ser preenchida com o nome da propriedade extra de desconto utilizada (ex.: preco_desconto).

Configurações Avançadas e Aplicação

Acesse no RuB em Configurações > Configurações Avançadas > Integração > RPInfo:

Propriedades Extras

Elementos do nó Extras com nome e valor preenchem dinamicamente propriedades adicionais de mesmo nome no RuB.

Tabelas

• rpinfo_controle: controle de sincronização (lastId ou dataHora) por loja.
• rpinfo_produto_depara: mapeamento de códigos (de produto origem/filho para produto destino/pai) e quantidade de embalagem entre RuB e RPInfo.
• rpinfo_classe_ignorada: cadastro de classes de produtos a serem ignoradas durante a sincronização.