Continuando con las ideas, y ya fuera de horario de trabajo, trataré de exponerte un par de conceptos respecto a los movimientos de cuentas, en cuanto a ventas, facturación y pagos que puedan orientarte al respecto, como para que tu solución no termine dispersando información que no deba estar en diferentes tablas.
Supongamos que tienes ya Clientes. La diferenciación de si son Personas físicas o Jurídicas no hace realmente al fondo de la operación comercial, porque lo que realmente tiene impacto es la carga impositiva que debe agregarse a los importes facturados.
Siendo que estás, en Santa Fe, en el mismo país, lo mencionaré como IVA e IGB. Supongo que con eso alcanza.
Todo cliente, tiene una posición ante el IVA y eso determinará lo que se le impute de impuestos al respecto. En cuanto al IGB, eso tiene dos determinantes: 1) el domicilio de facturación y 2) la inscripción en el Mulitilateral.
Si en IGB estás sólo en una provincia, o tienes el IGB local o tienes el multilateral; pero si estás en más de más de una, las alícuotas de los IGB cambian en cada provincia, lo mismo que algunos impuestos.
esto hace que necesites al menos tres tablas para determinar los impuestos aplicables: 1) La nomina de impuestos y 2) La tabla de Entidades impositivas (incluyendo los impuestos y tasas de la ciudad, 3) las condiciones impositivas, en función del impuesto y el organismo recaudador.
Obviamente, deberás tener una o más tablas fijas para ciudades y Provincias, pero eso ya lo debes haber tenido en cuenta.
Esto sólo para poder averiguar qué impuestos se le aplicaran al momento de facturar, y aún no facturamos.
Luego, a nivel de facturación debes tener en cuenta que la facturación no implica cobranza, en especial cuando un Cliente puede tener Cuentas de diverso tipo.
Entonces, cuando vemos al cliente desde su acción comercial, un cliente es una entidad que genera movimientos únicamente por Venta, no por Compra. Es decir, si la misma persona es cliente y proveedor, son entidades distintas. No se tiene en cuenta ambas cosas para la misma lógica, porque entre otras cosas, pertenecen a subistemas independientes.
El cliente realiza una compra (Venta del sistema), la que genera: 1) Una Factura, 2) Un detalle de factura, 3) Un movimiento de cuenta del cliente donde se vincula la factura (no el detalle), 4) Un documento de Pago, el cual a su vez puede tener diferentes estados (Pagado, Pendiente, Informado, Cancelado, por ejemplo). Según el estado del documento de pago, será la imputación luego a Banco, Caja, Tarjetas, etc. Pueden existir incluso movimientos compensatorios, pero eso es otro cantar y más complicado.
Como sea, hasta allí tenemos:
- Factura
- DetalleFactura
- DocumentoPago
- DetallePagoDocumentos (opcional, si un mismo pago abarca más de una factura)
- EstadosDocumento
- MovimientosCuenta
- CuentaCliente
- MediosPago
- Caja
- PagoEntidades (aprobaciones de tarjetas de credito, debito, otros medios)
- Entidades (las dueñas o proveedoras de las tarjetas, incluyendo bancos)
- PeriodosFacturacion (para las cuentas corrientes)
- ... y no se si me olvido de alguna (
)
En este momento tu posiblemente preguntes: ¿métodos de pago de cliente?
Esas son VIEWs, no tablas. Es decir, son vistas de BBDD para ciertos usos, pero por definición, un mismo cliente puede usar tantos medios de pago como acepte la empresa y / o tenga el cliente para pagar. Predefinir eso, no existe. Como mucho se debería registrar si la cuenta (CuentaCliente) es de pago por débito automático (se obtiene de MediosPago), y de se así se usan columnas flag para saber qué tipo de medio de pago se usará para ese cobro.
Hay muchas partes de esto que se resuelven luego en la lógica diseñada de los stored procedure.
Vale decir, la información que se usa para reportes
no necesariamente representa tablas independientes (generalmente NO SON TABLAS), sino que se generan dinámicamente en las consultas.
¿Por qué?
Por dos razones básicas: 1) No tiene sentido almacenar información cambiante en el tiempo, y 2) Al generarse en modo dinámico, los datos
siempre están actualizados y se puede evitar representar información que ya no resulta útil (caso, las facturas correspondientes a periodos contables que no se reportarán más).
En la empresa en que trabajo existen varios packages (usamos Oracle), con centenares de SP y SF que realizan estas validaciones, de modo que el sistema simplemente le envía a la base lo que debe cobrarse y son esos SP los que generan todas las validaciones e inserciones correspondeintes.
Y el pero de todos los SP es el de facturación (analizarlo completo llevaría semanas), ya que debe revalidar todo para obtener lo que necesita, simplemente para emitir un ticket.
Por allí tu preguntes ¿no es demasiado complicado?
...Bueno, te estoy dando una descripción simple. MUY simple. Los verdaderos sistemas de ventas son muchísimo más complejos.
Acá apenas te estoy describiendo un caso sacado de los apuntes y prácticas de clase, al momento en que cursara la asignatura.
En definitiva: Más allá de que esto te sea útil, debes tratar de simplificar las estructuras de las entidades, de modo que la base tenga la menor cantidad de tablas posible. Poner de más, sólo te traerá complicaciones (lamentablemente eso se aprende con la práctica, los libros no ayudan mucho).
Algunos de consejos muy básicos:
1) Si en la misma tabla ciertos campos aparecen como nulos en varios registros, es señal de que se debe normalizar, y separar esos datos en una tabla dependiente. Pero esa tabla no debe tener clave propia, sino que hereda la de su tabla madre.
2) Concentra las entidades que representen LO MISMO a nivel lógico. Que dos entidades tengan iguales datos no implica que sean lo mismo. Son iguales sí y sólo si se trata del mismo objeto (autos y motos son vehículos, y tienen datos comunes, pero no son iguales).
3) No geners una misma estructura de base para todos los subsistemas. Proveedores y Clientes no deben estar en la misma estructura de base (esquema), aunque compartan ciertas tablas, o pertenezcan al mismo esquema global. Esto al menos por dos motivos: 1) No tienen el mismo sistema administrativo, ni requisitos, 2) No están afectados por las mismas documentaciones comerciales (sus facturas no son las nuestras, y por tanto deben registrarse en base a otros atributos).
De hecho, y como dato final, el esquema de Cobranzas, no debería pertenecer al mismo esquema que Ventas, ya que también suele tener un circuito administrativo distinto. Si observas la organización de cualquier empresa chica (PyME), verás que las áreas de Ventas, Proveedores y Cobranzas, son funciones con circuitos y personas con funciones separadas....
Bueno. Espero que este pantallazo te sirva de algo.
