Una sola tabla o dos tablas distintas?
Estoy rediseñando mi ERP y me entra la duda, después de casi 5 años utilizando el actual. Para presupuestos y facturas utilizo varias tablas:
Presupuesto
Presupuesto_Detalle
Presupuesto_Subdetalle
Factura
Factura_Detalle
Factura_Subdetalle
Cuando un presupuesto se ejecuta se convierte en factura, pero en tablas distintas, lógicamente. La pregunta es, lo habitual es hacerlo en tablas distintas o utilizar una tabla que pueda servir para ambos propósitos, es decir:
Presupuesto_Factura
Presupuesto_Factura_Detalle
Presupuesto_Factura_Subdetalle
¿Cómo lo véis más adecuado?
Hasta ahora, el hecho de tener tablas distintas me supone manejar una enorme cantidad de datos duplicados. Pienso que en teniendo un campo en el que se indique si el movimiento es presupuesto o factura podría servir, pero tengo dudas.
2 respuestas
Compara ambas tablas y analiza que campos las diferencian, normalmente basta con añadirles campos y en base a ellos reglas para evitar que sean modificables una vez que se les añada la propiedad 'factura' (que suele ser el campo con el numero de factura asignado), la fecha de su emisión y aquellas que se requieran, pues se les va a aplicar misma la metodología que ya existe.
A titulo de curiosidad ¿para qué se utiliza el tercer desglose?:
Presupuesto_Factura + Presupuesto_Factura_Detalle + Presupuesto_Factura_Subdetalle
Gracias como siempre Enrique.
Por un lado los campos son exactamente iguales para presupuestos como para facturas, de ahí la duda de hacerlo con una sola tabla para cada apartado.
El hecho de que tenga tres niveles es porque hay presupuestos y facturas de obra donde el subdetalle incorpora datos de un trabajo concreto (pej. demolición muro) que se engloba dentro del capítulo "demolición", por lo que cada trabajo lleva un precio distinto y el conjunto de esos trabajos están dentro de la categoría correspondiente, que tiene un sumatorio de todos los trabajos.
Gracias de nuevo!
Un saludo.
La tercera es un desglose de la segunda, podrían ir al mismo nivel si se añadiese un código que las aunase como familia, pero supongo que es una adaptación a la metodología de la empresa.
Un registro de una tabla puede estar relacionado con mas de una tabla, solo hay que añadir un campo común (y ese campo a mayores evita el duplicado de ese registro).
Un supuesto, genero una oferta a un cliente de diversos trabajos o productos.
Creo una venta (o una obra) y añado su ID a los aceptados de la oferta.
Según entrego los artículos/finalizo los trabajos los voy marcando como finalizados y quedan disponibles para facturar.
Creo la factura para lo cual selecciono aquellos registros que están marcados como finalizados y NO tienen numero de factura, a los que decida añadir a esa factura les añado el numero de factura.
Este dato es primordial, a partir del momento en que este campo (n_factura) tenga valor, el registro no es modificable.
Se tiene en el mismo registro la oferta inicial, su aceptación total o parcial (obra/venta), la factura y lo pendiente tanto de finalizar como de facturar, solo se ha de filtrar por el campo adecuado.
Seria interesante anular las ofertas fuera de plazo o rechazadas (que irían a la factura n_0).
Adaptar el esquema a lo que hay actualmente puede ser sencillo si se añade un campo (el numero de factura) y se le asignarle la que corresponda cruzando datos con los datos actuales.
Dado que hacienda exige mantener los datos contables por un tiempo (en España un mínimo de cinco años), el volumen de datos puede ser considerable y desperdigados son mas difíciles de manejar.
Innegablemente es un esquema simplificado, pero no precisa complicarse mucho mas.
Eduardo, tengo un programa de elaboración y control de proyectos u obras, la base de datos está en PostgreSQL pero el fronend está en Access, en este manejo capitulos, subcapitulos, conrol de materiales, informes avance de obra y mucho más, como no puedo subir imágenes le dejo la idea.
Expicación breve del objeto de la aplicación
Los pasos para hacer una cotización son:
- Crear los materiales que se manejan en la construcción, estos pueden ser miles y son los que conforman cada uno de los grupos (Herramientas, Materiales, Mano de Obra y Transporte).
- Crear las unidades de medida. En este ejemplo no está el formulario, pero está la tabla.
- Crear los contratantes y contratistas, Estos formularios hacen falta.
- Falta el campo de la ciudad donde se va a desarrollar la obra, pero así funciona el ejemplo
- Crear los APU maestros
- Crear el APU por cotización (Toma los materiales del APU maestro)
- Crear los capítulos que componen el APU, es decir, 1,2,3,4,…. Etc
- Crear las alternativas o subcapítulos, es decir, 1.01, 1.02, ……. 2.01,2.02,……2.01,3.01, 3.02,..etc
- Crear los materiales que conforman cada alternativa o subcapítulo. Observe como al seleccionar un material se activa un formulario filtrado por tipo de material, para facilitar la búsqueda y seleccionar el material. Igualmente, observe como se controla que no se repita el material en el subcapítulo.
- Ya se puede imprimir el APU. Observe los niveles de agrupación y la consulta origen de los datos, ahí está la clave.
- Después de crear el APU se ubica sobre éste y damos clic sobre el botón Cotizar, se abre un formulario con 2 carpetas, una con los datos básicos de la cotización y otra con los subcapítulos pero consolidados, (son los mismos creados en el APU) aquí solo se ingresan las cantidades y mano de obra unitario, si en la primera carpeta datos básicos se parametrizó con mano de obra en Sí, el sistema automáticamente hace el cálculo. Observe que desde este formulario puede imprimir el APU, la cotización y el consolidado del material, este último informe es muy importante porque le indica al ingeniero que material necesita comprar el valor unitario.
Los subcapitulos es algo parecido a su pregunta.
Muchas gracias Eduardo. Después de leer con atención el texto de tu mensaje creo que el nivel de profesionalidad de tu programa es excelente en comparación con el mío. Decirte también que la actividad principal de mi empresa es la gestión integral de viviendas en alquiler de larga estancia. Las obras suponen un servicio adicional y suelen ser algo más sencillas de lo que representa las múltiples facetas y posibilidades que veo en tu programa. No me veo programando a ese nivel y creo que tendría un ERP infrautilizado. Te agradezco enormemente la aportación y ojalá algún día las obras nos requieran de un software tan avanzado como el tuyo. Gracias!
Éxitos en su proyecto.