Disear Base De Datos De Un Sistema De

Facturacin
Disear Base De Datos De Un Sistema De
Facturacin
James Revelo julio 24, 2014 Datos 30 Comments
Los Sistemas de facturacin estn en la mayora de Tiendas, Supermercados, Almacenes, y
otras Organizaciones comerciales, para Optimizar el Proceso de Venta y los Reportes de
flujo de ingresos. Este tipo de sistemas se caracterizan por almacenar los datos de los clientes
que compran en la empresa, emitir facturas generadas en base a la cantidad de productos que
han sido comprados por los clientes, manejar inventarios y muchas funciones mas.
En este artculo estudiaremos el diseo de una base de datos para un sistema de facturacin, a
travs de un enfoque generalizado. Veremos que entidades, atributos y relaciones existen y
como normalizar las anomalas ocurrentes.

Diseo de la Base de Datos

La primera tarea es identificar todas las entidades posibles que vayan a intervenir en el proceso
de facturacin de la empresa. Normalmente estas entidades ya estn definidas previamente en
el Modelo de datos para la elaboracin de los Componentes de Software.
Tambin puedes explorar en los Requerimientos funcionales, Historias de usuario, Reglas
de negocio, el Formato de las Facturas emitidas, los Diseos de formularios y Reportes.
A continuacin te mostrar algunas recopilaciones descriptivas para modelar la base de datos:

Registrar el Id, Nombre, Apellido, Direccin, Fecha de nacimiento, Telfono y el

Correo electrnico de los clientes de la compaa.

Registrar para los productos la siguiente informacin: Cdigo, Nombre, Precio, Nmero
de Existencias y Categora a la que pertenece.

Se debe especificar en la factura los Datos del cliente y una tabla que muestre la
Especificacin del tipo de producto comprado, su precio, la cantidad suministrada y el

total parcial. Al final de la factura debe calcularse el valor antes de impuestos y

descuentos, y luego calcular el valor total de la compra.

Un cliente puede pagar con las siguientes formas de pago: Efectivo, Tarjeta de crdito,
Tarjeta dbito, Paypal y Neteller.

Un cliente puede generar varias facturas debido a sus distintas compras, pero jams una
misma factura podr haber sido generada por ms de un cliente.

En una factura pueden contener varios productos vinculados, al igual que todos los
productos estn posibilitados a aparecer en todas las facturas.

Un cliente puede pagar el monto total de una factura con varios mtodos de pago.

Estas condiciones pueden cambiar dependiendo de las necesidades del cliente, ya que pueden
variar sus procesos de facturacin o aadir ms atributos relevantes para ellos. Pero para los
objetivos de este articulo usaremos solo las caractersticas esenciales.

Crear el Modelo
Requerimientos

Relacional

partir

de

los

Bueno, es sencillo pensar en que primero estn las personas que dan vida al negocio, es decir,
la entidad CLIENTE. Luego viene la satisfaccin de las necesidades del cliente a travs del
PRODUCTO. Y tambin es necesario entregar una FACTURA para constatar la entrega del
producto.
Por el momento CLIENTE, FACTURA y PRODUCTO son las entidades ms relevantes, cuya
informacin debe ser almacenada en la base de datos. Veamos el Diagrama Relacional
preliminar
para
comprender
este
caso:

He puesto los signos de interrogacin en las llaves forneas de FACTURA y PRODUCTO debido
a que esta relacin muchos a muchos es compleja. Para entenderla quiero mostrarte las

partes de una factura con un sencillo diseo perteneciente a una Tienda de artculos para
Computadoras.

La cabecera de la factura(Recuadro AMARILLO) contiene los datos del cliente y las

caracterstica de la factura. Al final(Recuadro AZUL) se obtiene el resultado total de toda la
compra. Como ves en el detalle(Recuadro ROJO) se encuentra una tabla que muestra que
productos han sido comprados por el cliente en esta ocasin, la cual representa la relacin de
factura y producto.
Recuerda que cuando se presenta una relacin muchos a muchos debemos reemplazar esa
relacin por una tabla intermediaria que reciba las claves principales de ambas tablas
referenciadas. Ademas de eso, las tablas originales deben tener una relacin uno a muchos con
la tabla intermedia. Esto permite optimizar y normalizar los datos.
As que crearemos una nueva tabla llamada DETALLE en alusin a cada rengln detallado en la
factura. Veamos como quedara el diagrama ahora:

Por qu se usa la llave compuesta PK= {id_factura,

num_detalle} en vez de PK= {id_factura, id_producto}?
Para diferenciar el orden de los items en la factura. Es decir, que al declarar El tercer producto
de la factura N podamos entender rpidamente a que nos referimos. Algo que visualmente
podra ser poco intuitivo de notar con la otra llave candidata.
Considera el siguiente ejemplo de una Tienda de Artculos de Deporte. A continuacin se
muestra la tabla DETALLE con tres facturas distintas:
num_detalle

id_factura

id_producto

cantidad

precio

101

SDA

101

SDB

102

SDA

103

SDC

Fjate que en la factura 101 podemos distinguir que el primer item registrado es el producto con
cdigo SDA, ya que num_detalle es igual a 1. Y que el producto con cdigo SDB esta
ubicado en el segundo rengln detallado de la factura.
Si la clave primaria fuera id_factura + id_producto no tendramos claro el orden de los
productos comprados. Es por eso que agregar el atributo num_detalle es tan beneficioso para
nosotros.

Por qu esta el precio del producto en DETALLE y en

PRODUCTO al mismo tiempo?
A primera impresin parece redundancia de datos al extremo, pero hay un secreto escondido.
La razn por la cual indujimos esta redundancia fue por que los precios de los productos
varan
en
el
mercado.
Importante?
Claro!, imagina que un Almacn de Ropa est vendiendo la camisa de la seleccin de Ftbol
en 10USD. Debido a que al equipo le est yendo muy bien en los ltimos partidos, muchas
personas vienen a comprar la camisa. Al dueo se le ocurre subir a 12USD el precio de la
camisa, ya que la demanda as lo est imponiendo.
Al final de mes la Tienda de Ropa ejecuta un reporte para ver el ingreso total por ventas, donde
se muestra que la cantidad de dinero contado no coincide con el valor del sistema.
Que pas?
Miremos algunos clculos pretenciosos antes y despus del cambio de precio:
Antes de la manifestacin aumentada de demanda

Precio = 10USD
Unidades vendidas = 200
Ingresos por ventas esperados = 2000USD

Despus de la manifestacin aumentada de demanda

Precio = 12USD
Unidades vendidas = 250
Ingresos por ventas esperados = 3000USD

Ingresos por ventas totales esperados = 5000USD

Los resultados anteriores seran los resultados ideales, pero al no incluir el precio del artculo en
la tabla DETALLE, suceder lo siguiente a la hora de calcular los ingresos totales:
Clculo de los ingresos con el precio actual
ARTICULO.precio = 12USD
Unidades vendidas = 450
Ingresos totales por ventas = 450 x 12USD = 5400USD

Son 400USD de ms!, es decir, tu Software est produciendo un error del 8% en el ingreso total
por ventas. Algo desastroso para tu reputacin. Al no incluir este atributo has calculado los
ingresos con el precio actual que refleja ARTICULO.precio, por lo cual todas las unidades
valen lo mismo.
No obstante, si incluyes el precio en DETALLE suceder lo siguiente:
Calculo de los ingresos con el precio de la ocasin

DETALLE.precio= 10USD
Unidades vendidas =200
Ingresos parciales por venta = 2000USD

DETALLE.precio = 12USD
Unidades vendidas = 350
Ingresos parciales por venta = 3000USD

Ingresos totales por ventas = 5000USD

Con esta redundancia inducida puedes tener el clculo exacto para cada producto en el
momento actual, porque DETALLE cumple la funcin de mantener el mismo estado para cada
rengln en la factura a lo largo del tiempo.

Amigo y por qu subtotal y total no son atributos de

FACTURA?
Porque son atributos derivados. Es decir, podemos calcularlos a travs del precio del
producto y la cantidad cuando queramos. Guardarlos en nuestra base de datos sera espacio
de almacenamiento adicional.
En cambio, si realizamos los clculos en tiempo real, a nuestra aplicacin solo le tomara un
pequeo instante de tiempo que no interferira con la velocidad de nuestro Software Comercial.
Es un sacrificio de tiempo vs memoria muy efectivo.

Crear tablas aisladas para Atributos Multivaluados

Darnos cuenta que el atributo categora de la entidad PRODUCTO es poco eficiente. Esto se
debe a que la categora se repetir un sinnmero de veces por todos los registros que
tengamos(redundancia).
Veamos un ejemplo con los productos de un Supermercado:
id_producto

nombre

precio

stock

categora

SDA

X-box 360

500

100

TECNO

SDB

Caja de huevos

230

COMIDA

SDC

Aceite de girasol

219

COMIDA

SDD

Coca-cola 200ml

2,3

341

BEBIDA

De los 4 hay 2 que repiten la categora COMIDA. Que tal si hubiesen 1000 productos?, la
cantidad de espacio usado para almacenar VARCHARS repetidos sera muy grande.
La solucin es sencilla, expandiremos nuestro diagrama para quitar el atributo categora de la
entidad PRODUCTO y agregaremos una nueva tabla llamada CATEGORIA. Esta modificacin
aadir una relacin uno a muchos entre producto y categora, por lo cual incluiramos la llave
fornea de categora.
Ventajas?

Mayor claridad e integridad en la base de datos

Economizar espacio en disco. Rinde mejor el valor de una llave fornea 1 que el nombre
de la categora COMIDA.

Aadir nuevos atributos como por ejemplo la descripcin de la categora.

Facilidad en la consulta de productos por categora y eleccin de nuevas mtricas.

Si el cliente decidiera que sus productos pueden pertenecer a ms de una categora, entonces
ya sabes que debes crear una tabla intermedia por la relacin muchos a muchos que se genera.
Con la solucin implementada, las tablas quedaran as:
id_producto

nombre

precio

stock

id_categora

SDA

X-box 360

500

100

SDB

Caja de huevos

230

SDC

Aceite de girasol

219

SDD

Coca-cola 200ml

2,3

341

id_categora

nombre

TECNO

COMIDA

BEBIDA

Ahora veamos nuestro diagrama:

Pagos en la Base de Datos del Sistema de Facturacin

No entrar en muchos detalles sobre la tabla PAGO ya que este tema es muy
extenso. Inicialmente podemos considerar datos como Fecha del pago, el Monto pagado y el
Mtodo de pago que se us, ya sea efectivo, tarjeta de dbito, etc.
Cuando un Sistema de facturacin acepta varias formas de pago electrnico, es necesario
realizar una investigacin sobre bases de datos e-Commerce. Esta caracterstica expande ms
el concepto de pagos, generado nuevas tablas y relaciones en el modelo, lo cual queda en tus
manos si te encuentras en esa situacin.
Es importante tener en cuenta la forma en que se realizarn los pagos, ya que hay negocios
donde la factura debe pagarse en un solo pago, otros donde se debe hacer un solo pago pero
divido en porcentajes con diferentes formas de pago. Tambin existen acuerdos donde abonas
un poco al inicio y en otra fecha pagas el valor restante.
O en el caso de las compras por Internet, se debe generar una Orden que sincronice la Cuenta
del cliente, sus Pagos y el Envo del producto.
En mi caso eleg una forma muy sencilla de pago para terminar este articulo, donde el negocio
recibe un pago por los productos de la factura y puede usar varios mtodos de pago:

Podemos notar que un cliente tiene posibilitado pagar con varias formas de pago su compra, por
lo cual creamos una relacin uno a muchos entre MODO_PAGO y la factura.
James Revelo julio 24, 2014 Datos 30 Comments
Los Sistemas de facturacin estn en la mayora de Tiendas, Supermercados, Almacenes, y
otras Organizaciones comerciales, para Optimizar el Proceso de Venta y los Reportes de
flujo de ingresos. Este tipo de sistemas se caracterizan por almacenar los datos de los clientes
que compran en la empresa, emitir facturas generadas en base a la cantidad de productos que
han sido comprados por los clientes, manejar inventarios y muchas funciones mas.
En este artculo estudiaremos el diseo de una base de datos para un sistema de facturacin, a
travs de un enfoque generalizado. Veremos que entidades, atributos y relaciones existen y
como normalizar las anomalas ocurrentes.

Diseo de la Base de Datos

La primera tarea es identificar todas las entidades posibles que vayan a intervenir en el proceso
de facturacin de la empresa. Normalmente estas entidades ya estn definidas previamente en
el Modelo de datos para la elaboracin de los Componentes de Software.
Tambin puedes explorar en los Requerimientos funcionales, Historias de usuario, Reglas
de negocio, el Formato de las Facturas emitidas, los Diseos de formularios y Reportes.
A continuacin te mostrar algunas recopilaciones descriptivas para modelar la base de datos:

Registrar el Id, Nombre, Apellido, Direccin, Fecha de nacimiento, Telfono y el

Correo electrnico de los clientes de la compaa.

Registrar para los productos la siguiente informacin: Cdigo, Nombre, Precio, Nmero
de Existencias y Categora a la que pertenece.

Se debe especificar en la factura los Datos del cliente y una tabla que muestre la
Especificacin del tipo de producto comprado, su precio, la cantidad suministrada y el
total parcial. Al final de la factura debe calcularse el valor antes de impuestos y
descuentos, y luego calcular el valor total de la compra.

Un cliente puede pagar con las siguientes formas de pago: Efectivo, Tarjeta de crdito,
Tarjeta dbito, Paypal y Neteller.

Un cliente puede generar varias facturas debido a sus distintas compras, pero jams una
misma factura podr haber sido generada por ms de un cliente.

En una factura pueden contener varios productos vinculados, al igual que todos los
productos estn posibilitados a aparecer en todas las facturas.

Un cliente puede pagar el monto total de una factura con varios mtodos de pago.

Estas condiciones pueden cambiar dependiendo de las necesidades del cliente, ya que pueden
variar sus procesos de facturacin o aadir ms atributos relevantes para ellos. Pero para los
objetivos de este articulo usaremos solo las caractersticas esenciales.

Crear el Modelo
Requerimientos

Relacional

partir

de

los

Bueno, es sencillo pensar en que primero estn las personas que dan vida al negocio, es decir,
la entidad CLIENTE. Luego viene la satisfaccin de las necesidades del cliente a travs del
PRODUCTO. Y tambin es necesario entregar una FACTURA para constatar la entrega del
producto.
Por el momento CLIENTE, FACTURA y PRODUCTO son las entidades ms relevantes, cuya
informacin debe ser almacenada en la base de datos. Veamos el Diagrama Relacional
preliminar
para
comprender
este
caso:

He puesto los signos de interrogacin en las llaves forneas de FACTURA y PRODUCTO debido
a que esta relacin muchos a muchos es compleja. Para entenderla quiero mostrarte las
partes de una factura con un sencillo diseo perteneciente a una Tienda de artculos para
Computadoras.

La cabecera de la factura(Recuadro AMARILLO) contiene los datos del cliente y las

caracterstica de la factura. Al final(Recuadro AZUL) se obtiene el resultado total de toda la
compra. Como ves en el detalle(Recuadro ROJO) se encuentra una tabla que muestra que
productos han sido comprados por el cliente en esta ocasin, la cual representa la relacin de
factura y producto.
Recuerda que cuando se presenta una relacin muchos a muchos debemos reemplazar esa
relacin por una tabla intermediaria que reciba las claves principales de ambas tablas
referenciadas. Ademas de eso, las tablas originales deben tener una relacin uno a muchos con
la tabla intermedia. Esto permite optimizar y normalizar los datos.
As que crearemos una nueva tabla llamada DETALLE en alusin a cada rengln detallado en la
factura. Veamos como quedara el diagrama ahora:

Por qu se usa la llave compuesta PK= {id_factura,

num_detalle} en vez de PK= {id_factura, id_producto}?
Para diferenciar el orden de los items en la factura. Es decir, que al declarar El tercer producto
de la factura N podamos entender rpidamente a que nos referimos. Algo que visualmente
podra ser poco intuitivo de notar con la otra llave candidata.
Considera el siguiente ejemplo de una Tienda de Artculos de Deporte. A continuacin se
muestra la tabla DETALLE con tres facturas distintas:
num_detalle

id_factura

id_producto

cantidad

precio

101

SDA

101

SDB

102

SDA

103

SDC

Fjate que en la factura 101 podemos distinguir que el primer item registrado es el producto con
cdigo SDA, ya que num_detalle es igual a 1. Y que el producto con cdigo SDB esta
ubicado en el segundo rengln detallado de la factura.
Si la clave primaria fuera id_factura + id_producto no tendramos claro el orden de los
productos comprados. Es por eso que agregar el atributo num_detalle es tan beneficioso para
nosotros.

Por qu esta el precio del producto en DETALLE y en

PRODUCTO al mismo tiempo?
A primera impresin parece redundancia de datos al extremo, pero hay un secreto escondido.
La razn por la cual indujimos esta redundancia fue por que los precios de los productos
varan
en
el
mercado.
Importante?
Claro!, imagina que un Almacn de Ropa est vendiendo la camisa de la seleccin de Ftbol
en 10USD. Debido a que al equipo le est yendo muy bien en los ltimos partidos, muchas
personas vienen a comprar la camisa. Al dueo se le ocurre subir a 12USD el precio de la
camisa, ya que la demanda as lo est imponiendo.
Al final de mes la Tienda de Ropa ejecuta un reporte para ver el ingreso total por ventas, donde
se muestra que la cantidad de dinero contado no coincide con el valor del sistema.
Que pas?
Miremos algunos clculos pretenciosos antes y despus del cambio de precio:
Antes de la manifestacin aumentada de demanda

Precio = 10USD
Unidades vendidas = 200
Ingresos por ventas esperados = 2000USD

Despus de la manifestacin aumentada de demanda

Precio = 12USD
Unidades vendidas = 250
Ingresos por ventas esperados = 3000USD

Ingresos por ventas totales esperados = 5000USD

Los resultados anteriores seran los resultados ideales, pero al no incluir el precio del artculo en
la tabla DETALLE, suceder lo siguiente a la hora de calcular los ingresos totales:
Clculo de los ingresos con el precio actual
ARTICULO.precio = 12USD
Unidades vendidas = 450
Ingresos totales por ventas = 450 x 12USD = 5400USD

Son 400USD de ms!, es decir, tu Software est produciendo un error del 8% en el ingreso total
por ventas. Algo desastroso para tu reputacin. Al no incluir este atributo has calculado los
ingresos con el precio actual que refleja ARTICULO.precio, por lo cual todas las unidades
valen lo mismo.
No obstante, si incluyes el precio en DETALLE suceder lo siguiente:
Calculo de los ingresos con el precio de la ocasin

DETALLE.precio= 10USD
Unidades vendidas =200
Ingresos parciales por venta = 2000USD

DETALLE.precio = 12USD
Unidades vendidas = 350
Ingresos parciales por venta = 3000USD

Ingresos totales por ventas = 5000USD

Con esta redundancia inducida puedes tener el clculo exacto para cada producto en el
momento actual, porque DETALLE cumple la funcin de mantener el mismo estado para cada
rengln en la factura a lo largo del tiempo.

Amigo y por qu subtotal y total no son atributos de

FACTURA?
Porque son atributos derivados. Es decir, podemos calcularlos a travs del precio del
producto y la cantidad cuando queramos. Guardarlos en nuestra base de datos sera espacio
de almacenamiento adicional.
En cambio, si realizamos los clculos en tiempo real, a nuestra aplicacin solo le tomara un
pequeo instante de tiempo que no interferira con la velocidad de nuestro Software Comercial.
Es un sacrificio de tiempo vs memoria muy efectivo.

Crear tablas aisladas para Atributos Multivaluados

Darnos cuenta que el atributo categora de la entidad PRODUCTO es poco eficiente. Esto se
debe a que la categora se repetir un sinnmero de veces por todos los registros que
tengamos(redundancia).
Veamos un ejemplo con los productos de un Supermercado:
id_producto

nombre

precio

stock

categora

SDA

X-box 360

500

100

TECNO

SDB

Caja de huevos

230

COMIDA

SDC

Aceite de girasol

219

COMIDA

SDD

Coca-cola 200ml

2,3

341

BEBIDA

De los 4 hay 2 que repiten la categora COMIDA. Que tal si hubiesen 1000 productos?, la
cantidad de espacio usado para almacenar VARCHARS repetidos sera muy grande.
La solucin es sencilla, expandiremos nuestro diagrama para quitar el atributo categora de la
entidad PRODUCTO y agregaremos una nueva tabla llamada CATEGORIA. Esta modificacin
aadir una relacin uno a muchos entre producto y categora, por lo cual incluiramos la llave
fornea de categora.
Ventajas?

Mayor claridad e integridad en la base de datos

Economizar espacio en disco. Rinde mejor el valor de una llave fornea 1 que el nombre
de la categora COMIDA.

Aadir nuevos atributos como por ejemplo la descripcin de la categora.

Facilidad en la consulta de productos por categora y eleccin de nuevas mtricas.

Si el cliente decidiera que sus productos pueden pertenecer a ms de una categora, entonces
ya sabes que debes crear una tabla intermedia por la relacin muchos a muchos que se genera.
Con la solucin implementada, las tablas quedaran as:
id_producto

nombre

precio

stock

id_categora

SDA

X-box 360

500

100

SDB

Caja de huevos

230

SDC

Aceite de girasol

219

SDD

Coca-cola 200ml

2,3

341

id_categora

nombre

TECNO

COMIDA

BEBIDA

Ahora veamos nuestro diagrama:

Pagos en la Base de Datos del Sistema de Facturacin

No entrar en muchos detalles sobre la tabla PAGO ya que este tema es muy
extenso. Inicialmente podemos considerar datos como Fecha del pago, el Monto pagado y el
Mtodo de pago que se us, ya sea efectivo, tarjeta de dbito, etc.
Cuando un Sistema de facturacin acepta varias formas de pago electrnico, es necesario
realizar una investigacin sobre bases de datos e-Commerce. Esta caracterstica expande ms
el concepto de pagos, generado nuevas tablas y relaciones en el modelo, lo cual queda en tus
manos si te encuentras en esa situacin.
Es importante tener en cuenta la forma en que se realizarn los pagos, ya que hay negocios
donde la factura debe pagarse en un solo pago, otros donde se debe hacer un solo pago pero
divido en porcentajes con diferentes formas de pago. Tambin existen acuerdos donde abonas
un poco al inicio y en otra fecha pagas el valor restante.
O en el caso de las compras por Internet, se debe generar una Orden que sincronice la Cuenta
del cliente, sus Pagos y el Envo del producto.
En mi caso eleg una forma muy sencilla de pago para terminar este articulo, donde el negocio
recibe un pago por los productos de la factura y puede usar varios mtodos de pago:

Podemos notar que un cliente tiene posibilitado pagar con varias formas de pago su compra, por
lo cual creamos una relacin uno a muchos entre MODO_PAGO y la factura.