git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@41441 20353a03-c40f-0410-a6d1-a30d3c3de9de

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

be needed to implement constraints in ZODB Property Sheets



git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@39337 20353a03-c40f-0410-a6d1-a30d3c3de9de

- Update API and interfaces
- Make it possible to:
  - do non-linear calculation (via global type-based script)
    for every considered base_amount
    (i.e. not only for base_application of input movements).
    To avoid performance issue, the type-based script is changed to return
    functions instead of calculating results directly.
  - get accumulated values from movements while generating amounts for a
    delivery (i.e. for Amount Generator Lines targetting deliveries).
- Produce amounts even if there is no resource, for reporting.
- Drop probably useless create_line property: checking if there is a resource
  should be enough.
- Prepare refactoring of MRP/Trade/Payroll by introducing AmountGeneratorLine
  class and property sheet.
- Stop doing anything if there is no base_application on an AGL to avoid
  conflicts while figuring out if a movement was created manually or not.
- Update some forms.
- Update testTradeModelLine

git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@39028 20353a03-c40f-0410-a6d1-a30d3c3de9de

(default value for quantity is 0)

git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@37402 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@37131 20353a03-c40f-0410-a6d1-a30d3c3de9de

Conflicts:
	bt5/erp5_base/bt/revision
	bt5/erp5_simulation/DocumentTemplateItem/InvoiceSimulationRule.py
	bt5/erp5_simulation/bt/revision
	bt5/erp5_trade/SkinTemplateItem/portal_skins/erp5_trade/Base_viewTradeFieldLibrary.xml
	bt5/erp5_trade/bt/change_log
	bt5/erp5_trade/bt/revision
	products/ERP5/Document/BusinessPath.py
	products/ERP5/Document/SimulationMovement.py
	products/ERP5/Document/TradeCondition.py
	products/ERP5/Document/TradeModelLine.py
	products/ERP5/bootstrap/erp5_mysql_innodb_catalog/bt/revision
	products/ERP5Type/ERP5Type.py

git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@37129 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@36902 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@35997 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@35474 20353a03-c40f-0410-a6d1-a30d3c3de9de

the condition changable. This fixes a bug tested on
test_tradeModelLineWithEmptyBaseContributionMovement.
Override the condition in PaymentCondition and make PaymentCondition
appliable to any movements.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@35473 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@35102 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@34653 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@34652 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@34527 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@34410 20353a03-c40f-0410-a6d1-a30d3c3de9de

resolves to XMLMatrix._checkConsistency


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@34406 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@34374 20353a03-c40f-0410-a6d1-a30d3c3de9de

CompositionMixin provides a 'asComposedDocument' method replacing
find{Effective,}SpecialiseValueList on Trade Condition.

Some deprecated code in TradeCondition is moved back to PaySheetModel for
compatibility reasons.

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@34217 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@33977 20353a03-c40f-0410-a6d1-a30d3c3de9de

value.
Test both the fixed quantity case and the other case
which trade model line does not have a fixed quantity but return a
fixed quantity value by using a calculation script.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@33774 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@33713 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@33707 20353a03-c40f-0410-a6d1-a30d3c3de9de

ideally, the context for the script should be the trade model line here, but unfortunately it is the passed context (i.e. a simulation movement).


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@33520 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@33324 20353a03-c40f-0410-a6d1-a30d3c3de9de

This fixes an interesting bug:
  # Takes place during indexing phase, when Transactional Cache is on

  # A transformation is defined, producing a (blue|red) resource from
  # (blue|red) fabric
  transformation = ...

  movement1 = newTempMovement(colour="blue", resource=A)
  movement2 = newTempMovement(colour="red", resource=A)

  amount1 = transformation.getAggregatedAmountList(movement1)[0]
  amount2 = transformation.getAggregatedAmountList(movement2)[0]

  # amount1 and amount2 have wrongly the same Physical path.
  # Which means that due to caching in CategoryTool, the category
  # values will be computed only once instead of twice:
  assert amount1.getVariationText() == "colour/blue" #OK
  assert amount2.getVariationText() == "colour/blue" # !!



git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@33314 20353a03-c40f-0410-a6d1-a30d3c3de9de

support the case where both base_application and base_contribution are empty, that happens for using Trade Model Line as a base class of Payment Condition.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@33311 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@33115 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@31992 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@31099 20353a03-c40f-0410-a6d1-a30d3c3de9de

Add an argument `aggregated_movement_list` to calculation script.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@30914 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@30865 20353a03-c40f-0410-a6d1-a30d3c3de9de

Add target level property which defines how trade model line is applied to movements and this changes getAggregatedAmountList behavior.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@30853 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@30608 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@30021 20353a03-c40f-0410-a6d1-a30d3c3de9de

Until now, when using, for example, VAT, you put like this:

price=0.196, efficiency=1.0

so the result by getAggregatedAmountList is, if the base is 100:

price=0.196, efficiency=1.0, quantity=100

Thus, the total price is 19.6.

This works but not compatible with rounding, as, for instance, if we want to 
round it up to 20, the result is not saved at anywhere.

So, from now on, we do like this instead:

price=1.0, efficiency=0.196

so the result is:

price=1.0, efficiency=0.196, quantity=100, total price=19.6

The total price does not change. When we apply a rounding method, it would 
result in:

price=1.0, efficiency=0.196, quantity=100, total price=20

--

This modification is approved by YO and Yusei.

TODO: write some test-cases



git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@30019 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@29133 20353a03-c40f-0410-a6d1-a30d3c3de9de

 - there is no need to use use category of resource to recognise if movements are put by user or by system, empty base_application suggest that movement is set by user


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@28794 20353a03-c40f-0410-a6d1-a30d3c3de9de

- self is not the same than context, use context parameter instead
- get closest model from the paysheet
- condition for slice was wrong. if the slice is equal to the base_application, quantity is 0


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@28123 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@28045 20353a03-c40f-0410-a6d1-a30d3c3de9de