Am Dienstag, 22. Oktober 2013, 15:42:44 schrieb Cédric Krier: > 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.
Not at all! At least not functionally. availability check: performs a check whether an order (sales-, production- , shipment order) can be fulfilled . Usually based on rules what elements (e.g. stock, blocked stock, incoming deliveries) should be taken into account. backorder scheduling: new scheduling of orders, based on new supply/demand information, e.g after a delayed PO was received. Usually updates the dates in a (sales) order > > > > 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. Not for a tock sale, I agree, but that was not the focus of my question. > > 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. The one thing has nothing to do with the other thing. Order confirmation based on availability check is one thing, lot sizing (of purchases) and clustering of demand is another thing. The last thing is considered as material requirements planning, and raising a PO out of a planning run is only one option. > > 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. ..but that does not help if a product has in general a longer lead time than we require. > 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). This assumes that we have more than one supplier and that lead times are significantly different. 'Nothing happens' is clearly a bad option, because that would leave the demand from sales uncovered. Better: Let the system propose a late order with a supplier, and adjust the confirmed delivery dates in the sales order. This is at least how it is made in most indurstries. > > 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. If I have a sales order, I'm already beyond the point of a quotation. If I do not update the sales order, where shall I keep the information that the requested delivery date can not be kept? in the mind of the sales clerk or on a yellow post-it on the monitor? No, in the sales order! > > 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. computing time in a background job? not really. IMHO it is required, otherwise you lose track of your sales situation. > > 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. Actually, I did, and its still unclear how it works, as the documentation is more focussed on developers than on users. > PS: Could you follow the netiquette and not write lines longer than 72 > to 78 characters. It is really painful to read such email. If you have to work from a webmailer, you are not always master of the setting.....and to be honest, the new mail frontend from GMX is a PITA. I'm already happy that I could configure it for inline quoting. BTW, my mailer (KMail) automatically breaks the lines to window-width. Does mutt not do so? Cheers/Axel
signature.asc
Description: This is a digitally signed message part.
