‎2009 Mar 26 12:34 PM
Good morning, Experts
We are debating the best method to replace hardcoded values in source. Starting out we hardcoded company codes, customer codes, shipping points, ... and as we've grown we've had to go back in to these source objects and add more values to the hardcoded list. Now we're taking a step back and wanting to replace these values within "something" so that an addition or subtraction from the list could be "configured" instead of requiring a programming change.
We have built a Z-table with program name as part of the key that does appear to be functional. Any change to the hardcoded list would then be changed using SM30 against this table. But we're wondering if this is the best way...
What are you using to avoid hardcoding or what ideas might you have???
Thanks in advance...
Chad
‎2009 Mar 26 1:05 PM
I would try to use selection options first, if not possible introduce custom config tables, if not possible introduce global constants (can be centralised in reusable includes, so just one place must to be updated in the future).
For the config tables, I would not choose program name as key, usually there is some relation between organizational criteria (e.g. find controlling area for a company code via TKA02).
You could quote an example case here for better understanding.
Thomas
‎2009 Mar 26 12:51 PM
Hi,
I prapose you can make a CLUSTER TABLE for it...Pass the KEYS...like PROGRAM NAME in 1st layer then COMpany code in 2nd layer and in that you can maintain values....and write a FM to fetch the valus from that cluster table....values fetched can be used to replace hardcoding.
Hope i am able to explain
Amresh.
‎2009 Mar 26 1:00 PM
Hello Chad,
Is this a report which you are concerned with? If so, then may be you can have the company codes, customer codes, shipping points in the selection-screen.
So that the user can i/p the values for which he wants to display the report.
BR,
Suhas
‎2009 Mar 26 2:01 PM
Some are reports but others are user exits, includes and other objects that we would not have access to screen selection variables.
Hidden screen selection variables do work for reports, but a lot of our changes are in other types of objects.
Thanks,
Chad
‎2009 Mar 26 1:05 PM
I would try to use selection options first, if not possible introduce custom config tables, if not possible introduce global constants (can be centralised in reusable includes, so just one place must to be updated in the future).
For the config tables, I would not choose program name as key, usually there is some relation between organizational criteria (e.g. find controlling area for a company code via TKA02).
You could quote an example case here for better understanding.
Thomas
‎2009 Mar 26 2:04 PM
For example...
One of our main shipping label programs needs to ONLY do a specific subroutine for a set of customers. Something like the following:
IF kunnr = '0000000001' OR
kunnr = '0000000002' OR
kunnr = '0000000003' OR
kunnr = '0000000004' OR
kunnr = '0000000005'.
PERFORM Process_UPC.
ENDIF.
Is a "config" table a specific type of table within SAP or is it just a Z-table used for a specific purpose???
‎2009 Mar 26 4:05 PM
For this example I would consider an extension to the customer master (KNA1 if based only on customer number). You can append fields and also add them to the maintenance screens without modifying the standard. How about a new flag "specific <whatever> on shipping label" that can be set for the relevant customers? There is also a few existing attribute fields (KNA1-KATRx) that could be used.
Yes, I was referring to Z-tables created as "sort of customizing" tables with table maintenance dialogs, and depending on the case with or without transport request handling. You could also solve the example problem with such a table. However, you will have more and more tables to maintain with this approach if you also apply it other cases. Of course you could maybe combine all settings relevant to customer master in one table. It's an extensive topic.
Thomas
‎2009 Mar 26 4:15 PM
>
> Is a "config" table a specific type of table within SAP or is it just a Z-table used for a specific purpose???
Hello Chad,
"Config" tables are ideally Std. SAP tables which can be maintained through customizing.(e.g., TCURR, T042Z). But in your case i feel you have to create a Z-table which has the values of the Vendors for which you need to trigger some code.
Hope this helps.
BR,
Suhas
‎2009 Mar 26 4:31 PM
Hi Chad,
I think the best option for you to maintain a custom table with constant values, where you can keep Program name / Field name / Index as primary key. You can write a FM through which you will copy all the data related to that program, at the very beginning of execution. We are working in this way, to avoid hardcoded value.
Kuntal
‎2009 Mar 26 4:35 PM
I can only stress again that I would make this independent of program or other technical names. The same functional logic might appear in many different programs, multiplying the maintenance effort.
Thomas
‎2009 Mar 26 4:47 PM
Yes Thomas - I agree maintenance effort is much in this case.
Kuntal
‎2009 Mar 26 5:38 PM
I would agree. By program name does have some limitations. For example, a single program that has multiple conditions to be configured. In that case we've configured the program name + "-1", "-2", "-3".
As far as not using the actual program name is concerned. I supposed we could use some generic descriptor like "UPC Label Customers" instead of the program name.
Still even if we used the program name the config tied to that program name could be used in other programs.
‎2009 Mar 26 4:26 PM
We also had a long debate on the same issue.
We decided to try the Soft-Code values instead of the Hard Code.
1. Create some custom tables which can hold the constant values. Like: We have some special processing for the normal sales Order ZOR1 and different logic for the Returns order ZRE1.
So, we have created
One table for the Group - NORM, RETN
One table for the Sales Order & Group relation.
NORM - ZOR1
NORM - ZOR2...
RETN - ZRE1
RETN - ZRE2
Create a View Cluster to maintain these tables easily.
2. Create a Classes which can fatch this data
Like: VALID_SALES_ORDER_TYPE
Definition-
Importing :
Sales Order type
Group
Exporting
Valid
Implementation-
Get the value from the table Sales Order & group relation
This class contains some other methods also, like VALID_GROUPS_4_SO, VALID_SO_4_GROUP etc.
Advantage: You can easily maitain a new Hardcoded value in the SM30
Disadvantage: Lots of coding
Another Approch:
You can create one Global class for Constants. You can maintain all your constants in that global class and use them in your coding. One main advantage would be, you can easily do the where used list on each individual constant.
Regards,
Naimesh Patel
‎2023 Apr 24 8:13 PM
Hi, we have one req very similar to this. can you please give an example of how to do this? so I could understand it better?
I already gave 1 constant (has multiple values) in the z table from sm30. now I want to use it in my program instead of hardcoding the values.