Esta vista es la Caja 1 (transaction-definitions): define qué transacciones existe en cada dominio y cómo se crea cada tabla. Es el insumo de la Caja 2 (genera los .sql) y la documentación viva de Beat.

Creación — el código de color (verde / amarillo)

Es la pregunta central: ¿cómo nace la fila? De ahí sale si Beat copia el SQL directo o si hay que inferirlo. Aplica a toda tabla in-scope, dims incluidas.

• 🟢 verde — un SP hace INSERT INTO la tabla. Beat copia el INSERT desde el dacpac: determinista, cero IA.
• 🟡 amarillo — lo crea el ORM de la aplicación; ningún SP inserta. No hay un INSERT que copiar → el insert se infiere.

Un dim también es verde o amarillo: p.ej. ATC/DCI son verde porque SP_SaveATC/SP_SaveDCI insertan; Warehouse o Manufacturer son amarillo (los crea el ORM). Que sea dim es su rol (columna Bucket), no su color de creación.

Estado

• ✓ in scope — Beat la genera (write-path + maestros).
• ⏭ skip — fuera de alcance, con su razón: D.1 muerta en parque (0 filas) · D.2 reubicada a otro dominio · D.3 read-only (sin SP escritor) · D.4 tabla temporal.

Bucket — el rol de la tabla en el documento

• cabecera — raíz del documento = un botón del FE.
• detalle — líneas hijas 1:N de la cabecera (anidan por nivel).
• side — side-effect transversal (p.ej. Kardex, stock).
• otra — sub-acción sin botón FE propio (se embebe en el padre).
• dim — maestro/catálogo.

Silver — cómo se consolida el documento

• Silver doc — a qué documento Silver (transacción) pertenece la tabla.
• Silver path — dónde va dentro del documento (JSONPath): $ = raíz (cabecera), $.lineas[] = array de detalle, embed = inline {id, codigo, nombre}.
• patrón — la forma del documento: A_plano, A_plus, B_anidado, B_complejo, C_referencia, C_mas_B, C_ref_por_lote, D_paciente_centrico, E_sub_accion, transversal.

Qué preguntas responde (= el output de transaction-definitions)

• Embudo — cuántas físicas hay y cuántas entran en scope (cards de arriba).
• Conteo — cuántas verde / amarillo / dims por dominio (cards).
• Generación — el split 🟢/🟡: qué se genera directo vs. qué se infiere.
• Fuera de scope — qué queda afuera y por qué (filas skip, razón D.x).
• Capas — proyección + silver (path/patrón), en el detalle de cada fila.

Haz clic en cualquier fila para ver su detalle: dim_refs, SPs, silver, parent/nivel y patrón Silver.

Convierte una vista de SQL Server (VieCloud) a Microsoft Fabric por reescritura AST determinista — mismo input, mismo output, sin IA. Es el motor P3 (goForge portado a Beat).

Cómo se usa

• Pegá una vista (CREATE VIEW … AS SELECT …).
• Elegí destino (Lakehouse default / Warehouse).
• (opcional) nombre del lakehouse — si no, se infiere del SQL.
• Transformar → devuelve el SQL Fabric + warnings.

Qué hace en la reescritura

• Flatten a landing ([dbo].[X] → LH_….MIRR_LANDING_INDIGO051.dbo_X).
• VW_ prefix + CREATE OR ALTER.
• Inyecta '051' AS SOURCE.
• Normaliza columnas con espacios/acentos ([Centro Costo] → Centro_Costo).
• Resuelve cross-db / cross-lakehouse.
• Agrega la unión histórica (UNION ALL … HISTORICAL_050.TBL_…) solo si existe el snapshot (si no, queda live-only).

Warnings y ship

• Los warnings son info (qué se reescribió), no errores.
• "sin errores bloqueantes — seguro para ship" = la vista está lista.
• Modo lote: adjuntá una carpeta/.zip de vistas → Transformar lote → Shipear lote (crea cada vista en Fabric como el usuario, OBO) → Reintentar fallidas. Las vistas se crean con CREATE OR ALTER VIEW (idempotente: re-shipear sobreescribe, no duplica).

Categorías de error al shipear

Cuando una vista no queda ejecutable, la columna Categoría te dice por qué y de quién es la pelota:

• 🔧 Transpilador — bug determinista del transpilador. Se corrige en código; reintentable tras el fix. (Nuestra pelota.)
• ⛓ Cascada — depende de otra vista del lote que falló. Se desbloquea sola al arreglar la raíz.
• 📦 Mirror — referencia una tabla/columna que está en el DACPAC pero falta en el mirror (MIRR_LANDING_INDIGO051). Hay que completar el mirror. (Pelota de datos, no del transpilador.)
• ⚠ Fuente — problema del SQL fuente: PIVOT no materializado, columna ambigua, u objeto ad-hoc que ni está en el DACPAC.
• ✋ Excluida — no migrable por diseño (OPENQUERY / linked server / procedural). No se reintenta.
• ↻ Conexión — transitorio / infra (caída de conexión, throttle). Reintentar.

El resumen agrupa el conteo por categoría; Reintentar fallidas solo reintenta las accionables por nosotros (transpilador / cascada / conexión), no mirror ni excluidas.

El modo convierte un script T-SQL Server en una vista o SP parametrizado dentro de un workspace Fabric que vos elegís (BYO). Generar compila y te muestra el SQL sin tocar Fabric; Shipear lo escribe (y corre paridad como gate).

Los tres campos del mapa de bases

Son las tres partes del nombre final:

tu SQL:     INDIGO102 . dbo . AGASICITA
               [1]      └──────┬──────┘
                               │  el schema se concatena a la tabla
                               ▼
resultado:  LH_MEDILASER_ANALYTICS . MIRR_LANDING_INDIGO051 . dbo_AGASICITA
                     [2]                      [3]

• [1] DB original — lo que dice tu SQL. Se detecta solo del texto (en lote se tipea a mano).
• [2] DB target — el item de Fabric (lakehouse/warehouse) donde viven los datos.
• [3] Landing schema (opcional) — el schema dentro de ese item donde el espejo aterriza.

Por qué existe el landing schema

Un espejo de Fabric no reproduce los schemas del origen: aterriza todas las tablas de la base en un schema y pliega el schema fuente dentro del nombre de la tabla. Por eso el espejo no tiene dbo y, sin landing, Fabric responde Invalid object name (208).

Varios schemas → un solo landing

El landing es por base, no por schema. Tabla (verificada en Fabric real):

El detalle fino: DBO/Dbo/dbo siempre salen como dbo_; cualquier otro schema conserva su caso (Contract → Contract_). No es un capricho: las tablas Delta en Fabric son case-sensitive, así que igualar el casing real del espejo es lo que evita un 208.

Varias bases

Si tu SQL referencia otra base (p. ej. ReportesAsistenciales.dbo.Tiempo), necesita su propia fila con su propio landing — es otro espejo. Botón ＋ agregar base.

Destino ≠ DB target

• Destino (arriba) = dónde se crea la vista/SP.
• DB target (el mapa) = de dónde se leen los datos.

Pueden ser el mismo item y está bien: la vista se crea en LH.dbo y lee de LH.MIRR_LANDING_INDIGO051.

Origen SQL Server (paridad) — no confundir

Ese campo es solo para comparar contra el SQL Server de producción (paridad/validación). No va un item de Fabric ahí. Si no querés paridad, dejalo vacío.

Qué NO se transpila

Funciones escalares del origen (p. ej. INDIGO102.dbo.Edad(...)) no existen en Fabric: los espejos replican tablas, no funciones. Hay que inline-arlas o crearlas en el destino. Lo procedural (WHILE/cursores/@table) está fuera de alcance y se reporta, nunca se adivina.