[salsharm]

Hi,

We are working on an OTM opportunity and I have following requirement:

Parent Company C1 has three different divisions D1, D2, and D3 located in three different continents (say Asia, Europe, and North America respectively). All of these divisions have inbound and outbound shipments across the globe. For example, one supplier based in America may ship material to all three divisions. On the other hand, all three divisions may ship to a customer in Europe.

Now the parent company C1 wants to be able to do centralized shipment planning globally, but still restrict the visibility of data to individual divisions for their own division only. That means that a user in D1 division should have visibility to data pertaining to its own division only and not to the data of other divisions. But planner at parent company should have visibility to data of all the divisions so that economies of volume can be achieved through centralized planning.

Another requirement is that administrator at parent company C1 should have the flexibility of granting and restricting access to any data to different users at will.

Can anybody elaborate how to achieve this in OTM? Any help is highly appreciated.

Regards,
-Salil

[bob_romijn]

Hi,

It seems to me that you want to create a parent domain for C1, and the D1,D2 and D3 are subdomains from this parent domain.
Challenge will be to give the right grants.

Buy shipments will be build in your parent domain. Sell shipments will be build in the sub domain. To give your subdomain users visibility to their orders/shipments you have to copy the events doen on the buy-side to the sell-side (agent action).
If you give visibility to the buy-shipment, your customers also see the other subdomains on that shipment.

[salsharm]

Hi Bob,

Thanks for your insight. I have few things that I need to know further. Is it possible to achieve my scenario by keeping all the divisions in the parent company in one single domain and then using VPD to create specific views for individual division users?

Regards,
-Salil

[bob_romijn]

Hi,

I never tried it, but my feeling is that it should be possible. You have to make the difference to your division for example by "Corporation".
Then you can create a VPD looking at that value for each user profile.
I don;t think you will discover too many problems regarding your orders (base or release).
The challenge will be the visibility to the shipments. My assumption is always that a buy-shipment can be shared by the divisions (perhpas not now, but everybody tries to save money and consolidate as much as possible). In that case you don't want to show the "division"-users the buy-shipments.
Then you should create a VPD instruction to give only access to sell-shipments where their orders are on. Never tried that, but that will be your challenge.

[salsharm]

Thanks Bob for your thoughts on this.

[krishna.kk]

Hi Bob ,

I have a Similar scenario .

I failed to understand why the buyshipmnet will be created in the parent domain and sell shipment in the child domain .

Does this mean there will be diffrent sell shipments created for one buy shipment .

(For sell shipment we need to have a diffrent itinerary)

Rgds
kishore

[bob_romijn]

Hi,

Buy shipments will always be built in your parent domain (even if you have a 5 deep child domain structure).

Look at this to understand:
- Each customer is a child domain of logistics company which is the parent domain.

As a logistic company you want to have savings by combining several customers in an equipment. Then it is mandatory to have it in one shipment. For that shipment you have to hire a carrier (buy) to do the job. Because it needs to be in one shipment it is the reason why buy-shipments are always built in the parent domain.

With all this saving in transportation you also need to send a bill to your customer for getting paid something (mandatory to survive in transport ). You don't want to have the customers to have also visibility to orders from another customer. Because you want to build seperate shipments from the orders on the customer side to get something paid (you sell something), you need to consolidate a bit different. For the consolidation and visibility the sell shipment is always built in the customer (child) domain.

It is not always neccesary to have another itinerary for this sell side. You can set an ititnerary to be used for buy, sell or both. An itinerary is not child-domain specific as I recognised.

If this still doesn't give any clarity please ask again.

[ianlo]

Hi Salil,

We are currently using this approach for a multi-site implementation (central planning site & decentralised site execution)

One thing you need to note is the sell shipments. Although they are generated at the site level (I don't know why they can't be generated in the same domain as the buy - i.e. central) managing the visibility of these sell shipments can be tricky as they may have the same sell shipment id but different domains - making identification quite a challenge

Are you having to cross-charge across divisions? or is the reconciliation done at the central level? We tried to consider cross charging but it was deemed too complicated. Hence we ended up doing sell side reconciliation at the central level.

Also please note that you may encounter some bugs with "centralised" planning as I am encountering them as we speak with regards to ERUs.

Can't seem to get OTM to apply ERUs when planned at the central level.

[ianlo]

Originally Posted by bob_romijn

Hi,

With all this saving in transportation you also need to send a bill to your customer for getting paid something (mandatory to survive in transport ). You don't want to have the customers to have also visibility to orders from another customer. Because you want to build seperate shipments from the orders on the customer side to get something paid (you sell something), you need to consolidate a bit different. For the consolidation and visibility the sell shipment is always built in the customer (child) domain.

Hi Bob,

Thanks for the explanation. However, in my case, sell side billing and reconciliation is a function of the "parent" domain because to the customer, regardless of how many legs (shipments) executed by the "child" domain, the customer only wants to be billed once - hence 1 sell shipment.

It is difficult to "gather" all the sell shipments from the "child" domain for consolidated billing. Rather, wouldn't it be more natural to allow users to choose where the sell shipment is to be built?

Another consideration is if there is a consolidated shipment with multiple legs, and each leg is executed by a "child" domain, the sell shipment would need to be built at the "parent" domain so that the orders can be easily linked together for a single consolidated bill to the customer.

Have you encountered such a scenario and what was the model applied?

Thanks!
Ian