Chinaunix首页 | 论坛 | 博客
  • 博客访问: 40012
  • 博文数量: 18
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 286
  • 用 户 组: 普通用户
  • 注册时间: 2013-09-16 21:41
个人简介

微信公众号:大话EPM 1、具有9年epm产品线(hyperion HFM+hyperion PLANNING)经验,尤其精通hyperion HFM产品。 2、针对不同规模的企业集团,具有丰富的合并报表业务方案、技术架构设计、规划与落地经验。3、具备很好的融合技术和业务落地的能力,具有从业务调研、方案设计、方案落地并交付的能力。

文章分类
文章存档

2021年(17)

2013年(1)

分类: IT职场

2021-07-28 12:10:01

            

今天看了公司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公司有应收股利(科目编码:113101100元,C公司对B公司有应付股利(科目编码:223201100元。

系统层面解释:在合并层面(A)来看,B,C两家子公司之间的往来是需要抵消的,即:在BElimination层面需要将BC的应收股利抵消掉,即在HFM中,抵消分录如下:

CElimination层面需要将CB的应付股利抵消掉,即在HFM中,抵消分录如下:

业务层面解释:

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

上面的例子是最基本的场景,实体都是在同一个节点。比较复杂的场景:假设存在如下架构:

现在BE两家公司有往来,在合并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的下面两个节点BDelimination上。
假设执行合并时,运行E-D-A这棵树,关于上图,
笔者理解:
当执行E实体相关的计算时,会判断与E实体有往来关系的ICP,假设扫描到发现有B的往来公司,如果发现EB不在同一个节点下,那么在E的层面不抵消,继续贡献到D,并且将EB两个节点之间的路径存储起来,当执行到D时依次逻辑进行判断,发现D,B是在同一合并层面,即可进行抵消。
------------------------begin--------------------------
如果用Java代码来实现,笔者认为也不是很难。
我们用sql来实现获取两个节点的共同父项的下一级节点,这是在一个论坛上和网友一起讨论得出的较好的实现结果:
组织结构及相关说明如下: