SD从零开始64-特异的业务交易(Special Business Transactions)

紧迫订单Rush Orders

紧迫订单和现金销售是用在从工厂销售流程可能用于当客户需要求即刻从货场获得他们的货物时的销售凭据种类;

在即刻交货的销售凭据种类中,即刻交货符号和交货种类DF是设置的;当你保留一张紧迫订单,系统积极创立一个交货种类DF的交货;

一旦货物曾经从货场取出,捡配和记账发货就能够开始;

当你创立Billing凭据(例如在凑近处理中)时,系统打印发票并将它们发送给客户;

现金销售Cash Sales

在现金销售的销售凭据种类中,即刻交货符号和交货种类BV是搭配的;当你保留现金销售凭据时,系统积极地创立一个交货种类BV的交货并打印一张可作为发票给客户的凭据;

你用输出种类RD03来扼制发票,RD03包括在订单种类CS的输出确定过程中;

一旦货物曾经从货场取出,捡配和记账发货就能够开始;

一张order-relatedBilling目录积极地发生;它会更新到期Billing清单;当处理到期Billing清单时创立Billing种类BV;在Billing中系统不会打印发票;

寄售Consignments

在寄售处理中,货物交付给客户然而保留公司的所有权,直到它们被切实利用;

发票不会创立直到客户从寄售库存中取出货物;直到彼时止客户都有权退回寄售的货物;

万一寄售库存在一个凑近点管教为而不是由sold-to party管教的话,你能够利用特异库存伴侣功能

寄售补货和发行Consignment Fill-up and Issue

  你用订单种类CF处理寄售补货;发货在客户处发生了一个特异库存;然而,货物任然在交货工厂的估价库存中;该交易不会Billing因为寄售库存保留你公司的所有权;

  寄售发行用订单种类CI处理;当货物发行时,客户特异库存和交货工厂的库存都被收缩了;该交易与Billing相干;

寄售捡配和退货Consignment Pick-up and Returns

  万一客户退货,你能够用订单种类CP(consignment pick-up)来描写它;该交易在发货时贷记特异客户库存;与寄售补货一样,该交易与Billing无关;

  万一你想废止寄售发行,你能够用凭据种类CR(consignment return)来处理它;发货又在客户处发生特异库存;一张贷项凭据基于该寄售退货发生;

免费交货以及后续交货Deliveries Free of Charge and Subsequent Deliveries

  你创立一张免费交货凭据,例如,当你想发送样品给你的客户时;

  你输入一张后续免费交货凭据,例如,当你因为一个投诉必需为一张订单交货时;

销售凭据种类SDF的搭配定夺了该交易必需一张前述凭据;所有可能会用到的前述凭据的相干的复制扼制定然发生,例如,从RE(return order)到SDF的复制扼制;

通过激活销售凭据种类中的交货凝固(delivery block),你确保免费交货和后续免费交货交易不会被释放直到他们曾经被相干的员工察看过;万一员工定夺交货不该当发生,他/她能够在销售凭据中维护拒绝的相干起因;

在条目种类的搭配中,你定夺在销售凭据种类DF和SDF中的条目是免费的(例如KLN可能KLX);你还能够定义这些条目关于定价和Billing的行动;

时间: 2024-11-08 11:51:02

SD从零开始64-特异的业务交易(Special Business Transactions)的相关文章

SD从零开始38-40

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

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

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

SD从零开始71 业务信息仓库(BW)

SD从零开始71 业务信息仓库(BW)概念 在线事务处理的环境OLTP Environment 在事务处理中,我们不断地填充用于跟踪我们的业务流程的数千个不同步骤的特定的表: 例如,销售凭证行条目来自询价行条目和/或报价条目,将变成交货抬头数据,变成发票抬头,变成应收款信息等等: 焦点通常在从一套表到另一套表的事务流上:在标准交付的系统中,有大概10000张表: 业务信息仓库是不同的!在BW中,我们不会设法处理事务,而是设法将焦点集中在R/3中的一个特定的"process",然后把与一

SD从零开始41-44

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

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

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

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

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

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

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

SD从零开始67-70 后勤信息系统中的标准分析, 信息结构, 信息的更新规则, 建立统计数据

SD从零开始67 后勤信息系统中的标准分析 标准分析中的报表Reporting in Standard Analyses 标准分析为高质量的表达和分析LIS中的数据基础提供了大量的功能: 当你决定了一个要分析的对象(例如,采购组,供应商,物料组等:)并设置了选择时,就为一个标准分析建立了数据基础: 然后该数据被组织并能够显示在一张初始的列表以及多种下钻列表中:每个分析都能够被存档: 你能够从列表的不同下钻层次使用应用中的标准事务来显示完整的主记录或凭证信息: 大量的功能能够用于从业务观点个别地检

SD从零开始45-46

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