2015-03-11 19:03 GMT+01:00 Mathias Behrle <mbeh...@m9s.biz>: > > Hi all, > > I just wanted to get feedback on how to setup the following scenario in the > best way. This scenario is a quite common pattern used by a number of > companies > in the retail sector and could serve probably as a general pattern also for > others. > > The company is sharing (pooling) its storing capacity over > > - the main warehouse > - several stores nearby in the city > - additionally a webshop shall be driven with the base of available products > computed from the products available in the different warehouses. So the > webshop basically is just handled as another store, but without stock (at > least in terms of storage). There shall be a precedence on how the goods for > the sales of the webshop shall be picked from the different warehouses. > > Purchases shall only be made from the main warehouse, which serves generally > as > the central communication point to the suppliers (incoming shipments, returns, > etc.). Deliveries to stores and pickings from stores back to the shipping > department are usually made twice a day. > > > To represent the above scenario I am currently using the following layout: > > - The main warehouse as well as the stores are defined as locations of type > warehouse. > > - The supply chain from the main warehouse to the stores is defined by order > points of type internal shipment. > > - The supply chain of the main warehouse is defined by oder points of > type purchase request. > > - The supply chain of the webshop is: just pick the available products from > their respective locations (with a defined precedence). > > > This basic setup works out of the box except for: > > - Internal shipments currently are created additively, not being replaced > with the complete numbers of the actual state (like purchase requests). > I don't know if this behavior is necessary by design/use case or if it could > generally be changed to behave in the same way as purchase requests. >
I think it would make sense to use the same behaviour as purchase requests or production requests: removing existing shipments and creating new ones. Currently tryton cannot distinguish between internal shipments created manually from those created automatically so that would be needed to remove automatically created ones only. One possibility would be to add the state "Request" to internal shipments, just like how productions work. > - The current handling of internal shipments is not convenient to handle > requests, where often only a part of the requested quantity can directly be > assigned (e.g. existing stock on the main warehouse), but the remaining > quantity has to be assigned later (e.g. when available from the main > warehouse in future, after purchase). > We will have to find a way, how to automatically assign available stock > while > waiting for stock to be purchased. At least having to go back to Draft to be > able to delete non assignable products is more than unconvenient and > probably > bothers other users, too. Perhaps we could extend the force assign wizard to > ask to split out non assignable products into a new shipment? That sounds reasonable to me. > - The webshop will need a special provision to create internal shipments > according to the available stock in the different warehouses. > > > Does this basic setup look ok for you? It does for me. > > Thanks for your input, > > Mathias > > -- > > Mathias Behrle > MBSolutions > Gilgenmatten 10 A > D-79114 Freiburg > > Tel: +49(761)471023 > Fax: +49(761)4770816 > http://www.m9s.biz > UStIdNr: DE 142009020 > PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 -- Albert Cervera i Areny Tel. 93 553 18 03 @albertnan www.NaN-tic.com
