documentation polished

1 files changed, 88 insertions, 6 deletions

diff --git a/doc/codeless.texi b/doc/codeless.texi
index 1b47785..9b3bfb6 100644
--- a/doc/codeless.texi
+++ b/doc/codeless.texi
@@ -47,6 +47,8 @@ Free Documentation License".
 * Installation::
 * Inventory Tracking::
 * Common Usage::
+* Limitation::
+* Future Work::
 
 
 
@@ -150,9 +152,9 @@ run.
 @example
 $ git clone https://git.taler.net/codeless.git/
 $ cd codeless/
+$ ./bootsrap
 $ make
 # make install
-# make run #to run the server
 @end example
 
 
@@ -176,7 +178,6 @@ The following image illustrates the database schema used for inventory tracking:
 
 @c @center @image{doc/database, 1in, 1in}
 
-
 @node New inventory
 @section New inventory
 
@@ -195,7 +196,13 @@ The Merchant can add two types of inventory
   add MinimumQuantity of Product that is required to be maintained
   in the stock. Whenever the stoxks run below this limit the seller
   would be notified(Curently this feature has not been added but 
-  soon email notification would be added).
+  soon email notification would be added). Whenever user purchases 
+  a product from the seller, after successful payment they will be
+  redirected to the fullfillment page. On the fullfillment page
+  the user can track his shipment. The status of the order is
+  updated by the merchant and on this basis the user is
+  updated about his shipment on the fullfillment page. For now there
+  are five paramters that have used for tracking.
 @end itemize
 
 
@@ -210,7 +217,8 @@ makes sence. Therefore on the fullfillment page the user can track
 his shipment. The status of the order is updated by the merchant
 and on this basis the user is updated about his shipment of fullfillment
 page. For now there are five paramters that have used for tracking, but
-this is extensible and can be modified according to the requirement.
+this is extensible and can be modified according to the requirement. The
+initial status of order is marked as 'Pre Processing'.
 
 @node Order Creation
 @section Order Creation
@@ -220,7 +228,12 @@ codeless payment backend. While handling this function the crsf
 token is exempted and this function returns the json request. The 
 order creation depends on the json format. If the json response status
 is 200 only then an order will be created and also the quantity of the
-same product is used to update the inventory on hand.
+same product is used to update the inventory on hand. For digital
+inventory the inventory on hand remains zero. Untill and Unless a response
+code of 200 is recieved, the inventory won't be updated. Similarly, all
+the orders purchased are added in the Order table in the database. The
+status for each order has to be updated buy the Merchant manually. The initial
+status of order is marked as 'Pre Processing'.
 
 @node Common Usage
 @chapter Common Usage
@@ -229,7 +242,76 @@ The following image illustrates the various use case of codeless payment:
 
 @c @center @image{doc/UseCaseDiagram, 1in, 1in}
 
+There are three parties for which codeless payment backend serves
+@itemize
+@item Merchant
+The Merchant has the ability to access the codeless payemnt backend
+by logging in the platform. Codeless is a platform for the merchant
+where they can manage their inventory and simultaneously create a
+'Buy Now' button for the specific product. This code can be directly
+copy pasted on the seller's frontend and can be used for 'Pay with Taler'.
+@item Buyer
+The Buyer will access the seller's frontend where the code
+for 'Buy Now' button is copy pasted. The buysers clicks on the payemnt
+button to pay with Taler. They enter their shipment details and redirected
+to the payment page. After successfull payment the buyer can track his
+shipment for physical products or view the digital version hosted by the
+codeless payment frontend.
+@item Admin
+The Admin of the project has all the rights to access the admin page and
+perform all the task that a Merchant can perform.
+@end itemize
+
+@node Limitation
+@chapter Limitation
+
+There are certain limitations that exists in thecodeless payment
+baackend. The reset password works only when the backend is running
+locally. Untill and unless, the backend is backend is deployed
+on the server it won't work. Anothere limitation that exist is the
+email notification when the stocks run below a certain limit. The
+minimum number of products required to be maintained in the stocks
+is currently taken from the seller but no email notification is send.
+
+@node Future Work
+@chapter Future Work
+
+The backend of codeless payment is very roboust and can be easily
+extended as per the requirements. It is adaptive to add new features
+to this framework. But as per the dicussion and the scope of this
+project there are various features that will be soon added in the
+Codeless Merchant Backend.
+The list of future work is a s follows:
 
+@itemize
+@item
+To send Email notification to the Merchant wwhen the stocks run below a
+certain limit. The minimum quantity required to be maintained in
+the stocks is currently taken from the Merchant(specific to each
+product) but no such notification system is designed.
+@item
+To add API access to the merchant backend via the codeless payment 
+service. Basically it would be used as a hosting platform for multiple
+merchants. There would be an additional user interface part in
+the codeless payment service where a logged-in merchant can generate an
+API key. This API key can be used to access the functionality of the
+merchant backend in a controlled way. After requesting an API key, the
+page would display the generated key and a base URL for the API to used
+by the seller, which is handled by the codeless payments service.
+@item
+Mapping every seller account to a separate merchant backend instance.
+This is not required for a simple version of codeless payments, but
+as soon as API access for sellers, this is a useful feature.
+The codeless payment service then can also double as a hosting service
+for merchants.
+@item
+To add various analytics for the Merchant. Various analysis could be
+performed on the orders placed for the respective merchant. Some of
+the analysis that can be performed are displaying the most frequently
+purchased product, some insights about the shipment tracking, analysis
+of products based on delivery location, etc. For this part, dicussions and
+some more research has to be done before procedding to the implementation. 
+@end itemize
 
 @c **********************************************************
 @c *******************  Appendices  *************************
@@ -245,4 +327,4 @@ The following image illustrates the various use case of codeless payment:
 
 @printindex cp
 
-@bye
\ No newline at end of file
+@bye