on 06-10-2010 6:02 PM
和大家交流一个问题。
对客户清账时,如果同时出现以下情况:
1. 被清的未清项是带有分支机构的总部帐户;
2. 全额付款,即付款金额=未清项金额。
那么,清账时,贷方不会自动带出分支机构,而是直接过账到总部帐户上。在模拟总分类帐时就可以看到这一现象。
而如果付款金额<>未清项金额,即只付一部分款项时,是可以带出分支机构的。
在英文论坛中,看到也有人提类似问题,但无人给出有效的答案:
F-28 Transaction
Posted: Apr 2, 2009 10:03 AM
In F-28 Transaction while posting full payment the branch code is not appearing while doing the simulation.But in case of partial clearing the branch code is appearing.
...
希望与有兴趣的人共同研究。
Hi 您好!
您所报的现象是一个标准的式样。原因是对同一个vendor,你可以手动输入多个支社,所以当你对一张凭证做partial payment的时候,支社是1:1的关系,所以新生成的partial payment传票可以从被clear的传票上集成BSEG-FILKD。
可是当你做全额clearing的时候,可能会有多张凭证一起被clear,而且在这些张被clear的凭证上可能有不同的支社,这样系统就不知道怎么更新BSEG-FILKD,所以对于全额的clear系统不会更新BSEG-FILKD。
建议你做一下,是否您的要求能够利用clearing rule来实现(在T-cd:OBIA and OBIB里做customizing for
BSEG-FILKD)。
如果不成功,你可以试着create 一个 sort key ,在这个sort key 里定义 FILKD field,然后update这个sort key到FS00的G/Laccount master里,然后定义ZUONR在OBIA, 最后定义OBIB,这样当你用这个G/L account做clearing的时候系统应该就会update BSEG-FILKD的值到clearing item 里面。
希望以上信息对你有帮助!
Best Regards
Gladys
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
谢谢回复。很有帮助。我们已经用clearing rule的方式测试成功。但接下来还要进一步考虑对于已经形成的凭证的u201C修复u201D的问题。
不过,我仍然对SAP的这一设计持有疑虑:
u201C做全额clearing的时候,可能会有多张凭证一起被clear,而且在这些张被clear的凭证上可能有不同的支社,这样系统就不知道怎么更新BSEG-FILKD...u201D
以对供应商付款为例,一般形成如下凭证:
Dr: 供应商
Cr: 银行存款
如果说借方不知道怎么更新BSEG-FILKD,那是基于这样一种前提假设:不管清了多少个支社的发票,借方要压缩到一行。
事实上,这只是为了技术上的便利。应该这样设计才好:如果有多个支社的发票被清掉,系统自动形成多个借方行u2014u2014这是理所当然的,为什么一定要去设个清账规则才行呢?在业务实践中,用户非常喜欢通过FK10N去细查明细,然后按照支社分类汇总。SAP的设计人员也应该考虑到用户的实践。
Dr: 供应商总部 - 支社1
Dr: 供应商总部 - 支社2
Dr: 供应商总部 - 支社3
...
Cr: 银行存款
Edited by: Linux Gao on Jun 18, 2010 2:32 AM
您好!
通常客户会同时clear很多张凭证(上百张是很普通的),这样如果在clearing 凭证上同样也要生成上百条line items的话,会有performance的问题,而且还会导致short dump,所以SAP采取了summarize这些条line items,算出balance,生成clearing line items(即尽可能的减少clearing items的数量)。
那么如何做这个summary,SAP定义了一个structure:KONTAB_1ST,在这个structure里面包括了一些key fields, 如果在被clear的items里,这些key fields 里的值都一样的话,就会被算出他们的balance, 然后生成一条line item。请参考note:69767.按照客户的需要和从财务业务观点来看, BSEG-FILKD没有必要被看成是clearing时的key field,就没有被包括在KONTAB_1ST之内,所以很遗憾您所希望的design目前为止不能实现。
希望上面的解释对您有帮助!
Gladys
User | Count |
---|---|
91 | |
8 | |
7 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.