Check my sanity: Creating a PIR via CALL TRANSACTION 'ME11'.

[gary_king2]

Guys, I've been at this for days, trying to get what essentially works in foreground to also work in background. I have a recording (BDC) that works fine in foreground using CALL TRANSACTION 'ME11', MODE 'P', INPUT 'S'.

I have re-recorded the BDC via Transaction SHDB, being careful what options I chose, so identified that I'll be using it 'Synchronously', and not in CATT mode. Also clicked/checked on 'Simulate background mode' and have created recordings having both clicked on the 'Not a batch input session' and also left it blank, but the recordings look identical in that particular case. Anyway, I have used this recording, having debugged it and checked the BDC to ensure that all values are populated in the BDC structure/table. I then call the statement:

          CALL TRANSACTION 'ME11'
            USING lt_bdcdata
            OPTIONS FROM gv_options
            MESSAGES INTO lt_messtab.

The gv_messages looks like this:

  gv_options-DISMODE  = 'P'.
  gv_options-UPDMODE  = 'S'.
  gv_options-CATTMODE = ' '.
  gv_options-DEFSIZE  = 'X'.
  gv_options-RACOMMIT = ' '.
  gv_options-NOBINPT  = 'X'.
  gv_options-NOBIEND  = ' '.

But I have also tried using these settings as well:

  gv_options-DISMODE  = 'P'.
  gv_options-UPDMODE  = 'S'.
  gv_options-CATTMODE = ' '.
  gv_options-DEFSIZE  = ' '.
  gv_options-RACOMMIT = ' '.
  gv_options-NOBINPT  = ' '.
  gv_options-NOBIEND  = ' '.

I have also tried using a DISMODE of 'N', and 'A' but to no avail.

No matter what I try I ALWAYS get the same entry in the (lt_messtab) message table, and there is always a single record with message type of 'S', Yes Success!, even though it isn't because the PIR does not exist. A message ID of '06' and message number of '381'. If you look up that message in SE91 you'll see the message 'Enter Plant', which is a big RED HERRING, as we don't enter a plant number, or need one, as the PIR is generic against Vendor/Material/Purchase Org. If I take the data from the lt_bdcdata table and manually enter it via ME11 then it works fine, so the data is okay, especially as the same data will work in foreground successfully, just ot in background.

If I slightly change the code so that it writes the data to SM35 (OPEN JOB etc) it also works fine, even when processed in background via SM35. Arrrrrhhhhh. I just can't get this to work via a CALL TRANSACTION command. I just don't know why.

I don't suppose the CATTMODE in the gv_options structure would make a difference, would it?.

There's one more option I am trying at this very moment, and that is to generate a new recording (via SHDB) and once complete click on the option to generate a program. It would be worth comparing what it produces with my code.

Update : Just tried the above bu SHDB only seems to use OPEN/CLOSE JOB to create an SM35 session, it does not make use of CALL TRANSACTION. Doh!

[Tomas_Buryanek]

When you run BDC on foreground, then that "Enter Pllant" message is not in lt_messtab?

Try also run ME11 manually and in debuger put breakpoin on this message (dont fill type (S), only number and id).

[gary_king2]

Well, I spent a good week trying to work out what the issue was, and finally, having spoken to a colleague about another subject, the penny dropped, and I realised that even though the program I was executing was running in background (Via SM37) its Step user was a specificed user (as looked up using user params tables), and, even though this user was able to both Create and update materials, plants, storage location, Sales org, warehouses, List prices, Material Determinations, it always seemed to fail when processing PIR's. I changed the code (which launches a job in background) to use my user name as the batch job step user, and hey presto, the creation of PIR's was successfull. I can only assume that the previously used user name with missing some autorisations, although I have no idea how I can find out, as I don't know the password for this user, we just use it to execute in background. 😉

Anyway, my problem is resolved, I can now use CALL TRANSACTION 'ME11' in background without any issues.

[gary_king2]

I believe I have the answer now. I was running in foreground as myself, but when executing in background we used a specific user ID, which could create/update all material data, create List proces and material determinations, but it could not process PIR's correctly. In the end I changed the code to use my user ID when executing in background and eveything worked, including the creation of PIR's.

There is obviouisly a authorisation missing against the USER ID we are using when processing in background.

To answer your question though, the creation of PIR's always worked in foreground, but then the program was executed with my User ID. Running in background with my User ID, and using the same BDC recording worked as well. It just would not work with the User ID we had assigned for background processing.

[gary_king2]

Well, embarrasing as it I did find the answer. I was always running the job in foreground as myself and everything worked perfectly.

We had a specific user for when processing in background, which we would do when going live. This user allowed us to both create new materials/Plants/Sales Org/Warehouses, etc, and also List prices and Material dependencies, but not, it would seem, PIR's. For some reason when creating PIR's (Via CALL TRANSACTION 'ME11') will not work in background for this user, but it will work perfectly well in background using my user ID. That is so odd that the user has the auths to do so much, but not create PIR's.

Anyway, we'll find out what the missing auths are and add them for the User ID we use for background processing.

Many thanks to those that posted things to try.