探索HFM系统PA模型的底层设计逻辑

18 篇文章 18 订阅
15 篇文章 3 订阅

               图片

今天看了公司CEO写给全体员工的寄语中,有一段很受用。这里引用下,以此激励自己:

接地气,感知闭环;

不着急,持续使劲;

不怕难,把本事变大;

不自大,把EGO变小。

如果说有一种态度能贯穿时间的经线,并对2021有所启示的话,那就用“ 真实”吧。

2021更真实,做真实的自己。

不设限,不自大,脚踏实地,拼搏进取,2021加油!!!

---------------------------------------------------------

正文开始:

图片      

       PA的全称叫PLUGACCOUNT,中文翻译叫插式账户,笔者认为叫差额科目会好理解点。在实际使用中叫“抵消科目“会更加符合业务场景。

看一段官方文档的解释:

    A plug account is an account that, when eliminations are completed, stores the difference between two intercompany accounts in the Elimination Value dimension. A plug account can be set up as an ICP account. For a plug account to be detailed by ICP, set the IsICP metadata attribute to Y or R so the system writes eliminations to the corresponding ICP member. If you do not want a plug account to be detailed by ICP, set the IsICP attribute to N so the system writes eliminations to [ICP None].

笔者认为,HFM中的PA模型,是这个产品设计的精髓之一,理由有:

1、配置简单

2、无需写任何代码

3、抵消准确

4、抵消差异清晰可追溯

图片

PA模型的默认抵消维度是在Value维度的成员:[Elimination],在value维度中的如下位置:

图片

举个例子:

有如下组织架构:

图片

PA02模型如下:

图片

场景描述:

A合并体下有B,C,D三家子公司,B,C往来如下:

B公司对C公司有应收股利(科目编码:113101)100元,C公司对B公司有应付股利(科目编码:223201)100元。

系统层面解释:在合并层面(A)来看,B,C两家子公司之间的往来是需要抵消的,即:

在B的Elimination层面需要将B对C的应收股利抵消掉,即在HFM中,抵消分录如下:

图片

在C的Elimination层面需要将C对B的应付股利抵消掉,即在HFM中,抵消分录如下:

图片

业务层面解释:

图片

备注:如果抵消有差异,比如B对C的应收股利是100,C对B的应付股利是120,那么在elimination层面对于应收应付科目都是全额抵消的,差额20是在PA02上,对于差额20的处理可根据实际情况灵活处理。

图片

上面的例子是最基本的场景,实体都是在同一个节点。比较复杂的场景:

假设存在如下架构:

图片

现在B和E两家公司有往来,在合并A层面是需要抵消掉的,所以抵消分录应该是在B(实体B,ICP:E)的elimination层面,和D(实体D,ICP:B)的elimination层面,而不是在E(实体E,ICP:B)的elimination层面。

这就是PA模型自动抵消的巧妙之处,任何架构下(前提是架构要收敛,即可以找到两个实体的共同父项)的任何两个实体之间的往来,都能准确抵消到你要的value维度上,而只需简单的配置,无需任何代码即可实现。

笔者认为,这背后的逻辑实现关键的地方在于如何确定两个往来实体的位置和合同父项,以及共同父项的下一级:

图片

关键在于两点:

找到B实体的树的路径:A-B

找到C实体的树的路径:A-D-E

所以抵消的结果应该是在共同父项A的下面两个节点B、D的elimination上。

假设执行合并时,运行E-D-A这棵树,

关于上图,笔者理解:

当执行E实体相关的计算时,会判断与E实体有往来关系的ICP,假设扫描到发现有B的往来公司,如果发现E和B不在同一个节点下,那么在E的层面不抵消,继续贡献到D,并且将E和B两个节点之间的路径存储起来,当执行到D时依次逻辑进行判断,发现D,B是在同一合并层面,即可进行抵消。

------------------------begin--------------------------

如果用Java代码来实现,笔者认为也不是很难。

我们用sql来实现获取两个节点的共同父项的下一级节点,这是在一个论坛上和网友一起讨论得出的较好的实现结果:

组织结构及相关说明如下:

图片

Sql实现如下:

--将上面的树构造sql语句

图片

--sql实现如下

图片

上面的sql语句笔者对此不作解释。

--------------end--------------------------------

图片

想要实现无代码化进行合并抵消,需要进行如下几点配置:

            1、account配置

        图片

            2、application设置

       图片

            3、entity必须是ICP

        图片

全文完。

  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值