CriptoMart/addons-cm
2
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Compare commits

base: CriptoMart:66a5e31060008ffee2a2ff39d2c9c60bffaabaec
Branches Tags
CriptoMart:16.0
CriptoMart:18.0
CriptoMart:17.0
CriptoMart:feature/refactor-cyclomatic-complexity
CriptoMart:test
CriptoMart:12.0
CriptoMart:master
..
compare: CriptoMart:5eb82741927a032a9ac6ccc17c104a9052b5b715
Branches Tags
CriptoMart:18.0
CriptoMart:16.0
CriptoMart:17.0
CriptoMart:feature/refactor-cyclomatic-complexity
CriptoMart:test
CriptoMart:12.0
CriptoMart:master

No commits in common. "66a5e31060008ffee2a2ff39d2c9c60bffaabaec" and "5eb82741927a032a9ac6ccc17c104a9052b5b715" have entirely different histories.
66a5e31060 ... 5eb8274192

6 changed files with 13 additions and 103 deletions
Download patch file Download diff file Expand all files Collapse all files

55
l10n_es_edi_tbai_reagyp_recibidas/README.rst
View file

@ -1,55 +0,0 @@
===================================
TicketBAI REAGYP Facturas Recibidas
===================================
.. |badge1| image:: https://img.shields.io/badge/maturity-Beta-yellow.png
:target: https://odoo-community.org/page/development-status
:alt: Beta
.. |badge2| image:: https://img.shields.io/badge/licence-AGPL--3-blue.png
:target: http://www.gnu.org/licenses/agpl-3.0-standalone.html
:alt: License: AGPL-3
|badge1| |badge2|
This module fixes a bug in the native Odoo ``l10n_es_edi_tbai`` module when
sending vendor bills under the special agriculture regime (REAGYP) to Batuz
(Bizkaia LROE).
**Problem Solved:**
For REAGYP vendor bills, ``l10n_es_edi_tbai`` hardcodes the regime key
``ClaveRegimenIvaOpTrascendencia`` to ``19``. Key ``19`` only exists in the
issued-invoices book; the received-invoices (FacturasRecibidas) schema rejects
it with::
cvc-enumeration-valid: Value '19' is not facet-valid with respect to
enumeration '[01, 02, 03, 04, 05, 06, 07, 08, 09, 12, 13]'
The correct key for REAGYP compensations on purchases is ``02``.
**Solution:**
Overrides ``account.move._l10n_es_tbai_get_vendor_bill_values_batuz`` to remap
the regime key from ``19`` to ``02`` for received invoices. The override is
defensive: it only acts when the value is exactly ``['19']``, so it becomes a
no-op once the upstream fix lands.
Upstream tracking: https://github.com/odoo/odoo/pull/266214
Bug Tracker
===========
Report issues at https://git.criptomart.net/criptomart/addons-cm
Credits
=======
Authors
~~~~~~~
* Criptomart
Maintainers
~~~~~~~~~~~
This module is maintained by Criptomart.

1
l10n_es_edi_tbai_reagyp_recibidas/__init__.py
View file

@ -1 +0,0 @@
from . import models # noqa: F401

12
l10n_es_edi_tbai_reagyp_recibidas/__manifest__.py
View file

@ -1,12 +0,0 @@
# Copyright 2026 - Today Criptomart
# License AGPL-3.0 or later (http://www.gnu.org/licenses/agpl).
{ # noqa: B018
"name": "TicketBAI REAGYP Facturas Recibidas",
"version": "18.0.1.0.0",
"summary": "Fix ClaveRegimenIvaOpTrascendencia for REAGYP vendor bills (19 -> 02)",
"license": "AGPL-3",
"author": "Odoo Community Association (OCA), Criptomart",
"maintainers": ["Criptomart"],
"website": "https://git.criptomart.net/criptomart/addons-cm",
"depends": ["l10n_es_edi_tbai"],
}

1
l10n_es_edi_tbai_reagyp_recibidas/models/__init__.py
View file

@ -1 +0,0 @@
from . import account_move # noqa: F401

16
l10n_es_edi_tbai_reagyp_recibidas/models/account_move.py
View file

@ -1,16 +0,0 @@
# Copyright 2026 - Today Criptomart
# License AGPL-3.0 or later (http://www.gnu.org/licenses/agpl).
from odoo import models
class AccountMove(models.Model):
_inherit = "account.move"
def _l10n_es_tbai_get_vendor_bill_values_batuz(self):
values = super()._l10n_es_tbai_get_vendor_bill_values_batuz()
# Clave 19 (REAGYP) sólo existe en el libro de facturas emitidas. En
# facturas recibidas, la compensación REAGYP se declara con la clave 02,
# única válida en el esquema LROE de recibidas.
if values.get("regime_key") == ["19"]:
values["regime_key"] = ["02"]
return values

21
website_sale_aplicoop/views/website_templates.xml
View file

@ -481,26 +481,21 @@
</div> </div>
<div class="col-md-4"> <div class="col-md-4">
<div class="info-item"> <div class="info-item">
<t t-if="group_order.pickup_slot_ids"> <t t-if="group_order.pickup_day and group_order.pickup_date">
<label t-att-class="'info-label'">Store Pickup Slots</label> <label t-att-class="'info-label'">Store Pickup Day</label>
<span class="info-value"> <t t-if="group_order.home_delivery">
<t t-foreach="group_order.pickup_slot_ids" t-as="slot"> <span class="info-value" t-attf-data-pickup-date="{{ group_order.pickup_date }}" t-attf-data-delivery-date="{{ group_order.delivery_date }}">
<div> <t t-esc="day_names[int(group_order.pickup_day) % 7]" />
<t t-esc="day_names[int(slot.weekday) % 7]" /> <span class="info-date">(<t t-esc="group_order.pickup_date.strftime('%d/%m/%Y')" />)</span>
&#160;
<t t-esc="('%02d:%02d–%02d:%02d' % (int(slot.start_hour or 0), int(((slot.start_hour or 0) % 1) * 60), int(slot.end_hour or 0), int(((slot.end_hour or 0) % 1) * 60)))" />
<t t-if="slot.label">&#160;(<t t-esc="slot.label" />)</t>
</div>
</t>
</span> </span>
</t> </t>
<t t-elif="group_order.pickup_day and group_order.pickup_date"> <t t-else="">
<label t-att-class="'info-label'">Store Pickup Day</label>
<span class="info-value" t-attf-data-pickup-date="{{ group_order.pickup_date }}"> <span class="info-value" t-attf-data-pickup-date="{{ group_order.pickup_date }}">
<t t-esc="day_names[int(group_order.pickup_day) % 7]" /> <t t-esc="day_names[int(group_order.pickup_day) % 7]" />
<span class="info-date">(<t t-esc="group_order.pickup_date.strftime('%d/%m/%Y')" />)</span> <span class="info-date">(<t t-esc="group_order.pickup_date.strftime('%d/%m/%Y')" />)</span>
</span> </span>
</t> </t>
</t>
</div> </div>
</div> </div>
<div class="col-md-4"> <div class="col-md-4">