-
-
Notifications
You must be signed in to change notification settings - Fork 176
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][MIG] l10n_eu_product_adr #109
[14.0][MIG] l10n_eu_product_adr #109
Conversation
StefanRijnhart
commented
Apr 27, 2021
•
edited
Loading
edited
@i-vyshnevska I have observed some points to improve this module; https://github.com/OCA/community-data-files/pull/109/files#diff-d967fda5116ea9b63e06dd49e2557fbfc802b8b6476598adcc50acd9d8b890b5R49-R73. Do you agree, or are there good reasons for some of the current design choices? What part of the specifications does |
@StefanRijnhart your comments looks reasonable, what I can say would be good to have one more POV as work was based on just one customer requirements, also related report appeared to be more specific for the country |
f235435
to
0a7849e
Compare
@StefanRijnhart is this ready now? |
0a7849e
to
fd0a3b5
Compare
@simahawk thank you for your interest. I've now pushed the latest version as accepted by our customer. I believe it is more correct as it allows for multiple entries in the dangerous goods table with the same UN number, distinguished by different packing instructions or limited quantities. It does mean however that the already very bare migration from the previous version was invalidated entirely so I removed it. |
fd0a3b5
to
7366702
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in new version we not distinguish good and waste
7366702
to
6aaf7d0
Compare
@i-vyshnevska sorry, I don't know what you mean by this comment. Can you clarify? |
6aaf7d0
to
6675b8a
Compare
from collections import defaultdict | ||
|
||
from lxml import etree | ||
from openpyxl import load_workbook # pylint: disable=W7936 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please wrap this import with a try
, except
https://github.com/OCA/odoo-community.org/blob/master/website/Contribution/CONTRIBUTING.rst#32imports
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, but this is not necessary in recent versions of Odoo. The linked page (now) mentions this as well:
This rule doesn't apply neither to Odoo >= v12, as an unmet dependency in an uninstalled module doesn't block the service thanks to this commit:
if len(goods.un_number) != 4: | ||
raise ValidationError( | ||
_( | ||
"UN Number %s is invalid because it does not have " | ||
"a length of 4." | ||
) | ||
% goods.un_number | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had to implement that as well. I don't recall why, but the our customer has some cases where the unnumber isn't a 4 digits long string. Here's where I implemented the solution we agreed on https://github.com/OCA/delivery-carrier/compare/0278821af40dc8fef2fc2518f53038a37bb07deb..0758137ff35a9a0e3170b641d566749de802df00
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be interesting to hear when such a number can appear, because no such number appears in any of the specs I've seen!
is_dangerous = fields.Boolean(help="This product belongs to a dangerous class") | ||
adr_goods_id = fields.Many2one("adr.goods", "Dangerous Goods") | ||
adr_class_id = fields.Many2one( | ||
"adr.class", related="adr_goods_id.class_id", readonly=True |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the dangerous attributes can vary from a variant to another, we moved those fields from product.template
to product.variant
.
see this PR #112
Could you please do the same?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, I will take care of that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See new commit [RFR] l10n_eu_product_adr: allow different adr goods per variant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
functional tests ok, even if it'll break a lot of module which depends on this one ^^'
However, @i-vyshnevska knows better about this.
previously we had two classes to distinct dangerous "good" and "waste" (products which producing dangerous staff after they used) they treated differently in reports etc |
since our customer does not work with dangerous waste at the moment, I think we can ignore this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@StefanRijnhart
We discussed internally about this, and it does not provide a way to tell that a product is valid or not, regarding the limited_qty.
I provided you a possible solution in the comments.
Thanks!
"vehicles.)" | ||
), | ||
) | ||
limited_quantity = fields.Char() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one should be different
limited_quantity = fields.Char() | |
limited_quantity = fields.Float() | |
limited_quantity_uom = fields.Many2one("uom.uom") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. I will not commit your suggestion directly because of the implications, but I will have a look at this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See new commit "[IMP] l10n_eu_product_adr: distinct uom for limited quantity" in this PR for this.
) | ||
adr_label_ids = fields.Many2many( | ||
"adr.label", related="adr_goods_id.label_ids", readonly=True | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
) | |
) | |
limited_quantity = fields.Boolean("Limited Qty", compute="_compute_limited_quantity", store=True) |
With the compute method like so
@api.onchange("adr_goods_id", "adr_goods_id.limited_quantity_uom", "adr_goods_id.limited_quantity", "uom_id", )
def _compute_limited_quantity(self):
for record in self:
compare product's uom_qty with adr.goods uom_qty:
product.limited_qty = adr.good uom_qty < product uom_qty
We should also ensure than the adr.label
uom has the same uom family as the product one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry, but my customer is a bulk trader. They trade in pallets, or gallons, and the individual subpackaging is encoded in the product name rather than the UoM of the product. So what suits your requirements is not generally valid.
@StefanRijnhart |
@mmequignon I tried to indicate in my comments what I was going to refactor: I hope to finish it this week on Monday or Tuesday. |
ee881f5
to
88ba907
Compare
88ba907
to
2b3fd18
Compare
Currently translated at 81.1% (99 of 122 strings) Translation: community-data-files-13.0/community-data-files-13.0-l10n_eu_product_adr Translate-URL: https://translation.odoo-community.org/projects/community-data-files-13-0/community-data-files-13-0-l10n_eu_product_adr/nl/
Co-authored-by: Iryna Vyshnevska <iryna.vyshnevska@camptocamp.com>
55ed548
to
f2779c1
Compare
I've rebased. As for the status, I'm considering to let this one slip because as expected this does not align well with the team that provided the previous implementation, and I think the communication has not been easy for either side. Also, I'm not working for the project that required this anymore and I'm a bit of a hippie so I prefer to work with bicycles rather than with dangerous goods anyway 😁 |
@bosd The runboat is now working, so you can test it. :) I would too but I don't know enough about this topic to test it properly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
This PR has the |
@jgrandguillaume Can we please merge this one? |
Maybe @OCA/community-data-files-maintainers can help |
FYI On our side we are waiting for @mmequignon to get back to this for a final review. |
/ocabot merge nobump |
This PR looks fantastic, let's merge it! |
Congratulations, your PR was merged at 0a70233. Thanks a lot for contributing to OCA. ❤️ |