À escala empresarial armazéns de amostra.

Perfil da empresa

Aviso de empresa fictícia: «Hilson» é uma empresa inteiramente fictícia, criada apenas para fins de demonstração. Não está afiliada, endossada, nem se destina a representar a Hilton Inc., a Hyatt Hotels Corporation ou qualquer empresa real de hotelaria.

Hilson Hospitality Group é um operador hoteleiro global com ~680 unidades em 18 marcas — desde bandeiras de luxo (nível Waldorf, nível Conrad), passando por full-service (Hilson, nível DoubleTree), até select-service e extended-stay. Cada unidade corre um Opera PMS on-premise e um CRS Amadeus central, servindo um mix de hóspedes de lazer transitório, corporativo negociado e grupos/convenções.

O negócio abrange loyalty (Hilson Honors com milhões de membros), vendas de grupos e convenções (pipeline Salesforce, blocos de quartos CPQ), pontos de food & beverage (POS MICROS Simphony), reporte a proprietário/franchise (extratos Oracle Fusion) e funções corporativas — gerando cerca de 1.900 reservas PMS e 1.750 cabeçalhos de folio num dia útil típico, com um pico de viagens de verão (junho–agosto) que eleva a ocupação, o ADR, o gasto de F&B e a atividade de loyalty em todas as unidades.

Entidades de amostra: A tabela abaixo mostra entidades de negócio representativas e os seus sistemas de origem; o EDW completo inclui entidades adicionais, subtipos e tabelas especializadas (p.ex. eventos de canal OTA, restrições de rate-plan, acordos legais de franchise, redlines de deal-desk) em todas as 62 tabelas bronze. Na V2, StayReservation e as classes de domínio relacionadas emitem linhas PMS, CRS, folio e loyalty através de adapters dos sistemas de origem à medida que o ciclo de vida da estadia avança.

Modelo de domínio OOP

HilsonEnterpriseSimulation sequencia o dia; os objetos de domínio são donos da lógica de emissão.

ReservationToLoyaltyAndOwnerReporting é a espinha dorsal primária do processo. StayReservation.execute_lifecycle() percorre reserva → sync PMS → encargos de folio → pagamento → pontos de loyalty → snapshot de ocupação → extrato do proprietário → GL. HilsonPortfolio.publish_foundation() masteriza marcas, unidades e membros Honors antes de as reservas correrem.

flowchart LR
  PORT[HilsonPortfolio.publish_foundation]
  STAY[StayReservation.execute_lifecycle]
  PORT --> STAY
  STAY --> BOOK[CRS booking]
  BOOK --> PMS[PMS sync]
  PMS --> FOL[folio charges]
  FOL --> PAY[Adyen settlement]
  PAY --> LOY[Honors points]
  LOY --> OWN[owner statement + GL]
          

Cadeia de valor de hóspede e unidade

Do mestre de marca e de unidade, passando por distribuição, estadia, liquidação e reporte ao proprietário.

Vista de amostra: Isto ilustra a cadeia de valor primária através do ecossistema Hilson; o EDW gerado completo inclui os 31 sistemas de origem, com integrações transversais, fluxos de receita secundários e fluxos de ciclo de vida de loyalty não mostrados aqui.

%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
  subgraph master["Brand & property master"]
    direction TB
    BR[hilson_brand]
    PROP[oracle_opera property]
    RMS[ideas_rms rate plans]
    BR ~~~ PROP
    PROP ~~~ RMS
  end
  subgraph dist["Distribution & booking"]
    direction TB
    AMA[amadeus_hosp CRS]
    SM[siteminder OTA]
    AMA ~~~ SM
  end
  subgraph stay["Stay & revenue"]
    direction TB
    RES[oracle_opera reservation]
    FOL[folio header / charges]
    SIM[micros_simphony F&B]
    PAY[adyen payments]
  end
  subgraph loy["Loyalty & VoC"]
    direction TB
    HON[hilson_loyalty member]
    MED[medallia · qualtrics]
    HON ~~~ MED
  end
  subgraph corp["Owner & corporate"]
    direction TB
    OWN[oracle_fusion owner stmt]
    SAP[sap_s4 GL]
    GRP[salesforce group sales]
    OWN ~~~ SAP
    SAP ~~~ GRP
  end
  master --> dist --> stay --> loy
  stay --> corp
          

Organização funcional por departamento

Sede empresarial e funções de reporte direto, com sistemas de origem representativos.

Estrutura organizacional de amostra: Isto mostra as linhas de reporte primárias; a organização Hilson completa inclui gestão regional adicional, equipas específicas de marca e funções de shared-services em todas as 31 integrações de fornecedor.

flowchart TB
  CEO[Hilson Hospitality Group]
  CEO --> BRAND[Brand & marketing]
  CEO --> DIST[Distribution & revenue mgmt]
  CEO --> PROP[Property operations]
  CEO --> SALES[Group sales]
  CEO --> LOY[Loyalty program]
  CEO --> FIN[Finance & owner reporting]
  CEO --> HR[Human resources]
  CEO --> GX[Guest experience]
  CEO --> LEG[IT / security / legal]
          

Estádios de maturidade do EDW

Catálogo stage agrupa tabelas desde a fundação até ao corporativo.

Desagregação de amostra apresentada: Isto é um recorte representativo do inventário completo de 62 tabelas, distribuído pelas camadas de maturidade; a distribuição real reflete a linhagem completa de dados desde a fundação até às tabelas gold corporativas.

flowchart LR
  F["foundation
~15 tables"]
  C["commercial
~7 tables"]
  GR["guest_revenue
~17 tables"]
  PO["property_ops
~7 tables"]
  CO["corporate
~16 tables"]
  F --> C --> GR --> PO
  F -.-> CO
  GR -.-> CO
          

Entidades nucleares do negócio

Relações lógicas e chaves âncora. Unidade (hotel_code) é a espinha dorsal; identidade do hóspede via Honors e tabelas de estadia.

Diagrama de amostra: Este diagrama de relação de entidades mostra o modelo lógico nuclear; o EDW gerado completo contém 62 tabelas bronze em 31 sistemas de fornecedor com milhares de tabelas de detalhe adicionais e ramos de linhagem.

erDiagram
  PROPERTY ||--o{ RESERVATION : hosts
  PROPERTY ||--o{ RATE_PLAN : offers
  BRAND ||--o{ PROPERTY : flags
  MEMBER ||--o{ RESERVATION : books
  MEMBER ||--o{ POINT_TXN : earns
  MEMBER ||--o{ REDEMPTION : redeems
  RESERVATION ||--|| FOLIO : bills
  FOLIO ||--o{ FOLIO_CHARGE : lines
  RESERVATION ||--o{ FNB_CHECK : posts
  CORP_ACCOUNT ||--o{ OPPORTUNITY : pursues
  SUPPLIER ||--o{ PO : supplies
  PROPERTY ||--o{ WORK_ORDER : maintains
          

Paisagem de sistemas de origem

31 prefixos de fornecedor, 62 tabelas bronze.

Sistemas de amostra apresentados: O diagrama abaixo ilustra sistemas de fornecedor representativos; o conjunto de dados gerado completo inclui os 31 sistemas, com a linhagem completa de tabelas e os pontos de integração ao longo do preenchimento histórico e dos streams live.

Cada tabela segue a {source_system_}__{entity} convenção de nomenclatura (p.ex. oracle_opera__reservation, hilson_loyalty__member), preservando a forma nativa das colunas do fornecedor e as chaves estrangeiras do esquema de exportação real de cada produto. O VibeBI infere a conformidade dos dados mestres quando promove os registos para silver e gold.

flowchart TB
  subgraph foundation["Foundation"]
    direction TB
    f1["hilson_brand · oracle_opera property · room_type"]
    f2["amadeus_hosp · ideas_rms · hilson_loyalty member"]
    f3["salesforce account · workday · sap_s4 · coupa supplier"]
  end
  subgraph commercial["Commercial"]
    direction TB
    c1["salesforce pipeline · CPQ · hubspot · marketo"]
  end
  subgraph guest_rev["Guest revenue"]
    direction TB
    g1["oracle_opera reservation · folio · events"]
    g2["amadeus_hosp · siteminder · micros_simphony"]
    g3["adyen · loyalty points · oracle_fusion owner"]
  end
  subgraph prop_ops["Property ops"]
    direction TB
    p1["housekeeping · occupancy · ibm_maximo · coupa PO"]
  end
  subgraph corporate["Corporate"]
    direction TB
    co1["sap_s4 journals · adp · ukg · anaplan"]
    co2["medallia · qualtrics · zendesk · concur"]
    co3["servicenow · okta · splunk · ironclad · onetrust"]
  end
  foundation --> commercial --> guest_rev --> prop_ops
  foundation --> corporate
  guest_rev --> corporate
          

Fluxo de dados de ponta a ponta

Sim OOP V2 → bronze em ClickHouse; semântica VibeBI → silver → gold na mesma instância.

Percurso OOP: kb/industries/hilson/ define a espinha dorsal das operações e o modelo de entidades; HilsonEnterpriseSimulation sequencia os ciclos de vida de domínio; SourceSystem os adapters exportam linhas nativas do fornecedor para hilson_v2.

flowchart LR
  subgraph kb["kb/industries/hilson"]
    SPINE[entity + process models]
  end
  subgraph sim["sim/industries/hilson"]
    ORCH[HilsonEnterpriseSimulation]
    DOM["StayReservation.execute_lifecycle()
Property · GuestMember …"]
  end
  subgraph simedw["SimEDW V2"]
    ADP[SourceSystem adapters]
    CHB[("ClickHouse hilson_v2
62 bronze tables")]
  end
  subgraph vibebi["VibeBI"]
    SEM[("semantic")]
    SIL[("silver views")]
    GLD[("gold views")]
  end
  DASH["Dashboards & agents"]
  SPINE --> DOM
  ORCH --> DOM --> ADP --> CHB
  CHB --> SEM --> SIL --> GLD --> DASH
          

Ciclo bronze em tempo real

./live-v2-hilson — ciclo de 60s via HilsonEnterpriseSimulation.generate().

Frequência em tempo real: Cada ciclo corre a máquina de estados de reserva-para-loyalty — os objetos de domínio emitem linhas correlacionadas de CRS, PMS, folio, F&B, pagamento, loyalty e GL; a escala varia por ciclo (base predefinida 5). Preencha qualquer intervalo de histórico de que precise (--days N); o Hilson inclui deteção de lacunas na tabela âncora de reservas.

flowchart LR
  START([60s tick]) --> SIM[HilsonEnterpriseSimulation.generate]
  SIM --> FOUND[Portfolio.publish_foundation]
  FOUND --> STAY[StayReservation lifecycles]
  STAY --> EVT[SourceSystem events]
  EVT --> BRZ[Append bronze rows]
  BRZ --> WAIT[Sleep] --> START
          

Grafo de eventos da estadia do hóspede

Máquina de estados ReservationToLoyaltyAndOwnerReporting — cada transição emite linhas de fornecedor.

Espinha dorsal do processo: Definido em kb/industries/hilson/process_model.yaml. Os modos de exceção (no-shows, chargebacks, upgrades de quarto) ramificam-se a partir do mesmo ciclo de vida da entidade, em vez de inserções aleatórias independentes.

flowchart LR
  BOOK[booked] --> SYNC[synced_to_pms]
  SYNC --> CHKIN[checked_in]
  CHKIN --> HOUSE[in_house]
  HOUSE --> CHKOUT[checked_out]
  CHKOUT --> SET[settled]
  SET --> PTS[points_posted]
  PTS --> OCC[occupancy_snapshotted]
  OCC --> OWN[owner_reported]
  OWN --> GL[posted_to_gl]
  SYNC -.->|no_show| NS[no_show]
  SET -.->|chargeback| CB[chargeback]
          

Categorias de tabelas bronze

O mesmo envelope de linhagem em cada tabela; a categoria controla atualização live vs. append em micro-lote.

Categorias de amostra: Todas as 62 tabelas bronze seguem este padrão de três categorias (snapshot, transação, evento), com metadados consistentes e acompanhamento de estado; o diagrama ilustra o padrão usado em todo o armazém.

flowchart LR
  subgraph snap["snapshot"]
    direction TB
    S1["Property · brand · member masters"]
    S2[Daily full refresh]
  end
  subgraph txn["transaction"]
    direction TB
    T1["Reservations · folios · payments"]
    T2[Append each live tick]
  end
  subgraph evt["event"]
    direction TB
    E1["HK · OTA · surveys · access"]
    E2[Append each live tick]
  end
  BRONZE[("hilson_v2 bronze row")]
  snap --> BRONZE
  txn --> BRONZE
  evt --> BRONZE
          

Perfil da empresa

Aviso de empresa fictícia: «P&C» é uma empresa inteiramente fictícia, criada apenas para fins de demonstração. Não está afiliada, endossada, nem se destina a representar The Procter & Gamble Company ou qualquer fabricante real de CPG.

P&C é um fabricante-marketer global de bens de consumo embalados — um modelo B2B2C que vende produtos de uso diário através de canais de grande retalho, club, mercearia e e-commerce em ~180 países. Cinco Sector Business Units (SBUs) abrangem Fabric & Home Care, Baby/Feminine/Family Care, Beauty, Health Care e Grooming, com ~12 marcas de referência (TidalWave, ComfortWrap, BrightSmile, EdgePro e outras) e oito fábricas mais três centros de distribuição regionais.

O negócio abrange planeamento da procura, procurement de matérias-primas, produção MES, libertação de qualidade, distribuição de produtos acabados, encomendas de clientes retalhistas, trade marketing e finanças — gerando ordens de trabalho MES correlacionadas, POs Ariba, cabeçalhos OMS, expedições OTM e linhas de diário SAP em cada dia de simulação, com um Pico Spring Clean (março–abril) que eleva a procura de cuidados de tecidos/lar, o débito das fábricas e o sell-in retalhista na América do Norte e na EMEA.

Entidades de amostra: A tabela abaixo mostra entidades de negócio representativas e os seus sistemas de origem; o EDW completo inclui entidades adicionais, subtipos e tabelas especializadas (p.ex. leituras de sensores IoT, ordens de manutenção, promoções comerciais, redlines CLM) em todas as 60 tabelas bronze. Na V2, ProductionBatch e CustomerOrder as classes de domínio impulsionam a espinha dorsal MakeToShipToSell.

Modelo de domínio OOP

PcEnterpriseSimulation sequencia o dia; os objetos de domínio são donos da lógica de emissão.

MakeToShipToSell é a espinha dorsal primária do processo. ProductionBatch.execute_lifecycle() percorre previsão → procurement → produção → libertação QC → produtos acabados; CustomerOrder.execute_lifecycle() percorre captura OMS → fulfillment WMS → expedição OTM. PcPortfolio.publish_foundation() masteriza SBUs, marcas, fábricas, SKUs e contas retalhistas antes de os lotes e as encomendas correrem. Objetos de serviço (PlantOperations, CommercialProgram, FinanceAndCorporate) emitem linhas de suporte corporativas e de marketing.

flowchart LR
  PORT[PcPortfolio.publish_foundation]
  BATCH[ProductionBatch.execute_lifecycle]
  ORDER[CustomerOrder.execute_lifecycle]
  PORT --> BATCH
  PORT --> ORDER
  BATCH --> FCST[BlueYonder forecast]
  FCST --> PO[Ariba PO]
  PO --> MES[SIEMENS MES work order]
  MES --> QC[MasterControl release]
  QC --> WMS[WMS finished goods]
  ORDER --> OMS[OMS order]
  OMS --> SHIP[OTM shipment]
  SHIP --> GL[SAP S/4 journal]
          

Cadeia de valor make-to-ship

Do portefólio de marcas, passando por planear, produzir, mover, vender e fecho corporativo.

Vista de amostra: Isto ilustra a cadeia de valor primária no ecossistema P&C; o EDW gerado completo inclui os 34 sistemas de origem, com integrações transversais, telemetria IoT de fábrica e fluxos de trade marketing não mostrados aqui.

%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
  subgraph portfolio["Portfolio & R&D"]
    direction TB
    PCB[pc_brand SBU ladder]
    PIM[akeneo_pim SKU]
    PCB ~~~ PIM
  end
  subgraph plan["Plan & procure"]
    direction TB
    BY[blueyonder forecast]
    ARB[sap_ariba PO]
    BY ~~~ ARB
  end
  subgraph make["Make & quality"]
    direction TB
    MES[siemens_mes work order]
    MC[mastercontrol QC]
    MES ~~~ MC
  end
  subgraph move["Store & ship"]
    direction TB
    WMS[manhattan_wms inventory]
    OTM[oracle_otm TMS]
    WMS ~~~ OTM
  end
  subgraph sell["Sell to retail"]
    direction TB
    SF[salesforce trade]
    OMS[manhattan_oms orders]
    SF ~~~ OMS
  end
  subgraph corp["Corporate"]
    direction TB
    WD[workday]
    S4[sap_s4 GL]
    WD ~~~ S4
  end
  portfolio --> plan --> make --> move --> sell --> corp
          

Organização funcional por departamento

Sede global em Cincinnati e funções de reporte direto, com sistemas de origem representativos.

Estrutura organizacional de amostra: Isto mostra as linhas de reporte primárias; a organização P&C completa inclui equipas regionais de SBU, gestores de fábrica e funções de shared-services em todas as 34 integrações de fornecedor.

flowchart TB
  CEO[P&C Global]
  CEO --> SBU[SBU portfolio & R&D]
  CEO --> MFG[Supply chain & manufacturing]
  CEO --> COMM[Commercial & retail sales]
  CEO --> MKT[Marketing & brand]
  CEO --> FIN[Finance & controller]
  CEO --> HR[Human resources]
  CEO --> QUAL[Quality & regulatory]
  CEO --> LEG[IT / legal / security]
          

Estádios de maturidade do EDW

Catálogo stage agrupa tabelas desde a fundação até ao corporativo.

Desagregação de amostra apresentada: Isto é um recorte representativo do inventário completo de 60 tabelas, distribuído pelas camadas de maturidade; a distribuição real reflete a linhagem completa de dados desde a fundação até às tabelas gold corporativas.

flowchart LR
  F["foundation
~13 tables"]
  SC["supply_chain
~10 tables"]
  D["distribution
~6 tables"]
  C["commercial
~16 tables"]
  CO["corporate
~15 tables"]
  F --> SC --> D --> C
  F -.-> CO
  C -.-> CO
          

Entidades nucleares do negócio

Relações lógicas e chaves âncora. Marca (brand_code) e fábrica (facility_code) são a espinha dorsal; os números de material ligam o PIM ao MES.

Diagrama de amostra: Este diagrama de relação de entidades mostra o modelo lógico nuclear; o EDW gerado completo contém 60 tabelas bronze em 34 sistemas de fornecedor com tabelas de detalhe adicionais e ramos de linhagem. As instâncias de entidade transportam entity_refs em cada evento emitido, para testes de joinability.

erDiagram
  BRAND ||--o{ PRODUCT : owns
  PRODUCT ||--o{ PRODUCTION_BATCH : produces
  PLANT ||--o{ PRODUCTION_BATCH : runs
  SUPPLIER ||--o{ PO : supplies
  PRODUCTION_BATCH ||--o{ PO : triggers
  PLANT ||--o{ INVENTORY : stocks
  RETAIL_CUSTOMER ||--o{ CUSTOMER_ORDER : places
  PRODUCT ||--o{ ORDER_LINE : contains
  CUSTOMER_ORDER ||--|{ ORDER_LINE : lines
  CUSTOMER_ORDER ||--o{ SHIPMENT : ships
  CUSTOMER_ORDER ||--o{ JOURNAL : posts
          

Paisagem de sistemas de origem

34 prefixos de fornecedor, 60 tabelas bronze.

Sistemas de amostra apresentados: O diagrama abaixo ilustra sistemas de fornecedor representativos; o conjunto de dados gerado completo inclui os 34 sistemas, com a linhagem completa de tabelas e os pontos de integração ao longo do preenchimento histórico e dos streams live. Manifests partilhados de sistemas de origem em kb/source_systems/ são reutilizados entre indústrias — o P&C acrescenta pc_brand como um sistema interno específico da indústria.

Cada tabela segue a {source_system_}__{entity} convenção de nomenclatura (p.ex. pc_brand__brand, siemens_mes__work_order), preservando a forma nativa das colunas do fornecedor e as chaves estrangeiras do esquema de exportação real de cada produto. O VibeBI infere a conformidade dos dados mestres quando promove os registos para silver e gold.

flowchart TB
  subgraph foundation["Foundation"]
    direction TB
    f1["pc_brand · akeneo_pim
oracle_scm · workday"]
    f2["sap_s4 dimensions"]
  end
  subgraph supply_chain["Supply chain"]
    direction TB
    s1["blueyonder · sap_ariba
siemens_mes · mastercontrol"]
    s2["ibm_maximo · aws_iot"]
  end
  subgraph distribution["Distribution"]
    direction TB
    d1["manhattan_wms
oracle_otm"]
  end
  subgraph commercial["Commercial"]
    direction TB
    c1["salesforce · manhattan_oms
hubspot · marketo"]
    c2["google_analytics · qualtrics · zendesk"]
  end
  subgraph corporate["Corporate"]
    direction TB
    co1["sap_s4 journals · coupa
adp · ukg · concur"]
    co2["servicenow · okta · splunk
ironclad · onetrust · greenhouse"]
  end
  foundation --> supply_chain --> distribution --> commercial
  foundation --> corporate
  commercial --> corporate
          

Fluxo de dados de ponta a ponta

Sim OOP V2 → bronze em ClickHouse; semântica VibeBI → silver → gold na mesma instância.

Percurso OOP: kb/industries/pnc/ define a espinha dorsal das operações e o modelo de entidades; PcEnterpriseSimulation sequencia os ciclos de vida de domínio; SourceSystem os adapters exportam linhas nativas do fornecedor para pnc_v2.

flowchart LR
  subgraph kb["kb/industries/pnc"]
    SPINE[entity + process models]
  end
  subgraph sim["sim/industries/pnc"]
    ORCH[PcEnterpriseSimulation]
    DOM["ProductionBatch · CustomerOrder
execute_lifecycle()"]
  end
  subgraph simedw["SimEDW V2"]
    ADP[SourceSystem adapters]
    CHB[("ClickHouse pnc_v2
60 bronze tables")]
  end
  subgraph vibebi["VibeBI"]
    SEM[("semantic")]
    SIL[("silver views")]
    GLD[("gold views")]
  end
  DASH["Dashboards & agents"]
  SPINE --> DOM
  ORCH --> DOM --> ADP --> CHB
  CHB --> SEM --> SIL --> GLD --> DASH
          

Ciclo bronze em tempo real

./live-v2-pnc — ciclo de 60s via PcEnterpriseSimulation.generate().

Frequência em tempo real: Cada ciclo corre a máquina de estados MakeToShipToSell — os objetos de domínio emitem linhas correlacionadas de previsão, PO, MES, WMS, OMS, OTM e GL por lote de produção e encomenda de cliente retalhista; a escala varia por ciclo (base predefinida 5). Preencha qualquer intervalo de histórico de que precise (--days N no script live ou na CLI).

flowchart LR
  START([60s tick]) --> SIM[PcEnterpriseSimulation.generate]
  SIM --> FOUND[PcPortfolio.publish_foundation]
  FOUND --> BATCH[ProductionBatch lifecycles]
  FOUND --> ORDER[CustomerOrder lifecycles]
  BATCH --> CORP[PlantOps + Finance + Commercial]
  ORDER --> CORP
  CORP --> EVT[SourceSystem events]
  EVT --> BRZ[Append bronze rows]
  BRZ --> WAIT[Sleep] --> START
          

Grafo de eventos make-to-ship

Máquina de estados MakeToShipToSell — cada transição é um método de domínio que emite linhas de fornecedor.

Espinha dorsal do processo: Definido em kb/industries/pnc/process_model.yaml. Os modos de exceção (refugo de lote, retenção de qualidade, expedição parcial, atraso de fornecedor) ramificam-se a partir dos mesmos ciclos de vida das entidades, em vez de inserções aleatórias independentes.

flowchart LR
  FCST[forecasted] --> PROC[materials_procured]
  PROC --> PROD[production_started]
  PROD --> QC[quality_released]
  QC --> FG[finished_goods_received]
  FG --> ORD[customer_ordered]
  ORD --> FUL[fulfilled]
  FUL --> SHIP[shipped]
  SHIP --> GL[posted_to_gl]
  PROD -.->|scrap| SCRAP[batch_scrap]
  QC -.->|hold| HOLD[quality_hold]
  FUL -.->|short| PART[partial_shipment]
          

Categorias de tabelas bronze

O mesmo envelope de linhagem em cada tabela; a categoria determina o comportamento live.

Categorias de amostra: Todas as 60 tabelas bronze seguem este padrão de três categorias (snapshot, transação, evento), com metadados consistentes e acompanhamento de estado; o diagrama ilustra o padrão usado em todo o armazém.

flowchart LR
  subgraph snap["snapshot"]
    direction TB
    S1["Brand · plant · SKU masters"]
    S2[Daily foundation refresh]
  end
  subgraph txn["transaction"]
    direction TB
    T1["POs · work orders · OMS · GL"]
    T2[Append each live tick]
  end
  subgraph evt["event"]
    direction TB
    E1["IoT · WMS movement · OTM tracking"]
    E2[Append each live tick]
  end
          BRONZE[("pnc_v2 bronze row")]
          snap --> BRONZE
          txn --> BRONZE
          evt --> BRONZE
          

Perfil da empresa

Aviso de empresa fictícia: «HKBC» é uma empresa inteiramente fictícia, criada apenas para fins de demonstração. Não está afiliada, endossada nem destinada a representar a HSBC Holdings plc, The Hongkong and Shanghai Banking Corporation Limited ou qualquer banco real.

HKBC (Hong Kong Banking Corporation) é um banco universal de Hong Kong com sede em Central, com Wealth and Personal Banking, Commercial Banking e Global Banking and Markets. A franchise capta depósitos HKD, origina hipotecas HIBOR e crédito não garantido, emite cartões, opera 24×7 os rails Faster Payment System e PearlPay (classe PayMe), financia o comércio da Greater Bay Area e regista FX USD/HKD e CNH dentro da banda de convertibilidade 7,75–7,85.

O book cobre ~10 balcões em Hong Kong Island, Kowloon e New Territories, mais um desk grossista GBA em Qianhai e um desk de mercados em Londres — gerando créditos FPS, autorizações de cartão, transferências CHATS/SWIFT, lançamentos em partida dobrada, alertas AML e diários SAP correlacionados em cada dia de simulação, com um Surge de Ano Novo lunar / tax-loan T1 que eleva o volume P2P PearlPay, as cobranças FPS e a originação de empréstimos pessoais.

Entidades de amostra: A tabela abaixo mostra entidades de negócio representativas e os respetivos sistemas de origem; o EDW completo inclui entidades, subtipos e tabelas especializadas adicionais (p. ex. casos AML, provisões ECL, ordens de valores, redlines de facility) em todas as 60 tabelas bronze. Em V2, FpsPayment e as classes de domínio relacionadas impulsionam a espinha PayToPostToBalance.

Modelo de domínio OOP

HkbcEnterpriseSimulation sequencia o dia; os objetos de domínio são donos da lógica de emissão.

PayToPostToBalance é a espinha dorsal primária do processo. FpsPayment.execute_lifecycle() (e as contrapartes PearlPay, cartão, CHATS, SWIFT) percorre mensagem de rail → lançamento em partida dobrada no core → alerta AML opcional → saldo de depósitos EOD → GL. HkbcPortfolio.publish_foundation() masteriza balcões, produtos, clientes CIF e contas antes de os pagamentos correrem. Os objetos de serviço emitem linhas de trade CMB, FX GBM, wealth, risco e corporate.

flowchart LR
  PORT[HkbcPortfolio.publish_foundation]
  PAY[FpsPayment.execute_lifecycle]
  PORT --> PAY
  PAY --> RAIL[FPS / PearlPay / card / CHATS / SWIFT]
  RAIL --> CORE[post_pair in hkbc_core]
  CORE --> AML[Actimize AML]
  CORE --> EOD[EOD deposit balance]
  EOD --> GL[SAP S/4 journal]
          

Cadeia de valor de pagamentos e franchise

Do mestre CIF e de produto, através de rails, posting do core, risco e fecho financeiro.

Vista de amostra: Isto ilustra a cadeia de valor primária através do ecossistema HKBC; o EDW gerado completo inclui os 32 sistemas de origem, com integrações transversais, wealth dealing e corredores comerciais GBA não mostrados aqui.

%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
  subgraph master["CIF & product master"]
    direction TB
    CORE[hkbc_core CIF / account]
    SF[salesforce]
    CORE ~~~ SF
  end
  subgraph rails["Payments rails"]
    direction TB
    FPS[hkicl_fps]
    PP[hkbc_pay PearlPay]
    CARD[fiserv_visionplus]
    CHATS[hkicl_chats · swift]
  end
  subgraph book["Core & risk"]
    direction TB
    POST[hkbc_core posting]
    AML[nice_actimize]
    ECL[moodys_risk]
    POST ~~~ AML
    AML ~~~ ECL
  end
  subgraph franchise["CMB · GBM · WPB"]
    direction TB
    TRD[hkbc_trade]
    FX[murex]
    WLT[hkbc_wealth]
    TRD ~~~ FX
    FX ~~~ WLT
  end
  subgraph corp["Corporate"]
    direction TB
    WD[workday]
    S4[sap_s4 GL]
    WD ~~~ S4
  end
  master --> rails --> book --> franchise --> corp
          

Organização funcional por departamento

HQ Harbourview Tower e funções de reporte direto com sistemas de origem representativos.

Estrutura organizacional de amostra: Isto mostra as linhas de reporte primárias; a organização HKBC completa inclui balcões de distrito adicionais, desks GBA e funções de shared services em todas as 32 integrações de fornecedor.

flowchart TB
  CEO[HKBC Hong Kong]
  CEO --> WPB[Wealth & Personal Banking]
  CEO --> CMB[Commercial Banking]
  CEO --> GBM[Global Banking & Markets]
  CEO --> RISK[Risk & AML]
  CEO --> FIN[Finance & ALM]
  CEO --> HR[Human resources]
  CEO --> OPS[Operations & branches]
  CEO --> LEG[IT / legal / security]
          

Estádios de maturidade do EDW

Catálogo stage agrupa tabelas desde a fundação até ao corporativo.

Desagregação de amostra apresentada: Isto é um recorte representativo do inventário completo de 60 tabelas, distribuído pelas camadas de maturidade; a distribuição real reflete a linhagem completa de dados desde a fundação até às tabelas gold corporativas.

flowchart LR
  F["foundation
~13 tables"]
  P["payments
~11 tables"]
  M["markets & risk
~12 tables"]
  C["commercial
~6 tables"]
  CO["corporate
~18 tables"]
  F --> P --> M --> C
  F -.-> CO
  P -.-> CO
          

Entidades nucleares do negócio

Relações lógicas e chaves âncora. Cliente (customer_id) e conta (account_id) são a espinha; os pagamentos ligam via source_txn_id.

Diagrama de amostra: Este diagrama de relação de entidades mostra o modelo lógico nuclear; o EDW gerado completo contém 60 tabelas bronze em 32 sistemas de fornecedor com tabelas de detalhe adicionais e ramos de linhagem. As instâncias de entidade transportam entity_refs em cada evento emitido, para testes de joinability.

erDiagram
  CUSTOMER ||--o{ ACCOUNT : holds
  PRODUCT ||--o{ ACCOUNT : defines
  BRANCH ||--o{ ACCOUNT : books
  ACCOUNT ||--o{ PAYMENT : pays
  ACCOUNT ||--o{ POSTING : ledgers
  ACCOUNT ||--o{ DEPOSIT_BALANCE : snapshots
  PAYMENT ||--o{ AML_ALERT : screens
  COMMERCIAL_CLIENT ||--o{ TRADE_CREDIT : finances
  ACCOUNT ||--o{ FX_TRADE : hedges
  ACCOUNT ||--o{ WEALTH_ORDER : deals
          

Paisagem de sistemas de origem

32 prefixos de fornecedor, 60 tabelas bronze.

Sistemas de amostra apresentados: O diagrama abaixo ilustra sistemas de fornecedor representativos; o conjunto de dados gerado completo inclui os 32 sistemas com linhagem de tabelas e pontos de integração no backfill de histórico e nos streams em tempo real. Os manifests de sistemas de origem partilhados em kb/source_systems/ são reutilizados entre indústrias — o HKBC acrescenta hkbc_core, hkbc_pay, hkbc_trade, e hkbc_wealth como sistemas internos específicos da indústria, mais os rails de mercado de Hong Kong.

Cada tabela segue a {source_system_}__{entity} convenção de nomenclatura (p.ex. hkbc_core__account, hkicl_fps__payment), preservando a forma nativa das colunas do fornecedor e as chaves estrangeiras do esquema de exportação real de cada produto. O VibeBI infere a conformidade dos dados mestres quando promove os registos para silver e gold.

flowchart TB
  subgraph foundation["Foundation"]
    direction TB
    f1["hkbc_core branch · product · CIF · account"]
    f2["salesforce · workday · sap_s4 dimensions"]
  end
  subgraph payments["Payments"]
    direction TB
    p1["hkicl_fps · hkbc_pay · fiserv_visionplus"]
    p2["hkicl_chats · swift · core posting"]
  end
  subgraph markets["Markets & risk"]
    direction TB
    m1["murex · bloomberg · hkbc_trade · hkbc_wealth"]
    m2["nice_actimize · moodys_risk"]
  end
  subgraph commercial["Commercial"]
    direction TB
    c1["salesforce pipeline · hubspot · marketo"]
  end
  subgraph corporate["Corporate"]
    direction TB
    co1["sap_s4 journals · anaplan · adp · ukg"]
    co2["genesys · zendesk · servicenow · okta"]
    co3["splunk · ironclad · onetrust · greenhouse"]
  end
  foundation --> payments --> markets --> commercial
  foundation --> corporate
  payments --> corporate
          

Fluxo de dados de ponta a ponta

Sim OOP V2 → bronze em ClickHouse; semântica VibeBI → silver → gold na mesma instância.

Percurso OOP: kb/industries/hkbc/ define a espinha dorsal das operações e o modelo de entidades; HkbcEnterpriseSimulation sequencia os ciclos de vida de domínio; SourceSystem os adapters exportam linhas nativas do fornecedor para hkbc_v2.

flowchart LR
  subgraph kb["kb/industries/hkbc"]
    SPINE[entity + process models]
  end
  subgraph sim["sim/industries/hkbc"]
    ORCH[HkbcEnterpriseSimulation]
    DOM["FpsPayment.execute_lifecycle()
Account · Customer · FxTrade …"]
  end
  subgraph simedw["SimEDW V2"]
    ADP[SourceSystem adapters]
    CHB[("ClickHouse hkbc_v2
60 bronze tables")]
  end
  subgraph vibebi["VibeBI"]
    SEM[("semantic")]
    SIL[("silver views")]
    GLD[("gold views")]
  end
  DASH["Dashboards & agents"]
  SPINE --> DOM
  ORCH --> DOM --> ADP --> CHB
  CHB --> SEM --> SIL --> GLD --> DASH
          

Ciclo bronze em tempo real

./live-v2-hkbc — ciclo de 60s via HkbcEnterpriseSimulation.generate().

Frequência em tempo real: Cada tick executa a state machine PayToPostToBalance — os objetos de domínio emitem linhas FPS, PearlPay, cartão, CHATS, SWIFT, posting do core, AML e GL correlacionadas; os ticks live de hoje emitem apenas eventos até Hong Kong as_of para que a fita de pagamentos cresça ao longo do dia. A escala varia por tick (base 5 por omissão). Faça backfill de qualquer intervalo de histórico de que precise (--days N no script live ou na CLI).

flowchart LR
  START([60s tick]) --> SIM[HkbcEnterpriseSimulation.generate]
  SIM --> FOUND[Portfolio.publish_foundation]
  FOUND --> PAY[Payment lifecycles]
  FOUND --> MKT[Trade · FX · wealth · risk]
  PAY --> EVT[SourceSystem events]
  MKT --> EVT
  EVT --> BRZ[Append bronze rows]
  BRZ --> WAIT[Sleep] --> START
          

Grafo de eventos pay-to-post

State machine PayToPostToBalance — cada transição é um método de domínio que emite linhas de fornecedor.

Espinha dorsal do processo: Definido em kb/industries/hkbc/process_model.yaml. Os modos de chegada tardia (lag de ack SWIFT, clearing de cartão após auth, lag de caso AML, atraso de lote GL) e os modos de exceção (rejeição FPS, recusa de cartão, hold AML, fundos insuficientes, discrepância LC) ramificam dos mesmos ciclos de vida da entidade em vez de inserções aleatórias independentes.

flowchart LR
  OPEN[account_opened] --> INIT[payment_initiated]
  INIT --> POST[core_posted]
  POST --> AML[aml_screened]
  AML --> CLR[cleared]
  CLR --> BAL[balance_snapshot]
  BAL --> GL[posted_to_gl]
  INIT -.->|fps_reject| REJ[fps_rejected]
  INIT -.->|card_decline| DEC[card_declined]
  POST -.->|aml_hold| HOLD[aml_hold]
          

Categorias de tabelas bronze

O mesmo envelope de linhagem em cada tabela; a categoria determina o comportamento live.

Categorias de amostra: Todas as 60 tabelas bronze seguem este padrão de três categorias (snapshot, transação, evento), com metadados consistentes e acompanhamento de estado; o diagrama ilustra o padrão usado em todo o armazém.

flowchart LR
  subgraph snap["snapshot"]
    direction TB
    S1["CIF · product · branch · account"]
    S2[Daily foundation refresh]
  end
  subgraph txn["transaction"]
    direction TB
    T1["Payments · postings · LC · FX · GL"]
    T2[Append each live tick]
  end
  subgraph evt["event"]
    direction TB
    E1["AML · card auth · access · NPS"]
    E2[Append each live tick]
  end
  BRONZE[("hkbc_v2 bronze row")]
  snap --> BRONZE
  txn --> BRONZE
  evt --> BRONZE
          

Perfil da empresa

Aviso de empresa fictícia: «AYA» é uma empresa inteiramente fictícia, criada apenas para fins de demonstração. Não está afiliada, endossada nem destinada a representar a AXA SA, a AXA Hong Kong and Macau ou qualquer seguradora real.

AYA é uma seguradora composta de Hong Kong — Life & Savings, Health (incluindo VHIS e benefícios de colaboradores) e General Insurance — distribuída por agentes vinculados, bancassurance, brokers, a app Aria by AYA e parceiros de e-wallet embedded. A HQ fica em Quarry Bay, com um centro de aconselhamento em Central, AYA Medical Centre em Tsim Sha Tsui, uma sucursal em Macau e um escritório comercial GBA em Qianhai.

O negócio cobre fábrica de produto, underwriting classe Magnum, PAS dividido (vida em Ingenium, GI em Guidewire), cobrança de prémios FPS, comissão Varicent, FNOL auto/viagem 24×7, sinistros de saúde FINEOS, cessão de resseguro, avaliação Prophet IFRS 17 e diários SAP S/4 — com um subida de sinistros GI na época de tufões (junho–outubro) e um pico de viagem CNY / motor northbound nos canais digitais e de agência.

Entidades de amostra: A tabela abaixo mostra entidades de negócio representativas e os respetivos sistemas de origem; o EDW completo inclui entidades, subtipos e tabelas especializadas adicionais (p. ex. Prophet BEL/CSM, cessões de tratado, visitas de centro médico, redlines CLM) em todas as 60 tabelas bronze. Em V2, LifePolicy e GiPolicy as classes de domínio impulsionam as espinhas QuoteToBindToPremium e FnolToPay.

Modelo de domínio OOP

AyaEnterpriseSimulation sequencia o dia; os objetos de domínio são donos da lógica de emissão.

QuoteToBindToPremium é a espinha de new business; FnolToPay é a espinha de sinistros. LifePolicy.execute_lifecycle() percorre cotação → UW Magnum → emissão Ingenium → cobrança FPS → comissão → GL. GiPolicy.execute_lifecycle() percorre cotação → bind PolicyCenter → fatura BillingCenter → FNOL same-day opcional no ClaimCenter. AyaPortfolio.publish_foundation() masteriza produtos, agentes, escritórios e tomadores antes de as apólices correrem.

flowchart LR
  PORT[AyaPortfolio.publish_foundation]
  LIFE[LifePolicy.execute_lifecycle]
  GI[GiPolicy.execute_lifecycle]
  PORT --> LIFE
  PORT --> GI
  LIFE --> Q[Aria quote]
  Q --> UW[Magnum UW]
  UW --> PAS[Ingenium / PolicyCenter]
  PAS --> FPS[FPS collect]
  GI --> FNOL[ClaimCenter FNOL]
  FNOL --> RI[reinsurance cession]
  FPS --> GL[SAP S/4 IFRS 17]
          

Cadeia de valor quote-to-claim

Da fábrica de produto, através de distribuição, bind, cobrança, sinistros e fecho financeiro.

Vista de amostra: Isto ilustra a cadeia de valor primária através do ecossistema AYA; o EDW gerado completo inclui os 39 sistemas de origem, com integrações transversais, visitas cashless do centro médico e contabilidade de tratados não mostrados aqui.

%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
  subgraph factory["Product & distribution"]
    direction TB
    PRD[aya_product]
    AG[aya_agency]
    DIG[aya_digital Aria]
    PRD ~~~ AG
    AG ~~~ DIG
  end
  subgraph bind["Underwrite & bind"]
    direction TB
    MAG[swissre_magnum]
    LIFE[dxc_ingenium]
    PC[guidewire_pc]
    MAG ~~~ LIFE
    LIFE ~~~ PC
  end
  subgraph cash["Collect & commission"]
    direction TB
    BC[guidewire_bc]
    FPS[fps]
    VAR[varicent]
    BC ~~~ FPS
    FPS ~~~ VAR
  end
  subgraph claims["Claims & health"]
    direction TB
    CC[guidewire_cc]
    FN[fineos]
    CLIN[aya_health]
    CC ~~~ FN
    FN ~~~ CLIN
  end
  subgraph corp["Investments & close"]
    direction TB
    AIM[bloomberg_aim]
    PR[prophet]
    S4[sap_s4]
    AIM ~~~ PR
    PR ~~~ S4
  end
  factory --> bind --> cash --> claims --> corp
          

Organização funcional por departamento

HQ AYA Tower Quarry Bay e funções de reporte direto com sistemas de origem representativos.

Estrutura organizacional de amostra: Isto mostra as linhas de reporte primárias; a organização AYA completa inclui distritos de agência adicionais, equipas de Macau e GBA, e funções de shared services em todas as 39 integrações de fornecedor.

flowchart TB
  CEO[AYA Hong Kong]
  CEO --> LIFE[Life & Savings]
  CEO --> HLTH[Health & Employee Benefits]
  CEO --> GI[General Insurance]
  CEO --> DIST[Agency / banca / digital]
  CEO --> CLM[Claims]
  CEO --> FIN[Finance & actuarial]
  CEO --> HR[Human resources]
  CEO --> LEG[IT / legal / security]
          

Estádios de maturidade do EDW

Catálogo stage agrupa tabelas desde a fundação até ao corporativo.

Desagregação de amostra apresentada: Isto é um recorte representativo do inventário completo de 60 tabelas, distribuído pelas camadas de maturidade; a distribuição real reflete a linhagem completa de dados desde a fundação até às tabelas gold corporativas.

flowchart LR
  F["foundation
~12 tables"]
  D["distribution
~10 tables"]
  P["policy & premium
~9 tables"]
  C["claims
~6 tables"]
  CO["finance & corporate
~23 tables"]
  F --> D --> P --> C
  F -.-> CO
  P -.-> CO
          

Entidades nucleares do negócio

Relações lógicas e chaves âncora. Produto (product_code) e apólice (policy_number) são a espinha; os sinistros ligam via FNOL e números de sinistro.

Diagrama de amostra: Este diagrama de relação de entidades mostra o modelo lógico nuclear; o EDW gerado completo contém 60 tabelas bronze em 39 sistemas de fornecedor com tabelas de detalhe adicionais e ramos de linhagem. As instâncias de entidade transportam entity_refs em cada evento emitido, para testes de joinability.

erDiagram
  PRODUCT ||--o{ LIFE_POLICY : tariffs
  PRODUCT ||--o{ GI_POLICY : tariffs
  AGENT ||--o{ LIFE_POLICY : sells
  AGENT ||--o{ GI_POLICY : sells
  POLICYHOLDER ||--o{ LIFE_POLICY : owns
  POLICYHOLDER ||--o{ GI_POLICY : owns
  LIFE_POLICY ||--o{ HEALTH_CLAIM : incurs
  GI_POLICY ||--o{ GI_CLAIM : notifies
  GI_POLICY ||--o{ INVOICE : bills
  LIFE_POLICY ||--o{ PREMIUM : collects
  GI_CLAIM ||--o{ CESSION : cedes
          

Paisagem de sistemas de origem

39 prefixos de fornecedor, 60 tabelas bronze.

Sistemas de amostra apresentados: O diagrama abaixo ilustra sistemas de fornecedor representativos; o conjunto de dados gerado completo inclui os 39 sistemas com linhagem de tabelas e pontos de integração no backfill de histórico e nos streams em tempo real. Os manifests de sistemas de origem partilhados em kb/source_systems/ são reutilizados entre indústrias — a AYA acrescenta aya_product, aya_agency, aya_digital, e aya_health como sistemas internos específicos da indústria, mais um PAS dividido (Guidewire + Ingenium).

Cada tabela segue a {source_system_}__{entity} convenção de nomenclatura (p.ex. aya_product__product, guidewire_cc__claim), preservando a forma nativa das colunas do fornecedor e as chaves estrangeiras do esquema de exportação real de cada produto. O VibeBI infere a conformidade dos dados mestres quando promove os registos para silver e gold.

flowchart TB
  subgraph foundation["Foundation"]
    direction TB
    f1["aya_product · aya_agency · oracle_scm"]
    f2["salesforce · workday · sap_s4 dimensions"]
  end
  subgraph distribution["Distribution"]
    direction TB
    d1["aya_digital · salesforce_cpq"]
    d2["hubspot · marketo · google_analytics"]
  end
  subgraph policy["Policy & premium"]
    direction TB
    p1["swissre_magnum · dxc_ingenium"]
    p2["guidewire_pc · guidewire_bc · fps · varicent"]
  end
  subgraph claims["Claims"]
    direction TB
    c1["guidewire_cc · fineos · aya_health · sap_fs_ri"]
  end
  subgraph corporate["Finance & corporate"]
    direction TB
    co1["prophet · bloomberg_aim · sap_s4 journals"]
    co2["anaplan · adp · ukg · concur · coupa"]
    co3["servicenow · okta · splunk · ironclad · onetrust"]
  end
  foundation --> distribution --> policy --> claims
  foundation --> corporate
  policy --> corporate
          

Fluxo de dados de ponta a ponta

Sim OOP V2 → bronze em ClickHouse; semântica VibeBI → silver → gold na mesma instância.

Percurso OOP: kb/industries/aya/ define a espinha dorsal das operações e o modelo de entidades; AyaEnterpriseSimulation sequencia os ciclos de vida de domínio; SourceSystem os adapters exportam linhas nativas do fornecedor para aya_v2.

flowchart LR
  subgraph kb["kb/industries/aya"]
    SPINE[entity + process models]
  end
  subgraph sim["sim/industries/aya"]
    ORCH[AyaEnterpriseSimulation]
    DOM["LifePolicy · GiPolicy
execute_lifecycle()"]
  end
  subgraph simedw["SimEDW V2"]
    ADP[SourceSystem adapters]
    CHB[("ClickHouse aya_v2
60 bronze tables")]
  end
  subgraph vibebi["VibeBI"]
    SEM[("semantic")]
    SIL[("silver views")]
    GLD[("gold views")]
  end
  DASH["Dashboards & agents"]
  SPINE --> DOM
  ORCH --> DOM --> ADP --> CHB
  CHB --> SEM --> SIL --> GLD --> DASH
          

Ciclo bronze em tempo real

./live-v2-aya — ciclo de 60s via AyaEnterpriseSimulation.generate().

Frequência em tempo real: Cada tick executa QuoteToBindToPremium e FnolToPay — os objetos de domínio emitem cotações, decisões UW, binds PAS, cobranças FPS, comissões, FNOL e linhas GL correlacionados; os ticks live de hoje emitem apenas eventos até Hong Kong as_of para que cotações, FNOL, FPS e diários cresçam ao longo do dia. A escala varia por tick (base 5 por omissão). Faça backfill de qualquer intervalo de histórico de que precise (--days N no script live ou na CLI).

flowchart LR
  START([60s tick]) --> SIM[AyaEnterpriseSimulation.generate]
  SIM --> FOUND[Portfolio.publish_foundation]
  FOUND --> LIFE[LifePolicy lifecycles]
  FOUND --> GI[GiPolicy lifecycles]
  LIFE --> CORP[Health + investments + finance]
  GI --> CORP
  CORP --> EVT[SourceSystem events]
  EVT --> BRZ[Append bronze rows]
  BRZ --> WAIT[Sleep] --> START
          

Grafos de eventos quote-to-bind e FNOL

State machines QuoteToBindToPremium e FnolToPay — cada transição é um método de domínio que emite linhas de fornecedor.

Espinha dorsal do processo: Definido em kb/industries/aya/process_model.yaml. Os modos de chegada tardia (lag de emissão PAS, clearing FPS, lote de comissões, FNOL noturno, bordereau de resseguro) e os modos de exceção (UW refer/recusa, lapse de prémio, sinistro recusado, liquidação parcial) ramificam dos mesmos ciclos de vida da entidade em vez de inserções aleatórias independentes.

flowchart LR
  Q[quoted] --> UW[underwritten]
  UW --> BIND[bound]
  BIND --> BILL[billed]
  BILL --> COL[collected]
  COL --> COMM[commissioned]
  COMM --> GL[posted_to_gl]
  UW -.->|uw_decline| DEC[declined]
  BILL -.->|lapse| LAPSE[premium_lapse]
          

flowchart LR
  FNOL[fnol_submitted] --> OPEN[claim_opened]
  OPEN --> RSV[reserved]
  RSV --> PAY[paid]
  PAY --> CLOSE[closed]
  OPEN -.->|denied| DENY[claim_denied]
  PAY -.->|partial| PART[partial_settlement]
          

Categorias de tabelas bronze

O mesmo envelope de linhagem em cada tabela; a categoria determina o comportamento live.

Categorias de amostra: Todas as 60 tabelas bronze seguem este padrão de três categorias (snapshot, transação, evento), com metadados consistentes e acompanhamento de estado; o diagrama ilustra o padrão usado em todo o armazém.

flowchart LR
  subgraph snap["snapshot"]
    direction TB
    S1["Product · agent · policyholder masters"]
    S2[Daily foundation refresh]
  end
  subgraph txn["transaction"]
    direction TB
    T1["Policies · premiums · claims · GL"]
    T2[Append each live tick]
  end
  subgraph evt["event"]
    direction TB
    E1["Digital sessions · FNOL · clinic visits"]
    E2[Append each live tick]
  end
  BRONZE[("aya_v2 bronze row")]
  snap --> BRONZE
  txn --> BRONZE
  evt --> BRONZE