De: "Alejandro F. Reimondo"
Fecha: Mar Oct 22, 2002 10:38 am
Asunto: Re: [objetos] clasificacion


Hola Pablo,
Creo que los problemas se te presentan al querer definir las clases antes de tener el sistema.
Comenzá construyendo partes del sistema según tu interés, no intentes definir el sistema con toda precisión ni detalle; construilo "inocentemente" y dandole tiempo para que el sistema vaya cambiando.
Para comenzar, elegí un objetivo (poco ambicioso), y escribí en un workspace como te gustaría hacerlo..., imaginate que tenes escritas todos los mensajes y clases necesarias... luego empeza a construir las partes que son necesarias para poder evaluar la expresión de partida.

 

naturaleza en si de Comprobante sino al contexto (Si es de venta
 o de compra) en que ese comprobante fue emitido/ingresado
 al sistema.

Modelar el contexto es mas importante que modelar los objetos que participan.
En un sistema como el que comentas es muy importante definir los contextos del sistema y a partir de ellos estudiar que objetos participan.
No es apropiado pensar alobjeto "en el aire", sino en función de su rol en los contextos que participan.
Es posible que al comienzo esto te parezca una forma compleja de resolver el problema, pero con el tiempo espero que puedas valorar su poder. Por ejemplo, cuando puedas agregar/sacar/modificar contextos dinámicamente en tu sistema y aplicar políticas a los contextos... es decir, cuando el sistema te quede en objetos que colaboran en distintas situaciones y no en su código.

Date tiempo y dale tiempo a tu sistema para que pueda mejorar; no intentes pensarlo bien, arremangate y construí partes del sistema, luego, sentate y fijate como anda, estudialo y cambia lo que veas que "esta fijo", rústico, o no sea apropiado.

suerte,
Ale.
 

• Original Message -----

From: Pablo Digonzelli
To: smalltalking@gruposyahoo.com.ar
Sent: Saturday, October 19, 2002 10:26 PM
Subject: [objetos] clasificacion


Hola a todos !!!!

Despues de mucho tiempo de ser basicamente lector de la lista y de estudiar smalltalk, me decidi a desarrollar una aplicacion. Existen gran cantidad de cosas que no estoy seguro como voy a resolver, pero creo estar lo suficientemente maduro (en smalltalk , ya que tengo 41) como para empezar.
Si bien considero a Smalltalk excelente, no se si es adecuado para desarrollar sistemas comerciales tipo E.R.P. ( esto es deudores , proveedores , stock , contabilidad , bienes de uso , etc ). Pese a todas mis dudas decidi empezar. Seleccione Dolphin del cual tengo la version full o profesional.
Enfocandome en Deudores y Proveedores , empiezo definiendo la clase Comprobante. Ahora bien , con este Objeto empiezan grandes dudas acerca de criterios de clasificacion. Me explico:

Un comprobante (esto es Factura , Notas de Credito , Notas de Debito , Ajustes , etc) puede puede ser generado por mi (facturando por ejemplo, esto es Deudores ) o ser recibido por mi (al comprar algo por ejemplo , esto es Proveedores). En ambos casos los comprobantes son identicos es decir :
"Todo comprobante tiene un numero que esta definido por su punto de venta mas un numero secuencial que indica el orden del mismo dentro de este punto de venta"
Ejemplos: 0001-00000001
"Todo comprobante tiene uin importe total que es el importe sin impuestos mas todos los impuestos que correspondieren de acuerdo a la categoria impositiva del que emite el comprobante y del que lo recibe. De acuerdo a esto ultimo un comprobante puede ser A , B , C o X". Por lo tanto puede tener neto , iva , ingresos brutos ,etc.
"Un comprobante puede tener naturaleza contable o no ." Es decir se contabiliza o no .
"Todo comprbante tiene un saldoque debe ser mayor o igual a cero".

Que quiero decir con esto?. Que desde el punto de vista de su conformacion , un comprobante de Deudores o Proveedores es igual. Pero a la hora de verlos desde el punto de vista contable o de cuenta corriente son diferentes. Esto es: una factura emitida por mi a un cliente genera un credito a mi favor (es decir alguien me debe) y una factura recibida por mi genera un debito contra mi (es decir le debo a alguien). O sea se invierten los signos.
Ademas si es contable estara incluido en un asiento contable .

Cuando quiero definir mi jerarquia de objetos se me ocurren por lo menos tres posibilidades:

Comprobante -> Factura , NotaDeCredito , NotaDeDebito, AjusteDeCredito->DeCompra,DeVenta->Contable, NoContable
Comprobante-> DeCompra (proveedores), DeVenta( Deudores) -> Factura, NotaDeCredito, etc->Contable,NoContable
Comprobante -> Contable,NoContable->DeCompra,DeVenta,etc

Por mas que lo analizo, ninguna de estas opciones me conforma. De acuerdo a la clasificacion que realice, siempre tengo que repetir metodos que no hacen a la naturaleza en si de Comprobante sino al contexto (Si es de venta o de compra) en que ese comprobante fue emitido/ingresado al sistema.
Ademas , un comprobante contable o no contable son exactamente iguales, difieren solamente en el hecho de si sera contabilizado o no.

Con este comentario me gustaria discutir ideas acerca de como debe ser clasificado un sistema de estas caracteristicas. Si alguien quiere discutir esto en la lista estoy a entera disposicion.


Saludos
Pablo
 

ArSol.biz 2004