sap-SD从零开始1

yw6866

　　Reference:http://blog.sina.com.cn/s/articlelist_1604613740_6_1.html

　　销售相关的组织结构：
　　销售组织Sales organization
　　分销渠道Distribution channel
　　产品组Division
　　销售区域Sales area
　　销售办公室Sales office
　　销售组Sales group
　　销售人员Salesperson
　　工厂Plant
　　库位Storage location
　　销售组织：
　　    一个销售组织代表一个合法的销售实体；
　　    一个销售组织只能分配给一个公司代码；
　　    一个销售组织可以分配给多个工厂；
　　    每个销售组织有自己的主数据，包括客户主数据、物料主数据以及条件记录；
　　分销渠道：
　　    在一个销售组织中，客户可以通过一个或多个分销渠道获得服务；
　　    可以为销售组织和分销渠道的组合定义不同的主数据；
　　产品组：
　　    对某一产品组，可以执行统计分析或制定市场战略；
　　销售区域：
　　    销售区域是 销售组织/分销渠道/产品组 的组合；
　　    销售订单(Sales order)，交货单(Delivery)，开票(Billing)都分配到某一销
　　      售区域；
　　    所有的销售流程都发生在某一特定的销售区域；
　　    相关的主数据经常维护在销售区域层；
　　    应该尽量保持销售区域组织结构越简单越好；
　　销售办公室：
　　    销售办公室可以分配给一个或多个销售区域；
　　销售组：
　　    可为每一个产品组或分销渠道定义一个销售组；
　　    销售组分配给销售办公室；
　　销售人员：
　　    一个销售组包括一定数量的销售员。
　　工厂、库位：
　　    每个工厂只能分配一个唯一的公司代码；
　　    对每一个交货给客户的工厂，必须在SD的配置中将它定义为delivering plant；
　　    在销售流程中，delivering plant首先需要check库存，然后才提供交付；
　　分配销售组织和工厂：
　　    一个销售组织可分配多个工厂，一个工厂可分配多个销售组织；（多对多关系）
　　    销售组织还可以分配跨公司代码的工厂；
　　
　　销售流程：
　　销售流程从建立客户关系开始，至开出销售发票终止；
　　售前活动Pre-Sales Activities（客户询、报价）-->
　　销售订单处理sales order processing（产生销售订单）-->
　　货源决定Inventory Sourcing（从delivering plant供货还是第三方供货商？哪一个？）-->出货shipping（交货） --> 销售发票Billing（开票）-->付款payments（清账，Post）；
　　
　　业务场景：
　　建立和维持客户关系；
　　获取订单；
　　应答客户物料、价格和交期；
　　基于客户需求和物料可用性的交货计划；
　　捡配和交付商品；
　　更新物料库存和物料消耗科目；
　　创建发票并更新销售科目；
　　清帐和销售收入过账；
　　
　　标准销售订单包括：
　　客户和物料信息；
　　对于每个item的定价条件；
　　交货日期和数量；
　　交货流程信息；
　　发票信息；
　　销售凭证的结构Sales document
　　头信息 Header
　　行项目Item
　　计划行Schedule Line
　　交货单结构Delivery document
　　头信息 Header
　　行项目Item
　　Billing document结构
　　头信息 Header
　　行项目Item
　　
　　客户主数据Customer master（分层维护）
　　一般数据general data；
　　与销售和财务都有关，对所有的组织单元有效；
　　销售区域数据sales area data；
　　与销售有关，对各自的销售区域有效；
　　公司代码数据company code data；
　　与财务有关，对company code有效；
　　MARK：如果修改了客户主数据，除了地址信息外，不会影响已经创建的凭证order，delivery，billing。。。）；
　　物料主记录Material master（分层维护）
　　基本数据Basic data；
　　与所有area相关，对所有的组织单元有效；
　　销售：销售组织数据 Sales：Sales organization data；
　　与销售相关，对各自的销售组织/分销渠道有效；
　　销售：工厂数据 Sales: plant data；
　　与销售相关，对各自的出货工厂（Delivering Plant）有效；
　　采购数据Purchasing data；
　　与采购相关，对各自工厂有效；
　　其他Other：工程、物料计划、财务等；
　　MARK：跨产品组的销售：可以在一张销售订单上输入不同产品组的物料；
　　可以在Sales Document Type中配置以下内容：
　　是否允许在一张销售订单上输入不同产品组的物料；
　　系统的反馈（提示还是不提示Warning）；
　　是否从物料主数据中Copy Division；
　　客户/物料信息记录Customer-material information record
　　可定义客户料号和自有料号的相互对照关系；在销售订单的Ordering Party 选项卡会反映；
　　可定义针对特定客户、物料组合的shiping信息；
　　输出主记录OUTPUT
　　采用了条件技术；
　　每一个OUTPUT Type 定义了传送媒介transmission medium、时间time、partner function、layout form（SAP Script定义）；
　　OUTPUT Type包括quotation, order confirmation, invoice等；
　　不完全日志Incompletion log
　　在配置中可以定义那些Fileds将会出现在不完全日志中（如果用户没有输入）；
　　该功能在Sales order 和 delivery中可用；
　　条件主记录Condition master
　　价格prices；
　　额外费用/折扣surcharges and discounts；
　　运费freights；
　　税taxes；
　　MARK：在配置中，你可以定义价格、费用/折扣、运费、税的依赖条件；
　　销售订单的数据来源：
　　主数据（客户、物料、条件）；
　　已有凭证；
　　配置（customizing）；
　　Hard-coded control；
　　Sales area的来源：
　　销售订单上的Sales area系统根据Sold-to-part自动带出；
　　SO从主数据获取数据：
　　在主纪录中存贮越多的数据越好，这样会节省你输入订单的时间并且避免出错；
　　你可以在主数据中输入各种类型的数据，例如业务伙伴的信息，物料，客户/物料信息记录，行项目建议，BOM，价格，折扣折让，税，输出，文本等。在输入订单的过程中系统会频繁地访问这些数据；
　　客户主数据中的业务伙伴
　　销售业务中的基本的业务伙伴有：
　　Sold-to party
　　ship-to party,
　　payer
　　bill-to party
　　他们在业务流程中扮演不同的角色（叫做partner function）；
　　你可以为每个伙伴维护客户主记录；
　　从客户主数据中获取订单数据：
　　订单中的业务数据来源于不同的业务伙伴的主数据；
　　因为ship-to party可能与sold-to party不在同一个地址，因此，交货地址和税的信息来源于ship-to party；
　　付款条件的数据来源于payer；
　　invoice发送的地址数据来源于bill-to party;
　　业务数据：
　　你可以在凭证头部定义业务数据（例如付款条件，incoterms）；
　　在配置中，可以在行项目类别（Item Catogray）中定义行项目层的业务数据是否可以与头部（header）的不同；
　　自动确定plants：
　　Plant是物流的主要部分，在SD中扮演的是Delivering Plant的角色；
　　系统自动确定Delivering Plant搜索的顺序：可用userexit增强；
　　客户/物料信息记录；
　　客户主记录（Ship-to-part）；
　　物料主记录；
　　销售信息汇总（Sales Summary）
　　销售汇总显示与客户相关的各种信息，例如地址，销售数据，价格等。
　　凭证数据修改：
　　修改的选项：
　　Fast change in document；
　　Changing several documents；
　　Blocking documents；
　　Rejecting documents；
　　BLOCK（冻结）：
　　在销售订单上，可以Block的事务：
　　For Shiping（出货冻结）；
　　For Billing；
　　MARK：可以设置在行项目，也可以设置在头部；
　　可以在配置中定义Delivery Block在Shipping流程中的详细影响：
　　如是阻止生成delivery，还是允许处理delivery和picking，但是阻止Goods Issue；
　　Reject（废弃）：
　　可以为Reject的行项目输入原因；
　　Reject的原因可以了解到一段时间内客户对公司产品的看法，对市场部门有用；
　　重新定价New Pricing In Sales Document：
　　Price 更新的层次：
　　At item level；
　　At header level；
　　Document list for several documents at the same time；
　　MARK：在Pricing type中定义该功能在update时的行为（全部重新确定or not）；
　　修改Sold-to-part：
　　重新确定的数据：
　　客户主记录、客户/物料信息记录、文本、免费商品、价格、输出、工厂和货运点
　　不变的数据：
　　销售区域、销售办公室和销售组、可用性和产品分配、批次
　　MARK：如果有状态相关的前导凭证或有后续凭证，则不会更改；
　　销售凭证类型Sales document type：
　　用来鉴别和控制不同的业务流程类型；
　　标准的销售凭证类型：
　　standard order；
　　Rush order；
　　cash sales；
　　free-of-charge delivery；
　　returns；
　　Contract；
　　Consignment fill-up；
　　Credit/Debit request；
　　销售凭证功能Sales Document Functions
　　通过销售凭证类型直接或间接地active或deactive；
　　功能：
　　Delivery scheduling；
　　Transfer of requirements；
　　Pricing；
　　Sales Info System；
　　Credit check；
　　Output；
　　Text；
　　Availability Check；
　　交货起运点Shipping Point
　　Shipping Point是R3中负责交货（shipping）的组织单元；
　　可以在Shipping Point中定义准备和装卸货物的时间；
　　Shipping Point通常为销售凭证中的每个行项目所确定；
　　路线Route：
　　起点/终点，可分为几段；
　　可以用Route来为运输计划定义实际的运输时间和前置时间；
　　自动确定shipping Point：
　　根据3个key来搜索：
　　交货条件shipping condition：Sold-to-party 客户主记录中定义；
　　装卸组loading group：物料主记录中定义；
　　出货工厂delivering plant：见出货工厂的自动确定（Lesson 4）；
　　MARK：可以用交货条件来定义客户需求；
　　自动确定Route：
　　根据4个key来搜索：
　　出发地区departure zone：shipping point中定义；
　　交货条件shipping condition：Sold-to-party 客户主记录中定义；
　　运输组transportation group：物料主记录中定义；
　　目标地区transportation zone：ship-to party客户主记录中定义；
　　交货计划Delivering Scheduling
　　订单发行日期Order date；
　　物料可用日期Material availability date；
　　运输计划时间Transport planning；
　　装载日期Loading date；
　　发货日期Goods issue date；
　　交货日期Delivery date：到达客户；
　　运输计划Transportation Scheduling
　　运输时间 transit time；
　　运输前置时间Transportation lead time；
　　回溯计划Backward scheduling
　　交货和运输计划的目的是确定客户物料的交期；
　　物料筹备日期和运输计划日期可根据客户要求的交货日期计算出来；外向交货单outbound delivery必须在此两个日期最早的那个创建；
　　前向计划Forward scheduling
　　当回溯计划的结果显示客户要求的交期无法达成时，使用前向计划；
　　物料最早可用的时间是新的物料筹备日期；outbound delivery日期是新的物料筹备日期和运输计划日期中早的那一个；
　　对销售凭证的ITEM，会有2条计划行项目产生：
　　第一条计划行的日期对应客户要求的交货日期，没有确认数量；
　　第二条计划行显示的是确认的交货期和确认金额；
　　集中交货处理Collective Processing in shipping
　　在系统中建立Outbound delivery依赖于shipping point、selection date 和 其他条件；
　　一旦你设置了这些标准，就能够控制选择到期应该shipping的业务；选择的可选项因Delivery的场景和用户的角色不同而变化；
　　当设置了选择日期（selection date），就定义了当日到期item会被考虑集中delivery处理；此日期是货物能够按时到达客户的最晚开始Shipping处理的时间；它对应物料筹备日期或者运输计划日期；
　　Outbound Delivery选项
　　完全交货Complete Delivery；
　　部分交货Partly Delivery；
　　合并交货 Order Confirmation；
　　不同订单合并的条件：
　　相同的shipping point；
　　Delivery到期的日期相同；
　　相同的ship-to-party；
　　相同的route；
　　相同的Inco terms；
　　出货流程中的检配Picking in Shipping Process
　　Picking是从创建Transfer request开始的；Transfer request中的行项目包括物料及数量，对应Outbound Delivery中的delivery的数量；
　　集中Picking处理Collective processing in Picking
　　系统自动地将outbound delivey的项目合并到尽可能少的transfer request中；
　　Picking选项Picking Options
　　从transfer request打印picking list/传送到外部WMS系统；
　　手动/自动确认；
　　如果全部数量无法满足：
　　产生另外一个新的tansfer request；
　　将Picked 的数量copy到Outbound delivery的delivery数量；（部分交货）
　　集中出货处理Collective processing for Posting Goods Issue
　　系统自动地将outbound delivey的项目合并到尽可能少的document中；
　　集中开票处理Collective Processing in Billing
　　系统提供billing due list来实现一次处理多张billing document；
　　系统自动地将项目合并到尽可能少的billing document中；项目可以是order中的也可以是outbound delivery中的（系统中配置）
　　合并的条件：
　　same billing date, the same ship-to party, payer or terms of payment；
　　Billing选项Billing Options
　　发票分割Invoice split：
　　eg: 1张outbound delivery对应1张sales order，
　　2张billing document对应1张outbound delivery；
　　每张交货单单独开票Separate billing document for each outbound delivery：
　　eg: 2张outbound delivery对应1张sales order，
　　2张billing document对应2张outbound delivery；
　　集中开票Collective invoice：
　　eg: 3张outbound delivery对应2张sales order，
　　1张billing document对应3张outbound delivery；
　　Worklist在SD中的集中处理：
　　Delivery list：处理order到outbound delivery；
　　Picking worklist：处理outbound delivery到transfer request；
　　Goods issue worklist：处理outbound delivery到goods issue；（Picking完成）
　　Billing Due list：处理outbound delivery（/order）到billing；（Goods issue完成）
　　销售中的业务流程控制Controlling Business Processes in sales
　　销售流程通过销售凭证（sales documents）的配置来控制；
　　销售凭证的配置可在凭证头Header、行项目Item、计划行schedule line层次，依赖于凭证的结构，
　　对应的控制工具为销售凭证类型Sales Document type、行项目类型Item Category、计划行类型Line Schedule Category；
　　需要配置以实现Item Category和Schedule Line Category在销售凭证中自动带出；
　　在Copy Control中可以根据你的需要配置数据从销售凭证传送到后续凭证的内容；
　　基本功能Basic Functions
　　必须为销售凭证定义一些基本功能，否则销售凭证就没有配置完成；
　　这些基本功能包括：
　　Partner determination；
　　Pricing；
　　Output determination；
　　Text determination；
　　Material determination；
　　Credit management；
　　Incompletion checks；
　　Delivery scheduling etc.
　　可以为不同的Sales Document Type使用不同的功能；
　　销售凭证类型的功能Functions in sales document type
　　号码分配Number assignment；
　　缺省值Default Value：
　　Date，billing type，delivery type，blocks；
　　检查Check：
　　Division，Open Quotations/contracts，Info Record；
　　MARK：Check会影响性能；
　　合同增强Enhancement for contracts；
　　分配基本功能Assigning basic
　　强制参考Mandatory reference
　　MARK：增加一个销售凭证类型到销售流程中是非常耗时的，因为在配置中很多输入都是依赖于销售凭证类型的；所以最好是Copy现有的；
　　修改销售凭证类型Changing The Sales Document Type
　　当修改销售凭证上的销售凭证类型时，必须确保：
　　没有后续的凭证；
　　不是状态相关的后续凭证；
　　凭证不是从service notification 或者contract创建；
　　行项目类别可以修改；
　　MARK：如果试图修改已经保存的凭证的凭证类型，2个凭证类型必须属于相同的号码范围；
　　销售区域允许的订单类型Order Types permitted for sales areas；
　　可以定义销售凭证的有效范围：
　　销售组织Sales organizations
　　分销渠道Distribution channels
　　产品组Divisions
　　
　　行项目类别
　　Item Category的例子：
　　 系统交付的不同的Item category支持不同的业务流程，可以根据它来创建自定义的；
　　定义为4位的key；前2位提示销售凭证类型，后2位显示Item category的作用；
　　AFTX Sales document type: IN    Usage: TEXT；
　　TAD Sales document type: OR     Item category group: LEIS；
　　KMN Sales document type: NMS   Item category group: NORM；
　　Item Category的作用：
　　控制Item在销售凭证及后续的业务处理流程中的行为；
　　Item Category的本质特怔决定：
　　行项目的业务数据是否允许不同于头部；
　　价格是否应用于Item；
　　Item是否和如何做Bill；
　　Item是否引用另外一个item，或它是否仅仅是一个文本行；
　　哪一个incompletion log用来Check the item data；
　　可以修改标准系统中定义的Item category的设置，也可以通过COPY/Change来定义新的Item category；
　　Delivery相关标记delivery relevance indicator 是仅适合没有计划行的Item，例如可以Text Item中MARK它，则系统会将该ITEM从sales order copy到Delivery document；
　　作用：
　　区分业务数据separate business data；
　　计划行允许Schedule Lines permitted；
　　交货相关delivery relevance；
　　开票相关Billing relevance；
　　定价Pricing；
　　物料清单BOMs；
　　完成规则completion rule；
　　分配基本功能Assigning basic functions；
　　控制销售凭证中的行项目：
　　销售凭证中的每个行项目是通过Item category来控制的；这样可以：
　　在不同的销售凭证中使用不同的Item category；
　　在销售凭证中为每个Item实现不同的业务处理流程；
　　标准订单中Item category的判定：
　　销售凭证中的Item category是通过销售凭证类型sales document type和物料主记录中的行项目类别组item category group来查找的；
　　子项目Sub-items：
　　可以将行项目分配给更高层的行项目，例如客户订购一定数量的的商品（10）将获得免费赠送的商品（20）；在20的higher-level item field中输入10；
　　其他应用sub-item的例子包括BOMs展开和Service 项目；
　　MARK：除了sub-item，可供选择的项目Alternative items 也可以记录在报价和询中，但是它的处理不同于sub-item，例如Alternative items不包含在凭证的净值中；
　　BOMs的例子：
　　所有你想要在销售凭证中控制的BOM items都必须标记为‘relevant for sales’；
　　当BOM使用类型BOM usage 5创建的BOM中的所有项目会自动标记为销售相关；
　　在销售凭证的Item category中作了适当的设置之后，你只需要输入BOM的料号就可以将BOM中的所有组件COPY到销售订单中；
　　BOM以主-子main and sub-items 的形式出现在销售凭证中，系统自动展开BOM为组件生成子项目；
　　在销售凭证中展开BOM：
　　在销售凭证中，有许多独立的Item Categorys控制BOM的行为，配置时，你为销售凭证中的BOM的main和sub-item定义和分配item category；
　　在main item的物料主记录中定义的item category group定义了哪种item category分配给了main item；
　　为了判定销售凭证中BOM要展开到什么程度，需要为main item定义item category结构的广度extent；
　　当你判定了sub-item，系统也需要知道上层item的item category；
　　在item category的配置中，你可以控制哪些item与定价有关以及怎样实现需求传递requirements transfer；