l10n_es_vat_book Restricción de la cuenta de impuestos

[ramiadavid]

Cuando tenemos un impuesto como el IVA Intracomunitario que va a dos cuentas, se usa la opción 'Restricción de la cuenta de impuestos' en el Mapeo del libro de IVA para que solo calcule los importes de la cuenta 472, pero en algunas empresas tienen configurados los impuestospara que vayan a subcuentas del tipo 472xxx.

Estoy pensando en cambiar esa configuración para que en vez de limitarlo por cuentas pudiera ser por grupo de cuenta de modo que pudiera funcionar con subcuentas si son del mismo grupo.

Como no estoy muy seguro si esto puede ocasionar algun problema en algun otro lugar, me gustaría ver la opinión de algun entendido.

Gracias.

[HaraldPanten]

Hola David,

Ni el vat_book ni los modelos están pensados para que se puedan utilizar subcuentas. Se planteó en su día, pero decidimos limitarlo por un posible problema de rendimiento a futuro. Poner un "ilike" para la 472 y 477 para que coja también subcuentas (si existen) daría más problemas que soluciones.

Por otra parte, en Odoo no son necesarias las subcuentas de impuestos. ¿Por qué necesitas subcuentas en la 472XXX?

Piensa que, aunque hagas esta adaptación para el vat_book, el resto de informes (OCA) no te cogerán bien esas subcuentas.

Saludos.

[ramiadavid]

Yo no digo usar un ilike, lo que digo es usar grupos de cuentas, todas las cuentas tienen group_id si en vez de filtrar por cuenta, filtramos todas las cuentas que pertenezcan a un grupo lo tendriamos solucionado, ya lo estaba haciendo así con una modificación que tengo hecha, y aparentemente funciona bien, pero cada actualización de los modulos tengo que volver a modificarlo.

No se si son necesarias o no las subcuentas, pero algunas empresas así lo quieren y así lo tienen configurado. y me piden que se lo arregle porque no les muestra bien los datos.

La modifiación tendria que hacerse en los demas modulos tambien. pero creo

[HaraldPanten]

En otros software se trabaja con subcuentas de impuestos para diferenciar cada uno de los impuestos y por eso los equipos de contabilidad intentan seguir trabajando igual que con los softwares a los que se han acostumbrado. La idea sería que se ajusten a Odoo.

Para mí el cambio es innecesario, partiendo de la base que el objetivo es poder trabajar con subcuentas de impuestos. Según como lo veo yo, no es que el libro de IVA no les muestre bien los datos, sino que han hecho un uso incorrecto de la configuración de las cuentas de impuestos y como consecuencia tienen una incongruencia en el libro de IVA.

Para mí es un ajuste que debería ir en un módulo privado, pero igual haría falta la visión de otros usuarios que aporten un punto de vista más técnico que el mío.

Saludos.

[pedrobaeza]

Fuera de las connotaciones de rendimiento, que también las hay, y utilizar sistemas como el grupo no servirían, ya que la agrupación no cuadra siempre con la clasificación buscada (aunque se podría crear otro grupo por otro sitio), pero el tema es que los desarrollos no deben propiciar malas prácticas que desnormalicen el sistema, por mucho que algunos contables insistan en que es su preferencia. Odoo tiene herramientas de sobra para ver de forma aislada las bases y cuotas de impuestos sin la necesidad de separar sus saldos en cuentas contables diferentes.

Siempre puede cada uno desarrollarse por su cuenta una extensión, pero recomiendo no hacerlo para evitar otro tipo de problemas a la larga (o a la no tan larga).

[dalonsod]

Hola a todos,

antes de nada, disculpad por añadir a este hilo ya cerrado, y dos años ha, de hecho.

Para @pedrobaeza y @HaraldPanten querría comentar que, de antemano, estoy de acuerdo con la política OCA de educar al máximo a los clientes para que no se salgan del plan contable propuesto.

Luego, para aquellos en los que se nos impone ciertas realidades (y no tenemos algunos la fuerza aún de cambiarlos), también de acuerdo de que no debe solucionar esa papeleta OCA, sino que corre de la cuenta de los desarrolladores que caemos en esto, al menos mientras no logramos revertir la situación.

Yo ahí solo tengo una petición: sabiendo los objetivos marcados (que son realidades, felizmente) de un estándar que persigue hacer las cosas así, que se pueda mantener la puerta abierta a los que por ahora no lo logramos aún, entre los que me incluyo. Y que creo que solo se traduciría en que, si hay alguna propuesta estilo hook que se haga, para preparar ese otro camino, se facilite la aceptación. Naturalmente, esfuerzo a cargo del interesado, y que no penalice nada el desarrollo actual ni su rendimiento. Esta es mi visión técnica, al menos, aprovechando que lo preguntaba @HaraldPanten con anterioridad. Y lo comento porque p.ej. en el Libro de IVA aún no es posible, o al menos eso me pareció a mí, sin recurrir a sobrescritura de código, e iba a plantear un hook entonces, pero confiando en que pueda ser aceptado... si no, pues no y lo acepto.

Con esto acabo el ladrillo, disculpad de nuevo.

@ramiadavid por si es de tu interés, en v15 tengo algo para esto y, al menos parcialmente, para el 303, ya me cuentas.

Gracias

[ramiadavid]

@dalonsod Hola, yo lo tengo solucionado para clientes que tienen el plan contable modificado, con dos módulos que tengo hechos, es una solución que no me gusta mucho ya que tras cada actualización de los módulos hay que revisar que el parche siga funcionando, pero por ahora parece que funciona bien... lo que planteas tu del hook a mi por lo menos me parecería genial, si los demás lo aceptan.

[pedrobaeza]

Es que no hace falta hook. Si se están utilizando otras cuentas, es añadir las líneas de mapeado de impuestos de dichas cuentas, a mano o con un módulo custom. Sin más... ¿o hay algo que se me escapa?

[dalonsod]

Los mapeos son por plantilla de cuenta, no por cuenta. El mapeo es p.ej. para la plantilla 472, que recoge entonces la cuenta 472000, pero no cualquier otra "personalizada por impuesto" 472001, 472002, etc.

Pero sí es normal que esas cuentas extra estén en el grupo de cuentas 472, que es el "truco" que comentó en su día @ramiadavid

Y lo mismo para las 477 del 303.

[pedrobaeza]

Claro, pero lo suyo es que el módulo custom añada esa tax.template o lo que se necesite. Así, no tienes datos en la BD no controlables por código, y puedes realizar actualizaciones vía account_chart_update sin problemas si algo cambia (o en migraciones).

Así lo tengo yo hecho para algún cliente en el que tiene el "IVA 21% (bienes)" de siempre, y luego otro "IVA 21% (bienes) incluido", porque trabaja con B2B y B2C a la vez. La parte custom se reduce a:

```xml IVA 21% sale IVA 21% (Bienes) Incluido percent ```

Lo mismo puedes hacer para cuentas y cualquier otra cuestión.

Pero si no quieres hacerlo así "bien", ya tienes los hooks necesarios. Puedes sobreescribir _get_move_line_domain para añadir lo que te interese. Ejemplos:

https://github.com/OCA/l10n-spain/blob/ec4237a72ef18f7ac2d9170a18ec4a2c9def967e/l10n_es_aeat_mod303_oss/models/mod303.py#L42 https://github.com/OCA/l10n-spain/blob/ec4237a72ef18f7ac2d9170a18ec4a2c9def967e/l10n_es_aeat_mod303/models/mod303.py#L526 https://github.com/OCA/l10n-spain/blob/ec4237a72ef18f7ac2d9170a18ec4a2c9def967e/l10n_es_aeat_mod303_vat_prorate/models/mod303.py#L86

o también _get_tax_lines o cualquier otro. ¿Por qué no es suficiente con ellos?

[dalonsod]

Con el 303 estoy de acuerdo, es bastante más abordable que el libro de IVA, pero con el Libro de IVA no lo veo (aún).

Los mapeos en el libro de IVA y en el 303, cuando se aplica la restricción por plantilla de cuenta, es un Many2one, por ello lo de añadir más plantillas custom creo que no valdría, pues solo se puede poner una. Y en el caso concreto del libro de IVA, lo que comentas de los hooks de primeras no lo veo posible, la última implementación, para optimizar el código, creo que no está preparada del mismo modo que los ejemplos que pones más arriba:

https://github.com/OCA/l10n-spain/blob/05a18aaf352e8e9faadd3669221485f4fe09901c/l10n_es_vat_book/models/l10n_es_vat_book.py#L440-L465

Y el hook al que me refería más arriba para proponer era del libro de IVA entonces

[pedrobaeza]

Pero y por qué no creas una línea extra con ese mismo book_type y la cuenta correspondiente? A ver, lo de cambiar ese campo a m2o quería evitarlo por lo que hemos comentado de no guiar hacia malas prácticas.

[ramiadavid]

@pedrobaeza No, no es cambiar el tipo de campo, es modificar el código de para que el filtrado de líneas de factura se haga en una función aparte, que podamos modificar fácilmente desde otro modulo sin tener que reescribir toda la función.

En el mapeo se quedaría igual, solo que el filtrado se delega a otra función que en el módulo de la OCA cogeria las lineas que estén la misma cuenta, pero nosotros podamos modifica lo que hace esa función para que si en el mapeo está la cuenta 472, pues nosotros filtremos las líneas cuya cuenta empiece por 472xxx,

Realmente el único cambio que se necesita es separar parte del código en una función, ya que de este modo es mucho mas fácil de modificar el comportamiento desde otro modulo

[pedrobaeza]

No es mi opción favorita, la verdad, pero adelante con el hook, porque no puedo imponer mi criterio a toda costa.

[ramiadavid]

Tampoco es que sea la mía, pero cuando trabajas con clientes que tienen sus manías al final tienes que darles una solución, creo que esta es la forma mas sencilla y de cara a la OCA todo queda igual, pero se le da posibilidad a otros desarrolladores a crear sus módulos para modificar el comportamiento mas facilmente

[pedrobaeza]

Como reza el dicho, "más vale una vez colorada que ciento sonrojada". Entonces yo ahí utilizo la baza de "no se puede hacer de otra forma", que desde luego no es una mentira, porque es que si no, luego todo lo que no funcione bien os toca a vosotros ser los que lo corregís sin que el cliente se haga cargo de nada, porque "como ya se le puso así de primeras, debe funcionar".

Siempre tengo presente un caso real contado en un webinar de AEOdoo acerca de un implantador al que el cliente le estuvo cansineando que pusiera Odoo en un servidor Windows que tenía por ahí, y el implantador le dijo que podría haber potencialmente problemas. El cliente dijo que no pasaba nada, que si había problemas, ya se lidiaría con ello y demás. Pues hubo problemas debidos a Windows, el implantador lo comentó y el cliente no quiso hacerse cargo de lo que suponía, denunció al implantador, y el implantador acabó condenado por tribunales...

[ramiadavid]

@dalonsod

Revisando el código creo que en realidad solo necesitamos modificar una linea: https://github.com/OCA/l10n-spain/blob/e1deeb3992650d0a8f112ebf350e9a2c099f4c43/l10n_es_vat_book/models/l10n_es_vat_book.py#L463-L464

Cambiando accounts.get(line.tax_line_id, line.account_id) == line.account_id Por line.account_id in accounts.get(line.tax_line_id, line.account_id)

Ya que en el resto de módulos el filtrado por cuenta se hace en el archivo en: https://github.com/OCA/l10n-spain/blob/e1deeb3992650d0a8f112ebf350e9a2c099f4c43/l10n_es_aeat/models/l10n_es_aeat_report_tax_mapping.py#L118-L119

Si se sobrescribe la función get_account_from_template para que una vez obtenida la cuenta desde la función superior, se añadan todas las subcuentas según el criterio que tu quieras ya debería funcionar correctamente. E incluso podrías hacerlo en el modelo res.company pudiendo discriminar fácilmente si este cambio quieres aplicarlo a una o a varias compañías.

Un ejemplo de como yo lo harias seria:

    def get_account_from_template(self, account_template):
        account = super().get_account_from_template(account_template)
        if not account:
            return account
        return account.search([
            ('code', '=like', "%s%%" % account.code.rstrip('0')),
            ('company_id', '=', account.company_id.id)
        ])

[dalonsod]

Hola, @ramiadavid

Le daré una vuelta, a ver si me animo pronto a hacer el PR, aunque no será de inmediato por cuestiones de planificación y ahí verías la propuesta.

Veo lo que comentas incorrecto o insuficiente, aunque es un camino posible... al cambio que indicas en el fichero de l10n_es_vat_book.py creo que, al menos, habría que añadirle pasar algo al contexto que llama previamente a get_account_from_template(), para que esta función pueda ser solo alterada para ese caso, y en ningún otro (en tu código se sugiere que cambiaría para todo uso, eso no debería ser así). Y luego esa modificación dentro de get_account_from_template() ya debería ser la que debería hacer cada uno para amoldarse a sus circunstancias (en mi caso acudiendo al grupo de cuentas), y usando ese contexto para saber de dónde se viene.

[dalonsod]

Como reza el dicho, "más vale una vez colorada que ciento sonrojada". Entonces yo ahí utilizo la baza de "no se puede hacer de otra forma", que desde luego no es una mentira, porque es que si no, luego todo lo que no funcione bien os toca a vosotros ser los que lo corregís sin que el cliente se haga cargo de nada, porque "como ya se le puso así de primeras, debe funcionar".

@pedrobaeza sí, a mí me falta ese arrojo en muchas ocasiones, aunque cada vez en menos, y cuando cedo no queda otra que dejarlo bien por escrito, para minimizar lo que comentas, avisar de los costes ocultos y que lo asuma quien lo impuso. Pero lo ideal está claro que es lograr un 100% Odoo/OCA y asunto resuelto 😉