solutema / trytonpos

Automatically exported from code.google.com/p/trytonpos
0 stars 0 forks source link

Ideas for a Tryton internal solution #1

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Some Ideas for a Tryton POS solution based on our own technology tryton.

  * Main database is a central Tryton backend server.
  * Using XMLRPC/NETRPC actions and interface modules on server and client 
    side for:
    * Distributing product/customer/pricing/payment data from server to 
      the POS
      * After login the POS database is updated from main server.
        * User login data
        * Products
        * Stocklevels not needed!
        * Actual prices, rebat
        * Taxes
        * Payment terms
        * Customer data or standard customer/cash customer
        * Report templates
    * Consolidate payed invoice lines (bill) from the POS to server:
      * Generate complete payed invoices on the POS. POS handles sales and 
        invoicing in one step, to store the stock levels.
      * Count and send stocklevels
      * Create individual prefix on invoicenumber for each POS
      * Copy the payed invoices (bills) to the server. 
        * Store the bill made by the POS printer as invoice document 
          (Usually text format with formatting sequences.) 
      * Copy all generated moves and movelines to the server.
      * Cash Account for each POS showing the individual amounts.
      * Different payment terms
        * cash
        * invoice
        * different credit cards and methods
      * The Payment closees the sale.
  * Using neso as autonom POS Software and create a standard POS View.
  * POS View General:
    * Users Home Action is open the POS view, show no menu.
    * Is completly keyboard driven, think 
      about customizable POS keybord and bar code scanner, they generate 
      text and control sequences.
    * Has only one input field for user acces, like a command line
    * Commands are textual and ended by pressing Enter.
    * All other fields are readonly or function fields updated when 
      pressing enter in the input field.
    * POS has modes like vi:
      * New bill
        * Items entry
        * Items cancel
        * Workflow: open
      * Payment
        * Payment term
        * Workflow: paied
        * Workflow: closed
      * Cancel bill      
        * All entries on a bill or the bill itself can be canceled at any 
          time if it is not payed. If it is payed, it can only canceled if 
          the user is in the 'pos-cancel' user group, which is usually 
          only the department chief or another third person. The procedure 
          is the same like on refunds.
        * Workflow: canceled
      * Refund bill (restricted to group pos-cancel):
        * Call back old bill from main server, check plausibility.
        * Pay money back.
        * Leveling stock with refund item.
        * Refund reason
        * Workflow: refunded
    * All other fields of the pos are generated on_change with the input 
      field.
    * Nice to have: Show all input elements of the POS on the screen, for 
      touch screens, need widget modifications.
    * Nice to have action for opening the cash box = cancel key
    * Action for POS printer
  * Widged modifications for POS view (nice to have) 
    * Width and height, picture and color on buttons
    * Font_size of contents on fields amount, integer, 
      nummeric, char on form views and complete lines on 
      one2many views.
    * Picture as background of form views
    * Focus attribute on fields for cursor focus, if we do not have 
      already.

Original issue reported on code.google.com by udo.spal...@googlemail.com on 20 Sep 2009 at 5:34

GoogleCodeExporter commented 8 years ago
If I understand the UI related comments, you suggest to use the Tryton client
directly for this?

I'm not sure whether that's a good idea, at least from the touch POS point of 
view,
the presentation is going to be radically different and also, I don't think we 
should
autogenerate the POS UI like current client does it, given that there are a lot 
of
things we are not interested to show in the POS client.

The only thing that may make sense to do is to add an special 'POS view' that 
would
be selected on client side, so only the 'POS Views' are rendered on POS mode 
(not
sure whether that's your POS view definition). However, I don't know whether 
Tryton
is able to do it, any input on this is welcome, in the meanwhile I would need to
investigate it a bit more.

Original comment by car...@pemas.es on 21 Sep 2009 at 3:19