profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/gdgellatly/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Graeme Gellatly gdgellatly O4SB New Zealand https://o4sb.com

gdgellatly/odoo.sql.migration 2

Fast Odoo Migration Framework

gdgellatly/report-print-send 2

Odoo Printing Services and Printer related addons

gdgellatly/care_center 1

Odoo Help Desk & Ticketing System

gdgellatly/odoo_public 1

My Odoo addons plus a random selection of others work I use

gdgellatly/baseimage-docker 0

A minimal Ubuntu base image modified for Docker-friendliness

gdgellatly/docker-duplicity 0

Docker image for running duplicity in a cron

gdgellatly/doodba 0

Base image for making the creation of customized Odoo environments a piece of cake

gdgellatly/doodba-scaffolding 0

Officially supported scaffolding template for your Doodba projects

gdgellatly/gdgellatly.github.io 0

Open for Small Business

gdgellatly/oca-custom 0

Custom Module for OCA Instance

pull request commentOCA/stock-logistics-workflow

[14.0][FIX] stock_picking_filter_lot configurable per operation_type

@remi-filament you don't need to add tuples, you need to add lists of tuples. e.g. [(tuple),(tuple)] + ([(tuple)] or [])

remi-filament

comment created time in a day

pull request commentOCA/stock-logistics-workflow

[14.0][FIX] stock_picking_filter_lot configurable per operation_type

https://github.com/odoo/odoo/blob/97e3115bce518cd9d98fe2454e341077077a79a8/addons/purchase/views/account_move_views.xml#L17

Yes you can define in view for simple boolean test and changes.

remi-filament

comment created time in 2 days

Pull request review commentOCA/stock-logistics-workflow

[WIP][13.0][ADD] stock_quant_constraint New module to guarantee quant information

+# Copyright 2020-2021 Therp BV <https://therp.nl>.+# License AGPL-3.0 or later (http://www.gnu.org/licenses/agpl).+import logging++from odoo import _, api, fields, models+from odoo.exceptions import UserError, ValidationError+from odoo.tools import float_compare++_logger = logging.getLogger(__name__)++UNIQUE_QUANTS_STATEMENT = """\+WITH grouped_quants AS (+     SELECT count(*) as kount, sum(quantity) as quantity,+     location_id, product_id, lot_id, package_id, lot_id+     FROM stock_quant+     GROUP BY location_id, product_id, lot_id, package_id, lot_id+ )+ SELECT * from grouped_quants where kount > 1;+"""++STOCK_STATEMENT = """\+-- A done stock move line, decreases a quant at the source location,+-- and increases or creates a quant at the destination location.++-- 1. Sum all incoming moves per location+-- 2. Sum all outgoing moves per location+-- 3. Sum all quants per location+-- (per location: per product, location, lot, package and owner)+-- The quantity per quant should be the quantity that went in+-- minus the quantity that went out.+WITH outgoing_moves AS (+    SELECT+        ml.product_id, ml.location_id,+        ml.lot_id, ml.package_id, ml.owner_id,+        SUM(ml.qty_done) AS qty_done+    FROM stock_move_line ml+    WHERE ml.state = 'done'+    GROUP BY+        ml.product_id, ml.location_id, ml.lot_id, ml.package_id, ml.owner_id+),+incoming_moves AS (+    SELECT+        ml.product_id, ml.location_dest_id,+        ml.lot_id, ml.package_id, ml.owner_id,+        SUM(ml.qty_done) AS qty_done+    FROM stock_move_line ml+    WHERE ml.state = 'done'+    GROUP BY+        ml.product_id, ml.location_dest_id, ml.lot_id, ml.package_id, ml.owner_id+),+quants AS (+    SELECT+        sq.product_id, sq.location_id,+            sq.lot_id, sq.package_id, sq.owner_id,+            sq.quantity+    FROM stock_quant sq+),+quant_summary AS (+    SELECT+        COALESCE(q.product_id, im.product_id, om.product_id) AS product_id,+            COALESCE(q.location_id, im.location_dest_id, om.location_id) AS location_id,+            COALESCE(q.lot_id, im.lot_id, om.lot_id) AS lot_id,+            COALESCE(q.package_id, im.package_id, om.package_id) AS package_id,+            q.quantity,+            COALESCE(q.owner_id, im.owner_id, om.owner_id) AS owner_id,+            im.qty_done AS quantity_in, om.qty_done AS quantity_out,+            COALESCE(q.quantity, 0) - (COALESCE(im.qty_done, 0)+                - COALESCE(om.qty_done, 0)) AS quantity_error+    FROM quants q+    FULL OUTER JOIN incoming_moves im ON+    q.product_id = im.product_id AND q.location_id = im.location_dest_id+    AND (q.lot_id = im.lot_id OR (q.lot_id IS NULL AND im.lot_id IS NULL))+    AND (q.package_id = im.package_id+        OR (q.package_id IS NULL AND im.package_id IS NULL))+    AND (q.owner_id = im.owner_id OR (q.owner_id IS NULL AND im.owner_id IS NULL))+    FULL OUTER JOIN outgoing_moves om ON+    q.product_id = om.product_id AND q.location_id = om.location_id+    AND (q.lot_id = om.lot_id OR (q.lot_id IS NULL AND om.lot_id IS NULL))+    AND (q.package_id = om.package_id+        OR (q.package_id IS NULL AND om.package_id IS NULL))+    AND (q.owner_id = om.owner_id OR (q.owner_id IS NULL AND om.owner_id IS NULL))+)+SELECT+    qs.product_id,+    qs.location_id,+    qs.package_id,+    qs.owner_id,+    qs.lot_id,+    COUNT(*) as kount,+    SUM(quantity) AS quant_quantity,+    SUM(quantity_in) AS quantity_in, SUM(quantity_out) AS quantity_out,+    SUM(quantity_error) AS quantity_error+    FROM quant_summary qs+    JOIN stock_location sl+    ON qs.location_id = sl.id+    WHERE quantity_error > 0.01+    AND sl.usage = 'internal'+    GROUP BY qs.location_id, qs.product_id, qs.package_id, qs.owner_id, qs.lot_id+    ORDER BY qs.location_id, product_id, qs.package_id, qs.owner_id, qs.lot_id+"""++RESERVED_STATEMENT = """+SELECT COALESCE(SUM(product_qty), 0.0) AS reserved_in_moves+ FROM stock_move_line+ WHERE location_id = %(location_id)s+   AND product_id = %(product_id)s+   AND COALESCE(lot_id, 0) = %(lot_id)s+   AND COALESCE(package_id, 0) = %(package_id)s+   AND COALESCE(owner_id, 0) = %(owner_id)s+"""+++class StockQuant(models.Model):+    _inherit = "stock.quant"++    quantity_error = fields.Float(+        "Quantity in Error",+        help="Difference between computed and actual quantity",+        readonly=True,+    )+    quantity_computed = fields.Float(+        "Quantity in Stock Move Lines",+        help="Difference between computed and actual quantity",+        readonly=True,+    )++    @api.constrains("product_id", "reserved_quantity")+    def check_reserved_quantity(self):+        """Check the consistency of reservations.++        - reservations can only be done on physical locations;+        - the sum of reservations for a product on a location, must match the+          move lines having that location as a source location.+        """+        precision = self.env["decimal.precision"].precision_get(+            "Product Unit of Measure"+        )+        for quant in self:+            reserved_quantity = quant.reserved_quantity or 0.0+            location = quant.location_id+            if reserved_quantity > 0.0 and location.usage != "internal":+                raise ValidationError(+                    _(+                        "Invalid attempt to reserve product %s"+                        " for a location with usage %s."+                    )+                    % (quant.product_id.display_name, location.usage,)+                )+            if location.usage != "internal":+                continue+            # Compare reserved quantity in quant with moves for the location.+            parameters = {+                "location_id": self.location_id.id,+                "product_id": self.product_id.id,+                "lot_id": self.lot_id.id or 0,+                "package_id": self.package_id.id or 0,+                "owner_id": self.owner_id.id or 0,+            }+            self.env.cr.execute(RESERVED_STATEMENT, parameters)+            reserved_in_moves = self.env.cr.fetchone()[0]+            _logger.info(+                _("Reserved in quants %s, reserved in moves %s for keys %s"),+                reserved_quantity,+                reserved_in_moves,+                str(parameters),+            )+            comparison = float_compare(+                reserved_quantity, reserved_in_moves, precision_digits=precision+            )+            if comparison == 0:+                continue+            # We detected a mismatch between moves and quants.+            raise ValidationError(+                _(+                    "Mismatch between reserved product quantity according to"+                    " quants %s and accourding to moves %s for product %s"+                    " in location %s."+                )+                % (+                    reserved_quantity,+                    reserved_in_moves,+                    quant.product_id.display_name,+                    location.complete_name,+                )+            )++    @api.model+    def cron_check_quant_consistency(self):+        """Check consistency of quants when compared with stock move lines."""+        cursor = self.env.cr+        # First check wether quants have unique keys.+        quants_unique = True+        cursor.execute(UNIQUE_QUANTS_STATEMENT)+        for row in cursor.fetchall():+            quants_unique = False+            _logger.error(_("Duplicate quant keys %s"), str(row))+        if not quants_unique:+            raise UserError(_("Cron to check quants aborted because of duplicat keys"))+        # Continue checking quants for mismatches.+        cursor.execute(STOCK_STATEMENT)+        for row in cursor.fetchall():+            _logger.error(_("Mismatch in stock %s"), str(row))+            self._do_repair(row)++    def _do_repair(self, row):+        """Repair (or create) stock_quant, based on stock moves."""

@NL66278 Well the docstring looks promising!

I have quite some experience in this problem. The biggest issue is of course failed to reserve/unreserve. I have never quite traced it but I feel it has to do with stock.inventory validation. In general the total qty is correct, but the movelines are not. The other one is within a failed transaction, again never quite tracked it, but the quant gets committed and the move rolled back, which of course breaks 2 quants.

I am very interested in this problem and have some database full of inconsistencies to test. V12 and V14 only mind you but looks pretty easy backport for me once you have something. Just ping when ready.

NL66278

comment created time in 3 days

PullRequestReviewEvent

delete branch odoonz/odoonz-addons

delete branch : 14.0-product_list_price_change

delete time in 3 days

push eventodoonz/odoonz-addons

Ammon Leslie

commit sha e4f4d5f14598a19cf1d556a5e4db40279483f99c

Failsafe partner key for price updates

view details

push time in 3 days

pull request commentOCA/stock-logistics-workflow

[14.0][FIX] stock_picking_filter_lot configurable per operation_type

I had a think about it. For me I'd prefer this picking type stuff is in another module and we do something like this to avoid the dependency. But done without the dependency, and a default of true on the picking types I wouldn't block it for in the main module.

In pseudocode

class MoveLine(...)
    filter_lots = fields.Boolean(related=<picking_type_field>)

class PickingType(..)
  filter_lots = fields.Boolean(default=True)

We can just use the boolean value in the view domain.

Then on the views we just add <field name='filter_lots', invisible='1' />

And for the field domain we just have [(product),(company)] + (filter_lots and [(location)] or [])

remi-filament

comment created time in 3 days

push eventodoonz/odoonz-addons

Graeme Gellatly

commit sha 849468d47ffe25d54adfa092f2aa97fa50ec1784

[FIX] Failsafe partner key for price updates

view details

push time in 3 days

PullRequestReviewEvent

Pull request review commentOCA/stock-logistics-workflow

[14.0][MIG] stock_picking_backorder_strategy: Migration to 14.0

+# Copyright 2018 ACSONE SA/NV+# License AGPL-3.0 or later (http://www.gnu.org/licenses/agpl).++from odoo import models+++class StockPicking(models.Model):+    _inherit = "stock.picking"++    def _check_backorder(self):+        # If strategy == 'manual', let the normal process going on+        self = self.filtered(lambda p: p.picking_type_id.backorder_strategy == "manual")

Just 1 little note here. I had sometimes a problem with infinite recursion on a similar idiom, not identical. Changing super recordset argument and calling super() although in that case it was to effectively process lines one by one.

I guess tests are passing. So just a note.

sebalix

comment created time in 4 days

PullRequestReviewEvent

pull request commentOCA/stock-logistics-workflow

[14.0][FIX] stock_picking_filter_lot configurable per operation_type

Hi

Are we sure this is the way to go? It seems really complicated way to solve a simple issue. And usability wise it isn't nice. Not to mention merging will break existing installations. Then even when they do get the dependencies, they need to update all existing picking types, surely the default must be true here.

The problem only presents in a non standard configuration, mostly for receiving existing lots. Personally I feel this change needs to be its own module. But I also feel we are missing a much easier solution. I just can't think of it but it revolves around location_id.usage.

Also computed and related fields are readonly by default. There is no need to set that.

remi-filament

comment created time in 4 days

push eventodoonz/odoonz-addons

Graeme Gellatly

commit sha c30825370f44668be6aab8fce02d78e1c482d60a

Failsafe partner key for price updates

view details

push time in 4 days

issue commentodoo/odoo

how can i send a request like this select count(*) from account.invoice group by partner_id !! ???

in Database psql - although use ; rather than !! ???

in UI Open Interface -> Group By partner_id and it will send largely that exact request just without all the punctuation at end.

ASMA149

comment created time in 5 days

Pull request review commentOCA/OpenUpgrade

[IMP] account: Migration of grouped invoice lines. Allow to import notes and sections

 def migration_invoice_moves(env):         )         if not env.cr.fetchone():             break  # exit condition not having more duplicates+    # Checking the missing lines to import+    openupgrade.logged_query(+        env.cr, """+        UPDATE account_invoice_line ail+        SET aml_matched = FALSE+        """+    )+    openupgrade.logged_query(+        env.cr, """+        UPDATE account_invoice_line ail+        SET aml_matched = TRUE+        FROM account_move_line aml+        WHERE aml.old_invoice_line_id = ail.id+        """+    )

@MiquelRForgeFlow I'm all for simple code. But as I say I got 2 cases where it just produces wrong results. And I still think ignoring the amounts is flawed. Obviously my hacky flattening is not how Odoo SA does it, it is just 1 function called with different arguments.

And it sounds like @etobella is experiencing something related.

etobella

comment created time in 6 days

PullRequestReviewEvent

pull request commentOCA/edi

[ADD] edi_pdf2data

@pedrobaeza Yes of course, until it doesn't. In practical use, simple_pdf is most suited to regular bills, coded to 1 line. If you use operating-unit, or you use purchase orders and stock, forget it, if you need to fill the origin field, forget it. For me they are completely different use cases for different kinds of businesses/supplier invoices.

As for pipeline issues, yes there were some problematic commits and release tags on invoice2data. A typo and then a py 3.6 f-string. In fact I was just fixing a v12 server for precisely that.

etobella

comment created time in 6 days

pull request commentOCA/edi

[ADD] edi_pdf2data

@pedrobaeza personally I think invoice2data is the less harmful dependency than the dependencies of #432. I have spent quite some time with invoice2data (2+ years), pymupdf (again 2+years) and #432 (in test and eval) and this is much more in line with my ideal than the existing invoice2data_pdf module, the new simple_pdf proposal and actually my own work I am porting to v14.

Multiline support for a start is a key differentiator. OCR processing too although more fringe. My main issue with the 2 existing ones coming from invoice import is the ignorance of purchase orders in a stock environment.

The main benefits of simple_pdf proposal is the fields interface and I think in future that idea could be generalised for the basic fields. Also for non-Europeans, the OCA dependencies are annoying for simple_pdf. We have to install all sorts of Euro specific data files. This is nice and clean.

But honestly, PyMuPDF is great when it works, and admittedly it is being used in a rather simple use case here, but it is a dependency you'd live without if you could IMO. But things like dynamic form filling on printed pdf forms it is pretty much all there is that works.

etobella

comment created time in 6 days

Pull request review commentOCA/OpenUpgrade

[IMP] account: Migration of grouped invoice lines. Allow to import notes and sections

 def migration_invoice_moves(env):         )         if not env.cr.fetchone():             break  # exit condition not having more duplicates+    # Checking the missing lines to import+    openupgrade.logged_query(+        env.cr, """+        UPDATE account_invoice_line ail+        SET aml_matched = FALSE+        """+    )+    openupgrade.logged_query(+        env.cr, """+        UPDATE account_invoice_line ail+        SET aml_matched = TRUE+        FROM account_move_line aml+        WHERE aml.old_invoice_line_id = ail.id+        """+    )

@MiquelRForgeFlow I have serious doubts on this aml_matched code. I got 2 cases now where it just isn't working. It basically just displays the same problem as before except instead of first it is last match. @etobella is actually just covering the effect, not the cause (which IMHO is the total ignorance of line values in the algorithm), but I spent so long inside that while loop I just can't work out where it goes wrong. It looks perfect.

I honestly feel like we have adopted the wrong approach here altogether with invoice migration and that Odoo SA has got it more right by applying ever restrictive rules and making decision based on amounts, among other things.

I used this really ugly code here (note it doesn't do grouped, because I didn't need) https://github.com/odoonz/OpenUpgrade/blob/13.0/addons/account/migrations/13.0.1.1/post-migration.py to kind of emulate and mismatches dropped from 300,000+ with current code to 57. Of the 57, 51 were due to an import/export bug allowing overwriting posted journals.

Now Odoo SA does make grouped invoice lines into comments and in this case I feel we do better.

FYI, here is some enterprise log output from a currently running enterprise mig, I think all in it applies 250 of these conditions. They are actually stored as data in postgres table so can provide all.

2021-09-20 06:50:39,940 2012 INFO db_31437 odoo.addons.base.maintenance.migrations.account.saas-12.4.end-09-account-pocalypse: insert query 183: cond:{'same_account', 'same_trimmed_name', 'paid_invoice_posted_move', 'nearly_same_amount', 'same_product'} 
2021-09-20 06:50:43,403 2012 INFO db_31437 odoo.addons.base.maintenance.migrations.account.saas-12.4.end-09-account-pocalypse: invoices: fill line mapping with +8/-8 entries using conditions {'same_account', 'same_trimmed_name', 'paid_invoice_posted_move', 'nearly_same_amount', 'same_product'} 
2021-09-20 06:50:43,754 2012 INFO db_31437 odoo.addons.base.maintenance.migrations.account.saas-12.4.end-09-account-pocalypse: invoices: still 55318 to match 
2021-09-20 06:50:43,754 2012 INFO db_31437 odoo.addons.base.maintenance.migrations.account.saas-12.4.end-09-account-pocalypse: insert query 184: cond:{'same_chopped_name', 'same_account', 'paid_invoice_posted_move', 'nearly_same_amount', 'same_product'} 
2021-09-20 06:50:44,196 2012 INFO db_31437 odoo.addons.base.maintenance.migrations.account.saas-12.4.end-09-account-pocalypse: invoices: fill line mapping with +0/-0 entries using conditions {'same_chopped_name', 'same_account', 'paid_invoice_posted_move', 'nearly_same_amount', 'same_product'} 
2021-09-20 06:50:44,543 2012 INFO db_31437 odoo.addons.base.maintenance.migrations.account.saas-12.4.end-09-account-pocalypse: invoices: still 55318 to match 
2021-09-20 06:50:44,543 2012 INFO db_31437 odoo.addons.base.maintenance.migrations.account.saas-12.4.end-09-account-pocalypse: insert query 185: cond:{'same_name_first_line', 'same_account', 'paid_invoice_posted_move', 'nearly_same_amount', 'same_product'} 
2021-09-20 06:50:48,081 2012 INFO db_31437 odoo.addons.base.maintenance.migrations.account.saas-12.4.end-09-account-pocalypse: invoices: fill line mapping with +8/-8 entries using conditions {'same_name_first_line', 'same_account', 'paid_invoice_posted_move', 'nearly_same_amount', 'same_product'} 
2021-09-20 06:50:48,428 2012 INFO db_31437 odoo.addons.base.maintenance.migrations.account.saas-12.4.end-09-account-pocalypse: invoices: still 55318 to match 
2021-09-20 06:50:48,428 2012 INFO db_31437 odoo.addons.base.maintenance.migrations.account.saas-12.4.end-09-account-pocalypse: insert query 186: cond:{'same_account', 'paid_invoice_posted_move', 'nearly_same_amount', 'substring_name', 'same_product'} 
2021-09-20 06:50:51,878 2012 INFO db_31437 odoo.addons.base.maintenance.migrations.account.saas-12.4.end-09-account-pocalypse: invoices: fill line mapping with +8/-8 entries using conditions {'same_account', 'paid_invoice_posted_move', 'nearly_same_amount', 'substring_name', 'same_product'} 
2021-09-20 06:50:52,228 2012 INFO db_31437 odoo.addons.base.maintenance.migrations.account.saas-12.4.end-09-account-pocalypse: invoices: still 55318 to match 
2021-09-20 06:50:52,228 2012 INFO db_31437 odoo.addons.base.maintenance.migrations.account.saas-12.4.end-09-account-pocalypse: insert query 187: cond:{'same_account', 'same_not_null_product', 'paid_invoice_posted_move', 'nearly_same_amount'} 
2021-09-20 06:50:55,712 2012 INFO db_31437 odoo.addons.base.maintenance.migrations.account.saas-12.4.end-09-account-pocalypse: invoices: fill line mapping with +8/-8 entries using conditions {'same_account', 'same_not_null_product', 'paid_invoice_posted_move', 'nearly_same_amount'} 
2021-09-20 06:50:56,067 2012 INFO db_31437 odoo.addons.base.maintenance.migrations.account.saas-12.4.end-09-account-pocalypse: invoices: still 55318 to match 
etobella

comment created time in 6 days

PullRequestReviewEvent

push eventodoonz/odoonz-addons

Graeme Gellatly

commit sha 8536e15f8b14ff7400486c2e4cfb60bd04d3e916

Minor Bug fixes.

view details

push time in 6 days

issue commentOCA/OpenUpgrade

OCA Days 2021 Talk Requests on Openupgrade

Hi @legalsylvain

Thankyou for your interest. https://odoo-community.org/event/oca-days-2021-online-2021-10-28-2021-10-29-128/track_proposal The details are there but in summary 28/29th October. 30/60/ (90 - training) minute slots.

In further discussions, OpenUpgrade may have a number of shorter talks on different areas. It is the most requested topic.

gdgellatly

comment created time in 11 days

issue openedOCA/OpenUpgrade

OCA Days 2021 Talk Requests on Openupgrade

  • New framework, using / writing.
  • Openupgrade writing migrations best practice/process

If you feel like doing these for OCA Days please let me know.

created time in 11 days

push eventodoonz/odoonz-addons

Graeme Gellatly

commit sha 5123b007467b3351d24c27c6a0c91d6db78e6b63

Fix account central billing migration script

view details

Graeme Gellatly

commit sha cadb0049b4688579cbf70491c7a6e550d4023666

Remove Redundant Module - sale_purchase_count - now in upstream

view details

push time in 12 days

pull request commentOCA/edi

[14.0] New module account_invoice_import_simple_pdf (invoice2data alternative)

@alexis-via I've started looking at this. I'd like to decouple the invoice parser from needing specific fields knowledge to ease extensibility. e..g If I want to add Operating Unit, or payment ref, or origin. What do you think? Partial diff below of the idea. I know the base is still somewhat tightly coupled but doesn't always need to be.

Also comma not coma, quite different pauses :)

@@ -295,6 +295,15 @@ class AccountInvoiceImportSimplePdfFields(models.Model):
         else:
             parsed_inv["failed_fields"].append(self.name)
 
+    def _get_date_due(self, *args):
+        return self._get_date(*args)
+
+    def _get_date_start(self, *args):
+        return self._get_date(*args)
+
+    def _get_date_end(self, *args):
+        return self._get_date(*args)
+
--- a/account_invoice_import_simple_pdf/wizard/account_invoice_import.py
+++ b/account_invoice_import_simple_pdf/wizard/account_invoice_import.py
@@ -162,16 +162,10 @@ class AccountInvoiceImport(models.TransientModel):
         # Check field config
         for field in partner.simple_pdf_field_ids:
             logger.debug("Working on field %s", field.name)
-            if field.name.startswith("date"):
-                field._get_date(parsed_inv, raw_text, partner_config, test_info)
-            elif field.name.startswith("amount_"):
-                field._get_amount(parsed_inv, raw_text, partner_config, test_info)
-            elif field.name == "invoice_number":
-                field._get_invoice_number(
-                    parsed_inv, raw_text, partner_config, test_info
-                )
-            elif field.name == "description":
-                field._get_description(parsed_inv, raw_text, partner_config, test_info)
+            try:
+                getattr(field, "_get_%s" % field.name)(parsed_inv, raw_text, partner_config, test_info)
+            except AttributeError:
+                logger.warning("Failed to find parse function for field %s", field.name)
 
         failed_fields = parsed_inv.pop("failed_fields")
alexis-via

comment created time in 13 days

push eventodoonz/OpenUpgrade

Graeme Gellatly

commit sha ca01f2434464c23fab7dc14498589364c4374732

13.0 Openupgrade Invoice Match improvement - add back exclude from tab query

view details

push time in 13 days

pull request commentOCA/helpdesk

[12.0][RFC] helpdesk_mgmt: refactor portal template

@marcelsavegnago for me it is OK. I only did tech review of python code. Probably better a functional review but i have noone left on 12.0 using helpesk.

marcelsavegnago

comment created time in 15 days

push eventodoonz/OpenUpgrade

Graeme Gellatly

commit sha 126a4a657cd34dca0729ce09351822b076655f56

9.0 Openupgrade tax match optimization - experiment #1

view details

Graeme Gellatly

commit sha 6d0785b0b1754dc3e06cc7a91f9f3ce0e0c2a865

9.0 Openupgrade tax match optimization - experiment #1 - use right code

view details

Graeme Gellatly

commit sha 9f4ea8f9bff78c54fbc3012a2761f8a755d36012

Merge pull request #7 from odoonz/9.0-opt-tax-fill 9.0 opt tax fill

view details

push time in 16 days