Introduction

Organizations play a central role in Intershop Commerce Management. Many of the features, such as features regarding order handling or the management of product repositories and catalogs, are closely tied to and organized around the organization concept.

This document gives an overview of the overall organizational model and illustrates important relations between different organizations.

Organizations

Organizations represent sales or partner organizations. They

• sell goods and services over direct and indirect channels to customers, consumers, and partners
• provide content to customers, consumers, and partners (mainly catalogs, but also marketing material and other content)
• receive transactions for fulfillment
• forward transactions to other organizations or to external systems for fulfillment.

Additionally, each instance of Intershop Commerce Management hosts one Operation organization. Users of this organization are responsible for main system administration tasks, such as:

• creating accounts for root sales organizations
• maintaining contact information that belongs to each root sales organization on the system
• maintaining central system resources

A typical Intershop Commerce Management installation hosts at least one root sales organization (also referred to as the enterprise or sales organization) and multiple child sales organizations (also referred to as partner organizations). The set of organizations that are hosted forms a hierarchy. This hierarchy can be modeled as a tree structure which obeys the following constraints:

• There is one root organization on top of the hierarchy.
• Multiple root organization can exist in parallel. These organizations (and the hierarchy of organizations which they dominate) are completely independent from each other and are maintained by Operations users.
• Organizations can have multiple child organizations. However, they do not necessarily have child organizations. They can be leaves within the tree.
• Such a child organization can have only one parent organization.
• A parent organization only has access to its child organizations.

Organization Type Codes

Type codes are used to distinguish organizations. Root organizations (enterprise or sales organizations) have the type code 20. Organizations which are partner organizations have the type code 30. An anonymous organization of a sales channel uses the type code 50. The Operations organization has the type code 10. The type code is a simple attribute of the organization instance.

Organization Structure

Organizations are grouped as a tree. The root of the tree is Operations which owns the corresponding sales organization instances (enterprise organization). Each root sales organization instance spans its own domain which owns the business objects of the enterprise organization (like catalogs, users, departments). See the figure below for an illustration of these relations.

Departments

Larger organizations usually have an internal structure that needs to be supported by Intershop Commerce Management to allow efficient implementation of the organization’s selling strategies (i.e., user groups and permissions). Intershop Commerce Management supports departments as structuring unit and exposes a fine-grained and powerful system of access privileges to manage the assignment of users to departments as well as user access to business objects.

Departments are used to structure different organizational units within a single selling organization. Departments can be arranged in hierarchies. Each department can have an arbitrary number of sub-departments. Similar to organizations, each of this sub-department has exactly one parent department. Typical examples for departments are Sales, Marketing, Production.

Sales Channels

Sales organizations (both, enterprise and partner organizations) can set up multiple sales channels to share/syndicate products and other content to partners and to sell to customers and consumers directly. In general, channels are used to
• enable different business models
• target different types of business partners
• target different regions
• use different brands
A channel is always owned and maintained by an organization. Channels cannot be shared between organizations.

Conceptual View

At a conceptual level, a channel is represented by a repository that contains business objects (e.g., products). The channels are supplied with products from a central product repository of the organization which has created (and hence owns) the channel. Catalog management is based on two types of product repositories:

• Master Repository: Each sales organization can set up a master repository (but not more than one). The master repository is managed by the master catalog manager. Its products can be shared or syndicated into the available channel repositories.

• Channel Repository: Channel repositories are defined in the context of a channel and are managed by the respective channel catalog managers. Channel repositories contain all those products that are to be made available to the partners, customers or consumers set up within the channel. Each channel has one channel repository. Since an organization can set up multiple channels, multiple channel repositories can exist.

Implementation View

From an implementation point of view, the following concepts are important:

• As mentioned above, a channel is always represented by its channel repository. There is no special "channel object".
• Channel repositories are represented by domains, more specifically: by units. Hence, creating a new channel also means to create a new channel repository unit. Consequently, a channel has the representation of a unit in the shared file system (i.e., import sources).
• Each channel repository is represented by exactly one instance of the repository persistent object. The PO instance is located in the domain that owns the repository. There can only be one repository instance per channel.
• A repository owns instances of products. The repository does not define any explicit structure on the product instances (e.g., through catalog categories).
• Sub-organizations are assigned to a channel by creating the respective organization instances within the domain of the channel repository.

Use Channels Structuring the Organization

First, how to use channels to structure an organization is not carved in stone. Obviously a channel is used to bundle a management application and the according storefront application. When planning a custom installation you will be confronted with the question: Should I implement a new channel, or just create a new application inside an existing channel?

The short answer is: It depends on your business model.

If you want to use partner organizations (e.g., like Myers in Intershop's demo shop inSPIRED) you strictly have to use a partner channel. A partner organization can only be set up inside a partner channel (see section Concept - Organization#Channel Types for details).

From a B2C perspective you should use another channel for a different language. Usually there are approval and completeness checks for products and content. So it is useful to manage the products, the content and the responsible users (Shop Manager, Content Editor, Approver etc.) in one channel. You may consider to bundle countries or regions using the same language into one channel, but there are also other things to consider which are mainly the used currency and taxation policies. So as a rule of thumb one might say:

In B2X business models, where you basically sell the same products via a B2C and a B2B application, you may use a single channel but different application types. Otherwise, if the product range is very different you should consider to use these applications in different channels.

If your business model is build upon different brands (e.g., a standard brand and a noble brand) you usually want the storefronts to be very different. So there should be a lot of different content and completely other marketing activities (promotions and campaigns). The more such differences are pronounced, the more likely should you use another channel. You may note that is this a vice versa relation. If you use the same promotions and campaigns in all of your storefront applications no matter what brand they are for, you should use a single channel approach, because you can re-use the promotions etc. of your channel in every application of the very channel.

Sometimes it might be useful to strictly model your commerce organization alongside the real-world organization. Especially if you are not done selling the product, but provide services (e.g., maintenance and repair in contract workshops) your organization uses sales territories. So if there is one sales team per territory it might be a good idea to use an separate channel for such region.

Of course there are also disadvantages using multiple channels. These are mainly additional efforts when it comes to:

• Data replication
• Search index generation
• Customer sharing (e.g., for a centralized CRM)

Also note, as already been said, the re-usability of marketing content is strongly restricted. You can re-use content itself, even the promotion. This means the promotion condition and the promotion action. But when it comes to promotions the "real magic" is not in the rules, but in their assignment to customers, customer segments, catalogs, products etc. Usually they are not the same in different channels. If they were you should rather use two different applications in one channel (e.g., a standard web shop and a mobile application).

Channel Types

Each sales channel is of a specific channel type. This type distinguishes between partner channel and customers/consumers channel. Intershop pre-defines certain sales channel types. The pre-defined channel types are:

• Partner Channel- channel for sales partners (type code 32)
• Sales Channel- channel for consumers. (type code 52)

To express the channel type, type codes are used (see the type codes listed above). The type codes are assigned to the channel repository which represents the channel. Among other things, the channel type determines which types of organizations can be assigned to the channel. For example, using this mechanism a partner organization cannot become a member of a sales channel.

Channel Domain Structure

A channel (i.e., a channel repository) is always represented by a database entry (table REPOSITORY) and by a domain. The repository instance belongs to the domain of the organization that owns the channel. All members of a channel (= instances of child organizations) are owned by the domain of the channel repository. Since each channel repository has its own domain, channel-sensitive import/export processes can be implemented easily.

Sites and Applications

Users can access the system by using applications. Applications run within the context of a site.

There are two main types of applications:

• Management application- Applications of this kind (e.g., EnterpriseBackoffice, PartnerBackoffice, B2CBackOffice) are used for managing the back office/storefront data. The back office user can switch between the working contexts he has permissions too.
• Storefront application- These applications (e.g., B2CWebShop, SMBWebShop) provide storefront access for the end user by defining touch-points. The content of a storefront application is governed by a corresponding management application.

Common to both application types is, that a application type defines the code that is executed. Additionally, applications have domain relations which define the repository and data that is used/managed by the application.

Example inSPIRED

The demo shop defines the sales organization inSPIRED. It contains two sales channels, inSPIRED-inTRONICS(B2C) and inSPIRED-inTRONICS_Business(B2B), and a partner channel. All three have their own channel repository with a spanned domain. The partner channel domain hosts the partner Myers, which has of course its domain, MasterRepository and B2C channel.