What is the difference between local and global Sourcing Rules, in Global Order Promising?

إجابة واحدة

1. الإجابة ١ — AbdAllah · CA627A

   A sourcing rule answers one question for an item: where should demand for it be met from? Each rule lists ranked sources — make it in an organization, buy it from a supplier, or transfer it from another organization — with optional percentage splits across them, and each rule is effective-dated, so the sourcing pattern can change over time without losing what it used to be. The difference between the two kinds is the destination, not the content. A global sourcing rule names no receiving organization. It says: wherever this rule applies, source the item this way. It is the right shape for the pattern that is true across the enterprise by default. A local sourcing rule is defined for one specific receiving organization. It says: when this organization needs the item, source it this way. It is the right shape where one site genuinely differs from the default. Neither kind does anything on its own, and this is the part worth internalising. An assignment set is what puts rules into effect. It binds rules at levels of increasing specificity — the whole enterprise, a category, an item, an organization, an item within an organization — and when more than one assignment could apply to the same demand, the more specific assignment wins. When sourcing does not behave the way you expected, that resolution is almost always what you are actually debugging, rather than the rule type. In Global Order Promising this matters because the promising engine works from the assignment set in force to decide which sources are even candidates for a line, before it considers lead times and availability. Two consequences follow: If no assignment covers the item and the receiving organization, the line has no source at all. You see that as a line refused or left unsourced at entry — not as a line promised for a later date. And promising has to be looking at the same assignment set you edited. Before suspecting the rules themselves, confirm which set is in force for the promising process in that environment. Practical shape: start with a global rule for the default pattern, add local rules only for the organizations that genuinely source differently, and keep the number of assignment levels you use small. Every extra level is one more place where "which rule won?" has to be worked out by hand, usually by whoever inherits it. Page names and parameters differ between releases, so take the above as the behaviour and check the labels in your own environment.