# El catálogo electrónico: el documento que mata al pedido con precio viejo

date: 2026-07-06

> El catálogo electrónico de productos y precios (832 en X12, PRICAT en EDIFACT) explicado sin jerga: cómo un proveedor publica catálogo, precios y disponibilidad a todos sus clientes B2B de una vez, y por qué eso elimina las notas de crédito por precio desactualizado. Serie 'EDI sin misterio'.


La escena se repite en cualquier distribuidora del país: el lunes actualizaste la lista de precios. La enviaste por WhatsApp a tus sesenta clientes, en PDF. El miércoles llega un pedido grande… con los precios del mes pasado. El cliente jura que esa era la lista que tenía. Facturas, él reclama, y administración termina emitiendo una nota de crédito, cuadrando la diferencia y gastando dos días de llamadas en un pedido que debió tomar diez minutos.

Nadie mintió. Simplemente **cada cliente tiene una copia distinta de tu verdad**, y las copias envejecen a velocidades distintas. En un mercado donde los precios cambian seguido —como el venezolano— eso no es una molestia ocasional: es un costo administrativo permanente disfrazado de "así es este negocio".

La transacción que resuelve esto es el **catálogo electrónico de productos y precios** (en el estándar X12 se llama 832, pero existe en todos los idiomas EDI — abajo la tabla completa).

### ¿Qué es el catálogo electrónico, en una frase?

**EDI** significa intercambio electrónico de datos: documentos comerciales que viajan de sistema a sistema, sin recaptura manual. El **catálogo electrónico** (*Price/Sales Catalog*, catálogo de precios y ventas) es el documento con el que **el proveedor publica su catálogo —productos, descripciones, códigos, precios, unidades de venta y disponibilidad— directamente al sistema de sus clientes**.

No es un PDF que alguien tiene que leer. Es data que el sistema del cliente **carga sola**: cuando su comprador arma el pedido, ya está viendo tu catálogo vigente, con tus precios de hoy.

### Cómo funciona: una farmacéutica que cambia precios cada semana

Imagina una distribuidora farmacéutica con 4.000 productos y decenas de farmacias y clínicas como clientes, en un mercado donde las listas se ajustan cada semana o cada quince días:

1. El lunes, la distribuidora actualiza precios en su sistema administrativo — como siempre lo ha hecho.
2. De ese sistema se genera automáticamente el **catálogo electrónico**: puede ser el catálogo completo o solo los cambios (los 300 productos que se movieron, los 5 nuevos, los 2 descontinuados).
3. El catálogo se transmite **a todos los clientes conectados a la vez**. No hay sesenta PDFs; hay una sola publicación.
4. El sistema de cada farmacia recibe el catálogo y actualiza sus registros: precios, presentaciones, códigos de barras, disponibilidad.
5. Cuando la farmacia arma su pedido del jueves (idealmente otro documento EDI, la orden de compra 850), **lo arma contra el catálogo vigente**. El precio del pedido y el precio de la factura son el mismo número, porque salieron de la misma fuente.

La nota de crédito por "precio viejo" no se resuelve más rápido: **deja de existir**, porque la condición que la creaba —dos copias distintas de la lista— ya no ocurre.

{{< figure src="/images/diagrams/catalogo-es.svg" alt="Una publicación, todos los clientes: la lista deja de envejecer por copias" caption="Una publicación, todos los clientes: la lista deja de envejecer por copias" class="diagram" >}}

### Una única fuente de verdad

Ese es el concepto de fondo: el catálogo deja de ser un archivo que se reparte y se convierte en una **única fuente de verdad** que todos consultan. El catálogo electrónico además transporta más que precios:

- **Identificación**: códigos del proveedor, códigos de barras (GTIN), descripción.
- **Comercial**: precio por presentación, mínimos de compra, unidad de venta (caja, blíster, unidad).
- **Ciclo de vida**: producto nuevo, cambio de precio con fecha de vigencia, producto descontinuado.
- **Disponibilidad**: qué hay para despachar, para que nadie pida lo que no existe.

Ese detalle de la **fecha de vigencia** es oro en mercados de precios cambiantes: puedes publicar hoy la lista que rige desde el lunes, y los sistemas de tus clientes la aplican exactamente ese día. Nadie madruga a reenviar PDFs.

### Qué gana cada parte

| | Proveedor | Cliente (comprador) |
|---|---|---|
| **Administración** | Adiós notas de crédito por precio viejo; facturas que se pagan sin disputa | Pedidos que llegan como se cotizaron |
| **Ventas** | El cambio de precio rige el mismo día en todos los clientes | Ve productos nuevos y disponibilidad al instante |
| **Operación** | Una publicación en vez de sesenta envíos | Cero transcripción de listas al sistema |
| **Relación** | Menos llamadas de reclamo, más de venta | Confianza: el precio es el precio |

### Errores comunes

- **Publicar el catálogo electrónico y seguir mandando el PDF "por si acaso".** Dos canales de precios es volver al problema original con un paso extra. El catálogo electrónico funciona cuando es *el* canal.
- **Catálogo sucio.** Si tu sistema interno tiene descripciones inconsistentes o códigos duplicados, el catálogo publicará ese desorden a todos tus clientes a la vez. Limpiar el maestro de productos es el prerrequisito real.
- **Actualizar "cuando se pueda".** El valor está en la disciplina: cada cambio de precio genera su publicación, sin excepción. Un catálogo electrónico desactualizado es un PDF con otro nombre.
- **"Mis clientes son pequeños, no tienen sistemas."** Muchos ya tienen un administrativo que puede recibir catálogos; y para los que no, existen portales que muestran ese mismo catálogo en web. La fuente única sirve a ambos.

### El mismo documento en cada idioma EDI

El catálogo electrónico es la transacción; "832" es solo cómo la llama un estándar. Según con quién te conectes, la vas a encontrar con estos nombres:

| Estándar | Mensaje | Dónde lo verás |
|----------|---------|----------------|
| [ANSI X12](/blog/x12-el-idioma-edi-de-america/) | 832 (Price/Sales Catalog) | Norteamérica y las Américas |
| [UN/EDIFACT](/blog/edifact-el-idioma-edi-del-mundo/) | PRICAT (Price/Sales Catalogue) y PRODAT (datos de producto) | Europa y EANCOM |
| [TRADACOMS](/blog/tradacoms-el-abuelo-del-edi-retail/) | PRIHDR/PRIDET (Price Information File) | Retail UK legacy |
| SAP IDoc | PRICAT01 / MATMAS (formato interno de SAP: no es un estándar entre empresas, pero es lo que tu ERP SAP emite y recibe) | Empresas con SAP |
| [GS1 XML](/blog/gs1-xml-el-idioma-de-los-negocios-aprende-web/) | Catalogue Item Notification (CIN) vía GDSN | Data pools globales |

La moraleja: **aprende la transacción, no el número**. Si entiendes el catálogo electrónico —única fuente de verdad, vigencias, ciclo de vida—, cambiar de sintaxis es cuestión de mapeo, no de volver a empezar.

### El catálogo es el primer eslabón

Fíjate en la secuencia: con el catálogo electrónico el cliente sabe **qué vendes y a cuánto**; con el [plan de entregas](/blog/edi-830-planificacion-sin-adivinar/) tú sabes **cuánto te va a comprar**; y con el [aviso de despacho](/blog/edi-856-el-camion-que-avisa-antes-de-llegar/) él sabe **qué le va en camino**. Es la misma idea repetida: reemplazar copias envejecidas por información compartida.

Si tu equipo de administración vive cuadrando diferencias de precio, el problema no es tu gente: es que cada cliente tiene una foto vieja de tu lista. Mira cómo se conecta un catálogo único en nuestras [soluciones](/soluciones/) — y calcula cuántas notas de crédito emitiste el mes pasado solo por precios. Ese es el número que este documento pone en cero.