1。请从"从通用文档读取"方法更改为灵活上传

2。 保存主数据更改

2。 再次将方法从> 灵活上传更改为从通用文档中读取

谢谢

Venkat

您好，Venkat-感谢您解决问题！

首先-按照小组报告的概念，"从通用文档中读取"确实支持灵活的上载。 因此，我认为"从通用文档中读取"是安全的选择。

此外，在此期间，我尝试更改合并单位主数据参数（而不是数据收集部分）。 我观察到的是（虽然这可能绝对是愚蠢的观察），合并分类帐的会计年度变式（Y1-EUR）和公司代码的会计年度变式（与合并单元关联）在确定要合并哪个合并单元中起一定作用 即使所有这些都在安装了组报告的同一个S/4盒中也没有。

我正在对此进行实验。 在3个合并单元（6010，FR10和HR10）上获得了成功，但在其他合并单元（6020、6030和GR10）上陷入了困境。 共享所有会计年度变式的设置。 也许您可以从中得出一些结论，或者根据配置建议可行的设置/主数据更改。

赞赏的建议。

我不是在谈论安全方法，只是为了解决您的问题

1。 将方法更改为灵活上传并保存

2。 再次回到同一位置/屏幕，从"灵活上载"更改为"从UD读取"

尝试此方法，应将您的问题解决为"从UD读取"

祝你好运

谢谢

Venkat

Venkat无法解决问题。 根据您的建议，尝试了两次。

让我们考虑一个场景：为了节省时间，在年底，我们考虑为CU激活灵活上载。 通过灵活的上传方法上传数据。 现在，我们要将上载方法从"灵活上载"更改为"从通用文档读取"。 对于相同的全局参数设置，它如何工作？

您曾经尝试过吗？

感谢您的回答。

是的，FYV是CU的关键

公司/交易伙伴是CU，并且公司已包含您的公司代码

在OBY6中具有FSV的公司代码

谢谢

Venkat

确认您的回复，Venkat。

您能否从小组报告的实施经验中分享有关您如何计划CU的FYV/公司代码FYV的详细信息，考虑到不同的本国货币和具有不同CoA的不同的FYV，而这些CU和公司代码中的每一个都与组相同 报告。