Cómo crear la salida de informes de Excel - COM/Open XML/plantillas

En las consultas sobre la salida de informes de Excel, no es raro que detrás de la frase «quiero generarlo en Excel» se escondan en realidad varios requisitos distintos mezclados entre sí.

• El usuario quiere poder corregirlo a mano más adelante
• Quiere conservar el .xlsm que ya existe
• Quiere seguir usando tal cual las tablas dinámicas, los gráficos y la configuración de impresión
• Quiere generar grandes volúmenes en un lote nocturno
• Quiere ejecutarlo de forma desatendida en un servidor
• También quiere obtener un PDF

Ninguno de estos puntos se resuelve limpiamente con un único método. Antes que el nombre de la biblioteca, lo primero que hay que mirar es si se va a ejecutar la aplicación Excel o si se va a crear un archivo Excel.

Si se falla en este punto, el sistema puede funcionar al principio, pero el mantenimiento se vuelve doloroso más adelante. En este artículo se organiza cómo elegir entre automatización COM / Open XML / inserción mediante plantilla / uso combinado con VBA existente, partiendo de la salida de informes de Excel en aplicaciones Windows y sistemas empresariales.

Público objetivo y prerequisitos

Este artículo está dirigido a desarrolladores que todavía tienen que decidir cómo generar informes de Excel desde un sistema empresarial.

El escenario que se asume es una configuración en la que la salida se genera desde una aplicación o un lote en C# / .NET que se ejecuta en Windows. También se contempla el caso de contar con activos VBA existentes, pero incluso entonces el artículo parte de la base de repartir los roles con el lado de .NET, en lugar de «completarlo todo solo con VBA». Los ejemplos de código están en C# / .NET 8.

Terminología previa

1. Conclusión inicial

Antes de nada, se enumeran solo las conclusiones.

• Si el informe es uno que el usuario abrirá y editará después en Excel, la primera opción es la plantilla combinada con la generación directa de .xlsx / .xlsm.
• Si la generación es automática mediante un servidor, un servicio o un programador de tareas, es más seguro no basarse en la automatización de Office.
• Si desea aprovechar el .xlsm, VBA, gráficos, tablas dinámicas y configuración de impresión existentes, es menos frágil dejar el diseño y las funciones propias de Excel del lado de la plantilla y limitar el código a la inserción de datos.
• Solo cuando realmente se necesita el comportamiento propio de la aplicación Excel, es natural usar la automatización COM, limitándola a la ejecución interactiva en el escritorio.
• Si se trata simplemente de generar un listado, en muchos casos CSV, PDF o una pantalla web se ajustan mejor a los requisitos desde el principio.

En definitiva, en muchos informes empresariales resulta más natural «construir un archivo Excel» que «operar Excel».

2. Qué decidir primero

A continuación se resume en una tabla lo que conviene decidir primero en la salida de informes de Excel.

3. Principales métodos de implementación

3.1 Automatización COM de Excel

Es el método que consiste en iniciar Excel y manipular Workbook, Worksheet y Range a través de COM. Resulta fácil de entender si se piensa como «conducir» el propio Excel real.

Su ventaja es poder usar tal cual el comportamiento propio de Excel. Combina bien con libros existentes, gráficos, tablas dinámicas, configuración de impresión, macros y salida a PDF, y permite trabajar directamente con «cómo se ve finalmente en Excel».

Sin embargo, sus puntos débiles también son claros.

• Requiere tener Excel instalado
• Arrastra problemas de ciclo de vida de procesos, bloqueo de archivos, cuadros de diálogo, bitness y dependencia del perfil de usuario
• La propia Microsoft no recomienda ni admite la automatización de Office desde servidores o servicios desatendidos

El tercer punto es la afirmación más contundente de este artículo, así que conviene dejar clara su base. El artículo de soporte de Microsoft «Considerations for server-side Automation of Office» establece explícitamente que no se recomienda ni se admite la automatización de Office en el lado del servidor. Los motivos que se citan son los cinco siguientes.

Para el entorno de RPA de Microsoft 365 existe una explicación aparte en «Considerations for unattended automation of Office». Cuando este punto sea motivo de discusión al elegir el método, use estos dos artículos como fuente.

3.2 Generación directa de .xlsx

Como .xlsx es un formato Open XML, es posible construir el archivo directamente sin iniciar Excel. Con herramientas como Open XML SDK, se puede manipular desde el programa el libro, las hojas, las celdas, los estilos y las tablas.

La ventaja de este método es que resulta fácil de ejecutar incluso en entornos sin Excel instalado, y combina bien con lotes y servidores.

Por otro lado, cuando se quiere reproducir con naturalidad el comportamiento propio de la interfaz de Excel, la cosa se complica un poco. Cosas como el ajuste automático del ancho de columna, los saltos de página, un aspecto visual complejo o la edición profunda de libros existentes hacen que, si se intenta resolver todo limpiamente solo con código, el número de líneas no deje de crecer.

.NET ofrece varias bibliotecas para trabajar con .xlsx, y en la práctica las condiciones de licencia sí importan. Las que suelen aparecer como candidatas son estas.

Con el método de inserción mediante plantilla, el aspecto visual queda del lado de la plantilla, por lo que al código solo se le exige «introducir el valor en el punto de entrada definido». Por eso, las bibliotecas de tipo envoltorio, con menos código, resultan más fáciles de manejar.

3.3 Inserción mediante plantilla

En la práctica, lo más recomendable es el método de crear primero la plantilla de Excel y limitar el código a la inserción de datos.

El aspecto del informe, las fórmulas, el formato condicional, el área de impresión, el encabezado/pie de página, el logotipo y los gráficos se colocan en la plantilla. El código, por su parte, duplica la plantilla y escribe los datos en «los puntos de entrada definidos», como rangos con nombre, tablas o rangos de celdas.

Al hacerlo así, la corrección del diseño y la corrección de la lógica de negocio quedan separadas. Resulta mucho más fácil evitar el infierno de Cells[37, 9] = ... tan habitual en los informes de Excel.

3.4 Método para conservar los activos VBA existentes

Si el .xlsm o el VBA existentes siguen siendo útiles, en muchos casos resulta más natural no reconstruirlo todo de golpe. Es bastante realista repartir las tareas dejando la interfaz del informe y el ajuste final en VBA, y trasladando los cálculos pesados, el acceso a base de datos/HTTP y la lógica de negocio al lado de C#/.NET.

Lo importante en este caso es no dejar ambigua la responsabilidad de cada parte.

• El lado de VBA se encarga del comportamiento dentro del libro
• El lado de .NET se encarga de la obtención de datos y el procesamiento de negocio
• El límite entre ambos se fija mediante rangos con nombre, tablas e interfaces públicas

3.5 Casos que usan Microsoft 365 / Graph

Si el archivo de Excel ya reside desde el principio en OneDrive o SharePoint y se desea compartirlo desde aplicaciones web o móviles, la API de Excel de Microsoft Graph también entra dentro de las opciones.

Sin embargo, no es una solución general para producir en masa y sin más cualquier archivo local en un PC. Los permisos, la ubicación de almacenamiento, la sesión y la operación parten, desde el principio, de la premisa de usar M365.

3.6 ¿Es realmente necesario usar Excel?

Si el requisito del informe es «una tabla que una persona manipulará después», elegir Excel es natural. Sin embargo, con requisitos como los siguientes, a menudo resulta más directo optar por otro formato.

• Imprimir y archivar -> PDF
• Importar a otro sistema -> CSV / TSV / JSON
• Basta con poder verlo en el navegador -> HTML / pantalla web
• El objetivo principal es la agregación y la visualización -> BI o paneles de control

4. Comparativa de métodos

Al ordenar las diferencias entre los métodos en una sola tabla, quedan así.

5. Cómo elegir según los requisitos habituales

5.1 Generar en el PC del usuario y editar directamente

En este caso, la plantilla combinada con la generación directa es una opción bastante sólida. Como el usuario abrirá el archivo en Excel después de generarlo, es aceptable dejar la edición final en manos de Excel.

5.2 Generación masiva mediante lotes nocturnos o servicios

Cuando hay de por medio un lote nocturno, es más seguro empezar por descartar la automatización COM. Conviene orientar la generación hacia la generación directa de .xlsx y, si es necesario, dejar que el usuario lo abra más adelante en Excel.

5.3 Aprovechar el .xlsm / VBA existente

Si los activos existentes siguen siendo útiles, lo realista es conservar el .xlsm como plantilla y realizar únicamente la inserción de datos desde fuera.

5.4 Cuando las filas de detalle son numerosas

El límite de una hoja de Excel es de 1.048.576 filas × 16.384 columnas. Cuando el detalle es grande, esto es lo primero que conviene decidir.

• A partir de cuántas filas se divide en varias hojas
• A partir de cuántos registros se divide en varios archivos
• Si, de entrada, no resultaría más natural usar CSV

6. Una configuración recomendable en la práctica

En la práctica, la configuración menos frágil es la que se divide en cuatro capas.

Lo bueno de esta división es que el código deja de verse arrastrado fácilmente por el aspecto visual de Excel.

6.1 Qué fluye entre las capas

Lo importante es qué es lo que cruza el límite entre capas. Si esto está decidido, es posible avanzar por separado con los cambios de diseño y los cambios de lógica de negocio.

flowchart LR
    accTitle: "Flujo de datos entre las capas ReportModel, Template, Binder y Finisher"
    accDescr: Diagrama que muestra cómo los datos sin procesar de la fuente (DB/API/archivo) se transforman en ReportModel, se combinan con la plantilla en el Binder mediante rangos con nombre y tablas, y opcionalmente pasan por el Finisher para producir el archivo final xlsx, xlsm o PDF
    DB[("DB / API / archivo")] -->|"Datos sin procesar"| RM["ReportModel<br/>Conserva únicamente los valores<br/>necesarios para el informe, ya formateados"]
    TP["Template<br/>xlsx o xlsm<br/>Apariencia, fórmulas y configuración de impresión"] -->|"Libro duplicado"| BD
    RM -->|"Pares de nombre y valor"| BD["Binder<br/>Escribe los valores en los rangos<br/>con nombre y las tablas"]
    BD -->|"Libro con los valores"| FN["Finisher<br/>Conversión a PDF, llamadas a VBA,<br/>solo cuando sea necesario"]
    FN -->|"Resultado"| OUT["xlsx / xlsm / PDF"]
    BD -.->|"Si no hace falta Finisher,<br/>termina aquí"| OUT

Lo único que cruza el límite es el par de nombre y valor; la dirección de celda no sale nunca fuera del Binder. Si las particularidades de la plantilla llegan a filtrarse hasta el ReportModel, en ese momento el diseño ya empieza a resquebrajarse.

6.2 Ejemplo mínimo de implementación

Si se escribe la inserción mediante plantilla con ClosedXML, queda así. En la plantilla Invoice.xlsx se definen de antemano los rangos con nombre Rpt_Title, Rpt_IssuedOn, Rpt_CustomerName y Rpt_DetailRows.

// C# / .NET 8 + ClosedXML (licencia MIT)
//   dotnet add package ClosedXML
using ClosedXML.Excel;

// Equivalente a ReportModel. No contiene ninguna dirección de celda
var rows = new (string Code, string Name, int Qty, decimal UnitPrice)[]
{
    ("A-100", "Rodamiento de bolas", 12, 480m),
    ("A-205", "Eje", 3, 12800m),
    ("B-010", "Soporte de montaje", 30, 260m),
};

const string TemplatePath = @"templates\Invoice.xlsx";
string outputDir = "output";
Directory.CreateDirectory(outputDir);

// No construya el nombre de archivo con la "hora hasta los segundos". En un lote
// que procesa un registro a la vez, en cuanto dos registros caen en el mismo
// segundo obtienen el mismo nombre, y el que se guarda después sobrescribe el
// informe anterior. Lo molesto es que nadie se da cuenta de que desapareció.
// Incluya siempre un identificador de negocio que determine el informe de forma
// única (aquí, el número de factura).
string invoiceNo = "INV-2026-000123";     // Se recibe del lado que hace la llamada
string outputPath = Path.Combine(outputDir, $"Invoice_{invoiceNo}.xlsx");

// 1. Abrir la plantilla. Como se guarda con otro nombre, la plantilla en sí no se modifica
using var workbook = new XLWorkbook(TemplatePath);

// 2. Los encabezados van a celdas con nombre. Lo importante es que la dirección de celda no aparezca en el código
workbook.Cell("Rpt_Title").Value = "Factura";
workbook.Cell("Rpt_IssuedOn").Value = DateTime.Today;   // Se introduce como valor. El formato de visualización queda del lado de la plantilla
workbook.Cell("Rpt_CustomerName").Value = "Empresa Ejemplo S.A.";

// 3. El detalle usa el rango con nombre como punto de entrada y se escribe por posición relativa dentro del rango
var detail = workbook.Range("Rpt_DetailRows");
if (rows.Length > detail.RowCount())
{
    // Se superó el número de filas previsto. No se trunca en silencio, se detiene aquí
    throw new InvalidOperationException(
        $"El detalle tiene {rows.Length} filas, pero Rpt_DetailRows de la plantilla solo tiene {detail.RowCount()} filas. " +
        "Aumente el número de filas de la plantilla o divida en varias hojas.");
}

for (int i = 0; i < rows.Length; i++)
{
    var row = rows[i];
    detail.Cell(i + 1, 1).Value = row.Code;        // Posición relativa dentro del rango, empezando en 1
    detail.Cell(i + 1, 2).Value = row.Name;
    detail.Cell(i + 1, 3).Value = row.Qty;
    detail.Cell(i + 1, 4).Value = row.UnitPrice;
}

// 4. Guardar con otro nombre. La plantilla se conserva como activo de solo lectura.
//    La escritura se hace en un archivo temporal de la misma carpeta y, al terminar,
//    se renombra al nombre definitivo. Si se escribe directo en outputPath, al fallar
//    a mitad de camino (disco lleno, libro inconsistente) queda un ".xlsx" a medias
//    con el nombre de archivo de negocio
string tempPath = Path.Combine(
    Path.GetDirectoryName(outputPath) ?? string.Empty,   // Mantiene el renombrado dentro del mismo volumen
    $".{Path.GetFileName(outputPath)}.{Guid.NewGuid():N}.tmp");

try
{
    using (var stream = new FileStream(tempPath, FileMode.CreateNew, FileAccess.Write, FileShare.None))
    {
        workbook.SaveAs(stream);
    }

    // Si ya existe un archivo con el mismo nombre, se produce IOException. Así no se
    // sobrescribe en silencio y el problema se detecta al instante (la misma política que FileMode.CreateNew)
    File.Move(tempPath, outputPath);
}
catch
{
    // Si falla, no dejar rastro. De lo contrario, la siguiente ejecución no podrá reintentar con el mismo nombre
    try { File.Delete(tempPath); } catch (IOException) { }
    throw;
}
Console.WriteLine($"Generado: {outputPath}");

Hay cinco puntos en los que se ha puesto atención en este código.

• La dirección de celda no aparece en el código. El destino de la inserción son únicamente los rangos con nombre. Aunque se añada una fila a la plantilla, este código no cambia
• No se sobrescribe la plantilla. El libro que se abre siempre se guarda con otro nombre
• Las fechas y los números se introducen como valores. Si se dan formato como cadenas de texto, en Excel dejan de poder ordenarse o agregarse
• Si el detalle se desborda, se detiene con una excepción. Truncar en silencio es la peor forma de fallo en un informe. Aquí se lleva a la implementación la política del punto 5.4
• El nombre definitivo se asigna solo después de terminar de escribir. SaveAs puede fallar después de haber empezado a escribir. El disco se llena, se corta el recurso compartido, el contenido del libro resulta inválido ── cualquiera de estas cosas puede ocurrir. Si se escribe directamente en outputPath, lo que queda en ese momento es un archivo cortado a medias con el nombre perfecto Invoice_INV-2026-000123.xlsx. Como las personas juzgan por el nombre, no pueden distinguirlo de un informe terminado. Y como FileMode.CreateNew rechaza los archivos ya existentes, incluso al reintentar la ejecución se detiene con un «ya existe». Si se escribe primero en un archivo temporal y luego se renombra con File.Move, ese nombre solo aparece cuando el contenido ya está completo. El destino del renombrado se coloca en la misma carpeta porque un Move que cruza de volumen se convierte en una copia, que sí puede quedar cortada a medias

Aunque el importe se mantenga como decimal, en el momento de entrar en el formato de archivo de Excel pasa a ser de punto flotante de doble precisión. Si el criterio de redondeo es importante para el negocio, es más seguro no dejarlo en manos de las fórmulas de Excel y generar el valor ya redondeado en el lado de ReportModel.

Cuando se usa .xlsm como plantilla, el flujo es el mismo, pero hay que ajustar la extensión del destino de guardado a .xlsm. La configuración para insertar datos conservando las macros es la del punto 3.4.

7. Errores comunes

7.1 No convertir la dirección de celda en una regla de negocio

Cuando Cells[12, 7] empieza a representar una regla de negocio, un cambio de diseño se convierte directamente en un cambio de especificación. El código es más duradero si toca el informe a través de rangos con nombre o nombres de tabla.

7.2 No usar celdas combinadas como punto de entrada de datos

Las celdas combinadas son una función pensada para el aspecto visual. Si se usan como destino de inserción, resulta fácil que se produzcan errores al añadir filas o calcular rangos.

7.3 No rellenar números ni fechas como “cadenas con formato visual”

Es más natural introducir los valores como valores y dejar el aspecto visual del lado del formato de celda.

7.4 No gestionar los cambios de plantilla de forma informal

La plantilla no es código, pero en la práctica equivale a la propia especificación. Es prudente tratarla como objeto de control de versiones, revisión de diferencias y revisión de cambios.

7.5 Si usa COM, no subestime la bitness ni la gestión del ciclo de vida

En la automatización COM o la integración con VBA, la diferencia entre 32 y 64 bits, la limpieza de los procesos de Excel, el bloqueo de archivos y las diferencias entre entornos de usuario pasan factura de forma silenciosa.

8. Resumen

La salida de informes de Excel parece resolverse con la simple frase «generarlo en Excel», pero en realidad es necesario decidir de antemano varias bifurcaciones.

• Si se va a ejecutar la aplicación Excel
• O si se va a crear un archivo Excel
• Si es en el PC del usuario o en ejecución desatendida
• Si se conservan el VBA o el .xlsm existentes
• Si el resultado final es Excel, o PDF o CSV

Como primera opción en la práctica, la plantilla combinada con la generación directa es bastante sólida. A partir de ahí, resulta fácil de organizar añadiendo, según haga falta, la reutilización de VBA existente o el procesamiento final en Excel en el PC del usuario.

9. Referencias

Se enumeran en el orden de lectura recomendado.

9.1 Lecturas previas a elegir el método

• Considerations for server-side Automation of Office — Es la fuente de la afirmación del punto 3.1 de que «la automatización de Office en el lado del servidor no se recomienda ni se admite». Es el argumento que más se usa como base para elegir el método
• Considerations for unattended automation of Office in the Microsoft 365 for unattended RPA environment — Corresponde a la excepción del punto anterior: las condiciones en el entorno de RPA de M365
• Excel specifications and limits — Es la lista de límites, incluyendo las 1.048.576 filas × 16.384 columnas del punto 5.4

9.2 Recursos para la generación directa

• About the Open XML SDK for Office — Es la base para construir .xlsx sin Excel
• ClosedXML — Es el envoltorio usado en el ejemplo de código del punto 6.2. Licencia MIT
• NPOI — Es una opción cuando también hace falta manejar el antiguo .xls. Apache License 2.0
• EPPlus — Antes de adoptarlo, compruebe siempre las condiciones de licencia a partir de la versión 5

9.3 Trabajar sobre M365 / SharePoint

• Descripción general de las API de libros y gráficos de Excel - Microsoft Graph
• Obtener acceso a OneDrive y SharePoint con la API de Microsoft Graph

9.4 Recursos para libros de gran tamaño

• Cómo copiar una hoja de cálculo mediante SAX (API simple para XML) — Es la técnica para manejar con Open XML SDK libros de un tamaño que no cabe en memoria. Normalmente no es necesaria dentro del alcance de la inserción mediante plantilla

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Debería elegir automatización COM o generación directa de archivos para la salida de informes de Excel?

Lo primero que hay que observar no es el nombre de la biblioteca, sino si se va a ejecutar la aplicación Excel o si se va a crear un archivo Excel. En muchos informes empresariales resulta más natural construir un archivo Excel que operar Excel, y si el usuario va a editar el informe después, la primera opción es la plantilla combinada con la generación directa de .xlsx/.xlsm. Solo cuando realmente se necesita el comportamiento propio de la aplicación Excel tiene sentido usar la automatización COM, limitada a la ejecución interactiva en el escritorio.

¿Es correcto usar la automatización COM de Excel en un servidor o en un lote nocturno?

Es más seguro evitarlo. La propia Microsoft no recomienda ni admite la automatización de Office desde servidores o servicios desatendidos. Además de requerir la instalación de Excel, la automatización COM arrastra problemas como el ciclo de vida de los procesos, el bloqueo de archivos, los cuadros de diálogo, la bitness y la dependencia del perfil de usuario. En los lotes nocturnos o la generación masiva, lo más seguro es orientarse hacia la generación directa de .xlsx y, si es necesario, dejar que el usuario abra el archivo en Excel más adelante.

¿Se puede construir la salida de informes conservando los activos existentes de .xlsm y VBA?

Sí, es posible. Si los activos existentes siguen siendo útiles, lo más realista no es reconstruirlo todo de golpe, sino conservar el .xlsm como plantilla y realizar la inserción de datos únicamente desde fuera. Resulta práctico dejar la interfaz del informe y el ajuste final en VBA, y trasladar los cálculos pesados, el acceso a base de datos/HTTP y la lógica de negocio al lado de C#/.NET. Lo importante es no dejar ambigua la responsabilidad de cada parte: el límite entre ambos se fija mediante rangos con nombre, tablas e interfaces públicas.

¿Qué trampas conviene evitar al implementar informes de Excel?

Lo primero y más importante es no convertir la dirección de celda en una regla de negocio: en lugar de indicaciones como Cells[12, 7], es preferible tocar el informe a través de rangos con nombre o nombres de tabla, lo que resulta más duradero. También ayuda no usar celdas combinadas como punto de entrada de datos, ya que son una función puramente visual; introducir números y fechas como valores y dejar la apariencia al formato de celda; y tratar la plantilla como control de versiones y objeto de revisión, puesto que en la práctica equivale a la especificación. Además, el límite de una hoja de Excel es de 1.048.576 filas por 16.384 columnas, así que si el detalle es grande conviene decidir de antemano la política de división por hojas o por archivos.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.