|
Posted by 鸿烈 on 2004-12-27 11:13 下午
|
事务代码FD32/FD33，输入credit acount和credit control area，选择Status，回车。
您将看到几个灰色的字段——
Receivables、Special liabil、Sales value和Credit exposure，可您知道它们的真实含义是什么吗？
定制IMG－－>Financial accounting－－>Accounts Receivable and Accounts Payable－－>Credit Management－－>Credit account－－>Define preliminary settings for Credit Management，您可以定义贵公司信用管理的业务范围。如果您的信用管理范围口径涵盖“销售订单阶段＋交付阶段＋出票阶段”，那么这将是完整的信用管理，在这种场景下——
Credit exposure，信用曝露额，永远服从公式 credit exposure = accounts receivable + special liabilities + sales value。其中——
accounts receivable：应收帐款余额，指出具了发票的总金额扣减顾客付款之后的应收帐款余额；
special liabilities：特殊债务，我们只遇到一种情况，预收款（customer down payment）。没有交货就预先收款，财务上当然视为我方债务，由于是债务，这个字段永远以负值表示；
Sales value：应理解为open sales value，并不是会计意义上的“因为开具发票而实现的销售收入”。在完整信用管理场景下，这个字段的理解如下——
open sales value＝open order value + open delivery value + open billing value；
open order value：建立了销售订单，但尚未交付的价值；
open delivery value：建立了出埠交付单（outbound delivery note），但尚未出具发票的价值。“交付”以VL01N创建交付单为唯一标志，与是否过账出货无关；
open billing value：出具了发票，但由于某种不正常的原因，发票的价值没有release into accounting从而没有生成会计凭证，既然连会计凭证没有，自然产生不了应收账款的余额了。
有经验的SD顾问都应知道，open billing绝对是荒唐的，其直接原因是没有release into accounting，而不能释放进入会计的原因，不外乎有四个——
1） VKOA定制不全面；
2） 新的财务年度，有关会计凭证的新年号码范围未能及时定制；
3） 不恰当地定制了revenue recognition；
4） 系统中缺乏欧元（euro）与其他货币（包括本位货币）之间的汇率关系。
open sales value记录于S066，open delivery value和open billing value记录于S067，似乎4.6C版本中两个信息结构的更新机制都是同步。
作业者如果对credit exposure或者其三个细目的余额有所不认同，一般可以用SE38调用标准程式RVKRED77运行有关的信用账户，刷新后再重新进入FD33观察。
常常有这种疑虑——“业务上这个买主早就跟咱们银货两清、互不相欠，为什么它还存在一定的credit exposure”？某些行业解决方案可能有这个问题，找 SAP AG support解决。如果排除这种可能性，用RVKRED77运行后还是如此，那就肯定是——“实务已经执行完毕，可实务的全部动作并没有完全在SAP系统中体现，肯定是那个SAP作业流程疏漏了，补上的干活！”
S066和S067的表格，只要获得了SAP的access key，可以修改其值，修改后存盘，进入FD33可以观察到credit exposure或者其三个子项目的余额有所变化。然而，问题在于——
有朝一日谁“不小心”再次执行RVKRED77，系统一刷新，FD33的信用曝露额又回归到原值。这说明——
消弭系统的数据不真实性最终只能补足系统本身的流程疏漏，任何改表最终都是徒劳。
本人今年三月份的经验，权当开胃餐。
|
|
|
|
Posted by york on 2004-12-27 11:22 下午
|
|
支持鸿烈，真正的原创，希望版主给此帖加精华！
|
|
|
|
Posted by baig on 2004-12-28 12:36 下午
|
|
不错不错,好香呀,值得回味
|
|
|
|
Posted by wangtim on 2004-12-29 02:16 下午
|
顶，狂顶！
但小弟还想虚心请教一事，对于
"有朝一日谁“不小心”再次执行RVKRED77，系统一刷新，FD33的信用曝露额又回归到原值。这说明——
消弭系统的数据不真实性最终只能补足系统本身的流程疏漏，任何改表最终都是徒劳。"
我们如何处理？
|
|
|
|
Posted by 鸿烈 on 2004-12-29 02:26 下午
|
正如帖子所述，在排除某些行业解决方案的BUG因素之后，credit exposure余额就只剩下“未履行完SAP作业流程”一项了。您可以运行VA05观察还有哪些open order，运行VF05观察还有哪些open billing（当然是荒唐的场景），运行VF04之Delivery-related billing观察还有哪些交付单“该出票却没出票”从而掌握哪些open delivery。至于open accounts receivable，FD10N大约可以回答问题了吧。
不过，在执行VA05的时候，小心销售单据的状态。有关状态机制，本论坛上有本人的另一篇帖子，自己找找吧。
|
|
|
|
Posted by 思 on 2005-01-13 12:20 下午
|
|
好贴
|
|
|
|
Posted by 吃猫鼠 on 2005-01-25 09:37 上午
|
|
不错，看来楼主也经历过SAP计算信用出错的情况，我以前的公司出现过两三次，偶发性的，能过自己写的程序复算的确出错，SAP到现场或德国远程登陆也没发现问题，最后只有通过RVKRED77重算，当时再查notes时才发现sap在信用这块的bug其实挺多的
|
|
|
|
Posted by Bei Cat on 2005-11-21 01:39 下午
|
hao tie.
ding
|
|
|
|
Posted by jackfen on 2005-12-26 01:05 下午
|
ding,hao
|
|
|
|
Posted by arlong on 2006-06-01 01:15 下午
|
都是经验之谈啊，沿着前辈的道路学习中！！！
|
|
|
|
Posted by Benny2006 on 2006-06-02 05:06 下午
|
|
真是好贴
|
|
|
|
Posted by 黄金 on 2006-07-06 10:47 上午
|
|
经验之谈啊，沿着前辈的道路学习中！！！
|
|
|
|
Posted by jianshuigen on 2006-07-07 02:06 下午
|
|
也学习！！！！！！！！！！！！！
|
|
|
|
Posted by ali on 2006-07-07 05:00 下午
|
感谢楼主的无私精神!
我还想请教一下:为什么accounts receivable是负制值,而Sales value却是正值呢?按照你对Sales value的解释,我认为Sales value也应该取负值呀? 请赐教!!!
|
|
|
|
Posted by ali on 2006-07-07 05:00 下午
|
感谢楼主的无私精神!
我还想请教一下:为什么accounts receivable是负值,而Sales value却是正值呢?按照你对Sales value的解释,我认为Sales value也应该取负值呀? 请赐教!!!
|
|