Return new doc num from std R/3 to custom program?

[patricia_brainard]

Colleagues,

I am designing a process in FI, and need some help with a technical problem. I have a custom table that contains a list of items, each with a status code. This list is presented to the user in a screen. Each line on the screen has a "Take Action" button. Depending on the item status, "Take Action" will transfer control to a different FI transaction -- F-28 (post with clearing), or FB01 (create document). I want to capture the results of the standard transactions (the new document numbers) back into the custom table.

Is this possible? Both standard transactions will display the new document number in the status bar, but how do I make that information available to the custom program?

My plan is to have the standard transactions open in a new session (window), so that user can switch back and forth between the custom transaction and the standard transaction. However, I cannot trust the user to capture the document number manually. I don't think a user exit would work, because there is nothing to distinguish these transactions from the hundreds of thousands of other F-28 and FB01 transactions.

In my research, I did find a reference to a function module FI_MESSAGE_GET, but I cannot find any information about it, and the code itself is not enlightening.

Thanks in advance for your help

Patricia

[patricia_brainard]

Colleagues,

I am designing a process in FI, and need some help with a technical problem. I have a custom table that contains a list of items, each with a status code. This list is presented to the user in a screen. Each line on the screen has a "Take Action" button. Depending on the item status, "Take Action" will transfer control to a different FI transaction -- F-28 (post with clearing), or FB01 (create document). I want to capture the results of the standard transactions (the new document numbers) back into the custom table.

Is this possible? Both standard transactions will display the new document number in the status bar, but how do I make that information available to the custom program?

My plan is to have the standard transactions open in a new session (window), so that user can switch back and forth between the custom transaction and the standard transaction. However, I cannot trust the user to capture the document number manually. I don't think a user exit would work, because there is nothing to distinguish these transactions from the hundreds of thousands of other F-28 and FB01 transactions.

In my research, I did find a reference to a function module FI_MESSAGE_GET, but I cannot find any information about it, and the code itself is not enlightening.

Thanks in advance for your help

Patricia

[Former Member]

Hi Patricia

You can use the BTE in order to get the FI number and store it in a custom table, the event 00001030 should be ok for you, this BTE is triggered by FI posting generated by FI

All kind of posting should be triggered it

Max

[Jelena_Perfiljeva]

In addition to the BTE recommendation - the document # should be in memory (GET PARAMETER) after transaction is complete. Although this option is not 100% reliable (e.g. what if the same user has multiple sessions open or if there is an error?).

I'm not sure what's the purpose of the custom transaction and how exactly it's going to work. But when using BDC/BAPI it is possible to capture the document # and do better error handling. Not many options there with CALL TRANSACTION since it kind of runs on its own.

[patricia_brainard]

Hi All,

Thank you for your suggestions. I am running them past my developers and will get back to you when I have heard from them.

The reason for the custom transaction is this: External partners are transmitting data. We have a batch process to automatically post this data. Unfortunately, the partners do not always send enough data for the batch process to figure out what to do. In our new process, we will capture the failed transactions in a log file. We will present the logfile data to the users in a nice simple screen (like a spreadsheet) that allows them to click through to the standard posting transactions. They need to have both sessions open so that they can figure out how to do the posting, based on the data in the log file.

Because of the user interaction that is required (and the nature of the specific users who will be interacting), we cannot use BDC sessions -- we have to launch the standard transactions (such as FB01).

All of this is pretty easy -- the tricky part is getting the actual posting data back to the log file.

Thanks again!

Patricia

[Former Member]

Hello,

when you are launching FB01 / F-28, do you have any unique number / text which are part of each document?

If yes, you can query standard table periodically in transaction time and refresh the ALV screen.

Thanks.

[patricia_brainard]

Hi,

Sadly, I do not have any information other than the customer number (for F-28). I could pre-populate data in FB01, but the users are likely to overtype it.

Patricia

[Subhankar]

Another think you can try.

when user will chick on the button 'Take Action' it taking to standard transaction with some reference fields. in the At user command subroutine you can check if any records are created with that reference value and modify the custom table accordingly.

Thanks

Subhankar

[patricia_brainard]

My developer has tested the BTE solution and it works if the standard transaction is called in the same window. He is going to test calling in a new window. It is more important for us to get the document number than to have the two windows. Therefore, I will modify my design if we can't have two windows AND capture the document number.

[Former Member]

I can't understand.....

The BTE always retunrs the FI number of the document is being posted, so if you have the number you can stored it in your custom (database ?) table,

where's the problem for the windows?

Why do you have to worry about the window, if you need to store the number in a table?

Max

[patricia_brainard]

Remember, this is all based on the receipt of transactional data from an external partner. The reason we have the log file is that our automatic process could not determine what kind of posting to create. So the user has to figure it out. Ideally, I would like the user to be able to display the log file screen in one window (so they can see the transmitted data), and the posting screen in another (so they can apply the transmitted data appropriately).

[Former Member]

So

you need to show the document number in the window with the log file?

Max

[patricia_brainard]

Max,

Yes (if I understand your question).

Basically, this is the logic:

BATCH PROCESS

1. Receive external file

2. Post automatically if possible

3. Write unposted transactions to the log file.

SUBSEQUENT MANUAL PROCESS

1. Build "spreadsheet" screen from log file.

2. User decides how to post the transaction.

3. User selects line; FB01 (for example) is called.

4. User completes FB01 and posts the transaction.

5. Return to "spreadsheet" screen; update log file with posting data (document number); update screen to display current status.

6. User continues processing until all items are posted.

Patricia

[Former Member]

ok

You need to have a custom table to create a link with the record of the log file, this table will be updated (with the document number) by BTE.

After posting the document, the user backs to the log file and presses a button for refreshing it: so the table will be read in order to get the document number and write it in the log (screen).

Max

[patricia_brainard]

Thanks to everyone for the very helpful responses!