SD从零开始38-40

[原创]SD从零开始38 创建Billing Document

根据需要BillingBilling On Request

你可以通过手工输入凭证的号码(订单号码和Delivery note,依赖于你想要执行订单相关的还是交货相关的Billing)明确地指定哪些交易将要Billing;

如果Billing无法产生,例如因为一个billing block,系统会发行一个错误日志;

到4.5版本,在为deliveries或ordersBilling时你还可以选择单个的items或者items的部分数量来Billing;要这样做你需要选择Billing中的item selection功能;

MARK:在delivery-relatedBilling中,你只能修改具有billing relevance K的item category的item quantities;

处理Billing Due Lists

你通常不会为每个交易单独Billing;你更愿意执行周期性的集中Billing(例如,集中通过发货过账);

如果你使用Billing due list,输入选择条件,例如,sold-to party,billing date,destination country;系统以选择条件为基础合并要Billing的交易;

在选择中,你还可以决定billing due list是否只包含order-ralated,delivery-related或者both的凭证;

保存后,你可以显示日志来确定哪些Billing从Billing due list中创建了以及是否发生了什么错误;

你可以在模拟模式下处理billing due list;系统显示billing document而不保存凭证;包含错误的交易用相应的处理状态标明;

在特定的日期创建发票Creating Invoices on Specific Dates

你可以周期性地处理发票;所有在某一天到期应该Billing的deliveries能以合并到一次集中开发票;

要这样做,你必须首先:

使用特定的规则在工厂日历中维护单独的Billing日期;

在付款者的客户主记录中输入工厂日历(Billing schedule on billing screen);

当你创建一张凭证,系统从工厂日历中复制下一Billing日期到当前的凭证中作为Billing日期;

MARK:日历是client独立的;

后台执行BillingBilling in the Background

你可能决定使用一个后台作业来创建发票,因为这样是实用的和有效率的;你可以用以下方式自动运行后台作业:

Periodically(例如,每个星期一下午2点);

At a specific time(例如,7月09号上午8点);

系统可以将billing due list分割到多个后台作业并同时启动它们;通过这种方式,你可以通过运行多处理器更好地利用你的硬件;

如果你不需要日志或者详细列表,SAP推荐你在选择屏幕上不选择这些选项;这会相当地提高性能;

取消集中Billing运行Cancellation of Collective Billing Run

到4.5版本时,系统提供了功能使你能够取消集中Billing运行;

这会取消一次集中运行中的所有billing document;取消的billing document集合在集中处理类型S里的一个集中处理号码中并且可以在Billing日志中显示;

然后你可以为取消了Billing的preceding document重新Billing;

只有具有正确权限的用户才可以取消集中运行;

为了取消集中Billing运行,选择:

Billing -> Information system -> Billing document -> Log of Collective Run -> Documents -> Reverse all

通用Billing接口General Billing Interface

使用通用Billing接口,你可以为外部凭证在R/3系统中开发票(那比如,不是在R/3系统中创建的订单和交货单);

要这样做,你必须首先:

准备数据到一个特定格式的顺序文件(sequential file of specified format);

指定最少必需的字段从数据记录填充;

剩余的Billing需要的字段或者通过顺序文件的数据记录指定或者在R/3系统中决定(可选的字段);

例如:

必须的字段:Customer Master,Sales Organization…..

可选的字段:Material Master,Price Componentsl….

外部参考号码可以在接口中输入(例如外部交货号或者外部订单号);

[原创] SD从零开始39 结算的类型(Types of seetlements)

集中Billing--Collective Biling Document

有一个规则是,系统尝试合并所有兼容的交易到一张billing document;

在SAP R/3系统中,可以在同一张Billing中包含订单相关的和交货相关的Items;

自动发票分割Automatic Invoice Split

如果header partners或者header fields中数据不相同,系统将自动执行发票分割;

Billing中所有的header partner和header fields都能够导致发票分割;

例如:

两张订单中的付款条件不同;

依赖于item的发票分割Item-Dependent Invoice Split

系统管理员也可以在配置中为复制控制定义附加的分割条件来防止系统合并销售凭证到一张Billing中;

例如:基于物料分组或者利润中心分割;

字段VBRK-ZUKRI用于在billing header中存储这些附加的分割条件;

导致分割的字段,显示在split analysis中;

单个Billing--Individual Billing Documents

你可以设置系统为每张销售凭证创建一张Billing;

要这样做,在copying control的配置中选择data transfer routine 3(参考凭证的号码设置在字段VBRK-ZUKRI中);

发票列表Invoice list

发票列表包含许多的Billing Document(发票,贷项/借项凭证)并且可以在某一天或者某一期间发送给付款方;

系统管理员需要在SD的配置中维护以下数据:

如果你有协议的代理折扣(factoring discount),维护条件类型RL00(factoring discount)以及条件类型MW15;

要包含在一张invoice中的每个billing type都必须分配一个invoice list type;SAP R/3标准系统包含两种invoice list type:

LR用于invoices和debit memos;

LG用于credit memos;

你还需要维护一下的主数据:

定义一个工厂日历,它指定了发票列表何时创建;在付款方的客户主记录中输入该工厂日历;

为付款方维护条件类型RL00的条件记录;

为条件类型LR00和RD01维护输出条件记录(你可以决定发票是在发票创建时还是当发票列表创建后发送给客户);

到4.5版本时,你可以取消发票列表;在factoring discount的案例中,会为FI创建一张相应的取消凭证;

[原创] SD从零开始40 特殊的业务交易

Billing计划Billing Plan

当处理一张订单,除了存储一个专一的Billing日期,你可以存储一个详细的带有几个Billing日期的Billing计划在销售凭证的item层次上;

到3.0E版本,你也可以在header层次定义一个Billing计划,这对分配给她的所有items都有效;这些header billing plans被分配给销售凭证类型;

周期性Billing经常用于租金和服务协议,为了周期性地在某一日期为总金额Billing;

里程碑Billing(Milestone billing)经常用于设备工程和建筑,为了在一个billing plan中将总金额的Billing分布到几个日期;

依赖于你正在处理的业务交易,系统会自动地建议两种billing plan types中的一种;

周期性Billing--Periodic Billing

周期性Billing可用于,例如,包括租赁合同的交易;

然后系统中存储的合同数据可用做创建billing plan的基础;

开始和结束日期定义了billing plan的期间;如果可能的话,它们从合同数据中获取;也许你决定不设置结束日期(如果期间是无限的),在这种情形下,时间轴(horizon)上可延伸新的日期(horizon指定billing plan中设置的结算区间的数量);

你可以直接在billing plan中创建新的日期或者使用报表RVFPLA01;你应该安排该report定期运行,因为当单个的结算区间Billing后不会自动形成新的日期;

你能够使用billing dates来决定billing何时以及多久执行,例如,在每月的第一天或最后一天;

里程碑BillingMilestone Billing

在里程碑Billing中,要Billing的总价值按照某些规则分布到单个的日期中;

你可以为每个billing plan输入你需要的任意多的日期;

Billing plan dates可以blocked for billing;

在某些里程碑Billing已经创建之后发生的改变在剩余的billing plan dates之间分配;对于已经创建的Billing需要的剩余金额包含在final invoice中;

与里程碑Billing相联系的Billing计划--Billing Plan with Link to Milestone Billing

里程碑Billing的一个典型例子是设备工程和建筑的项目Billing;这些项目通常包含一连串的里程碑,代表一个项目不同阶段的完成;

在SAP R/3中,里程碑连同计划和实际的项目数据存储在一个网络中;里程碑被分配给billing plan dates并且blocked for blling直到里程碑被确认完成;

在里程碑Billing计划中,现在你可以控制一个billing date是否是:

一个固定的日期;

总是需要用实际的里程碑日期来更新;

如果产品在计划的billing date之前完成,则用实际的里程碑日期更新;

里程碑Billing中的凭证流程Document Flow in Milestone Billing

系统为每个billing date在billing index中创建一个条目;这意味着你可以在billing index中为该milestone billing在指定的billing date找到一个条目;这种情形下,billing以order-related形式执行;

当你创建一张billing document,系统更新Billing计划日期的状态;

已经Billing的日期在billing plan中不可再更改;

你可以使用document flow来显示已经存在的Billing;

决定Billing价值Determining Billing Value

可以为每个billing plan date创建一个billing rule;这些规则确定特定日期将要Billing的价值如何决定;

这允许你定义,例如,是否一个固定的数量或者总量的一个百分比将会Billing;

系统还可以决定将要Billing的数量是否作为final invoice,那样的话到那时为止没有Billing的日期也必须被考虑;

在定价中,为特殊的条件类型创建了条件记录,可以为它(例如处理租金成本)定义月度的价格;这允许价值逐月Billing;

Billing计划的配置Customizing for Billing Plans

Billing plan type从document item category和relevance for billing决定;

Date descriptions表示billing plan中相应billing dates的文本描述,例如,0003 for contract completion,0005 for assembly;它们对于控制不重要;

定义的Date categories在billing date层次有控制功能;例如,它们决定哪个billing rule用来结算该日期,该billing date是否是一个固定日期以及是否为该日期设置了一个billing block;

Date rules在billing plan中是必须的,目的是定义开始日期和结束日期,以及确定相应的billing dates(例如,每月结束前2天);

每个日期决定规则(date determination rule)的基础是一个基准日期加上一个定义的周期(period);

带有相应的控制参数的Periodic billing和milestone billing的区别通过biling plan type来实现;

Date proposal专门用于milestone billing;它决定一个日期列表作为订单处理中的日期确定的参考;

SD/FI中的预付定金处理Down Payment Processing in SD/FI

预付定金通常在处理设备工程和建筑或者资本性货物时与客户商定的;

预付定金已经在SD销售订单中创建;

在相应的到期日,一个down payment request(SD billing document)发送给客户;

预付定金请求(SD)自动作为一个预付定金请求(posted as a noted item)记账到财务会计(FI);该Item具有特殊的G/L标记F,这确保该过账是统计性的;记账到一个不同的统御科目,这允许你区分开预付定金请求和其他的应收账款;

当为一笔预付定金记账一笔收入付款时,该收入付款指派给该预付定金请求;预付的总额也指派给销售订单;该item具有特殊的G/L标记A;

当处理partial/final invoices时,已产生的预付定金转换为待清的预付定金;在FI中,预付定金从特殊统御科目中扣除并输入到标准的统御科目;然后待清的预付定金作为客户的未清项出现并且减少应收总额;

销售订单中的预付定金协议Down Payment Agreements in the Sales Order

预付定金处理利用billing plan功能执行;

一个或多个预付定金协议能够作为一个日期存储在billing plan中;

协议的预付定金价值可以输入一个固定总额或者该item价值的一个百分比;

控制通过billing rule执行:

Billing rule 4:Down payment for percentage milestone billing;

Billing rule 5: Down payment for value-related milestone billing;

预付定金协议可以直接指派给一个item或者可以定义为对订单中的所有items有效;

MARK:特殊条件类型AZWR在销售凭证中用于预付定金items,而不是通常的条件类型PR00;Condition category“e”和calculation rule“B”(固定金额)指派给条件类型AZWR;当条件类型AZWR决定了,所有其他的条件类型都设置为非激活;

预付定金请求Down Payment Request

只要预付定金的billing date(in the billing plan)已经到达,系统创建一张预付定金发票并且发送到客户;billing type FAZ用来创建预付定金请求;

该预付定金请求可以创建如下:

自动地通过billing due list processing集中运行,或者

通过事务Create billing document明确地指定订单号码;

当预付定金请求创建时,税会自动确定和显示;

FI中的预付定金请求自动地从SD中的预付定金请求创建;

你可以通过销售订单的凭证流来查看SD和FI中创建的预付定金请求;

预付定金的收入付款Incoming payment for down payment

在预付定金请求结算时,在FI中,特别总账标志A显示该收入付款为预付定金;

你可以从未清的请求中选择一笔收入付款并且选择“Create down payment”按钮将它指派给一个处理;

你可以通过特殊总账标志A查看应收科目的未清项中的预付定金;

在SD订单的凭证流中,预付定金请求相应地设置为“cleared”;

部分开发票-全部结算Partial Invoice-Full Settlement

对于partial and final invoices,产生的预付定金传送到billing documenst作为待清的预付定金;

当发票打印时,应该清账的预付定金金额显示并可以从应收中扣除;用其他的话说,清账自动在发票打印时执行;

部分开发票-按比例结算Partial Invoice-Proportional Settlement

在部分开发票中,待清的预付定金的金额可以修改(通过在item的定价屏幕上修改条件类型AZWR的金额);

在这种清况,待清的最大金额是收到的预付定金减去已经清账的预付定金;

在final invoicing中,到那时止没有清账的预付定金都会被考虑;

分期付款方式Installment plans

分期付款方式允许客户分期支付;仅为所有的分期付款产生一张Billing;打印的发票基于该billing document创建并且包括一列单个的付款日期和准确金额;

每个分期付款的支付创建一条应收科目行项目记账到FI;

你必须在配置中定义分期付款支付的条件;

对于分期付款支付条件,你必须用百分比指定每期的数量和金额以及每期支付的付款条件;当你用分期付款支付条件记账一张发票,系统会在会计凭证中基于这些规范产生适当数目的记账;

时间: 2024-12-24 23:05:10

SD从零开始38-40的相关文章

SD从零开始41-44

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

SD从零开始45-46

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

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 每个员工都可以列出他们已经创建的不完全的销售订单:他们还可以在选择屏幕上显示为某个特定的步骤冻结的某些凭证,例如因不完全而冻结不能装运的所有凭证的

SD从零开始01-02

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

SD从零开始03-04

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