[Papo-hackers] dbstruc PAPOv2: the beggining (pun intended)

[Marcos Dione]

    guarda quese viene largo.

    ok, hoy estuvimos discutiendio con mateo un poco como se va a
organizar la base de datos. pronotti medio que entro en la discusion al
ultimo y le dio una media sancion, pero obviamente esto no se termina
aca: hace falta (seguramente) mas refinacion.

    entonces... no estamos reformando toda la estructura, sino lo que
tiene que ver casi estrictamente con la parte de personas y documentos.
empecemos por la parte de personas.

    la forma de reflejar personas (como en personas juridicas, pero no
tanto; es decir, no estrictamente personas de carne y hueso) cambia de
enfoque hacia uno mas centralizado. hasta ahora cada entidad reflejada
en el sistema podia estar varias veces, segun que relacion tenia con
nosotros. por ejemplo, una misma empresa podia ser tanto cliente como
proveedor. entonces habia que ingresar los datos de la misma dos veces,
con la consiguiente tendencia a la inconsistencia (por no hablar de la
duplicacion de datos; no en todos los casos utilizamos ese criterio para
desaparecer tablas o atributos).

    la propuesta, que ya habia sido medio charlada entre los que estamos
en vialibre, era llevarlo a un esquema donde haya un unico listado de
personas (segun la definicion anterior; se le puede cambiar el nombre si
trae confusion, pero recordemos que usamos el idioma ingles para la
definicion de la estructura de la base) y luego un conjunto de roles que
tendrian una persona asociada; segun estos roles es como miramos a las
personas en distintas partes del sistema: como clientes,  provedores, o
lo que haga falta. Un preliminar de esa parte de la estructura seria (en
un metalenguaje python/pascalesco):

Persona:
    isActive: boolean
    obs: text
    # este viene del esquema viejo y en realidad no se para que sirve.
    startTime: date
    name: text
    
Role:
    """
    Clase abstracta de todos los roles
    """
    name: text
    # con esto podemos armar un arbol de inclusion que poco tiene que ver con 
CRM.
    relatesTo: Persona
    persona: Persona

OwnStoreHouse (Role):
    stockByInvoice: boolean
    
AlienStoreHouse (Role):
    pass

Employee (Role):
    # o sea, float
    commission: percentage
    # por si ponemos seguridad por usuario
    user: text
    passwd: text
    
Organization (Role):
    """
    La cascara mas externa de una empresa. Puede ser tanto 'nosotros'
    (desde el punto de vista de la empresa para la cual esta corriendo el 
programa)
    como una empresa con la cual nos relacionamos.
    """
    pass

OwnBranch (Role):
    number: integer
    
AlienBranch (Role):
    ...
    
Client (Role):
    score: float
    priceType: PriceType
    commission: float
    
Provider (Role):
    ...
    
PoitOfSale (Role):
    ...
    
Fisco (Role):
    ...

    con este esquema podemos armar varios arboles con el atributo
relatesTo. por ejemplo 'atar' sucursales o depositos con la empresa a la
que pertenecen.

    un detalle a resolver es como llegar desde un cliente a toda la
organizacion que representa y por ejemplo si conviene atar los depositos
a las sucursales o a las empresas. todo esto es dicutible.

    otro es como arreglarnos con el tema de los uids ahora que todas las
personas son iguales (sin dios de por medio :). recordemos que en algun
momento va a hacer falta buscar una persona para poder agregarle un
nuevo rol (el tipico caso "mira nene", er... perdon, el del cliente que
se convierte tambien en proveedor o viceversa y similares).

----

    por otro lado tenemos los documentos. actualmente tenemos los
megacomplejos {Alien,Own}Document, que acaparan todos los atributos que
pudieran los documentos [conocidos] y que en realidad no son compartidos
por todos. por ejemplo los remitos no tienen vencimiento o las ordenes
de pago no tiene cantidad de bultos. como resumen, OwnDoc tiene 23 (!!!)
atributos.

    Entonces lo obvio es partirlo en varias clases, una (dos) de las
cuales es abstracta ({Alien,Own}Doc) y varias concretas. A su vez hacer
lo mismo del lado de los items, y ademas dividirlos en items comunes y
descriptivos. la principal diferencia entre ellos es que los primeros
tienen cantidad y precio unitario en la base de datos y un precio total
calculado a partir de ambos y de los impuestos, mientras que los
segundos no tienen estos atributos y tienen un precio bruto, que sumados
los eventuales impuestos, dan el precio final. si bien se puede decir
que podriamos mapear unos en otros (quel descriptivo tenga siempre
cantidad uno y mapear los precios), distinguirlos nos permite usar los
descriptivos como contenido de documentos que nada tienen que ver con
productos o servicios (pensar en un recibo). Algo del estilo de:

OwnProductItem:
    # pensar en kilos o litros
    qty: float
    # recordemos que ahora hacemos el historico de esta forma:
    # simplemente llenamos los campos del documento con los valores en ese 
momento.
    productName: text
    unitPrice: float
    
OwnInvoiceProductItem (OwnProductItem):
    # por si no queremos recalcularlo, 
    # a pesar que la informacion adecuada va a estar disponible;
    # ver mas abajo
    discount: percentage
    bonus: float
    taxTotalAmount: float
    netPrice: float
    invoice: OwnInvoice
    
Tax:
    name: string
    # tiene que devolver un porcentage
    # sera posible que en algunos casos devuelva un monto,
    # o sea, que el impuesto sea un monto fijo?
    formula: code

OwnInvoiceProductItemTax:
    # evntualmente no hace falta referenciarlo,
    # o directamente reemplazarlo por el nombre.
    tax: Tax
    ownInvoiceItem: OwnInvoiceItem
    # tanto el porcentage realemnte aplicado
    # como el valor ya redondeadito
    taxPercentage: percentage
    taxAmount: float

OwnDescriptiveItem:
    description: text
    price: float

OwnInvoiceDescriptiveItem (OwnDescriptiveItem):
    taxTotalAmount: float
    netPrice: float
    
...

    habria que ademas hacer tablas[1] que describan que impuestos son
aplicables en cada caso. eventualmente se pueden crear clases mas
genericas de forma de poder referenciarar de forma mas generica (una
clase OwnItem y desde TaxForOwnItems referenciar las instancias).

    tambien se pueden hacer cambios de lugar de los atributios, pero
trate de que los atributos de los items que esten orientados para cierto
tipo de documento queden en la clase correspondiente.

    tener en cuenta que consideramos que hay de dos tipos de servicios:
servicios servidos de a cantidades discretas (horas de laburo, cantidad
de maquinas reparadas, etc) y los cobrados por 'bulto' (honorarios
profesionales por un mes de laburo). los primeros los llamamos
'productizables' y se modelan como porductos y facturables como items de
producto y los segundos con items descriptivos en documentos.

    este esquema de items y taxes se repite en documentos y taxes.
perdonenme un poco la incoherencia hacia el final del mail pero se me
esta apagando el cerebro. me voy a descansar. ma#ana lo continuo.