RV_INVOICE_CREATE in update task

[former_member204338]

Hi All,

i'm using output message for oubound delivery to create automatically invoice.

Dispatch method of message is immediate so printing program is called in update task mode.

Printing program creates invoice by function RV_INVOICE_CREATE with WITH_POSTING = 'F'.

Now there is a problem that sometimes there is a dump 'POSTING_ILLEGAL_STATEMENT' appears

"Statement "COMMIT" is not allowed in this form.".

Callstack:

FUNCTION SAPLSYDB LSYDBU27

DB_COMMIT

FORM SAPLKEFT LKEFTF02

EXPORT_TO_INDX

FUNCTION SAPLKEFT LKEFTU02

RKE_FILL_FIELD_TABLE

FORM SAPLKEAK LKEAKF05

FILL_FIELD_TABLE

FORM SAPLKEAK LKEAKF05

DETERMINE_OPERATING_CONCERN

FUNCTION SAPLKEAK LKEAKU07

COPA_PROFITABILITY_SEGMENT

FUNCTION SAPLKEAK LKEAKU02

COPA_GET_PAOBJNR

FORM SAPLV60A LV60AA16

ERGEBNISOBJEKT_ERMITTELN

FORM SAPLV60A LV60AA59

PREISFINDUNG_GESAMT

FORM SAPLV60A LV60AA27

FAKTURA_BEARBEITEN_ENDE

FUNCTION SAPLV60A LV60AU02

RV_INVOICE_DOCUMENT_ADD

FUNCTION SAPLV60A LV60AU01

RV_INVOICE_CREATE

Looks like problem while creating Profitability Segment in controlling. But why there is a commit work?

ERP2005, ehp4

Thanks

[former_member204338]

You should run the output asynchronously with RSNAST00 - there's no reason to try to spin off the function call to another thread and I seem to remember that the approach does not work from the update task anyway.

[brad_bohn]

Obviously, there can't be one - if this results from standard config and code as it appears, then you should search OSS and raise a message if you don't find a solution.

[Clemenss]

Hi Denis,

check all programs involved - including print program and forms. I'd bet that somewhere you will find some piece of code added to the system with a COMMIT WORK. Too many users and developers just refuse to admit that a COMMIT WORK issued in a called routine (not from the original caller) can never be correct.

Regards,

Clemens

[former_member204338]

Hi Clemens,

The problem in standard. But SAP refused to do anything because it's Z-form calls RV_INVOICE_CREATE in update task. The answer was "do not do so".

So now the question is how to investigate the situation properly? call function in separate task? or?

Kind regards,

Denis

[Sandra_Rossi]

"in separate task"? You mean in background task as separate unit (tRFC, use SM58 to monitor failures). That should work. Or simpler, create a batch which creates invoices at regular intervals.

[Clemenss]

Hi Sandra,

Just call the function with the addition DESTINATION 'NONE'. This initiates an RFC call to the own system starting a separate task.

Regards,

Clemens

[Sandra_Rossi]

Clemens, you're right.

There is an interesting difference between the 2 solutions: tRFC (the one I proposed) proposes recovery (SM58) while aRFC (technology behind destination 'NONE') does not, so if you don't have a manual recovery possible (like running again the dialog transaction), you must code it by yourself.

[Former Member]

Hi,

You may try creating one more FM and call Invoice create in it with COMMIT WORK.

Just for the FM call use:

CALL FUNCTION 'ZABC' starting new task abcd

IMPORT

-

---

EXPORT

-

---

TABLES

-

---

.

where abcd has to be of type C.

(As In Update task database commit is not allowed this will help our commit work to happen out of update task)

Thanks,

Preyansh

[brad_bohn]

You should run the output asynchronously with RSNAST00 - there's no reason to try to spin off the function call to another thread and I seem to remember that the approach does not work from the update task anyway.

[former_member204338]

I'm agree with you that there is no need to make another thread. But could you please clarify what do you mean under "run the output asynchronously with RSNAST00"?

thank you

[brad_bohn]

If I understand you correctly, you have a custom delivery output type which is configured to run in 'immediate' mode during the delivery create process and your output program issues a commit work in the update task processing, via the called standard function?

Since you can't control the commit by detecting the presence of the update task processing due to the standard code being used (this would have been my first suggestion), I would schedule the output type for background processing, then run RSNAST00 at some interval via a background job for your output type. This means that your output program processing is de-coupled from the delivery create process and thus the update task processing is avoided.