An error occurred fetching the project authors.
  1. 02 Sep, 2020 1 commit
    • Arnaud Fontaine's avatar
      ZODB Components: erp5_trade: Migrate TestOrder{Mixin} and all Unit Tests... · 8e9bd755
      Arnaud Fontaine authored
      ZODB Components: erp5_trade: Migrate TestOrder{Mixin} and all Unit Tests inheriting from these classes.
      
      Also, Split testInvoice to a Module Component in erp5_invoicing for Mixins used
      by several other tests and Test Component in erp5_simplified_invoicing (initially
      everything was migrated to erp5_invoicing but this does not work as Alarm_buildInvoice
      is different in simplified and advanced invoicing).
      8e9bd755
  2. 05 Jun, 2020 1 commit
  3. 23 May, 2019 1 commit
  4. 31 Oct, 2018 1 commit
    • Tristan Cavelier's avatar
      erp5_{accounting,trade}: fix inconsistent "Sale Trade Condition" column · f5a70122
      Tristan Cavelier authored
      in accounting_module and sale_order_module listbox.
      
      The "Sale Trade Condition" column was showing first found specialise title
      instead of the Sale Trade Condition one.
      
      This adds z_related_specialise_trade_condition with related key specialise_trade_condition_title
      and an accessor getSpecialiseTradeConditionTitle
      f5a70122
  5. 14 Jun, 2018 1 commit
  6. 26 Oct, 2017 1 commit
  7. 23 Dec, 2016 1 commit
  8. 28 Jan, 2016 1 commit
  9. 27 Nov, 2015 1 commit
  10. 02 Jul, 2015 1 commit
    • Sebastien Robin's avatar
      invoicing: invoice transaction builders should find corresponding deliveries... · ebcef705
      Sebastien Robin authored
      invoicing: invoice transaction builders should find corresponding deliveries only through explanations
      
      What happened before :
      - user confirm sale invoice
      - activity for building vat invoice lines is created
      - user change destination_section
      - since builder was expecting having same destination_section on delivery
      and simulation movements, it was failing
      
      Now, the builder does not look at source/destination or other categories, it only looks
      for common explanation. This can be done this way only because transaction lines should
      go inside the same delivery as invoice lines with standard invoicing.
      ebcef705
  11. 10 Mar, 2015 1 commit
  12. 10 Feb, 2015 1 commit
  13. 16 Oct, 2014 1 commit
  14. 04 Sep, 2014 1 commit
  15. 30 Jan, 2014 1 commit
  16. 16 Aug, 2013 1 commit
  17. 09 Apr, 2013 1 commit
  18. 15 Oct, 2012 1 commit
  19. 03 Oct, 2012 1 commit
    • Julien Muchembled's avatar
      Simulation: splitted expand, performance improvements and bugfixes · 5c09e2e2
      Julien Muchembled authored
      All interactions and activity tags are reviewed to fix bugs like duplicated
      root applied rules, and also reduces the amount of duplicated/useless work, e.g:
      - Simulation trees are not expanded anymore when simulated objects are modified.
      - 'expand' activities are merged (i.e. dropped) with any other 'expand' activity
        for an ancestor.
      New implementation exposes new API that hides much complexity to the developper
      about activity dependencies.
      
      By default, expand() now automatically defers any work if the current
      transaction takes too long time. This method also gains a parameter to
      explicitely choose when to expand, which is often important in unit tests or
      solvers. In particular, when postponing work, it takes care of setting proper
      activity dependencies.
      - If you have any code requiring to expand everything immediately, you'll have
        to replace 'expand()' by 'expand(expand_policy="immediate")'.
      - On the contrary, you should replace any 'activate().expand()' by
        'expand(expand_policy="deferred")'.
      expand() still accepts activity parameters for any extra needs.
      
      In causality workflow, 'building' state is clarified and now means
      « delivery may diverge but we can't know now ». A delivery remains in draft
      as long as it does not contain any movement built from simulation.
      After init/clone/builder/etc. scripts used to call 'startBuilding' &
      'updateCausalityState': this calls must be removed since only
      SimulatedDeliveryBuilder should take care of move to 'building' state and
      workflows now triggers 'updateCausalityState'.
      
      Disguised interactions have been unhardcoded and either deleted, or moved to
      appropriate interaction workflows, which have been reorganized. Those
      that triggers update of portal_workflow can be easily customized or disabled.
      
      New API:
      - updateSimulation() on deliveries and subscription items. It takes care of
        creating root applied rule, expanding and reindexing parts of simulation
        trees. It somehow replaces:
        - Delivery_updateSimulation
        - Delivery_updateAppliedRule
        - Delivery.applyToDeliveryRelatedMovement
        - Delivery.updateAppliedRule
        - Delivery.expand
        - Delivery.expandRuleRelatedToMovement
        - SubscriptionItem.expand
        - SubscriptionItem.updateAppliedRule
      - Delivery.localBuild() is the new way to do local building and replaces
        Delivery_expandAndBuild. Private method Delivery._localBuild replaces
        Delivery_buildOnComposedDocument.
      - Simulation Movements that are being built by a builder are reindexed with
        the following tag: 'built:<delivery_path>'. Any after_path_and_method_id
        dependency against 'related_simulation_movement_path_list' and reindexing
        methods should be replaced by this after_tag.
      
      After builder scripts used to confirm the delivery in a separate activity,
      which was useless.
      5c09e2e2
  20. 18 May, 2012 1 commit
  21. 15 May, 2012 1 commit
  22. 11 May, 2012 1 commit
  23. 29 Mar, 2012 1 commit
    • Rafael Monnerat's avatar
      Move solvers, rules and code from erp5_simulation_test to erp5_configurator_standard_*_template · 399caf39
      Rafael Monnerat authored
       - Solvers were moved to erp5_configurator_standard_solver
       - trade related code and rules to  erp5_configurator_standard_trade_template
       - accounting related code and rules to  erp5_configurator_standard_accounting_template
       - invoicing related code and rules to  erp5_configurator_standard_invoicing_template
      
      Code were moved and splited to several diferent business templates. The rules
      and related code should be used only as template.
      399caf39
  24. 05 Jan, 2012 3 commits
  25. 16 Jun, 2011 1 commit
  26. 06 Apr, 2011 1 commit
  27. 05 Jan, 2011 1 commit
  28. 07 Nov, 2010 2 commits
  29. 05 Nov, 2010 1 commit
  30. 02 Nov, 2010 1 commit
  31. 17 Sep, 2010 1 commit
  32. 16 Sep, 2010 2 commits
  33. 07 Sep, 2010 1 commit
  34. 03 Sep, 2010 1 commit
  35. 01 Sep, 2010 2 commits