Create purchasing documents with reference

[Former Member]

Hi all,

In a 4.7 Enterprise environment.

I have added some customer screens to the Enjoy Purchase order (PO) transaction ME21N (using the BADIs ME_GUI_PO_CUST and ME_GUI_PROCESS_PO_CUST).

The mechanism works well.

I want to create a PO with reference to another PO (using the Document Overview). This functionality copies only the standard fields from the originating document into the new document, but DOES NOT copy my custom fields included in the custom screens that I've included in this transaction using the BADI's mentioned above.

How could I do to copy those fields too, from the originating to the new document, when creating a PO with reference to another PO?

(ofcourse, the originating PO contains data in the custom fields)

Thank you,

Bogdan CIOC

[Former Member]

Hi Bogdan,

Did you see my reply to your previous thread? I paste it again for your reference. If its not helpful then explain why and perhaps you can get some more useful input.

-

---

Hi Bogdan,

I can see two ways of handling this:

1. If the new fields that you added to the customer screens are based on append strucutres of the EKKO, EKPO, etc. tables, then the data should copy automatically when one purchase order references another.

2. If you have already implemented the change and have not used append structures and don't want to change your solution, then you will have to do the coding yourself in the BADI's ME_GUI_PO_CUST and BADI_ME_PROCESS_PO_CUST. I would expect that in the INITIALISE or OPEN methods of BADI_ME_PROCESS_PO_CUST that you could include code to copy from the reference purchase order.

Hope that makes sense.

Cheers,

Brad

[Former Member]

Sorry Brad ,

Indeed I didn't notice your previous post.

I did used the two customer includes that EKKO and EKPO provide for the purpose (CI_EKKODB and CI_EKPODB).

The data isn't copied automatically.

Any solution is to be taken in consideration, Brad, including modification.

Thank you,

Bogdan

[Former Member]

Hi Bogdan,

What about option 2:

2. If you have already implemented the change and have not used append structures and don't want to change your solution, then you will have to do the coding yourself in the BADI's ME_GUI_PO_CUST and BADI_ME_PROCESS_PO_CUST. I would expect that in the INITIALISE or OPEN methods of BADI_ME_PROCESS_PO_CUST that you could include code to copy from the reference purchase order.

Methods OPEN or INITIALISE look promising as places for you to put code to copy the custom data from the source document to your document.

Have you had a look at these?

Brad

[Former Member]

In those two methods I have no visibility whatsoever over the reference document(s).

There can only eather

- initialise some of my own attributes/variables (INITIALIZE) inside the class *_PROCESS_PO_CUST;

or

- use the initial header of the current Purchase Order to initialize some dependent variables, whatever (OPEN), again inside the *_PROCESS_PO_CUST class.

After debugging the code, I reached to the conclusion that copying the data is made with the help of some statically defined SAPQueryes (defined statically by SAP) (for instance /SAPQUERY/MEMEPO for copying one PO to another PO).

The "copy with reference" framework then creates dynamically, based on the structure of those queries (blocked at modification by SAP AG) some take-over internal structures and internal tables, fills them with the data returned by the queries mentioned above, then places that data in the corresponding fields of the current document.

That would mean that my custom fields are not copied by the framework, nor SAP has predicted that, yet.

What do you think?

Thank you,

Bogdan

[Former Member]

Hi Bogdan,

Unfortunately I don't have access to SAP today so its difficult to confirm your statements.

One thing I would suggest, however, is that you don't need access to the whole reference document to copy your data. All you need is the reference purchase order number. You can then use this to select the data directly from the tables. If you don't have access to the reference purchase order number (perhaps in the header of the current po?) then you can use the technique in the following blog to access this: /people/brad.williams/blog/2005/04/25/userexits--how-do-i-access-inaccessible-data

If you are still having problems, you still have some another possibility:

You can code your own logic to copy the reference custom po data into the new po in the PBO of your custom screen. Thus, when the screen is displayed you select the reference data at that point (in a once only execution so that if the user makes changes then they are accepted).

To cater for the fact that users may not always display the custom screen, you can put additional logic to achieve the same in the SAVE event of the PO (this should only execute for reference documents where the custom screen was not displayed in the transaction).

I have done something similiar for a specific requirement in the sales order transaction (completely different style of userexit but the logic still holds).

Cheers,

Brad

[Former Member]

Hello, Brad.

Nice technique, the one described in your weblog :).

That makes the concept of variable's visibility an innocent joke.

Still, I want to make a comment on the issue we're discussing here: in the standard functionality, it is possible to create a PO with reference to more than one PO (header from a PO and items from more PO's);

I have to keep as close as possible to the standard functionality (that means that I shouldn't ask the user <i>again</i> to point to the reference document), so my best alternative, having in mind that the standard was already modified, is to modify also the query that gathers the data from the reference document and brings it into memory, in such a manner that it brings my data too into the application.

Do you think that modifying the /SAPQUERY/MEMEPO query could be a solution to the problem?

Thank you,

Bogdan

[Former Member]

Hey Bogdan,

As I said, I don't have access to SAP today so its difficult to confirm that the approach you are suggesting will work, but in general the approach seems sound.

It does seem a bit short sighted of SAP to allow you to add extra fields into the transaction and then not provide any method of copying them from one document to another. In SD you have copy control routines which allow you to handle all of this.

I hear what you are saying about the system already being modified but I wouldn't say that it makes it ok to modify it again. Every modification just creates work for you at updgrade time. Having said that, sometimes a simple modification to achieve exactly what you are after can be a lot less maintenance than 100s of lines of code to achieve the same thing via userexits.

So, I guess if you feel you have exhausted the possibilities offered by userexits, and you have a clean solution available with a modification then thats probably the way to go.

Good luck!

Brad

[Former Member]

It may also be worth letting it sit in SDN for a day or two and seeing whether other people have other suggestions (if that fits with your timeframes).

Brad

[Former Member]

Yes, that's exactly the case.

In this particular case the user-exists don't help me too much in achiving the requirements.

I agree with your considerations regarding the modifications, but, unfortunately...

The clean solution is what I have in mind, you figured right.

Thank you,

Bogdan

[Former Member]

I'll do just that.

[Former Member]

Anybody has other ideas?

Or, do you find my idea good enough?

Thank you,

Bogdan