2015-06-10 12:37 GMT+02:00 Jordi Esteve <[email protected]>: > On 09/06/15 23:23, Albert Cervera i Areny wrote: >> >> 2015-06-09 21:24 GMT+02:00 Antonio Roncero <[email protected]>: >>> >>> 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. > > 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):
Sólo comentar que la idea de añadir cantidades, si es conveniente está previsto añadirlo en los consumos, los cuales se calculan antes de facturar. La idea es calcular ahí la cantidad a partir de datos externos (como el número de copias de una fotocopiadora, por ejemplo). >>> - 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 > [email protected] > Mòbil 679 170 693 > > Zikzakmedia SL > St. Jaume, 9, baixos, 2a > 08720 Vilafranca del Penedès > Tel 93 890 2108 > -- Albert Cervera i Areny Tel. 93 553 18 03 @albertnan www.NaN-tic.com
