[14.0] [ADD] purchase_sale_inter_company: Support returns#653
[14.0] [ADD] purchase_sale_inter_company: Support returns#653thomaspaulb wants to merge 3 commits intoOCA:14.0from
Conversation
|
Hi @aleuffre, @renda-dev, |
thomaspaulb
force-pushed
the
14.0-10738-support-returns
branch
from
2eacd7d to
5befa8b
Compare
thomaspaulb
force-pushed
the
14.0-10738-support-returns
branch
2 times, most recently
from
1863dca to
517f38b
Compare
thomaspaulb
force-pushed
the
14.0-10738-support-returns
branch
from
517f38b to
dd0b31b
Compare
christian-ramos-tecnativa
left a comment
christian-ramos-tecnativa
left a comment
There was a problem hiding this comment.
Hello @thomaspaulb,
Thanks for your work! Could you please review my comments? I'm working in a multicompany environment where each user only has access to one company. With my suggested changes, everything works perfectly.
Thanks again!
thomaspaulb
force-pushed
the
14.0-10738-support-returns
branch
2 times, most recently
from
67e665e to
e97dad7
Compare
- serial number product combined with regular product - backorder created on serial number validation
…o rebel module For product_supplierinfo_inter_company, this introduces a hard requirement to configure a pricelist on each supplier. This makes the tests of other modules fail because they do not set these. For stock_intercompany I don't know why it was set to rebel, it was done before but not updated in the copier template, so just updating copier to reflect reality.
thomaspaulb
force-pushed
the
14.0-10738-support-returns
branch
from
e97dad7 to
36d06c0
Compare
When a return is actioned on the SO side, also process the return on PO side.
thomaspaulb
force-pushed
the
14.0-10738-support-returns
branch
from
36d06c0 to
c398bc0
Compare
|
@Christian-RB Done. Note that in order to solve a number of other bugs I ended up refactoring and simplifying the module: Still pondering how best to contribute this back to OCA, since it's a whole bunch of stuff, and there's a number of other things that have to be brought from 14.0 to 16.0 as well. |
|
I think the best way (To make it easier to review) is splitting the changes in a logical way, by feature or refactor done. |
| # dont trigger on returns of incoming pickings | ||
| if pick.picking_type_code == "incoming": | ||
| return res | ||
|
|
||
| # only trigger in case there is a coupled picking on the other side | ||
| ic_pick = pick.intercompany_picking_id | ||
| if not ic_pick: | ||
| return res |
There was a problem hiding this comment.
We have been working for a couple of weeks with a customer using this PR and it seems like the return of a return make sense in some cases. Is there any reason why this shouldn't be applied?
| # dont trigger on returns of incoming pickings | |
| if pick.picking_type_code == "incoming": | |
| return res | |
| # only trigger in case there is a coupled picking on the other side | |
| ic_pick = pick.intercompany_picking_id | |
| if not ic_pick: | |
| return res | |
| # dont trigger on returns of incoming pickings | |
| if pick.picking_type_code == "incoming" and not pick.intercompany_return_picking_id: | |
| return res | |
| # only trigger in case there is a coupled picking on the other side | |
| ic_pick = pick.intercompany_picking_id or pick.intercompany_return_picking_id | |
| if not ic_pick: | |
| return res |
|
There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. |
github-actions
bot
added
the
stale
3 participants
When a return is actioned on the SO side, also process the return on PO side.