2 Logical Components for 1 Business Process Step

[Former Member]

Hello All,

I'm looking for a way to assign in SolMan --> transaction Solar01 - Tab Structure - Business Process Step, 2 logical components for 1 business step. When creating the business step I have to assign 1 specific logical component to this step. Once I have done this I can only select the chosen logical component ffor SAP Transactions, configuration object etc.. As my business step is running on 2 different systems I need to find a way to link transactions etc. in the step to the different systems. Is there any way to change this for the Level 3 elements, like it is for level 2 (business processes) where I can choose in the different tabs between all the logical components?

Thanks in advance

Ramó

[Former Member · Accepted solution]

I agree with Jason. The way the BPS is built is to assign a business process step(a transactional step) to which logical component it is meant to run on.

To give you an example of purchase requisitioning process where it can be either in ECC or SRM you can do either of the following.

Process name: Purchase requisitioning (one process two process steps)

Process steps:

Create PR in ERP ME51N ZECC

Create PR in SRM ZSRM

Alternatively you can have two process names.

Process name: Purchase requisitioning in ERP

Process step:

Create PR in ERP ME51N ZECC

Process name: Purchase requisitioning in SRM

Process step:

Create PR in SRM ZSRM

Hope this helps.

-

Kathir

[Former Member · Accepted solution]

Hello Jason, Kathir

First of all, thanks for your answers. Our system landscape consists of ECC and CRM system for the template project. We are facing the issue that a business step will be executed both on the ECC and the CRM and we need to assign transactions, customizing objects to the step . Thatu2019s why I would need to have both components available in the step. I already though about modifying the BPS, but I was wondering what other option would be available.

Kind regards,

Ramó

[Former Member · Accepted solution]

OK well this is a lot easier than if you had 2 production systems like I imagined.

Since you have two different system types it means you haven't broken up your steps enough. You want to keep these seperate from one another. You just have to get more granular. It's no different than how you would model the process in a swim lane diagram in Vision.

If you need help, post an example process and we'll help you break it up.

regards,

Jason

[Former Member · Accepted solution]

Hello Jasons,

The problem for us is that we canu2019t not add another business level as we have already 5 Level created via naming convention. Just to give you an idea:

1. business scenario u2013 business process level one

2. business processes u2013 business process level two / three

3. business processes step u2013 business process level four / five

So if I come back to now to your idea about the 2 production systems, it would be somehow similar. Could I ask you on how the template or the system role could be used as a work around?

Thanks!

Kind regards,

Ramó

[Former Member · Accepted solution]

Hello Jasons,

The problem for us is that we canu2019t not add another business level as we have already 5 Level created via naming convention. Just to give you an idea:

1. business scenario u2013 business process level one

2. business processes u2013 business process level two / three

3. business processes step u2013 business process level four / five

So if I come back to now to your idea about the 2 production systems, it would be somehow similar. Could I ask you on how the template or the system role could be used as a work around?

Thanks!

Kind regards,

Ramó

[Former Member · Accepted solution]

I've seen people use some absolute craziness to get more than three levels. The most extreme being using multiple projects at the highest level (i.e. a project for PTP Accounts Payable). Don't go there.

I personally like to have 1 transaction per process step. Don't use the transaction tab as another process level, use it to better describe the process step (like all the other tabs are uses). It results in a better understanding of the system as you go forward. To do that I make teams break up things they think are one step (this can take some arm twisting, so hit the gym and maybe take a few judo classes).

This allows you to use SolMan in more powerful ways. For instance, if you attach development objects to a step with 5 transactions, you cannot tell which transaction is modified by the development object. However, one transaction per node provides you this link. There are other examples, but basically the "where used" button becomes very useful when you have 1 transaction per node.

Maybe you could provide a specific example of your process and we can think of a better way to collapse it.

Such as:

- PTP Non-Merchandise Purchasing

-- Expense Purchasing

--- Create Purchase Requisition

--- Create Purchase Order (Assign Vendor & Price)

--- Send to Vendor

--- Post Goods Receipt

--- Perform LIV

--- Process Payment

Some companies have 6 level processes already defined in models and putting it into SolMan can be a pain for sure. Your naming convention is usually the best route.

regards,

Jason

The system role and template work around doesn't apply to your situation.

[Former Member · Accepted solution]

Hello Jason,

thanks for your answer and the way you were describing the different kind of thinks to take into account. As you already highlight out, I will push for the naming convention solution.

Kind regards,

Ramó

[Former Member]

Hi Ramon,

You can't have 2 logical components for 1 step. Can you explain your system landscape and how you are using SolMan please? There is probably a work around with a global template, new system role, or a modified BPS.

regards,

Jason