taler-docs

Documentation for GNU Taler components, APIs and protocols
Log | Files | Refs | README | LICENSE

016-backoffice-order-management.rst (9706B)


      1 DD 16: Backoffice Order Management
      2 ##################################
      3 
      4 Summary
      5 =======
      6 
      7 This document describe the complete list features for orders management and how
      8 will be shown.
      9 
     10 Motivation
     11 ==========
     12 
     13 User will use the backoffice to manage their orders and verify the status of the
     14 current and past orders.
     15 
     16 Requirements
     17 ============
     18 
     19 Access all information provided from the Merchant Backend API in a
     20 understandable and accessible way
     21 
     22 User should use the backoffice to manage orders by:
     23 
     24 * searching for orders
     25 * showing details about the order and the activity history
     26 * refund order that are refundable
     27 * create orders ( if admin )
     28 
     29 Proposed Solution
     30 =================
     31 
     32 Listing orders
     33 --------------
     34 
     35 .. image:: ../images/backoffice-order-list.svg
     36   :width: 800
     37 
     38 4 tabs will be show for an easy access to common filter, click on any of this and
     39 search will reset all filter except date
     40 
     41 * paid (default)
     42 * refunded
     43 * not wired
     44 * all (empty filter box)
     45 
     46 Columns for the order listings will be:
     47 
     48 * date in 'dd/MM/yyyy HH:mm:ss' format
     49 * amount: value and currency
     50 * summary
     51 
     52 Actions per row:
     53 
     54 * refund: pop up with amount and reason (select box and text)
     55 * copy payment url (if not status==unpaid)
     56 * view details
     57 
     58 An export button will allow the user to download the result page in CSV format.
     59 
     60 An infinity scroll is propose instead of a pagination, reasons:
     61 
     62 * users usually does not jump from one page to another using random access
     63 * if the user want to search, is going to limit the result using filters
     64 * no need to go back after loading more result
     65 * it could be triggered by scrolling, with buttons (or both)
     66 
     67 Create orders
     68 -------------
     69 
     70 this form is divided into 4 sections
     71 
     72 * ``product``: where the merchant can add inventory product and non-inventory
     73   product.
     74 
     75 * ``price``: where the merchant can override the total price (if product was
     76   added) or set the order price and summary.
     77 
     78 * ``payment``: where some default of the payment processing can be changed
     79 
     80 * ``extra``: where the merchant can add extra information in JSON format
     81 
     82 
     83 Create order: Product section
     84 .............................
     85 
     86 This section has two parts:
     87 
     88 The first part will add/remove product from the current stock.
     89 
     90 * ``name``: search box to select product by description field. if not found it
     91   will be a 'create new' option leading to the create product without losing
     92   context
     93 
     94 * ``quantity``: mandatory
     95 
     96 The second part will add non inventory product. To add a product a :ref:`create
     97 product <backoffice-create-product>` form will be shown. The product in the list
     98 can be edited or deleted from the list.
     99 
    100 In both cases, the total unit and price of the products will be calculated and
    101 shown in the bottom of the section. If the merchant collapse one of the product
    102 list a line with a resume of the total price and units will be shown.
    103 
    104 .. image:: ../images/backoffice-order-create.product-section.svg
    105   :width: 800
    106 
    107 Create order: Price section
    108 ...........................
    109 
    110 This section has 2 scenarios.
    111 
    112 The fist one is without products being added: the ``order price`` and
    113 ``summary`` inputs will be shown.
    114 
    115 If there is at least one product added, the ``total products price`` as the sum
    116 of all products prices will be shown. The ``order price`` will default to
    117 ``total products price``. The ``products taxes`` and ``profit`` will be shown
    118 since ``order price`` cannot be less that ``product taxes``.
    119 
    120 .. image:: ../images/backoffice-order-create.price-section.svg
    121   :width: 800
    122 
    123 Create order: Payment section
    124 .............................
    125 
    126 This section show optional values that can be overwritten by the merchant
    127 
    128 * ``refund deadline``: calendar type of input. default from instance
    129 
    130 * ``pay deadline``: calendar type of input. default from instance
    131 
    132 * ``auto refund deadline``: calendar type of input. default empty, optional.
    133 
    134 * ``delivery date``: calendar type of input. default empty, optional.
    135 
    136 * ``delivery location``: location section similar to instance jurisdiction or
    137   instance address. optional
    138 
    139 * ``max fee``: default value from the instance
    140 
    141 * ``max wire fee``: default value from the instance
    142 
    143 * ``wire_fee_amortization``: default value from the instance
    144 
    145 .. image:: ../images/backoffice-order-create.payment-section.svg
    146   :width: 800
    147 
    148 Create order: all section expanded
    149 ..................................
    150 
    151 An example of how all section in a page will be shown.
    152 
    153 .. image:: ../images/backoffice-order-create.all-expanded.svg
    154   :width: 800
    155 
    156 
    157 Creation order success
    158 ......................
    159 
    160 A success message showing the amount, summary and the order id. Additionally the
    161 taler_pay_uri can be shown to be copied to send to the customer.
    162 
    163 action buttons that allow the following:
    164 
    165 * create another payment: go to the create payment page again
    166 * view details: show details of the payment (see page)
    167 
    168 Order details
    169 -------------
    170 
    171 Status text should be set with a background color for easier recognition when
    172 indicated:
    173 
    174 * paid: green
    175 * claimed: light-green
    176 * unpaid: grey
    177 * refunded: red
    178 
    179 Header
    180 ......
    181 
    182 This is a resume of most important information
    183 
    184 * big status with color
    185 * date
    186 * total
    187 
    188   - deposit_total (if not refunded)
    189   - refund_amount (if status is refunded)
    190   - deposit_total - refund amount (if refunded partially)
    191 
    192 * order_status_url
    193 * taler_pay_uri (if unpaid)
    194 * actions: refund (if not refunded), add note, copy order_status_url
    195 
    196 Timeline of events
    197 ..................
    198 
    199 Event of status changed over time describe vertically.
    200 Sorted from newest to oldest.
    201 On line per status updated, with datetime and a short description.
    202 
    203 Info taken from:
    204 
    205 * refund_details: a row showing date an amount
    206 
    207 * wire_details: a row date and id
    208 
    209 
    210     About wire details
    211 
    212     Normally one wire transfer will involve more than one payment from the same
    213     exchange. And an order can have multiple wire transfers if the payment
    214     involved more than one exchange.
    215 
    216 
    217 
    218 Error status
    219 ............
    220 
    221 This section is not going to be shown if there is no error
    222 
    223 * Wire Error: info taking from wire_reports in contractTerm. for every element
    224   in the list show hint and error code
    225 
    226 * Exchange Error: connection with exchange failed, info taking from exchange_ec
    227   and exchange_hc
    228 
    229 Payment details
    230 ...............
    231 
    232 If the order was claimed
    233 
    234 * summary
    235 * amount (contract.amount)
    236 * fee (contract.amount - deposit_total)
    237 * refund_amount (if status is refunded)
    238 * net (deposit_total - refund_amount)
    239 * current status
    240 
    241 
    242 Contract Terms
    243 ..............
    244 
    245 collapsed as default. show disabled if unpaid
    246 
    247 * summary
    248 * amount
    249 * fulfillment_url, if present
    250 * max fee
    251 * max fire fee
    252 * wire_fee_amortization
    253 * list of (exchange | auditor) name and url
    254 * products table: list of products, one row per product
    255 
    256   * description
    257   * quantity
    258   * total price
    259   * total tax
    260   * sum at the bottom
    261 
    262 * horizontal timeline of important dates in the contract
    263 
    264   * start at contract creation time
    265   * show current date
    266   * pay_deadline
    267   * wire_transfer_deadline
    268   * refund_deadline
    269   * delivery_date (immediately if null)
    270   * auto_refund
    271 
    272 
    273 refund popup
    274 ............
    275 
    276 If there is any refund:
    277 
    278 * show total refund from ``refund_amount``
    279 * a (down arrow) to show more information
    280 * if expanded show table with date, amount and reason
    281 
    282 Warn if there is a pending refund when ``refund_pending`` is true
    283 
    284 Ask for:
    285 
    286 * amount: default 0, show max amount refundable (order amount - already
    287   refunded)
    288 
    289 * reason: concatenation of the next values
    290 
    291   * drop down options: duplicated, requested by customer, other
    292   * after selecting, free text for additional information
    293 
    294 .. image:: ../images/backoffice-order-refund.svg
    295   :width: 800
    296 
    297 .. image:: ../images/backoffice-order-refund.already.svg
    298   :width: 800
    299 
    300 Example of details by status
    301 ----------------------------
    302 
    303 
    304 
    305 .. image:: ../images/backoffice-order-details.paid.svg
    306   :width: 800
    307 
    308 .. image:: ../images/backoffice-order-details.unpaid.svg
    309   :width: 800
    310 
    311 .. image:: ../images/backoffice-order-details.claimed.svg
    312   :width: 800
    313 
    314 .. image:: ../images/backoffice-order-details.refunded.svg
    315   :width: 800
    316 
    317 
    318 Alternatives
    319 ============
    320 
    321 
    322 pagination
    323 ----------
    324 order list was originally thought with pagination footer
    325 
    326 .. image:: ../images/backoffice-order-list.pagination.svg
    327   :width: 800
    328 
    329 ascending boolean flag cloud be eliminated using the load before and load after
    330 and a design without random access to pages was proposed
    331 
    332 search box
    333 ----------
    334 
    335 A SearchBox was considered for managing filter.
    336 Filter will allow paid, refunded, wired status and date.
    337 
    338 * paid: yes/no
    339 * refunded: yes/no
    340 * wired: yes/no
    341 * date: 'dd/MM/yyyy'
    342 
    343 The UI of the search box is an input field with tags showing ``field=value`` for
    344 any filter set. Additionally a custom criteria can be supported like
    345 ``date>last_week`` or ``amount>USD:10``
    346 
    347 
    348 
    349 Discussion / Q&A
    350 ================
    351 
    352 * Shall we show merchant information from the ContractTerm in the order detail?
    353 
    354 * Do we have the date and time of when the order goes from these states?
    355 
    356   * null => unpaid (using contractTerm.timestamp from now but may not be correct)
    357 
    358   * unpaid => claimed (maybe contractTerm.timestamp)
    359 
    360   * claimed => paid (maybe last wire_details.execution_time with confirmed = true )
    361 
    362 * Refund button is being show if "refund_amount < contract_terms.amount" and "time < refund deadline".
    363   Is there any other case? Is this taking into account auto_refund?
    364 
    365 * Field left out in the order creation:
    366 
    367   * contractTerm.summary_i18n: it makes the UI complex
    368   * contractTerm.order_id: should be created by the backend
    369   * contractTerm.timestamp: defined by backend
    370   * contractTerm.merchant_pub: filled by the backend
    371   * contractTerm.merchant_base_url: filled by the backend
    372   * contractTerm.h_wire: defined by the backend
    373   * contractTerm.nonce: not used