Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[14.0]intrastat Brexit support #163

Merged
merged 10 commits into from
May 15, 2022
Merged

Conversation

luc-demeyer
Copy link
Contributor

No description provided.

@pedrobaeza
Copy link
Member

Please rebase/cherry-pick instead of pulling for avoiding the merge commits.

@luc-demeyer
Copy link
Contributor Author

@alexis-via
I have tested the changes in this module with your l10n_fr_intrastat_product localisation and it looks ok: my changes seem to be non-breaking for the localisation modules but imho we should forward port this PR asap to 15.0 and remove the deprecated fields and logic from the localisation modules.

While testing l10n_fr_intrastat_product I encountered what I believe is a functonal bug (but unrelated to the brexit change in this PR). I have created a PR for this one, cf. OCA/l10n-france#357

I was also surprised to find the _get_product_origin_country in your module with a warning on missing product country of origin. In Belgium we can simply specify 'QU' as country code in this case.

@@ -490,8 +490,30 @@ def _get_incoterm(self, inv_line, notedict):
return incoterm

def _get_product_origin_country(self, inv_line, notedict):
_logger.warning(

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In Odoo Community, they are using warnings.warn with a DeprecationWarning and this warning is shown in logs but also in the IDE (at least Pycharm does it) as Deprecated https://github.com/odoo/odoo/blob/687d88eeea836aacbcd1b079e82e597d1bd9309c/addons/account/models/account_move.py#L119

@luc-demeyer
Copy link
Contributor Author

@jdidderen-be
Thanks for your review. Code adapted accordingly.

vals["product_origin_country_code"] = (
vals["product_origin_country_code"].upper().strip()
)
if len(vals["product_origin_country_code"]) != 2:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of having a check here on the length, I think it would be more easier and user-friendly to have a max-length directly on the field to be warned beforehand.

Copy link

@vanderperre vanderperre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Luc,

the version must take into account of the 14.0.1.5.4 changes ....

When i copy/paste in my current last oca update ....:

 "name": "Intrastat Product",
  • "version": "14.0.1.5.4",
  • "version": "14.0.1.5.3",
    "category": "Intrastat",

A+

Screen Shot 2022-05-12 at 12 14 59

aaah Ok, the versioning is automatic with the runbot ... ;)

@OCA-git-bot
Copy link
Contributor

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

@luc-demeyer
Copy link
Contributor Author

/ocabot merge minor

@OCA-git-bot
Copy link
Contributor

On my way to merge this fine PR!
Prepared branch 14.0-ocabot-merge-pr-163-by-luc-demeyer-bump-minor, awaiting test results.

@OCA-git-bot OCA-git-bot merged commit 9faa481 into OCA:14.0 May 15, 2022
@OCA-git-bot
Copy link
Contributor

Congratulations, your PR was merged at 1d203b6. Thanks a lot for contributing to OCA. ❤️

@alexis-via
Copy link
Contributor

With this code, we now have this bug when a French company sells to a belgian companies but the goods are delivered to spain: cf last line of the screenshot
Src/Dest Country = Spain
Country code = BE

bug_intrastat

This is because the country code is now only generated by looking at the commercial_partner_id of the invoice, without consideration for the field "src_dest_country_id". It's great to have super code for Northern-Ireland, but I should not break basic country code scenarios!

@alexis-via
Copy link
Contributor

Other issues caused by this PR:

  • we don't see the product country of origin any more, but only it's code, which makes it more difficult for the user to control the data before validating the declaration.
  • the field "origin_state_id" is always displayed on product form view in the first tab, which is really a waste given that's it is only for products from Northern Ireland... I don't think we can afford that on the product form ! => what do you think about displaying it only when the country is UK ?

I really think that we shouldn't have gone so far for Northern Ireland. Northern Ireland is a mess anyway, so we should not try to make the "perfect" implementation with so many drawbacks for all users. I think my previous implementation was "good enough" and didn't cause so many drawback for such a corner-case scenario.

xu_counties = uk_counties.filtered(lambda r: r not in self._get_xi_counties())
return xu_counties

def _get_intrastat_country_code(self, country=None, state=None):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is really strange with it's "if self / else" ! When self has a value, then the arguments country and state are ignored, which is surprising. For me, instead of this wired code, we should have 2 separate methods, the first one calling the second one.

string="Country of Origin of the Product",
size=2,
required=True,
default="QU",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find it a bit "too easy" to use QU by default. I think we should display a warning in the warning dialog box about the fact that the country of origin is missing on product X and say that we've set the country code to QU as a temporary solution.

<field
name="product_origin_country_code"
attrs="{'column_invisible': [('parent.declaration_type', '=', 'arrivals')]}"
string="Product C/O"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In France, since for reform of January 2022 1st, we have to declare the product country of origin on arrivals AND departures! I would be very surprised if it was not the case in other countries. Cf page 28 section "9. Pays d'origine" of this PDF : https://www.douane.gouv.fr/sites/default/files/2021-12/21/Note-enquete-statistique-EMEBI-2022.pdf

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants