- Este debate está vacío.
-
Entradas
-
(Este post es sobre todo para Javier pero el quiera aportar es totalmente bienvenido!!!)
Los centros de costos (cc) conforman un método que permite contestar al empresario o gerente las siguientes preguntas:
– Cuanta plata me gastó tal sucursal/área/empleado/recurso/etc?
– Cuanto plata gane con tal sucursal/área/empleado/recurso/etc?
Un cc puede ser cualquier cosa, lo que el gerente quiera que sea. Cualquier cosa me implique un gasto puede ser un centro de costo: un empleado, una sucursal, una retroescabadora, un departamento comercial etc. Esas entidades físicas o administrativas gastan plata. A la retroescabadora tengo que comprarle neumáticos, al empleado pagarle viáticos, la sucursal paga sueldos, un departamento comercial gasta en librerías, etc.
Entonces, al final del año o del mes, el gerente quiere saber “Cuanta plata gasté en tal entidad”. Para contestar esa pregunta, cuando se efectiviza un gasto hay que imputarlo o asignarlo a un cc. En libertya esa efectivización debería darse cuando completamos una factura de compra, es decir una factura de proveedor; o cuando imputamos cargos desde algúna ventana que realize movimientos de plata. (Libros de caja, Extracto Bancario y creo que nada mas…).
Ahora podemos pensarlo al revez… si el gerente quiere saber cuanta plata ganó con tal entidad? es decir, cuanta plata me hizo ganar la retroescavadora? y la sucursal? y tal vendedor? etc
Entonces, para saber eso se realiza una imputación o asignación de una factura de venta (o cualquier ingreso de efectivo en las mismas ventanas mencionadas antes) a un cc, pero no como un gasto sino como una ganancia.
De manera que al final del período, el gerente puede restar lo que gastó en un cc con lo que ganó en el mismo cc, dejanle la ganancia neta. Nada mejor para un gerente ordenado.
Unas palabras sobre la estructura de los cc: Normalmente éstos se definen como un árbol, por ejemplo, si mi cc es una sucursal, tengo muchos subcentros de costos. La raíz del centro de costos tiene una hoja que es la Sucursal, pero esa hoja Sucursal puede tener hojas que sean departamento Ventas, Departamentos Compras, etc. y puedo imputar a cualquiera de ellas gastos o ganancias. Por ésta razón los cc son árboles, porque se estructuran igual que un arbol. Gráficamente:
Centros de Costos
– Sucursal A
Depto Ventas
Depto Compras
Depto Comercial
– Sucursal B
Depto Ventas
Depto Jurídico
Depto Contable
División Activos
Disisión Patrimoniales
…Esta funcionalidad la solicitan mucho, y en el erp nacionales se resuelve como paso a explicar:
En las ventanas de las facturas (o las ventanas de movimiento de dinero) hay un botón que se llama “Imputar a cc”. De manera que la factura es conocida, lo mismo que su monto neto. A continuación se abre una nueva ventana, que ofrece todos los cc como si fueran un árbol. Primero se selecciona con un click a uno de los cc del árbol y luego se carga en una grilla de la misma ventana, las imputaciones. Para una misma factura puedo tener N imputaciones a muchos cc. Por ejemplo, si pagué el alquiler de los locales de mi empresa, puedo imputar el 50% de ese alquiler a la Sucursal A y el 50% de ese mismo alquiler a la Sucursal B. Es decir, la registración de una factura a los centros de costos, puede implicar N imputaciones a N cc, pero los porcentajes de esas N imputaciones deben sumar 100% por supuesto. Gráficamente:
FACTURA 0001 (10000$ EN CONCEPTO DE PAGO DE ALQUILER)
Sucursal A: 50%
Sucursal B: 50%Si la ventana se abrió desde una factura de compra, la imputación es un gasto, pero si se abrió desde la ventana de factura de ventas, la imputación es una ganancia.
Eso es todo, no tiene más ciencia que lo mencionado. Por supuesto, hay que hacer reportes para ver esa info que se fué cargando durante el período, así como comparadores de gasto/ganancia por centro de costo.
Creo que ahora esta mas claro, no? igual cualquier cosa me preguntan. Pero los cc no son mucho mas que lo que mencioné.
De manera que su definición a nivel binario, es solo una tupla que contendrá en general
– descripción
– id o código identificatorio
– Id del padre
– Booleano indicando si es gasto o ganancia
La imputación sería una tupla con los siguientes campos:
– Id del cc al cual se imputó
– Id de la factura a la cual imputó
– PorcentajePD: El LY atravéz de Proyectos, implementa una asignación de costos o ganancias de dos niveles… eso podría parchar algúnos casos pero tiene el incoveniente de que las asignaciones se hacen por líneas de documentos,y no se pueden hacer asignaciones porcentuales del documento, ademas de que no tiene apertura de niveles para cc.
Bueno, Javier ahora te toca a vos! = )
como seguimos? Nos das una mano para armar el componente?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_CCSe 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_CyGOk, 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.
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?
En cuanto a las modificacioens de árbol, si ahora que lo pienso mejor tenes cierta razón y tambien con lo de las validaciones “nodo-padre-nodo-hijo”; despues de todo se podría “confiar” un poco más en el usuario final y que no se ponga a mucho jugar con esas cosas. Igual, en el futuro se podría pasar a algo similar a tener varios arboles pero uno solo activo o por defecto (una vez activado este arbol las nuevas imputaciones se hacen contra este; por ej, al momento de hacer informes el usuario tiene que seleccionar una arbol dado). Esta último lo digo mas que nada porque se podría agregar esta flexibilidad sin mayores problemas en el futuro si es que es requerida.
En cuanto a lo del componente:
Si,para distribuirlo las modificaciones seguro que es mucho inteligente hacerlo via componentes. Ahora… lo que por ahora solo pueden hacer los componentes es aplicar modificaciones a nivel de metadatos y potencialmente instalar datos “de usuario” (por ej, al instalar este componente se puede no solo crear las tablas si no tambien agregarle por ej, un arbol de costo para qu ese tome como ejemplo o como base; ojo pero esto ultimo reuqiere otras columnas “especiales” relacionadas con los componentes en las tablas que agregues; pero aca me falta un poco entrar en detalles; en otro thread me dijeron como hacerlo, pero no lo testie; igual, eso también se puede hacer sobre el final); lo que no tiene (creo… por que lo veo “potencialmente” posibible) es la funcionalidad de agregar código java… esto que yo sepa require agregar codigo a mano y recompilar el proyecto (el chico que va a tomar el curso de programación lo va a saber hacer enseguida, es bastante simple usando Eclipse; de todas maneras, si no le adelanto un poco por msn para no hacer este thread larguiiiiiiiisimo; igual, en la wiki dice como compilar libertya; de ahi, agregar modificaciones, no hay mucha distancia). Este es un componente de ejemplo http://www.eltita.com.ar/libertya/jug01/files/jug01.jar (lo descomprimis como si fuera un zip normal si queres ver el contenido), si queres probalo instalar (es la versión “componnte” del ejemplo “Juguetes” que se usaron en los cursos anteriores y supongo que en lo siguen usando en los actuales); si no me equivoco, anda bien (es posible que tengas un problemita con los acentos y letras no ascii… pero bueno, ese es otro tema).
En conclusión: creo que no tiene muchas implicancias “dearrollarlo” como si fuese un componente desde el principio (solo se convierte en componente más adelante; mientras tanto se puede ir probando tal como esta) aunque se podría hacer como una forma de ir compartiendo los cambios (pero esto creo que termina complicando mas las cosas, al menos en este caso en que no hay muchas tablas). De todas maneras: si me hago un tiempito, desarrollo las ideas que te propuse como si fuese un componente (versión muy beta) y de ahi partimos como base.
–
- Debes estar registrado para responder a este debate.
