123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191 |
- ==============================================
- Building an e-commerce site: the key questions
- ==============================================
-
- When building an e-commerce site, there are several components whose
- implementation is strongly domain-specific. That is, every site will have
- different requirements for how such a component should operate. As such, these
- components cannot easily be modelled using a generic system - no configurable
- system will be able to accurately capture all the domain-specific behaviour
- required.
-
- The design philosophy of Oscar is to not make a decision for you here, but to
- provide the foundations upon which any domain logic can be implemented, no matter how
- complex.
-
- This document lists the components which will require implementation according
- to the domain at hand. These are the key questions to answer when building your
- application. Much of Oscar's documentation is in the form of "recipes" that
- explain how to solve the questions listed here - each question links to the
- relevant recipes.
-
- Catalogue
- =========
-
- What are your product types?
- ----------------------------
-
- Are you selling books, DVDs, clothing, downloads, or fruit and vegetables? You will
- need to capture the attributes of your product types within your models. Oscar
- divides products into 'product classes' which each have their own set of
- attributes. Modelling the catalogue on the backend is explained in
- :doc:`/topics/modelling_your_catalogue`.
-
- How is your catalogue organised?
- --------------------------------
-
- How are products organised on the front end? A common pattern is to have a
- single category tree where each product belongs to one category which sits
- within a tree structure of other categories. However, there are lots of other
- options such as having several separate taxonomy trees (e.g., split by brand, by
- theme, by product type). Other questions to consider:
-
- * Can a product belong to more than one category?
- * Can a category sit in more than one place within the tree? (e.g., a "children's fiction" category
- might sit beneath "children's books" and "fiction").
-
- How are products managed?
- -------------------------
-
- Is the catalogue managed by an admin using a dashboard, or though an automated
- process, such as processing feeds from a fulfilment system? Where are your
- product images going to be served from?
-
- * :doc:`/howto/how_to_disable_an_app_or_feature`
-
- Pricing, stock and availability
- ===============================
-
- How is tax calculated?
- ----------------------
-
- Taxes vary widely between countries. Even the way that prices are displayed
- varies between countries. For instance, in the UK and Europe prices are shown inclusive of
- VAT whereas in the US, taxes are often not shown until the final stage of checkout.
-
- Furthermore, the amount of tax charged can vary depending on a number of
- factors, including:
-
- * The products being bought (e.g., in the UK, certain products have pay no VAT).
- * Who the customer is. For instance, sales reps will often not pay tax whereas
- regular customers will.
- * The shipping address of the order.
- * The payment method used.
-
- Recipes:
- * :doc:`/howto/how_to_handle_us_taxes`
-
- What availability messages are shown to customers?
- --------------------------------------------------
-
- Based on the stock information from a fulfilment partner, what messaging should be
- displayed on the site?
-
- * :doc:`/howto/how_to_configure_stock_messaging`
-
- Do you allow pre-orders and back-orders
- ---------------------------------
-
- A pre-order is where you allow a product to be bought before it has been
- published, while a back-order is where you allow a product to be bought that is
- currently out of stock.
-
- Shipping
- ========
-
- How are shipping charges calculated?
- ------------------------------------
-
- There are lots of options and variations here. Shipping methods and their
- associated charges can take a variety of forms, including:
-
- * A charge based on the weight of the basket
- * Charging a pre-order and pre-item charge
- * Having free shipping for orders above a given threshold
-
- Recipes:
-
- * :doc:`/howto/how_to_configure_shipping`
-
- Which shipping methods are available?
- -------------------------------------
-
- There's often also an issue of which shipping methods are available, as
- this can depend on:
-
- * The shipping address (e.g., overseas orders have higher charges)
- * The contents of the basket (e.g., free shipping for downloadable products)
- * Who the user is (e.g., sales reps get free shipping)
-
- Oscar provides classes for free shipping, fixed charge shipping, pre-order and
- per-product item charges and weight-based charges. It is provides a mechanism
- for determining which shipping methods are available to the user.
-
- Recipes:
-
- * :doc:`/howto/how_to_configure_shipping`
-
- Payment
- =======
-
- How are customers going to pay for orders?
- ------------------------------------------
-
- Often a shop will have a single mechanism for taking payment, such
- as integrating with a payment gateway or using PayPal. However more
- complicated projects will allow users to combine several different payment
- sources such as bankcards, business accounts and gift cards.
-
- Possible payment sources include:
-
- * Bankcard
- * Google checkout
- * PayPal
- * Business account
- * Managed budget
- * Gift card
- * No upfront payment but send invoices later
-
- The checkout app within ``django-oscar`` is suitably flexible that all of these
- methods (and in any combination) is supported. However, you will need to
- implement the logic for your domain by subclassing the relevant ``view/util``
- classes.
-
- Domain logic is often required to:
-
- * Determine which payment methods are available to an order;
- * Determine if payment can be split across sources and in which combinations;
- * Determine the order in which to take payment;
- * Determine how to handle failing payments (this can get complicated when using
- multiple payment sources to pay for an order).
-
- When will payment be taken?
- ---------------------------
-
- A common pattern is to pre-authorise a bankcard at the point of checkout then
- 'settle' for the appropriate amounts when the items actually ship. However,
- sometimes payment is taken up front. Often you won't have a choice due to
- limitations of the payment partner you need to integrate with, or legal
- restrictions of the country you are operating in.
-
- * Will the customer be debited at point of checkout, or when the items are dispatched?
- * If charging after checkout, when are shipping charges collected?
- * What happens if an order is cancelled after partial payment?
-
- Order processing
- ================
-
- How will orders be processed?
- -----------------------------
-
- Orders can be processed in many ways, including:
-
- * Manual process. For instance, a worker in a warehouse may download a picking
- slip from the dashboard and mark products as shipped when they have been put in the van.
-
- * Fully automated process, where files are transferred between the merchant and
- the fulfilment partner to indicate shipping statuses.
-
- Recipes:
-
- * :doc:`/howto/how_to_set_up_order_processing`
|