Proyecto simple de bases de Datos

[gnzsoloyo]

Creo que va a ser mejor dar varios pasos atrás, hasta el mimo principio, porque hay cosas que no están correctamente planteadas, cosas que so habituales y que no estás poniendo, y cosas que estás poniendo y no están requeridas ni se puede inferir de las premisas del trabajo.

Lo primero que debes hacer es intentar sacar un resumen de la información importante, y en especial la relevante para el diseño de la base, para lo cual hay una cosa que debes hacer: Descarta toda referencia a listados, informes, reportes y consultas de usuario que existan. Esos componentes no son parte del diseño de la base, sino que deben ser soportados por la base, que no es la misma cosa.
¿Que quiere decir eso?
Que los reportes e informes, son temas procedimientales, y sólo sirven para establecer, por inferencia, qué datos que no figuran explicitamente en las reglas del negocio, se requerirán luego en la aplicación. Pero rara vez un reporte o informe define alguna estructura de la base (entiéndase estructura=tabla / relación).
Luego, todo lo que te digan sobre los reportes, es superfluo para el inicio del diseño.

En cuanto a las "fichas" que menciona al principio, sólo sirven para saber qué es lo que tienen hoy, y qué información registran. Pero no se transformará a esas en tablas, por lo que no deberás considerarlas como parte de las estructuras de la base. Sólo nos aportan conocimientos de los flujos de dato entrante y saliente en general, así como detalles de datos.
Pero nada mas.

Dicho esto, la base de datos tiene que ser estructurada en base a una abstracción del sistema, para lo cual tienes que identificar los elementos conceptuales principales. Pero a nivel abstracto. No debes pensar aún en tablas. Todavía no llegaste allí.

Tienes, seguro, estas entidades:
1) Empresa.
2) Sede
3) Empleado.
4) Proveedor.
5) Cliente
6) Producto.
Estas son entidades fuertes, de las que depende el sistema. Luego vienen:
7) Stock (vinculada a Producto y Sucursal).
8) Compra (vinculada a producto y proveedor, Generadora de Lote).
9) Venta (vinculada a Cliente y Factura).
10) Factura (vinculada a Cliente y Producto).

A estas se pueden sumar:
11) Pedido (relacionada con Factura y producto).
12) Remito (relacionada con Cliente y Factura).
13) Lote (es independiente de stock , producto y de compra, aunque se relaciona con las tres)

También pueden surgir nuevas tablas de las relaciones entre elementos:
14) Producto_Proveedor (si hay N proveedores para un mismo producto).
15) Empleado_Sucursal.

Ahora bien, en algunas de las entidades mencionadas hay cierto tipo de relaciones que sólo se vuelven visibles cuando normalizas, pero son evidentes para todos, simplemente porque siempre se construyen así.
Ejemplo: Factura.
Una Factura SIEMPRE se genera como un modelo Maestro/Detalle, donde la Factura contiene fecha, id de cliente, sucursal, numero de factura, y otros datos que van en el encabezado. Pero no llevan detalles referidos a los productos que se facturan, porque estos van en la tabla Detalle_Factura.
La tabla Detalle_Factura es la que contiene numero de factura, id de producto y cantidad.
¿Se entiende?

Ese mismo modelo Maestro<-Detalle, se aplica para Remito, Pedidos, Ordenes, Venta, y cualquier otra entidad que tenga una iteracion de ID+cantidad.

¿Va quedando claro?

En tu modelado, por otro lado, tienes una "normalización" qu eno se entiende, no tiene utilidad y no se ha pedido en ninguna parte de los documentos que posteas: Estás separando la Dirección de un Cliente en una tabla separada. Eso no está bien.
¿Por qué?
En primer lugar porque no lo piden. En ninguna parte de todo el documento se hace mención que un mismo cliente pueda tener N direcciones, y si no las tiene, entonces no existe más que una.
Por otro lado, un cliente, comercialmente, sólo debe poder declarar una única dirección comercial legalmente válida. Si declarase mas, sólo una debería estar vigente, porque es a esa a donde se enviarán los pedidos y las facturas.
Eso es el mundo real.
¿Que pasa si el cliente cambia la dirección?
Bueno, si es posible que suceda, entonces si se pone una tabla adicional, pero donde se almacenan las direcciones que han sido dadas de baja. La activa debe estar con el resto de los datos activos del cliente.
¿Se entiende?
Sólo los Teléfonos de un cliente, como también e-Mails, pueden tener tabla separada, porque eso sí es usual. Pero de todos modos en ese caso o poner un campo como flag de "Teléfono Principal", o bien los adicionales van en otra tabla, pero el principal va en la maestra.

Respecto a la factura y sus cancelaciones, eso es un tema clásico: La factura no implica el Pago... es sólo la emisión de un comprobante a cobrar. El Pago va por otro lado, es otra tabla, y se vincula a la cabecera de factura. A su vez el pago está relacionado con los modos de pago, que pueden ser múltiples: Efectivo, Tarjeta de Débito, Tarjeta de Crédito, Nota de Crédito, Cheque, Pagaré, etc.
¿Cuales son los válidos?
Bueno, eso es algo que debe ser definido por el cliente... eso no está determinado en los documentos que posteas, por lo que deberás decidirlo tu, y ponerlos al principio del trabajo, bajo el título de "Supuestos de diseño"o algo así. Es decir, son aquellas cosas que tu determinas porque no hay cliente a quien consultar.

Habrás notado que no he hablado de datos de las entidades. Bueno, a nivel de análisis conceptual, no son relevantes. Solo las debes ir poniendo si son necesarias para el Diagrama Entidad-Relación, y sí debes ponerlas antes de definir las estructuras de las tablas.
En el punto actual de lo que describo, solo las miro por encima.

Esto es sólo un acercamiento. Para que lleguemos a un diseño de tablas aún falta, y para normalizarlo más aun. Es la forma en que yo lo veo, mirando lo que dicen tus documentos.

Una nota: Hay cosas que no veo claramente definidas, y que sería bueno que expliques en un glosario. Es posible que tengan algún significado en España, pero aquí no, y no sé a que se refieren, como por ejemplo "Incidencias de Ventas".
¿Qué se supone que es una "incidencia" en ventas y compras?