FIX after changing customer on SO with lines, can't save sale order anymore #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…nymore See odoo/odoo#17618 Also add button to recompute agents on SO lines
hurrinico
pushed a commit
that referenced
this pull request
Jun 23, 2017
FIX after changing customer on SO with lines, can't save sale order anymore
hurrinico
pushed a commit
that referenced
this pull request
Jun 23, 2017
FIX after changing customer on SO with lines, can't save sale order anymore
hurrinico
pushed a commit
that referenced
this pull request
Jun 23, 2017
FIX after changing customer on SO with lines, can't save sale order anymore
hurrinico
pushed a commit
that referenced
this pull request
Jun 27, 2017
FIX after changing customer on SO with lines, can't save sale order anymore
hurrinico
pushed a commit
that referenced
this pull request
Jun 27, 2017
FIX after changing customer on SO with lines, can't save sale order anymore
hurrinico
pushed a commit
that referenced
this pull request
Jun 27, 2017
FIX after changing customer on SO with lines, can't save sale order anymore
eLBati
added a commit
that referenced
this pull request
Aug 8, 2017
#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
eLBati
added a commit
that referenced
this pull request
Aug 21, 2017
#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
eLBati
added a commit
that referenced
this pull request
Aug 21, 2017
#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
eLBati
added a commit
that referenced
this pull request
Aug 21, 2017
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See #2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
eLBati
added a commit
that referenced
this pull request
Aug 21, 2017
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See #2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
etobella
pushed a commit
to etobella/commission
that referenced
this pull request
Oct 17, 2017
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
pedrobaeza
added a commit
to Tecnativa/commission
that referenced
this pull request
Apr 1, 2018
These onchanges were introduced in hurrinico#2, but they are causing that sales orders that have been invoiced with the proper commissions propagated from sales, to empty their values when changing one of the following values: * Partner * Journal * Invoice date * Payment term Having the button for recomputing the agents is enough when you want to recompute agents for the new data. Take into account that there are a lot of module extensions that can put different agents according some conditions on sales order, but not on invoices (for example, sale_commission_formula with formula only in sales orders, or the new sale_commission_pricelist, that bases the commission on the pricelist item used, and that's only applicable on sales orders).
pedrobaeza
added a commit
to Tecnativa/commission
that referenced
this pull request
Apr 1, 2018
Some onchanges were introduced in hurrinico#2 for workarounding the issue odoo/odoo#17618, but they are causing that sales orders that have been invoiced with the proper commissions propagated from sales, to empty their values when changing one of the following values: * Partner * Journal * Invoice date * Payment term It should be taking into account that there are a lot of extensions to this module that can put different agents according some conditions on sales order, but not on invoices (for example, sale_commission_formula with formula only in sales orders, or the new sale_commission_pricelist, that bases the commission on the pricelist item used, and that's only applicable on sales orders). More over, the problem will still appears if you add in other module another onchange. The solution to properly bypass the issue is to directly not add the field on the invoice form view. This way, there are no glitches. To compensate it, I have add it a computed field that show the same information, or even better, as we reduce the number of fields to 1 instead of 2, and this field can be used for expanding the given information.
pedrobaeza
added a commit
to Tecnativa/commission
that referenced
this pull request
Apr 1, 2018
Some onchanges were introduced in hurrinico#2 for workarounding the issue odoo/odoo#17618, but they are causing that sales orders that have been invoiced with the proper commissions propagated from sales, to empty their values when changing one of the following values: * Partner * Journal * Invoice date * Payment term It should be taking into account that there are a lot of extensions to this module that can put different agents according some conditions on sales order, but not on invoices (for example, sale_commission_formula with formula only in sales orders, or the new sale_commission_pricelist, that bases the commission on the pricelist item used, and that's only applicable on sales orders). More over, the problem will still appears if you add in other module another onchange. The solution to properly bypass the issue is to directly not add the field on the invoice form view. This way, there are no glitches. To compensate it, I have add it a computed field that show the same information, or even better, as we reduce the number of fields to 1 instead of 2, and this field can be used for expanding the given information.
pedrobaeza
added a commit
to Tecnativa/commission
that referenced
this pull request
Apr 1, 2018
Some onchanges were introduced in hurrinico#2 for workarounding the issue odoo/odoo#17618, but they are causing that sales orders that have been invoiced with the proper commissions propagated from sales, to empty their values when changing one of the following values: * Partner * Journal * Invoice date * Payment term It should be taking into account that there are a lot of extensions to this module that can put different agents according some conditions on sales order, but not on invoices (for example, sale_commission_formula with formula only in sales orders, or the new sale_commission_pricelist, that bases the commission on the pricelist item used, and that's only applicable on sales orders). More over, the problem will still appears if you add in other module another onchange. The solution to properly bypass the issue is to directly not add the field on the invoice form view. This way, there are no glitches. To compensate it, I have add it a computed field that show the same information, or even better, as we reduce the number of fields to 1 instead of 2, and this field can be used for expanding the given information.
pedrobaeza
added a commit
to Tecnativa/commission
that referenced
this pull request
Apr 1, 2018
Some onchanges were introduced in hurrinico#2 for workarounding the issue odoo/odoo#17618, but they are causing that sales orders that have been invoiced with the proper commissions propagated from sales, to empty their values when changing one of the following values: * Partner * Journal * Invoice date * Payment term It should be taking into account that there are a lot of extensions to this module that can put different agents according some conditions on sales order, but not on invoices (for example, sale_commission_formula with formula only in sales orders, or the new sale_commission_pricelist, that bases the commission on the pricelist item used, and that's only applicable on sales orders). More over, the problem will still appears if you add in other module another onchange. The solution to properly bypass the issue is to directly not add the field on the invoice form view. This way, there are no glitches. To compensate it, I have add it a computed field that show the same information, or even better, as we reduce the number of fields to 1 instead of 2, and this field can be used for expanding the given information.
pedrobaeza
added a commit
to Tecnativa/commission
that referenced
this pull request
Apr 1, 2018
Some onchanges were introduced in hurrinico#2 for workarounding the issue odoo/odoo#17618, but they are causing that sales orders that have been invoiced with the proper commissions propagated from sales, to empty their values when changing one of the following values: * Partner * Journal * Invoice date * Payment term It should be taking into account that there are a lot of extensions to this module that can put different agents according some conditions on sales order, but not on invoices (for example, sale_commission_formula with formula only in sales orders, or the new sale_commission_pricelist, that bases the commission on the pricelist item used, and that's only applicable on sales orders). More over, the problem will still appears if you add in other module another onchange. The solution to properly bypass the issue is to directly not add the field on the invoice form view. This way, there are no glitches. To compensate it, I have add it a computed field that show the same information, or even better, as we reduce the number of fields to 1 instead of 2, and this field can be used for expanding the given information.
pedrobaeza
added a commit
to Tecnativa/commission
that referenced
this pull request
May 2, 2018
Some onchanges were introduced in hurrinico#2 for workarounding the issue odoo/odoo#17618, but they are causing that sales orders that have been invoiced with the proper commissions propagated from sales, to empty their values when changing one of the following values: * Partner * Journal * Invoice date * Payment term It should be taking into account that there are a lot of extensions to this module that can put different agents according some conditions on sales order, but not on invoices (for example, sale_commission_formula with formula only in sales orders, or the new sale_commission_pricelist, that bases the commission on the pricelist item used, and that's only applicable on sales orders). More over, the problem will still appears if you add in other module another onchange. The solution to properly bypass the issue is to directly not add the field on the invoice form view. This way, there are no glitches. To compensate it, I have add it a computed field that show the same information, or even better, as we reduce the number of fields to 1 instead of 2, and this field can be used for expanding the given information.
|
why not call recompute_agents in onchange directly? |
|
@scigghia I think we would got into odoo/odoo#17618 anyway |
carlosdauden
pushed a commit
to Tecnativa/commission
that referenced
this pull request
Jul 23, 2018
Some onchanges were introduced in hurrinico#2 for workarounding the issue odoo/odoo#17618, but they are causing that sales orders that have been invoiced with the proper commissions propagated from sales, to empty their values when changing one of the following values: * Partner * Journal * Invoice date * Payment term It should be taking into account that there are a lot of extensions to this module that can put different agents according some conditions on sales order, but not on invoices (for example, sale_commission_formula with formula only in sales orders, or the new sale_commission_pricelist, that bases the commission on the pricelist item used, and that's only applicable on sales orders). More over, the problem will still appears if you add in other module another onchange. The solution to properly bypass the issue is to directly not add the field on the invoice form view. This way, there are no glitches. To compensate it, I have add it a computed field that show the same information, or even better, as we reduce the number of fields to 1 instead of 2, and this field can be used for expanding the given information.
aitorbouzas
pushed a commit
to aitorbouzas/commission
that referenced
this pull request
Oct 5, 2018
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
aitorbouzas
pushed a commit
to aitorbouzas/commission
that referenced
this pull request
Oct 5, 2018
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
pedrobaeza
added a commit
to Tecnativa/commission
that referenced
this pull request
Nov 21, 2018
Some onchanges were introduced in hurrinico#2 for workarounding the issue odoo/odoo#17618, but they are causing that sales orders that have been invoiced with the proper commissions propagated from sales, to empty their values when changing one of the following values: * Partner * Journal * Invoice date * Payment term It should be taking into account that there are a lot of extensions to this module that can put different agents according some conditions on sales order, but not on invoices (for example, sale_commission_formula with formula only in sales orders, or the new sale_commission_pricelist, that bases the commission on the pricelist item used, and that's only applicable on sales orders). More over, the problem will still appears if you add in other module another onchange. The solution to properly bypass the issue is to directly not add the field on the invoice form view. This way, there are no glitches. To compensate it, I have add it a computed field that show the same information, or even better, as we reduce the number of fields to 1 instead of 2, and this field can be used for expanding the given information.
pedrobaeza
pushed a commit
to Tecnativa/commission
that referenced
this pull request
Dec 14, 2018
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
pedrobaeza
pushed a commit
to Tecnativa/commission
that referenced
this pull request
Dec 14, 2018
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
manuelcalerosolis
pushed a commit
to Tecnativa/commission
that referenced
this pull request
Mar 31, 2020
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
manuelcalerosolis
pushed a commit
to Tecnativa/commission
that referenced
this pull request
Apr 13, 2020
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
manuelcalerosolis
pushed a commit
to Tecnativa/commission
that referenced
this pull request
Apr 16, 2020
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
pedrobaeza
pushed a commit
to Tecnativa/commission
that referenced
this pull request
Jul 6, 2020
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
cjallais
pushed a commit
to archeti-org/commission
that referenced
this pull request
Feb 9, 2021
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
fredzamoabg
pushed a commit
to fredzamoabg/commission
that referenced
this pull request
May 25, 2021
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
manuelcalerosolis
pushed a commit
to xtendoo-corporation/commission
that referenced
this pull request
Mar 8, 2022
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
slominchar
pushed a commit
to archeti-org/commission
that referenced
this pull request
Mar 9, 2022
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
AungKoKoLin1997
pushed a commit
to AungKoKoLin1997/commission
that referenced
this pull request
Sep 7, 2022
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
AungKoKoLin1997
pushed a commit
to qrtl/commission
that referenced
this pull request
Sep 19, 2022
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
AungKoKoLin1997
pushed a commit
to qrtl/commission
that referenced
this pull request
Nov 5, 2022
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
yostashiro
pushed a commit
to qrtl/commission
that referenced
this pull request
Nov 19, 2022
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
hildickethan
pushed a commit
to Studio73/commission
that referenced
this pull request
Dec 26, 2022
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
hildickethan
pushed a commit
to Studio73/commission
that referenced
this pull request
Dec 27, 2022
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
hildickethan
pushed a commit
to Studio73/commission
that referenced
this pull request
Dec 28, 2022
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
hildickethan
pushed a commit
to Studio73/commission
that referenced
this pull request
Jan 2, 2023
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
ambientWave
pushed a commit
to ambientWave/commission
that referenced
this pull request
Jan 19, 2024
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
Tisho99
pushed a commit
to sygel-technology/commission
that referenced
this pull request
Apr 30, 2024
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
Borruso
pushed a commit
to Borruso/commission
that referenced
this pull request
Dec 6, 2024
as May would have June as period start: ((5 - 1) // 3 + 1) * 3 instead, the new formula: >>> for m in range(1, 13): ... print (m - 1) // 3 * 3 + 1 ... 1 1 1 4 4 4 7 7 7 10 10 10 See hurrinico#2 and odoo/odoo#17618 This extends the workaround, fixing "Record not found" after changing invoice date, for example
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Also add button to recompute agents on SO lines
This is a workaround for odoo/odoo#17618