There we will choose to create a transaction ID called LstMCHEADU2. Note that you can call the transaction whatever we like, so long as the first characters in the name are “Lst.” We can then join the transaction with the information category that we have just created.
The view for CMS015/E is then extended, and we are presented with additional options:
First, your sorting option. Since we wanted to filter by the facility and cost type in our example, we need to select your sorting order with the sorting option where these two fields were the first keys. We must also select the view that we made to make sure we get the desired output.
Once we have selected our sorting order, we can then move to the filter control options. The “No. filters” field will determine which fields we can filter by. Note that the number of filters and which fields are determined by the sorting option of the sorting order that we chose to use. That’s why it was so important to create a sorting option with the key fields with the proper sequence.
Since we only want to filter by the facility and costing type in this example, you can choose “2-Facility, Cstng type”. But just for our consideration, had we chosen option “3-Facility, Cstng type, Item number”, we would also be able to filter on item number, i.e., we would have to provide a single item number and not be able to show the costing of any other items. However, this would be too restrictive for our purposes, so we stop at “2-Facility, Csting type”.
But how do we get to filter by item number or costing date? After all, we did not select a filter-option where these fields were available…
By using a selection field! When we choose a field as a selection field, that field is added as an optional range filter for the API, exactly what you want for both item number (KOITNO) and costing date (KOPCDT). To do this, we enter the relevant fields in “Selection fld 1” and “Selection fld 2”.
Please note that only fields in the master table can be used as selection fields in CMS015 (or filters in general). In our example, the master table is MCHEAD, so we would only be able to use fields from that table and not any fields from the joined tables (MITMAS and MITFAC).
We now have our API!
But before we add it to the MI-repository, we can simulate it in CMS100. To do this, chose option 11-Simulate list in CMS015/B1, and we are taken to CMS100 where we can play around with our API. In CMS100, we can add different values to the filters to see how the API will work and change the API’s design on the fly.
Perhaps we would like to see how the API will behave using a different number of filters? Maybe we want to add another selection field? Or maybe we want to try a completely different sorting option or view? Here we can try it out without actually making any changes to the API.
Once we are satisfied with how the API works and have the settings you want, you will need to release it to the MI-repository to become an active API. This is done in CMS015 with the option “20-Update Mi repository”. Once we have done this, the API will appear in MRS001 under program CMS100MI.
We are now able to use this API in whichever way we would like. In our example, we want to use it with a Vince Excel (VXL) export function. The first thing that must be done is to make sure that Vince Excel is aware of this new API. To ensure this, we will need to send the new MI-repository (with our new API) to VXL. This is done through the Vince Excel by clicking on the “Update Repository” button for the M3- environment in which we just created the API.
Note that the Update Repository button is only available for the users that have been defined as administrators for your company. If you are not an admin, please contact the person authorized to help you with this upload.