Avoid read-only fields from draft table

[Juwin]

Hi,

Consider this scenario:

I have a table ZTABLE with 5 fields. I have created an entity view ZIVIEW with all those fields and then some fields from other tables using foreign key relationships (e.g. other field attributes or text descriptions). I have created a behavior definition ZIVIEW for entity the view and marked all the fields from other tables as static read-only, since the intention of the behavior is to just allow user to maintain fields from ZTABLE. Since there are more fields in the view ZIVIEW than in the ZTABLE, I have provided explicit mapping of field names from the view to the table.

Now, when I try to create the draft table for this ZIVIEW, the table is created with exact replica of fields from ZIVIEW. My question is, when there are static read-only fields in the view, why are they still being included in the draft table? Shouldn't the draft table be a replica of the persistent table and not the view. Is there a way to only include the fields that are editable in the draft table? A draft table should need to store only what the user has typed in and not yet saved to active version, isn't it?

Tutorial link for reference

Practical problems:

When the draft table is generated from behavior definition using the Quick Fix tool, the fields from foreign key relations present in ZIVEW refer to the original data elements from the foreign tables. Often in S/4HANA Public Cloud, the top view used for foreign relation is released for use, but not the original table or the data element. Thus, the draft table cannot be activated until those data elements are replaced with native data types.

The fields brought in by foreign key relations are just informational to the user. There may be requirements to add more such informational fields to ZIVIEW in the future. But, every-time a new field is added to ZIVIEW, draft table has to be regenerated and activated, even-though the field is non-editable to the user.

Thanks

[TamasFodor]

Hi,

We helped you to accept the answer, since there were no updates after a few days. You can unaccept it anytime if you have further questions.

Kind regards,

Tamas

SAP Community Topic Expert

[MattDion · Accepted solution]

Hi Juwin,

By 'foreign key relationships', I assume you are referring to associations, correct?

If yes, then I would be doing the following:

1. Remove the association's fields from the entity view, and just expose the association itself
2. Rebuild the draft table (should only have the fields that can be maintained at this point)
3. Add the fields in the projection view instead

The fields will be read-only by default, so you shouldn't need to adjust the behavior projection, but you can also add field specific feature controls in the behavior projection if necessary.

Regards,

Matt

[ReinholdK]

Hello,

could you please share your table, entity view, and behavior definition in order to better understand the problem?

Regards

Reinhold