You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

key_questions.rst 6.9KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191
  1. ==============================================
  2. Building an e-commerce site: the key questions
  3. ==============================================
  4. When building an e-commerce site, there are several components whose
  5. implementation is strongly domain-specific. That is, every site will have
  6. different requirements for how such a component should operate. As such, these
  7. components cannot easily be modelled using a generic system - no configurable
  8. system will be able to accurately capture all the domain-specific behaviour
  9. required.
  10. The design philosophy of Oscar is to not make a decision for you here, but to
  11. provide the foundations upon which any domain logic can be implemented, no matter how
  12. complex.
  13. This document lists the components which will require implementation according
  14. to the domain at hand. These are the key questions to answer when building your
  15. application. Much of Oscar's documentation is in the form of "recipes" that
  16. explain how to solve the questions listed here - each question links to the
  17. relevant recipes.
  18. Catalogue
  19. =========
  20. What are your product types?
  21. ----------------------------
  22. Are you selling books, DVDs, clothing, downloads, or fruit and vegetables? You will
  23. need to capture the attributes of your product types within your models. Oscar
  24. divides products into 'product classes' which each have their own set of
  25. attributes. Modelling the catalogue on the backend is explained in
  26. :doc:`/topics/modelling_your_catalogue`.
  27. How is your catalogue organised?
  28. --------------------------------
  29. How are products organised on the front end? A common pattern is to have a
  30. single category tree where each product belongs to one category which sits
  31. within a tree structure of other categories. However, there are lots of other
  32. options such as having several separate taxonomy trees (e.g., split by brand, by
  33. theme, by product type). Other questions to consider:
  34. * Can a product belong to more than one category?
  35. * Can a category sit in more than one place within the tree? (e.g., a "children's fiction" category
  36. might sit beneath "children's books" and "fiction").
  37. How are products managed?
  38. -------------------------
  39. Is the catalogue managed by an admin using a dashboard, or though an automated
  40. process, such as processing feeds from a fulfilment system? Where are your
  41. product images going to be served from?
  42. * :doc:`/howto/how_to_disable_an_app_or_feature`
  43. Pricing, stock and availability
  44. ===============================
  45. How is tax calculated?
  46. ----------------------
  47. Taxes vary widely between countries. Even the way that prices are displayed
  48. varies between countries. For instance, in the UK and Europe prices are shown inclusive of
  49. VAT whereas in the US, taxes are often not shown until the final stage of checkout.
  50. Furthermore, the amount of tax charged can vary depending on a number of
  51. factors, including:
  52. * The products being bought (e.g., in the UK, certain products have pay no VAT).
  53. * Who the customer is. For instance, sales reps will often not pay tax whereas
  54. regular customers will.
  55. * The shipping address of the order.
  56. * The payment method used.
  57. Recipes:
  58. * :doc:`/howto/how_to_handle_us_taxes`
  59. What availability messages are shown to customers?
  60. --------------------------------------------------
  61. Based on the stock information from a fulfilment partner, what messaging should be
  62. displayed on the site?
  63. * :doc:`/howto/how_to_configure_stock_messaging`
  64. Do you allow pre-orders and back-orders
  65. ---------------------------------
  66. A pre-order is where you allow a product to be bought before it has been
  67. published, while a back-order is where you allow a product to be bought that is
  68. currently out of stock.
  69. Shipping
  70. ========
  71. How are shipping charges calculated?
  72. ------------------------------------
  73. There are lots of options and variations here. Shipping methods and their
  74. associated charges can take a variety of forms, including:
  75. * A charge based on the weight of the basket
  76. * Charging a pre-order and pre-item charge
  77. * Having free shipping for orders above a given threshold
  78. Recipes:
  79. * :doc:`/howto/how_to_configure_shipping`
  80. Which shipping methods are available?
  81. -------------------------------------
  82. There's often also an issue of which shipping methods are available, as
  83. this can depend on:
  84. * The shipping address (e.g., overseas orders have higher charges)
  85. * The contents of the basket (e.g., free shipping for downloadable products)
  86. * Who the user is (e.g., sales reps get free shipping)
  87. Oscar provides classes for free shipping, fixed charge shipping, pre-order and
  88. per-product item charges and weight-based charges. It is provides a mechanism
  89. for determining which shipping methods are available to the user.
  90. Recipes:
  91. * :doc:`/howto/how_to_configure_shipping`
  92. Payment
  93. =======
  94. How are customers going to pay for orders?
  95. ------------------------------------------
  96. Often a shop will have a single mechanism for taking payment, such
  97. as integrating with a payment gateway or using PayPal. However more
  98. complicated projects will allow users to combine several different payment
  99. sources such as bankcards, business accounts and gift cards.
  100. Possible payment sources include:
  101. * Bankcard
  102. * Google checkout
  103. * PayPal
  104. * Business account
  105. * Managed budget
  106. * Gift card
  107. * No upfront payment but send invoices later
  108. The checkout app within ``django-oscar`` is suitably flexible that all of these
  109. methods (and in any combination) is supported. However, you will need to
  110. implement the logic for your domain by subclassing the relevant ``view/util``
  111. classes.
  112. Domain logic is often required to:
  113. * Determine which payment methods are available to an order;
  114. * Determine if payment can be split across sources and in which combinations;
  115. * Determine the order in which to take payment;
  116. * Determine how to handle failing payments (this can get complicated when using
  117. multiple payment sources to pay for an order).
  118. When will payment be taken?
  119. ---------------------------
  120. A common pattern is to pre-authorise a bankcard at the point of checkout then
  121. 'settle' for the appropriate amounts when the items actually ship. However,
  122. sometimes payment is taken up front. Often you won't have a choice due to
  123. limitations of the payment partner you need to integrate with, or legal
  124. restrictions of the country you are operating in.
  125. * Will the customer be debited at point of checkout, or when the items are dispatched?
  126. * If charging after checkout, when are shipping charges collected?
  127. * What happens if an order is cancelled after partial payment?
  128. Order processing
  129. ================
  130. How will orders be processed?
  131. -----------------------------
  132. Orders can be processed in many ways, including:
  133. * Manual process. For instance, a worker in a warehouse may download a picking
  134. slip from the dashboard and mark products as shipped when they have been put in the van.
  135. * Fully automated process, where files are transferred between the merchant and
  136. the fulfilment partner to indicate shipping statuses.
  137. Recipes:
  138. * :doc:`/howto/how_to_set_up_order_processing`