Esta página foi traduzida pela API Cloud Translation.

Integração com o SAP

Esta página descreve as etapas de integração para cargas de trabalho operacionais do SAP (SAP ECC e SAP S/4 HANA) no Cortex Data Foundation. O Cortex Framework pode acelerar a integração de dados do SAP com o BigQuery usando modelos de processamento de dados predefinidos com pipelines do Dataflow até o BigQuery. Já o Cloud Composer programa e monitora esses pipelines do Dataflow para gerar insights dos dados operacionais do SAP.

O arquivo config.json no repositório do Cortex Framework Data Foundation configura as configurações necessárias para transferir dados de qualquer fonte, incluindo a SAP. Esse arquivo contém os seguintes parâmetros para cargas de trabalho operacionais do SAP:

  "SAP": {
        "deployCDC": true,
        "datasets": {
            "cdc": "",
            "raw": "",
            "reporting": "REPORTING"
        },
        "SQLFlavor": "ecc",
        "mandt": "100"
    }

A tabela a seguir descreve o valor de cada parâmetro operacional do SAP:

Parâmetro	Significado	Valor padrão	Descrição
`SAP.deployCDC`	Implantar a CDC	`true`	Gere scripts de processamento de CDC para serem executados como DAGs no Cloud Composer.
`SAP.datasets.raw`	Conjunto de dados de destino bruto	-	Usado pelo processo de CDC, é onde a ferramenta de replicação armazena os dados do SAP. Se estiver usando dados de teste, crie um conjunto de dados vazio.
`SAP.datasets.cdc`	Conjunto de dados processado pela CDC	-	Conjunto de dados que funciona como origem para as visualizações de relatórios e como destino para os DAGs processados de registros. Se estiver usando dados de teste, crie um conjunto de dados vazio.
`SAP.datasets.reporting`	Dataset de relatórios SAP	`"REPORTING"`	Nome do conjunto de dados que pode ser acessado pelos usuários finais para gerar relatórios, em que visualizações e tabelas voltadas ao usuário são implantadas.
`SAP.SQLFlavor`	Versão do SQL para o sistema de origem	`"ecc"`	`s4` ou `ecc`. Para testar dados, mantenha o valor padrão (`ecc`).
`SAP.mandt`	Mandante ou cliente	`"100"`	Mandatário ou cliente padrão para SAP. Para testar dados, mantenha o valor padrão (`100`).
`SAP.languages`	Filtro de idioma	`["E","S"]`	Códigos de idioma SAP (SPRAS) para usar em campos relevantes, como nomes.
`SAP.currencies`	Filtro de moeda	`["USD"]`	Códigos de moeda de destino da SAP (TCURR) para conversão de moeda.

Embora não haja uma versão mínima do SAP necessária, os modelos ECC foram desenvolvidos na versão mais antiga com suporte do SAP ECC. É normal que haja diferenças nos campos entre nosso sistema e outros sistemas, independente da versão.

Modelo de dados

Esta seção descreve os modelos de dados do SAP (ECC e S/4 HANA) usando os diagramas de relacionamento de entidades (ERD).

SAP ECC

Figura 2. SAP ECC: diagrama de relacionamento de entidade.

SAP S/4 HANA

Figura 2. SAP S/4HANA: diagrama de relacionamento de entidades.

Visualizações básicas

Esses são os objetos azuis no ERD e são visualizações em tabelas de CDC sem transformações, exceto alguns aliases de nome de coluna. Consulte os scripts em src/SAP/SAP_REPORTING.

Visualizações de relatórios

Esses são os objetos verdes no DER e contêm os atributos dimensionais relevantes usados pelas tabelas de relatórios. Consulte os scripts em src/SAP/SAP_REPORTING.

Visualização de utilitário ou BQML

Esses são os objetos amarelos no DER e contêm os fatos e dimensões mesclados, além do tipo específico de visualização usado para análise de dados e relatórios. Consulte os scripts em src/SAP/SAP_REPORTING.

Tags adicionais

As tags codificadas por cores neste ERD representam os seguintes recursos das tabelas de relatórios:

Tag	Cor	Descrição
`L`	Amarelo	Essa tag se refere a um elemento ou atributo de dados que especifica o idioma em que os dados são armazenados ou exibidos.
`S/4`	Vermelho	Essa tag indica que atributos específicos são específicos para o SAP S/4 HANA. Esse objeto pode não estar no SAP ECC.
`MANDT`	Roxo	Essa tag indica que atributos específicos contêm o parâmetro MANDT, que representa o cliente ou o ID do cliente, para determinar a instância de cliente ou empresa a que um registro de dados específico pertence.
`EXT`	Vermelho	Essa tag indica que objetos específicos são preenchidos por DAGs ou conjuntos de dados externos. Isso significa que a entidade ou tabela marcada não é armazenada diretamente no sistema SAP, mas pode ser extraída e carregada no SAP usando um DAG ou outro mecanismo.
`T`	Roxo	Essa tag indica que atributos específicos serão automaticamente materializados usando o DAG configurado.
`S`	Vermelho	Essa tag indica que os dados em uma entidade ou tabelas são influenciados ou afetados por várias moedas.

Pré-requisitos para a replicação do SAP

O Cortex Framework Data Foundation espera que as tabelas do SAP sejam replicadas com os mesmos nomes e tipos de campos criados no SAP.
Desde que as tabelas sejam replicadas com o mesmo formato, nomes de campos e granularidade, não é necessário usar uma ferramenta específica de replicação.
Os nomes das tabelas precisam ser criados no BigQuery em letras minúsculas.
A lista de tabelas usadas pelos modelos da SAP está disponível e pode ser configurada no CDC cdc_settings.yaml. Se uma tabela não estiver listada durante a implantação, os modelos que dependem dela vão falhar. Outros modelos seriam implantados com sucesso.
Considere o seguinte se você estiver usando o Conector do BigQuery para SAP:
- Para saber mais sobre a opção de conversão, siga a documentação padrão de mapeamento de tabelas.
- É recomendável desativar a compactação de registros, porque ela pode mudar os dados originais do SAP de uma maneira que afete a camada CDC do Cortex, bem como o conjunto de dados de relatórios do Cortex.
Se você não planeja implantar dados de teste e pretende gerar scripts de DAG do CDC durante a implantação, verifique se a tabela DD03L para metadados do SAP é replicada do SAP no projeto de origem. Essa tabela contém metadados sobre tabelas, como a lista de chaves, e é necessária para que o gerador de CDC e o resolvedor de dependência funcionem. Essa tabela também permite adicionar tabelas não cobertas pelo modelo para gerar scripts de CDC, como tabelas personalizadas ou Z.
Se houver pequenas diferenças no nome de uma tabela, algumas visualizações podem não encontrar um campo porque os sistemas SAP podem ter pequenas variações devido a versões ou complementos e anexar estruturas a tabelas ou porque algumas ferramentas de replicação podem ter um processamento ligeiramente diferente de caracteres especiais. Recomendamos executar a implantação com turboMode : false para detectar a maioria das falhas em uma tentativa. Exemplo:
- Os campos que começam com _ (por exemplo, _DATAAGING) têm o _ removido.
- Os campos não podem começar com / no BigQuery.
Nessa situação, é possível adaptar a visualização com falha para selecionar o campo conforme ele é inserido pela ferramenta de replicação escolhida.

Como replicar dados brutos do SAP

O objetivo da base de dados é expor modelos de dados e análises para relatórios e aplicativos. Os modelos consomem os dados replicados de um sistema SAP usando uma ferramenta de replicação preferencial, como as listadas nos Guias de integração de dados para SAP.

Os dados do sistema SAP (ECC ou S/4HANA) são replicados na forma bruta. Os dados são copiados diretamente do SAP para o BigQuery sem nenhuma mudança na estrutura. É basicamente uma imagem espelhada das tabelas do sistema SAP. O BigQuery usa nomes de tabelas em letras minúsculas para o modelo de dados. Portanto, mesmo que suas tabelas SAP tenham nomes em maiúsculas (como MANDT), elas são convertidas em letras minúsculas (como mandt) no BigQuery.

Pré-requisitos para a replicação do SAP

Considere os seguintes pré-requisitos para dados de replicação do SAP com a base de dados do Cortex Framework.

Integridade de dados: o Cortex Framework Data Foundation espera que as tabelas do SAP sejam replicadas com nomes, tipos e estruturas de dados idênticos aos que existem no SAP. Desde que as tabelas sejam replicadas com o mesmo formato, nomes de campos e granularidade, como na origem, não é necessário usar uma ferramenta de replicação específica.
Nomeação de tabelas: os nomes das tabelas do BigQuery precisam ser criados em letras minúsculas.
Configuração de tabela: a lista de tabelas usadas pelos modelos SAP está disponível e pode ser configurada no arquivo cdc_settings.yaml do CDC (captura de dados alterados). Se uma tabela não for listada durante a implantação, os modelos que dependem dela vão falhar, embora outros modelos não dependentes sejam implantados.
Considerações específicas BigQuery Connector para SAP:
- Mapeamento de tabela: sobre a opção de conversão, siga a documentação padrão de mapeamento de tabela.
- Desativar a compactação de registro: recomendamos desativar a compactação de registro, que pode afetar a camada CDC do Cortex e o conjunto de dados de relatórios do Cortex.
Replicação de metadados: se você não estiver implantando dados de teste e gerando scripts de DAG de CDC durante a implantação, verifique se a tabela DD03L para metadados do SAP é replicada do SAP no projeto de origem. Essa tabela contém metadados sobre tabelas, como a lista de chaves, e é necessária para que o gerador de CDC e o resolvedor de dependências funcionem. Essa tabela também permite adicionar tabelas não cobertas pelo modelo, por exemplo, tabelas personalizadas ou Z, para que os scripts de CDC possam ser gerados.
Processamento de variações menores no nome da tabela: se houver pequenas diferenças no nome de uma tabela, algumas visualizações podem não encontrar os campos necessários porque os sistemas SAP podem ter variações menores devido a versões ou complementos ou porque algumas ferramentas de replicação podem ter um processamento ligeiramente diferente de caracteres especiais. Recomendamos executar a implantação com turboMode : false para identificar a maioria das falhas em uma tentativa. Confira alguns problemas comuns:
- Os campos que começam com _ (por exemplo, _DATAAGING) têm o _ removido.
- Os campos não podem começar com / no BigQuery.
Nessa situação, ajuste a visualização com falha para selecionar o campo conforme ele é apresentado pela ferramenta de replicação escolhida.

Processamento da captura de dados alterados (CDC)

Escolha um dos seguintes modos de processamento de CDC que o Cortex Framework oferece para ferramentas de replicação para carregar registros do SAP:

Append-always: insere todas as mudanças em um registro com um carimbo de data/hora e uma flag de operação (Inserir, Atualizar, Excluir), para que a última versão possa ser identificada.
Atualizar ao acessar (mesclar ou inserir e atualizar) cria uma versão atualizada de um registro ao acessar a página change data capture processed. Ele executa a operação de CDC no BigQuery.

O Cortex Framework Data Foundation oferece suporte aos dois modos, embora para o append-always, ele forneça modelos de processamento de CDC. Alguns recursos precisam ser comentados para atualizar a página inicial. Por exemplo, OneTouchOrder.sql e todas as consultas dependentes. O recurso pode ser substituído por tabelas como CDPOS.

Processamento de CDC

Figura 1. Processamento de CDC.

Configurar modelos de CDC para ferramentas que replicam no modo de adição

Recomendamos configurar o cdc_settings.yaml de acordo com suas necessidades. Algumas frequências padrão podem resultar em custos desnecessários se a empresa não exigir esse nível de atualização de dados. Se você usar uma ferramenta que seja executada no modo de adição sempre, o Cortex Framework Data Foundation vai fornecer modelos de CDC para automatizar as atualizações e criar uma versão mais recente do twin digital ou da verdade no conjunto de dados processado pelo CDC.

É possível usar a configuração no arquivo cdc_settings.yaml se você precisar gerar scripts de processamento de CDC. Consulte Configurar o processamento do CDC para conferir as opções. Para dados de teste, você pode deixar esse arquivo como padrão.

Faça todas as mudanças necessárias nos modelos de DAG de acordo com sua instância do Airflow ou do Cloud Composer. Para mais informações, consulte Como coletar as configurações do Cloud Composer.

Opcional: se você quiser adicionar e processar tabelas individualmente após a implantação, modifique o arquivo cdc_settings.yaml para processar apenas as tabelas necessárias e execute novamente o módulo especificado chamando src/SAP_CDC/cloudbuild.cdc.yaml diretamente.

Configurar o processamento da CDC

Durante a implantação, é possível mesclar mudanças em tempo real usando uma visualização no BigQuery ou agendando uma operação de mesclagem no Cloud Composer (ou qualquer outra instância do Apache Airflow). O Cloud Composer pode programar os scripts para processar as operações de mesclagem periodicamente. Os dados são atualizados para a versão mais recente sempre que as operações de mesclagem são executadas. No entanto, operações de mesclagem mais frequentes resultam em custos mais altos. Personalize a frequência programada de acordo com as necessidades da sua empresa. Para mais informações, consulte Programação com suporte do Apache Airflow.

O exemplo de script a seguir mostra um extrato do arquivo de configuração:

  data_to_replicate:
    - base_table: adrc
      load_frequency: "@hourly"
    - base_table: adr6
      target_table: adr6_cdc
      load_frequency: "@daily"

Este arquivo de exemplo de configuração faz o seguinte:

Crie uma cópia de SOURCE_PROJECT_ID.REPLICATED_DATASET.adrc em TARGET_PROJECT_ID.DATASET_WITH_LATEST_RECORDS.adrc, se o último não existir.
Crie um script de CDC no bucket especificado.
Crie uma cópia de SOURCE_PROJECT_ID.REPLICATED_DATASET.adr6 em TARGET_PROJECT_ID.DATASET_WITH_LATEST_RECORDS.adr6_cdc, se o último não existir.
Crie um script de CDC no bucket especificado.

Se você quiser criar DAGs ou visualizações de execução para processar mudanças em tabelas que existem no SAP e não estão listadas no arquivo, adicione-as a esse arquivo antes da implantação. Isso funciona desde que a tabela DD03L seja replicada no conjunto de dados de origem e o esquema da tabela personalizada esteja presente nela. Por exemplo, a configuração a seguir cria um script do CDC para a tabela personalizada zztable_customer e uma visualização de execução para verificar as mudanças em tempo real de outra tabela personalizada chamada zzspecial_table:

    - base_table: zztable_customer
      load_frequency: "@daily"
    - base_table: zzspecial_table
      load_frequency: "RUNTIME"

Exemplo de modelo gerado

O modelo a seguir gera o processamento das mudanças. Modificações, como o nome do campo de carimbo de data/hora ou outras operações, podem ser modificadas neste ponto:

  MERGE `${target_table}` T
  USING (
     SELECT *
     FROM `${base_table}`
     WHERE
        recordstamp > (
            SELECT IF(
                MAX(recordstamp) IS NOT NULL,
                MAX(recordstamp),
                TIMESTAMP("1940-12-25 05:30:00+00"))
            FROM `${target_table}` )
  ) S
  ON ${p_key}
  WHEN MATCHED AND S.operation_flag='D' AND S.is_deleted = true THEN
    DELETE
  WHEN NOT MATCHED AND S.operation_flag='I' THEN
    INSERT (${fields})
    VALUES
    (${fields})
  WHEN MATCHED AND S.operation_flag='U' THEN
  UPDATE SET
      ${update_fields}

Como alternativa, se a empresa exigir insights quase em tempo real e a ferramenta de replicação oferecer suporte a isso, a ferramenta de implantação aceita a opção RUNTIME. Isso significa que um script de CDC não será gerado. Em vez disso, uma visualização faria a varredura e extrairia o registro mais recente disponível no momento da execução para consistência imediata.

Estrutura de diretórios para DAGs e scripts do CDC

A estrutura de bucket do Cloud Storage para DAGs de CDC do SAP espera que os arquivos SQL sejam gerados em /data/bq_data_replication, como no exemplo abaixo. É possível modificar esse caminho antes da implantação. Se você ainda não tiver um ambiente do Cloud Composer disponível, crie um e mova os arquivos para o bucket do DAG.

with airflow.DAG("CDC_BigQuery_${base table}",
                template_searchpath=['/home/airflow/gcs/data/bq_data_replication/'], ##example
                default_args=default_dag_args,
                schedule_interval="${load_frequency}") as dag:
    start_task = DummyOperator(task_id="start")
    copy_records = BigQueryOperator(
      task_id='merge_query_records',
        sql="${query_file}",
        create_disposition='CREATE_IF_NEEDED',
        bigquery_conn_id="sap_cdc_bq", ## example
        use_legacy_sql=False)
    stop_task = DummyOperator (task_id="stop")
    start_task >> copy_records >> stop_task

Os scripts que processam dados no Airflow ou no Cloud Composer são gerados separadamente dos scripts específicos do Airflow. Isso permite que você transfira esses scripts para outra ferramenta de sua escolha.

Campos do CDC obrigatórios para operações MERGE

Especifique os seguintes parâmetros para a geração automática de processos em lote do CDC:

Projeto de origem + conjunto de dados:conjunto de dados em que os dados do SAP são transmitidos ou replicados. Para que os scripts do CDC funcionem por padrão, as tabelas precisam ter um campo de carimbo de data/hora (chamado de recordstamp) e um campo de operação com os seguintes valores, todos definidos durante a replicação:
- I: para inserir.
- U: para "Update" (atualizar).
- D: para exclusão.
Projeto de destino + conjunto de dados para o processamento de CDC: o script gerado por padrão gera as tabelas de uma cópia do conjunto de dados de origem, se elas não existirem.
Tabelas replicadas: tabelas para as quais os scripts precisam ser gerados
Frequência de processamento: seguindo a notação Cron, com que frequência os DAGs precisam ser executados:
Bucket de destino do Cloud Storage, onde os arquivos de saída do CDC são copiados.
Nome da conexão: o nome da conexão usada pelo Cloud Composer.
(Opcional) Nome da tabela de destino:disponível se o resultado do processamento do CDC permanecer no mesmo conjunto de dados que o destino.

Otimização de performance para tabelas de CDC

Para alguns conjuntos de dados da CDC, talvez seja melhor usar o particionamento de tabelas ou o clustering de tabelas do BigQuery, ou ambos. Essa escolha depende dos seguintes fatores:

Tamanho e dados da tabela.
Colunas disponíveis na tabela.
Necessidade de dados em tempo real com visualizações.
Dados materializados como tabelas.

Por padrão, as configurações da CDC não aplicam o particionamento ou o clustering de tabelas. Você pode configurar o app com base no que funciona melhor para você. Para criar tabelas com partições ou clusters, atualize o arquivo cdc_settings.yaml com as configurações relevantes. Para mais informações, consulte Particionamento de tabelas e Configurações de cluster.

Esse recurso só se aplica quando um conjunto de dados em cdc_settings.yaml é configurado para replicação como uma tabela (por exemplo, load_frequency = "@daily") e não definido como uma visualização (load_frequency = "RUNTIME").
Uma tabela pode ser particionada e em cluster.

Se você estiver usando uma ferramenta de replicação que permita partições no conjunto de dados bruto, como o BigQuery Connector para SAP, recomendamos definir partições baseadas em tempo nas tabelas brutas. O tipo de partição funciona melhor se corresponder à frequência dos DAGs do CDC na configuração cdc_settings.yaml. Para mais informações, consulte Considerações de design para a modelagem de dados SAP no BigQuery.

Opcional: como configurar o módulo de inventário do SAP

O módulo de inventário do SAP do Cortex Framework inclui visualizações InventoryKeyMetrics e InventoryByPlant que fornecem insights importantes sobre seu inventário. Essas visualizações são apoiadas por tabelas de snapshots mensais e semanais usando DAGs especializadas. Ambos podem ser executados ao mesmo tempo e não interferem um no outro.

Para atualizar uma ou ambas as tabelas de snapshots, siga estas etapas:

Atualize SlowMovingThreshold.sql e StockCharacteristicsConfig.sql para definir o limite de movimentação lenta e as características de estoque de diferentes tipos de material com base nos seus requisitos.

Observação: a partir do Cortex Framework v6.0, esses scripts estão localizados no diretório src/SAP/SAP_REPORTING/{SQL_FLAVOR}, em que {SQL_FLAVOR} é ECC ou S4. Atualize os scripts corretos com base no seu sistema.
Para carga inicial ou atualização completa, execute DAGs Stock_Monthly_Snapshots_Initial e Stock_Weekly_Snapshots_Initial.
Para atualizações subsequentes, programe ou execute os seguintes DAGs:
- Atualizações mensais e semanais:
  - Stock_Monthly_Snapshots_Periodical_Update
  - Stock_Weekly_Snapshots_periodical_Update
- Atualização diária:
  - Stock_Monthly_Snapshots_Daily_Update
  - Stock_Weekly_Snapshots_Update_Daily
Observação: os nomes de DAG aqui se referem aos nomes de DAG após a implantação, conforme exibido na interface do Airflow.
Atualize as visualizações intermediárias StockMonthlySnapshots e StockWeeklySnapshots, seguidas pelas visualizações InventoryKeyMetrics e InventoryByPlants, respectivamente, para expor os dados atualizados.

Opcional: como configurar a visualização "Textos da hierarquia de produtos"

A visualização "Textos da hierarquia de produtos" nivela os materiais e as hierarquias de produtos. A tabela resultante pode ser usada para alimentar o complemento Trends com uma lista de termos para recuperar o interesse ao longo do tempo. Configure essa visualização seguindo estas etapas:

Ajuste os níveis da hierarquia e o idioma no arquivo prod_hierarchy_texts.sql, abaixo dos marcadores de ## CORTEX-CUSTOMER.
Se a hierarquia de produtos tiver mais níveis, talvez seja necessário adicionar uma instrução SELECT adicional semelhante à Expressão de tabela comum h1_h2_h3.

Talvez haja outras personalizações, dependendo dos sistemas de origem. Recomendamos que os usuários de negócios ou analistas se envolvam no início do processo para ajudar a identificar esses problemas.

Opcional: como configurar visualizações de nivelamento de hierarquia

A partir da versão v6.0, o Cortex Framework oferece suporte ao nivelamento de hierarquia como visualizações de relatórios. Essa é uma grande melhoria em relação ao nivelador de hierarquia legada, já que agora ele nivela toda a hierarquia, otimiza melhor para o S/4 usando tabelas específicas do S/4 em vez de tabelas ECC legadas e também melhora significativamente o desempenho.

Resumo das vistas de relatórios

Encontre as seguintes visualizações relacionadas ao nivelamento da hierarquia:

Tipo de hierarquia	Tabela que contém apenas a hierarquia simplificada	Visualizações para visualizar hierarquia nivelada	Lógica de integração de P&L usando essa hierarquia
Versão do extrato financeiro (FSV, na sigla em inglês)	`fsv_glaccounts`	`FSVHierarchyFlattened`	`ProfitAndLossOverview`
Centro de lucro	`profit_centers`	`ProfitCenterHierarchyFlattened`	`ProfitAndLossOverview_ProfitCenterHierarchy`
Centro de custos	`cost_centers`	`CostCenterHierarchyFlattened`	`ProfitAndLossOverview_CostCenterHierarchy`

Considere o seguinte ao usar visualizações de nivelamento de hierarquia:

As visualizações somente de hierarquia nivelada são funcionalmente equivalentes às tabelas geradas pela solução de nivelamento de hierarquia legada.
As visualizações de visão geral não são implantadas por padrão, porque servem apenas para mostrar a lógica do BI. Encontre o código-fonte no diretório src/SAP/SAP_REPORTING.

Como configurar o nivelamento da hierarquia

Com base na hierarquia com que você está trabalhando, os seguintes parâmetros de entrada são necessários:

Tipo de hierarquia	Parâmetro obrigatório	Campo de origem (ECC)	Campo de origem (S4)
Versão do extrato financeiro (FSV, na sigla em inglês)	Gráfico de conta	`ktopl`	`nodecls`
Versão do extrato financeiro (FSV, na sigla em inglês)	Nome da hierarquia	`versn`	`hryid`
Centro de lucro	Classe do conjunto	`setclass`	`setclass`
Centro de lucro	Unidade organizacional: área de controle ou chave adicional do conjunto.	`subclass`	`subclass`
Centro de custos	Classe do conjunto	`setclass`	`setclass`
Centro de custos	Unidade organizacional: área de controle ou chave adicional do conjunto.	`subclass`	`subclass`

Se você não tiver certeza dos parâmetros exatos, pergunte a um consultor de finanças ou de controle do SAP.

Depois que os parâmetros forem coletados, atualize os comentários ## CORTEX-CUSTOMER em cada um dos diretórios correspondentes com base nos seus requisitos:

Tipo de hierarquia	Local do código
Versão do extrato financeiro (FSV, na sigla em inglês)	`src/SAP/SAP_REPORTING/local_k9/fsv_hierarchy`
Centro de lucro	`src/SAP/SAP_REPORTING/local_k9/profitcenter_hierarchy`
Centro de custos	`src/SAP/SAP_REPORTING/local_k9/costcenter_hierarchy`

Se aplicável, atualize os comentários ## CORTEX-CUSTOMER nas visualizações de relatórios relevantes no diretório src/SAP/SAP_REPORTING.

Detalhes sobre a solução

As tabelas de origem a seguir são usadas para nivelamento de hierarquia:

Tipo de hierarquia	Tabelas de origem (ECC)	Tabelas de origem (S4)
Versão do extrato financeiro (FSV, na sigla em inglês)	`fagl_011pc` `fagl_011zc` `ska1`	`hrrp_node` `hrrp_directory` `ska1`
Centro de lucro	`setheader` `setnode` `setleaf`	`sethanahier0106`
Centro de custos	`setheader` `setnode` `setleaf`	`sethanahier0101`

Como visualizar as hierarquias

A solução de nivelamento da hierarquia SAP do Cortex nivela toda a hierarquia. Se você quiser criar uma representação visual da hierarquia carregada que seja comparável ao que o SAP mostra na interface, consulte uma das visualizações para visualizar hierarquias planas com a condição IsLeafNode=True.

Migrar da solução de nivelamento de hierarquia legada

Para migrar da solução de nivelamento de hierarquia legada anterior à Cortex v6.0, substitua as tabelas conforme mostrado na tabela a seguir. Verifique a precisão dos nomes dos campos, já que alguns foram ligeiramente modificados. Por exemplo, prctr em cepc_hier agora é profitcenter na tabela profit_centers.

Tipo de hierarquia	Substitua esta tabela:	Com:
Versão do extrato financeiro (FSV, na sigla em inglês)	`ska1_hier`	`fsv_glaccounts`
Centro de lucro	`cepc_hier`	`profit_centers`
Centro de custos	`csks_hier`	`cost_centers`

Opcional: como configurar o módulo de finanças do SAP

O módulo SAP Finance do Cortex Framework inclui visualizações FinancialStatement, BalanceSheet e ProfitAndLoss que fornecem insights financeiros importantes.

Para atualizar essas tabelas de finanças, siga estas etapas:

Para o carregamento inicial

Após a implantação, verifique se o conjunto de dados do CDC está preenchido corretamente (execute os DAGs do CDC conforme necessário).
Verifique se as Visualizações de nivelamento de hierarquia estão configuradas corretamente para os tipos de hierarquias que você está usando (FSV, centro de custo e centro de lucro).
Execute o DAG financial_statement_initial_load.

Observação: os nomes de DAG aqui se referem aos nomes de DAG após a implantação, conforme exibido na interface do Airflow.
Se implantado como tabelas (recomendado), atualize o seguinte em ordem executando os DAGs correspondentes:
1. Financial_Statements
2. BalanceSheets
3. ProfitAndLoss

Para atualização periódica

Verifique se as Visualizações de nivelamento de hierarquia estão configuradas e atualizadas corretamente para os tipos de hierarquias que você está usando (FSV, centro de custo e centro de lucro).
Programe ou execute o DAG financial_statement_periodical_load.

Observação: programe esse DAG com base nas necessidades de negócios para garantir que as tabelas downstream também sejam atualizadas corretamente.
Se implantado como tabelas (recomendado), atualize o seguinte em ordem executando os DAGs correspondentes:
1. Financial_Statements
2. BalanceSheets
3. ProfitAndLoss

Para conferir os dados dessas tabelas, consulte as seguintes visualizações de visão geral:

ProfitAndLossOverview.sql se você estiver usando a hierarquia de FSV.
ProfitAndLossOverview_CostCenter.sql se você estiver usando a hierarquia de centros de custo.
ProfitAndLossOverview_ProfitCenter.sql se você estiver usando a hierarquia de centro de lucros.

A seguir

Para mais informações sobre outras fontes de dados e cargas de trabalho, consulte Fontes de dados e cargas de trabalho.
Para mais informações sobre as etapas de implantação em ambientes de produção, consulte Pré-requisitos de implantação da base de dados do Cortex Framework.