Javier, buenísimo.
Respecto a tus preguntas:
¿Se puede imputar un costo a un nodo y otro a un nodo que es un hijo del anterior? Digamos en tu ejemplo: 10% a Sucusal A y 30 a Dtpo de Ventas que es “hijo” de Sucursal A.
Yo creo que es poco probable que esto suceda… pero de todas formas contemplarlo o no contemplarlo no haría ningúna diferencia a nivel de código, no? o por lo menos contemplarlo nos ahorraría alguna validación.
Porque estas esta haciendo la diferenciación de si es de costo o ganancia a nivel de “centros de costos”? Para mi es mas simple tener un solo árbol de Centros de Costo Y Ganancias, y que la diferenciación se de a nivel de imputación.
Sí tenes razón, como decís es mucho mejor hacer la diferenciación a nivel de imputación.
También: tené en cuenta los casos en que los centros de costos se puede modificar…. por ej, debería poder haber mas de un arbol de centros de costos? Acá el tema viene porque es probable que surga algo como “vamos a refefinir el arbol de centros de costos”; pero lo que en realidad quieren es dejar de usar el anterior (pero mantenenrlo para que quede como referencia) y pasar a usar un nuevo arbol.
Entiendo… pero ésto sería mas o menos como querer cambiar un plan de cuentas habiendo asientos imputados, no lo tiene que dejar. Creo que lo mas simple por ahora proponer solo un árbol, y que las modificaciones solo puedan darse si no hay referencias en base de datos, por lo que no deberíamos tener ningún control por código para las modificaciones de nodo, estando las foreing key habilitadas.
Vamos a avanzar entonces con lo que definiste. Ahora, tiene algún impacto el concepto de componente en el modelo de datos que definiste? O eso como se va a distribuir, con un script?
