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 represent sales or partner organizations. They
Additionally, each instance of Intershop Commerce Management hosts one Operation organization. Users of this organization are responsible for main system administration tasks, such as:
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:
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.
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.
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.
Departments (as a means to structure an organization internally) are available to selling organizations only. Intershop Commerce Management does not support departments for buying organizations.
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.
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:
The term channel repository can be conceived of as a synonym for channel. In fact, creating a new channel means to create a new channel repository. An organization can have zero to n channel repositories because they can have zero to n channels.
From an implementation point of view, the following concepts are important:
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).
One partner organization - One partner channel!
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:
One country - One channel!
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.
One product assortment - One channel!
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.
Encouraged to consider
One brand - One 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.
Encouraged to consider
One sales team - One channel!
Of course there are also disadvantages using multiple channels. These are mainly additional efforts when it comes to:
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).
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:
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.
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.
Users can access the system by using applications. Applications run within the context of a site.
There are two main types of applications:
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.
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.
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.