Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

BAPI for Parking non-PO Invoices?

Former Member
0 Kudos

Hi Experts,

I am posting FI invoices using 'BAPI_ACC_GL_POSTING_POST'. These invoices DO NOT have POs associated with the Item Details. This is working fine for me.

I want to park similar invoices (that DO NOT have POs).

Can someone please point me to a BAPI that is similar in functionality to BAPI_INCOMINGINVOICE_PARK but does not require a PO?

Thanks,

- Vik.

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Try MRM_INVOICE_PARK.

Srinivas

17 REPLIES 17

Former Member
0 Kudos

Try MRM_INVOICE_PARK.

Srinivas

0 Kudos

Hi Srini,

Is the function module 'MRM_INVOICE_PARK' remote-enabled out of the box?

Right now the source code of my application is in ABAP but eventually it may need to be ported over to Java or to .NET. In that case can my non-SAP application consume the functionality of this function module just like it can of all the BAPI_* function modules?

Thanks,

- Vik.

0 Kudos

No, it is not a RFC. I didn't find any other BAPI that would give you the desired results.

One alternative could be that you wrap this in a RFC function module of your own with the same interface and then use it.

Regards,

Srinivas

0 Kudos

Hello Srini-

How can I go about wrapping this function module in an RFC-enabled function module of my own?

What is the best way to do this?

Any short-cuts or tips and tricks?

Thanks,

- Vik.

0 Kudos

Create a custom function module and in the attributes, under Processing Type, select 'Remote-enabled module. Have the import parameters, export parameters, changing parameters, table parameters and the exceptions defined exactly like that of the MRM function module. Then in the source code, just call the MRM function module using the values from your Z function module.

Srinivas

0 Kudos

Vik,

copy the FM to a customer namespace 'Z' FM in a new function group.

Delete the source code and call the original FM using the parameters from the new "Z' FM.

In the attributes tab select processing type "Remote-enabled module".

Activate the FM. Easy as pie!

Rishi

0 Kudos

Hi Srini and Rishi-

Thanks for taking the time to help.

I created a new 'Z' function group. Then I copied the function module 'MRM_INVOICE_PARK' to a new 'Z' function module within that group.

I removed all the code and tried to activate but got the error 'Reference types not allowed in RFC'.

Then I created a new function module from scratch and copied the Import, Export, Changing, Tables and Exceptions.

Again, when I tried to activate I got the error 'Reference types not allowed in RFC'.

What am I missing here?

Thank you,

- Vik.

0 Kudos

Cannot use TYPE as the reference in the import/export/tables definition of a RFC enabled function module. Use LIKE instead.

This means that you need to use Data Dictionary definitions and not TYPES declared in the function group. Which also means that you may have to create dictionary structures for the FM 'MRM_INVOICE_PARK' and this might be a little difficult.

BTW! I am not sure this FM will give you what you are looking for as this is still used for Logistics Invoice verification and you do not have a PO. I could be wrong! Just wanted you to test it first before all the effort of creating a wrapper RFC and it not solving your need.

Rishi

Message was edited by: Rishi Joseph

0 Kudos

Hi Vik,

First, is this function module working for you. If so, then we can continue with the next step of converting that into a RFC function module.

As I look at this function module, I see that its import parameters are deep structures and are typed instead of using a like. So you cannot do an exact copy. You need to see what is the data that you will need to pass to the function module to make it work for you. Once you determine that, have your function module's interface defined in such a way to suit the call to 'MRM_INVOICE_PARK'. Then inside your source code, convert your input data into the input data for the 'MRM_INVOICE_PARK' function module and call it. <b>You don't have to copy the entire source code of the function module for that.</b>

Take a look at how BAPI_SALESORDER_CREATEFROMDAT2 is coded. The interface of this function module is different from the interface of the function module it calls in its source code(SD_SALESDOCUMENT_CREATE). Before calling this other function module, the BAPI converts its inputs into a format that this other function module expects.

Hope this helps,

Srinivas

0 Kudos

Thanks for your help, Rishi.

What do I do with the one field 'I_EDITOR' which is 'TYPE REF' to 'C_TEXTEDIT_CONTROL'?

Gracias,

- Vik.

0 Kudos

Okay, Srini. This sounds pretty good.

First I will make sure whether this FM will serve my needs.

Then, I will go ahead and see how many of the parameters within this function module I need to use. Once I have a handle on that, I'll create a RFC module with exactly the parameters I need to use.

Once that start working, I can look at extending the parameters as per need.

Thanks again,

- Vik.

0 Kudos

Also, once you have this resolved, could you please reward and close the issue?

Thanks,

Srinivas

Former Member
0 Kudos

Hello Friends-

I wanted to update this thread with some helpful information for others that are facing or migh come across a similar scenario in the future.

I found that the BAPIs for posting and parking invoices do not change based upon whether the invoice has a PO or not. The same BAPIs are used for posting and parking invoices regardless of whether there is a PO or not.

BAPI_INCOMINGINVOICE_PARK and BAPI_INCOMINGINVOICE_POST are the two BAPIs to use in both PO and non-PO scenarios. If you examine them you will notice that they are very "deep" and can be used for even some fairly complex and advanced purposes in this context.

Ofcourse, in both scenarios (PO, Non-PO), the tables/fields of the function modules that need to filled when invoking the BAPI differ.

At the minimum: in the case of POs, you need to fill out the Header and the Item Details tables and in the case of non-PO you need to fill out the Header and GL Account tables. Ofcourse, you can look into the structures behind these tables in the FM and ascertain which fields are mandatory and which aren't.

In some cases, you can even park an invoice with only Header data by using the FM 'BAPI_INCOMINGINVOICE_PARK'. To do this though you need to refer to OSS Note# 579939.

Hope this helps.

Thanks,

- Vik.

0 Kudos

Hi Vik,

I know I am replying after a long time. But I am havin a same scenario wherein I need to park and post PO's and NON-PO's vendor invoices. I am able to PARK / POST MM invoice but I am unable to do so for PARK / POST FI invoice. Please can you urgently tell me the mandatory fields to PARK / POST FI invoices.

Just to tell you the scenario I'll be getting a XML file and I need to ascertain whether PO exists or not. If PO is there then I need to PARK / POST MM invoice and if there is no PO then PARK / POST FI invoice. I have tried to PARK / POST but system is giving 1 or another error. Please can you urgently tell me the mandatory fields to PARK / POST FI invoices. Points will be given for sure.

Thanx in advance,

Anand

0 Kudos

But if you look once the document gets parked through this BAPI, it is a credit memo and not an invoice. How did you get around this problem? We want to park an incoming invoice for a non PO scenario

Thanks

Anusha

Former Member
0 Kudos

Thanks Vik. A feedback like this always helps others in the forum.

Regards,

Srinivas

0 Kudos

I tried using BAPI_INCOMINGINVOICE_PARK to park the FI invoice and I am getting an error:

'Vendor is not defined in company code 0202'. I do't have any vendor that I can assign. Any help is appreciated.