[ADD] 9.0 saleorder_import_invoice2data and [MIG] sale_commercial_partner / sale_order_import

[thomaspaulb]

@hbrunn Tests are running but code needs review

[thomaspaulb]

@Kiplangatdan requesting changes

[thomaspaulb]

If done properly I think we should be second in the list

[thomaspaulb]

There must be a prettier way to do this, the issue was that dict(fake_so._cache) returns the objects in a dict, whereas we need the id's.

[thomaspaulb]

Actually have found it in @hbrunn's commits, see comment below

[thomaspaulb]

@Kiplangatdan Why was it necessary to change all the name occurrences to string or group ? IMO name is the preferred way to make the object accessible to inheriting views, and it's commonly used in Odoo 9.

If the aim was to add a caption, you can leave the name and add string separately.

[thomaspaulb]

Invoice2data

[thomaspaulb]

Maybe this should be the OCA instead.

[thomaspaulb]

I think we should use this as an example to clean up this

[hbrunn]

this is slightly more complicated, here the fixed version: https://github.com/OCA/edi/pull/11/files#diff-57b8c6799922b0e67a34d15dc8b010a8R142

[thomaspaulb]

Have made it into a helper function:

def get_values_for_create(instance):
    """ Helper function to get values from object as dict """
    return {
        f: instance._fields[f].convert_to_write(v)
        if not isinstance(instance._fields[f],
            fields._RelationalMulti)
        else v.ids
        for f, v in instance._cache.iteritems()
    }

[thomaspaulb]

We should also fix these style issues

[thomaspaulb]

Have seen that Odoo 9.0 already puts partner.commercial_id in this view, so this part can indeed be removed.

[hbrunn]

@thomaspaulb I just changed my proposal for the invoice line parsing, this now is a lot more robust and gives better results. You will have to change your templates though, but the new format is a lot simpler to write

[thomaspaulb]

Alright, we will change the template for the test accordingly. Do you have an example or is it clear from the code? Op 8 mei 2017 18:52 schreef "Holger Brunn" <notifications@github.com>:

…

@thomaspaulb <https://github.com/thomaspaulb> I just changed my proposal for the invoice line parsing, this now is a lot more robust and gives better results. You will have to change your templates though, but the new format is a lot simpler to write — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABZf9KxMQhWJFl1cxLW4CXZAKAZYN6zeks5r30g9gaJpZM4NPQgr> .

[hbrunn]

https://github.com/m3nu/invoice2data/pull/22/files#diff-f4398b8b9e01f2cb73701655ba612b47R11

[hbrunn]

I changed #11 quite a bit, you should rebase your work on this branch. And hopefully we get this merged soon, then reviewing this is a lot simpler because if won't contain #11's cruft diffs any more. Github really needs the prerequisite branch feature launchpad had...

[hbrunn]

there's an API for this: https://github.com/OCA/OCB/blob/9.0/openerp/modules/module.py#L142
But in the end, I think we need a base module that provides a model

class Invoice2dataTemplate(models.Model):
    type = fields.Selection([]) # other modules like yours add a type of template, as in invoice_import, sale_order_import, etc
    template = fields.Text('The template')

This makes it much more convenient to deliver templates in your module.

[thomaspaulb]

Is this something you have done in the invoice version of this module already?

[hbrunn]

no, not yet. For now, just remove this part of the code and set your template path in the test. Then it's very simple to change this later to use the yet-to-be-written module, and the test template will not interfere with normal operations

[hbrunn]

I think it would be nice to add the intersection of line.keys() and self.env['sale.order.line']._fields.keys() to the line values too. This way, you simply have to use odoo names in your templates, and you get whatever exotic field you might want to use without having to write custom code

[hbrunn]

in my own override of this, I use

common_fields = set(self.env['sale.order.line']._fields.keys()) &\
    set(parsed_line.keys()) - set(order_line.keys())
for field in common_fields:
    order_line[field] = parsed_line[field]

this way, you can support arbitrary fields without having to write custom code

[hbrunn]

one class per file

[hbrunn]

what's this override good for? Looks suspiciously like you just copied https://github.com/OCA/edi/blob/9.0/sale_order_import/wizard/sale_order_import.py#L212

[thomaspaulb]

Suspicions confirmed.

[hbrunn]

you destroy modularity here. Do something similar to what account_invoice_import does in sale_order_import

[thomaspaulb]

I am calling super now in case I am not happy with the PDF, I hope that solves the issue

[hbrunn]

it's either model or multi, not both

[coveralls]

Coverage remained the same at 100.0% when pulling a2eeffd on sunflowerit:9.0-saleorder_import_invoice2data into 1802e81 on OCA:9.0.

[coveralls]

Coverage remained the same at 100.0% when pulling a2eeffd on sunflowerit:9.0-saleorder_import_invoice2data into 1802e81 on OCA:9.0.

[coveralls]

Coverage remained the same at 100.0% when pulling e8dae67 on sunflowerit:9.0-saleorder_import_invoice2data into 1802e81 on OCA:9.0.

[coveralls]

Coverage remained the same at 100.0% when pulling e8dae67 on sunflowerit:9.0-saleorder_import_invoice2data into 1802e81 on OCA:9.0.

[coveralls]

Coverage remained the same at 100.0% when pulling ebdf99b on sunflowerit:9.0-saleorder_import_invoice2data into 1802e81 on OCA:9.0.

[hbrunn]

closing this in favor of #21