Club Builder

[ercea]

Hola a todos, tengo mi programa ya prácticamente terminado, y gran parte del éxtio os lo debo a vosotros por la gran cantidad de información que teneis y, cuando no hay, proporcionais .

Vereis, ya tengo el programa probándolo en la empresa y todo, pero hoy me ha surgido una pequeña duda, no obstante importante.

Vereis, el programa genera presupuestos, abaranes y facturas de tres tipos de artículos (máquinas, recambios y taller). Según la empresa, puede ocurrir varias casos:

-El cliente pide un presupuesto, si este lo acepta, se le genera luego un albarán, cuadno pague, se le hace una factura

-El cliente compra algo directamente, se puede, o bien generar un albaran y cuando pague generar una factura, o bien hacerle directamente una factura.

Entonces en mi programa en estos casos tengo puesto un checkbox, para presupuestos llamado "Presupuesto aceptado", si se marca y pulsa el botón "Aceptar", pues guarda ese presupuesto y en la base de datos, traspasa toda la info en el formulario "Nuevo albarán" y se le muestra dicho formulario para que lo genere. Idem con los albaranes, un checkbox llamado "albarán facturado", que si se marca y se pulsa aceptar, se guarda el albarán y se traspasa su contenido a una factura y se muestra dicho formulario.

Bien, todo funciona perfectamente, pero ahora me viene una cuestion. Realmente, un albarán no puede facturarse más de una vez no?, es decir, llega un cliente para pagarme un albarán, cojo su albarán en la base de datos, lo edito para marcar "Albarán facturado" y le hago una factura.... pero ya ese albarán no debería de poder editarse no?, el programa no deberiá de dejar volver a facturar ese albarán no?. En caso afirmativo, pensé para su solución, en que cuando edite el albarán lea ese registro, si tiene el campo alb_facturado a 1, que salte una excepción avisando que no puede editar ese albarán porque ya ha sido facturado... pero no me parece una solución correcta, ya que si por alguna casualidad, crea un albarán, y marcar "sin querer" albarán facturado cuadno realmente no se ha hecho... ya la empresa no podrá corregirlo. Y peor aún, si marco "albarán facturado", pero luego en el formulario de factura cancelo... ya ese albarán queda como facturado cuando realmente no lo está.

Entonces pensé en tener referenciado albarán con factura... es decir en factura guardar el código del albarán como clave foránea. Así, al marcar "albarán facturado" al crear la nueva factura, almaceno tambien el albarán al que pertenece, y si luego quiero editar ese albarán busco en facturas el codigo del albarán, si existe alguna factura con ese código... entonces no puede editarlo porque ya ha sido facturado. Pero claro, esta solución plantea otro problema... ¿que ocurre cuando la empresa cree directamente una factura? No tiene clave foranea y daría un error...

En fin, solución que ahora mismo tengo en mente.... guardar el código del albarán pero sin que sea clave foranea... simplemente que se almacene como un dato más de la factura, y que pueda ser Nulo (para el caso de crear una factura directamente).

Siento este tocho, intento explicaros lo más detallado posible la situación y me gustaría que compartierais comigo vuestras experiencias, ya que realmente es mi primer programa de cara al público (es un PFC pero lo va a usar una empresa) y no es plan de que tenga fallos y mucho menos relacinoados con el tema de facturación, que es lo que luego la empresa declara xD.

Gracias de nuevo a todos por vuestra ayuda, un saludo

[Cesar C. Salazar Gonzalez]

Hola Ercea, veo que tienes algunas dudas, sobre relaciones de tablas, creo que puedo darte una idea, sin tener que moverle tanto a tu diseño de base de datos.. empecemos por analizar los documentos, algunas veces he dicho que los softwares son Ingenieria Inversa de Resultados (presupuestos, albaranes ?, Facturas) (establezco un signo de Interrogación pues por America Latina no es muy común el térmno Albaran)

Esto mas que codigo depende del diseño de la base, como considero que usas maestro detalles, quiero manejar las siguientes "formulas" si asi podemos llamarles.

Tienes un Presupuesto (Resultado a Obtener), este presupuesto contiene 2 partes

1.- la parte "Maestra" donde viene la fecha, la hora y el encabezado del presupuesto.
2.- la parte del "Detalle" donde viene la descripción del cuerpo del presupuesto, articulos, herramientas etc etc, que sé yo el contenido del presupuesto, pero le denominaremos detalle.

Ahora bien, vamos a generar un Albaran (aun no tengo idea que es, pero voy a buscar en google) bien regresando de Google, es una nota de Remisión donde se le entrega al cliente, en america latina se conoce como (Nota de Remision ó Ticket), este a su vez contiene una parte "Maestra" y una parte "Detalle" esta ultima es la misma que la del presupuesto y los analizamos de nuevo

1.- la parte "Maestra" donde viene la fecha, la hora y los datos de la empresa, o cliente del Albaran (je je ahora si ya se que es, )

2.- la parte del "Detalle" donde viene la descripción de articulos, herramientas ( que es la misma del presupuesto )

Ahora bien, vamos a la parte de la Factura, que tambien contiene esto de la parte "Maestra" y la parte "Detalle" y que seguiremos tomando los datos del presupuesto o del Albaran, por que alguien puede comprar entregarle un Albaran y posteriormente una Factura, o alguien puede llegar y Pedir un presupuesto -> luego el Albaran -> y por ultimo la factura.

1.- la parte "Maestra" donde viene la fecha, la hora, Datos del cliente para la facturacion, nombre de la empresa.

2.- la parte del "Detalle" Los articulos que hay que facturar o que son facturados.

jeje despues de este "breve" recorrido por los resultados a obtener, ahora pasamos a la parte de las tablas,

A mi forma de ver las cosas, debes contener 4 tablas, de la siguiente manera

Tabla 1: Presupuesto (Tabla Maestra, contiene el encabezado del presp)
Tabla 2: Albaran (Tabla Maestra, contiene el encabezado del albaran)
Tabla 3 : Facturas (Tabla Maestra, contiene el encabezado de la Fact)
Cada una de estas tablas (3 anteriores), contienen un ID campo unico que las identifica, para sus datos.

Tabla 4: Detalles Tabla que contiene los registros de cada una de las piezas que conforman el presupuesto, albaran y Factura.

Ahora, como le hacemos para determinar que productos pertenecen a cada cosa (Presupuesto, Albaran o Factura), pues la manera mas fácil es establecer dentro de esta tabla 3 campos mas que sirvan para guardar los "ID"s de las 3 tablas anteriores,

ahora el ejemplo real,
Presupuesto No 4567 <- puede ser el ID o algun otro campo num.
Albaran No. 778 <- puede ser ID o algun otro campo Num.
Factura No. 983 <- ID o algun otro campo numerico.

Cada uno de esos campos se van almacenar en los registros de la tabla "Detalles"

[ercea]

Hola César de nuevo, muchísimas gracias por tu respuesta, me ha aclarado más las cosas ya que mi diseño era algo distinto. Las tres tablas maestras las tengo como tales, pero los detalles tengo una por cada tabla maestra, es decir, tenia

Tabla 1: Maestra Presupuesto
Tabla 2: Detalles del presupuesto
Tabla 3: Maestra Albarán
Tabla 4: Detalles Albarán
...

Y la verdad que ahora que me lo has explicado bastante bien, veo razonable el tener solamente una tabla detalles y relacionarlas con las maestras. Es más me facilitará el trabajo al a hora de "traspasar" de un presupuesto a un abarán, o de un albarán a una factura, ya que tan solo tendría que crear un registro en la tabla maestro y luego rellenar su respectivo campo en la tabla detalles, ¿no es asi?. Además así se garantiza siempre que haya una sola factura para un albarán (si el campo id_factura de detalles de ese albarán no está vacío es porque ya se ha facturado)... en fin, gracias por mostrarme la luz jeje.

En fin, lo que no sé es si tendré que hacer muchos cambios en el programa, espero que no jeje, haré una copia d seguridad por si acaso y me pondré a ello

Lo dicho muchas gracias amigo

saludos!

EDITO: Una sola pregunta, estos tres campos (los id de cada documento) en la tabla detalles¿son claves foráneas a sus respectivas tablas maestras?

[Cesar C. Salazar Gonzalez]

Podrian ser claves foraneas, pero si te das cuenta son campos que solo sirven para "Filtrar" los datos dependiendo del tipo de documento (Presupuesto, Albaran, Factura)

Intenta primero usarlos como campos normales tipo "INTEGER", pero ahi si ya viene a consideración del desarrollador.

Claro y un poco de tiempo extra en modificar algunas cosas del sistema, jeje

Saludos y en lo que pueda ayudarte estamos en contacto. y claro una copia de seguridad (backup) del tus originales y de la base de datos por si consideras algo complicado, pero es mejor que lo hagas de una vez a que posteriormente tengas que hacerlo cuando el sistema se vuelva más complejo y ya sea muy Difícil cambiarlo
_________________

[ercea]

Bueno César sólo queria comentarte que ya está todo solucionado ^^. Gracias por todo amigo , ahora falta que me den el visto bueno, y mientras a documentar!

saludos!

EDITO: Una pequeña pregunta,¿sabes de algún buen programa para crear DFD's (diagramas de flujo de datos)? El único que conozco y tego es DIA pero para UML está muy bien, pero para DFD's no me gusta mucho :S

saludos!

[Cesar C. Salazar Gonzalez]

El EMS Manger es muy bueno y uno de los mas completos, para lo que gustas.
_________________