RF01 Servicio de recuperación de tickets no integrados (pub/sub, RDO, fallos Dataflow)

Situación Actual

No tenemos resiliencia automatizada. Dependemos de procesos manuales, cruces entre entornos que no deberían tocarse y de la vigilancia de una persona.

A. PoS (Tiendas Físicas) + RDO

Detección Humana No hay alerta sistémica fiable. La pérdida de datos la detecta una persona revisando un informe de Looker Studio donde compara el legacy (FAT) contra la capa Silver en BigQuery. Si esa persona no mira, no nos enteramos.

Dependencia de UAT (Obsolescencia) Para recuperar datos, usamos el entorno de ¡pruebas! (UAT) como almacén. Un proceso en Spring Boot carga los backups de las cajas en la BBDD de UAT solo para poder consultarlos. Estamos usando un entorno de test como si fuera producción.

Reprocesado "Cutre" Una vez identificados los tickets, ejecutamos scripts ad-hoc heredados que leen el JSON crudo desde UAT y lo inyectan a la fuerza en el Pub/Sub (PoS) de Producción.

Monitorización Básica Existe una Google Cloud Function (digital_ticket_control) que detecta anomalías estructurales simples (cabecera sin líneas) e intenta republicarlas, pero su alcance es limitado.

B. eCommerce (Ocado)

Procesos Cíclicos y Monitorización Dependemos de tareas programadas en la infraestructura de Ocado Orders Sync que comparan los pedidos pagados (Ocado Datafeeds) con Bronze/Silver.

Hay una segunda tabla de control independiente para eCom.

MONITORIZACIÓN: Un cíclico revisa los últimos 2-3 días: compara Bronze contra una vista que extrae la info de Ocado Datafeeds y para los pedidos que falten, encola sus IDs para procesamiento.

Además, los pedidos que fallan al procesarse se acumulan en colas de mensajes fallidos (Dead Letter Queue), cuyo contenido es el código de pedido. Estas colas también se explotan para monitorizar y reprocesar envíos fallidos mediante GitHub Pipelines.

Puntos de Fallo Silenciosos Si una cola de Ocado Orders Sync falla o se detiene (como ocurrió recientemente durante días), el sistema no alerta hasta que el impacto llega a negocio. Aunque existe un flujo de reprocesado, requiere invocación manual y nadie lo ejecuta de forma proactiva.

Reprocesado Ocado Orders Sync tiene una API que reprocesa un día cualquiera de la misma forma que lo haría la monitorización.

En la práctica, la API publica en una cola el código del pedido y datos que obtiene del datafeed. Con ello, una segunda ruta (consumidor queue⇒api⇒Pub/Sub (eCom)) invoca orders API y publica definitivamente en Pub/Sub.

C. Duplicados y Dataflow

Duplicados Se gestionan con un procedimiento almacenado en BigQuery posterior a la carga.

Dataflow Los fallos técnicos (timeouts, errores de procesamiento) que no llegan a Bronze quedan en el limbo si la Google Cloud Function actual no los detecta.

Solución Técnica

Siguiendo las directrices del equipo de arquitectura, la nueva arquitectura elimina UAT y la detección de duplicados y divide la responsabilidad en dos guardianes automáticos: uno mira al pasado (Respaldo) y otro al presente (Integridad).

A. Subsistema PoS + RDO (El Núcleo del Cambio)

Implementamos dos funciones para cubrir el flujo completo:

El Reconciliador: transaction_pos_backup_reconciler (GCF_1)

• Fuente de Verdad: El Backup PoS en GCS (.zip) subido por Backup Transacciones PoS. Asumimos que todo lo que está en el backup es la verdad absoluta — eliminamos la necesidad de cotejar con FAT.
• Lógica de Conciliación:
  1. Consulta la Tabla de Control (Staging) para obtener el inventario de lo procesado hoy.
  2. Lee y procesa el ZIP de la tienda en memoria (extrae ID, tienda, fecha).
  3. Match: Cruza ambas listas.
  4. Acción (Backfilling): Si el ticket está en el ZIP pero no en la Tabla de Control (Indicador: BACKUP_MISSING_IN_CONTROL) → Llama a la API de Ventas PoS.
• Resultado: La API ejecuta bin2raw, escribe en la tabla de control y distribuye a Pub/Sub (PoS) y RDO.

%% RF01 — Sequence: Backup + GCF_1 Reconciliación

sequenceDiagram
    autonumber

    participant GCS as Backup PoS en GCS
    participant GCF1 as transaction_pos_backup_reconciler
    participant Staging as Staging (Tabla de Control)
    participant API as API de Ventas PoS
    participant Yoda as Yoda PoS (bin2raw)
    participant PubSub as Pub/Sub (PoS)
    participant RDO as RDO

    Note over GCF1,Staging: Reconciliación (scheduler diario)
    activate GCF1
    GCF1 ->> GCS: reads / expands ZIPs
    GCS -->> GCF1: transaction inventory
    GCF1 ->> Staging: reads processed transactions
    Staging -->> GCF1: transaction status
    GCF1 ->> GCF1: reconcile (ZIP vs Staging)

    alt BACKUP_MISSING_IN_CONTROL
        GCF1 ->> API: reconciles missing transaction
        activate API
        API ->> Yoda: proxies
        deactivate API
        activate Yoda
        Yoda ->> Yoda: bin2raw (transforms)
        Yoda ->> Staging: writes transaction status
        Yoda ->> PubSub: publishes raw JSON
        Yoda ->> RDO: creates Digital Ticket
        Yoda ->> Staging: writes RDO delivery status
        deactivate Yoda
    end

    deactivate GCF1

%% SUBSET of sales-ecosystem-component.mmd — GCF_1 Reconciliador
%% Focus: Backup reconciliation flow (PoS backups → GCF_1 → API)

graph TB
    classDef system fill:#f5f5f5,stroke:#616161,stroke-width:4px,color:#000000;
    classDef karaf fill:#ffcdd2,stroke:#e30613,stroke-width:2px,color:#000000;
    classDef pos fill:#ffcdd2,stroke:#e30613,stroke-width:2px,color:#000000;
    classDef yoda fill:#dcedc8,stroke:#558b2f,stroke-width:2px,color:#000000;
    classDef gravitee fill:#dcedc8,stroke:#558b2f,stroke-width:2px,color:#000000;
    classDef gcf_monitor fill:#e3f2fd,stroke:#1565c0,stroke-width:6px,color:#000000;
    classDef gcs fill:#e3f2fd,stroke:#4285f4,stroke-width:2px,color:#000000;
    classDef gcf fill:#e3f2fd,stroke:#4285f4,stroke-width:2px,color:#000000;
    classDef staging fill:#d7ccc8,stroke:#5d4037,stroke-width:2px,color:#000000;
    classDef library fill:#fff9c4,stroke:#fbc02d,stroke-width:2px,color:#000000;

    subgraph POS_Stores ["PoS Servers"]
        direction TB
        POS_001["PoS Server - Store 001"]:::system
        POS_Sync_001("<i>«pos»</i><br/>PoS Transaction Sync"):::pos

        POS_002["PoS Server - Store XXX"]:::system
        POS_Sync_002("<i>«pos»</i><br/>PoS Transaction Sync"):::pos
    end

    API_POS{{"<i>«gravitee»</i><br/>PoS Transaction Sync API <br/> <code>Data v2 + RDO</code>"}}:::gravitee
    SFTP_Backup["sFTP PoS"]:::system
    ESB_Backup("<i>«karaf»</i><br/>PoS Transaction Backup<hr/><div style='text-align:left'>Raises:<br/>🚩 <font color='#b71c1c'>BACKUP_MISSING</font><br/>🚩 <font color='#b71c1c'>PHYSICAL_MISSING</font></div>"):::karaf
    GCS_Backup_Bucket[("<i>«gcs»</i><br/>PoS Transaction Backup Bucket")]:::gcs
    transaction_pos_backup_reconciler("<i>«gcf»</i><br/><b>transaction_pos_backup_reconciler</b><hr/><div style='text-align:left'>Detects:<br/>🚩 <font color='#b71c1c'>BACKUP_MISSING</font><br/>🚩 <font color='#b71c1c'>PHYSICAL_MISSING</font></div>"):::gcf_monitor
    Yoda_PoS("<i>«yoda»</i><br/>PoS Transaction Sync<br/> <code>Data v2 + RDO</code><hr/><div style='text-align:left'>Raises:<br/>🚩 <font color='#b71c1c'>RDO_PENDING</font></div>"):::yoda
    BQ_Staging[("<i>«gbq»</i><br/>Staging")]:::staging
    PubSub_PoS{{"<i>«pub/sub»</i><br/>Pending PoS Transactions" <br/> <code>Data v2</code>}}:::gcf
    API_RDO{{"<i>«gravitee»</i><br/>Digital Ticket API <br/> <code>RDO</code>"}}:::gravitee
    RDO["RDO"]:::system
    Jar_B2R["<i>«jar»</i><br/>bin2raw.jar"]:::library

    %% Core PoS Ingestion
    POS_001 -->|NRT transaction sync| POS_Sync_001
    POS_Sync_001 --> API_POS
    POS_002 -->|NRT transaction sync| POS_Sync_002
    POS_Sync_002 --> API_POS
    POS_Stores -->|batch transaction backup| SFTP_Backup

    %% Backup Pipeline
    SFTP_Backup -->|reads ZIPs| ESB_Backup
    ESB_Backup -->|stores ZIPs| GCS_Backup_Bucket

    %% GCF_1 Recovery
    GCS_Backup_Bucket -.->|expands ZIPs| transaction_pos_backup_reconciler
    transaction_pos_backup_reconciler -->|"reconciles PoS missing transaction"| API_POS
    transaction_pos_backup_reconciler <-->|read / write<br/>transaction status| BQ_Staging

    %% Yoda PoS Outputs
    API_POS -->|proxies| Yoda_PoS
    Yoda_PoS -->|creates or updates| API_RDO
    Yoda_PoS -->|publishes raw JSON| PubSub_PoS
    Yoda_PoS <-->|read / write<br/>transaction status| BQ_Staging

    %% Downstream
    API_RDO -->|creates or updates| RDO
    Yoda_PoS -.-|embeds| Jar_B2R

    %% Edge index: 0-15
    %% 0:POS_001->Sync  1:Sync->API  2:POS_002->Sync  3:Sync->API  4:POS->SFTP
    %% 5:SFTP->ESB  6:ESB->GCS  7:GCS-.->rec  8:rec->API  9:rec<->Stg
    %% 10:API->Yoda  11:Yoda->RDO_API  12:Yoda->PubSub  13:Yoda<->Stg
    %% 14:RDO_API->RDO  15:Yoda-.-B2R

    linkStyle 0,2,4,5 stroke:#616161,stroke-width:2px;
    linkStyle 1,3,6 stroke:#e30613,stroke-width:2px;
    linkStyle 7 stroke:#4285f4,stroke-width:2px,stroke-dasharray: 2 3;
    linkStyle 8,9 stroke:#1565c0,stroke-width:2px;
    linkStyle 10,11,12,13,14 stroke:#558b2f,stroke-width:2px;
    linkStyle 15 stroke:#fbc02d,stroke-width:1px,stroke-dasharray: 5 5;

El Supervisor: transaction_integrity_controller (GCF_2)

• Objetivo: Detectar tickets que, habiendo sido ingeridos, no llegaron al final (RDO) o están corruptos.
• Lógica de Detección:
  1. Consulta la tabla de control buscando estados inconsistentes (ej. first_row=true pero rdo_success_row=false o pubsub_success_row=false). (Indicadores: RDO_DELIVERY_FAILURE / PUBSUB_DELIVERY_FAILURE)
  2. Ejecuta vistas de calidad en Bronze (ej. cabeceras sin líneas). (Indicador: CORRUPTED_TICKET)
  3. Detecta paradas de flujo (Latido) si no hay entradas en un periodo de tiempo. (Indicador: PIPELINE_STALLED)
• Acción (Reprocesado):
  1. Para PoS: Llama a la API de Ventas PoS.
  2. Inserta en la tabla de control el registro con un "nuevo tipo" de estado para trazar la corrección.

%% RF01 — Sequence: GCF_2 Integridad PoS

sequenceDiagram
    autonumber

    participant Bronze as Bronze
    participant Silver as Silver
    participant GCF2 as transaction_integrity_controller
    participant Staging as Staging (Tabla de Control)
    participant API as API de Ventas PoS
    participant Yoda as Yoda PoS (bin2raw)
    participant PubSub as Pub/Sub (PoS)
    participant RDO as RDO
    participant Chat as Google Chat

    Note over GCF2: Auditoría PoS (scheduler periódico)
    activate GCF2
    GCF2 ->> Bronze: audit data integrity (header vs lines)
    Bronze -->> GCF2: anomalies
    GCF2 ->> Silver: audit master filtering (active stores)
    Silver -->> GCF2: context
    GCF2 ->> Staging: reads transaction status
    Staging -->> GCF2: pending / failed states
    GCF2 ->> GCF2: detect anomalies

    alt CORRUPTED_TICKET / RDO_DELIVERY_FAILURE
        GCF2 ->> API: reprocesses failed transaction
        activate API
        API ->> Yoda: proxies
        deactivate API
        activate Yoda
        Yoda ->> Yoda: bin2raw (re-transforms)
        Yoda ->> Staging: updates transaction status
        Yoda ->> PubSub: re-publishes raw JSON
        Yoda ->> RDO: re-creates Digital Ticket
        deactivate Yoda
    end

    opt Critical errors
        GCF2 ->> Chat: notifies via webhook
    end

    GCF2 ->> Staging: writes audit result
    deactivate GCF2

%% SUBSET of sales-ecosystem-component.mmd — GCF_2 Supervisor (PoS scope)
%% Focus: Integrity audit + PoS reprocessing flow

graph TB
    classDef system fill:#f5f5f5,stroke:#616161,stroke-width:4px,color:#000000;
    classDef yoda fill:#dcedc8,stroke:#558b2f,stroke-width:2px,color:#000000;
    classDef gravitee fill:#dcedc8,stroke:#558b2f,stroke-width:2px,color:#000000;
    classDef gcf_monitor fill:#e3f2fd,stroke:#1565c0,stroke-width:6px,color:#000000;
    classDef gcf fill:#e3f2fd,stroke:#4285f4,stroke-width:2px,color:#000000;
    classDef middleware fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:#000000;
    classDef bronze fill:#ffe0b2,stroke:#bf360c,stroke-width:2px,color:#000000;
    classDef silver fill:#eeeeee,stroke:#616161,stroke-width:2px,color:#000000;
    classDef staging fill:#d7ccc8,stroke:#5d4037,stroke-width:2px,color:#000000;
    classDef library fill:#fff9c4,stroke:#fbc02d,stroke-width:2px,color:#000000;

    transaction_integrity_controller("<i>«gcf»</i><br/><b>transaction_integrity_controller</b><hr/><div style='text-align:left'>Detects:<br/>🚩 <font color='#b71c1c'>NO_ITEMS / CORRUPT</font><br/>🚩 <font color='#b71c1c'>RDO_PENDING</font><br/>🚩 <font color='#b71c1c'>PIPELINE_STALLED</font></div>"):::gcf_monitor
    Google_Chat{{"Google Chat"}}:::middleware

    BQ_Bronze[("<i>«gbq»</i><br/>Bronze")]:::bronze
    BQ_Silver[("<i>«gbq»</i><br/>Silver")]:::silver
    BQ_Staging[("<i>«gbq»</i><br/>Staging")]:::staging

    API_POS{{"<i>«gravitee»</i><br/>PoS Transaction Sync API <br/> <code>Data v2 + RDO</code>"}}:::gravitee
    Yoda_PoS("<i>«yoda»</i><br/>PoS Transaction Sync<br/> <code>Data v2 + RDO</code><hr/><div style='text-align:left'>Raises:<br/>🚩 <font color='#b71c1c'>RDO_PENDING</font></div>"):::yoda
    PubSub_PoS{{"<i>«pub/sub»</i><br/>Pending PoS Transactions" <br/> <code>Data v2</code>}}:::gcf
    API_RDO{{"<i>«gravitee»</i><br/>Digital Ticket API <br/> <code>RDO</code>"}}:::gravitee
    RDO["RDO"]:::system
    Jar_B2R["<i>«jar»</i><br/>bin2raw.jar"]:::library

    %% GCF_2 Audit Inputs
    BQ_Silver -.->|"master filtering<br/>(active store context)"| transaction_integrity_controller
    BQ_Bronze -.->|"data integrity<br/>(header vs lines join)"| transaction_integrity_controller
    transaction_integrity_controller <-->|manages status <br/>+<br/> audit| BQ_Staging

    %% GCF_2 Recovery Actions (PoS)
    transaction_integrity_controller -->|notifies critical errors| Google_Chat
    transaction_integrity_controller -->|"reprocesses PoS<br/>(failed transactions)"| API_POS

    %% Yoda PoS outputs
    API_POS -->|proxies| Yoda_PoS
    Yoda_PoS -->|creates or updates| API_RDO
    Yoda_PoS -->|publishes raw JSON| PubSub_PoS
    Yoda_PoS <-->|read / write<br/>transaction status| BQ_Staging

    %% Downstream
    API_RDO -->|creates or updates| RDO
    Yoda_PoS -.-|embeds| Jar_B2R

    %% Edge index: 0-10
    %% 0:Silver-.->integ  1:Bronze-.->integ  2:integ<->Stg
    %% 3:integ->Chat  4:integ->API  5:API->Yoda
    %% 6:Yoda->RDO_API  7:Yoda->PubSub  8:Yoda<->Stg
    %% 9:RDO_API->RDO  10:Yoda-.-B2R

    linkStyle 0 stroke:#616161,stroke-width:2px,stroke-dasharray: 2 3;
    linkStyle 1 stroke:#bf360c,stroke-width:2px,stroke-dasharray: 2 3;
    linkStyle 2,3,4 stroke:#1565c0,stroke-width:2px;
    linkStyle 5,6,7,8,9 stroke:#558b2f,stroke-width:2px;
    linkStyle 10 stroke:#fbc02d,stroke-width:1px,stroke-dasharray: 5 5;

B. Subsistema eCommerce (Pub/Sub (eCom))

El enfoque se alinea con PoS para mantener coherencia. Es un caso particular de la transaction_integrity_controller (GCF_2). No desarrollamos una función nueva — configuramos y reutilizamos.

• Monitorización:
  • Cíclico de 2-3 días: Comparar la tabla de control de eCom contra una vista del Ocado Datafeeds (todos los pedidos pagados en los últimos días). (Indicador: MISSING_ORDER_BRONZE)
  • Monitorizar que haya movimiento ("Latido") en la tabla de control para evitar fallos silenciosos de colas caídas. (Indicador: PIPELINE_STALLED)

• Reprocesado:

  • Si detectamos inconsistencia, la Google Cloud Function publica directamente en Pub/Sub (eCom) el contenido extraído de la tabla de control o invoca la API de Pedidos enriqueciendo con información del Ocado Datafeeds.
  • Contenido API ejemplo (siempre mismo startDate y endDate de 1 día):

  {
      "startDate": "2025-06-29",
      "endDate": "2025-06-29",
      "onlyNewOrders": true
  }
  

%% RF01 — Sequence: GCF_2 Integridad eCom

sequenceDiagram
    autonumber

    participant Ocado as Ocado Datafeeds
    participant GCF2 as transaction_integrity_controller
    participant Staging as Staging (Tabla de Control)
    participant PubSub as Pub/Sub (eCom)
    participant Chat as Google Chat

    Note over GCF2: Auditoría eCom (scheduler periódico)
    activate GCF2
    GCF2 ->> Ocado: audit eCom (returns & subscriptions)
    Ocado -->> GCF2: gap analysis results
    GCF2 ->> Staging: reads eCom transaction status
    Staging -->> GCF2: pending / missing orders
    GCF2 ->> GCF2: detect anomalies

    alt MISSING_ORDER_BRONZE
        GCF2 ->> PubSub: publishes eCom JSON (reprocess)
        activate PubSub
        deactivate PubSub
    end

    opt Critical errors
        GCF2 ->> Chat: notifies via webhook
    end

    GCF2 ->> Staging: writes audit result
    deactivate GCF2

%% SUBSET of sales-ecosystem-component.mmd — GCF_2 Supervisor (eCom scope)
%% Focus: eCom gap analysis + reprocessing flow

graph TB
    classDef system fill:#f5f5f5,stroke:#616161,stroke-width:4px,color:#000000;
    classDef yoda fill:#dcedc8,stroke:#558b2f,stroke-width:2px,color:#000000;
    classDef gcf_monitor fill:#e3f2fd,stroke:#1565c0,stroke-width:6px,color:#000000;
    classDef gcf fill:#e3f2fd,stroke:#4285f4,stroke-width:2px,color:#000000;
    classDef middleware fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:#000000;
    classDef bronze fill:#ffe0b2,stroke:#bf360c,stroke-width:2px,color:#000000;
    classDef staging fill:#d7ccc8,stroke:#5d4037,stroke-width:2px,color:#000000;
    classDef ocado_db fill:#37474f,stroke:#263238,stroke-width:2px,color:#ffffff;

    Ocado["Ocado"]:::system
    Yoda_eCom("<i>«yoda»</i><br/>Ocado Orders Sync<hr/><div style='text-align:left'>Raises:<br/>🚩 <font color='#b71c1c'>PIPELINE_STALLED</font><br/>🚩 <font color='#b71c1c'>GAP_ANALYSIS</font></div>"):::yoda

    transaction_integrity_controller("<i>«gcf»</i><br/><b>transaction_integrity_controller</b><hr/><div style='text-align:left'>Detects:<br/>🚩 <font color='#b71c1c'>GAP_ANALYSIS</font><br/>🚩 <font color='#b71c1c'>PIPELINE_STALLED</font><br/>🚩 <font color='#b71c1c'>DATAFEED_MISSING</font></div>"):::gcf_monitor
    Google_Chat{{"Google Chat"}}:::middleware

    PubSub_eCom{{"<i>«pub/sub»</i><br/>Pending eCom Orders"}}:::gcf
    Dataflow("<i>«process»</i><br/>Dataflow"):::middleware

    BQ_Ocado[("<i>«gbq»</i><br/>Ocado Datafeeds")]:::ocado_db
    BQ_Staging[("<i>«gbq»</i><br/>Staging")]:::staging
    BQ_Bronze[("<i>«gbq»</i><br/>Bronze")]:::bronze

    %% Normal eCom flow (context)
    Ocado -->|GET /orders| Yoda_eCom
    Yoda_eCom -->|publishes eCom JSON| PubSub_eCom
    Yoda_eCom <-->|read / write<br/>transaction status| BQ_Staging

    %% GCF_2 Audit (eCom)
    BQ_Ocado -.->|"eCom audit<br/>(returns & subscriptions)"| transaction_integrity_controller
    transaction_integrity_controller <-->|manages status <br/>+<br/> audit| BQ_Staging

    %% GCF_2 Recovery Actions (eCom)
    transaction_integrity_controller -->|notifies critical errors| Google_Chat
    transaction_integrity_controller -->|"reprocesses eCom<br/>(publishes eCom JSON)"| PubSub_eCom

    %% Data Pipeline
    PubSub_eCom -->|subscribes to| Dataflow
    Dataflow -->|writes models| BQ_Bronze
    Dataflow -->|saves transaction info| BQ_Staging

    %% Edge index: 0-9
    %% 0:Ocado->Yoda  1:Yoda->PubSub  2:Yoda<->Stg
    %% 3:Ocado_DB-.->integ  4:integ<->Stg
    %% 5:integ->Chat  6:integ->PubSub
    %% 7:PubSub->DF  8:DF->Bronze  9:DF->Stg

    linkStyle 0 stroke:#616161,stroke-width:2px;
    linkStyle 1,2 stroke:#558b2f,stroke-width:2px;
    linkStyle 3 stroke:#263238,stroke-width:2px,stroke-dasharray: 2 3;
    linkStyle 4,5,6 stroke:#1565c0,stroke-width:2px;
    linkStyle 7 stroke:#4285f4,stroke-width:2px;
    linkStyle 8,9 stroke:#01579b,stroke-width:2px;

C. Tratamiento de Casos Específicos

• Duplicados PoS: Decisión: Eliminar el procedimiento almacenado actual en BigQuery. La deduplicación ya se realiza en Silver y ningún consumidor accede directamente a Bronze, por lo que mantenerlo es innecesario.
• Fallos de Dataflow: Decisión: Se cubren con la lógica de "Integridad Estructural" de la transaction_integrity_controller. Detectar cabeceras sin líneas en Bronze y reprocesar.
• Datafeed de Devoluciones y Suscripciones: Decisión: Cubierto por la lógica de la transaction_integrity_controller. La función de integridad debe poder procesar estos flujos, aunque su monitorización específica sea RF06/RF08.
• Gasolineras: Decisión: Cubierto por la lógica de la transaction_integrity_controller. La arquitectura aplica, aunque su instanciación final la realizará el proyecto de Gasolineras.

Fuera de Alcance

Resumen de Diferencias Clave