3. El Diccionario de Aplicación

El Diccionario de Aplicación (Application Dictionary, AD) es la idea más importante para entender iDempiere y, por extensión, cómo FINORA agrega funcionalidad sin tocar el core: casi toda la estructura del ERP —qué tablas existen, qué ventanas las muestran, qué campos tiene cada pestaña, qué procesos se pueden correr— es información guardada en la propia base de datos, no código Java fijo. Es un “diccionario activo”: cambiarlo cambia el comportamiento del sistema sin recompilar nada.

La consecuencia práctica

Cuando FINORA LVE agrega una columna a C_Invoice o una tabla nueva como FVE_TaxUnit, no edita ningún archivo .java del core: inserta filas en AD_Table, AD_Column, AD_Window, etc. El core las lee igual que lee las suyas, porque para el core todas las tablas se definen de la misma forma (ver Tutorial 8 sobre cómo se entregan esas filas).

Las piezas centrales

erDiagram
    AD_TABLE ||--o{ AD_COLUMN : tiene
    AD_TABLE ||--o{ AD_WINDOW_TAB : "se muestra en"
    AD_WINDOW ||--o{ AD_WINDOW_TAB : contiene
    AD_WINDOW_TAB ||--o{ AD_FIELD : contiene
    AD_FIELD }o--|| AD_COLUMN : referencia
    AD_COLUMN }o--o| AD_REFERENCE : "usa (tipo de dato / lista)"
    AD_TABLE ||--o{ AD_PROCESS : "puede disparar"

• AD_Table: una fila por tabla física (C_Invoice, C_BPartner, la nueva FVE_TaxUnit). Guarda el nombre de la tabla, el nivel de acceso (ver Tutorial 4), y de qué clase Java se genera el modelo (X_<Tabla> autogenerada, M<Tabla> la que se extiende a mano).
• AD_Column: una fila por columna de esa tabla — nombre físico, tipo de dato, si es obligatoria, su valor por defecto, y opcionalmente a qué AD_Reference apunta (por ejemplo, una columna que solo puede valer IVA/ISLR/MUN referencia una Lista de esos tres valores). El core lee las columnas de una tabla desde AD_Column, no desde una anotación en el código: por eso una columna nueva que el core no conoce simplemente la ignora sin romperse (finora-lve/docs/ARCHITECTURE.md, §3.2).
• AD_Window / AD_Tab / AD_Field: una ventana (AD_Window) tiene una o más pestañas (AD_Tab, cada una apuntando a una AD_Table y opcionalmente anidada bajo otra pestaña por clave foránea — así Business Partner tiene pestañas hijas Location, Contact, Bank Account). Cada pestaña tiene una lista de campos (AD_Field), cada uno apuntando a una AD_Column y agregando cosas propias de la pantalla: orden, si es de solo lectura, lógica de visualización condicional (DisplayLogic).
• AD_Reference: define cómo se edita y se muestra un tipo de dato — no solo tipos simples (String, Integer, Date, Amount), sino también Listas (List, con sus AD_Ref_List de valores), Tablas (Table/TableDir, un combo que busca en otra tabla, como elegir un Business Partner desde una factura) y Búsquedas (Search). El editor que ve la persona usuaria en ZK (input de texto, combo, calendario, buscador con lupa) se decide por el AD_Reference de la columna, no por código escrito a mano en cada pantalla (ver Tutorial 5).
• AD_Process: un proceso o reporte ejecutable desde el menú, un botón de ventana o la API REST — desde un simple reporte SQL hasta una clase Java (SvrProcess) con lógica compleja, como el motor de retenciones de FINORA LVE (ver Tutorial 9).

Un ejemplo real: FVE_TaxUnit

FINORA LVE necesita guardar el valor histórico de la Unidad Tributaria (UT) venezolana, con vigencia por fecha. En vez de escribir una tabla ad-hoc fuera del Diccionario, se define como una tabla más:

• AD_Table — FVE_TaxUnit, EntityType='FVE' (así se distingue de un vistazo lo propio de FINORA de lo del core; ver Tutorial 8).
• AD_Column — ValidFrom (fecha), Amt (monto), FVE_LegalSource (texto: la Gaceta que respalda el valor).
• Una clase generada X_FVE_TaxUnit (autogenerada a partir del Diccionario, con getters/setters tipados) y una clase MTaxUnit que la extiende con lógica propia — el mismo patrón X_/M que usa el core para todas sus tablas.

finora-lve/plugins/com.finora.lve.base/src/com/finora/lve/base/model/X_FVE_TaxUnit.java

// (generada a partir del Diccionario: getters/setters por columna, sin lógica de negocio)
public class X_FVE_TaxUnit extends PO implements I_FVE_TaxUnit {
    public void setAmt (java.math.BigDecimal Amt) { ... }
    public java.math.BigDecimal getAmt() { ... }
    public void setValidFrom (java.sql.Timestamp ValidFrom) { ... }
    // ...
}

No hace falta escribir un DAO, un mapeo objeto-relacional ni una migración SQL manual: el proceso de importar el Diccionario (2Pack, Tutorial 8) crea la tabla física y sincroniza sus columnas.

Por qué esto hace posible la API REST genérica

El plugin idempiere-rest puede exponer cualquier tabla en /api/v1/models/{tabla} sin conocer de antemano qué tablas existen, porque le pregunta al Diccionario: qué columnas tiene, cuáles son obligatorias, a qué referencia apunta cada una. Por eso una tabla nueva de FINORA LVE queda disponible por REST automáticamente en cuanto su 2Pack se aplica — no hay que escribir un controlador ni una ruta a mano (ver Tutorial 10).

Fuentes

• Application Dictionary — ADempiere Wikiversity
• Application Dictionary - Create a Custom Table and Window — wiki.idempiere.org
• finora-lve/docs/ARCHITECTURE.md, §3.2 (tablas y columnas nuevas, niveles de acceso)
• finora-lve/plugins/com.finora.lve.base/src/com/finora/lve/base/model/X_FVE_TaxUnit.java