The B2B Extension Module extends applications of the types intershop.SMBWebShop and interhop.B2CBackoffice with additional B2B functionality.
The content of the present document is valid for the following combinations of software versions:
B2B Module | Intershop 7 |
---|---|
1.0 | 7.3 |
1.1 | 7.4 |
1.1.1 | 7.4 CI |
The B2B Extension Module supports roles and permissions for storefront users.
The table below lists the introduced permissions.
Permission ID | Description |
---|---|
APP_B2B_PURCHASE | Permission to purchase products |
APP_B2B_MANAGE_USERS | Permission to manage the users of the customer |
APP_B2B_ORDER_APPROVAL | Permission to approve pending orders |
APP_B2B_MANAGE_OWN_QUOTES | Permission to create and use own quotes |
APP_B2B_MANAGE_BRANDING | Permission to manage the branding |
The table below lists the introduced roles and their assigned permissions.
Role ID | Description | OilCorp User | PURCHASE | MANAGE USERS | ORDER APPROVAL | MANAGE OWN QUOTES | MANAGE BRANDING |
---|---|---|---|---|---|---|---|
APP_B2B_BUYER | The B2B buyer. | jlink | |||||
APP_B2B_APPROVER | The B2B approver. | pmiller | |||||
APP_B2B_ACCOUNT_OWNER | The B2B account owner. | bboldner |
The overview page of My Account has been adjusted to behave like a dashboard for B2B users. The roles described above determine the information to be displayed.
The following sections are available:
Role: Buyer
Role: Approver
Role: Account Admin
The navigation section on the left side of My Account has been extended. Now it:
While there are more complicated processes possible, the current implementation is intentionally kept simple.
The current implementation recommends that the user is logged in before doing anything. After logging in, the user can:
The current implementation supports the following administrative tasks:
The B2B Extension Module introduces a complete management section for customer users.
In addition to creation and deletion of users, managing a single user includes role and budget settings as well as profile settings.
The profile dialog now features a checkbox for controlling the active flag. That is, it is now possible to enable and disable a user directly in the storefront.
At business object level, the entire role management is covered by two business object extensions. With extending CustomerBO
, CustomerBOSecurityExtension
provides the functionality to ask a customer for its roles as well as to obtain all users that have a certain role or to look up a role by its ID. The purpose of UserBORoleExtension
is to assign and retrieve a role to and from a user.
When a user is created in the customer section of the back office, it is automatically given the account owner role, APP_B2B_ACCOUNT_OWNER
. The corresponding pipeline of the B2B back office plugin, ProcessCustomerUser_52
, provides an extension point CustomerUserCreated
, which is extended by the pipeline CreateCustomerUser-Start
in bc_b2b_ext. The corresponding extension is CreateCustomerUser.extension
in app_bo_ch_sales_b2b_ext.
Upon user registration in the storefront, the created user is granted the account owner role of the customer created at the same time. Again, as with the user creation via the back office, CreateCustomerUser-Start
is used to extend the standard user creation process. In this case, however, the extension point UserRegistered
of the pipeline ProcessUserAccount
in sld_ch_sf_base is extended.
The job ResetMonthlyBudgetsSpentJob
, which has been created during the database initialization (DBinit), takes care of resetting all monthly budgets spent by users. The job therefore iterates through all applications, their defined customers and the users once a customer is identified as a group customer (or "container" of users).
By default, the job is disabled. You can define the execution schedule of the job using the Schedules module of the SMC (root
domain). See the setup example below.
The order templates feature of the B2B Extension Module is, basically, an adapted wishlist feature.
Note
The order template functionality resembles the wishlist functionality. Therefore, an application that uses order templates cannot use wishlists.
Currently, there are the following differences between order templates and wishlists:
The checkout process has been extended by a simple approval process. It depends on the following criteria whether the current order needs approval or not:
(see UserBOOrderApprovalExtension
)
If an approval is required, the system displays according messages on order review pages and order confirmation pages.
The order appears on the Pending Orders list of the buyer and on the Orders To Approve list of all users with the permission to approve orders.
It is possible to add multiple products to the cart at once through providing pairs of product ID and quantity via the Quick Order functionality.
By default, the user can add 10 products. Clicking Add 5 Lines extends the form with five additional lines, each with two pairs of product ID and quantity. Using the CSV import, you can import a configurable number of products (see pipelet properties of the pipelet TransformCSVFileToInputPairs in the pipeline ProcessQuickOrder) in a single step, just by providing a CSV file.
The quick order functionality was also implemented on the cart page with the restriction of only one product at the time.
To allow business customer specific pricing and catalog filters, price lists and catalog views can be assigned to business customers. The assignment is done via a hidden customer segment, HG_<CustomerNo>
. The assignment is valid for all users that belong to a business customer.
The assignment is done in the back office. To this end, it features two new tabs, Price Lists and Catalog Views, in the customer detail view:
There is no need to implement new features. The customer specific assignment is just an abbreviation for the following:
A user with the role account admin can upload an individual branding logo, visible for all logged in users of a customer.
Note
Currently, this feature is not supported with enabled page caching.
A logged in user can save an item from the cart in a special list in order to save it for later. This Save For Later List is displayed at the bottom of the cart. Later, the user can move an item from this list to the cart or remove it from the list.
This functionality is implemented using a special wish list, which is not displayed within the Order Templates section of My Account.
The order search within the Order History of My Account has been improved by adding a search for order number or purchaser name.
The checkout shipping page provides a new section with an input field for the desired delivery date. In addition to a date validation, a branded calendar has been implemented for picking up a date.
The date is saved as basket attribute value (table BASKET_AV).
The external price provider illustrates how an external system can be used to query a product price. This is done using a managed service. In addition, there has been implemented a product price provider. For demonstration purposes, there is a price look-up from a CSV file. Generally, it is possible to implement calls to external systems.
ProductPriceProvider
and ExternalProductPriceProviderImpl
have been implemented and registered. This makes sure that Intershop 7 uses ExternalProductPriceProviderImpl
to look up a price. This provider has been set to the first position. This means, if the price query is not successful, other registered price provider(s) are called.ExternalProductPriceProviderImpl
calls the external price service. It will get this information from the ServiceConfigurationBORepository
. For more details, refer to bc_pricing_external...services.component
.null
. This is necessary to indicate that there is no price found.The externalPrices.csv file, which is used for demonstration purposes, is stored in $IS_SHARE/sites. It has the following structure:
CustomerID;ProductSKU;PriceUSD "null";"4011592";50 OilCorp;"4011592";52
null
, the price is returned for all customers.The price provider delivers more detailed information as used in the show case. Prices from previously called price providers are available.
The price provider may use the managed service to use its monitoring and logging capabilities. For this simple example, a direct query of the CSV file would be easier. The strength of a managed service is its monitoring and logging capabilities. This is recommended for calling external systems.
The user can provide additional information on the checkout review page:
The information is saved as basket attribute values (table BASKET_AV
). At business object level, the information is handled via an extension of the BasketBO
.