Adding fields in Travel WDA Applications
This document shows a practical approach for adding fields in the WDA standard applications FITE_REQUEST and FITE_EXPENSES including the respective business logic and impact on other parts of the FI-TV module. What follows has been done on a system from NW 7.01 / ECC 6.04 to NW 7.03 (731) ECC 6.06; I won’t rule out that the approach is going to work on any system that holds the corresponding sources for the WDYN Components, but.. you never know π
In the recent past, I’ve seen quite a lot threads on the travel management subforums that deal with problems like “Where can I add field XYZ…” or “How can I include Information ZZZ..” whereas the ‘end of the story’ of these threads pretty much always seems to be violating standard fields for something they’re not meant for with (most of the time) unknown consequences what impact on the entire FI-TV process might occur. Thus I thought, I’d share my approach (which I partially already shared in numerous discussions) with you as a whole in my very first document π .
Please note:
You should have the following expertise, if you want to fully understand the entire document from a technical side(Info material at the end of document):
- ABAP Dictionary, ABAP/4 + OO in general, Dynpros
- basic knowledge in the development in WebDynpro ABAP
- basic knowledge in Enhancement Framework
My approach contains a solution for Travel Requests and Expenses, but NOT for Planning, i.e. not for FI-TV-PL, since the planning component uses a different data foundation. This document is NOT a step-by-step guide, I will not go into every detail of enhancements, modifications etc.
1. Use Case
“Hey! Programming-Guy! Make it work so that we can use the Standard Web-Thingies for Travel, but we need about 50 dedicated extra fields that have to reflect upon the backend too; also our business process is completely different than assumed in the standard and we need it by FIVE PM! GO! GO! GO!”
Nah. Kidding. But jesting aside, in my company we had the following requirements:
We had to migrate from our current Travel Solution to the one SAP provides without losing any information-depth, without hurting our Public Sector specific travel law (which is quite some son of a gun) and without diverting from our original business process. Having these requirements, our options came down to:
- Building our own WDYN-Applications (which was no option anymore, though, after considering the TCO)
- Twist and bend the standard fields to our needs without knowing the entire depth of consequences (and probably bite the hand that feeds you without knowing –> baaaad idea)
- ‘Somehow’ enhance the Standard organically. This ‘somehow’ is further explained in this document π
2. What do we need and what is the technical data foundation?
If you take a look at the Travel Management Implementation Guide, in the branch of data acquisition, there is an entry most people probably don’t even bother clicking on, because the description doesn’t really tell you the whole story:
In short, the IMG entry tells you there is a structure called ‘PTK99’ that can be used to add fields through appends and then make them accessible with minor means of (wanted) modifications in the Screen 9999 of Frame Program SAPMP56T. It also tells you this is not supported for SAP EP; fair enough. Now, what’s most interesting isn’t the screen modification for Transactions PR05/TRIP/TP01 etc; it’s the structure PTK99 itself. If you take a look at the cluster PCL1-TE via Transaction PRTE, you will notice a structure called ‘USER’. This structure ‘USER’ is of the type PTK99. See where this goes? π
The structure PTK99 is used in the cluster and more importantly its macros; it’s used in a lot of standard routines, it’s used in the data retrieval FM’s, it’s used in the standard ADOBE Forms Interfaces etc. etc. etc. The fact that SAP provides this dedicated structure for custom developing activities that is used in vast areas of the standard business logic gives you immens power and possibilities. Now imagine you are using a Z-Table for your custom data that has to stay consistent with the cluster and the transparent tables for the header data, i.e. recreate all the save-update-delete-routines in the dozens and dozens of submodules. It won’t make you happy. Chances are good you miss some and the whole process becomes inconsistent. So, bottom line, in my humble opinion, Z-Tables = bad, PTK99 = good.
Even though you can see I’m a fan of PTK99, I’ll try to stay fair and point out some disadvantages you should be aware of:
- PTK99 is not considered in the WDA applications in Standard (but then, neither are Z-Tables π )
- If you modify/enhance PTK99 and you don’t know what you’re doing (like my former self) you will cause your cluster to become inconsistent. I’ve had an interesting discussion with Sally Redmond about it over here http://scn.sap.com/thread/3194702. Furthermore, by now SAP also provided some notes that diminish the risk of inconsistencies, for example #1533696 and #1689972. In case things go wrong nevertheless, SE14 will save you.
- At some parts in the standard business logic, there are gaps of PTK99 being passed from one module to another. I think to have reported all of them to SAP and all gaps that I found and are within support limitations have been plugged by now. Nevertheless, initially it felt to me, like the idea with PTK99 was implemented by SAP bit by bit and then suddenly all responsible developers dropped dead; but nevermind, as I said, I think all of the gaps are closed (but don’t be angry if you DO find another one π )
What I did, bottom line, was adding nearly 80 fields via an Enhancement Append to the Structure PTK99. So far so good.
3. Backend modifications for data visibility and access
Since it most probably makes sense for most business processes to be able to see and have access to the data that is entered/changed in the WDA Frontend in the Backend as well, there are some minor things that need to be done:
Please Note: The part that follows is identical with the IMG-Documentation of the entry I mentioned earlier; I’ll put it down anyway, in case somebody is too lazy to read it from the IMG π
Assuming, you have now enhanced the structure PTK99 with your custom fields, go to SE80 and open the sources for the report SAPMP56T. The report already contains the standard global data variables ‘USER’ for from-database/to-database and ‘PTK99’ for from-screen/to-screen. What you have to do here is modify (since the enhancement framework is not integrated for dynpros) the modules “d9999i_init” and “d9999o_init”, so basically code the shifting of data from USER to PTK99 and the other way around plus the handling of the OK-Codes; but aside from that, you don’t need to do anything since the standard does the rest.
Next, modify the layout of the screen 9999 accordingly to your datafields. Last but not least, go to TA FITVFELD and enable the screen ‘Userdata’ for each trip provision variant and each schema you want.
I really didn’t do more here than the data shifting in the PBO/PAI modules and implement some particular OK codes. The screen painter took me most time I think. Though, it all was done in a couple of hours (not much if you consider the magnitude in the entire business process). Here’s a portion of how it can look like:
4. Frontend Enhancements and integration into the standard business logic
Now that the data foundation is set up, you can go ahead and start enhancing the standard webdynpro components that are part of the Travel Request/Expense Sheet Applications. The most important ones are: FITE_VC_GENERAL_DATA, FITE_VC_ITINERARY, FITE_VC_SERVICE_REQUEST, FITV_VC_COST_ASSIGNMENT, FITE_VC_REVIEW, FITE_VC_RECEIPTS and FITE_VC_CONFIRMATION. I will not go into details what I did here since it’s not the purpose of this document to tell stories about WDA-Development and the Enhancement Framework.
In Short, what I did was:
- enhanced the context and the layout according to my needs for my fields of PTK99
- implemented some custom UI-Fieldcontrol for my PTK99-Fields
- dynamically registered events to standard fields to cause events influencing custom fields and vice versa and did quite some post and overwrite exits (avoid to use overwrite exits if possible, by the way)
- used and enhanced the assistance class CL_FITE_ASSISTANCE for custom business logic access and for data consistentcy in runtime between the different WebDynpro Components
Assuming you now have your custom fields and routines implemented in the WDA environment, the actual interesting question is “how does this correspond with the database and frame program routines”? The Standard WDAs do not support the structure PTK99, however the business logic in SAPMP56T does. Here’s the deal: slightly before the navigation to the WDA FITE_VC_REVIEW, I export the data from my ptk99-context into the abap-memory (for example, in FITE_REQUEST it’s the Method CHECK_GENERAL_DATA in FITE_VC_GENERAL_DATA). Before I break loose a discussion now, yes, there also are singleton instance classes and yes, there also are shared memory objects, but in my scenario I only need the data for the time while the callstack is active and after that it can be eliminated by the garbage collector, so, abap memory it is.
The next thing that is needed, is the old SMOD-Enhancement FITR0003. This SMOD implements a function module EXIT_SAPMP56T_002 which again is called inside of a user exit that is called every time AFTER the Trip Number has been determined and BEFORE the data is saved/updated to the database. Inside this FM, you can manipulate all data that is provided by the FM’s interface and guess what we also have here? PTK99. So, Import back from memory, shovel it to the FM’s Interface and the data is automatically consideres in the further saving routines for the database/cluster.
Up to this point, there are custom fields in the WDA which hold data that is later saved in the standard cluster and that can be accessed from TA TRIP/PR05 for further processing.
One thing is still missing, and that’s the data retrieval from the cluster for further WDA processings, for example when a travel request is changed or when a travel expense sheet is created based on a prior travel request. For this, I use the first call of the method ON_SHOW in FITE_VC_GENERALDATA and the FM HRTRV_IF_GET_TRIP. I had to code an additional enhancement in HRTRV_IF_GET_TRIP for it to successfully pass PTK99 from the local coding to its interface (sending it to the SAP Support was no option here because the FM is not released for customers, i.e. = no support for this). The FM then provides the data for PTK99 from the data base and all that needs to be done after that is post PTK99 back to the custom context of the WDA. All Done.
5. Personal experience after implementation and conclusion
We are running FI-TV with this solution now for about one year and I haven’t been able to blow up the PCL1 cluster yet, despite adding further fields successively(no situation where we had to use SE14). Concerning updates and upgrades it’s also all going very smoothly, SPAU_ENH works great for all enhancement-conflicts, especially in the WDA environment. What I did in addition was connect the package with all my enhancements to a reversible switch that can be switched on and off in the switch framework. This possibility also makes it easy to isolate problems after upgrades (particulary when something crashes and the first thing you would like to know is, whether it’s your own fault for messing with the standard or the fault of the standard itself).
Links to Information sources that can help understanding this document better:
What | Where |
---|---|
Overall Travel Management Process | http://help.sap.com/saphelp_erp60_sp/helpdata/en/26/fddaabb7dd11d194c600a0c92946ae/content.htm |
FI-TV Implementation Guide | http://help.sap.com/printdocu/core/Print46c/en/data/pdf/FITVPLAN/FITVGENERIC.pdf |
WebDynpro ABAP Basics | http://scn.sap.com/docs/DOC-8863 |
Enhancement Framework | http://help.sap.com/saphelp_banking50/helpdata/de/94/9cdc40132a8531e10000000a1550b0/content.htm |
Switch Framework | http://help.sap.com/saphelp_nw73/helpdata/de/af/e8b540afc87c2ae10000000a155106/frameset.htm |
Aight’, I hope this approach is interesting and useful for someone else than myself. I’d be glad to see some destructive criticism etc. concerning this document, so I can get a grip what I can do better next time, for example whether more pictures would be nice or whether I need to explain certain things more clearly/more in detail or whether I should just shut the hell up π
Best Regards and Cheers,
Lukas
P.S. @Laure Cetin; There! Your new gamification interface finally made me blog/write a document! I hope you’re happy now! π π π π :
Very useful blog Lukas - its interesting for me to see it from customer perspective too π , Thanks for sharing the knowledge!
Thanks, Sally! I'm happy hearing this from you π
Useful Blog..
Woohoo! Congrats on a very good document!
Yes, you made me happy, I am glad that gamification encouraged you to contribute more and differently.
All the best,
Laure
Hi Lukas,
Thanks for sharing such nice stuff. I was yesterday reading http://scn.sap.com/community/web-dynpro-abap/floorplan-manager/blog/2013/06/09/demystifying-fpm-for-travel-expense-fitvfpm and I thinkl those two blogs/documents complement each other quite nicely.
Cheers,
Custodio
Hey Custodio,
thanks for the nice feedback! I just checked out the blog you linked and think it really harmonizes well with my document indeed!
Cheers, Lukas
Hi Lukas,
Thanks for this informative blog.
I had a quick question. We know that the General Data View is used for both Create Travel Request and Create Expense Report, but the fields visible in the two application's for this view are different. In my environment the Change Cost Assignment section appears in Create Expense Report but does not come for Create Travel Request. Can you please suggest how through config I can control the visibility of standard fields(on General Data View) in Travel Request. I used the transaction "FITVFELD_WEB" (IMG config) using the Trip Provision variant but the changes are not reflected.
Regards
Sundeep
Hi Sundeep,
FITVFELD_WEB is the right place to configure this. You need to configure Schema PL (used for the Travel Request + Plan) for the respective Trip provision variant and tick the checkbox in subscreen 'Cost Distribution' labeled 'whole trip' or 'entire trip' (loosely translated from German). If you did this, it should reflect. Can you confirm this is what you did? Unfortunately I cannot include Screenshots inside a comment.
Cheers, Lukas
Hi Lukas,
Thanks for your reply.
I was doing the changes in the wrong schema.
As suggested by you when I made the change in the Schema PL, my changes worked.
Cheers,
Sundeep
Lukas - Sorry to jump in even though the query was directly assigned to you, hope you don't mind me responding π
Hi Sundeep,
Basically you would ike to control the fields within the cost assignment block - if yes then this can be achived through configuration. Follow the path:
IMG: Financial Accounting > Travel Management > Travel Expenses > Dialog Control >Set Up Field Control for Account Assignment Object via TRVCO.
Once you have set up the layout for your variable key, you can use this for as a return value in feature TRVCO based on the employee's org assignment or the other way round, use the retrun value of feature as a variable key to set up the field characteristics of each cost assignement field.
IMG: Financial Accounting > Travel Management > Travel Expenses > Dialog Control > Set up variable layout for accounts assignement block.
Hope this helps.
Ankur
Hi Sundeep,
in general I don't mind being asked directly as long as its in an open-for-all discussion/thread, for example by tagging me (I think asking me in my document isn't useful for others who might encounter similar problems like you because they won't find the correspondence here); however I do not answer technical questions solely directed to me excluding the SCN community, this is against my principles.
@ Ankur, I don't mind at all, since I don't think there is or should be content directed at only one dedicated person on the forums; that's simply against the very purpose of the forums itself.
Cheers, Lukas
Sundeep,
I totally agree with Lukas comments. I suggest once you have some free time (I know it is really difficult when you are on SAP FI-TV project π ) then can you delete your comments, my suggestions etc. from this blog/document (incl this message) and open a thread and paste it there.
Cheers
Very good document Lukas !! i was stuck with similar requirement and you got me out !!! π
Thanks for the positive feedback, Abhijit! π
Hi Lukas,
This is absolutely brilliant.
I am going to get my consultant working on this logic asap and let you know how it turns out.
So this means that from a config point a check needs to be made that the field appears in the list in Transaction code FITVFELD and FITVFELD_WEB.
T&R
Avi
Hi Avi,
thanks for the kudos! π I'm indeed interested in how the implementations turn out for you and will be curiously waiting for your feedback.
I have not implemented my new fields into the configuration Transactions FITVFELD and FITVFELD_WEB but the idea intrigues me. It's probably possible by adding respective entries to the config Table T706Z1.
Cheers, Lukas
Hi Lucas, Thanks for good document.
Hi Lukas,
thx a lot for the helpful document.
Do you have also experience in the field of adding a customer field in the detailed Receipt?
(I assume we have to enhance the structure PTK33 as well WDA-Component FITE_UI_RECEIPT_DETAILS and so on -doing the steps you described for PTK99, but for PTK33-.
Can you share your point of view to the topic adding a customer field (to other than PKT99 structures)? )
Thanks Alexander
Hi Alexander,
sorry for the late reply (I'm swamped) and thanks for your positive feedback.
I don't have any experience in the field of adding custom fields to the receipt business logic.
In theory, yes you could technically attempt to do the same to PTK33 as I have described in my blog for PTK99 but that would, in my opinion, be the very last resort because PTK33 (or any other PTK Structures), in contrast to PTK99, is maintained and updated by SAP, meaning there can and most probably be conflicts during upgrades. It also means, that you have to "trust" that, in every possible constellation, SAP has programmed clean MOVE-CORRESPONDING business logic
I would suggest that you open a new question for your use case and describe in detail what it is you want to achieve. There might be other (cleaner) ways than DDIC-Enhancements, but first we need to know what you ultimately want to do/what your functional requirement is. That way, other people like Monika Putzer who has a much deeper functional understanding of FI-TV than me (I'm more of a technician) can give their opinion and find approaches that I might not be able to give you.
Cheers, Lukas
Hi Lukas,
Thanks again.
Business requirement is as follows: for specific Receipts-types (e.g. Taxi-receipts) additional information on the detailed receipt is needed (letβs say taxi "route") in order to be able to have a better controlling-reporting.
(Business department does not want it to have it on a separate screen as you used it with the "custom data"-via PTK99 but direct linked to the detailed Receipt)
So we have to enhance the PTK33 (as Sap did it also for PTK33_APPEND SAP Enhancement For PTK33 In R/3 Enterprise Add-on Append structure) via a custom include.
Furthermore we will have to analyse the: Application FITE_EXPENSES / Component FITE_UI_RECEIPT_DETAILS as well depended components for the further WDA processing and find all corresponding applications and components including navigation and communication structures as well (in order to be able to store it in the database / TE-Cluster)).
Iβll get you informed
Alexander