El miércoles, 10 de junio de 2015, 11:37:29 (UTC+1), Jordi Esteve (Zikzakmedia) escribió: > > On 09/06/15 23:23, Albert Cervera i Areny wrote: > > 2015-06-09 21:24 GMT+02:00 Antonio Roncero <ron...@gmail.com > <javascript:>>: > >> Gracias, voy a probar las dos opciones, a ver cual me viene mejor. Yo > mismo > >> iba a intentar modificar el comportamiento del modulo (aunque aun estoy > muy > >> verde). > >> > >> Como comentario, que no critica, es una pena ver tanto esfuerzo > duplicado. > >> Me imagino que es algo mas que comentado y no se si tiene solucion, > pero > >> seria interesante encontrarla (no se si es parte de los objetivos de la > >> fundacion) > > No es esfuerzo duplicado, simplemente que para tener un diseño > > adecuado hace falta darle bastantes vueltas a las cosas. Zikzak hizo > > una primera versión, nosotros intentamos utilitzarla (lo utilizábamos > > nostros mismos hasta hace bien poco), hasta que nos encontramos con > > las limitaciones que tu has visto y tubimos que replantearlo de nuevo. > > > > Más que dos opciones que compiten simplemente creo que una es la > > evolución de la otra. > > Cierto, aunque seguramente el contract de zikzakmedia tb evolucione de > forma independiente a como lo hace el de nantic. Tendrás que tomar una > decisión, tb la de hacer un tercer fork si lo consideras oportuno. >
Estoy probando los dos y os comento mi opinion: El concepto de servicio en el de ZikZak está mejor planteado como idea, al poder poner varios productos por servicio, pero creo que es un error que las cantidades se definan aquí y no en el contrato en sí. Los servicios en el NaN para mi sobran al ser simplemente un enlace 1 a 1 a un producto. Se podria ahorrar ese paso En cambio el concepto de contrato de NaN me gusta mas a poder "personalizar" cada contrato y no creando servicios diferentes segun la cantidad como se hace en el de ZikZak. Creo que hubiera sido ideal el modulo de NaN pudiendo añadir varios productos por servicio. Bueno todo esto hablando desde la teoria porque en el modulo de NaN no puedo crear servicios al ser el campo interval_type obligatorio y no aparecer en el formulario :) IntegrityError: el valor null para la columna «interval_type» viola la restricción not null > Como comentar Albert, el contract de Nantic añade nuevas funcionalidades > muy interesantes como la asociación de activos y partes de trabajo. Pero > a nosotros no nos gusta la simplificación que han hecho con > contract.service dejándolo con sólo un único producto y sin cantidad. > Preferimos nuestro enfoque de que un servicio puede contener varios > productos con cantidades por defecto o calculadas de forma periódica. > Dicho de otro modo el servicio es como una plantilla de contratos, y > pudiendo tener varios productos con sus cantidades por defecto es más > flexible. Y estos dos puntos que comenta Albert tb están en el contract > de zikzakmedia (el primero está en el horno): > > >> - Facturar por períodos naturales o no (por ejemplo del 16 al 15 del > >> mes siguiente o bien siempre del 1 al 31 y proratear si se empieza el > >> día 16). > >> - Añadir desfase entre el período facturado y la fecha de factura. Por > >> ejemplo, puedes decidir si facturas el trimestre el día 1 de enero, el > >> 20 de febrero o cuando quieras... > > -- > Jordi Esteve > Consultor Zikzakmedia SL > jes...@zikzakmedia.com <javascript:> > Mòbil 679 170 693 > > Zikzakmedia SL > St. Jaume, 9, baixos, 2a > 08720 Vilafranca del Penedès > Tel 93 890 2108 > >
