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模型，是这个产品设计的精髓之一，理由有：
PA模型的默认抵消维度是在Value维度的成员：[Elimination]，在value维度中的如下位置：
|
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维度上，而只需简单的配置，无需任何代码即可实现。
笔者认为，这背后的逻辑实现关键的地方在于如何确定两个往来实体的位置和合同父项，以及共同父项的下一级：
所以抵消的结果应该是在共同父项A的下面两个节点B、D的elimination上。
当执行E实体相关的计算时，会判断与E实体有往来关系的ICP，假设扫描到发现有B的往来公司，如果发现E和B不在同一个节点下，那么在E的层面不抵消，继续贡献到D，并且将E和B两个节点之间的路径存储起来，当执行到D时依次逻辑进行判断，发现D,B是在同一合并层面，即可进行抵消。
------------------------begin--------------------------
我们用sql来实现获取两个节点的共同父项的下一级节点，这是在一个论坛上和网友一起讨论得出的较好的实现结果：
--------------end--------------------------------
想要实现无代码化进行合并抵消，需要进行如下几点配置：
