> For the complete documentation index, see [llms.txt](https://docs.prebilt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.prebilt.com/prebilt-for-im-wm-strm/enhancing-prebilt/making-enhancements-in-the-backend-abap.md).
# Making enhancements in the backend (ABAP)
## Custom classes and methods
In this section we will cover how to make enhancements to established PreBilt apps and their methods in the backend.
### Option A – create a customised method
This option we create an enhancement within our class to create a customised method. We can then create an implicit enhancement within the original method to call our customised method, passing in any parameters and then return out of the original method before any of the original code is executed.
It is a good option if we only want to make a change to a single method within an app.
To do this, within the class you want to enhance, go to the methods and click the enhance button. This will bring up the below screen where you can fill in the following fields:
Clicking the tick will confirm the enhancement and request you add it to a transport.
Once added we can then add custom methods to our class, for example if we want to create a customised method of VALIDATE\_ITEM, we can create a Z version called ZVALIDATE\_ITEM then copy all the code from the original method and remove any of the enhancement points.
Within the original method we can then create an implicit enhancement point (right click > Enhancement Operations > Show Implicit Enhancement Options) at the start of the method to call our custom method (ZVALIDATE\_ITEM) and then RETURN out of the original method.
When we call our custom method, we need to ensure we pass any exporting/importing/changing parameters which can be found in the Signature of the original method.
Note: When passing parameters; we are EXPORTING any “imported” parameters (denoted by the prefix i…), we are IMPORTING any “exported” parameters (denoted by the prefix e…) and CHANGING parameters are the same (denoted by the prefix g…). It must be done this way to “pass on” any parameters from the original method to our custom method. For example, parameters that are exported to the original method then need to be imported to our custom method, likewise parameters that are imported from the original method need to be exported from our custom method. It is important these parameters are “reversed” for this enhancement to work.
### Option B - create a custom app
This option involves creating a Z version of the app which we can customise and is useful if we want to make changes to multiple methods.
* In the Object Navigator (SE80) within the package ZTCTM, create a custom package called ZTCTM\_WM\_APP\_XXX and within that package create a class also called ZTCTM\_WM\_APP\_XXX.
* Open the class then select Properties and Superclass, enter the superclass you wish to inherit from which will be in the format /TCTM/WM\_APP\_XXX. Then save and activate.
* Add any Macros you may wish to use that these will not be copied over. On the toolbar Goto -> Local Definitions/Implementations -> Macros.
* In change mode, right click on the method you want to change and select Redefine or click on the method and click the Redefine button.
* You may want to copy the code from the original as this will be replaced, but it can still be found in the same method of the Superclass. Once a method has been redefined it will turn from blue to black
* You can now start making changes to the custom Z version of the app/method.
* The custom backend service class (ZTCTM\_WM\_APP\_XXX) will then need to be assigned to the app’s transaction code in config.
## TCTM/WM package structure
When making enhancements you may want to use code within the /TCTM/WM package. The package has 3 subpackages:
* /TCTM/SERVICES – contains a series of service classes that we use throughout PreBilt apps and can be reused when dealing with Batches, Bins, Materials, MatDocs, Transfer Orders, Serial numbers and Stock amongst others.
It is worth taking the time to familiarize yourself with these service classes and using the “Where-Used” functionality can provide examples of how each service/method has been implemented.
* /TCTM/WM\_APPS – holds the packages that contain each app’s backend code.
* /TCTM/WM\_BASE – this package holds the ‘base’ information used across all apps.
### Dictionary objects
* Database Tables – holds information about the database tables we use.
* Table Types – custom tables types we use when defining tables within our ABAP code.
* Structures – custom structures which we use to define structures in our ABAP code.
* Search help – manages our search help functionality across apps.
### Class library
* Holds Classes and Interfaces that we commonly use within our code and some useful helper functions.
* In particular /TCTM/WM\_CFG\_HELPER and `/TCTM/WM_UTILS` hold a lot of common methods we see used in our apps and are worth getting familiar with:
### Programs
* Holds programs that we may not want to directly reference in our apps but allows for additional functionality within an SAP system. For example, /TCTM/WM\_CFG is the program that runs our CFG transaction that we will discuss below.
### Function groups
* This is where our Conversion Exits are defined and can be added to.
### Transactions
* Handles additional transactions we may want in an SAP system; this is where we define our CFG and CFG\_D (AMD) transactions.
## SELECT\_OPTS, FIELDS and ACTION classes
Within the packages of our apps we have SELECT\_OPTS and FIELDS classes with the naming convention:
/TCTM/WM\_APP\_XXX\_SELECT\_OPTS/TCTM/WM\_APP\_XXX\_FIELDS
These classes are referenced in AMD next to a field and allow us to write code that can make changes to on screen fields or inputted values, suppress fields based on conditions that we define, populate dropdown lists and process fields (for example for field validation). This allows us to make changes outside of the app's main classes and reuse code.
Within our ABAP class /TCTM/WM\_UTILS we have functions PROCESS\_SELECT\_OPTS and PROCESS\_FIELDS\_IN that when called handle the changes we make within our SELECT\_OPTS and FIELDS classes respectively.
We also have ACTIONS classes that operate in a similar way but allow us to change actions within AMD, often this is for showing/suppressing a field but other logic can be added in aswell.
These classes have the naming convension:
/TCTM/WM\_APP\_XXX\_ACTIONS
