Skip to content

erp5
erp5
An error occurred fetching the project authors.
Switch branch/tag
  1. 21 Sep, 2018 1 commit
  3. 22 Feb, 2018 1 commit
  5. 03 Jan, 2018 1 commit
    • Sebastien Robin's avatar
      stock optimisation: fixed error when stock optimisation was used with inventories · 3a597c96
      Sebastien Robin authored 
      generateMovementListForStockOptimisation was raising error when there was inventories.
The method was assuming that doing getObject() on an inventory line (from
getFutureInventoryList) was always returning a movement. But sometimes we get
the inventory itself. So do not use getVariationCategoryList, but use the variation_text
stored in the stock table.
      3a597c96
  7. 10 Aug, 2016 1 commit
  9. 12 Jan, 2016 2 commits
  11. 02 Oct, 2015 1 commit
    • Sebastien Robin's avatar
      simulation: remove concept of mirror movement (continue) · e8524a08
      Sebastien Robin authored 
      Remove broken concept of Mapping Properties that was used on legacy
simulation. We do not want to use this concept any more, any mapping
should be done by rule themself. Removing mapping properties leads
to more generic concepts and much simpler code.

With legacy simulation, in case of returned sale packing list
(in case we want to invoice in same sale invoice usual sale packing
list and returned sale packing list) :
AR (delivering_rule):
  -> SM (source/A, destination/B)
    -> AR (invoicing_rule, having mapped_property mapping
           source to destination and vice versa)
      -> SM (source/A, destination/B) builders and solvers
         where doing sm.getMappedProperty('source') which was equivalent
         to sm.getProperty('destination'), thus the mapping was done
         in live time

Now in such case, we should implement mapping directly at rule level,
and this should give:
AR (delivering_rule):
  -> SM (source/A, destination/B)
    -> AR (invoicing_rule, reversing source and destination)
      -> SM (source/B, destination/A) here we directly have properties
         we wish, no need of hacks on builders and solvers
      e8524a08
  13. 22 Sep, 2015 1 commit
  15. 01 Jul, 2015 1 commit
  17. 30 Jun, 2015 1 commit
    • Sebastien Robin's avatar
      simulation: review generated delivery builder (update existing deliveries, date precision) · 15f08b29
      Sebastien Robin authored 
      Up to know, order builders were mostly used having in mind the idea of
deleting all previously created automated orders.

This way was mostly requesting to run generated delivery builder only
once per night, assuming there is no users working at that time.

So to allows running very often (many times a day) generated delivery
builders, allow them to update existing deliveries. This way :
- automated deliveries could be much more up to date
- there is no need to delete everything
- this generate few activities, there is no need of a long calculation
  to update everything

Also, the stock optimization was using dates with a precision of one
full day. Generic code must support much better precision.
      15f08b29
  19. 10 Mar, 2015 1 commit
  21. 05 Mar, 2015 1 commit
  23. 17 Feb, 2015 2 commits
  25. 16 Oct, 2014 1 commit
  27. 08 Aug, 2014 1 commit
  29. 21 Feb, 2013 1 commit
  31. 29 Jan, 2013 1 commit
    • Leonardo Rochael Almeida's avatar
      When building, edit changes in the right order · e1a07bc5
      Leonardo Rochael Almeida authored 
      The builder was taking a carefully ordered list of movement group nodes and
their suggested changes, and squashing the changes all together in a single
dictionary for .edit(**kw).

Now we calculate the edit_order to take the movement_group order into account.
      e1a07bc5
  33. 19 Oct, 2012 1 commit
  35. 14 May, 2012 1 commit
  37. 11 May, 2012 1 commit
    • Julien Muchembled's avatar
      Cleanup API of TransactionalVariable and read-only cache · d70587e3
      Julien Muchembled authored 
      - New readOnlyTransactionCache context manager replacing
  enableReadOnlyTransactionCache and disableReadOnlyTransactionCache
- Drop compatibility code that tolerate a dummy context to be passed to
  getReadOnlyTransactionCache and getTransactionalVariable.
      d70587e3
  39. 23 Apr, 2012 2 commits
  41. 21 Apr, 2011 1 commit
  43. 14 Mar, 2011 1 commit
  45. 18 Aug, 2010 1 commit
  47. 05 Aug, 2010 3 commits
  49. 04 Aug, 2010 3 commits
  51. 23 Mar, 2010 1 commit
  53. 10 Mar, 2010 1 commit
  55. 03 Mar, 2010 2 commits
  57. 01 Mar, 2010 1 commit
  59. 18 Feb, 2010 1 commit
  61. 09 Nov, 2009 1 commit
  63. 11 Sep, 2009 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7