* ERP5Type.PropertySheet becomes a dynamic module that returns strings
  instead of classes for compatibility:
  - the document classes can now use strings in property_sheets attribute
  - if a document uses a string instead of a class reference to point to a
    property sheet, it means that the property sheet can either be an old
    (filesytem, local, in a product) property sheet, or a zodb propertysheet

  For now, the contents of ERP5Type.PropertySheet (strings) are overwritten
  if a local PropertySheet is loaded from the disk. But with time, as
  property sheets will migrate to ZODB, the module will empty itself and
  contain only strings.

* Move all property sheets from all products to ERP5PropertySheetLegacy
  product. Only property sheets that were left 'as is' are CMF* property
  sheets.

This commit is mostly a move to another Product, and should have small
consequences on tests/existing instances.

However, if you used to import PropertySheets in custom/project code
in your custom Property Sheets, you will need to rename:
   from Products.*.PropertySheet.Foo import Foo
to:
   from Products.ERP5PropertySheetLegacy.Foo import Foo



git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@41639 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

git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@34653 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@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@28686 20353a03-c40f-0410-a6d1-a30d3c3de9de

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

move default_calculation_script_id property from PaySheetModel to TradeCondition. Rename it as calculation_script_id to be consistent with TradeModelLine.
Now PaySheetModelLine propertysheet became useless, so remove it


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

add a new property create_line used to indicate if we want to create movement corresponding to this model line or not.
This is usefull in case of "intermediate lines" : a line we want to participe on some base_amount without being created.


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

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

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

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

 - NodeBudgetVariation that explicitly lists the possible values one by one,
   either by selecting them of specifying a script to return this list of
   values
 - CategoryBudgetVariation that uses a base category
for each one, you specify what will be the "axis" used for getInventory (node,
mirror_node, node_category etc)

"SectionCategoryBudgetVariation" is therefore useless, it's a
CategoryBudgetVariation where the axis is "section_category"

Budget Cell, Budget Line and now Budget itself can be variated
 


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

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

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

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

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