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

[原创] SD从零开始57 第三方订单处理流程

第三方订单处理的流程Processes for Third-Party Order Processing

客户的采购订单首先在你公司的一个销售组织作为一张销售订单输入;自动地从这张订单创建一张采购请求;

然后,在MM的采购应用程序中为外部供应商创建一张采购订单;该订单声明所有商品将直接交货给客户;

一旦供应商向你证实外向交货已经完成,你就记账收货以使这些信息记录在系统中;

在MM的发票校验应用程序,你输入由供应商为因由供应商交货给客户而出具给你公司的发票;

最后,你产生给你的客户的销售Billing活动;

第一处理步骤:创建销售订单1st Process Step:Create Sales Order

第三方订单处理在你输入带有第三方条目的销售订单时启动;无论该订单是由部分第三方条目还是订单中所有的条目都是第三方条目组成;

依赖于你的系统在配置中是怎样设置的,第三方条目类别可以由系统为各自的物料自动地确定(“自动第三方订单处理”);然而,如果你想将你通常自己交货的物料作为第三方条目处理,你可以通过输入各自的条目类别手动地将标准条目修改为第三方条目(“手动第三方订单处理”);

在第三方订单条目的自动排程中,系统考虑来自物料主数据的计划交货时间,那就是,供应商要求交货的时间;采购部门的处理时间,那就是采购部门处理第三方订单所需要的时间,也包括在内;采购部门处理时间在配置中分配给工厂;

创建采购请求Creating the Purchase Requisition

在销售的标准配置中,系统配置为当你保存销售订单到数据库中时,采购请求在采购中自动地创建;

这里,为每个第三方条目自动地创建了一条单独的采购请求条目;在创建采购请求的同时,系统自动地为每个请求条目确定一个供应商;如果一个第三方订单条目具有多个计划行,系统为每一行创建一个采购请求条目;

你可以从销售订单的计划行跳转到显示创建的采购请求条目;

在销售订单中,你可以对第三方订单条目的数量和交货日期作后续的修改;你所做的修改会自动地复制到各自的采购请求,倘若采购请求的发布状态还允许这样的话;

采购请求具有销售订单的科目分配;该科目分配在采购请求中不能修改;

带第三方条目的订单的结构Structure of Order with Third-Party Item

销售凭证由凭证抬头和任意数量的条目组成;每个条目可以有任意数量的计划行;在计划行层次你找到采购和分销的数据;

销售凭证为抬头,条目和计划行设置进行配置,与各自的结构保持一致;有关的控制手段包括销售凭证类型,条目类别,以及计划行类别;

你通过创建一张标准销售订单(例如,销售凭证类型OR)来创建第三方订单条目;

在标准配置中,条目类别TAS定义为第三方订单条目;同样,系统配置使计划行类别CS为第三方订单条目确定;

销售订单可以由更多的第三方订单条目或其他条目类别的条目组成;

条目类别确定Determination of Item Category

对绝大多数来讲,条目类别依赖于销售凭证类型和物料的条目类别组;另外2个因素,条目用法(item usage)和上级条目的条目类别,在第三方订单处理中具有较小的重要性;

使用条目类别组,你可以从销售的角度将不同的物料分组;例如,你应该将条目类别组BANS(“第三方条目”)分配给那些在销售中独自作为第三方订单处理的物料;标准系统中的条目别分配引起自动确定条目类别TAS;

如果你已经在配置中定义了允许的选择,由系统确定的条目类别可以被修改;典型的用法是如果你想要通常由你自己交货的物料由外部供应商直接交货给客户;

第三方订单处理的交货计划行类别Delivery Schedule Line Category For Third-Party Order Processing

在标准系统中,计划行类别CS用于处理第三方订单条目;

因为第三方订单条目不是由你公司供应,你不需要在你的系统中记账发货;因此,计划行类别CS在配置中不包含移动类型并且不会设置为与交货相关;

在标准系统版本中,一旦销售订单保存到数据库中,系统就会自动地从销售订单为第三方订单条目创建一张采购请求;同样,计划行类别CS的配置中包含用于采购请求的凭证类型的说明以及条目类别(用内部特性表示)和科目分配类别;

确定计划行类别Determination of the Schedule Line Category

计划行类别被分配给条目类别;

这样分配的目的是:

当订单输入到系统时系统自动地带出一个计划行类别;

定义如果默认值会被改变时用户可以选择的计划行类别;

分配受物料主记录中的MRP类型的影响;

当自动确定计划行类别时,系统进行2个步骤:

首先,系统尝试使用条目类别/MRP类型的关键字组合来确定计划行类别;

如果没有找到计划行类别,系统使用条目类别/无MRP类型关键字组合来搜索;

因此,如果有物料的MRP类型在物料主记录中没有维护,但是需要找到一个计划行类别,计划行类别分配的配置设置必须包含带条目类别和MRP类型为空的行;例如这种情况:对于条目类别TAS,系统确定计划行类别CS;

第二处理步骤:创建采购订单2nd Process Step:Create a Purchase Order

  在第三方订单处理中,采购订单通常的方式是从采购请求创建;

  当创建采购订单时,系统自动地采用来自各自销售订单的交货地址和收货地址;

  你可以在销售订单中为每个第三方订单条目维护订单文本;他们在采购订单创建时自动地复制到采购订单;

  创建的采购订单出现在销售订单的凭证流中,从这里你也可以跳转到采购订单;

  采购订单中的第三方条目Third-Party Item in the Purchase Order

第三方订单条目在采购订单中标记为条目类别S;

第三方条目必须具有一个科目分配;在标准版本中,使用科目分配类别X(所有辅助科目分配);

你在采购订单中做的任何数量和日期的修改会自动地复制到销售订单;这些修改可能是必须的,例如,如果供应商报告不同的日期和数量;

Mark:如果已经有了一张业务交易的采购订单并且你想要修改销售订单,你必须在采购订单中手工地执行这些修改因为这不会自动地更新;这可能会发生,例如,虽然客户已经取消了销售订单,但是它们还是收到了交货;为了监控这些活动,你可以使用报表SDMFSTRP来创建一张带有第三方订单条目但是采购和销售之间存在数量差异的所有销售订单的清单;

第三处理步骤:记账收货3rd Process Step:Post Goods Receipt

你可以按这种方式设置业务流程,只有在预先为采购订单输入了收货,才可以输入供应商的发票;

用这种方式防止了即使交货尚未发生,客户却收到了Billing凭证的情形;

只有当供应商向你报告交货已经交割时,你才记账收货;可选择的是你可以让客户确认交货的收据;

为了能使用该监控特征,在采购订单条目中设置GR标识符或者在配置中执行必须的设置;

因为没有物流发生在你的公司,收货记账仅作用于你系统的价值更新;

第四处理步骤:为采购订单记账发票接收4th Process Step:Post Invoice Receipt for Purchase Order

你使用后勤发票校验模块为来自供应商的每张发票输入一张发票接收;

如果在你的第三方订单处理的业务流程中提供了收货,只有在你已经输入了收货到系统之后你才可以记账发票接收;

第五处理步骤:为销售订单Billing 5th Process Step:Bill for Sales Order

一旦你在系统中记录了发票接收,你就可以开始为客户Billing;

销售订单组合到billing due list并且在为Billing的下一次多重处理运行中处理;

该due list有关的billing date对应于发票接收凭证的记账日期;

因为在系统中不存在第三方订单条目的交货,你在选择要Billing凭证时设置标记为order-related billing;

Billing相关性和Billing数量Billing Relevance and Billing Quantity

如果在配置中,Billing相关性标识符设置为F(“订单相关的Billing:状态依赖于IR的数量”),只有当供应商发票已经收到并输入到系统中,系统才会在billing due list中包括该订单;

在销售凭证到Billing的复制控制中,第三方订单条目类别的标准设置定义了来自发票接收凭证的数量,而不是订单数量,会复制到Billing中(Invoiced quantity字段);

第三方订单处理:配置清单Third-Party Order Processing:Checklist for Customizing

如果你在销售凭证控制中实施用户定义的对象:

定义第三方条目类别(包括定义Billing相关性);

维护条目类别确定;

定义第三方订单处理的计划行类别(包括分配凭证类型给采购请求);

维护计划行类别确定;

维护销售凭证到Billing的复制控制(包括Billing数量的确定);

[原创] SD从零开始58 跨公司销售

跨公司销售活动的流程Process for Cross-Company Sales Activity

example:首先在销售组织2200中输入一张销售订单,这属于所谓的订单公司Ordering Company Code(公司2200);

与负责交货的工厂相关的公司叫做交货公司(公司1000);

一旦订单到期应该交货,你就创建交货;Goods Issue发生在装运活动的结尾,并且货物交付给客户;

然后,最终客户的发票在销售组织2200中创建,那就是,在订单公司中;

为了使公司间Billing发生在涉及的2个公司之间,交货公司通过它的销售组织1000发行一张内部发票给订单公司;

依赖于这两个公司之间达成的协议,发票接收的输入可能自动地发生;如果不的话,收到的发票在订单公司的财务会计系统中手工地输入;

第一处理步骤1st Process Step:Create Sales Order

跨公司销售处理的流程开始于你创建一张标准的销售订单;

在一张销售订单中,系统为每个订单条目确定交货工厂,或者这些数据由处理者手工输入;系统可以从下列主记录中带出交货工厂(顺序依照优先级):

客户-物料信息记录;

收货的客户主数据;

物料主数据;

如果订单条目的交货工厂属于不在创建订单的销售组织中的一个公司代码,系统认识到这是一个跨公司的销售活动;

分配销售组织和工厂Assignment Sales Organization and Plant

当你创建订单,系统检查销售组织和交货工厂的组合是否被允许;

依赖于销售组织,被销售活动允许的工厂连同分销渠道一起定义;这样就可以允许销售组织从几个工厂销售货物;反过来,一个工厂可以分配给几个销售组织;

在配置中,一个工厂唯一地分配给一个公司代码;一个销售组织,也仅属于一个公司代码;

销售组织和工厂的相互分配不需要属于相同的公司代码;否则,跨公司的销售活动就不可能了;

分销渠道从销售的角度提供了在一个销售组织中更进一步的区分工厂的方法;例如,一个分销渠道可以允许一个销售组织内的某些工厂,而不允许其他的;

公司间Billing的价格Price For Intercompany Billing

在订单中,系统自动地执行定价,通过评估存储的条件主记录;

条件类型PR00指定向客户Billing的价格;该价格可能在给客户的发票中以附带费用和折扣的形式出现,倘若其间没有发生修改的话;因此该价格代表了收入;

为信息的目的,代替物料的移动平均价,你具有这样的价格,即订单公司需要支付给交货公司(为公司间Billing的价格)的价格;它会与公司间Billing相关并且描述订单公司的成本;

为了描述内部价格,在标准系统中有2个条件类型:

PI01(quantity-dependent);

PI02(percentage);

条件记录连同订单中输入的销售组织,交货工厂以及,如果必要的话,物料一起维护;

公司间Billing的金额作为一个统计值出现在销售订单的条件屏幕上(它只是显示,对于客户的定价结果没有影响);

第二处理步骤:执行装运活动2nd Process Step:Execute Shipping Activities

一旦交货已经被创建,装运活动就开始了;这可以在为到期的订单执行标准的集中交货处理功能的帮助下或者直接参考一张销售订单来发生;

作为一个规则,交货在装运流程的第一个工作步骤将要开始时创建;

装运流程中的单个工作步骤(捡配,包装,打印交货票据等等)在交货的基础上执行并且也记录在交货中;

交货的创建和装运活动的执行都发生在订单中指定的装运点;装运点在配置中分配给交货工厂;

装运处理的工作步骤Worksteps for Shipping Processing

为捡配的目的,一张参考交货的转移订单被创建了;转移订单的打印清单交给捡配人员以使他/她能够从仓库中捡配所需的货物;

依赖于配置中的设置,捡配可能需要确认(confirmation requirement);在转移订单的确认中,你可以输入数量差异;

如果货物在装运中会被包装到大箱子或放到货盘中,适当的信息会被存储在交货中;

使用SD输出控制和输出处理功能,你可以打印交货票据;

发货过账是装运流程的结束活动;这里会发生对库存数量和价值的更新;

第三处理步骤:为最终客户创建发票3rd Process Step:Create Invoice for End Customer

给最终客户的发票是在创建销售订单的销售组织中创建;

开发票参考交货单;这里,外向交货取自另外一个公司代码并不重要;

由于发货记账,交货单自动地输入到billing due list;发票或者立即创建,或者在一次Billing集中处理运行中创建;

交货的发货记账日期是billing due list的相关的Billing日期;

给最终客户的发票的元素Elements of Invoice to End Customer

给最终客户的发票是“普通”发票;在标准版本中,你使用Billing类型F2或者F1,藉此在标准订单(销售凭证类型TA)的案例中,系统自动地使用Billing类型F2作为默认值;

与内部发票相比,付款人以及销售单元和公司代码都直接从订单中获取;

在订单中,公司代码得自输入订单的销售组织,因此被叫做订单公司;

第四处理步骤:创建内部发票4th Process Step:Create Internal Invoice

在上面的例子中,为在销售组织2200中提供服务给客户在公司间Billing,交货公司发行一张发票给订单公司;

内部发票由销售组织1000创建;在配置中,你分配负责公司间Billing的销售组织给交货工厂;

像给最终客户的发票的情况一样,Billing参考交货;你在为Billing选择凭证时设置指示符“intercompany billing”;

只有在发票发行给最终客户之后,交货才会输入到交货公司的各个销售组织的biling due list;

内部发票的元素Elements of Internal Invoice

在标准版本中,Billing类型IV用于内部发票,这是自动地在订单的基础上带出的;

内部发票的付款人通常是订单公司,就像是交货公司的客户;为此你在交货公司中创建一条客户主记录,在其中你维护与Billing相关的数据;然后,你在配置中分配各自的客户号码给订单公司的销售组织(字段“Customer IV”);

内部发票中的公司代码来自交货工厂所属的公司代码;因此它和交货公司相同;

在配置中,你分配为创建内部发票所必须的销售组织单元给交货工厂(字段“Sales organization IV”,“Distribution channel IV”,“Division IV”);确保相同的设置也用于库存转移活动;

付款人的客户主记录Customer Master Record for Payer

为了使内部发票能够被创建,创建销售订单的订单公司中的销售组织必须存在一个客户主记录;该客户主记录必须分配给该销售组织;

在客户主记录中,最小限度的信息必须被维护;这些信息包括付款人角色相关的数据(例如,地址,统御科目);你也应该在这里存储公司间Billing使用的货币;

公司代码层的数据在交货公司创建;

销售范围层数据连同公司间Billing的销售组织单元一起维护(sales organization IV,distribution channel IV, division IV);

内部发票中的条件Conditions in Internal Invoice

内部发票中的条件类型PR00显示了Billing给最终客户的金额,它作为信息条目并且是非激活的;

内部Billing激活的价格由条件类型IV01提供;它通过参考条件类型PI01来确定并因此是交货公司需要从定购公司收到的价值;

对于交货公司,条件类型IV01表示收入;成本通过物料的移动平均价提供;

内部发票中的定价程序Pricing Procedure in Internal Invoice

在内部发票中,系统使用一个计算程序(标准版本是ICAA01),不同于销售订单和客户Billing凭证中的计算程序;这里,条件类型PI01被条件类型IV01取代;

IV01,与PI01相反,不被标记为统计值;

通过在条件类型IV01的定义中定义对条件类型PI01的参考,你最终为两个条件类型得到相同的条件值;这里条件PI01代表定购公司的成本,而IV01代表交货公司的收入;为公司间Billing使用不同的条件类型对于确保数据正确地传送到财务决算(CO-PA)是必要的;

内部发票中的计算程序确定与Billing类型中定义的凭证程序,销售范围以及客户主数据中存储的客户定价程序有关;用销售范围你可以查看为公司间Billing分配给交货工厂的销售单元;

第五处理步骤:记账发票接收 5th Process Step:Post Invoice Receipt

由发货公司(公司代码)发行给定购公司的发票必须在订单公司代码的财务会计中输入以使付款发生;这可以手工地操作;

跨公司销售处理可以建立以便在交货公司中创建一张内部发票会自动地生成在订单公司中一张接收发票的创建;

例如,可能在涉及的两个公司之间达成一个协议,对于由销售组织1000发行给销售组织2200的发票,立即会记账到订单公司中的供应商科目(公司代码2200);

自动记账到供应商科目Automatic Posting to Vendor Account

如果订单公司手工地输入接收发票,交货公司可以在输出类型RD00的帮助下打印处一张发票凭证,然后发送给付款人;

如果同意了自动发票接收,你必须使用SD输出控制功能来保证输出类型RD04在内部Billing中;在R3系统中,包含该输出类型的输出确定程序V40000分配给Billing类型IV;

自动记账到供应商科目开始于输出类型RD04被处理时;系统使用EDI输出类型INVOIC在FI变量中;对于有关必须的系统设置的描述(伙伴参数文件等),参考公司间Billing的实施指南;

为了便于应付款能够在订单公司的财务中记账,交货公司必须创建为供应商;

跨公司销售:配置清单Cross-Company Sales:Checklist for Customizing

为内部公司间Billing分配一个销售范围给供货工厂;

维护销售组织,分销渠道和供货工厂之间的分配;

分配客户给销售组织;

如果必要的话,在销售凭证类型中为内部公司间Billing维护Billing类型;

如果必要的话,维护为自动记账到供应商科目所必须的设置;

时间: 2024-10-11 00:24:52

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

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

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

SD从零开始01-02

SD从零开始1 SD中的组织结构 销售相关的组织结构: 销售组织Sales organization 分销渠道Distribution channel 产品组Division 销售区域Sales area 销售办公室Sales office 销售组Sales group 销售人员Salesperson 工厂Plant 库位Storage location 销售组织: 一个销售组织代表一个合法的销售实体: 一个销售组织只能分配给一个公司代码: 一个销售组织可以分配给多个工厂: 每个销售组织有自己的

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从零开始03-04

[原创]SD从零开始3 SD中的主数据 客户主数据Customer master(分层维护) 一般数据general data: 与销售和财务都有关,对所有的组织单元有效: 销售区域数据sales area data: 与销售有关,对各自的销售区域有效: 公司代码数据company code data: 与财务有关,对company code有效: MARK:如果修改了客户主数据,除了地址信息外,不会影响已经创建的凭证order,delivery,billing...): 物料主记录Materi

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

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

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 装运类型控制装运凭证中的元素并因此为装运描述了一个特殊的处理类型: 装运类型设置包括: 段确定类型(例如,自动段确定): 完成类型(例如,已装载的外向装运,内向装运): 处理控制(例如,使用一种运输方式的汇总装运): 服务水

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

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