Travel Request Date Collision Check

[Former Member]

Hi Experts,  Is their any provision available to check  date collision when employee is raising  travel request through ESS.  Scenario : Employee first raise travel request through ESS for specific date 01-Aug-2013 to 04-Aug-2013 for destination X and it is pending for approval with supervisor / already approved. But expense are not yet claimed.  If again employee raise travel request for the same date 01-Aug-2013 to 04-Aug-2013 for destination X or Y.   Is their any setting which prompt for collision check which indicates employee that already a travel request exist for the same period.  Please advise.  Regards, IFF

[former_member131723 · Accepted solution]

Hi there

I'll move this to the travel management forum and please post any FI-TV related queries there but to answer your question, no in the standard version, overlapping travel requests for same dates are permitted whereas travel EXPENSES are not. If you try to create expense report from an overlapping travel request, it is coded for error. (note 1469149 also brings some changes to the customizing too)

To prevent overlapping travel requests can only be possible by modification and this is the case for trip schema PL.

thanks

Sally

[Former Member · Accepted solution]

Hi Sally,

"To prevent overlapping travel requests can only be possible by modification and this is the case for trip schema PL."

Can you justify/elaborate, how can we prevent through trip schema PL.

Regards,

Narayana

[Lukas_Weigelt · Accepted solution]

Hi,

@ Sally; when I read this I thought, "nah that can't be, the navigation is interrupted when a collision occurs", and it is, but only as a warning in Requests/Plans, so you are indeed right. I need to change this as well, good I looked into this thread.

@ Narayana, the message is thrown in Include PTRA_UTIL_GLOBAL_TRIP_DATES Form OVERLAP_CHECK, I just traced it; and to my dismay, it really needs to be modified, there's no chance for enhancements here... the only reliable way is replacing all occurances of the FM

PTRM_UTIL_MESSAGE_APPEND where the message is thrown with the parameter i_msgtype = 'E' instead of 'W'.

Cheers, Lukas

[former_member131723 · Accepted solution]

Hi Lukas/Narayana

Yep, its a coded warning in ESS but different for TRIP in the gui (I wrote a KBA on this earlier in the year as we get this query alot )  you'd need to modify FITP_GET_VALUE, TRIP_WISH_CHECK_OVERLAP and CHECK_OVERLAP but I'd suggest to be hesitant in doing so as alot of underlying processes in trip schema PL so could cause more problems!

The thought behind is that during the planning phase of a trip it should be possible to create overlapping trips. Thus you only get a warning message that there are already trip dates and not an error (as soon as an expense report has been created an error message occurs if you try to create a new travel request that overlaps the expense report).

hope it helps!

Sally

[Lukas_Weigelt · Accepted solution]

but I'd suggest to be hesitant in doing so as alot of underlying processes in trip schema PL so could cause more problems!

Mh... true enough. The deeper business logic in the util parts of FI-TV is horribly complex and I wouldn't want to search an error in there I might have caused by a modification ... I'll check back with my special department and editorial possibilities to keep endusers from the creation of overlapping travel requests before modifying this.

[Former Member · Accepted solution]

Hi Sally, Please advise what schema modifications has to be done in schema. Regards, IFF

[former_member131723 · Accepted solution]

As mentioned before, I'd advise NOT to modify this as we see alot of problems around modifications in trip schema PL and of course it is unsupported but if your client is insistent, you need to concentrate in the following main areas of FITP_GET_VALUE, TRIP_WISH_CHECK_OVERLAP and CHECK_OVERLAP as already stated  - maybe one of the other contributors might be able to suggest an alternate approach they utilised though.

.

Message was edited by: Sally Redmond