cancel
Showing results for 
Search instead for 
Did you mean: 

Park & Post from Travel Management

Former Member
0 Kudos

Dear Friends

I'm facing a serious Issue regarding Park & Post. My client wants to Park the Travel documents which come in PRRW t-code, where they want to edit the data &  where practically its not possible. I know the logic that documents will be generated once we post them, but in FI t-codes we can only see them, and cannot edit them. But client wants everything to be under FI control before they post them, so they need to control with Park option to verify them & post. I tried to convince them with other options by canceling the Travel Expense & re-posting it with corrections, but they are not satisfied with the process. now there is only one option in my mind that, I need to go for development, but for that what EXIT i need or what Badi i should take. where is the break point that i can generate a Park document  with document number instead of Post with document number. Please provide me a solution.

kindly give some valuable suggestions

Regards

Pradyp

Accepted Solutions (1)

Accepted Solutions (1)

0 Kudos

Hi Pradyp

I must admit I have never quite heard of it described as park and post before!!! So I hope I am answering correctly here for you, but what I can suggest from Travel side though is that you first of all consider whether you want to post in batch via PRFI or else you can use the check mode which gives you some greater control over the documents before they are posted to FI but the batch process can otherwise be configured as:

RPRTEC00
RPRFIN00_40
RPRPOSTD in check mode (optional)
    –Would prevent partially posted posting runs

RPRPOSTD in productive mode

You mentioned BAdI's also  - here's the possibilities

On Travel side:
Called in RPRFIN00_40
Methods of TRIP_POST_FI exept from FILL_EXT_RAWDATA
Called in RPRPOSTD
TRIP_POST_FI Method FILL_EXT_RAWDATA

On FI Side:
ACBAPI01 (SMOD)
FI Substititions and FI Validations

hope it helps

Sally

Former Member
0 Kudos

Hi Pradyp,

I agree with Sally, I have also not heard of such a peculiar requirement.

If your client's requirement is for FI to control the posting process for expenses then I would suggest that you give them access to transaction PRFI and they can create a posting run in 'Simulation mode' - there is a check box available. Once they are happy with document and have verified it then they can create a live posting run which they can post it to finance using tcode PRRW.

I hope I understood your requirement correctly.

Ankur

0 Kudos

Actually I meant to add as it might of interest to others that there is some enhanced logic coming with support packs in the next few months for the posting process (but it will ONLY be implemented through support packs for all versions from ECC 6.0) but this gives greater control over finding and reposting unposted documents so helping with partially posted document scenarios plus some additional logic already delivered with 1773055.

But for manipulating the document sent to FI, still the only possibility from Travel side is the BAdI  I mentioned.

cheers

Sally

Former Member
0 Kudos

Hi Pradyp,

I think, I know exactly, what you mean. You are referring to the standard park&post process commonly used in most FI transaction creating posting docs.

The problem is, that the DNA of TandE in SAP comes from HR, not FI if I may say so. Therefore, the posting into FI is designed to be the final step in the process - after everything has been approved. Sure, you could send docs from TandE into a parking loop with modifications (don't know where though), but this would break the integration. If docs where changed in FI before posting, what TandE thinks has been posted would differ from what's actually been posted with dire consequences for changes of trips, cancellations, reporting and possibly for consistency and legality of what's been fed into payroll for taxation and what's actually been paid through the creditor - or imconsistency between payments, if done on the HR side, and GL. Manageable in theory, but a Pandita's box I would never want to open.

I've had customers adking similar things. I agree with other comments: the park&post (though not labelled as such) has to happen on the TandE side. You have the various status of trips and the workflow to play with. Solutions vary between bespoke processes. But the essence is: if the accountants want to be in control, they need to manage the final steps on the TandE sude, BEFORE it's posted. It's normal in many countries that accounts run the TandE module anyway, but more difficult to argue, if HR does it. But ir's as simple as that: the boundaries between SAP modules do not always coincide with boundaries between departments.

I know it's no "add your code here" answer, but hopefully a new and clear, though not welcome, perspective to discuss design from.

And finally: there's akways the payment run, which FI can control, most notably, if paying via FU-AP - always my choice as it handels overpayments best.

One Question: do you run SAP payroll? Should be the same problem, shouldn't it?

Former Member
0 Kudos

Thnx Sven

for Posting such a wonderful answer. hope this will be accepted by my client

Regards

Pradyp

Former Member
0 Kudos

Thanks Pradyp. Really glad you find it useful. I keep my fingers crossed you get it solved.

Answers (0)