销售订单中的可用性检查Availability Check in the Sales Order
在物料主数据的销售和分销TAB页你能够：在general/plant页的可用性检查字段中输入，应该在订单处理过程中为该物料执行哪个和/或什么类型的可用性检查；
在配置中还有许多的表，可用性检查也依赖于这些表；
销售订单处理中发生可用性检查的条件：
物料需要库存检查；
在配置中为该事务设置了可用性检查；
物料可用日期检查Material Availability Date Check
物料可用日期从交货排程确定；足够的物料需要在该日期可用以在客户要求的交货日期及时地交货给客户；
系统计算该日期，从客户要求的交货日期向后扑悖?/span>
系统计算捡配，包装，装载和运输货物的时间；
可用性在物料可用日期检查；
工厂检查Plant Check
系统按照下列顺序访问信息以建议标准的交货工厂：
1. 客户-物料信息记录；
2. Ship-to Party客户主记录；
3. 物料主记录；
如果你在订单输入时手工输入交货工厂，你的输入会覆盖默认值；
在客户-物料信息记录中，你可以为一个客户的某一特定物料维护建议的值；
你可以在物料主数据的销售和分销tab页：Sales Org.1的delivering plant字段找到交货工厂；
你可以在客户主数据的shipping tab页找到交货工厂；
可用性检查控制Control of Availability Check
在配置中，依照你正在使用的事务，你可以设定哪些元素包括在一个可用性检查中；这样，你定义哪种类型的库存（例如，安全库存，转移中的库存或者质量检查中的库存），哪种向内的移动（例如，采购或者生产订单）以及哪种向外的移动（例如，销售订单，来自MM的预留）应该包括在检查中；
需求传递Transfer of Requirements
销售和分销与采购之间的交流通过需求来实现；
需求传递的类型能够影响可用性检查；
负责物料计划的员工收到有关系统中的销售订单以及SD需要来交付这些订单的数量的信息；
订单的物料可以来自内部生产或者外部采购；
如果可用的物料不足，可通过物料计划（Material planning）来创建采购订单；
完全和部分交货Complete and Partial Deliveries
你和客户关于交货达成的协议也会影响可用性检查的结果；
依赖于客户销售订单中的部分/完全交货的协议，你可以交付一张订单用一个完整的交货或者几个部分交货；
在一个完全交货中，所有条目的订购数量都被交付了；
对于部分交货你可以将一张订单的条目或者数量分配到几个交货中；
部分交货协议Partial Delivery Agreement
控制完全/部分交货的指示符从客户主记录中带出；条目层的建议来自客户-物料信息记录，如果那里已经维护了客户和物料的协议的话；这些指示符可以在销售订单输入过程中手工修改；
客户可能要求，例如，一个完全交货意味着销售订单中的所有条目应该一起被交付；如果客户同意一个部分交货，该订单可以对应几个交货；
如果你选择“完全交货”，你能够确定整张订单中的所有条目必须一起交货；在条目层次，你也可以决定你是否可以分割交货数量；
存在以下部分交货协议：
_允许部分交货；
A输入一个数量不等于0的交货；
B仅创建一个交货（也含数量=0）；
C只能执行完全交货；
D首选并发交货；
案例1：确认要求的交货日期Case1：Confirmation on Required Delivery Date
系统使用交货排程来检查货物是否在物料可用日期可用；
可用性检查包括：
当前库存；
计划的向内移动（例如采购订单，采购请求，计划订单）；
计划的向外移动（例如存在的销售订单，交货）；
在案例1，关于向内移动的情况如下：存在的向内移动有：
库存：100pc；
存在的采购订单有数量50pc和60pc；
下列未来的向外移动也存在：
存在销售订单有数量100pc，40pc，50pc；
在该向外情况中你输入另外一张10pc的销售订单；系统基于客户要求的交货日期执行交货排程（后向排程）并确定物料可用日期；然后为该日期运行可用性检查；
案例1的结果：确认要求的交货日期Result for Case 1：Confirmation Required Delivery date
可用性检查显示系统可以为要求的交货日期确认这10pc；
案例2：确认一个稍后的日期Case 2：Confirmation for a Later Date
案例2的最初情况和案例1相同；
然而在本案例中，客户要求完全交货；
在向外的情况你输入另外一张20pc的销售订单；系统基于客户要求的交货日期执行计划排程（后向排程）并且确定物料可用日期；然后为该日期运行可用性检查；
案例2的结果：确认一个稍后的日期Result for Case2：Confirmation for a Later Date
在库存不足的事件中，系统使用可用性检查和交货排程来确定下一个可用日期，在该日期可以为客户确认货物；
因为有一个完全交货协议，数量不可以分割；
你需要为稍后的日期确认这20pc；
系统使用基于物料可用日期（前向排程）的交货排程来计算20pc的确认日期；
案例3：部分交货Case 3：Partial Deliveries
如果客户和销售凭证类型允许，要求的销售订单数量也能够被分割到几个部分交货；
案例3的情况与1和2相同：
在案例3，客户要求尽快交货并且允许你必要的话分割交货数量到部分交货中；
案例3的结果：部分交货Result for Case 3：Partial Deliveries
当没有足够的库存，系统使用可用情况和交货排程来确定下一可用日期，在该日期能够确认客户的货物；
“允许部分交货”协议意味着数量能够被分割；
你能够为2个稍后的日期确认这20pc，每个日期10pc；
系统使用物料可用日期和交货排程来计算2个部分交货，每个10pc；
案例4：带补货提前期的检查Case 4：Check With Replenishment Lead Time
你可以考虑所有的向内和向外的移动；推荐的是，你只在补货提前期的末尾执行一个可用性检查；
补货提前期可以为每个物料指定；例如，贸易商品：计划交货时间+收货处理时间；最终产品：内部生产时间；
系统假定物料最晚将会在补货提前期的末尾可用；
可用性检查仅在补货提前期的末尾运行；
如果你在案例4中执行不带补货提前期的可用性检查，结果和案例2一样；客户要求一个完全交货；你不能使20pc可用直到最后那张60pc的采购订单到达（向内移动）的同一天；
然而，如果系统使用补货提前期执行可用性检查，你可以使20pc在50pc的采购订单到达的日期可用；只有在补货提前期内的向内和向外移动才包含在该检查中；
拖欠订单处理Backorder Processing
满足下列条件的订单条目是拖欠订单：
一个订单条目的数量没有完全确认；
订单条目的要求的交货日期不能遵守；
有两种类型的拖欠订单处理：
手工拖欠订单处理：
你可以使用拖欠订单处理来为物料列出销售凭证并且参考确认手动地处理；这意味着ATP数量能够被重新分配并且任何不足会被清除；
通过重新排程
你能够在自动重新排程中使用交货优先级（为销售订单从客户主记录中带出）作为一个排序标准；
控制可用性检查和需求传递Controlling Availability Check and Transfer of Requirements
在需求传递和可用性检查中，系统区分定购时间和交货时间；
对两个时间点，物料的可用性检查组决定是独立的还是全部的记录作为需求传递到MRP，如果需求传递执行的话；对特殊库存的需求记录基本上都是独立需求；
系统为两个时间点确定在可用性检查中货物的哪些向外和向内移动会被考虑；包含特殊库存（寄售，可返回包装，按订单库存）的事务被单独立控制；存在哪些特殊库存通过条目类别确定；在按订单生产的案例中，需求类的科目分配类别E确定实际上包含按订单库存；
你使用需求类来为SD（orders，deliveries）全局地确定是否将为物料传递需求以及是否将会执行一个可用性检查；两个功能都可以通过计划行类别为相应的事务设置为非激活；交货专门由需求类控制；
例子：计划的独立需求-在订单中按订单生产Example：Planned independent Requirements- Make-to Order in the Order
分配给物料类型的策略组将计划作为主要策略；如果销售订单中没有协议别的东西，需求根据该策略传递；计划策略确保物料需求是预先计划的（计划的独立需求类别VSF）；后续的计划的独立需求（KSV）针对计划消耗这些预先计划；
如果为需求类激活了可用性检查，可用数量计算来自库存，计划的收货，向内移动的货物和向外移动的货物；可用性检查规则控制在可用性检查中什么被评价为货物的向内移动和向外移动；
如果在销售的事务处理中设置了计划分配；并且如果可用性检查通过需求类设置为非激活的，则可用性检查针对生产计划执行；如果物料的计划的独立需求不能覆盖订单数量，则计划分配（planning assignment）控制销售订单中屏幕的显示；该屏幕与可用性控制屏幕相同并且相同的规则对采用检查的结果有效（one-time delivery，delivery proposal，full delivery）；
除了计划主策略，策略组还允许你为物料执行按订单生产；为此，你必须到订单的procurement预览屏幕并在相应的条目中替换默认的需求类型KSV为策略（KE）允许的需求类型；
例子：计划的独立需求-按订单生产/报价单Example：Planned indep.Requirements –Make-to Order/Quotation
相应的流程通过计划行类别影响需求传递和可用性检查；这意味着，例如，通过计划行类别来使需求传递和可用性检查无效；
没有评论:
发表评论