> > 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) > > 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. 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. 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. 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 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). 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). 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.' ? Cheers/Axel
