Getting familiar with the E-commerce Solution

Abandoned shopping cart

Abandoned shopping cart is a shopping cart that the customer did not use for making a purchase. For example, a visitor browses through your on-line store, puts some products in their shopping cart but then changes their mind and leaves without buying anything. The visitor’s shopping cart is then considered as abandoned.

You can then use abandoned carts to reach out to the visitors. For example, you can send them an email to remind them that they want to buy something.

Abandoned shopping cart is not any specific object or type of shopping carts in the database. You can set a scheduled task that creates an activity for every abandoned shopping cart. When you then set a marketing automation process that uses the created activity, you can send them an email.

Learn more in Walkthrough - Sending an automated reminder of an abandoned shopping cart. You can also customize the way the system recognizes abandoned shopping carts, see Customizing marking shopping carts as abandoned.

Anonymous customers

Customers who have purchased something, but have not registered in the store.

Learn more in Customers.

Anonymous customers are stored (as well as registered customers) in the COM_Customer database table. However, they do not have assigned any user (in the CustomerUserID column), the value is NULL.

Billing address

Billing and shipping addresses are addresses used for orders. The billing address is an address that sets the payer of the order.

Based on billing and shipping addresses, you can then set shipping prices or further alter orders. Customers can select their address in the Customer address web part. Learn more in Reference - Checkout process web parts.

Billing addresses are (as well as shipping addresses) stored in the COM_Address database table. Technically, the billing and shipping addresses are the same and are interchangeable. If the address has already been used in an order, you can find the address also in the COM_OrderAddress table.

The potential “duplication” of information is to prevent retroactive changes of orders. Customers are enabled to change their saved addresses (in COM_Address). If orders had used the same table and customers had changed their address, the order’s address would also change. Therefore, orders use their own address table (COM_OrderAddress), which can be changed only through the administration interface while editing an order.

Bundles

A special type of products. Bundles are basically packs of multiple products.

For example, when you want to sell a complete package for making coffee, you can sell a grinder, a brewer and coffee itself and sell it as one bundle. Alternatively, when you want to sell a special edition of Lord of the Rings movies, you can add Blu-rays of all movies, a map of Middle-earth and a One Ring replica to one bundle.

Learn more in Managing Bundles.

One of the product representations in Kentico. Bundles are stored in the COM_SKU database tables as well as other types of products. Besides that, IDs of products offered in the bundle are connected to the bundle’s ID in the COM_Bundle database table.

Buy X Get Y discounts

A type of discounts. Buy X Get Y discounts have a wide range of uses. You can use them when you want to add a gift to specific products or offer discounts like 2+1 free. You can manage all Buy X Get Y discounts in the Buy X Get Y discounts application.

Learn more in Working with Buy X Get Y discounts.

Buy X Get Y discounts use multiple database tables:

• COM_MultiBuyDiscount – with core properties of the discount and the “Get” properties
• COM_MultiBuyDiscountSKU – the “Buy” properties if the discount is applied to specific products
• COM_MultiBuyDiscountDepartment – the “Buy” properties if the discount is applied to whole departments
• COM_MultiBuyCouponCode – discount coupons of those Buy X Get Y discounts which are applied only after typing a coupon code

See Customizing evaluation of Buy X Get Y discounts and Customizing application of Buy X Get Y discounts to learn how to customize Buy X Get Y discounts to support other scenarios.

Catalog discounts

A type of discounts. Catalog discounts cheapen selected products to all customers, registered customers or registered customers in selected roles. You can manage them through the Catalog discounts application.

For example, with catalog discounts, you can create loyalty bonuses, flat discounts for partners, set price levels, etc.

Learn more in Working with catalog discounts.

To create catalog discounts, you need to create a discount rule based on which the discount is applied.

Catalog discounts are stored in the COM_Discount database table along with order discounts and free shipping offers. Catalog discounts are recognizable by having Products in the DiscountApplyTo column.

Checkout process

Checkout process is a customer’s journey that starts with putting a product to the shopping cart and ends with creating an order.

Checkout process is a set of pages where customers prepare their order – the shopping cart, billing and shipping information, payment method selection, etc. Checkout process ends right before creating an order object and saving it to the database. From this time, it is referred to as an order.

Customers cannot pay while they still go through the checkout process. Customers pay for their orders after an order is created.

Coupons

See discount coupons.

See discount coupons.

Currencies

With money of a specific currency, you can pay for products in your order. You can create an on-line store with multiple currencies or have multiple sites with different sets of currencies. Every site has then its main currency in which store administrators type prices in the administration interface.

You can change currencies in the Store configuration or Multistore configuration application on the Currencies tab. Learn more in Configuring currencies.

Currencies are stored in the COM_Currency database table. Since they can be both global and site, you can see NULL or the site ID respectively in the CurrencySiteID column.

Relationships among currencies are expressed with exchange rates. Exchange rates ensure the ratio when recalculating an amount of money from one currency to another.

Customer credit

A payment method. You can enable registered customers to have their credit and then pay with the credit for their orders. You can modify customers’ credits in the Customers application on the Credit tab (available only for registered users).

You can configure customer credit as a payment method in the Store configuration or Multistore configuration application on the Payment methods tab. Learn more in Configuring customer credit.

All customer credit transactions are stored in the COM_CustomerCreditHistory database table. The credit is connected to the customer via the EventCustomerID column with the customer’s ID. If the credit is connected to a specific site, the EventSiteID column contains the site’s ID. If the credit is global, the EventSiteID column contains NULL.

Customers cannot pay for an order partly with their credit and partly with another payment method.

Customer details

Customer details are information about a customer like their name, phone number, email address, etc.

You can edit customers’ details in the administration interface in the Customers application.

You can let customers to change their own details on the live site. Place either the My profile or Customer detail web part on a page. The My profile web part is suitable for a My profile section where customers–users can modify their details, see their orders, etc. The Customer detail web part is on the other hand more suitable for the checkout process.

Customers

Customer is a person or a company that has purchased something in the past in your on-line store. Customers can be either registered or anonymous.

Learn more in Customers.

All customers are stored in the COM_Customer database table.

If the customer is registered, the customer’s properties are synchronized with their user account. Learn more in Synchronizing customer and user properties.

Departments

Departments are one of the possibilities when categorizing products. Departments are only logical categorization (departments provide no display differences if not configured otherwise).

With departments, you can assign taxes to new products in a specific department automatically.

Departments are stored in the COM_Department database table. If you assign default tax classes to a department, a new record in the COM_DepartmentTaxClass is created with the department’s and tax class’s IDs.

Discount coupons

Discount coupons are basically codes that customers need to type during the checkout process to obtain a discount. If a customer does not type the required coupon code, they are not eligible for the specific discount. You can use discount coupons when using:

• Buy X Get Y discounts
• Free shipping offers
• Order discounts
• Product coupons

Discount coupons are stored based on the discount they are related to. Buy X Get Y discounts use the COM_MultiBuyCouponCode database table, the product coupons use the COM_DiscountCoupon table and the other discounts that use coupons are stored in the COM_CouponCode table.

Discount rules

Discount rules are rules that need to be fulfilled in order to apply the discount. For example, when you want to discount those orders which are sent to the USA.

You can configure them when creating or modifying a discount. Discount rules are used for Buy X Get Y discounts, order discounts, catalog discounts, and free shipping offers.

Discount rules are customizable via the administration interface. You can add or remove them in the Store configuration or Multistore configuration application. See Configuring discount rules to learn more.

Discounts

Discounts are a way to promote your store and your products. Discounts cheapen your products or shipping, which you can use to encourage your potential customers to buy something. Kentico offers several types of discounts:

• Buy X Get Y discounts
• Catalog discounts
• Free shipping offers
• Order discounts
• Product coupons
• Volume discounts

Learn more in Discounts.

Discounts in Kentico are a decentralized system. Therefore, you can find discounts in several database tables.

See a specific discount type to find out more details about the discount.

Donations

A special type of products. Donations act as a standard product, i.e., you can add it to the shopping cart and pay for it when going through the whole checkout process.

For example, you want customers to be able to donate some money to charity along with a purchase of other stuff. You then add a donation product to the store and probably with a banner, you notify your customers they can add the donation to their shopping carts.

Learn more in Managing Donations.

One of the product representations in Kentico. Donations are basically standard products in the COM_SKU database table but have DONATION in the SKUProductType column.

E-products

A special type of products. E-products are like standard products but they are electronic (intangible) and downloadable. E-products are therefore suitable for e-books, files (images, audio, video), apps, etc.

Learn more in Managing E-products.

One of the product representations in Kentico. E-products are basically standard products in the COM_SKU database table but have EPRODUCT in the SKUProductType column. They also have linked their downloadable files in the COM_SKUFile table. In the FileSKUID column, there are the files’ product IDs.

You can find links to the e-products already bought in orders in the COM_OrderItemSKUFile table.

Exchange rates

Exchange rates express the ratio for recalculating an amount of money from one currency to another currency. For this recalculating, Kentico uses exchange tables with all required rates in the tables. You can edit the exchange tables in the Store configuration or Multistore configuration applications on the Exchange rates tab.

Learn more in Configuring exchange rates.

Exchange tables are stored in the COM_ExchangeTable database table. You can see whether a specific exchange table is global or site by checking the value in the ExchangeTableSiteID column. Global exchange tables have NULL in the column; site exchange tables have the table’s site ID.

A table’s exchange rates are then stored in the COM_CurrencyExchangeRate table. They are connected to the table ID with the ExchangeTableID column.

Formatted price

Formatted price contains not only the nominal amount but also a currency code or other text and styling configured in the settings.

Formatted price is suitable for any page where customers can see the price. Customers are not therefore confused about the currency. See Configuring currencies to learn more about configuring currencies and the Currency formatting string currency property.

Formatted weight

Formatted weight contains not only the nominal amount but also a weight unit or other text and styling configured in the settings.

Weight is used mainly for products and shipping option price levels. See Configuring products to learn more about configuring products or see directly Settings - E-commerce to set the Mass format string setting.

Free shipping offers

A type of discounts. Free shipping offers enable customers to have free shipping for their purchase. You can manage them through the Free shipping offers application.

You can limit a free shipping offer based on orders’ properties (prices, currencies, billing or shipping addresses, shipping, weight, etc.) or type of customers, duration, or enable the offer only when the customer types a discount coupon code.

Learn more in Working with free shipping offers.

To create free shipping offers, you need to use a discount rule based on which the free shipping offer is applied. If your desired rule is not predefined, you can create your own, see Configuring discount rules. Free shipping offers and order discounts use the same set of discount rules.

Free shipping offers are stored in the COM_Discount database table along with catalog discounts and order discounts. Free shipping offers are recognizable by having Shipping in the DiscountApplyTo column.

Global objects

Global e-commerce objects are those e-commerce entities that are set for all sites. For example, products, product options, manufacturers and suppliers, payment methods, tax classes, or currencies. Some of them can be used along with the site objects, some of them replace the site objects.

Learn more in Choosing site or global e-commerce configuration.

Global objects have typically NULL in the database where the site ID usually is, or a specific database column is used to label objects as global.

Global settings

Global e-commerce settings are settings related to the E-commerce Solution and are used for all sites. You can find settings under the Store settings tab in the Multistore configuration application. They serve as setting simplification for multisite stores.

Learn more in Choosing site or global e-commerce configuration.

Settings are stored in the CMS_SettingsKey database table. Global settings have NULL in the SiteID column, where the site ID usually is.

Invoices

Invoice is a confirmation of a purchased order. The invoice appearance is editable in the Store configuration or Multistore configuration applications.

Learn more in Configuring invoices.

Invoices are printable confirmations that you can browse in the system. If you want to send invoices by email, you need to specify it in the specific email notification. Learn more about e-commerce email notifications in Configuring e-commerce email notifications.

Main currency

Main currency is a currency used by store administrators to type prices in the administration interface. Each site has its own main currency or a site can use a global main currency if the site uses global currencies.

Main currencies are distinguishable from other currencies by the CurrencyIsMain column in the COM_Currency database table, where all currencies are stored.

Manual payment methods

A type of payment methods. Manual payment methods are basically only labels used as payment methods. All logic is manual and up to a store administrator. This type of payment methods is typically suitable for payment on delivery, i.e. when a salesperson or a shop assistant marks the order as paid.

Learn more in Configuring payment methods.

From the technical point of view, manual payment methods are payment methods that do not have any payment gateway URL and payment gateway provider class.

Manufacturer’s recommended retail price

See product list prices.

See product list prices.

Manufacturers

Manufacturers are “makers” of products. When adding or editing a product, you can set the product’s manufacturer.

They can serve either for further sorting in the product listing or for easier product management.

Learn more in Managing manufacturers.

Manufacturers are stored in the COM_Manufacturer database table. Every product has then a manufacturer’s ID assigned (in the SKUManufacturerID column in the COM_SKU table). If the product does not have a manufacturer assigned, the value in the column is NULL.

Memberships

A special type of products. Memberships are suitable when you offer your customers to be members in a paid club. You can also link together customers’ memberships to a membership section on your site, which only members can access.

For example, you want to provide some exclusive materials or stuff for your paid members. You create a membership and customers who purchase the membership will be able to access a restricted section on the site. In the restricted section, you publish the exclusive materials.

Learn more in Managing E-commerce memberships.

One of the product representations in Kentico. Memberships are basically standard products in the COM_SKU database table but have MEMBERSHIP in the SKUProductType column.

Multisite store

Multisite store is basically a Kentico instance that runs more on-line stores.

When running a multi-site store, You can take advantage of division settings and objects to global and site.

See Choosing site or global e-commerce configuration.

Notification emails

Notification emails are emails that the system sends when some event happens. You can configure which events trigger sending a notification email.

Learn more in Configuring e-commerce email notifications.

E-commerce notification emails can be sent to the customer who caused the event (created an order, paid an order, etc.) or to the administrator.

You can set the appearance of the notification emails.

Option categories

Option categories are logical categories of product options. When you want a product to have some product options, you need to assign the product an option category that contains the desired product options.

This is particularly useful when you want to use the same set of product options for more products. Typically, it can be sizes of T-shirts. You define one option category with the sizes and then assign it to all T-shirts.

You can manage option categories in the Product options application.

Learn more in Working with product options.

Option categories are stored in the COM_OptionCategory database table.

The relationships between products and option categories are stored in the COM_SKUOptionCategory table.

Order discounts

A type of discounts. Order discounts cheapen the whole order. You can manage them with the Orders discounts application.

You can limit the discount based on orders’ properties (prices, currencies, billing or shipping addresses, shipping, weight, etc.) or type of customers, duration, or enable the offer only when the customer types a discount coupon code.

Learn more in Working with order discounts.

To create order discounts, you need to use a discount rule based on which the order discount is applied. If your desired rule is not predefined, you can create your own, see Configuring discount rules. Order discounts and free shipping offers use the same set of discount rules.

Order discounts are stored in the COM_Discount database table along with catalog discounts and free shipping offers. Order discounts are recognizable by having Order in the DiscountApplyTo column.

Order statuses

Order statuses label orders to describe in which phase the orders are. For example, you can assign new orders to the New order status, paid orders to the Paid order status or delivered orders to the Finished order status.

With order statuses, you can also automatically mark orders as paid.

You can edit order statuses in the Store configuration or Multistore configuration applications.

Learn more in Order statuses.

Orders statuses are stored in the COM_OrderStatus database table. You can see whether a specific order status is global or site by checking the value in the StatusSiteID column. Global order statuses have NULL in the column whereas site order statuses have the status’s site ID in the column.

You can also see the history of order status changes in the COM_OrderStatusUser table.

Orders

When customers want to purchase products in your on-line store, they need to create an order, which you can then process and deliver the products to the customer.

Order is created when the customer adds products to their shopping cart, goes through the checkout process and clicks the final button that creates an order (such as Make an order, Finish the order or Submit).

Learn more in Orders.

Torsos of orders are stored in the COM_Order database table. In the COM_OrderAddress table, you can see addresses used in orders. In the COM_OrderItem table, you can see every product item bought with the order (items that were in the shopping cart before creating an order). Finally, you can see links to the bought e-products in the COM_OrderItemSKUFile table.

Original price

The highest price of a product. The original price is suitable for showing visitors of your store, how much money they can save in your store.

Original prices can be either product list prices or product prices before applying discounts depending on which is bigger number.

Paid orders

Paid orders are orders that are marked as paid. You can mark order as paid either one by one manually when editing an order or automatically by creating an order status, which marks orders as paid for you.

Learn more in Orders.

Paid orders are stored in the COM_Order database table as well as not paid orders. You can find out whether an order is paid by looking at the OrderIsPaid column. Unpaid orders have NULL as the column’s value whereas paid orders have 1 as the value.

Payment forms

Payment forms are web parts that enable customers to pay for their orders. The Payment form web part either processes the payment itself or redirects the visitor to the payment gateway (a website that was set to process the payment).

Payment forms appear after creating an order, see Configuring steps of the checkout process to learn more.

Manual payment methods do not need any payment forms.

Payment methods

Payment methods are options of how customers can pay for their orders. You can use either site or global payment methods. Therefore, you can edit payment methods in the Store configuration or Multistore configuration applications.

Learn more in Configuring payment methods.

Payment methods are stored in the COM_PaymentOption database table. You can see whether a specific payment method is global or site by checking the value in the PaymentOptionSiteID column. Global payment methods have NULL in the column whereas site payment methods have the method’s site ID in the column.

Permissions

By configuring permissions, you can limit access or ability to modify specific content of your on-line store. For example, you can enable specific users to create products but disable the users to delete products.

See Configuring permissions to learn more about permissions in Kentico generally, or see Configuring e-commerce permissions to learn more about permissions in the E-commerce Solution.

You can set different permissions to different roles, not just for purposes of store managers.

Prices

Prices in Kentico express the amount of money for which customers can buy a product, order a shipping, etc. 

There are several types of prices:

• Product prices
• Product list prices
• Original prices

Product coupons

A type of discounts. Product coupons cheapen specific products after customers type a specific discount coupon code. You can manage product coupons with the Product coupons application.

Learn more in Working with product coupons.

Product coupons are stored in the COM_DiscountCoupon database table. However, the connections between products and product coupons are expressed in the COM_SKUDiscountCoupon with the product’s and product coupon’s IDs.

Product detail pages

See Product details.

See Product details.

Product details

Product details are pages that display a specific product’s properties (details). It is typically the page where you get when you click on a product in the product listing.

Product details are usual pages with web parts, transformations, etc.

Learn more in Configuring product pages.

Product list prices

The price specified in the List price field when editing a product. Often abbreviated as a “list price”. In other systems, you can find list prices also as retail prices, recommended retail prices or even manufacturer’s recommended retail prices.

With list prices and transformations or macros, you can show visitors of your store, how much money they can save by purchasing the product in your store.

List prices are stored in the COM_SKU database table in the SKURetailPrice column.

Product listing pages

See Product listings.

See Product listings.

Product listings

Product listings are pages that display a list of products (all of them or a part of them). It is typically a department’s page with department’s products. After clicking on a product, you usually get to the product detail of the clicked product.

Product listings are usual pages with web parts, transformations, etc.

Learn more in Configuring product pages.

Product options

Product options are selectable parts of products. For example, T-shirts can have different sizes or cups can have inscriptions. They are divided into three types:

• Attribute (e.g., Color of clothing)
• Products (e.g., Portable PC accessories, Configurable PC – Operating system)
• Text (e.g., Book – Inscription)

Learn more in Working with product options.

Product options of all types are stored in the COM_SKU database table among products. In the SKUOptionCategoryID column, they have the ID of their option category. Every product option category is then saved in the COM_OptionCategory table.

Unlike product options of the attribute and products type, product options of the text type have by default one option in the COM_SKU table.

Product prices

The price specified in the Price field when editing a product. It is the price from which taxes, discounts, etc. are calculated.

Product prices are stored in the COM_SKU database table in the SKUPrice column.

Product representations

Product representations are basically different types of products. For example, some products are classic tangible items (food, computers, etc.), some of them are electronic or some of them are special, like memberships, donations, etc. Kentico divides product representations to:

• Standard products
• E-products
• Memberships
• Donations
• Bundles

Learn more in Managing product representations.

Product representations in Kentico are a partially centralized system. Some of the representations are right in the COM_SKU database table with products and some of them are stored in another table.

See the specific product representations to find out more details about each representation.

Product structure

Product structure is display division of products, so called product tree. The Products application and also the product part of the Pages application reflect the product structure.

Learn more in Configuring product structure.

Product structure is only for display purposes. To divide product logically, see Categorizing products.

Product tree structure

See Product structure.

See Product structure.

Product trees

See Product structure.

See Product structure.

Product types

Product types are page types for .

Learn more in Configuring product page types.

Apart from product page types, there are also product section types. They work the same way as thePage (menu item)section type when creating a new page.

Product variants

Product variants are basically products with preselected product options of the attribute type. You can assign all properties to product variants as if the variants were products.

Learn more in Working with product variants.

Product variants are stored among other products in the COM_SKU database table. The SKUParentSKUID column contains the parent product from which the product variants were created. Product variants are also connected with the preselected product options in the COM_VariantOption table.

Products

Products are items (stuff) which your customers can buy. For example, you can offer books, food, computers, audio, video, etc. You can find your products in the Products application.

Products can be divided based on several points of view, for example:

• Based on their product representation
• Whether they are created as an SKU object with an assigned page (a standard way) or as an SKU-only product

Learn more in Products.

Products are stored in the COM_SKU database table where SKU (stock keeping unit) objects are kept. By default, the SKU is created along with a page (in the CMS_Document table) to embrace also page properties and their advantages.

However, it is possible to create products just as stand-alone SKUs. It speeds up the system when you have many products but you cannot, for example, categorize products with categories or tags.

Based on every product’s product representation, more database tables can be used (for example, COM_Bundle or COM_SKUFile). Similarly, to get all information regarding product options or variants, you also need to see more database tables.

Learn more in Configuring products.

Purchase

To purchase something is actually to buy something in the on-line store. When a customer puts products to their shopping cart, goes through the checkout process to the state when they finally make an order, it is considered as a purchase.

Purchasing something does not mean any special system entity or object. It is just a state where an order is created.

Recommended retail prices

See product list prices.

See product list prices.

Retail prices

See product list prices.

See product list prices.

Registered customers

Customers who have purchased something and have registered in the store.

Learn more in Customers.

Registered customers are stored (as well as anonymous customers) in the COM_Customer database table. In the CustomerUserID column, they have their user’s ID.

Customers’ properties are synchronized with their user accounts. Learn more in Synchronizing customer and user properties.

Sample sites

Sample sites are websites that you can add during or after the installation of Kentico. On those sites, you can see implementation of different parts of typical websites, and therefore the sample sites can serve as inspiration for your own desired website.

Learn more in Installing the e-commerce sample sites.

Regarding the E-commerce Solution, the relevant sample sites are Dancing Goat, an example of a modern responsive website with an on-line store using the most used e-commerce features, and E-commerce Site, a more conservative site/on-line store where most of e-commerce features are implemented and ready to see.

Shipping address

Shipping and billing addresses are addresses used for orders. The shipping address is an address that sets where the order is shipped after the purchase. The shipping address is used only when at least one product of the order needs shipping.

Based on the shipping and billing addresses, you can set shipping prices or further alter orders. Customers can select their address in the Customer address web part. Learn more in Reference - Checkout process web parts.

Shipping addresses are (as well as billing addresses) stored in the COM_Address database table. Technically, the shipping and billing addresses are the same and are interchangeable. If the address has already been used in an order, you can find the address also in the COM_OrderAddress table.

The potential “duplication” of information is to prevent retroactive changes of orders. Customers are enabled to change their saved addresses (in COM_Address). If orders had used the same table and customers had changed their address, the order’s address would also change. Therefore, orders use their own address table (COM_OrderAddress), which can be changed only through the administration interface while editing an order.

Shipping carriers

Shipping carriers contain the functionality of shipping options. To enable any shipping option for your customers, you need to install shipping carriers to your system first.

Learn more in Configuring shipping carriers.

Shipping carriers are installed in the system through shipping carrier providers, a source code that provides running of its shipping carriers (and in the end their shipping options).

Learn more in Implementing custom shipping carrier providers.

Shipping options

Customers can choose from shipping options, you offer in your store, to choose how you send the order to the customer. You can edit shipping options in the Store configuration application.

Learn more in Configuring shipping options.

Shipping options are directly dependent on shipping carriers and basically connect shipping option’s settings with shipping carrier’s functionality. They are stored in the COM_ShippingOption database table. If a shipping option has a tax level, the relationship is stored in the COM_ShippingOptionTaxClass table.

Shipping options can be only site objects.

Shopping cart

Shopping cart is a page on which your customers see all shopping cart items and can continue with the checkout process and make an order.

Learn more in Configuring steps of the checkout process.

Shopping cart is a page in the checkout process. Typically, you can have a one-step checkout process or a multi-step checkout process. Therefore, the shopping cart can continue with other steps of the checkout process.

Shopping carts are stored in the COM_ShoppingCart database table.

Shopping cart item

Shopping cart item is one product in a shopping cart.

Shopping cart items of each saved shopping carts are stored in the visitor’s session and in the COM_ShoppingCartSKU database table.

Shopping cart preview

Shopping cart preview is a part of pages that displays how many products are in the shopping cart, what is the shopping cart’s total price, or any other desired information. Clicking the shopping cart preview usually leads to the shopping cart.

You can create shopping cart previews via transformations. Learn more in Displaying the shopping cart preview on pages.

Site objects

Site e-commerce objects are those e-commerce entities that are set for one site only. For example, products, product options, manufacturers and suppliers, payment methods,tax classes, orcurrencies. Some of them can be used along with the global objects, some of them can be used only without global objects.

Learn more in Choosing site or global e-commerce configuration.

Site objects have typically their site’s ID in their database record (opposed to global objects’ NULL), or a specific database column is used to label the object as site.

Site settings

Site e-commerce settings are settings related to the E-commerce Solution and are used for one site only. You can find settings under the Store settings tab in the Store configuration application.

Learn more in Choosing site or global e-commerce configuration.

Settings are stored in the CMS_SettingsKey database table. Site settings have site’s ID in the SiteID column.

SKU-only products

Products consist by default of an SKU object and a page. SKU-only products are products that do not have any bound page.

Such products therefore cannot use some advantages of pages.

Learn more in Managing stand-alone SKUs.

SKU-only products are stored in the COM_SKU database table as well as default products. SKU-only products speed up the system when you have many products, but you cannot, for example, categorize products in categories or tags.

Based on every product’s product representation, more database tables can be used (for example, COM_Bundle or COM_SKUFile). Similarly, to get all information regarding product options or variants, you also need to see more database tables.

Learn more in Configuring products.

Standard products

A standard type of products. Standard products represent usual tangible products, such as books, computers, food, cars, etc. On the other hand, standard products are not suitable for electronic files – e-products (e-books, audio, video, etc.) or other intangible “products” (like donations or memberships).

Learn more in Managing Standard products.

One of the product representations in Kentico. Standard products are stored along with other products in the COM_SKU database table and have PRODUCT in the SKUProductType column. Other product representations are derived from standard products.

Suppliers

Suppliers are “providers” of products, they typically bring the products to the store (or its stock). When adding or editing a product, you can set the product’s supplier. They can serve for easier product management when tracking which supplier takes care of which products.

Learn more in Managing suppliers.

Suppliers are stored in the COM_Supplier database table. Every product has a suppliers’s ID assigned (in the SKUSupplierID column in the COM_SKU table). If the product does not have a supplier assigned, the value in the column is NULL.

Tax classes

Kentico uses tax classes to express products’ taxes, eventually also other entities’ taxes (e.g. shipping). You can use either site or global tax classes. You can edit tax classes in the Store configuration or Multistore configuration applications.

Learn more in Configuring taxes.

Tax classes are stored in the COM_TaxClass database table. You can see whether a specific tax class is global or site by checking the value in the TaxClassSiteID column. Global tax classes have NULL in the column whereas site tax classes have the class’s site ID in the column.

Specific tax amounts are different for countries and states, they are stored in the COM_TaxClassCountry and COM_TaxClassState tables. If you decide to assign tax classes automatically based on products’ departments, the department–tax class relationships are stored in the COM_DepartmentTaxClass table.

Users

Users are those visitors of your website that have a user account.

Learn more in Configuring user registration in stores.

Users are not an e-commerce functionality and are therefore stored in the CMS_User database table (the table does not have the COM prefix).

Users have a contact assigned for the on-line marketing purposes (as well as a visitor without a user account) and users can also have a customer. They have a customer when they have already made an order.

Volume discounts

A type of discounts. Volume discounts cheapen products based on the number of purchased items. You can manage volume discounts through the Products application. Edit a product and switch to the Advanced -> Volume discounts tab.

Learn more in Working with volume discounts.

Volume discounts are stored in the COM_VolumeDiscountdatabase table. They are bound to their products with the product’s ID.