search

OCA / l10n-spain

Odoo Spain Localization
https://www.aeodoo.org/estado-localizacion
GNU Affero General Public License v3.0
274 stars 517 forks source link

[10.0][l10n_es_vat_book] Error cuando hay asientos de tpv sin partner #1682

Closed xAdrianC-Kernet closed 1 year ago

xAdrianC-Kernet commented 3 years ago

Hola a todos,

me han reportado un error en la generación del libro de iva tras la actualización del commit: https://github.com/OCA/l10n-spain/commit/55bfd3866fe10d04fcf4758babf148800b9d291f

el despliegue en el que se genera el error tiene TPV y por tanto está generando asientos sin partner, cuando llega a la linea 333 de l10n_es_vat_book.py en el método _check_exceptions se genera une error cuando hay lineas sin partner, ya que llama al método _parse_aeat_vat_info de res.partner que tiene ensure_one.

Me ha dado que pensar si es obligatorio que todos los asientos que tienen iva deberían tener partner, pero en v10 no he entonctrado uno para poner por defecto y he obvservado que hasta ahora no aparecia ese error (deshacinedo el commit desaparece)

No estoy seguro si el propio commit no ha tenido en cuenta esta casuistica o la casuistica en si misma es erronea y no debería haber asientos sin partner, si es esto segundo, el único camino es instalar modulos externos para prevenir que desde el pos no se creen?

Gracias.

pedrobaeza commented 3 years ago

¿Puedes indicar el stack trace del error?

xAdrianC-Kernet commented 3 years ago

Haciendo algunas pruebas, tengo muy claro que es debido a que tenemos asientos sin partner, que se genran al estar haciendo ventas en tpv sin cliente, pero la única forma que encuentro de poner un cliente por defecto es desarrollando o modulos externos a base-OCA, o puede que desconozca algo adicional.

Esta es la traza:

Traceback (most recent call last):
  File "/opt/odoo/OCB/odoo/http.py", line 642, in _handle_exception
    return super(JsonRequest, self)._handle_exception(exception)
  File "/opt/odoo/OCB/odoo/http.py", line 684, in dispatch
    result = self._call_function(**self.params)
  File "/opt/odoo/OCB/odoo/http.py", line 334, in _call_function
    return checked_call(self.db, *args, **kwargs)
  File "/opt/odoo/OCB/odoo/service/model.py", line 101, in wrapper
    return f(dbname, *args, **kwargs)
  File "/opt/odoo/OCB/odoo/http.py", line 327, in checked_call
    result = self.endpoint(*a, **kw)
  File "/opt/odoo/OCB/odoo/http.py", line 942, in __call__
    return self.method(*args, **kw)
  File "/opt/odoo/OCB/odoo/http.py", line 507, in response_wrap
    response = f(*args, **kw)
  File "/opt/odoo/OCB/addons/web/controllers/main.py", line 899, in call_button
    action = self._call_kw(model, method, args, {})
  File "/opt/odoo/OCB/addons/web/controllers/main.py", line 887, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "/opt/odoo/OCB/odoo/api.py", line 689, in call_kw
    return call_kw_multi(method, model, args, kwargs)
  File "/opt/odoo/OCB/odoo/api.py", line 680, in call_kw_multi
    result = method(recs, *args, **kwargs)
  File "/opt/odoo/OCA/l10n-spain/l10n_es_aeat/models/l10n_es_aeat_report.py", line 295, in button_calculate
    res = self.calculate()
  File "/opt/odoo/OCA/l10n-spain/l10n_es_vat_book/models/l10n_es_vat_book.py", line 178, in calculate
    self._calculate_vat_book()
  File "/opt/odoo/OCA/l10n-spain/l10n_es_vat_book/models/l10n_es_vat_book.py", line 391, in _calculate_vat_book
    self.create_vat_book_lines(lines_issued, 'issued', taxes_issued)
  File "/opt/odoo/OCA/l10n-spain/l10n_es_vat_book/models/l10n_es_vat_book.py", line 363, in create_vat_book_lines
    self._check_exceptions(line_vals)
  File "/opt/odoo/OCA/l10n-spain/l10n_es_vat_book/models/l10n_es_vat_book.py", line 335, in _check_exceptions
    if (partner._parse_aeat_vat_info()[0] in
  File "<decorator-gen-124>", line 2, in _parse_aeat_vat_info
  File "/opt/odoo/OCB/odoo/tools/cache.py", line 87, in lookup
    value = d[key] = self.method(*args, **kwargs)
  File "/opt/odoo/OCA/l10n-spain/l10n_es_aeat/models/res_partner.py", line 40, in _parse_aeat_vat_info
    self.ensure_one()
  File "/opt/odoo/OCB/odoo/models.py", line 4881, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: res.partner()
pedrobaeza commented 3 years ago

El error de código se arregla poniendo en el if if partner .... Otra cosa es que en el libro de IVA deba volcarse o no esa información y el libro de IVA no tiene extensión para tratar específicamente el TPV (si la requiere).

xAdrianC-Kernet commented 3 years ago

En esa situación me encunetro, tengo el cambio hecho y me lo calcula correctamente, pero no se si hacer el merge request ya que no estoy seguro de si es conidcion obligatoria a nivel contable que todos los apuntes con iva tengan partner

pedrobaeza commented 3 years ago

Bueno, haz el PR y se soluciona el error de código, y lo otro necesitarás asesoramiento fiscal al respecto.

SoniaViciana commented 3 years ago

@xAdrianC https://github.com/OCA/pos/tree/12.0/pos_default_partner

HaraldPanten commented 3 years ago

Funcionalmente eso tiene solución si haces uso del campo aeat_anonymous_cash_customer que te da el módulo l10n_es_aeat.

Eso sí, tendrás que poner un partner por defecto en las ventas del TPV. Yo crearía un del estilo "Cliente Tienda" o similar.

Puedes usar el módulo que te indica @SoniaViciana , por ejemplo, pero no lo tienes en V10.

xAdrianC-Kernet commented 3 years ago

Sí, la solución la tengo más o menos clara, ya he aclarado a nivel fiscal también.

Simplemente porque es un problema que hasta ese commit no existia y si tienes movimientos anteriores no se regularizan ni con el pos_default_partner ni con la casillas, esto solo sirve a posteriori.

Gracias a todos.

jabelchi commented 3 years ago

He comprobado que, aunque crees un cliente con "AEAT-Cliente anónimo" y lo pongas en los tickets, el error en el diario de IVA sigue saliendo. A final del día se hace un asiento global con todos los tickets (que no se hayan convertido en factura) y ese asiento no tiene en cuenta el posible partner que hayas informado en los tickets. Entiendo, pues, que instalar un módulo para hacer obligatorio el partner en los tickets no soluciona el problema.

fgarcia-humanoide commented 3 years ago

A mi me pasa lo mismo,

voy a probar con módulos indios:

https://apps.odoo.com/apps/modules/13.0/pos_set_default_customer/

https://apps.odoo.com/apps/modules/13.0/mai_pos_default_customer/

https://apps.odoo.com/apps/modules/13.0/pw_pos_default_customer/

xAdrianC-Kernet commented 3 years ago

El tema aqui también es, que este tipo de módulos, pone un partner por defecto en los nuevos pedidos del POS, pero no corrige los anteriores.

Igual la solución pasa más por solventarlo en el momento de generar el libro de iba, hacer que si la linea de pos viene vacia meter un res_partner por defecto.

jalzaga commented 3 years ago

A nosotros también se nos ha planteado este error en v13 al exportar el borrador. Odoo no pone partner en los asientos del POS y, por otro lado el libro de IVA toma todos los asientos cuyo IVA esté en el mapeo. Los asientos del POS llevan el IVA asociado al producto vendido y ese IVA está en el mapeo. Yo creo que para que esto fuese fluido, el módulo libro de IVA debería tomar un cliente por defecto para el caso en que no viniese en el apunte contable. Si no se hace así este módulo sería incompatible con el POS.

xAdrianC-Kernet commented 3 years ago

Yo pienso exactamente igual, más en el camino de que el libro tome un partner parametrizable para dicho fin en el propio libro de iva (que es el único sitio donde falla) más que tirar por el camino de poner un partner por defecto en el pos (habría que pasar un script o hacer alguna mecánica en el módulo para que se establezca en todos los registros existentes afectados).

Sería cuestión de trabajar en esa vía, yo creo que con el análisis que hice se me ocurre como resolverlo, voy a intentar hacer un PR y comentamos sobre él

etobella commented 3 years ago

https://github.com/OCA/pos/tree/12.0/pos_default_partner

Esta es la forma que hemos utilizado para resolverlo nosotros

fgarcia-humanoide commented 3 years ago

https://github.com/OCA/pos/tree/12.0/pos_default_partner

Esta es la forma que hemos utilizado para resolverlo nosotros

En la 12 va bien, en la 13 ya no funciona

pedrobaeza commented 3 years ago

PRs con alguna de las propuestas son bienvenidos.

github-actions[bot] commented 2 years ago

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.

rafaelbn commented 2 years ago

Hola a todos,

Esto aplica de v10 a v15.

Esto que se plantea aquí, no tiene por qué ser un error del libro de IVA si no de cómo almacenamos las ventas del POS (recordemos l10n_es_pos que quizá haya que mejorar este).

La solución que comenta @etobella con pos_default_partner es buena porque a ese partner se le pone el campo a TRUE que comenta @HaraldPanten en la ficha de los clientes aeat_anonymous_cash_customer. Yo haría una mejora en l10n_es_pos para que cubra todo esto de serie. Hecho esto el Libro de IVA ya no se va a quejar nunca.

El problema vendría otra vez, si este cliente (o cualquiera) se acoge al SII, porque el SII ya no hace caso alguno a este campo tan importante que viene de antaño y que en mi opinión se debió usar/re-aprovechar.

Estudiada la doc de AEAT con respecto al SII y al Libro de IVA la realidad es que lo que se presenta por SII y lo que saque el libro de IVA (que te lo pueden requerir igualmente en una inspección aunque te hayas acogido al SII) debe de ser exactamente igual. De tal forma que el inspector vea fiel reflejo de lo presentado en el SII y del libro de IVA.

Además si un clientes está usando el POS y presentando el LIVA y a mitad de año o con el cambio de año fiscal se acoge al SII, su manera de trabajar no debería cambiar en absoluto. Odoo debe manejar esta situación.

Por lo tanto:

Pero claro, aquí entra el no tocamos el SII bajo ningún concepto y entonces la solución que debe de buscar es otra. Habría que replicar en l10n_es_pos y l10n_es_vat_book lo mismo que hace el SII, es decir:

Es un tema complejo en el que habría que hacer una mesa de trabajo para buscar la mejor solución desde el punto de vista global de la localización española. Y unificar poniendo como caso de uso una empresa que usa el POS y no está acogida al SII, presenta Libro de IVA y después se acoge al SII y no hay tenido que tocar nada en ningún partner ni cambiar su forma de operar. Y ya lo ideal que ha este cliente le haga una inspección Hacienda antes y después del SII y no encuentren falta alguna 😄

No sé si @acysos estaría interesado a dar su punto de vista

HaraldPanten commented 2 years ago

Hola @rafaelbn por supuesto, encantado de debatirlo. Aún así, creo que no te he entendido del todo bien.

¿Si utilizamos el pos_default_partner no solucionamos todo este aspecto? Marcamos ese cliente anónimo en AEAT mediante el campo que añade l10n_es_aeat tal como haría el SII indicando factura simplificada en SII con el campo sii_simplified_invoice

Digamos que las soluciones son equivalentes. Una para el Libro de IVA y otra para el SII.

¿O te refieres a unificarlo todo en un mismo campo, teniendo en cuenta que el SII no te exime del Libro de IVA?

github-actions[bot] commented 1 year ago

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.