Cita:
Iniciado por jesusjj 
Buenos días:
Lo primero de todo, muchas gracias, ahora tengo que asimilarlo con calma en casa.
De todas maneras me han surgido un par de dudas/consultas:
1- la tabla temporal y la final de detalle, no tienen los mismos campos, ya que la primera la relleno sin idPresupuesto ( por si interesa, tengo planteado cómo lo relleno en:
http://www.forosdelweb.com/f127/cons...racias-774188/ ). El tema es que idPresupuesto se forma después del registro de la cabecera.
2- No me queda claro el concepto de 'SUBITEM' en general. Hasta ahora no había utilizado nada de todo esto, ya que lo hacía directamente por código, pero me parece más estable hacerlo en BBDD directamente, sobretodo, si tengo la posibilidad de ponerle un rollBack, por cualquier posible fallo de conexión, durante el proceso, que me podría dejar presupuestos 'rotos'.
De todas maneras, cuando llegue a casa, me sentaré a 'meditarlo' y a 'asimilarlo'.
Muchas gracias de nuevo.
Saludos.
En esencia, un
presupuesto, es un documento similar a una
factura con la diferencia que no tiene valor contable, y por lo tanto no genera transacciones en Caja, Banco, Cuentas a Cobrar, recibos, ni ningún otro tipo de documento que implique transacciones de valores.
Pero tiene similitudes en al menos dos cosas:
1. Contiene los datos del cliente o destinatario, con sus datos de número de presupuesto, fecha y opcionalmente condiciones impositivas del cliente.
2. Contiene un listado de items que se estén presupuestando, sean estos servicios o productos.
Esto implica que hay al menos dos tablas involucradas en la generación de un presupuesto: Presupuesto y Presupuesto_Detalle, por darles algún nombre.
Ahora bien, al igual que en la factura, un mismo registro de Prespuesto debe estar relacionado con uno o más de Presupuesto_detalle. Esto quiere decir que el número de presupuesto debe estar en los registros del detalle como FK. El problema es cómo hacer para identificar unívocamente los registros del detalle. Hay al menos dos formas
- Puedes usar el ID del producto o servicio. Es funcional, siempre y cuando no se pongan en el mismo presupuesto dos veces los mismos productos con diferencias de precios o cantidades, cosa que en un presupuesto es posible dadas ciertas circunstancias (como descuentos, ofertas y otras cosas así).
- Puedes numerar las líneas del presupuesto. Es lo más simple y no produce ningún tipo de problemas respecto al contenido.
Así pues, la PK de Presupuesto_detalle debería ser: nroPrespuesto + nroSubItem.
¿Se comprende la idea?
Cita: 1- la tabla temporal y la final de detalle, no tienen los mismos campos, ya que la primera la relleno sin idPresupuesto (...). El tema es que idPresupuesto se forma después del registro de la cabecera.
Eso no tiene absolutamente ninguna importancia. El SP que te propongo inserta primero el registro en presupuesto e inmediatamente recupera el ID creado, asignándolo al mismo campo INOUT del prototipo del SP. Con eso, no solamente lo genera, sino que lo devuelve.
Luego lo pone como constante en el nuevo INSERT... SELECT..., éste último debe ser específico y poner dos valores como constantes: el ID del presupuesto y cero (0) para el subitem, y en la tabla hay que indicar los campos que se insertarán (hay una forma de hacer que la numeración se genere en el mismo SELECT). Al insertarse los registros, el TRIGGER los irá numerando uno por uno en la medida que van llegando a la tabla.
Puedo asegurarte que el método es funcional. Lo uso hasta con tablas de 10.000 registros y ni pestañea.
El único secreto es cómo manejarás la transacción: o la haces dentro del SP, o la invocas antes de llamarlo, en la aplicación.
Eso es una decisión de diseño: hazlo como quieras, de todos modos funcionará.
