Limiting VL10BATCH to Specific Shipping Points and/or Plants in ECC

[Former Member]

Hello friends,

Does anyone know if there are auth objects associated to transaction VL10BATCH in which we can limit by shipping points and/or plants???

Auth objects associated by SAP through SU24 are as follows:

S_ADMI_FCD

S_BTCH_ADM

S_DOKU_AUT

S_GUI

S_TCODE

S_TRANSLAT

None of the above objects are useful for what it is we are trying to do.

Anyone?

Regards,

Marshall

[Former Member]

None of the above are usefull.

What actually happens when the "batch" is processed (?) is a different story....

Whom are you expecting to use this transaction and how often?

Also, I would like to add that transactions which use the current logged on user (system field sy-uname) and make nasty checks, and then schedule business user type processing are in some cases a "brain-****".

It forces either the IT department to have the (full) business access or the business department to have system and support type access.

Su53 and St01 are not completely innocent here either... but immortalizing dialog users in the system is worse.

Cheers,

Julius

[arpan_paik]

Hi Marshall,

VL10BATCH is originated from the transaction VL10X. So when you will create a role with VL10BATCH it will automatically pull objects maintained for VL10X. In this case Object is V_LIKP_VST what do have a check for Shipping point.

However restriction through plant may no be possible. But shipping point sure do by above object.

Arpan

[Former Member]

Thank you both for your intuitive responses...

The auth object V_LIKP_VST is limited by the users respective shipping point, but in Functional test, they are telling me that they can still process the batch to post to the inventory of all shipping points. This is a bit unsettling to us here on our Security team and we are going to submit an OSS Note as there is nothing in their archives currently that address controlling this transaction.

Just thought if anyone knew of some "hidden" auth object that would "tame" this rogue transaction.

Thanks again...!!!

[Former Member]

It's not "hidden", it is just not released yet... or your trace is filtered and not picking up the background job. ST01 is application server specific and background processing can be "load balanced" in several ways.

It schedules a job in your name and to process a certain scenario, namely:

VL10	Default Scenario for Transaction VL10
0001	Sales Orders
0002	Purchase Orders
0003	Sales Orders and Purchase Orders
0101	Sales Order Items
0102	Purchase Order Items
0103	Sales Order Items and Purchase Order Items
0201	Sales Order Schedule Lines
0202	Purchase order item schedule line
0203	Schedule Lines for Sales Orders and Purchase Orders
1001	Cross-System Deliveries
VLHU	Deliver Handling Units
PDON	Deliver Scheduling Agreement with DON (Not Implemented Yet)
500B	Schedule Background Processing (3 Tabs)
500C	Schedule Background Processing (6 Tabs)  "  <-- this is your one!
VL04	Scenario for Transaction VL04 (Upgrade - Only Release 4.6)
QM01	Create Delivery from Quality Notification
2000	Confirm Transfer Orders
UNCO	Check and Combine Unchecked Deliveries
STOA	Automatic Delivery Creation for STO

The application checks only kick in when the job is released and something is processed.

If there is nothing to do, then the authority-checks are a mime in a forest...

Cheers,

Julius

Edited by: Julius Bussche on Feb 3, 2010 7:46 PM

[Former Member]

Thank you Julius...and even though the problem is pending as far as being resolved, I will mark this as "answered" as you did help answer my main question. Which was if there was anyway to control the txn and currently there isn't.

Again, thank you!!!

[Former Member]

No, please leave it open and let us know.

There is already the S_TCODE check on VL10BATCH and the S_BTCH_ADM check, however in the latter case you should take a closer look. The others are "just red herrings" in the navigation and screen programming. You can ignore them.

--> The system first checks S_BTCH_ADM to determine whether it should override the authority of S_BTCH_JOB. It does this EVERY TIME after a check against S_BTCH_JOB is makd, so SU53 will always show it.

One way of working around this problem of periodic job scheduling wizards, is to change the user type of your "order related" batch user (user type SYSTEM) to a DIALOG user and run the wizard with that ID. The scheduler and the steps will be in the name of the batch user, and then you can change the user type and delete the password again afterewards.

In higher releases, you can also subsequently switch the jobstep user to a SYSTEM user and leave the scheduler.

Ideally, you should be able to define the user in the wizard, and it should be checking S_BTCH_NAM in your authorizations to the name of the SYSTEM batch user you choose - and not create dependencies.

Please open the thread and keep us posted.

Cheers,

Julius

[Former Member]

Re-Opening

[Former Member]

To add on to Marshall's response, here's more clarity to the issue. In VL10BATCH, a background variant was created and named for lets say plant ABC. When you select that variant and go into "change variant", through the Values tab, there is a specific shipping point saved for the vairant/plant combo, lets say shipping point 001.

Currently, security allows a user who isn't tied to plant ABC to go into the values tab, enter or change any of the settings, shipping point, DN create window value, etc. and save that new information. This causes obviuos issues.

What we are looking for is a security solution to only allow users that are working in plant ABC to change values in that specific variant, thanks.

[Former Member]

Not possible, to my knowledge.

What you can do is add an authorization group to report RVV50R10C and control via S_PROGRAM p_action VARIANT for the report group whether the variant can be changed or not. See report RSCSAUTH documentation for this.

That way you can define the variants by a variant admin "centrally" and the users can only start and (possibly) release them, but not change or create new ones.

For the actual batch job administration it is often the same approach as well -> make sure that object S_BTCH_ADM is not authorized beyond your batch and system administrator users.

Worth a try, and much easier than coding screen exits and validations into the variant maintenance. RSCSAUTH also supports upgrading the system and restoring the values!

Cheers,

Julius