[原创]SD从零开始59 跨公司的库存转移处理流程
库存转移流程Stock Transfer Procedure
2个工厂间的库存转移能够使用不同的流程来执行；
只执行一个库存转移记账的流程使用MM库存管理模块；与此相比，你还有这样流程，即当在MM的采购模块输入一张采购订单时，自动开始库存转移流程（库存转移订单）；如果你使用带SD交货的库存转移流程，有一个优势是装运活动也能够在R/3系统中处理（捡配，包装，打印交货票据等）；
如果你希望为库存转移处理使用R/3的装运功能，使用为公司内部转移的流程“带SD交货的库存转移订单”，以及为跨公司库存转移的流程“带SD交货和Billing的库存转移订单”
跨公司库存转移的流程（两步流程）Process for Cross-Company Stock Transfer（Two-step Procedure）
与公司内部库存转移相比，跨公司库存转移流程中的两个工厂属于不同的公司代码；
这里我们将描述带SD交货和Billing的库存转移流程，该流程用于跨公司的库存转移，如果R/3装运和Billing功能将被使用的话；
在接收工厂（工厂2200），首先创建一张库存转移订单；
一旦该采购订单到期应该装运，就会创建交货；一旦装运活动已经被执行了，在交货工厂（工厂1200）记账发货；然后货物从工厂1200运输到工厂2200；
最后，在销售组织1000，也就是交货公司创建一张内部发票；现在这两个公司代码之间的内部公司间Billing就可以发生了；
因为使用两步流程，一旦货物在接收工厂被接收，货物接收就被记账；
当收到发票，它可以在接收公司的后勤发票校验部门输入；
第一处理步骤：创建库存转移订单1st Process Step：Create a Stock Transport Order
库存转移流程开始于在收货工厂的采购部门输入一张库存转移订单；如果必要的话，可以参考一张采购请求或者一个交货计划；
在标准版本中，你使用订单类型NB（“标准采购订单”）；在配置中你可以定义当输入一个不合适的订单类型（例如，UB）时是否发行一个警告或错误消息；
库存转移订单包含在交货和收货工厂的计划活动中；
依赖于系统设置，可能会在交货工厂执行一个可用性检查运行以检查请求的货物能否及时交货；
库存转移订单的订单类型Order Types for Stock Transport Order
与公司内部库存转移相比，订单类型UB不用于带SD交货和Billing的跨公司库存转移；你用条目类别“空”（“普通”）创建一张标准订单（订单类型NB）；对于公司内库存转移，你使用条目类别U（“库存转移”）；
当你用订单类型NB创建库存转移订单，你指定一个供应商；在供应商主记录中为该供应商分配了一个工厂；该工厂叫做交货工厂；然而，当你用订单类型UB创建一张库存转移订单时，需要你立即输入交货工厂；
订单条目中指定的工厂是收货工厂；
第二处理步骤：创建一个补货2nd Process Step：Create a Replenishment Delivery
和公司内库存转移相同的方式，在销售活动开始时创建一个补货；
补货单独地在各自的装运点在一次交货集中运行中创建；在这里库存转移订单用作选择标准；
Ship-to Party和其他交货参数的确定以和公司内库存转移相同的方式发生：
在配置中分配一个客户号给收货工厂，和公司内库存转移使用相同的设置；
订单类型NB和交货工厂的组合对应一个交货类型；为此目的，使用交货类型NLCC（“Replenishment Cross-company”）；
第三处理步骤：执行捡配和记账发货3rd Process Step：Execute Picking and Post Goods Issue
使用跨公司的库存转移，补货在装运中照常处理；然而，如果你希望同销售订单的交货或公司内库存转移的补货相比采用不同的处理方式，你可以在配置中为该交货类型和条目类别进行定义；
如果必要的话，补货也可以被包装，或者计划到外向装运中；
一旦装运活动结束，就会在SD装运中为该补货Post Goods Issue；
移动类型确定Determination of The Movement Type
当补货的发货被记账时，系统必须知道要使用的移动类型；这是从计划行类别确定的，而计划行类别又是从其他因素确定的；
在配置中，你分配交货类型NLCC给订单类型NB和交货工厂的组合；
在交货类型和物料的条目类别组的帮助下，交货的条目类别确定程序确保条目类别NLC为标准条目（条目类别组为NORM的物料）建立；
在标准版本中，系统为条目类别NLC和带任意MRP类型的物料确定计划行类别NC；如果你有不同的设置，相应地维护计划行类别搜索；
计划行类别NC的标准设置定义了，在两步的流程中，使用移动类型634；
公司内部库存转移的一步和两步流程的移动类型在分配的交货类型以及条目和计划行类别的搜索的帮助下确定；
发货后库存修改（两步流程）Stock Changes after Goods Issue：（Two-step Procedure）
当发货被记账时，库存类型“非限制使用库存”和“交货给客户”在交货工厂的库存预览中改变了，因为货物已经作为一个交货（在这里，补货）离开了工厂；同样，交货公司代码财务会计中的库存帐和物料费用帐也被更新了；物料的评估价格流入交货工厂；
在跨公司库存转移的两步流程中，这时货物还没有在收货工厂记账，从会计的观点，他们尚不属于收货工厂的公司代码；
非限制使用库存和未清订单数量任然没有修改；
在收货工厂的库存预览中，运送中的数量以“Stock in transit CC”（CC：Cross Company）的形式出现；
运送中的跨公司库存的价值也可以显示为按工厂或公司代码的累积值；
第四处理步骤：创建内部发票4th Process Step：Create Internal Invoice
交货公司代码（公司1000）为货物交货到收货工厂的内部公司间Billing发行一张发票；
内部发票由销售组织1000创建；这是负责内部公司间Billing的销售组织并且在配置中分配给交货工厂；相同的设置也适用于跨公司销售活动的内部公司间Billing；
内部发票直接参考补货创建，或者在一次集中运行中创建；在你处理到期的交货清单时，设置标识符“Intercompany billing”；
如果涉及的公司代码之间达成了协议，你能够设置系统以便当内部发票创建时，会自动地触发在公司代码2200的后勤发票校验中的发票接收；
和跨公司销售相似，自动发票接收由Billing的输出控制连同EDI技术发起；这样，EDI输出类别INVOICE被用在MM变量中；
内部发票的元素Elements of Internal Invoice
内部发票的Billing类型的默认值得自订单类型DL，它在配置中作为“不带订单参考的交货的默认订单类型”分配给交货类型NLCC；
付款人得自分配给收货工厂的客户号码；该设置也用于在补货中确定ship-to Party；
内部发票中的公司代码是交货公司代码，也就是交货工厂的公司代码；
内部公司间Billing的销售组织单元在配置中分配给交货工厂；他们应用于公司内部库存转移以及跨公司销售；
跨公司库存转移：配置清单Cross-Company Stock Transfer：Checklist for Customizing
为交货工厂的内部公司间Billing分配一个销售范围；
为收货工厂分配一个客户号码；
为补货分配一个交货类型；
决定一步还是两步的流程；
如果必要的话，确定转移点；
如果必要的话，维护自动发票接收所需的设置；
如果你在销售凭证控制中实施用户定义的对象：
维护交货中的条目类别确定；
维护计划行类别中的移动类型；
维护计划行类别确定；
在分配给供应商的默认订单类型中维护内部公司间Billing的发票类型；
[原创] SD从零开始60 界面（Interface）修改
客户主数据Customer Master
分为一般数据，公司代码数据和销售数据；
销售数据是销售分销和装运的基础；
公司代码数据是财务会计的基础；
一般数据直接分配给集团；因此它对许多公司代码以及不同的销售范围都有效；例如，销售和分销中使用的客户代码和会计中使用的客户代码是同样的；
客户主数据-帐户组Customer Mater-Account Groups
一个帐户组是客户主记录的一个分类；帐户组指定了一下内容：
主记录中的哪些输入是必须的或可选的（字段选择）；
客户帐户编号的号码范围；
编号是用户分配还是系统分配（外部或内部编号分配）；
是否是一次性帐户；
使用何种输出确定程序；
你可以用你自己的帐户组来补充系统预定义的帐户组；
客户主数据-数据组的字段选择Customer Master-Selecting Fields for Data Groups
你可以在客户主记录中找到一般数据以及销售和分销的数据以及公司代码的数据；
你可以使用字段选择来为每个帐户组定义字段是可选的还是必输的，你可以隐藏任何你不需要的字段；
客户主数据-帐户组的字段选择Customer Masters-Selecting Fields for Account Groups
在标准系统中已经为不同的伙伴功能建立了帐户组，例如：
Sold-to party；
Ship-to party；
Payer；
Bill-to party；
为这些帐户组的每个都选择特定的字段；字段选择依赖于需要的伙伴功能的功能；
客户主数据-影响字段选择的其他因素；
除了帐户组以外，创建的事务、修改和显示客户主记录也影响哪些字段被选择；
编辑客户主记录的事务有：
从销售和分销的观点；
从会计的观点；
集中的观点；
在SAP标准系统，例如，你能够使用会计或者集中事务来维护银行详细资料；
字段选择的结合规则Lingking Rules for Field Selection
两个影响因素（帐户组和事务）的字段状态信息成对地组合；组合的规则是具有高优先级的决定各自字段的状态；
优先级（高->低）Hide，Display，Require，Optional
物料-物料类型Material-Material Type
每个物料都定义一个物料类型，它是物料一般数据的一部分；
负责该物料类型的部门决定可以为那种物料类型的物料维护哪些视图的数据；
物料类型的库存管理类型（数量/价值）可以依赖于工厂；
在价格控制中，你定义物料库存是用标准价格还是移动平均价评估；
你能够为每种物料类型定义在物料主记录的会计数据维护中允许使用哪些评估类；评估类，连同其他的因素，在发生与评估相关的事务时（例如，货物移动）确定哪些总账科目会被更新；
物料字段选择：影响因素Material Field Selection：Influencing Factors
Material Type，Transaction，Procurement indicator，Plant，Branch，SAP Component；
对以上的每个影响因素都有一张可用的独立的控制表；控制表中的每个位置对物料主数据中的一组字段有效；
表控制Table Control
“Table control”是一个显示元素，它允许用户配置该表来满足他们的需要；这对于如果表中包含很多字段特别有用；
每个用户可以定义他们自己的数据视图来使他们的工作更轻松，通过：
改变列的顺序；
改变列的宽度（包括隐藏他们）；
保存设置为一个显示变量；
将他们的显示变量设置为标准设置；
管理员也能够设置单个的字段对整个系统都不可见；（授权对象：S_ADM_FCD in the Basis Administration authorization class）；
事务变量/屏幕变量/GuiXT Transaction Variants/Screen Variants/GuiXT
事务处理可通过屏幕变量来简化：
字段中输入默认值；
隐藏和修改哪些字段can be completed with data；
隐藏整个屏幕；
压缩和隐藏屏幕特别地使使用R/3系统更加容易并且提供给你一个更好的预览；
一个事务变量由屏幕变量组成；
一个事务变量只分配给一个事务而每个事务可以由几个变量；
事务变量只允许为屏幕事务；
如果你使用batch input或者batch input recording，系统不会使用事务变量中的值；
辅助工具GuiXT允许个别屏幕的柔性设计；GuiXT为前端运行的脚本使用一种脚本语言；你可在GuiXT厂商的主页上找到更多的信息（http://www.synactive.com/）；
[原创] SD从零开始61 可用性检查和需求传递
销售订单中的可用性检查Availability Check in the Sales Order
在物料主数据的销售和分销TAB页你能够：在general/plant页的可用性检查字段中输入，应该在订单处理过程中为该物料执行哪个和/或什么类型的可用性检查；
在配置中还有许多的表，可用性检查也依赖于这些表；
销售订单处理中发生可用性检查的条件：
物料需要库存检查；
在配置中为该事务设置了可用性检查；
物料可用日期检查Material Availability Date Check
物料可用日期从交货排程确定；足够的物料需要在该日期可用以在客户要求的交货日期及时地交货给客户；
系统计算该日期，从客户要求的交货日期向后推算；
系统计算捡配，包装，装载和运输货物的时间；
可用性在物料可用日期检查；
工厂检查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
相应的流程通过计划行类别影响需求传递和可用性检查；这意味着，例如，通过计划行类别来使需求传递和可用性检查无效；