Stock Transport Order (ME21N)

[Former Member]

Greetings

Hope you are all doing okay.

I have 10 plants 1 - 10 and all plant do STOs via ME21N to plant 10 which is the central plant - everything gets controlled here. User in plant 1 should do STO to plant 2-10 and so on and so forth. I however don't want user in plant 1 to login and change purch group to 2 and ship to 3 as if he is user in plant 2. Currently all plants can roll back material to plant 10 as stipulated. Only plant 10 is allowed to do STOs for plant 1-9. How do I stop plant 1-9 to work on each others plant?

Thanking you in advance.

Mdanisi Mawila

[Former Member]

To create an STO you need the create/change for the originating plant, but only display for M_BEST_WRK for the target/receiving plant.

Take plant 0001 as an example:

Requirement is to create STO for Plant 0001 and send to Plants 0001-0010

Your authorisation combination would need to be:

M_BEST_WRK: ACTVT 01, 02 WERKS 0001

+

M_BEST_WRK: ACTVT 03 WERKS 0001 - 0010

If your users get additional M_BEST_WRK auths from anywhere else then they will override this. This is generally the most problematic part with STO's.

Edited to add: If you have only given authorisation to Create/Change for the originating plant then users can display the STO using ME23N but can't change any of the details.

Edited by: Alex Ayers on Aug 14, 2009 3:13 PM

[Former Member]

Hi Alex

Thank you for the response. Maybe I should have specified the Authorizations approach I am on - I maintain plant access via org levels and if I choose to on the first object (M_BEST_WRK) add 1 & 2 and 3 on the 2nd object with plant 0001 - 0010, it will still defeat the purpose as plants are maintained via org levels and using derived roles approach.

Another point is that: plant 0001 has sub-plants which only plant 0001 and 0010 currently ship material to. Plant 0002 also has its sub-plants and supplies those in conjuction with plant 0010.

However in object V_LIKP_VST: ACTVT 1,2,3 & 85 I have specified plant 0001 to 0010 as receiving plants. This is the only place I could specify my shipping points. I then added these plant - 0001-0010 to M_BEST_WRK with activity 1 as per SU53 report and it allows them access to these plants. They shouldn't work on these plant except for their respective plant in this case plant 0001. Please assist and thanking you in advance.

[Former Member]

how did you do the trick with the sub-plants? there's no hierachy in plants in SAP ERP as far as i know ... ? did you do it by a 'telliing' numbering?

well, Alex approach is the only way to get a little grip on your problem, but i can see where you cannot implement it using derived roles. how many child roles are we talking about, here ... if it were only few, i'd recommend you get away from the derived roles approach.

about V_LIKP_VST: i am not sure, i understand what you tried to explain. is that a group of points where your are shipping from or where you are receiving ?? if you were shipping from and i understood your first post correctly, shouldn't you only ship from the point of plant 0001 and it's subs to the point of plant 0010 (and its subs) instead of allowing for values 0001-0010 ?

[Former Member]

Hi Mdanisi,

M_BEST_WRK is usually maintained by org levels.

There are plenty of ways to get the split I was talking about:

For example:

1 role which has create, change, display for the originating plant

1 role which has display for the rest of the plants

You will only run into trouble if you are trying to do this all in 1 role & don't want to resort to "bodge" techniques to get it to work with 1 role.

I am not sure about shipping points as I have not used that level restriction in any STO work I have done. I do know that what I have suggested above works if you are using standard SAP.

Edited by: Alex Ayers on Aug 17, 2009 9:07 AM

[Former Member]

Hi Meylen

I have 200 child roles linked to one parent role. In this instance I only want 10 plants (these are warehouse where stock is kept) out of 200 plants.

I am in an Electoral Commissions depart ment which runs elections for South Africa. We have 10 plants which are 0001 through 0010 are the core of rest, they depend on them. e.i.c plant 0001 has 20 subs (obtain stock from plant 0001), If plant 0001 want to support plant 0002, the current set up allows them to do STO to plant 0010 - head office plant which in tern STO to 0002. Now we want these plants to support each orther without going through plant 0010.

I applied Alex's advice to the situation but userr in plant 0001 is able to STO to plant 0003 from 0002 - it is wrong they should not work where they don't belong.

I went back to my origional method of using V_LIKP_VST - shipping points which specifies plant 0001, 0002, 0003, 0004 till 0010. It does allow them to ship but can still ship from e.g 0002 to 0003. this object M_BEST_WRK allows them to ship stock their sub-plants (correct) and also allows them to work in wrong plants - not supposed to be like this. If I grant activity 3 it request 1

I hope I explained my self in a way that you understand what I am trying to archive.

[Former Member]

>

> I applied Alex's advice to the situation but userr in plant 0001 is able to STO to plant 0003 from 0002 - it is wrong they should not work where they don't belong.

Your request was the users could STO from 0001 (for example) to 0002 - 0010 and I told you how to do it. Your requirements have now changed.

It doesn't matter though as you need the following to make it work. How you arrange your authorisations is your choice

1. M_BEST_WRK with activity 01/02 for the originating plant

2. M_BEST_WRK with activity 03 for the receiving plant

If you have built it like this then users will only be able to raise STO for the plant listed in 1 and send to the plants listed in 2.

If this restriction is not enforced then that will be because you have not segregated the plants between create/change and the display functions.

The general STO process is: Create PO with STO doc type for the sending plant. Enter the material line items with the receiving plant/company.

You will need activity 01 to designate the sending plant and activity 03 to add those material line items

[Former Member]

i can see where you need derived roles.

Alex, i have been tracing that with PO-type = UB and item line type = U.

checkings in the trace for sending plant:

M_BEST_EKO ACTVT 01, 09, EKORG = XXXX

M_BEST_EKG ACTVT 01, ,09, EKGRP = YYY

M_BEST_BSA ACTVT 01, 09, BSART = UB

M_BEST_WRK ACTVT 01, 08, 09 WERKS = SendingPlant

checkings in the trace for receiving plant

M_BEST_EKO ACTVT 01, 09, EKORG = XXXX

M_BEST_EKG ACTVT 01, ,09, EKGRP = YYY

M_BEST_BSA ACTVT 01, 09, BSART = UB

M_BEST_WRK ACTVT 01, 08, 09 WERKS = ReceivingPlant

the OP is correct. it wouldn't work and i cannot think of anything else that would in his constellation.

Edited by: Mylene Euridice Dorias on Aug 17, 2009 11:21 AM

the trace above as in our system, it seems the checking of the sending plant is due to configuration. on a blank system, the sending plant is not checked. however, the results for the receiving plant are the same.

[Former Member]

I would be interested to know the config required to toggle this check. In all the implementations where I have provisioned for STO's (the most recent being ECC6) the receiving plant has only needed to be display access.

The IDES system I have access to also only required 03 for the sending plant too.

Logically it more sense for the STO to only require create auth for the sending plant in the STO situation. Maybe the OP can run through it with the functional team to determine where this is controlled from.

[Former Member]

i have been debugging it. it's not configuration. this behaviour is actually coded in SAP standard: LMEPOF1Z (SAPLMEPO), Line 43 ff.:

*- WERK ---------------------------------------------------------------*
  CASE ekko-bstyp.
    WHEN bstyp-anfr.
      IF t160-vorga EQ vorga-angb.
        xobjekt = 'M_ANGB_'.
        xobjtxt = text-504.
      ELSE.
        xobjekt = 'M_ANFR_'.
        xobjtxt = text-503.
      ENDIF.
    WHEN bstyp-best.
      xobjekt = 'M_BEST_'.
      xobjtxt = text-500.
    WHEN bstyp-lfpl.
      IF t160-vorga EQ vorga-lpet.
        xobjekt = 'M_LPET_'.
        xobjtxt = text-505.
      ELSE.
        xobjekt = 'M_RAHM_'.
        xobjtxt = text-501.
      ENDIF.
    WHEN bstyp-kont.
      xobjekt = 'M_RAHM_'.
      xobjtxt = text-501.
  ENDCASE.
  xobjekt+7(3) = 'WRK'.
  xfldtxt = text-523.
  AUTHORITY-CHECK OBJECT xobjekt
       ID 'ACTVT' FIELD im_actvt
       ID 'WERKS' FIELD im_werks.    <-----  

there is a differentiation when it comes to objects (M_RAHM etc.) but none with the sending or receiving plant, it's always im_werks. the activities checked are 01 and 02.

actually, i am no longer surprised: we had a similar discussion about MBST on a STO-PO, see here:

i never happened across this before, because all our STO-PO's are created by MRP (and therefore the very powerful BATCH UserID).

Of course, Alex is correct, this behaviour is illogic ...

Edited by: Mylene Euridice Dorias on Aug 17, 2009 3:08 PM

see also http://www.sapfans.com/forums/viewtopic.php?f=24&t=30987&p=91504&hilit=+M_BEST_WRK#p91504

[Former Member]

Hi Mylene

I have asked my ABAPer to assist by building auth check on supplying plant to make sure that the purch.Group (EKGRP) co-relates with supplying plant. I'll let you guys know once done and functioning as per my needs. obviously it will be a different scenario per business needs.

[Former Member]

If I get some time I will see if I can find out the config of the last place I did it, would be useful to see why we are seeing this behave differently in different systems. (the other systems I did it in were ECC5 or lower so maybe not that valid).

I'll take a look in the IDES system to see if anything jumps out.

[Former Member]

Hi Mdanisi,

that's the best idea, really ... there are no other options, i think. come back when you have it done

[Former Member]

You should generally be investigating config options alongside modifying standard SAP transactions. Your system is behaving differently to many others so it's worth investigating why that is the case.

[Former Member]

Though it might be worth taking a look into this case:

  WHEN bstyp-lfpl.
      IF t160-vorga EQ vorga-lpet.
        xobjekt = 'M_LPET_'.
        xobjtxt = text-505.
      ELSE.
        xobjekt = 'M_RAHM_'.
        xobjtxt = text-501.
      ENDIF.

The coding is a context-sensitive case-check where the object is a variable itself. This means that it must be called from a multiple of contexts. Try to find where it is being called from and what it depends on.

I don't think a transaction context is likely. Customizing would be nice. A PID would be sad

Cheers,

Julius

[Former Member]

note 45243 explains the difference. yes, the note is old - but valid still.

basically: if you define your STO-scenario as a one-step-process, you have to have authorizations for both plants (whether in the same company code or no) ... if you opt for a two-step-process, you only need have authorization for the sending plant - but this is another process entirely! however, this should only affect scenarios where only MM and IM is concerned:

http://help.sap.com/saphelp_erp60_sp/helpdata/EN/4d/2b90dc43ad11d189410000e829fbbd/content.htm

but obviously it does not. it still affects the whole process, even if you work with deliveries, handling units and billing documents - in one company code or across company codes ... even if you are sending the whole thing via IDOC.

the definition whether to use 1 or 2 step is made in view V_T161W.

[Former Member]

Interesting find, thanks. Will update this thread when I find out a bit more about the config in my clients.