An error occurred fetching the project authors.
- 15 Dec, 2017 1 commit
-
-
Kazuhiko Shiozaki authored
-
- 24 May, 2016 1 commit
-
-
Julien Muchembled authored
-
- 23 May, 2016 3 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
Sometimes, we need to generate amounts with and without aggregation. With this new method, we avoid duplicate computation. The purpose is to generate amounts only once and
-
Julien Muchembled authored
-
- 26 Apr, 2016 1 commit
-
-
Julien Muchembled authored
By default, Base._edit first tests each property with getProperty, not to modify the object when values don't change. Here, getProperty costs a lot (in particular for categories) and rarely/never avoids the use of setters. So here, the main gain is to do something like _edit(force_update=1). As an additional small optimization, we directly use _setProperty instead of _edit. We also stop copying int_index from the Amount Generator Line because it's not useful enough: - float_index may be used instead - or dependency-based sorting is enough - as a last resort, properties can be fetched directly from the causality value, or dynamically with asPredicate and mapped_value_property_list
-
- 12 Jan, 2016 2 commits
-
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
- 16 Oct, 2014 1 commit
-
-
Julien Muchembled authored
-
- 03 Oct, 2014 1 commit
-
-
Julien Muchembled authored
-
- 20 May, 2014 1 commit
-
-
Julien Muchembled authored
The attempt to make sorting stable in commit 28698f35 was broken because there may be pairs of items that can't be compared, and list.sort() relies on < transitivity.
-
- 15 May, 2014 1 commit
-
-
Julien Muchembled authored
-
- 14 May, 2014 2 commits
-
-
Julien Muchembled authored
This implements dependency resolution to sort amount generator lines so that a base_amount is never contributed after it was applied. Before, it was required to sort manually using int_index or float_index, which can be difficult for a human when there are many lines spreaded over different containers (which are merged by composition). Another problematic case is when a set of lines is configured by a user (like discounts & fees) and must all be applied before other lines (taxes) that are installed elsewhere by the developer: how to reliably make sure the latter have index values that are already greater than those entered by the user ? Setting int_index or float_index is now only useful for lines: - with same reference: only the maching one with lowest index is taken into account (commit 68ec6bda) - applying to intermediate values of some base_amount (commit 10be013b) The difficult part to solve dependencies is that the calculation for a given base_amount may trigger the application of other base_amount, and so on recursively. In order to support this case, amount generator lines are first applied on a dummy amount, and getGeneratedAmountQuantity must be call unconditionally for all dependent base_amount. So optimizing like return 3 <= delivery_amount.getGeneratedAmountQuantity('base_amount/1') \ or 1 <= delivery_amount.getGeneratedAmountQuantity('base_amount/2') is wrong except if 'base_amount/2' is only contributed by the movement or if you sort manually with indices. Dependency resolution has precedence over indices. But since the sort is stable, lines will remain sorted by index if it respects dependencies.
-
Julien Muchembled authored
Preliminary commit only to indent a big section of code.
-
- 13 May, 2014 5 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Julien Muchembled authored
Before we dropped amounts with quantity=0 and we stopped doing that because it broke expand. However, there's still one case when such amount can be ignored, i.e. when there's no base_application set on the amount generator.
-
Julien Muchembled authored
-
Julien Muchembled authored
-
- 10 Apr, 2014 2 commits
-
-
Julien Muchembled authored
This is implemented by first changing Composition so that a model can define several lines with same reference, masking inherited ones. There is actually no compatibility issue, because previously, the result would have been undefined (composition only keeping a random line).
-
Julien Muchembled authored
-
- 12 Dec, 2011 1 commit
-
-
Julien Muchembled authored
In the case of Base.asContext, initializing workflow was totally useless because 'workflow_history' was overridden by the original one.
-
- 25 Nov, 2011 1 commit
-
-
Aurel authored
application/contribution in payroll, remove the asserts
-
- 16 Nov, 2011 1 commit
-
-
Tatuya Kamada authored
This reverts commit 2674ce84. The commit broke amount generator functionality. That caused 20 errors, and 64 failures in the test suite.
-
- 15 Nov, 2011 1 commit
-
-
Kazuhiko Shiozaki authored
-
- 06 Sep, 2011 1 commit
-
-
Kazuhiko Shiozaki authored
-
- 31 Aug, 2011 1 commit
-
-
Kazuhiko Shiozaki authored
-
- 22 Feb, 2011 1 commit
-
-
Julien Muchembled authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@43576 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 26 Jan, 2011 3 commits
-
-
Julien Muchembled authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42692 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
Julien Muchembled authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42685 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
Julien Muchembled authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42684 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 12 Jan, 2011 1 commit
-
-
Julien Muchembled authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42272 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 07 Jan, 2011 1 commit
-
-
Julien Muchembled authored
The default value is False, except for getAggregatedAmountList with legacy simulation, in order to fix a backward compatibility issue when solving a simulation tree. git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42117 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 03 Nov, 2010 1 commit
-
-
Julien Muchembled authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@39857 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 25 Oct, 2010 1 commit
-
-
Julien Muchembled authored
To simplify amount generator and because requirements are not clear, support of '*_quantity' variants (as mapped property) is dropped. git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@39505 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 18 Oct, 2010 1 commit
-
-
Julien Muchembled authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@39282 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 15 Oct, 2010 2 commits
-
-
Julien Muchembled authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@39253 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
Julien Muchembled authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@39221 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 14 Oct, 2010 1 commit
-
-
Julien Muchembled authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@39173 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 13 Oct, 2010 1 commit
-
-
Julien Muchembled authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@39110 20353a03-c40f-0410-a6d1-a30d3c3de9de
-