[AIFA] Add new object type

[Smartynkov]

No description provided.

[GuilhermeSaraiva96]

Thank you for your AFF! I have a few questions and some minor comments :)

[GuilhermeSaraiva96]

Suggested change

	field_name TYPE c LENGTH 255,
	name TYPE c LENGTH 255,

[GuilhermeSaraiva96]

Is this length correct? 255

[Smartynkov]

Its string now.

[Smartynkov]

IN the future it will be field path. In case we have a deep structure with many substructures the path will be longer than char 40.

[Smartynkov]

Hi, we had a long discussion with a team about changes with Action file format and here is the summary:

We need number id because it's a key field for our table and its shouldn't be calculated automatically. Earlier it was a key and an order number of a check, we decided to spilt t up and now number field isn't about an order of a check and just a key field. we have a new field for the order, and it will be defined by the order of a check in the table on the UI we will add order changeable to the table for that to happen.

Also, there was some discussion about 'number' as a name for this key field on the UI and we think it's not showing what is this field is about. We propose name 'numeric_id', but we are also opened for the discussion.

[schneidermic0]

Thanks for your proposals, @Smartynkov. @GuilhermeSaraiva96 asked me to review the changes, too. I have added some questions and comments.

I guess an example object would also help to understand your use case even better.

[albertmink]

Observations related to recent README updates: @schneidermic0 this section title is generated from the current SVAL object. Merging the pr then may lead to uncorrect README as the SVAL will be checked much later in our process.

[schneidermic0]

Yes, I agree. I don't see a simple way to improve this, do you?

[albertmink]

More generic README outside the ABAP System 😉

[schneidermic0]

Yeah, on the other hand, I think it is helpful to see a meaningful name (even if it is not 100% correct and might be updated in the future) instead of having none.

[GuilhermeSaraiva96]

Hi, we had a long discussion with a team about changes with Action file format and here is the summary:

We need number id because it's a key field for our table and its shouldn't be calculated automatically. Earlier it was a key and an order number of a check, we decided to spilt t up and now number field isn't about an order of a check and just a key field. we have a new field for the order, and it will be defined by the order of a check in the table on the UI we will add order changeable to the table for that to happen.

Also, there was some discussion about 'number' as a name for this key field on the UI and we think it's not showing what is this field is about. We propose name 'numeric_id', but we are also opened for the discussion.

Hi,

We have discussed this in our team. We have a few questions:
1.You mentioned that the key field is not calculated automatically. How will the user know what to write then? Does it have to be a random number so that it does not collide with the other ids?
2. Is the check field also a key field, together with numeric id?
3. What do you think of have that id as a textual id instead of a number? It would be kind of a normal id, so that it also has some meaning and makes sense to the user

[D047539]

Hi, we had a long discussion with a team about changes with Action file format and here is the summary:
We need number id because it's a key field for our table and its shouldn't be calculated automatically. Earlier it was a key and an order number of a check, we decided to spilt t up and now number field isn't about an order of a check and just a key field. we have a new field for the order, and it will be defined by the order of a check in the table on the UI we will add order changeable to the table for that to happen.
Also, there was some discussion about 'number' as a name for this key field on the UI and we think it's not showing what is this field is about. We propose name 'numeric_id', but we are also opened for the discussion.

Hi,

We have discussed this in our team. We have a few questions: 1.You mentioned that the key field is not calculated automatically. How will the user know what to write then? Does it have to be a random number so that it does not collide with the other ids? 2. Is the check field also a key field, together with numeric id? 3. What do you think of have that id as a textual id instead of a number? It would be kind of a normal id, so that it also has some meaning and makes sense to the user

Hi,
I will attempt to answer the questions, but I recommend scheduling a brief meeting to discuss them further.
Regarding question 1: In the past, the customer would enter a sequence number that also functioned as an identification number. We now aim to split this dual-purpose by separating the sequence number from the identification number. Consequently, the customer will now be required to input a unique 3-digit identification number.
To question 2: No, the check field is not part of the key because it can be assigned multiple times with different validation parameters.
To question 3: Because this is legacy functionality, and the number is already included in the key, we are unable to make changes to it. Moreover, some existing tables have rather lengthy keys, which unfortunately limits the available space for using text fields as keys.

[GuilhermeSaraiva96]

Hi, we had a long discussion with a team about changes with Action file format and here is the summary:
We need number id because it's a key field for our table and its shouldn't be calculated automatically. Earlier it was a key and an order number of a check, we decided to spilt t up and now number field isn't about an order of a check and just a key field. we have a new field for the order, and it will be defined by the order of a check in the table on the UI we will add order changeable to the table for that to happen.
Also, there was some discussion about 'number' as a name for this key field on the UI and we think it's not showing what is this field is about. We propose name 'numeric_id', but we are also opened for the discussion.

Hi,
We have discussed this in our team. We have a few questions: 1.You mentioned that the key field is not calculated automatically. How will the user know what to write then? Does it have to be a random number so that it does not collide with the other ids? 2. Is the check field also a key field, together with numeric id? 3. What do you think of have that id as a textual id instead of a number? It would be kind of a normal id, so that it also has some meaning and makes sense to the user

Hi, I will attempt to answer the questions, but I recommend scheduling a brief meeting to discuss them further. Regarding question 1: In the past, the customer would enter a sequence number that also functioned as an identification number. We now aim to split this dual-purpose by separating the sequence number from the identification number. Consequently, the customer will now be required to input a unique 3-digit identification number. To question 2: No, the check field is not part of the key because it can be assigned multiple times with different validation parameters. To question 3: Because this is legacy functionality, and the number is already included in the key, we are unable to make changes to it. Moreover, some existing tables have rather lengthy keys, which unfortunately limits the available space for using text fields as keys.

I will schedule a brief meeting with us and Michael then.
To question 2: the check could still be part of the key. Basically, the check would be key 1 and to separate the entries with different validation parameters, you could use this numeric_id as a second key.
To question 3: I hope I understood the problem well. Could it be that the new values could still be textual, and the old ones stay as numeric? The datatype would basically be string, so both types are supported.
Since you are the experts of the domain and we are not, sometimes we oversee details or present solutions that are not feasible. We are insisting on this topic because it we think it could be improved, maybe it just cannot :)