Extensibilidad de FieldSets
El mecanismo de extensión más potente de REDA Financials no requiere código y sobrevive a cada actualización: los conjuntos de campos (field sets). Agrega tu campo personalizado al conjunto correcto y aparecerá en los formularios de captura, viajará hasta el libro mayor, filtrará los informes e imprimirá en los PDFs — las pantallas y los motores del paquete leen los conjuntos en tiempo de ejecución. Se distribuyen más de cuarenta conjuntos en los objetos transaccionales, agrupados en tres familias.
Las tres familias
| Familia | Dónde aparece | Uso típico |
|---|---|---|
| Interface | Columnas/campos adicionales en los formularios de captura empaquetados (líneas de factura, líneas de asiento, formularios de recibo…) | Las dimensiones de tu industria — Meridian agregó Property__c a las líneas de factura; aparece en la cuadrícula del formulario como si hubiera nacido ahí (y el mismo conjunto de líneas incluso extiende las líneas de plantillas recurrentes) |
| Posting_Mapping | Traslada los valores de dimensión de los documentos a las Transacciones contables — y de ahí a los filtros de informes, los drill-downs y las aplicaciones con coincidencia de dimensiones | El mismo Property__c fluyendo hasta el libro mayor para poder generar el estado de resultados por propiedad |
| Plantilla PDF | Filas de encabezado / detalles de línea adicionales en los documentos generados (más detalles) | Método de pago en los recibos, códigos de proyecto en las facturas |
Además del conjunto Account Ledger en Transacción contable — columnas adicionales para los mayores de cuenta de terceros y sus extractos.
La razón por la que esto funciona: los conjuntos de campos en objetos administrados quedan deliberadamente editables por el administrador a nivel de plataforma. Tus ediciones de membresía son metadatos de la org — el paquete lee lo que contengan los conjuntos en tiempo de ejecución, y por eso este es el mecanismo de extensibilidad sin código principal, y por eso sobrevive intacto a cada actualización.
La receta de extremo a extremo (una dimensión nueva en ~15 minutos)
Crea el campo donde se captura — y donde llega
El campo personalizado en la línea del documento (por ejemplo, Property en Línea de factura de venta) y un campo con el mismo nombre de API en Transacción contable. Que los nombres de API coincidan es el contrato que permite que los valores fluyan.
Agrégalo a Interface (captura) y a Posting_Mapping (flujo)
Administrador de objetos → Conjuntos de campos → arrastra el campo hacia adentro. El formulario lo muestra de inmediato; las contabilizaciones empiezan a llevarlo; la sección Dimensiones del panel de informes y los drill-downs lo detectan automáticamente.
Opcionalmente: imprímelo, fíltralo, empárejalo
Conjunto PDF Template → se imprime. Aparece entre los filtros de dimensión de los informes. Y las funciones que reconocen dimensiones (coincidencia de aplicaciones, cierre de año con alcance por dimensión) lo tratan como si fuera el centro de costos nativo.
En palabras del propio paquete
Los conjuntos de campos se documentan a sí mismos — sus descripciones empaquetadas son la intención de diseño, palabra por palabra. El conjunto Interface de Línea de factura de venta dice: "Add client-specific accounting dimensions here (e.g. Property__c, Cost_Centre__c, Sub_Property__c)" — esas son solo las ilustraciones que trae el paquete; los mismos espacios aceptan cualquier dimensión que tu industria rastree (centros de costos, proyectos, departamentos, fondos), que es exactamente como una firma como Meridian los usa para propiedades. Se distribuyen cuarenta y tres conjuntos de campos en los objetos transaccionales; el patrón se repite por objeto, de modo que el formulario, el flujo de contabilización y el PDF de cada tipo de documento son extensibles de forma independiente.
Dos contratos están detrás de los conjuntos — uno en las descripciones empaquetadas, otro en el propio motor — y vale la pena expresarlos con claridad:
- La coincidencia de nombres es la plomería. El flujo de contabilización mapea por nombre de API — y lo mismo hace la coincidencia de aplicaciones: cuando entran en juego las aplicaciones con coincidencia de dimensiones, el motor exige que "los nombres de API coincidan entre los dos FieldSets de Posting_Mapping" de los documentos que se están emparejando. Un campo, un nombre, en todas partes.
- Las columnas estándar quedan afuera. Los conjuntos Interface son solo para tus adiciones; las columnas empaquetadas ya son renderizadas por los formularios, y volver a agregarlas duplica la columna.
La dimensión Property de Meridian, en todas partes a la vez
Un solo campo personalizado — Property__c — agregado según la receta anterior, y aquí está en todas partes donde ahora aparece sin invertir otro minuto de configuración:
| Superficie | Lo que ve Meridian |
|---|---|
| Formulario de factura de venta | Una columna Property en la cuadrícula de líneas, poblada por línea de renta |
| Plantillas recurrentes | La misma columna en las líneas de la plantilla — el conjunto Interface de la línea extiende ambas, así que la plantilla de renta mensual también lleva la propiedad |
| El libro mayor | La Transacción contable de cada línea contabilizada lleva el valor de la propiedad (Posting_Mapping) |
| Informes | Property aparece entre los filtros de dimensión — estado de resultados por edificio, drill-down incluido |
| PDFs generados | La propiedad se imprime en las facturas de los inquilinos (conjunto PDF Template) |
| Extracción con IA | El catálogo de campos de OCR la incluye — las facturas de proveedores cargadas pueden tener la propiedad completada por la IA cuando el documento la implica |
Errores comunes que hay que evitar
| Error | Por qué perjudica | Haz esto en su lugar |
|---|---|---|
| Nombres de API distintos entre el campo del documento y su gemelo en Transacción contable | La asignación se hace por nombre — los valores se detienen silenciosamente en el documento y nunca llegan al libro mayor | Crea ambos campos con nombres de API idénticos antes de tocar los conjuntos |
| Agregarlo a Interface pero no a Posting_Mapping | Los usuarios completan fielmente un campo que nunca llega a los informes — se descubre al cierre de mes | Piensa en pares: captura (Interface) y flujo (Posting_Mapping) juntos |
| Volver a agregar columnas estándar a un conjunto Interface | Las columnas duplicadas en la cuadrícula confunden al formulario | Los conjuntos Interface llevan únicamente tus campos |
| Renombrar un campo de dimensión después de meses de contabilizaciones | Las filas antiguas del libro mayor conservan el campo anterior; los informes dividen una dimensión en dos | Elige los nombres con el mismo cuidado que las cuentas contables; renombrar es un proyecto de migración de datos, no una edición |
| Saltarse la conversación sobre campos obligatorios | Los conjuntos de campos hacen que los campos estén disponibles, no obligatorios — las dimensiones opcionales terminan pobladas al 60% | Combina el cambio en el conjunto de campos con validaciones o un proceso de equipo que haga confiable la dimensión |
Qué sigue
- Columnas de PDF impulsadas por FieldSets — la familia de impresión en profundidad.
- Dimensiones de contabilización — la teoría contable de las dimensiones.
- Lightning Web Components — cuando los conjuntos de campos no bastan.
Preguntas frecuentes
Los formularios empaquetados son interfaces personalizadas (cuadrículas, asistentes), no diseños de página estándar — los conjuntos de campos son la forma en que un paquete administrado permite extender las pantallas que le pertenecen. Misma idea, superficies más ricas: formularios, motores, informes y PDFs los leen todos.
Sí — tus ediciones de membresía son metadatos de la org, y se preservan entre versiones del paquete. Precisamente por eso es la vía de extensión recomendada.
Técnicamente es generoso; en la práctica, cada dimensión es un campo que los usuarios deben completar y que los informes deben desglosar. Dos o tres dimensiones bien gobernadas superan a ocho medio pobladas — es una decisión de política contable más que técnica.
Sin código, sin implementación: es apuntar y hacer clic en el Administrador de objetos, y tiene efecto de inmediato. Aun así, gestiónalo como un cambio de configuración: primero en sandbox, porque un formulario en producción gana una columna en el momento en que guardas.
Interface — los mismos conjuntos que extienden los campos del formulario de Factura de compra son los que lee la IA al construir su catálogo de campos, de modo que extender el formulario le enseña automáticamente al extractor sobre el nuevo campo. Una sola definición, todos los consumidores.
Sí. Cualquier campo personalizado que hayas agregado que no forme parte del conjunto de campos de Posting Mapping permanece editable en todos los estados — borrador, contabilizado, anulado e incluso revertido. REDA bloquea únicamente sus propios campos, los campos estándar y cualquier campo que hayas convertido en una dimensión de contabilización (esos se escriben en el libro mayor cuando el registro se contabiliza, por lo que quedan congelados junto con él). Las marcas simples, las notas y las claves de integración se pueden modificar en cualquier momento. Una precisión: “tuyos” significa campos del espacio de nombres de tu propia organización. Un campo personalizado que llega desde otro paquete gestionado instalado lleva espacio de nombres, así que la protección lo trata como gobernado y no como libre.
¿Te resultó útil?