Factura, líneas de facturas, artículo

Hola Bingen
Muy buena tu inquetud...
Si hablamos de POO (programacion orientada a objetos) es un tema, si
hablamos de las relaciones en la DB (base de datos) es otro tema y
tambien habria de no ponerse tan "puristas" de la POO sino mas bien ver
el ambiente y llegar a una conclusion

Bueno.. cias todo en la vida la respuesta es DEPENDE ;)
Mira todo los temas que se desprenden
- Si vas a eliminar los articulos es una tema
- Si van a cambiar los precios .. (seimpre cambian) tambien
Imaginate aqui que veas una factura antigua con el precio nuevo :(

Una cosa es modelar tus objetos de negocios y luego otra es como mapear
esos objetos de negocios a tu base de datos relacional.. por ahora ;),
y alli es que puede venir estos SALTOS que nos hacen dudar a mas de
uno...
Bueno.. respuesta "sacrificios" por no decirlo de otra manera, tenes
que ver la mejor opcion (estrategia) para no peder informacion y a la
vez mantener nuestros datos

Bueno en todos estos temas hay estretegias a seguir.. primeramente el
tema del precio...luego si guardaras historial (ya sea de clientes,
articulos, etc) y todo depende de tu "universo" o sea tu ambiente

Lo que si es claro que la FACTURA es una foto en un momento dato de un
articulo ok
Pero tambien tienes que acordarte que se pueden ANULAR las facturas o
sea esa factura existe pero no tiene implicancia legal pero debe estar
ene l sistema, y los articulos tendran que volver a ciclo de compras
para su venta; o cuando se ELIMINA la factura alli la factura ya no
existe mas

Ahora otro tema es el stock¿? muchas veces hacen que el stock sea una
simple campo CANTIDAD en una tabla articulos y la verdad el stock es
una serie de movimientos de entrada y salida de facturas de proveedores
y de clientes o sea es una suma (y resta de esas cantidades).. si es un
simple campo no es "natural" mantenerlo

Espero que te sirva de ayuda o guia
_______________________
Jose A. Fernandez



Bingen ha escrito:

Hola a todos:

Mi pregunta es la siguiente, la verdad que podría colgarse en cualquier otro
lenguaje pero...

tenemos una clase Factura que agrupa líneas de factura. Estas líneas de
factura tienen una cantidad y una relación con un artículo.

Mi duda es la siguiente, si la línea la relacionamos con un artículo (nos da
la información de descripción de artículo, código artículo precio), es decir
tenemos una propiedad en la clase línea que es un objeto artículo, nuestro
sistema está obligado a no dejarnos borrar artículos ¿verdad?, porque si no,
todas las líneas de facturas que contengan dicho articulo, quedan inutiles ¿
no?.

¿ Que filosofia empleais vosotros ?

otra cosa, algún sitio de discusiones de UML (o preguntas similiares...)

Un saludo, y gracias por vuestro tiempo !!!

Bix

Hola, ante todo gracias por tu respuesta.

Como bien comentas, mis inquietudes estan relacionados con la POO y en
consecuencia luego con las BD relacionales a la hora de mapear los objetos.

Sobre la relación de los artículos con las líneas de factura he decidido lo
siguiente:

- Crear una propiedad precio a las líneas de factura y a la hora de
relacionar el artículo con la línea, guardar en esta propiedad el precio
vigente (por si cambia posteriormete, que como bien me comentas, siempre
cambia, todo sube en esta vida, ;)
- No dejar borrar artículos y pero ponerles una propiedad llamada
descatalogado para indicar que están en estado de "borrado". (Gracias a
Hernan, por el comentarío en el foro de csharp)

En cuanto a la cantidad de la línia y el stock, por la naturaleza de mi
programa no requiere mayores pretensiones y no implementará stock.

Gracias por tu tiempo, un saludo
Bix




"Jose A. Fernandez" escribió en el mensaje
news:
Hola Bingen
Muy buena tu inquetud...
Si hablamos de POO (programacion orientada a objetos) es un tema, si
hablamos de las relaciones en la DB (base de datos) es otro tema y
tambien habria de no ponerse tan "puristas" de la POO sino mas bien ver
el ambiente y llegar a una conclusion

Bueno.. cias todo en la vida la respuesta es DEPENDE ;)
Mira todo los temas que se desprenden
- Si vas a eliminar los articulos es una tema
- Si van a cambiar los precios .. (seimpre cambian) tambien
Imaginate aqui que veas una factura antigua con el precio nuevo :(

Una cosa es modelar tus objetos de negocios y luego otra es como mapear
esos objetos de negocios a tu base de datos relacional.. por ahora ;),
y alli es que puede venir estos SALTOS que nos hacen dudar a mas de
uno...
Bueno.. respuesta "sacrificios" por no decirlo de otra manera, tenes
que ver la mejor opcion (estrategia) para no peder informacion y a la
vez mantener nuestros datos

Bueno en todos estos temas hay estretegias a seguir.. primeramente el
tema del precio...luego si guardaras historial (ya sea de clientes,
articulos, etc) y todo depende de tu "universo" o sea tu ambiente

Lo que si es claro que la FACTURA es una foto en un momento dato de un
articulo ok
Pero tambien tienes que acordarte que se pueden ANULAR las facturas o
sea esa factura existe pero no tiene implicancia legal pero debe estar
ene l sistema, y los articulos tendran que volver a ciclo de compras
para su venta; o cuando se ELIMINA la factura alli la factura ya no
existe mas

Ahora otro tema es el stock¿? muchas veces hacen que el stock sea una
simple campo CANTIDAD en una tabla articulos y la verdad el stock es
una serie de movimientos de entrada y salida de facturas de proveedores
y de clientes o sea es una suma (y resta de esas cantidades).. si es un
simple campo no es "natural" mantenerlo

Espero que te sirva de ayuda o guia
_______________________
Jose A. Fernandez



Bingen ha escrito:

Hola a todos:

Mi pregunta es la siguiente, la verdad que podría colgarse en cualquier
otro
lenguaje pero...

tenemos una clase Factura que agrupa líneas de factura. Estas líneas de
factura tienen una cantidad y una relación con un artículo.

Mi duda es la siguiente, si la línea la relacionamos con un artículo (nos
da
la información de descripción de artículo, código artículo precio), es
decir
tenemos una propiedad en la clase línea que es un objeto artículo, nuestro
sistema está obligado a no dejarnos borrar artículos ¿verdad?, porque si
no,
todas las líneas de facturas que contengan dicho articulo, quedan inutiles
¿
no?.

¿ Que filosofia empleais vosotros ?

otra cosa, algún sitio de discusiones de UML (o preguntas similiares...)

Un saludo, y gracias por vuestro tiempo !!!

Bix

Ok Bingen
Si quieres un libro sobre mapeo de nuestros queridos objetos a
relacional tienes este
An Advanced Course in Database Systems: Beyond Relational Databases
Suzanne W. Dietrich and Susan D. Urban
Department of Computer Science and Engineering
Ira A. Fulton School of Engineering
Arizona State University
Published by Prentice Hall, 2005
ISBN 0-13-042898-1
http://www.eas.asu.edu/~advdb/

(que lo estaba leyendo para una maestria que estoy cursando)

Un abrazo
_____________________
Jose A. Fernandez


Bingen wrote:

Hola, ante todo gracias por tu respuesta.

Como bien comentas, mis inquietudes estan relacionados con la POO y en
consecuencia luego con las BD relacionales a la hora de mapear los objetos.

Sobre la relación de los artículos con las líneas de factura he decidido lo
siguiente:

- Crear una propiedad precio a las líneas de factura y a la hora de
relacionar el artículo con la línea, guardar en esta propiedad el precio
vigente (por si cambia posteriormete, que como bien me comentas, siempre
cambia, todo sube en esta vida, ;)
- No dejar borrar artículos y pero ponerles una propiedad llamada
descatalogado para indicar que están en estado de "borrado". (Gracias a
Hernan, por el comentarío en el foro de csharp)

En cuanto a la cantidad de la línia y el stock, por la naturaleza de mi
programa no requiere mayores pretensiones y no implementará stock.

Gracias por tu tiempo, un saludo
Bix




"Jose A. Fernandez" escribió en el mensaje
news:
Hola Bingen
Muy buena tu inquetud...
Si hablamos de POO (programacion orientada a objetos) es un tema, si
hablamos de las relaciones en la DB (base de datos) es otro tema y
tambien habria de no ponerse tan "puristas" de la POO sino mas bien ver
el ambiente y llegar a una conclusion

Bueno.. cias todo en la vida la respuesta es DEPENDE ;)
Mira todo los temas que se desprenden
- Si vas a eliminar los articulos es una tema
- Si van a cambiar los precios .. (seimpre cambian) tambien
Imaginate aqui que veas una factura antigua con el precio nuevo :(

Una cosa es modelar tus objetos de negocios y luego otra es como mapear
esos objetos de negocios a tu base de datos relacional.. por ahora ;),
y alli es que puede venir estos SALTOS que nos hacen dudar a mas de
uno...
Bueno.. respuesta "sacrificios" por no decirlo de otra manera, tenes
que ver la mejor opcion (estrategia) para no peder informacion y a la
vez mantener nuestros datos

Bueno en todos estos temas hay estretegias a seguir.. primeramente el
tema del precio...luego si guardaras historial (ya sea de clientes,
articulos, etc) y todo depende de tu "universo" o sea tu ambiente

Lo que si es claro que la FACTURA es una foto en un momento dato de un
articulo ok
Pero tambien tienes que acordarte que se pueden ANULAR las facturas o
sea esa factura existe pero no tiene implicancia legal pero debe estar
ene l sistema, y los articulos tendran que volver a ciclo de compras
para su venta; o cuando se ELIMINA la factura alli la factura ya no
existe mas

Ahora otro tema es el stock¿? muchas veces hacen que el stock sea una
simple campo CANTIDAD en una tabla articulos y la verdad el stock es
una serie de movimientos de entrada y salida de facturas de proveedores
y de clientes o sea es una suma (y resta de esas cantidades).. si es un
simple campo no es "natural" mantenerlo

Espero que te sirva de ayuda o guia
_______________________
Jose A. Fernandez



Bingen ha escrito:

> Hola a todos:
>
> Mi pregunta es la siguiente, la verdad que podría colgarse en cualquier
> otro
> lenguaje pero...
>
> tenemos una clase Factura que agrupa líneas de factura. Estas líneas de
> factura tienen una cantidad y una relación con un artículo.
>
> Mi duda es la siguiente, si la línea la relacionamos con un artículo (nos
> da
> la información de descripción de artículo, código artículo precio), es
> decir
> tenemos una propiedad en la clase línea que es un objeto artículo, nuestro
> sistema está obligado a no dejarnos borrar artículos ¿verdad?, porque si
> no,
> todas las líneas de facturas que contengan dicho articulo, quedan inutiles
> ¿
> no?.
>
> ¿ Que filosofia empleais vosotros ?
>
> otra cosa, algún sitio de discusiones de UML (o preguntas similiares...)
>
> Un saludo, y gracias por vuestro tiempo !!!
>
> Bix

Hola,

On Fri, 17 Nov 2006 16:03:07 +0100, "Bingen"
wrote:

Hola a todos:

Mi pregunta es la siguiente, la verdad que podría colgarse en cualquier otro
lenguaje pero...

tenemos una clase Factura que agrupa líneas de factura. Estas líneas de
factura tienen una cantidad y una relación con un artículo.

No veo que puede aportar tener una clase como esa.

Mi duda es la siguiente, si la línea la relacionamos con un artículo (nos da
la información de descripción de artículo, código artículo precio), es decir
tenemos una propiedad en la clase línea que es un objeto artículo, nuestro
sistema está obligado a no dejarnos borrar artículos ¿verdad?, porque si no,
todas las líneas de facturas que contengan dicho articulo, quedan inutiles ¿
no?.

¿ Que filosofia empleais vosotros ?

Usar un SGBD para gestionar los datos y no hacerlo desde la aplicación
con código procedimental.

Para que no te deje borrar los artículos se crea una "Foreign Key" y
listo. Implementar esto mediante código de la aplicación es un
disparate.

otra cosa, algún sitio de discusiones de UML (o preguntas similiares...)

Lo que preguntas no tiene nada que ver con UML ni con la OO. No debes
de usar la OO para gestionar datos. La OO no sirve para eso.


Saludos
Alfredo

On 17 Nov 2006 11:28:35 -0800, "Jose A. Fernandez"
wrote:

Ahora otro tema es el stock¿? muchas veces hacen que el stock sea una
simple campo CANTIDAD en una tabla articulos y la verdad el stock es
una serie de movimientos de entrada y salida de facturas de proveedores
y de clientes o sea es una suma (y resta de esas cantidades).. si es un
simple campo no es "natural" mantenerlo

Efectivamente. Para esto lo ideal es usar una vista. Algunos SGBD
tienen mecanismos para que estas vistas sean mantenidas por el sistema
de forma invisible para el programador. En SQL Server se llaman vistas
indexadas y en Oracle vistas materializadas.


Saludos
Alfredo