Back to POS POS

Data Exchange Procedures (API) for POS

User Access Procedures
!!SERVER FUNCTION Login( String ~UserName, String Password ) RETURNS ~XmlData!!
* Login using API
* Authenticate
* Loads Security
* Reply with :
* ~UserID,
* Security Permitions
* some additional environment variables that might be needed, default price list, home currency etc.
* The reply should also contain a session SID key so it can be placed on a url when a browser is opened from within the POS app. This will insure the user log in only once no mater the application.

!!CLIENT FUNCTION ~CheckPermission( Integer ~SecurityTokenToCheck, ~XmlData ~LoginData ) RETURNS Boolean!!
* Yes access granted / No access denied
* The ~LoginData will contain a section containing a list of granted ~SecurityTokens (Integers)

New Security Tokens and Rolls needs to be added for POS access token Identifiers should be upwards from 100.
Tokens addition is a manual process. Tokens ranges should be allocated to any application by the ~WebERP Team

Stock Items
!!SERVER FUNCTION ~GetStockItem( String ~StockCodeOrBarCode, String Warehouse, String ~PriceList, Boolean ~CheckAvailability ) RETURNS ~XmlData!!

* This function should accept either a ~StockCode or a ~BarCode ( A partial ~BarCode or ~StockCodes will return multiple items )
* The warehouse is importand here Warehouse and so is the ~PriceList you want to use
* ~CheckAvailability will only return stock that is available for retail.
* Returns with :
* Empty if the Item is not available
* Available Quantity
* Stock Name and related data ( unit of measure, decimals, etc. )

A Flag is required in the ~StockMaster table indicating whether an item may be sold through a POS and another for Online Sales the requirements may be different for instance I am not going to sell fridges Online the risk with mail-order transactions is to great.

Another Flag is required to allow a stock item to be sold even if it is out of stock (~BackOrder sales)

Stock Categories

We need Sales Categories though, the requirement is hierarchical ( allow sub catagories ) and a stock item may exist in multiple categories. This is required for restotant type point of sales as well as eCommerce type interfaces. We already have Warehouse categories, and it is correct that a stock item may only exist on one stock type category it is therefore not the same as sales catagories.
The stock categories has stuff connected to it to hadle cost accounting and should not be changed.

Functions needed here :
* List of stock items from a catagory
* List of sub categories from a catagory
* A way to assosiate an image with stock and categories.
* A way to upload images (inside ~WebERP)

Cart System

I'll get back to this.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki