SD从零开始03-04

[原创]SD从零开始3 SD中的主数据

客户主数据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:在配置中,你可以定义价格、费用/折扣、运费、税的依赖条件;

[原创]SD从零开始4 SD销售订单流程

销售订单的数据来源:

主数据(客户、物料、条件);

已有凭证;

配置(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:如果有状态相关的前导凭证或有后续凭证,则不会更改

时间: 2024-10-22 08:13:29

SD从零开始03-04的相关文章

SD从零开始41-44

[原创] SD从零开始41 科目确定(Account determination) 使用科目确定Using Account Determination 你将需要在几个不同的领域确定将要记账的科目: 用于记账销售收入,销售扣除和增值税的总账科目在数据从billing document传输到FI时自动地确定: 当处理现金销售时,必须在凭证中设置一个总账科目用于现金结算(不会记账到客户账户): 到4.0版本时,可以确定一个不同于付款方客户主数据中输入的科目的统御科目: 当使用payment cards

SD从零开始38-40

[原创]SD从零开始38 创建Billing Document 根据需要BillingBilling On Request 你可以通过手工输入凭证的号码(订单号码和Delivery note,依赖于你想要执行订单相关的还是交货相关的Billing)明确地指定哪些交易将要Billing: 如果Billing无法产生,例如因为一个billing block,系统会发行一个错误日志: 到4.5版本,在为deliveries或ordersBilling时你还可以选择单个的items或者items的部分数

SD从零开始45-46

[原创] SD从零开始45 运输流程的控制 运输业务场景的例子Examples 一个公司可使用不同的运输业务场景,通过不同的处理类型或者运输方式来刻画: 要模型化这些不同的装运,你可以在配置中定义装运类型(shipment types): 装运类型Shipment type 装运类型控制装运凭证中的元素并因此为装运描述了一个特殊的处理类型: 装运类型设置包括: 段确定类型(例如,自动段确定): 完成类型(例如,已装载的外向装运,内向装运): 处理控制(例如,使用一种运输方式的汇总装运): 服务水

Android实现推送方式解决方案【转载地址:http://www.cnblogs.com/hanyonglu/archive/2012/03/04/2378971.html】

本文介绍在Android中实现推送方式的基础知识及相关解决方案.推送功能在手机开发中应用的场景是越来起来了,不说别的,就我们手机上的新闻客户端就时不j时的推送过来新的消息,很方便的阅读最新的新闻信息.这种推送功能是好的一面,但是也会经常看到很多推送过来的垃圾信息,这就让我们感到厌烦了,关于这个我们就不能多说什么了,毕竟很多商家要做广告.本文就是来探讨下Android中实现推送功能的一些解决方案,也希望能够起到抛砖引玉的作用.^_^ 1.推送方式基础知识:  在移动互联网时代以前的手机,如果有事情

shell 如何生成一个序列 01 02 03 04 05

seq 命令介绍 用途: seq - print a sequence of numbers 语法: seq [OPTION]... LAST seq [OPTION]... FIRST LAST seq [OPTION]... FIRST INCREMENT LAST 常用选项 -s, --separator=STRING use STRING to separate numbers (default: \n) -w, --equal-width equalize width by paddi

SD从零开始51-54 信用控制范围, 信用范围数据维护, 自动信用控制, 信用控制-阻止后续功能

[原创] SD从零开始51 信用控制范围 分散的组织结构Decentralized Organization 信用控制范围是一个为客户指定和控制信用限额的组织单元: 依赖于你公司的需求,应收款可以使用集中的或者分散的信用政策来管理: 使用分散的信用政策,每个公司代码可以为它的客户确定它自己的信用数据: 一个销售组织只可以分配给一个公司代码,一个业务交易只可以分配给一个信用控制范围: 集中的组织结构Centralized Organization 在集中的组织结构中,公司代码组合到信用管理的一个信

SD从零开始59-61,跨公司的库存转移,Interface 修改,可用性检查和需求传递

[原创]SD从零开始59 跨公司的库存转移处理流程 库存转移流程Stock Transfer Procedure 2个工厂间的库存转移能够使用不同的流程来执行: 只执行一个库存转移记账的流程使用MM库存管理模块:与此相比,你还有这样流程,即当在MM的采购模块输入一张采购订单时,自动开始库存转移流程(库存转移订单):如果你使用带SD交货的库存转移流程,有一个优势是装运活动也能够在R/3系统中处理(捡配,包装,打印交货票据等): 如果你希望为库存转移处理使用R/3的装运功能,使用为公司内部转移的流程

SD从零开始57-58,第三方订单处理,跨公司销售

[原创] SD从零开始57 第三方订单处理流程 第三方订单处理的流程Processes for Third-Party Order Processing 客户的采购订单首先在你公司的一个销售组织作为一张销售订单输入:自动地从这张订单创建一张采购请求: 然后,在MM的采购应用程序中为外部供应商创建一张采购订单:该订单声明所有商品将直接交货给客户: 一旦供应商向你证实外向交货已经完成,你就记账收货以使这些信息记录在系统中: 在MM的发票校验应用程序,你输入由供应商为因由供应商交货给客户而出具给你公司

SD从零开始55-56, 风险管理, 付款卡

[原创] SD从零开始55 风险管理的内容 应收款风险最小化Risk Minimization for Receivables 每个信用政策的目的是减少由客户应收款带来的风险: 连同信用管理,你也有权限在业务处理中使用其他几种付款担保形式:这包括信用证,出口信用保险(外部连接)和付款卡: 这些付款担保形式因他们提供给你的安全水平而不同,且都集成在风险管理中: 当使用了一种付款担保(例如,信用证),系统首先尝试提供最适宜的风险最小化: 如果这是不可行的,然后你可以在第二阶段使用信用管理来创建一个信

SD从零开始62-63,不完全日志,业务伙伴及业务伙伴确定

[原创] SD从零开始62 不完全日志 不完全日志Incompletion log 一个不完全日志是销售凭证中对你公司重要的而还没有在系统中输入的所有数据的清单: 你可以在配置中为不完全日志定义这些数据字段: 系统可以从不完全日志直接跳转到各个屏幕,在这里你可以编辑这些不完全的数据: 不完全订单清单Lists of incomplete orders 每个员工都可以列出他们已经创建的不完全的销售订单:他们还可以在选择屏幕上显示为某个特定的步骤冻结的某些凭证,例如因不完全而冻结不能装运的所有凭证的