Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
Lukas_Weigelt
Active Contributor

Hello folks,

This blog post is meant to show a best-practice-approach for designing the trip number ranges used in the FI-TV module. I'm writing this blog in the first place, because I've seen several threads on the forums where this topic is discussed over and over again, there are some wikis and there are several SAP-Notes and I'm kind of trying to combine all the information here adding my personal experience.

System Information:

Assuming you are aware of the dependencies of the FI-TV module and its Business Functions there are no additional restrictions, since it's mostly customizing. There's the user exit Include MP56TFEX which exists since before the netweaver adaption and a Badi TRIP_WEB_NUMBER which should be available as of ECC 6 EHP2 (or even earlier).

Looking at the IMG-documentation:

(System Status Snapshot: NW AS 7.03 ABAP Stack 731 Level 13, ECC 606 (EHP 6) with SAP_HR 604 Level 78 and EA_HR 607 (HR-Renewal 1) Level 29)

The first thing the IMG-documentation tells us, is, that there are two possibilities for the assignment of the trip number:

  1. Internal: Automatically by the System, i.e. with the increment of the number intervall
  2. External: Number is chosen by the end user, i.e. the employee directly

I'm not even going to assume why the possibility for an external number assignment exists. The product owner might know, I don't. My advise, which overlaps with the official recommendation from SAP, is, use the Internal Number Range approach (if you use the external number range for whatever reasons you have, you can stop reading this blog right now :smile: ).

Then there's another good hint in the documentation that goes like "Don't use overlapping intervals in different number ranges"; I'll bounce back to this statement a few paragraphs later. Last but not least, there's a generic hint that number intervals are not transported automatically, fair enough.

Bottom Line so far: Use the Internal Number Range Approach, Don't overlap your intervals and take care of the Transport manually (careful, transporting number intervals after go-live is a no-go!)

My concrete recommendation:

I'm partially copying from one of my posts of the following thread: Trip number range concept

Use Case:


Let's say you have a number volume of 1000 and 3 personnel areas

1. Example how it is NOT done:

Personnel Area 1: 0-1000

Personnel Area 2: 0-1000

Personnel Area 3: 0-1000

Why not? Let's say you have 3 Personnel Areas; in that case you'd have a multiplication of the number volume by 3, right? Wrong, because what happens when an employee switches the personnel area? Data inconsistency happens, because the trip numbers of employee who switches the PA might already be taken by another employee. That's why you don't do it this way.


Furthermore you'd have a Trip Number collision faster than you can say "Help me, Dietmar Hopp!".

2. Example how it should be done according to SAP (not good in my humble opinion):

Personnel Area 1: 0-333

Personnel Area 2: 334-666

Personnel Area 3: 667-1000

Now we have nicely split number ranges for every PA and if an employee switches the PA, the trip number can't have been given to an employee of this PA he switched to because it isn't defined there. So now everything's fine, right? Wrong. Three things are certain in companies: death, taxes and reorganization. Let's say, after you have used up all your numbers for the split intervals and went productive, there are created 10 new personnel areas, also 90% of the employees in PA1 go to PA 2. number interval for PA2 will overflow and on top you don't have any numbers for 10 new personnel areas resulting in chaos.

3. How to do it right (in my opinion):

Now that I've explained how to NOT do it, look at what happens when you have one generic number interval for all PAs:

You use all numbers in any case, this means roughly 10 billion numbers. So even if you have 500 Trips a day, you'd last 10.000.000/500/365 = ~54 years with this. If you still use FI-TV after that time, you can either archive or delete old trips and reset the intervall counter to 0 to last for the next 54 years :wink:

  • What happens if an employee switches the Personnel Areas? Nothing, doesn't matter, the number interval is the same for all.
  • What happens when new Personel Areas are created? Nothing.
  • What happens when huge amounts of employees switch certain Personnel Areas? Nothing.


"How do I do this?"


  1. Create a Dummy Personnel Area via Table T500P and maintain the subsequent dependant customizing tables (like V_T500P, for exmpamle) accordingly.
  2. In IMG activity Financials --> Travel Management --> Create Number Range for Trip Numbers, create one single interval for your Dummy Personell Area "TRIP" from 0000000001 to 9999999999.
  3. In the User-Exit Include MP56TFEX, maintain the Form Routine  ex_get_number and hardcode your Dummy Interval into the exporting parameters with means of a modification or an implicit enhancement at the end (I prefer enhancements). Example:
  4. If you are using the WDA scenarios in your business process, also implement the BADI TRIP_WEB_NUMBER Method IF_EX_TRIP_WEB_NUMBER->USER_EXIT_NUMBER_INTERNAL likewise.
  5. You are done. Enjoy your eternally consistent TRIP Number Range :smile:

Useful Sources (Notes, Discussions, Wikis, help-links, etc.) covering the topic:


FAQ:


Q: We think of using a dedicated number range for each Personnel Area, is that a good approach?

A: No. Use one number range for all personnel areas statically. The reasons for this are posted above.


Q: But if we only have one number range we cannot report on different personnel areas!

A: Yes you can, by using other means of customizing. For example you can use one of the freely maintainable indicator fields, for example KZREA

BEREI or KZTKT or even derive the personnel area directly from the PERNR. The last thing you want to do is misconfigure the basis of the FI-TV application for mere reporting.

Q: There are "gaps" in the number range in our data. For example one trip has the number 400 assigned and the next one has the number 405. What happened to the other 4 numbers?

A: In standard, the buffering for number intervals is activated to allow for less database accesses. Normally there are around 10 numbers in the buffer and sometimes some of them are dopped so you get these "gaps". This is good to know especially when the audit department is visiting :wink: . It is possible to deactivate the buffering but in my opinion you should never do that, because it's a modification without any technical or functional benefit and the load on the database will increase, i.e the performance will suffer.

Q: The numbers in one of my ranges are used up, what should I do?

A: Reconfigure the Interval, i.e. use an interval at the end of the range of all intervals and reassign the Personnel Area to it so you have a "fresh" interval for it. Of course this only works out if you haven't initially taken every single number that's available into account. If you have, and there are no numbers "left" to revert to, you should have read this blog earlier :smile: . Careful: Dependant on your infrastructure, it might be cleaner to actually open the production system and configure this manuall instead of transporting the new number ranges and their counters; transporting number intervals after go-live is NEVER a good idea.

Q: I have created several number ranges for several personnel areas. Now a lot of employees have switched personnel areas and the database entries are inconsistent, what should I do?

A: Fortunately the PCL1-TE Key still always is the PERNR and the overall key for the module is a combination of PERNR and REINR so there is no actual inconsistency. The problem can only be sustainably avoided if you use one number range for all personnel areas.

That's it, folks. Feel free to promote content that should be included in this blog via the comments.

Cheers, Lukas

P.S. Check out my other FI-TV content:

6 Comments
Labels in this area