Casos de uso

Documentos que sostienen negocios reales.

Pagr nació de proyectos con clientes, no de un pitch deck. Estas son las formas de documento para las que se creó — y las plantillas listas para empezar si el tuyo se parece a alguna.

En producción

Un resumen patrimonial para cada cliente, en manos del corredor.

DORI es la plataforma con la que los corredores de seguros belgas pueden gestionar su oficina: fichas de clientes, contratos, cumplimiento y el portal del cliente en un mismo sitio. Metanous la desarrolló, y la sigue manteniendo.

La plataforma genera muchos tipos de documentos, entre ellos el vermogensoverzicht: un resumen de todo lo que tiene un cliente. Es distinto para cada cliente. Un número distinto de contratos, otros productos, otros totales, y textos legales que solo se aplican a algunos. No es un formulario al que se le cambia el nombre — la forma del documento sigue a los datos.

Y quienes son dueños de ese documento son corredores, no desarrolladores. Cuando un regulador cambia la redacción obligatoria, o una oficina quiere su propia marca en el resumen, eso no puede depender de una release. Así que DORI necesitaba dos cosas a la vez: PDF generados a demanda a partir de los datos de cada cliente, y una plantilla que alguien sin perfil técnico pudiera cambiar de verdad.

Esa combinación es una de las razones por las que Pagr existe. Fue el motor detrás de documentos como este mucho antes de ser un producto.

Por qué creamos Pagr →

Lo que este documento tiene que hacer

✓Tablas que crecen con el número de contratos que tiene un cliente

✓Gráficos y totales calculados por cliente, no fijados en la plantilla

✓Párrafos legales que aparecen solo cuando corresponden

✓La marca propia de cada oficina en el mismo resumen

✓Generado a demanda desde la plataforma, e idéntico cada vez

vermogensoverzicht — portada

vermogensoverzicht — un producto en detalle

Dos páginas de un vermogensoverzicht, generado por Pagr. Los nombres y los importes son datos de ejemplo; la maquetación, el gráfico de valor por cliente y las líneas fiscales que solo aparecen cuando corresponden salen de la plantilla real.

Más casos de uso

El mismo problema, en cuatro sectores más.

Documentos distintos, los mismos dos requisitos: la maquetación tiene que seguir a los datos, y quien es dueño del texto tiene que poder cambiarlo.

Cumplimiento regulado

Certificados que va a leer un regulador

Una maquetación legal fija rellenada con datos que cambian según el edificio: una puntuación en una escala, una foto de la fachada, observaciones que se aplican a unos inmuebles y a otros no. La redacción está prescrita, así que la plantilla tiene que ser exacta, y cambia cuando cambian las normas.

✓Campos condicionales: las observaciones y exenciones se renderizan solo si existen

✓Fotos por URL; códigos de barras generados desde el valor de tu JSON, no enviados como imagen

✓Una versión de plantilla fijada por llamada, para que un certificado reemitido coincida con el original

Volumen

Facturas al ritmo en que se cierran transacciones

La facturación es donde el volumen aparece primero: una factura por transacción, un abono por devolución y un extracto por cliente y mes, todos a la vez el día uno.

✓Una llamada síncrona en la ruta de la petición, o un trabajo en cola con webhook firmado para el cierre mensual

✓Estado por documento, para que un registro mal formado no tumbe el lote

✓Finanzas cambia la redacción del IVA o un pie de página sin despliegue

Personas y RR. HH.

Contratos que RR. HH. cambia por su cuenta

Contratos de trabajo, anexos y nóminas salen del sistema de RR. HH., pero el texto es de RR. HH. y de legal. Cada cláusula que varía por país, tipo de contrato o antigüedad es una condición en la plantilla, no una rama en el código de alguien.

✓Cláusulas que cambian según país, tipo de contrato o puesto

✓Una sola plantilla para todos los idiomas en los que contratas

✓Legal edita el párrafo en el editor; no se despliega nada

Mucho volumen, impreso

Papel que tiene que salir idéntico

Albaranes, etiquetas, cartas de porte y órdenes de trabajo se imprimen, se escanean y se archivan. Tienen que encajar exactamente en un formato físico, llevar un código que un escáner lea, y salir igual en el documento diez mil que en el primero.

✓Formatos fijos y tamaños de etiqueta, con la paginación bajo tu control

✓Códigos de barras y QR generados desde los datos de la llamada de render

✓Envía el PDF directamente a una cola de impresión, sin guardar nada

Plantillas de ejemplo

Empieza con una de las nuestras.

Plantillas de Pagr listas para usar para los documentos que más generan los equipos. Descarga un ejemplo real abajo, o sube el PDF que envías hoy y empieza por ahí.