A escala empresarial almacenes de muestra.

Perfil de la empresa

Aviso de empresa ficticia: «Hilson» es una empresa enteramente ficticia, creada únicamente con fines de demostración. No está afiliada a Hilton Inc., Hyatt Hotels Corporation ni a ninguna empresa hotelera real, ni está respaldada por ellas, ni pretende representarlas.

Hilson Hospitality Group es un operador hotelero global con ~680 propiedades en 18 marcas — desde banderas de lujo (nivel Waldorf, nivel Conrad) pasando por full-service (Hilson, nivel DoubleTree) hasta select-service y estancias prolongadas. Cada propiedad opera un PMS Opera on-premise y un CRS central Amadeus, atendiendo una mezcla de huéspedes de ocio transitorio, corporativos negociados y de grupos/convenciones.

El negocio abarca fidelización (Hilson Honors con millones de miembros), ventas de grupos y convenciones (pipeline de salesforce, bloques de habitaciones CPQ), puntos de alimentos y bebidas (POS MICROS Simphony), informes a propietarios/franquicias (estados de Oracle Fusion) y funciones corporativas — generando unas 1.900 reservas PMS y 1.750 encabezados de folio en un día hábil típico, con una oleada de viajes de verano (junio–agosto) que eleva la ocupación, el ADR, el gasto de F&B y la actividad de fidelización en todas las propiedades.

Entidades de muestra: La tabla siguiente muestra entidades de negocio representativas y sus sistemas de origen; el EDW completo incluye entidades adicionales, subtipos y tablas especializadas (p. ej., eventos de canal OTA, restricciones de planes tarifarios, acuerdos legales de franquicia, redlines de deal-desk) en las 62 tablas de bronce. En V2, StayReservation y las clases de dominio relacionadas emiten filas de PMS, CRS, folio y fidelización a través de adaptadores del sistema de origen a medida que avanza el ciclo de vida de la estancia.

Modelo de dominio OOP

HilsonEnterpriseSimulation secuencia el día; los objetos de dominio poseen la lógica de emisión.

ReservationToLoyaltyAndOwnerReporting es la columna vertebral primaria del proceso. StayReservation.execute_lifecycle() recorre reserva → sincronización PMS → cargos de folio → pago → puntos de fidelización → snapshot de ocupación → estado del propietario → GL. HilsonPortfolio.publish_foundation() consolida marcas, propiedades y miembros Honors antes de que corran las reservas.

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]
          

Cadena de valor de huésped y propiedad

Desde el maestro de marca y propiedad hasta distribución, estancia, liquidación e informes al propietario.

Vista de muestra: Esto ilustra la cadena de valor primaria a través del ecosistema Hilson; el EDW generado completo incluye los 31 sistemas de origen con integraciones interfuncionales, flujos de ingresos secundarios y flujos del ciclo de vida de fidelización no mostrados aquí.

%%{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
          

Organización funcional por departamento

Sede empresarial y funciones de reporte directo con sistemas de origen representativos.

Estructura organizativa de muestra: Esto muestra las líneas de reporte primarias; la organización completa de Hilson incluye dirección regional adicional, equipos específicos de marca y funciones de servicios compartidos en las 31 integraciones de proveedor.

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]
          

Etapas de madurez del EDW

Catálogo stage agrupa tablas desde la base hasta lo corporativo.

Desglose de muestra mostrado: Esta es una franja representativa del inventario completo de 62 tablas distribuido en capas de madurez; la distribución real refleja el linaje de datos completo desde la base hasta las tablas de oro 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 centrales de negocio

Relaciones lógicas y claves ancla. Propiedad (hotel_code) es la columna vertebral; identidad del huésped mediante Honors y tablas de estancia.

Diagrama de muestra: Este diagrama de relaciones de entidades muestra el modelo lógico central; el EDW generado completo contiene 62 tablas de bronce en 31 sistemas de proveedor con miles de tablas de detalle adicionales y ramas de linaje.

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
          

Paisaje de sistemas de origen

31 prefijos de proveedor, 62 tablas de bronce.

Sistemas de muestra mostrados: El diagrama siguiente ilustra sistemas de proveedor representativos; el conjunto de datos generado completo incluye los 31 sistemas con su linaje de tablas completo y puntos de integración a lo largo del relleno histórico y los flujos en vivo.

Cada tabla sigue la {source_system_}__{entity} convención de nomenclatura (p. ej. oracle_opera__reservation, hilson_loyalty__member), conservando la forma de columnas nativa del proveedor y las claves foráneas del esquema de exportación real de cada producto. VibeBI infiere la conformidad de datos maestros al promover registros a plata y oro.

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
          

Flujo de datos de extremo a extremo

Simulación OOP V2 → bronce en ClickHouse; semántica VibeBI → plata → oro en la misma instancia.

Ruta OOP: kb/industries/hilson/ define la columna vertebral de operaciones y el modelo de entidades; HilsonEnterpriseSimulation secuencia los ciclos de vida de dominio; SourceSystem los adaptadores exportan filas nativas del proveedor hacia 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 de bronce en vivo

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

Frecuencia en vivo: Cada ciclo ejecuta la máquina de estados de reserva a fidelización — los objetos de dominio emiten filas correlacionadas de CRS, PMS, folio, F&B, pagos, fidelización y GL; la escala varía por ciclo (base predeterminada 5). Rellene el tramo de historia que necesite (--days N); Hilson incluye detección de huecos en la tabla ancla 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 de estancia del huésped

Máquina de estados ReservationToLoyaltyAndOwnerReporting — cada transición emite filas de proveedor.

Columna vertebral del proceso: Definido en kb/industries/hilson/process_model.yaml. Los modos de excepción (no-shows, chargebacks, upgrades de habitación) se ramifican desde el mismo ciclo de vida de entidad, no desde inserciones aleatorias independientes.

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]
          

Categorías de tablas de bronce

El mismo sobre de linaje en cada tabla; la categoría controla la actualización en vivo frente al append en micro-lotes.

Categorías de muestra: Las 62 tablas de bronce siguen este patrón de tres categorías (snapshot, transacción, evento) con metadatos y seguimiento de estado consistentes; el diagrama ilustra el patrón usado en todo el almacén.

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 de la empresa

Aviso de empresa ficticia: «P&C» es una empresa enteramente ficticia, creada únicamente con fines de demostración. No está afiliada a The Procter & Gamble Company ni a ningún fabricante de CPG real, ni está respaldada por ellos, ni pretende representarlos.

P&C es un fabricante-comercializador global de bienes de consumo empaquetados — un modelo B2B2C que vende productos de uso diario a través de canales de gran distribución, club, supermercado y comercio electrónico en ~180 países. Cinco unidades de negocio sectoriales (SBU) cubren Cuidado de telas y del hogar, Cuidado infantil/femenino/familiar, Belleza, Salud y Aseo personal, con ~12 marcas insignia (TidalWave, ComfortWrap, BrightSmile, EdgePro y otras) y ocho plantas de fabricación más tres centros de distribución regionales.

El negocio abarca planificación de demanda, compras de materia prima, producción MES, liberación de calidad, distribución de productos terminados, pedidos de clientes minoristas, trade marketing y finanzas — generando órdenes de trabajo MES correlacionadas, PO de Ariba, encabezados OMS, envíos OTM y líneas de diario SAP en cada día de simulación, con una Oleada de Spring Clean (marzo–abril) que eleva la demanda de cuidado de telas y del hogar, el rendimiento de planta y el sell-in minorista en Norteamérica y EMEA.

Entidades de muestra: La tabla siguiente muestra entidades de negocio representativas y sus sistemas de origen; el EDW completo incluye entidades adicionales, subtipos y tablas especializadas (p. ej., lecturas de sensores IoT, órdenes de trabajo de mantenimiento, promociones comerciales, redlines de CLM) en las 60 tablas de bronce. En V2, ProductionBatch y CustomerOrder las clases de dominio impulsan la columna MakeToShipToSell.

Modelo de dominio OOP

PcEnterpriseSimulation secuencia el día; los objetos de dominio poseen la lógica de emisión.

MakeToShipToSell es la columna vertebral primaria del proceso. ProductionBatch.execute_lifecycle() recorre pronóstico → comprar → producir → liberación QC → productos terminados; CustomerOrder.execute_lifecycle() recorre captura OMS → cumplimiento WMS → envío OTM. PcPortfolio.publish_foundation() consolida SBU, marcas, plantas, SKU y cuentas minoristas antes de que corran los lotes y los pedidos. Los objetos de servicio (PlantOperations, CommercialProgram, FinanceAndCorporate) emiten filas corporativas y de marketing de apoyo.

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]
          

Cadena de valor de fabricación a envío

Desde el portafolio de marcas hasta planificar, fabricar, mover, vender y el cierre corporativo.

Vista de muestra: Esto ilustra la cadena de valor primaria a través del ecosistema P&C; el EDW generado completo incluye los 34 sistemas de origen con integraciones interfuncionales, telemetría IoT de planta y flujos de trade marketing no mostrados aquí.

%%{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
          

Organización funcional por departamento

Sede global en Cincinnati y funciones de reporte directo con sistemas de origen representativos.

Estructura organizativa de muestra: Esto muestra las líneas de reporte primarias; la organización completa de P&C incluye equipos regionales de SBU, gerentes de planta y funciones de servicios compartidos en las 34 integraciones de proveedor.

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]
          

Etapas de madurez del EDW

Catálogo stage agrupa tablas desde la base hasta lo corporativo.

Desglose de muestra mostrado: Esta es una franja representativa del inventario completo de 60 tablas distribuido en capas de madurez; la distribución real refleja el linaje de datos completo desde la base hasta las tablas de oro 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 centrales de negocio

Relaciones lógicas y claves ancla. Marca (brand_code) y planta (facility_code) son la columna vertebral; los números de material vinculan PIM con MES.

Diagrama de muestra: Este diagrama de relaciones de entidades muestra el modelo lógico central; el EDW generado completo contiene 60 tablas de bronce en 34 sistemas de proveedor con tablas de detalle adicionales y ramas de linaje. Las instancias de entidad llevan entity_refs en cada evento emitido para pruebas 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
          

Paisaje de sistemas de origen

34 prefijos de proveedor, 60 tablas de bronce.

Sistemas de muestra mostrados: El diagrama siguiente ilustra sistemas de proveedor representativos; el conjunto de datos generado completo incluye los 34 sistemas con su linaje de tablas completo y puntos de integración a lo largo del relleno histórico y los flujos en vivo. Los manifiestos compartidos de sistemas de origen en kb/source_systems/ se reutilizan entre industrias — P&C añade pc_brand como un sistema interno específico de la industria.

Cada tabla sigue la {source_system_}__{entity} convención de nomenclatura (p. ej. pc_brand__brand, siemens_mes__work_order), conservando la forma de columnas nativa del proveedor y las claves foráneas del esquema de exportación real de cada producto. VibeBI infiere la conformidad de datos maestros al promover registros a plata y oro.

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
          

Flujo de datos de extremo a extremo

Simulación OOP V2 → bronce en ClickHouse; semántica VibeBI → plata → oro en la misma instancia.

Ruta OOP: kb/industries/pnc/ define la columna vertebral de operaciones y el modelo de entidades; PcEnterpriseSimulation secuencia los ciclos de vida de dominio; SourceSystem los adaptadores exportan filas nativas del proveedor hacia 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 de bronce en vivo

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

Frecuencia en vivo: Cada ciclo ejecuta la máquina de estados MakeToShipToSell — los objetos de dominio emiten filas correlacionadas de pronóstico, PO, MES, WMS, OMS, OTM y GL por lote de producción y pedido de cliente minorista; la escala varía por ciclo (base predeterminada 5). Rellene el tramo de historia que necesite (--days N en el script en vivo o la 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 de fabricación a envío

Máquina de estados MakeToShipToSell — cada transición es un método de dominio que emite filas de proveedor.

Columna vertebral del proceso: Definido en kb/industries/pnc/process_model.yaml. Los modos de excepción (scrap de lote, retención de calidad, envío parcial, retraso de proveedor) se ramifican desde los mismos ciclos de vida de entidad, no desde inserciones aleatorias independientes.

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]
          

Categorías de tablas de bronce

El mismo sobre de linaje en cada tabla; la categoría impulsa el comportamiento en vivo.

Categorías de muestra: Las 60 tablas de bronce siguen este patrón de tres categorías (snapshot, transacción, evento) con metadatos y seguimiento de estado consistentes; el diagrama ilustra el patrón usado en todo el almacén.

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 de la empresa

Aviso de empresa ficticia: «HKBC» es una empresa enteramente ficticia, creada únicamente con fines de demostración. No está afiliada, respaldada ni destinada a representar a HSBC Holdings plc, The Hongkong and Shanghai Banking Corporation Limited ni a ningún banco real.

HKBC (Hong Kong Banking Corporation) es un banco universal de Hong Kong con sede en Central, con Wealth and Personal Banking, Commercial Banking y Global Banking and Markets. La franquicia capta depósitos HKD, origina hipotecas HIBOR y crédito no garantizado, emite tarjetas, opera 24×7 los rails Faster Payment System y PearlPay (clase PayMe), financia el comercio del Greater Bay Area y registra FX USD/HKD y CNH dentro de la banda de convertibilidad 7,75–7,85.

El libro cubre ~10 sucursales en Hong Kong Island, Kowloon y los New Territories, más una mesa mayorista GBA en Qianhai y una mesa de mercados en Londres — generando créditos FPS, autorizaciones de tarjeta, transferencias CHATS/SWIFT, asientos de doble partida, alertas AML y diarios SAP correlacionados cada día de simulación, con un Oleada de Año Nuevo lunar / préstamo fiscal T1 que eleva el volumen P2P de PearlPay, los cobros FPS y la originación de préstamos personales.

Entidades de muestra: La tabla inferior muestra entidades de negocio representativas y sus sistemas de origen; el EDW completo incluye entidades, subtipos y tablas especializadas adicionales (p. ej. casos AML, provisiones ECL, órdenes de valores, redlines de facilidad) en las 60 tablas bronce. En V2, FpsPayment y las clases de dominio relacionadas impulsan la columna PayToPostToBalance.

Modelo de dominio OOP

HkbcEnterpriseSimulation secuencia el día; los objetos de dominio poseen la lógica de emisión.

PayToPostToBalance es la columna vertebral primaria del proceso. FpsPayment.execute_lifecycle() (y las contrapartes PearlPay, tarjeta, CHATS, SWIFT) recorre mensaje de rail → asiento de doble partida en el core → alerta AML opcional → saldo de depósitos EOD → GL. HkbcPortfolio.publish_foundation() masteriza sucursales, productos, clientes CIF y cuentas antes de que corran los pagos. Los objetos de servicio emiten filas de trade CMB, FX GBM, wealth, riesgo y corporativo.

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]
          

Cadena de valor de pagos y franquicia

Desde el maestro CIF y de producto, a través de rails, posting de core, riesgo y cierre financiero.

Vista de muestra: Esto ilustra la cadena de valor primaria a través del ecosistema HKBC; el EDW generado completo incluye los 32 sistemas de origen con integraciones interfuncionales, dealing de wealth y corredores comerciales GBA no mostrados aquí.

%%{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
          

Organización funcional por departamento

HQ Harbourview Tower y funciones de reporte directo con sistemas de origen representativos.

Estructura organizativa de muestra: Esto muestra las líneas de reporting primarias; la organización HKBC completa incluye sucursales de distrito adicionales, mesas GBA y funciones de shared services en las 32 integraciones de proveedor.

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]
          

Etapas de madurez del EDW

Catálogo stage agrupa tablas desde la base hasta lo corporativo.

Desglose de muestra mostrado: Esta es una franja representativa del inventario completo de 60 tablas distribuido en capas de madurez; la distribución real refleja el linaje de datos completo desde la base hasta las tablas de oro 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 centrales de negocio

Relaciones lógicas y claves de ancla. Cliente (customer_id) y cuenta (account_id) son la columna; los pagos se unen vía source_txn_id.

Diagrama de muestra: Este diagrama de relaciones de entidades muestra el modelo lógico central; el EDW generado completo contiene 60 tablas de bronce en 32 sistemas de proveedor con tablas de detalle adicionales y ramas de linaje. Las instancias de entidad llevan entity_refs en cada evento emitido para pruebas 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
          

Paisaje de sistemas de origen

32 prefijos de proveedor, 60 tablas bronce.

Sistemas de muestra mostrados: El diagrama inferior ilustra sistemas de proveedor representativos; el conjunto de datos generado completo incluye los 32 sistemas con su linaje de tablas y puntos de integración en el relleno histórico y los streams en vivo. Los manifiestos de sistemas de origen compartidos en kb/source_systems/ se reutilizan entre industrias — HKBC añade hkbc_core, hkbc_pay, hkbc_trade, y hkbc_wealth como sistemas internos específicos de la industria, más los rails de mercado de Hong Kong.

Cada tabla sigue la {source_system_}__{entity} convención de nomenclatura (p. ej. hkbc_core__account, hkicl_fps__payment), conservando la forma de columnas nativa del proveedor y las claves foráneas del esquema de exportación real de cada producto. VibeBI infiere la conformidad de datos maestros al promover registros a plata y oro.

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
          

Flujo de datos de extremo a extremo

Simulación OOP V2 → bronce en ClickHouse; semántica VibeBI → plata → oro en la misma instancia.

Ruta OOP: kb/industries/hkbc/ define la columna vertebral de operaciones y el modelo de entidades; HkbcEnterpriseSimulation secuencia los ciclos de vida de dominio; SourceSystem los adaptadores exportan filas nativas del proveedor hacia 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 de bronce en vivo

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

Frecuencia en vivo: Cada tick ejecuta la máquina de estados PayToPostToBalance — los objetos de dominio emiten filas FPS, PearlPay, tarjeta, CHATS, SWIFT, posting de core, AML y GL correlacionadas; los ticks en vivo de hoy emiten solo eventos hasta Hong Kong as_of para que la cinta de pagos crezca a lo largo del día. La escala varía por tick (base 5 por defecto). Rellene cualquier tramo de historial que necesite (--days N en el script en vivo o la 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

Máquina de estados PayToPostToBalance — cada transición es un método de dominio que emite filas de proveedor.

Columna vertebral del proceso: Definido en kb/industries/hkbc/process_model.yaml. Los modos de llegada tardía (lag de ack SWIFT, clearing de tarjeta tras auth, lag de caso AML, retraso de lote GL) y los modos de excepción (rechazo FPS, declinación de tarjeta, hold AML, fondos insuficientes, discrepancia LC) se ramifican de los mismos ciclos de vida de entidad en lugar de inserciones aleatorias independientes.

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]
          

Categorías de tablas de bronce

El mismo sobre de linaje en cada tabla; la categoría impulsa el comportamiento en vivo.

Categorías de muestra: Las 60 tablas de bronce siguen este patrón de tres categorías (snapshot, transacción, evento) con metadatos y seguimiento de estado consistentes; el diagrama ilustra el patrón usado en todo el almacén.

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 de la empresa

Aviso de empresa ficticia: «AYA» es una empresa enteramente ficticia, creada únicamente con fines de demostración. No está afiliada, respaldada ni destinada a representar a AXA SA, AXA Hong Kong and Macau ni a ninguna aseguradora real.

AYA es una aseguradora compuesta de Hong Kong — Life & Savings, Health (incluido VHIS y beneficios para empleados) y General Insurance — distribuida por agentes vinculados, bancaseguros, brokers, la app Aria by AYA y socios de e-wallet embebidos. La sede está en Quarry Bay, con un centro de asesoría en Central, AYA Medical Centre en Tsim Sha Tsui, una sucursal en Macao y una oficina comercial GBA en Qianhai.

El negocio cubre fábrica de producto, suscripción clase Magnum, PAS dividido (vida en Ingenium, GI en Guidewire), cobro de primas FPS, comisión Varicent, FNOL auto/viaje 24×7, siniestros de salud FINEOS, cesión de reaseguro, valoración Prophet IFRS 17 y diarios SAP S/4 — con un alza de siniestros GI en temporada de tifones (junio–octubre) y un pico de viaje CNY / motor northbound en canales digitales y de agencia.

Entidades de muestra: La tabla inferior muestra entidades de negocio representativas y sus sistemas de origen; el EDW completo incluye entidades, subtipos y tablas especializadas adicionales (p. ej. Prophet BEL/CSM, cesiones de tratado, visitas de centro médico, redlines CLM) en las 60 tablas bronce. En V2, LifePolicy y GiPolicy las clases de dominio impulsan las columnas QuoteToBindToPremium y FnolToPay.

Modelo de dominio OOP

AyaEnterpriseSimulation secuencia el día; los objetos de dominio poseen la lógica de emisión.

QuoteToBindToPremium es la columna de nuevo negocio; FnolToPay es la columna de siniestros. LifePolicy.execute_lifecycle() recorre cotización → UW Magnum → emisión Ingenium → cobro FPS → comisión → GL. GiPolicy.execute_lifecycle() recorre cotización → bind PolicyCenter → factura BillingCenter → FNOL same-day opcional en ClaimCenter. AyaPortfolio.publish_foundation() masteriza productos, agentes, oficinas y tomadores antes de que corran las pólizas.

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]
          

Cadena de valor quote-to-claim

Desde la fábrica de producto, a través de distribución, bind, cobro, siniestros y cierre financiero.

Vista de muestra: Esto ilustra la cadena de valor primaria a través del ecosistema AYA; el EDW generado completo incluye los 39 sistemas de origen con integraciones interfuncionales, visitas cashless del centro médico y contabilidad de tratados no mostrados aquí.

%%{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
          

Organización funcional por departamento

HQ AYA Tower Quarry Bay y funciones de reporte directo con sistemas de origen representativos.

Estructura organizativa de muestra: Esto muestra las líneas de reporting primarias; la organización AYA completa incluye distritos de agencia adicionales, equipos de Macao y GBA, y funciones de shared services en las 39 integraciones de proveedor.

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]
          

Etapas de madurez del EDW

Catálogo stage agrupa tablas desde la base hasta lo corporativo.

Desglose de muestra mostrado: Esta es una franja representativa del inventario completo de 60 tablas distribuido en capas de madurez; la distribución real refleja el linaje de datos completo desde la base hasta las tablas de oro 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 centrales de negocio

Relaciones lógicas y claves de ancla. Producto (product_code) y póliza (policy_number) son la columna; los siniestros se unen vía FNOL y números de siniestro.

Diagrama de muestra: Este diagrama de relaciones de entidades muestra el modelo lógico central; el EDW generado completo contiene 60 tablas de bronce en 39 sistemas de proveedor con tablas de detalle adicionales y ramas de linaje. Las instancias de entidad llevan entity_refs en cada evento emitido para pruebas 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
          

Paisaje de sistemas de origen

39 prefijos de proveedor, 60 tablas bronce.

Sistemas de muestra mostrados: El diagrama inferior ilustra sistemas de proveedor representativos; el conjunto de datos generado completo incluye los 39 sistemas con su linaje de tablas y puntos de integración en el relleno histórico y los streams en vivo. Los manifiestos de sistemas de origen compartidos en kb/source_systems/ se reutilizan entre industrias — AYA añade aya_product, aya_agency, aya_digital, y aya_health como sistemas internos específicos de la industria, más un PAS dividido (Guidewire + Ingenium).

Cada tabla sigue la {source_system_}__{entity} convención de nomenclatura (p. ej. aya_product__product, guidewire_cc__claim), conservando la forma de columnas nativa del proveedor y las claves foráneas del esquema de exportación real de cada producto. VibeBI infiere la conformidad de datos maestros al promover registros a plata y oro.

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
          

Flujo de datos de extremo a extremo

Simulación OOP V2 → bronce en ClickHouse; semántica VibeBI → plata → oro en la misma instancia.

Ruta OOP: kb/industries/aya/ define la columna vertebral de operaciones y el modelo de entidades; AyaEnterpriseSimulation secuencia los ciclos de vida de dominio; SourceSystem los adaptadores exportan filas nativas del proveedor hacia 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 de bronce en vivo

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

Frecuencia en vivo: Cada tick ejecuta QuoteToBindToPremium y FnolToPay — los objetos de dominio emiten cotizaciones, decisiones UW, binds PAS, cobros FPS, comisiones, FNOL y líneas GL correlacionados; los ticks en vivo de hoy emiten solo eventos hasta Hong Kong as_of para que cotizaciones, FNOL, FPS y diarios crezcan a lo largo del día. La escala varía por tick (base 5 por defecto). Rellene cualquier tramo de historial que necesite (--days N en el script en vivo o la 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 y FNOL

Máquinas de estados QuoteToBindToPremium y FnolToPay — cada transición es un método de dominio que emite filas de proveedor.

Columna vertebral del proceso: Definido en kb/industries/aya/process_model.yaml. Los modos de llegada tardía (lag de emisión PAS, clearing FPS, lote de comisiones, FNOL nocturno, bordereau de reaseguro) y los modos de excepción (UW refer/rechazo, caducidad de prima, siniestro denegado, liquidación parcial) se ramifican de los mismos ciclos de vida de entidad en lugar de inserciones aleatorias independientes.

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]
          

Categorías de tablas de bronce

El mismo sobre de linaje en cada tabla; la categoría impulsa el comportamiento en vivo.

Categorías de muestra: Las 60 tablas de bronce siguen este patrón de tres categorías (snapshot, transacción, evento) con metadatos y seguimiento de estado consistentes; el diagrama ilustra el patrón usado en todo el almacén.

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