An error occurred fetching the project authors.
- 06 Apr, 2020 1 commit
-
-
Rafael Monnerat authored
Introduce temp_object parameter on builder.build() and propagate it over until the newContent() calls. This change allow use create Temporary Documents intestead real ones, like a "preview". (cherry picked from commit 959776ce50c2e7ee2b8f9945ec91a2e0fbe08619) Conflicts: product/ERP5/Document/SimulatedDeliveryBuilder.py
-
- 14 Jan, 2020 1 commit
-
-
Arnaud Fontaine authored
ZODB Components: Preparation of erp5_base migration from FS: Fix pylint no-name-in-module on newTempXXX (04b49859).
-
- 25 Dec, 2019 2 commits
-
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
ZODB Components: Followup of 47b14fd4 making sure that there is only one Delivery to update (as it was before that commit).
-
- 19 Dec, 2019 2 commits
-
-
Arnaud Fontaine authored
ZODB Components: Preparation of erp5_base migration from FS: Fix pylint unbalanced-tuple-unpacking warning.
-
Arnaud Fontaine authored
ZODB Components: Preparation of erp5_base migration from FS: Fix pylint unused-import and unused-variable warnings.
-
- 27 Jun, 2019 1 commit
-
-
Sebastien Robin authored
When we ignore variations, we should also ignore them when looking to update existing orders
-
- 26 Jun, 2019 1 commit
-
-
Sebastien Robin authored
-
- 19 Apr, 2019 1 commit
-
-
Sebastien Robin authored
Fully rewrite portal_simulation.mergeDeliveryList to use builders to reconstruct new merged delivery. Add parameter "merge_delivery" to builder. This parameter is used when merge should be done in such a way that movement group at delivery level are ignored
-
- 21 Sep, 2018 1 commit
-
-
Sebastien Robin authored
-
- 22 Feb, 2018 1 commit
-
-
Julien Muchembled authored
Reindexing a delivery is always recursive so in scenario where lines are added by many different builders and the values in property_dict are always the same, the useless reindexing was slower and slower. In the worst case, each builder adding 1 line, the number of reindexing activities increased quadratically. See also commit c020b93b.
-
- 03 Jan, 2018 1 commit
-
-
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.
-
- 10 Aug, 2016 1 commit
-
-
Sebastien Robin authored
This is very helpful when a warehouse is splitted into multiple stock points. Also avoid returning no stock optimisations if no date could be found in future.
-
- 12 Jan, 2016 2 commits
-
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
- 02 Oct, 2015 1 commit
-
-
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
-
- 22 Sep, 2015 1 commit
-
-
Vincent Pelletier authored
Avoids giving catalog parameters it cannot handle and would complain about. Reviewed-By: Julien Muchembled <jm@nexedi.com>
-
- 01 Jul, 2015 1 commit
-
-
Sebastien Robin authored
-
- 30 Jun, 2015 1 commit
-
-
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.
-
- 10 Mar, 2015 1 commit
-
-
Sebastien Robin authored
before, the code was going through an error when no date was found for doing stock optimisation. But we do date is found, this only means that the stock is not going below the expected value, so we do not need to do any optimisation
-
- 05 Mar, 2015 1 commit
-
-
Sebastien Robin authored
-
- 17 Feb, 2015 2 commits
-
-
Sebastien Robin authored
So all newSimulation expected failures are removed. Make generateMovementListForStockOptimisation looking min_flow and max_delay on supply lines. Introduce a getNextAlertInventoryDate in addition to getNextNegativeInventoryDate. This allows to know when an inventory will be below a reference quantity. This is particularly helpful to know when an inventory is below the minimal admitted stock
-
Sebastien Robin authored
So it's no longer a newSimulation expected failure. Review method generateMovementListForStockOptimisation of builders to nicely generated temporary movements depending on future negative stocks.
-
- 16 Oct, 2014 1 commit
-
-
Julien Muchembled authored
-
- 08 Aug, 2014 1 commit
-
-
Jérome Perrin authored
reapply commit 1761194e that got lost in the renaming
-
- 21 Feb, 2013 1 commit
-
-
Jérome Perrin authored
-
- 29 Jan, 2013 1 commit
-
-
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.
-
- 19 Oct, 2012 1 commit
-
-
Aurel authored
-
- 14 May, 2012 1 commit
-
-
Julien Muchembled authored
Select methods do not need to check if catalog data is up-to-date: this is always done automatically by searchMovementList()
-
- 11 May, 2012 1 commit
-
-
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.
-
- 23 Apr, 2012 2 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
-
- 21 Apr, 2011 1 commit
-
-
Jérome Perrin authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@45601 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 14 Mar, 2011 1 commit
-
-
Jérome Perrin authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@44227 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 18 Aug, 2010 1 commit
-
-
Julien Muchembled authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@37883 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 05 Aug, 2010 3 commits
-
-
Jean-Paul Smets authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@37568 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
Jean-Paul Smets authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@37565 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
Jean-Paul Smets authored
Quickly moved core to mixin, added what is needed for new BPM (taken from BPMBuilder.py now in Legacy) and tried to have single code base) git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@37547 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 04 Aug, 2010 2 commits
-
-
Jean-Paul Smets authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@37490 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
Jean-Paul Smets authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@37488 20353a03-c40f-0410-a6d1-a30d3c3de9de
-