Incompatibilidad saldo ficha partner respecto a cierre localización española

[Sebastán Jara]

La adaptación del cierre de la localización española para OpenERP provoca que el saldo debe y haber que se muestra en la ficha del partner sea incorrecto. Intento argumentarlo:

 - El cálculo del saldo debe/haber que se muestra en la ficha se basa en sumar todos los movimientos contable NO CONCILIADOS TOTALMENTE a partir de los periodos de los ejercicios abiertos. Adjunto parte del código tratado en account/partner.py, función def _credit_debit_get():

SELECT l.partner_id, a.type, SUM(l.debit-l.credit)
                      FROM account_move_line l
                      LEFT JOIN account_account a ON (l.account_id=a.id)
                      WHERE a.type IN ('receivable','payable')
                      AND l.partner_id IN %s
                      AND l.reconcile_id IS NULL # AQUI ES DONDE FILTRA SOLO POR LOS NO CONCILIADOS TOTALMENTE
                      AND """ + query + """ # Esta subquery es la que trata los periodos de los ejercicios abiertos
                      GROUP BY l.partner_id, a.type

 - El proceso cierre/apertura estandar de OpenERP consiste en un asiento de apertura del ejercicio correspondiente en base a la suma de los saldos del ejercicio anterior, sin conciliarse dicho asiento con ningún otro.

  - El proceso de cierre/apertura de la localización española genera un asiento de cierre y otro de apertura, y ambos SE CONCILIAN entre si. Esto provoca que cuando se calcula el saldo de la ficha del partner, NO TIENE EN CUENTA EL MOVIMIENTO DE APERTURA, dado que está conciliado, provocando que el saldo que se muestra en la ficha del partner, es erróneo y no coincide con el resumen de apuntes contables del ejercicio o los listados de mayor.

Este bug está comprobado y corroborado por varios clientes que lo han sufrido. Y dado que el problema viene por el tratamiento específico del cierre contable de la localización española, por eso lo he añadido aquí.

[Sebastán Jara (sebas-jara-bravo)]

La solución que he encontrado pasa por eliminar la sentencia que filtra por los no conciliados totalmente, tratando así todos los apuntes a partir del primer ejercicio abierto. Es algo más lento, pero de momento no he encontrado otra más solución:

Es decir:

SELECT l.partner_id, a.type, SUM(l.debit-l.credit)
                      FROM account_move_line l
                      LEFT JOIN account_account a ON (l.account_id=a.id)
                      WHERE a.type IN ('receivable','payable')
                      AND l.partner_id IN %s
                      AND """ + query + """
                      GROUP BY l.partner_id, a.type

[Nhomar - Vauxoo (nhomar)]

Este bug es interesante.

Nosotros en Mexico y Venezuela usamos el proceso estándard de OpenERP de cierre y apertura para evitar generar éste tipo de bugs.

Sería interesante corroborar si ese asiento está correcto, por que creo que en las versiones 6.1 y 7.0 no es necesario hacer casi ninguna corrección al proceso de cierre original.

Si alguien de los que históricamente tiene conocimiento de por qué legalmente se necesita éste asiento de apertura y cierre, por que en mi parecer no es necesario.

Incluso la incompatibilidad de éste proceso en versiones anteriores cuando lo había probado nos evitó mejorar el cierre español, les parece bien que algún contable pueda corroborar como DEBE legalemente ser el cierre en españa?

Les comento acerca del punto inicial en el bug-

SELECT l.partner_id, a.type, SUM(l.debit-l.credit)
                      FROM account_move_line l
                      LEFT JOIN account_account a ON (l.account_id=a.id)
                      WHERE a.type IN ('receivable','payable')
                      AND l.partner_id IN %s
                      AND l.reconcile_id IS NULL # AQUI ES DONDE FILTRA SOLO POR LOS NO CONCILIADOS TOTALMENTE

EN ESTE COMENTARIO:

Esto te parece que está bien y lo estás apuntando solo como comentario, o crees que debe ser modificado?

Si es la primera opción ok, estoy de acuerdo, OpenERP gestiona las CxC y CxP de ésta manera y a mi parecer está correcta.

Si debe cambiarse, creo que deben resolver un algoritmo más complejo para no olvidar nada.

                      AND """ + query + """ # Esta subquery es la que trata los periodos de los ejercicios abiertos
                      GROUP BY l.partner_id, a.type

Saludos.

[Pedro Manuel Baeza (pedro.baeza)]

Buenas, Nhomar, ahora mismo estoy estudiando este bug. Tengo casi completo el grado de empresariales, por lo que puedo abordar con suficientes conocimientos esta cuestión. El tema principal es que en España es obligatorio realizar estos asientos de cierre y apertura para que cuando se presenten los estados de cuentas, salgan ciertos valores en unas cuentas determinadas (como la 129, que representa el resultado del ejercicio), o bien otras se queden con saldo 0. De ahí provienen estos "malabarismos".

De todas formas, tal como te expresaba en el estado técnico de la localización, para la v7 la intención es aprovechar el proceso estándar con el mínimo de adaptaciones, y Joaquín Gutierrez ya se encuentra echando un vistazo al tema.

Plasmo aquí el resultado de mis investigaciones en un rato.

Un saludo.

[Nhomar - Vauxoo (nhomar)]

Corrijo mi comentario

Si el saldo de un asiento está reconciliado quiere decir que cuadra con otro asiento haciendo 0.

Si el proceso de cierre como lo hace OpenERP lo ejecutas en un periodo en le "Año FIscal Actual" y éste periodo lo marcas como "Apertura/Cierre" no tendrás problemas,

Como carácter informativo ésto fué resuelto en la 6.0 y el módulo correctivo de la localización española fué hecho respondiendo a un problema conceptual que estaba en la Versión 5.

Saludos.

[Nhomar - Vauxoo (nhomar)]

@Pedro.

Puedes validar antes de revisar la migración del módulo de cierre por éste motivo que se entiende el concepto que explico?

Saludos.

[Pedro Manuel Baeza (pedro.baeza)]

Creo que el bug se debe a unas optimizaciones que se introdujeron en el core, que tuvieron como efecto lateral esto.

@Sebas: La solución temporal que has puesto es muy costosa de tiempo cuando tengas muchos apuntes, y además incompleta, pues sigue excluyendo asientos de otros periodos, por lo que facturas que estén impagadas dos ejercicios no aparecían (aunque normalmente ya haya un tratamiento contable para ello de llevarlas a impagadas o incobrables). Una solución más directa es establecer un context con la clave 'all_fiscalyear' a True, que es la que le pasas método _get_query. Te pongo el código:

        ctx = context.copy()
        ctx['all_fiscalyear'] = True
        query = self.pool.get('account.move.line')._query_get(cr, uid, context=ctx)

De esta forma, no limitas la búsqueda a sólo los ejercicios abiertos, y da el resultado correcto.

@Nhomar: He probado vuestro plan de cuentas y el cierre estándar, y aunque no sé si lo he hecho correctamente, creo que existe el mismo problema que con el cierre español, ya que no es una cuestión del cierre, sino del código para calcular el saldo. Pero para asegurarme, me gustaría que probaras tú o que hiciéramos una sesión interactiva para ver si he hecho algo mal. La prueba que he hecho es:

- BD vacía con l10_mx instalado.
- Creo ejercicio 2012 y sus periodos.
- Factura en el año 2012 validada y sin pagar (conciliar) de por ejemplo 1 servicio, por un valor de 75.
- En el saldo cliente, efectivamente aparece en el total a cobrar 75.
- Configuro en el diario de apertura unas cuentas debe y haber por defecto (al azar, no es lo más importante para probar este proceso).
- Voy a 'Procesamiento periódico' > 'Fin de periodo' > 'Generar asiento apertura'.
- Después, a 'Cerrar un ejercicio fiscal' dentro del mismo apartado.
- Consultando el total a cobrar del cliente, ahora ya no es 75, si no a 0.

La solución que pongo a Sebas es la que se podría aplicar en el core de manera general.

Un saludo.

[Nhomar - Vauxoo (nhomar)]

Hola.

Te tengo la explicación completa de esto. Si quieres hacemos un hangout para dejarlo grabado, que tal te suena?

Escribeme al chat de Gmail, y después colocamos aquí el enlace de la conversación.

Saludos.

[Nhomar - Vauxoo (nhomar)]

Hola a Todos.

Acá coloco el proceso de cierre original de OpenERP donde explico que el bug orignal no es de la localización sino de una falla en OpenERP original, publicaré el error dnd corresponde y lo haré valer con nuestra licencia enterprise.

Saludos.

http://youtu.be/xYkQdFV1THM

[Pedro Manuel Baeza (pedro.baeza)]

Nhomar, acabo de ver el vídeo que has publicado, y efectivamente el bug aparece tal como yo me lo había encontrado. Sólo quería indicarte que el código que le indico a Sebas creo que sería la mejor forma de solucionarlo. Inclúyelo en el bug que reportes para si les sirve de orientación a OpenERP.

Muchísimas gracias por tu trabajo en esta cuestión.

[Nhomar - Vauxoo (nhomar)]

Sorry Pedro me perdí,

Puedes ponerme un patch para ver donde crees que debemos colocar ese código, conceptualmente ya lo veo pero no me ubico dnd para proponer el merge a OpenERP.

BTW, creo que esto no es un tema de optimización, sino de error conceptual.

Openerp para computar el saldo en el cliente debería tomar los asientos de Apertura el asunto es que éstos están conciliados entre sí cuando deberían estar conciliados con los del año anterior, sin embargo ésta solución nos haría afrontar el ver a la factura como pagada tal como está manejado el saldo en la factura ahora mismo, por lo que tendríamos que manejar ese algorithmo tambien, pero creo que sería la forma correcta.

BTW, creo que la solución que tiene openerp está "Bien" solo que tiene un "Bug" si estamos de acuerdo en eso, pásame un branch, con mp al core, o un patch para ver donde va ese código.

Te comento que si al branch se das el siguiente nombre :

bzr branch lp:~openerp-community/openobject-addons/7.0-numerodebug lo podemos probar en Runbot casi mágicamente, y yo le pido a mis muchacho que le monten un test yaml para asegurarnos que no vuelva a pasar, creo seriamente que es importante.

Saludos.

[Pedro Manuel Baeza (pedro.baeza)]

Aquí tienes el patch.

[Nhomar - Vauxoo (nhomar)]

Bug Publicado:

https://bugs.launchpad.net/openobject-addons/+bug/1219381

Patch aplicado:

https://code.launchpad.net/~vauxoo/openobject-addons/7.0-bug1219381

MP Hecho:

https://code.launchpad.net/~vauxoo/openobject-addons/7.0-bug1219381/+merge/183350

Runbot Compilando.

http://runbot.openerp.com/vauxoo.html

[Nota: lo coloque como vauxoo por que runbot hace la magia solo ;-)]

Si consideras que hay que hacer algo más relacionado a éste problema, solo proponle a ese branch un MP y lo commiteo.

Siguientes pasos:

1.- Hacer los test YAML para que no vuelva a pasar en la 8.0
2.- Hacer el MP en la 8.0
3.- Esperar la respuesta de la garantía.

Saludos.

[Sebastán Jara (sebas-jara-bravo)]

Gracias Pedro.

Verificaré en breve que la solución que aportas funciona correctamente en mis casuisticas.

Respecto al comentario de que mi solución es incompleta "pues sigue excluyendo asientos de otros periodos, por lo que facturas que estén impagadas dos ejercicios no aparecían (aunque normalmente ya haya un tratamiento contable para ello de llevarlas a impagadas o incobrables)", recordar que estamos hablando del saldo en la ficha del partner (nada de vencimientos o efectos pendientes), y que se supone que cuando cierras el ejercicio, en la apertura se arrastra ese saldo de ejercicios anteriores. Si sigo sin ver lo que me querías decir, por favor, ampliame este comentario.

Creo que realmente el problema viene porque OpenERP, con el objetivo de optimizar el cálculo del saldo, sólo tiene en cuenta los movimientos no conciliados a partir del primer ejercicio en estado abierto, y el único problema es que no se tiene en cuenta el asiento de apertura, ya que está conciliado con el cierre (cosa específica de España). Si solucionamos ese detalle, todo funciona correctamente.

[Pedro Manuel Baeza (pedro.baeza)]

Sebastián, tienes razón en eso de que no es incompleta, ya que si una factura sigue abierta más de dos ejercicios, se va arrastrando el saldo. La otra parte del comentario iba refiriéndome a que normalmente a nivel contable cuando una factura está más de dos años, se pasa a impagada o incontable, quitando ese saldo del cliente.

Pero la primera parte sí que es cierta, ya que imagina que tienes 1000 facturas pagadas al mismo cliente en un ejercicio y 1 sin pagar. Quitando el filtro de conciliadas, se sumarán (las facturas) y restarán (los pagos) 1000 veces para luego al final sólo ser vaĺida la cifra de la de sin pagar. Cuando de un ejercicio a otro se queda una factura sin pagar, como bien dices los apuntes del asiento de cierre y de apertura se concilian entre si, pero el que importa para el saldo sigue siendo el apunte original de la factura abierta, que está en el otro ejercicio cerrado. Y esto es así también a nivel mundial, en el que no es necesario traspasar los saldos entre ejercicios. La única solución para ver el saldo pasa por buscar apuntes no conciliados de ejercicios cerrados, y de ahí mi propuesta de parche.

Un saludo.

[Sebastán Jara (sebas-jara-bravo)]

Comprobación del parche correcta, efectivamente mi solución podía ser muy 'pesada' si había muchos movimientos.

Gracias por la aclaración, y por la solución.