Antes que nada unas 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.
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.
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.
Bueno igual: el tema de manejar arboles siempre es complicado en bases de datos, habría que ojear un poco el código que por ej muestra el árbol del menú; me da la sensación que hay un elemento gráfico reusable que se podría utilizar (a nivel de tablas o tabs, hay una variable que dice “contiene” arbol que creo que se podria usar).
De cualquier manera, tal vez la forma mas simple (al menos para un primer enfoque que despues se puede llegar a mejorar) que no requiere modificaciones a nivel de base de datos de la tabla de facturas (el botón que decís requiere una columna; podría ser un columna virtual pero al el hecho de ser virtual creo que lo hace que el botón quede deshabilitado) es agregar una tab para a la ventana factura de compras que apunte a la tabla de asociaciones de imputaciones. Antes de esto se crea la tabla “preliminar” (despues se la podría convertir en arbol…) C_CyG (Bajo mi enfoque el un centro siempre puede ser tanto de costo como de ganacias;):
C_CyG
C_CyG_ID int not null, clave primaria
IsActive, Name, Description, AD_Client_ID, AD_Org_ID, como todas las tablas,
Y NADA MAS por ahora…
C_InvoiceImp
Esta tabla tendría esta definición:
C_InvoiceImp_ID int not null
AD_Client_ID, AD_Org_ID, IsActive
C_Invoice_ID int not null //referencia a C_Invoice
C_CyG_ID int not null referencia a C_CyG//
IsCost Y/N not null (si es una imputación de costo o ganancia)
Percentage numeric(5,2) not null,
//posiblemente un campo Obeservations no vendría mal aca…)
//también quizá un seqNo pero no lo veo muy necesario
C_InvoiceImp_ID clave primaria
C_Invoice_ID referencia a C_Invoice
C_CC_ID, referencia a C_CC
Se crea un tabla para a nivel de libertya para C_CyG y para
C_InvoiceImp ; se crea una ventana con una sola pestaña para la edición de C_CyG (de nuevo…. por ahora, nada de arboles…).
Se crea una pestaña en la ventana de facturas de compra asociada al tabla de C_InoviceImp (creo que ahi hay que setear que la clave “padre” es C_Invoice_ID, aunque me parece que no es estrictamente necesario); esta pestaña que este con un nivel de anidación 2 y un nivel de secuencia determinado (al final puede ser tranquilamene). Para que la la imputaciones a una factura de compra siempre sean de costo se puede hacer este campo readonly y jugar con el IsSOTrx de la factura para setearle el valor por defecto (bien bien , no recuero como se hacer pero casi seguro que se puede)
Así como esta, no hay casi nada de chequeos (por ej, no se verifica si la suma de los porcentajes excede 100 ) ni hay ningún árbol… Pero el funcionamiento sería asi:
-se selecciona el tab de Imputaciones de la factura
-se pone el porcentaje (creo que hay formas para que sugiera el porcentaje que falta)
-se selecciona el C_CyG
Ok, las validaciones y el arbol se pueden agregar mas adelante usando codigo:
-Al momento de guardar una nueva C_Ivoice_Imp, se verifica que el porcentaje total no exceda 100 y , en caso de que haya restricciones de arbol que te dije, se hacen tambien aca
-Al momento de guardar un C_Invoice_Imp modificada idem.
-A nivel de factura se puede agregar dos columnas virtual (y read only por lo tanto) que haciendo un simpel “select sum(* ) from C_Invoice_Imp where C_Invoce_ID =id de factura actal AND IsCost = Y, para la primera,N para la sengunda), permite visualizar facilamente que porcentaje del costo o ganancia se tienen actualmente imputado (en la ventana de compra solo se muestra la primera, en la de ventas, la segunda).
-Para mejorar la selección desde el punto de vista visual se puede agregar un boton “Seleccionar Centro de CyG” a la tabla C_Invoice_Imp que al ser disparado muestre un dialogo especializado y que permita selecionar algún nodo por el usuario; el proceso asociada al boton dispara este dialogo y a su retorno setea el el campo C_CyG_ID (que en este caso seria NO actualizable a nivel de pestaña). Este dilogo se podría reutilizar en todos los demás lugares en que sea requerido, pero su funcionalidad es permitir seleccionar SOLO un nodo.
-Y bueno, finalmente convertir a C_CyG en un arbol…
Si te parece más o menos la idea, avanzamos en este sentido; pero la primer parte como te digo, se podría ir haciendo asi (incluso esto te permite, asumiendo que la tabla C_Invoice_Imp queda estable, ir haciendo los reportes o cosas por el estilo en paralelo; toda la lógica de verificación de imputaciones la dejas solo en las clases que hacen las verificaciones a nivel de C_Invoice_Imp y en el dialogo especializado, el cual potencialmente se puede ir “afinando” de poco y que ademas es reutilizable)
PD : para pasar todo estas modificaciones a la forma de componente es algo bastante trivial pero el tema que va haber mucha prueba y error, y las modificaciones intermedias no van a tener sentido al final; por eso creo que la mejor forma de hacerlo es: una vez que se definen y testean todos los cambios (y se va documentando los cambios que realizas) , en otra base de datos creas un nuevo componente y lo pones en estado desarrollo; una vez hecho esto, repetís todos los cambios que finalmente tomaron efectos; detenés el desarrallo del componente y lo exportas.
