Volver a la arquitectura

Modelo de datos · modelo de partida (v1)

Cómo se conectan las tablas

Las cinco tablas iniciales con todos sus campos, más tres tablas puente que faltaban (con borde punteado) y que surgen al programar las relaciones. Las líneas con flecha indican qué tabla apunta a cuál.

Esta página es el punto de partida: el esquema inicial y las tablas puente que faltaban. El modelo vigente y oficial —que separa producto de variante y completa la parte legal— es Las tablas del negocio →. Si algo aquí contradice esa página, manda esa página.
Catálogo Proveedor Cliente Factura Empleado Tablas que faltaban
distribuidorEl proveedor (China)
  • PK id_distribuidor
  • · nombre
  • · pais
  • · ciudad
  • · direccion
  • · codigo_postal
  • · email
  • · telefono
  • · horario_atencion
producto_distribuidorTabla puente
  • PK id
  • FK id_producto
  • FK id_distribuidor
productoCatálogo
  • PK id_producto
  • · categoria
  • · facilidad_venta
  • · demanda
  • · unidades_por_caja
  • · precio_compra
  • · precio_venta
  • · precio_mercado
  • · peso_unidad
  • · dimensiones_unidad
  • · stock (calculado)
  • · fecha_proximo_pedido
movimiento_inventarioCalcula el stock
  • PK id_movimiento
  • FK id_producto
  • · tipo (entra/sale)
  • · cantidad
  • · fecha
  • · referencia
detalle_facturaTabla puente · los productos de cada venta
  • PK id_detalle
  • FK id_factura
  • FK id_producto
  • · cantidad
  • · precio_unitario
empleadoEquipo · cuenta intranet
  • PK id_empleado
  • · nombre
  • · apellidos
  • · password (hash)
  • · dni
  • · puesto
  • · direccion
  • · lugar_trabajo
  • · rol
  • · correo
  • · estado
  • · ultimo_login
  • · horario
facturaFacturación · base principal
  • PK id_factura
  • FK id_cliente
  • FK id_empleado
  • · portal
  • · fecha_creacion
  • · fecha_envio
  • · precio_total
  • · metodo_pago
clienteVentas
  • PK id_cliente
  • · nombre
  • · tipo
  • · ciudad
  • · pais
  • · direccion
  • · codigo_postal
  • · telefono
  • · correo

Cómo se leen las conexiones

1 → Nfactura → cliente. Cada factura es de un cliente; un cliente puede tener muchas facturas.
1 → Nfactura → empleado. Quién hizo la venta. En la tienda física es un empleado; en la web puede ir vacío (el cliente compra solo).
puentedetalle_factura. Una factura lleva varios productos, así que cada producto vendido es una fila aquí, con su cantidad y su precio. Corresponde a lo que en el esquema inicial se llamaba «lista productos».
puenteproducto_distribuidor. Como un producto lo puede traer uno o varios distribuidores, el enlace vive aquí. Por eso ya no hace falta el campo "id_distribuidor" dentro de producto.
stockmovimiento_inventario → producto. Cada entrada (compra) y salida (venta) se anota aquí, y el stock disponible se calcula sumando. Así nunca queda mal.

Lo que cambió. La factura incorpora el campo portal (web / tienda física). Las tres tablas de borde punteado —detalle_factura, producto_distribuidor y movimiento_inventario— son las que faltaban: las dos primeras resuelven las relaciones de «uno o varios», y la tercera hace que el stock sea siempre correcto y auditable.

Cómo evolucionó esto: al diseñar a fondo se vio que el producto con versiones (una pintura en 5 colores, un pincel en 3 tamaños) necesita partir producto en producto + variante, porque el SKU, el stock y el precio son de cada versión, no del producto en general. Y la facturación electrónica añade a la venta el tipo (boleta o factura) y la serie/correlativo de SUNAT. Todo eso ya está resuelto en el modelo oficialLas tablas del negocio—, que es el que se implementa. Esta vista se conserva para entender de dónde se partió.