Cobros parciales, conciliación parcial y más
Santi Argüeso
Os expongo un caso "complejo" que me tiene un poco desquiciado porque creo que además ya me lo he planteado anteriormente y ahora no lo doy resuelto, supongo que será cosa de la edad :)
Con OpenERP 6.1 (pero por lo que he visto con 7.0 puede que no haya mucha diferencia)
1) Tengo tres hermosas facturas de un cliente al que llamaremos en este cuento "Parcial"
2) Se registra en un extracto un ingreso de 2000 € de este cliente, pero no se hace una propuesta de pago /conciliación de esa línea del extracto en el momento de introducirlo:
3) Veamos lo que tiene el cliente en su 43 (Ignorad la numeración de asientos, no es relevante).
Hasta aquí OK
4) Ahora un usuario decide que hace una conciliación parcial estos 4 apuntes (todos en una conciliación):
Si me decís que esto no se debe hacer, os pido que me digais cómo le ato la mano al usuario.
5) Volvemos al listado de facturas:
:O Aunque me ha pagado 2000 eurillos donde me debía 1000 ahora me debe 4000, donde 2000 también 4000 y donde 3000 pues eso.... Vale pues ni idea de lo que me debe el cliente según el listado de facturas
Esto sí está corregido en la 7.0, después lo pongo con el cambio de la funcion _amount_residual de account_invoice, para que lo veais... ya alguna cosa más..
En listado de efectos
¿Alguien lo ve claro ? ¿Cómo carallo :) sé lo que me debe mi cliente? (bueno sí el saldo de la 43 para mi amigo Parcial es correcto, pero en fin.....)
6) Lo lío un poco más ¿de acuerdo?. Supongamos que soy un usuario desesperado :( y ahora voy y registro un pago de cliente de otros mil eurillos. Como en lo que veo no tengo ni idea de qué pagar con esos mil lo valido tal y como me lo presenta.
Como me imagino que ya sabréis, al estar parcialmente conciliado el movimiento que trato de pagar, añade este pago a la conciliación, con lo que se va reducir el total por conciliar de la conciliación parcial y por tanto los totales que me debe en cada factura que ahora serán 3000 en cada una.
Por cierto, encima si cancelais este cobro porquno os gusta loque ha hecho os elimirá toda la conciliación con lo que las 3 faturas volverán a estar como al inicio sin nada pagado, esto puede ser uan solución para reinicial las conciliaciones desde 0 y, manualmente tratar de hacer una conciliación más lógica.
Si esto se lía más y van entrando facturas, y cobros y conciliaciones parciales, pagos parciales os podeis imaginar que el entuerto puede llegar a ser bonito....
La única forma de salir (entiendo) es tener un pago por el total exacto de lo que esté pendiente en la conciliación parcial
¿Se os ocurre alguna otra forma de resolver esto una vez que ya se ha liado la madeja?
Y por otro lado ¿Cómo prevenir este lío?
Con la función _amount_residual cambiada según está en 7.0,por lo menos deberíamos ver lo que el sistema calcula que nos debe de cada factura y, al menos, que el total que debe el cliente en el listado de facturas fuese correcto, pero tampoco lo es del todo
SUGERENCIAS:
1) Lo de la conciliación es así, no hay mucha solución, para eso habrái que cambiar todo el proceso de conciliación parcial de OpenERP y no creo que sea el plan...
2) Se puede parchear esa función _amount_residual de las facturas para tratard de tener esto al menos bien.
3) Relacionado con esto estaría también la misma función _amount_residual de los apuntes contables. Rehaciendo esta para que considere calcule correctamente los campos amount_residual y amount_residual_currency sería un buen paso pra clacular a partir de ahí lo debido en las facturas, ¿no creeis?
4) Relacionado con account_payment_extension y el cálculo del amount_to_pay para estos casos (en los que ya vimos que no es capaz de darte exactamente cuanto te debe el cliente), ¿podría considerarse el campo amount_residual_currency del apunte? ¿ o creeis que es mejor que quede como está y que cuando tengas una conciliación parcial de este tipo no se entere de lo que se debe?
5) Volver a hacer un cobro sobre algo conciliado parcialmente es un infierno a menos que sí busquemos una mejora del _amount_residual de los apuntes contables
Sea como sea me gusaría contar con vuestra opinión para buscar una solución, bien que nos valga a todos o tratar de buscarme la vida por otro lado.
Salud y saludos .....
Ignacio Ibeas
Hola Santi,
Si haberlo mirado mucho en profundidad, porque es Sábado.
Esta claro que OpenERP 6.1 cuando realiza la conciliación une todos los saldos conciliados como uno, de ahí que las facturas pasen a deber todas 4000, ya que se han convertido en un conjunto. Pero si es cierto que es tremendamente confuso.
Sin mirarlo mucho a fondo se podría considerar un bug, ya que realmente deberia descontar el pago de una de ellas y no crear un conjunto. Pero el problema aquí, de cual, la más antigua, la más nueva, le indicamos de cual descontamos...
Yo para evitar estos problemos siempre indico que se concilie cada factura una a una. De esta forma va cerrando las que se completen y dejando parcial las que no se completen. Esto implica algo más de trabajo por parte del usuario.
En OpenERP 7 comentas que parece que han solucionado este problema, buscar la diferencia y aplicarla en la 6.1??
Saludos
On Viernes, 27 de septiembre de 2013 20:44:06 Santi Argüeso escribió:
> Muy buenas a todos (y todas, vale)
>
> Os expongo un caso "complejo" que me tiene un poco desquiciado porque
> creo que además ya me lo he planteado anteriormente y ahora no lo doy
> resuelto, supongo que será cosa de la edad :)
>
> Con OpenERP 6.1 (pero por lo que he visto con 7.0 puede que no haya
> mucha diferencia)
>
> 1) Tengo tres hermosas facturas de un cliente al que llamaremos en este
> cuento "Parcial"
>
>
>
> 2) Se registra en un extracto un ingreso de 2000 EUR de este cliente,
> pero no se hace una propuesta de pago /conciliación de esa línea del
> extracto en el momento de introducirlo:
>
>
>
> 3) Veamos lo que tiene el cliente en su 43 (Ignorad la numeración de
> asientos, no es relevante).
>
>
> Hasta aquí OK
>
> 4) Ahora un usuario decide que hace una conciliación parcial estos 4
> apuntes (todos en una conciliación):
>
>
>
> Si me decís que esto no se debe hacer, os pido que me digais cómo le ato
> la mano al usuario.
>
> 5) Volvemos al listado de facturas:
> :O Aunque me ha pagado 2000 eurillos donde me debía 1000 ahora me debe
>
> 4000, donde 2000 también 4000 y donde 3000 pues eso.... Vale pues ni
> idea de lo que me debe el cliente según el listado de facturas
>
>
> Esto sí está corregido en la 7.0, después lo pongo con el cambio de la
> funcion _amount_residual de account_invoice, para que lo veais... ya
> alguna cosa más..
>
> En listado de efectos
>
>
>
> ¿Alguien lo ve claro ? ¿Cómo carallo :) sé lo que me debe mi cliente?
> (bueno sí el saldo de la 43 para mi amigo Parcial es correcto, pero en
> fin.....)
>
> 6) Lo lío un poco más ¿de acuerdo?. Supongamos que soy un usuario
> desesperado :( y ahora voy y registro un pago de cliente de otros mil
> eurillos. Como en lo que veo no tengo ni idea de qué pagar con esos mil
> lo valido tal y como me lo presenta.
>
>
>
>
> Como me imagino que ya sabréis, al estar parcialmente conciliado el
--
Ignacio Ibeas
Acysos S.L. (www.acysos.com)
LinkedIn: http://lnkd.in/Mi37Fk
Launchpad: http://launchpad.net/acysos
Github: http://github.com/acysos
C/ Miguel Astrain 18, 1º Oficina A
31006 Pamplona, Navarra.
Tel. 948238905
Móvil 639452423
---------------------- // -------------------
La información contenida en este mensaje de correo electrónico es
confidencial, para ser leída por la(s) persona(s) a quién se dirige. El
acceso a este mensaje por otras personas no está autorizado. Si Ud. no es la
persona a la que va dirigido, cualquier divulgación, copia o distribución de
la información queda prohibida y puede ser ilegal. Asimismo, cualquier acción
tomada o dejada de tomar basada en la información contenida en este mensaje
queda prohibida y puede ser ilegal.
The information in this e-mail is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this e-mail by anyone is
unauthorised. If you are not the intended recipient, any disclousure,
copying, distribuition or any action taken or omited to be taken in reliance
on it, is prohibited and may be unlawful.
Humanoide
Santi Argüeso
-------- Mensaje original --------
De: Humanoide <fernandoga...@gmail.com>
Fecha: 29/09/2013 11:30 (GMT+01:00)
Para: openerp-s...@googlegroups.com
Asunto: Re: Cobros parciales, conciliación parcial y más
Has recibido este mensaje porque estás suscrito al grupo "Usuarios OpenERP en España" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a openerp-spain-u...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
Santi Argüeso
Hola Santi,
Si haberlo mirado mucho en profundidad, porque es Sábado.
Esta claro que OpenERP 6.1 cuando realiza la conciliación une todos los saldos conciliados como uno, de ahí que las facturas pasen a deber todas 4000, ya que se han convertido en un conjunto. Pero si es cierto que es tremendamente confuso.
Sin mirarlo mucho a fondo se podría considerar un bug, ya que realmente deberia descontar el pago de una de ellas y no crear un conjunto. Pero el problema aquí, de cual, la más antigua, la más nueva, le indicamos de cual descontamos...
Yo para evitar estos problemos siempre indico que se concilie cada factura una a una. De esta forma va cerrando las que se completen y dejando parcial las que no se completen. Esto implica algo más de trabajo por parte del usuario.
En OpenERP 7 comentas que parece que han solucionado este problema, buscar la diferencia y aplicarla en la 6.1??
Mi otra duda es cómo actuar corectamente con los campos amount_residual de factura, amount_residual del apunte y amount_to_pay, porque ademñas de en el listado de facturas, es muy complidado ver lo que te deben en el listado de efectos de account_payment_extension, que tampoco gestiona correctamente este caso.
--
Has recibido este mensaje porque estás suscrito al grupo "Usuarios OpenERP en España" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a openerp-spain-u...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
============================================
Santi Argüeso
Director Técnico - Responsable Aplicaciones de negocio
htttp://www.pexego.es
Ignacio Ibeas
On Lunes, 30 de septiembre de 2013 11:04:51 Santi Argüeso escribió:
> En la 7.0 hace algo un poco "sucio" que es repartirlo de forma igual entre
> todas, no o he probado a fondo, pero creo que si haces varos pagos
> parciales tampoco lo gestiona bien
Esto no es muy limpio. Y plantearse una opción que permita elegir la factura a conciliar??? Un campo many2many que permita indicar facturas a conciliar o similar.
Saludos
Santi Argüeso
Hay un bug que debate esto (https://bugs.launchpad.net/openobject-addons/+bug/1008774) y creo que tienen razón en alguno de los comentarios, esto implicaría cambiar toda la conciliación de OpenERP y para eso se hizo el voucher ... El problema es que esto no soluciona la problemática en que un usuario registro los movimiento bancarios y otro qué es lo que pagan.
Para esto solo se me ocurre el uso de extractos bancarios donde uno lo teclea pero no valida el extracto y el encargado de los pagos lo revisa, hace las correspondientes propuestas y valida el extracto una vez que lo haya hecho .¿Alguna otra alternativa?El 30/09/13 11:08, Ignacio Ibeas escribió:
Pedro Manuel Baeza Romero
Un saludo.
--
Santi Argüeso
Buenas, Santi, yo iba a echar un vistazo después, pero una de las primeras cosas que te iba a recomendar es utilizar el voucher en lugar de hacer la conciliación de manera manual. Te comento más tarde.
Un saludo.
Santi Argüeso
¿Y el movimiento bancario se registra a través de los propios extractos bancarios de OpenERP o a pelo como asientos?
Pedro Manuel Baeza Romero
Santi Argüeso
Bueno, déjame ver si se puede parchear el cálculo del amount_residual (aunque habría que cortar por lo sano estableciendo un criterio rígido, como ir saldando por fecha), y desde ahora, quita el menú para la conciliación manual, jeje.
Tú solo dime cómo ves y a ver si encontramos uan solución válida.
Pedro Manuel Baeza Romero
Un saludo.
Pedro Manuel Baeza Romero
Voy a proponer ahora la inclusión de los mismos en las ramas OCB de la 6.1.
Un saludo.
Santi Argüeso
Sí esto lo probé el otro día, es un apaño y puede valer para salir del paso, pero realmente no creo que solucione el problema de base.
Hará que veas "correctamente" lo que te deben en las facturas pero no en el listado de efectos o en el listado de apuntes si sigues concliando manualmente con lo que , más que probablemente el problama de que esa conciliación parcial siga creciendo estará ahí y pudiendo crecer, y puden pasar cosas tan peculiares como que hoy tengas una factura en la que te deben 100 y al entrar otras facturas y pagos en esa misma factura mañana veas que te deben 200... Difícil de explicar al usuario...
Desde luego esto no creo que tenga más solución que el cambio en el procedimiento de cobros y pagos
El 30/09/13 13:46, Pedro Manuel Baeza Romero escribió:
Pedro Manuel Baeza Romero
Un saludo.
Pedro Manuel Baeza Romero
Por último, la vista Efectos que añade account_payment_extension también muestra la cantidad a pagar / cobrar correctamente, con el parche que incorporo para el mismo, aunque ahora mismo no es completo del todo. En su momento, creo que fue Mikel de Zhenit el que preguntaba en la lista que por qué existían ambos campos, residual y amount_to_pay, y qué sentido tenía el último. Habiendo indagado en el código gracias a la cuestión de este hilo, he podido dar con la respuesta: ese campo debía reflejar también cambios en el importe a pagar/cobrar debido a órdenes de cobro/pago que se hayan preparado pero aún no hayan sido validadas, para así evitar que se introduzca la misma línea en varias órdenes. El propósito original era por tanto noble, pero a lo largo de las versiones se ha ido difuminando el mismo, y la falta de documentación ha hecho que ya no cumpla esa función. En cuanto tenga un rato, completaré el método y propondré su inclusión con una adecuada documentación en las ramas de account-payment para que así no vuelva a pasar esto.
Un saludo.
Santi Argüeso
Me pongo a probarlo y miro también el tema del método de la factura, que ya has currado bastante y ya te comento
Y en cuanto a la comilona, por supuesto, queda la invitación hecha y confirmada, solo nos queda buscar lugar y fecha....
El 01/10/13 02:37, Pedro Manuel Baeza Romero escribió: