PROD_ROOT and PRD_ROOT

简介: PROD_ROOT and PRD_ROOT

one question regarding your include PRD_INCL_EEW_PS. It is registered for business context PRODUCT, which means once extension field is created in “Custom Fields” Fiori application, all database table which have this include will see the extension as well.

image.pngimage.pngWill the value of extension field be persisted to all those database tables?


I made a test by myself.

As first step, I list all 18 database tables which have included PRD_INCL_EEW_PS.

Then I type “1.7” as extension field value and save the change, and go to each table to check whether the value are there via SE16. The test result is listed below.


My question:


take table PRD_PROC and PRD_SALE for example, since semantically speaking they are not responsible to store product header level data but for sub node ( procurement and sales data ? ), why they still include the structure PRD_INCL_EEW_PS?

Among these 18 tables, some are really confusing. For example PRD_SALES and PROD_SALES. May I know the difference between them?

image.pngimage.png# answer The include PRD_INCL_EEW_PS is for all tables which contain data from table MARA. In the new Product BO model, we have separated the MARA fields in different BO nodes based on their semantic, as an example please see the active core entities I_Product and I_ProductSales:

Both CDS views select the data from active core table MARA but have a different field list. In the BOPF BO you will find the corresponding BO nodes I_PRODUCTWD (root node) and I_PRODUCTSALESWD (sales node). Here you will see in which draft database tables these data will be stored (PROD_ROOT & PROD_SALES). After activating a draft BO instance, these draft data will be merged in one single MARA entry. And due to this we have decided to use for all MARA relevant BO nodes (CDS views) the same include structure.image.pngSuch a field separation for table MARA & MARC is done for several BO nodes, the corresponding draft database tables are listed in your list. Due to a major change in the draft infrastructure, it was necessary to create complete new draft tables, that’s the reason why you found most tables twice, as example see PRD_ROOT & PROD_ROOT or PRD_SALES & PROD_SALES. The tables with the prefix PRD_ are obsolete meanwhile and will be deleted.



相关文章
|
10月前
|
存储 关系型数据库 MySQL
The user specified as a definer (‘root‘@‘%‘) does not exist
The user specified as a definer (‘root‘@‘%‘) does not exist
|
Shell 开发工具 Perl
写一个脚本/root/bin/sumid.sh,计算/etc/passwd 文件中的第10个用户和第20用户的ID之和
写一个脚本/root/bin/sumid.sh,计算/etc/passwd 文件中的第10个用户和第20用户的ID之和
67 1
|
关系型数据库 MySQL
The user specified as a definer (‘root‘@‘%‘) does not exist(已解决)
The user specified as a definer (‘root‘@‘%‘) does not exist(已解决)
572 0
The user specified as a definer (‘root‘@‘%‘) does not exist(已解决)
|
文字识别 Oracle 关系型数据库
Oracle rac重新执行root.sh脚本
Oracle rac重新执行root.sh脚本
833 0
|
Shell
ansible--user和group模块用户创建及删除
执行脚本增加用户[root@10-15-195-231 roles]#ansible test -a "/root/addappuser.sh ansible"addappuser.sh 为远端服务器上的脚本[root@10-15-195-231 ~]# cat addappuser.
5572 0
check_user_createdate.sh
在前面这篇文章Linux如何找出用户的创建时间里面讨论了查看用户创建时间的方法,后面自己尝试弄了一个脚本来检查所有用户创建时间脚本,当然更合理的应该叫检查所有用户的密码修改时间比较准确(因为这种方法有条件限制),期间和夕照讨论了一下如何用shell脚本实现,获益良多。
637 0
|
Oracle 关系型数据库 Linux
RHEL7.X安装12.2RAC时root.sh错误CLSRSC-400的解决方案
问题现象: [root@ora12c ghome]# /opt/oracle/ghome/root.sh Performing root user operation. The following environment variables are set as:     ORACLE_OWNER= grid     ORACLE_HOME=  /opt/oracle/ghome 。
7318 0