On 22/10/13 14:33 +0200, Axel Braun wrote: > > > I asked: I have already POs with my supplier and incoming goods at a > > > later > > > time than I request (late supplier move)? > > > > > > you wrote:You are just not thinking with the time dimension in mind. > > > There is > > > not just 1 purchase involved. > > > > > > This exactly what I asked. I can not know if my goods are late unless I > > > have > > > received some kind of confirmation back from supplier. > > > > Or he is late. Such information comes with simply the time going, that's > > what I call "thinking with the time dimension". > > Yes, but at that point in time I have already ordered. > So it is not really a purchase request calculation anymore, but more an > availability check resp. backorder scheduling (see below)
It is the same. > > > But maybe we have a misunderstanding in wording: A purchase request is a > > > request to purchase goods. It may be linked to some authorisation and > > > approval > > > workflows. > > > > Yes. > > > > > In case a purchase request is confirmed, it is linked to a vendor > > > (sourcing) > > > and transformed into a purchase order. Now this PO can have a later > > > delivery > > > date than what I requested, which affects my ability to deliver in time > > > to the > > > customer -> I need to reschedule my sale to the customer. > > > > This is not managed by Tryton. It is impossible to do because there is > > no link between a purchase and a sale. > > A 'hard' link between sales order and PO would be required for a > purchase-to-order process. I understand from your words that this is not > covered. No problem. The module exists sale_supply but it is far from being the common case. > What I think should happen (no idea if that happens in Tryton): > In most cases, when you take a sales order, the system should check for > available stock (or additional incoming/expected goods receipts from open > purchase orders). If it finds stock or an incoming PO, it can confirm the > sale. No it is not. > In case there is no stock or no PO, a purchase request should be raised, > followed by a PO, to get the goods in at a point in time that is early enough > to fulfil the customers requested delivery date. No it is not. Both ways of working are very bad for productivity and cost management. Tryton works on a global scale where it takes into account all the sales, purchases etc. when computing the stock supply. This way allow to group purchases. > Now two things can happen: The lead time of the product is too long to match > the customers requested delivery date, or the PO gets delayed after ordering. The system must be configured to have a correct delivery time. Any way, if a situation happens where there will be not enough quantity on a specific time, the system will try to fix it by proposing to purchase to a supplier that can deliver on time. If none is found then nothing happens (it could be good to have an report about this). > The first case would require to update the sales order with a new delivery > date to the customer. This is not really a suprise, as we know it when we > order (PO). I don't see why updating the sale order is a good things. It is already too late as you already sent the quotation to the customer. > In the second case, we would need to enter the delay information somehow in > the system, maybe by changing the expected Goods-receipt date. If now a new > availability check in the sales order is carried out, it should pick up the > changed goods receipt date and reschedule the delivery date in the sales > order accordingly. This is sometimes referred as backorder-scheduling, and > should work in the first case as well (it can confirm the sale according to > the expected GR date). Doing all that stuffs to validate a sale order will cost really too much. > Coming back to my earlier question....what part of this process is now > covered by > 'If there are late supplier moves when creating purchase requests, the wizard > shows a warning to allow the user to change the date of those moves into the > future if needed otherwise those incoming moves will be ignored.' > ? None. I propose that you test Tryton to understand how it works. PS: Could you follow the netiquette and not write lines longer than 72 to 78 characters. It is really painful to read such email. -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: [email protected] Website: http://www.b2ck.com/
pgpAGuy1qtx3E.pgp
Description: PGP signature
