Controle de Moeda nas Definições do Data Processing Engine

O que é

A Winter '27 traz uma nova configuração para definições do Data Processing Engine (DPE) que rodam sobre CRM Analytics ou Data 360: o controle explícito de como campos de moeda com múltiplas moedas são tratados. Você escolhe entre converter todos os valores de moeda para uma moeda única, garantindo cálculos consistentes, ou manter cada valor na sua moeda original para aplicar lógica de conversão customizada.

Antes dessa mudança, o comportamento era inconsistente entre os dois runtimes. O runtime de CRM Analytics convertia automaticamente os campos de moeda para a moeda do usuário de integração, sem opção de escolha. Já o runtime de Data 360 mantinha os valores na moeda original, mas sem nenhuma forma de selecionar uma moeda de destino. Ou seja, cada motor de execução do DPE resolvia o problema de um jeito diferente, e nenhum dos dois dava controle real à arquiteta.

Essa configuração de moeda só está disponível em orgs com múltiplas moedas habilitadas. Se sua org opera em moeda única, o item não se aplica.

Por que importa

Quem trabalha com DPE em cenários de consolidação financeira, scoring ou agregações que cruzam entidades com moedas diferentes sabe que a conversão implícita de moeda é uma fonte clássica de erro silencioso. Já vi cálculo que somava valores em moedas distintas sem conversão e devolvia um número tecnicamente correto, mas semanticamente errado, e ninguém percebeu até o fechamento do trimestre. O inverso também é problemático: se você precisa aplicar sua própria tabela de câmbio ou regra de negócio específica, uma conversão automática que você não controla atrapalha mais do que ajuda.

O ponto mais relevante aqui é a paridade de comportamento entre runtimes. Se você tem definições de DPE que hoje rodam em CRM Analytics e está migrando ou vai migrar para Data 360, essa diferença de tratamento de moeda era um risco real de regressão silenciosa nos números. Com o controle explícito, você define o comportamento na definição, não depende do runtime por baixo, e isso facilita portabilidade e auditoria dos resultados.

Como se preparar

• Mapeie todas as definições de DPE ativas em orgs multi moeda e identifique quais dependem hoje da conversão automática do runtime de CRM Analytics.
• Se você usa Data 360 e aplica conversão de câmbio manual em passos posteriores do pipeline, avalie se faz sentido migrar essa lógica para a nova configuração nativa do DPE.
• Antes de trocar o comportamento de uma definição em produção, rode em ambiente de teste e compare os resultados agregados com o histórico, principalmente em relatórios financeiros ou de scoring que dependem de valores monetários.
• Documente, por definição, qual opção de moeda foi escolhida e por quê, isso evita retrabalho de investigação quando alguém questionar um número discrepante mais adiante.

Nível de aplicação: Médio

É uma configuração simples de habilitar, mas exige análise cuidadosa de impacto em cálculos financeiros já existentes para evitar regressão silenciosa de números.

Considerações de arquiteto

• Antes de ativar, a arquiteta precisa auditar todas as definições de DPE em produção que hoje dependem da conversão implícita do runtime de CRM Analytics.
• Se a org já usa Data 360 com conversão manual em etapas posteriores do pipeline, vale avaliar consolidar essa lógica na configuração nativa para reduzir pontos de manutenção.
• A escolha entre moeda única e moeda original deve ser documentada por definição, com justificativa de negócio, para sustentar auditorias futuras.
• Testes comparativos entre o comportamento antigo e o novo devem rodar em sandbox antes de qualquer troca em definições que alimentam relatórios financeiros críticos.

Pegadinhas:

• O recurso só aparece em orgs com múltiplas moedas habilitadas, então quem opera em moeda única não terá essa opção disponível.

Este artigo faz parte do guia Flow na Winter '27, um item oficial por artigo. Fonte: release notes de Automation.