Skip to main content

Detailed Order Recognition (DOR) concept and methodology

Descarregue o relatório
Download DOR logic and flow diagram

Antecedentes do projeto

O cliente é uma empresa multinacional de tecnologias de informação que fornece produtos e serviços orientados para o centro de dados, tais como servidores, armazenamento empresarial, redes e software empresarial. O objetivo do projeto era reconhecer com precisão as encomendas SOW (Statement of work) personalizadas, os contratos de serviço e as ordens de serviço para previsão e ligação ao crédito de vendas. O modelo é o exemplo clássico de um relatório quase em tempo real para as encomendas ou contratos de serviços reconhecidos. Deste modo, ajuda os utilizadores empresariais das Finanças e dos Serviços a tomarem a sua decisão sobre a realização da respectiva faturação numa base diária.

businessman hand working with new modern computer and business strategy as concept; Shutterstock ID 276609200

Related links

Strategy, Analytiscs and M&A

Alcance os seus objetivos empresariais e um crescimento contínuo com um roadmap estratégico e insights mais inteligentes. As soluções que implementa hoje abrem caminho para o sucesso de amanhã.
Saiba mais

Customer & Marketing

No panorama atual, o marketing pode ser essencial para o sucesso da sua empresa. Com o nosso método human-first, criamos soluções digitais e estratégias fundamentadas em dados para o ajudar a crescer. 
Saiba mais

Human Capital

Reimaginar o trabalho como algo mais do que um processo. Explore o poder do digital para impulsionar produtividade e valor, libertando o potencial humano e criando uma organização resistente ao risco, assente em valores para os seus colaboradores e orientada para o futuro.
Saiba mais

Enterprise, Technology & Performance

Alcance um resultado excecional dos seus investimentos em tecnologia empresarial, através de uma abordagem holística e estratégica à transformação tecnológica.
Saiba mais

O processo de captura e apresentação de encomendas e a forma como o modelo DOR reconhece e resolve várias encomendas/contratos de serviços recebidos do sistema S4 HANA para tipos de encomendas específicos na plataforma EAP(HIVE) para reconhecer a receita num momento específico. A quantia de rédito resultante de uma transação é geralmente determinada por acordo entre as partes envolvidas na transação. Quando existem incertezas quanto à determinação do montante, ou dos custos associados, estas incertezas podem influenciar o momento do rédito. O processo vai ao encontro de critérios pré-definidos e definidos, contribuindo em última análise para o reconhecimento atempado do rédito.

  1. OsCDS - Core Data Services são modelos de dados virtuais do SAP HANA que permitem o acesso direto às tabelas subjacentes da base de dados HANA. As visualizações do SAP CDS têm como objetivo enviar a lógica do servidor de aplicações para o lado do cliente e para a base de dados.
  2. Configuração NACE - Para associar o tipo de aplicação, o tipo de saída e a rotina de processamento (programa condutor) para gerar a saída.
  3. Tópico Kafka - Plataforma de processamento e gestão de fluxos de código aberto que recebe, armazena, organiza e distribui dados entre diferentes utilizadores finais ou aplicações.
  4. HIVE - O HIVE é um sistema de armazenamento de dados que é utilizado para analisar dados estruturados. É construído em cima do Hadoop.
  5. EORD -A primeira data de reconhecimento da encomenda especifica a data em que a encomenda deve ser reconhecida. A EORD é derivada logicamente com base na determinação da janela (de acordo com a data de início e fim do cabeçalho) e na duração da rubrica para a Ordem/Contrato de Serviço.
  6. OCM-Order criteria met representa a bandeira que significa se todos os critérios foram cumpridos para reconhecer a Ordem/Contrato de Serviço.
  7. ORF-Order reportable flag é um indicador que indica se a ordem/contrato de serviço pode ser reportado ou ligado para crédito de vendas quando reconhecido.
  8. Estado do utilizador -

a) CACT(Active)- Estado ao nível do cabeçalho que define que a Ordem/Contrato de Serviço está ativa e pode ser considerada para processamento da DOR,

b) INAC (Inativo)- Estatuto ao nível do cabeçalho que define que a ordem/contrato de serviços está inativo e não deve ser considerado para processamento da DOR,

c) Bloco GT -estatuto ao nível do cabeçalho para representar o bloco de piso global que restringirá a ordem/contrato de serviços a considerar para o processamento da DOR.

d) Bloqueio de crédito -Estado ao nível do cabeçalho para representar o bloqueio de crédito num país específico ou com um montante de crédito que ultrapasse o limite predefinido,

e) Relevância para a DOR -O estatuto a nível do item para definir a rubrica é relevante para a DOR,

f) NDOR-O estatuto ao nível do item para definir a rubrica não é relevante para a DOR

9.Conclusão/Incompletude - Define a completude ou incompletude da encomenda/dos contratos de serviços e uma das condições para que a CCO seja "Y".

10. Sinalizador pré-pago -Indica que os pagamentos são efectuados antecipadamente para a encomenda/contrato de serviços e, consequentemente, considerados para o processo de reconhecimento.

11. Ordem de Alteração -Representa a alteração do Contrato de Encomenda/Serviço que proporciona flexibilidade à Empresa para efetuar alterações nas condições de pagamento

  1. Sistema SnapLogic (sistema intermédio) para suportar a ingestão de ficheiros em fluxo contínuo do S4 para o HIVE(EAP), a fim de fornecer relatórios quase em tempo real.
  2. Arquitetura de ingestão do HIVE para aplanar o ficheiro recebido do S4 numa visualização bidimensional (tabular) no HIVE (EAP).
  3. Mecanismo de transposição do HIVE para separar os campos obrigatórios do atributo único da fonte para efetuar a lógica necessária.
  4. Tabelas de origem e destino do HIVE para comparar o registo mais recente com o registo anterior e executar as etapas necessárias da lógica DOR.
  5. Ferramenta de criação de relatórios como Qlik sense, Power BI, etc. .
  6. Requisito mínimo do sistema:

S4/HANA: SAP 7.3 SP 10

SnapLogic: Snaplex -13393 - 4.30 Patch 1 (obsoleto)

HIVE: NOME - CentOS Linux; Versão - 7 (Core); versão spark - 2.3.0.2.6.5.0-292; Beeline

versão - 1.2.1000.2.6.5.0-292 e Hadoop (Hortonworks) - 2.7.3.2.6.5.0-292

QlikSense - Patch 4 do QS de setembro de 2020

7. Fluxos de trabalho/trabalhos criados para assegurar a atualização atempada dos registos nas camadas respectivas, com atribuição adequada de filas/memória.

Clique aqui para ver o diagrama da arquitetura DOR

Processo em S4

  1. Atualizar o parâmetro de saída no t-code VV11 para os códigos de país das encomendas/contratos de serviços com o respetivo tipo de documento.
  2. 2. A configuração do NACE para a aplicação V1 é necessária para chamar o programa sempre que a respectiva saída é accionada através dos códigos t VA01 & VA02 (para encomendas) e VA41 & VA42 (para contratos de serviços) e gerar o ficheiro JSON que é extraído do sistema intermédio (SnapLogic).

Processo no sistema intermédio (SnapLogic)

3. Extraia os ficheiros JSON do S4, mantendo a conetividade persistente.

4. Mantenha os registos no tópico Kafka com um período mínimo de retenção de 7 dias.

Processo no HIVE(EAP)

5. Ingira ficheiros JSON do tópico Kafka e efectue o nivelamento dos registos, actualizando-os em tabelas bidimensionais para processamento posterior.

6. Transposição ou bifurcação dos campos conforme necessário para a lógica DOR.

7. Efetuar a lógica da DOR e verificar o reconhecimento da ordem/contrato de serviços.

Processo em QlikSense

8. Manter os relatórios de acordo com os requisitos da empresa, que devem ser actualizados, pelo menos, de 2 em 2 horas.

Objectos criados nos sistemas S4, SnapLogic e HIVE(EAP):

Tipo de objeto do sistema

S4 : Programa ABAP standard chamado através da configuração NACE

SnapLogic : tópico do Kafka

HIVE(EAP) : Tabelas de ingestão (Histórico, Erro, Raw, Tabelas refinadas)

HIVE(EAP) : Tabelas temporárias (staging) para transposição de campos e para otimização do desempenho

HIVE(EAP) : Tabela DOR Dimension (Reporting)

QlikSense : Ficheiro de registo DOR, DOR em falta, relatórios ao nível do cabeçalho e ao nível do item

Opções disponíveis

Podem ser criadas vistas CDS personalizadas para fornecer o relatório, juntando logicamente as tabelas necessárias com derivações DOR complexas em S4.

Prós:

  • Poupe tempo realizando as junções e derivações na base de dados S4.
  • Relatórios quase em tempo real.

Contras:

  • A lógica complexa torna o desempenho mais lento durante a geração do relatório.
  • Será extraída uma grande quantidade de dados devido aos 300 campos do CDS (~50 milhões de registos).
  • É difícil obter a vista consolidada com 300 campos.
  • Serão necessárias várias visualizações CDS para diferentes relatórios.
  • Não dispõe de funcionalidades de depuração.

As vistas CDS personalizadas podem ser criadas juntando logicamente as tabelas necessárias no S4. Estas vistas CDS são depois expostas ao HIVE(EAP) através do método de integração de dados (DI). As vistas ingeridas são combinadas de modo a terem todos os campos necessários disponíveis para a execução da lógica DOR.

Prós:

  • A capacidade do HIVE pode ser utilizada para análise.
  • O HIVE suporta o processamento de grandes volumes de dados com capacidade para lidar com cerca de 1200 atributos e fornece um processamento optimizado dos registos através de várias funcionalidades do HIVE.
  • O Spark SQL é utilizado para a execução otimizada da lógica complexa.
  • Automatização de dados através do agendamento de fluxos de trabalho/trabalhos de acordo com os requisitos da empresa.
  • A estrutura em camadas permite uma fácil depuração de problemas com uma caraterística adicional de tratamento de erros.
  • As atividades de limpeza podem ser realizadas de acordo com as necessidades da empresa, através do condicionamento e filtragem dos registos.
  • Suporta a execução de lógicas complexas sem ter qualquer impacto no desempenho.

Contras:

  • A sincronização e a combinação de várias entradas aumentarão o tempo de processamento.
  • A falta de registos em caso de erros técnicos inesperados durante a geração ou o atraso na geração de um ou outros ficheiros a partir de múltiplas visualizações CDS do S4 acabará por resultar em relatórios incompletos.
  • Os dados estão disponíveis quase em tempo real.

A configuração NACE para a aplicação V1 é chamada através do programa ABAP sempre que a saída é accionada através do código t VA01 & VA02 (para encomendas) e VA41 & VA42 (para contratos de serviços) e gera o ficheiro JSON consolidado que é extraído do sistema intermédio (SnapLogic). O ficheiro JSON é então extraído do respetivo tópico Kafka do SnapLogic no HIVE(EAP) para executar a lógica DOR.

De entre as opções disponíveis, a opção 3 foi escolhida para implementação pelas razões que se seguem:

Prós:

  • A capacidade do HIVE pode ser utilizada para análise.
  • O HIVE suporta o processamento de grandes volumes de dados com capacidade para lidar com cerca de 1200 atributos e fornece um processamento optimizado dos registos através de várias funcionalidades do HIVE.
  • O Spark SQL é utilizado para a execução otimizada da lógica complexa.
  • O mecanismo de paralelismo é utilizado durante a execução do trabalho Spark, o que garante que cada tarefa de partição recebe um único núcleo para processamento.
  • É utilizado o ficheiro Optimized Row Columnar (ORC), que melhora o desempenho durante a leitura, a escrita e o processamento dos dados.
  • São criadas tabelas temporárias intermédias (tabelas de preparação) para armazenar temporariamente os dados enquanto se executa sequencialmente a lógica DOR complexa, o que distribui a carga na memória, evitando trabalhos de execução prolongada ou falhas de trabalho após execução prolongada.
  • Automatização de dados através do agendamento de fluxos de trabalho/trabalhos de acordo com os requisitos da empresa.
  • A estrutura em camadas permite uma fácil depuração de problemas com uma caraterística adicional de tratamento de erros.
  • As atividades de limpeza podem ser realizadas de acordo com as necessidades da empresa, através do condicionamento e filtragem dos registos.
  • Suporta a execução de lógicas complexas sem ter qualquer impacto no desempenho.

Contras:

  • Os dados estão disponíveis quase em tempo real.

Visão geral da solução

O programa de driver ABAP é escrito no sistema S4, que chama a configuração NACE para o tipo de aplicação "V1" (para vendas) quando a saída é acionada com um modo de acionamento imediato a partir de VA01 & VA02 (para encomendas) e VA41 & VA42 (para contratos de serviços), que gera o ficheiro JSON consolidado por encomenda ou contratos de serviços.

O sistema intermediário (SnapLogic) extrai o ficheiro JSON e armazena os dados no tópico Kafka com um período de arquivamento de 7 dias. Com a configuração específica mantida no EAP, os dados são extraídos/ingressados no sistema HIVE(EAP) com as tarefas de fluxo contínuo. A tarefa de fluxo contínuo certifica-se de que extrai os dados para o HIVE(EAP) assim que os dados estiverem disponíveis.

O ficheiro JSON ingerido é então aplanado numa tabela bidimensional com uma arquitetura específica composta por tabelas Error, Raw e Refined. Uma vez que as tabelas S4, como a VBPA para a função de parte e a JEST para o estatuto de utilizador, contêm as informações relevantes para várias funções e estatutos de parceiros, respetivamente, num único atributo, é necessária uma bifurcação lógica através do mecanismo de transposição para obter os campos individuais disponíveis para efetuar as derivações necessárias.

Os campos transpostos são então disponibilizados à camada de consumo da DOR através da criação da tabela refinada específica da DOR. Ao escrever o código, esta tabela refinada é também designada por tabela de origem para facilitar a comparação com os registos já existentes na tabela de destino. A tabela de destino é a tabela de dimensão específica da DOR para a elaboração de relatórios, que está estruturada de forma a manter todas as transações. A lógica principal da DOR, incluindo a conversão de moeda, é escrita entre a tabela de origem (refinada pela DOR) e a tabela de destino (tabela de relatório final), tendo sido criadas tabelas temporárias intermédias (staging) para distribuir a carga na memória/fila de espera enquanto se processa a lógica sequencialmente antes de a tornar disponível na tabela de destino. A tabela temporária armazena os dados numa base contínua enquanto obtém os registos incrementais/delta e elimina-os com a execução do ciclo seguinte.

O QlikSense capability é utilizado para reportar os dados, obtendo os registos da tabela de dimensão DOR a partir do HIVE(EAP). Várias folhas para manter todas as transacções DOR, dados de cabeçalho e de item de linha, registos em falta ou de erro são criados de acordo com as necessidades do negócio.

  1. O programa ABAP do condutor combina os dados logicamente quando a configuração NACE para o tipo de aplicação "V1" é chamada para um único JSON por encomenda/contrato de serviços quando acionado em modo imediato. Abaixo encontra-se a condição de junção com pormenores entre as várias tabelas. Clique aqui para ver a condição de junção da tabela S4 e os pormenores do mapeamento
  2. Em seguida, o EAP ingere o ficheiro JSON do SnapLogic para o transformar numa camada bidimensional refinada.
  3. Os dados da tabela VBPA e JEST são transpostos/bifurcados para os respetivos estados do utilizador e funções Partner e carregados na DOR refinada (tabela de origem para os cálculos da DOR) com o resto dos ~180 campos relevantes.
  4. A DOR Dimension (tabela de destino para os cálculos da DOR) é então actualizada a partir da DOR Refined após a execução da lógica da DOR de forma sequencial, carregando tabelas temporárias/de preparação intermédias (ajuda a reduzir o consumo de memória executando o código de cada vez numa base contínua), de acordo com o fluxo abaixo anexado, que fica então disponível para relatório. Clique aqui para ver o diagrama de fluxo lógico DOR e os pormenores
  5. A determinação da janela é um fator importante durante a execução da lógica DOR, que é determinada com base na data de início e de fim do cabeçalho da ordem/dos contratos de serviços. A janela tem uma duração máxima de 12 meses, sendo a janela atual considerada para a execução da lógica DOR e as janelas futuras aguardarão até que a EORD se torne igual ou inferior à data atual.
  6. Determinação de compensação do início dos meses subsequentes quando o último dia do mês inicial é superior ao dia 28 - que os últimos três dias activos é explicado no excel anexo abaixo. Clique aqui para ver os pormenores da explicação da determinação de compensação
  7. Os vários cenários de cálculo de rateio quando as datas de início e fim do cabeçalho não coincidem com as datas de início e fim da rubrica são explicados no Excel em anexo. Clique aqui para ver os pormenores da explicação do cálculo de proporcionalidade

  1. Relatórios DOR em cerca de 4 horas após a execução da lógica complexa necessária para o reconhecimento de ordens/contratos de serviços.
  2. O recurso do QlikSense de criação de tabela QVD e análise de conjunto (para derivar as colunas) aumentará de forma competitiva a velocidade de processamento em 90% para os relatórios.
  3. Múltiplos relatórios como o registo de DOR, DOR em falta, Resumo, Cabeçalho, relatórios de itens de linha, etc. podem ser criados de acordo com os requisitos de negócio sobre a única tabela de dimensão DOR em QlikSense ou qualquer aplicação de relatórios equivalente.
  4. Visualização de todas as transacções com a manutenção da granularidade até às entradas debook/rebooking/original por janela de Ordem/Contrato de Serviço.
  5. A tarefa de reprocessamento programada diariamente assegurará o reconhecimento atempado da encomenda/contrato de serviços que satisfaça as condições predefinidas e a EORD, sem estar à espera de uma nova transação para processar a lógica DOR.
  6. A automatização dos dados pode ser controlada de acordo com os requisitos da empresa através de fluxos de trabalho/jobs programados.
  7. Apoie a Compensação de Vendas no cálculo do crédito e compreenda as receitas futuras, disponibilizando prontamente os registos reconhecidos derivados.
  8. Flexível para apoiar qualquer melhoria de acordo com os requisitos comerciais futuros.

Veja abaixo as estatísticas que explicam os pormenores sobre o tempo de processamento melhorado e a poupança de esforços manuais por execução de relatório.

Sistema HIVE QlikSense

Número de registos 2 M 2 M

Consumo de memória 50 GB 20 GB

Tempo necessário para a execução automatizada 81 min 30 min

Tempo necessário para o funcionamento manual 300 min 280 min

% Redução do tempo de processamento 73 % 90 %

Trabalho manual poupado por execução 219 min 250 min

  1. Ao implementar esta solução, conseguimos reportar com sucesso o reconhecimento de Contratos de Encomenda/Serviço dentro do período de tempo necessário de cerca de 4 horas.
  2. Não é necessário sincronizar e combinar os vários ficheiros ingeridos, o que acabará por poupar cerca de 1 hora de tempo de processamento.
  3. O Spark SQL é utilizado para a execução otimizada da lógica complexa.
  4. O mecanismo de paralelismo é utilizado durante a execução do trabalho Spark, o que garante que cada tarefa de partição recebe um único núcleo para processamento.
  5. É utilizado o ficheiro Optimized Row Columnar (ORC), que melhora o desempenho durante a leitura, a escrita e o processamento dos dados.
  6. São criadas tabelas temporárias intermédias (tabelas de preparação) para armazenar temporariamente os dados enquanto se executa sequencialmente a lógica DOR complexa, o que distribui a carga na memória, evitando trabalhos de execução prolongada ou falhas de trabalho após execução prolongada.
  7. Melhorou a experiência do utilizador, fornecendo todos os aspetos dos relatórios DOR necessários para o processo comercial e apoiando adicionalmente os sistemas a jusante para efetuar o cálculo do crédito de vendas e prever as receitas.

Autor:

Patrocinadores:

Recomendações

Veja o seu mundo em formato digital

O digital não pára e a sua empresa também não. Para prosperar no atual mundo digital em constante mudança, a transformação digital é imperativa.

A organização baseada em competências

Um novo modelo operacional para o trabalho e a força de trabalho

Agricultura regenerativa e inteligente em termos climáticos

Consulte um relatório sobre a forma como investimentos específicos na agricultura sustentável podem proporcionar benefícios económicos positivos para os agricultores.

2021 Human Capital Trends

Leia este relatório para saber mais sobre novas formas de prosperar a longo prazo, mesmo quando a disrupção redefine constantemente o caminho a seguir.

Contactos