应付账款业务单位逻辑

账款业务单位逻辑"/>

应付账款业务单位逻辑

早上听同事讲公司在讨论延长在家办公。
感觉这个公司要倒了。

公务员的书又要拿起来翻翻了😭
说多了都是泪啊。

从我进这个公司，每次开大会的重要议题都会有一个cost saving。
虽然我已经有几年不参加这个开大会了。。。能逃就逃吧。
但是涨工资已经是不可能的了，就怕有一天公司要卷铺盖走司。。。

事情是这样的：逻辑设置好了后，业务发现偏差。
一个document被多年重复，因此会有不同的利润中心，（利润中心随时间变化，比如2018年之前叫AAA，2019之后叫123）。在这种情况下，报表只显示旧的利润中心。
一个document中有不同利润中心的不同amounts，大多数amount是定在123这个利润中心下的，但是在报表里显示的是234这个错误的利润中心。

• 事情到这里，我有个猜测，这个利润中心是BW没更新么？还是说这个利润中心没有设置time dependent?
  先来看评论：
  在测试过程中，发现一个可以改进的逻辑：对于业务单位来说，应收账款凭证的业务单位逻辑有需要改进的地方。

1. 总账/应收账款 凭证属于哪个会计年度需要被考虑。
   在FI里面，一个特定的凭证ID总是属于一个特定的会计年度。相同的凭证ID可能会出现在不同会计年度，出现很多次。因此，为了把应收账款凭证正确对应到总账凭证，这两个凭证的会计年度必须得一致。会计年度的技术名称是GJAHT。得把这个字段放到逻辑里。
2. 基于每个利润中心的总值计算，得基于“normal” 数量字段。
   很明显在当前的逻辑里，每个利润中心的总值计算是基于借debit和贷credit的值的。这就导致了0值的错误情况。为了正确计算利润中心总值，得选“normal”数量字段。
   “normal”值的技术名称是WRBTR。

讲了半天利润中心和业务单位。实际上在ERP里是在profit center下面：

业务单位就是个部门。
到这里，那就是对FI的ERP那块不了解了，需要去看书，嘎嘎嘎。。。
看所有的配置。
利润中心下面有个controlling area,还有Department,还有user responsible。
这些所有的概念都要懂，在哪里，怎么配置的也要知道。
然后就是业务，应收账款，应付账款，总账啥的。
都要知道。

现在没空管这个了，那来看AP（Accounts Payable)的底层逻辑：

client太多，先放到info source里面去了。

有好多没拉的字段，大概是从routine里面给的。
因为有个start routine和end routine.

先来看看这个转换谁改的：Transformation->Properties:
这里可以看到谁改的。

在Transformation->Extras->Display Generated program

Utilities->Versions->Version Management下面，还可以对比不同版本。

这里可以看到完整的程序。然而我比较版本的时候歇了，为啥只有一个版本？

这咋连SAP自己的版本都看不到？我哪里操作错误了？
也许就一个人改了？
唉，不知道。

不管了，从这个program来看下，毕竟我从来没从这里看过。以前都是开始routine,结束routine来看的。
我今天要来看看这个完整的传输程序里面都有啥。

3000多行，定义了800多行？
实现了2000多行？

有点乱，我还是放弃了，从开始例程来看：

开始例程

定义部分

实现部分：没啥东西

结束例程

定义部分


实现部分：还是很规范的

在这里连了GL的数据，给了AP的profit center和controlling area.
为啥AP的这个可以从GL出呢？

AP的抽取是从行项目来的。
GL的底层呢，一样的。

不过GL这个真是应有尽有啊。

这个是上面的建议，应收账款必须得和总账对应起来，这个逻辑其实我一窍不通。
但是他讲凭证编号对应的年度得一致，才能把本年度的应收账款和总账对应起来。
再回过头来看他的逻辑：

这种相同凭证出现在不同年度，是这样的：
一个凭证是这样的：

这个凭证出现在不同年份下：

然后逻辑是这样的。
不知道这个干啥的。

这个搞归档的，有空来看看。


说实话，里面东西还挺多，我如果不写这个，我也不会来看。
大的program里面一样的，多一些乱七八糟的定义。

今天先到这里了，明天来看上层。