I am thinking about developing a POS system for my own, however, I
need a solid database design which I couldn't accomplish.
The database should accommodate:

1) Inventory
   - Quantity on hand, reorder quantity etc.
2) Product
   - product info, pic, buy price
3) Price
   - sales price, discount price
4) Sales
   - record every transation and print receipt
5) Employee
   - employee, sales clerk
6) Supplier
   - supplier info

Problems need to solve:

1) Same product can be bought from two suppliers at different prices,
the system should be able to differentiate them at sales in order to
get accurate profit report(without having two different product code).
2) Define product price in a period, allow for flexiable change. 
Define different types of discount methods, and set the discount in a
range of time
3) Be able to print a sales receipt, with exactly previous sold price,
discount and tax rate(price, discount and tax rate may changed since)

please post a follow up message if you need more info or explanation.

http://sourceforge.net/projects/l-ane/
http://sourceforge.net/projects/phppointofsale/

Starting from the problems:

1) You need a general "products" table that has a product description
and sale prices, but should not include the purchase price.  This can
be calculated on-the-fly from the "purchased goods" table.  All
purchased goods are assigned a product number and contain the price
they were bought at and a quantity.  Determining on-hand values
computes the sum of all purchased and subtracts the sum of all sales. 
Profit reports work in reverse, take the sum of all sales and subtract
the sum of all purchases.  If you need more granular profit reports,
you'll want to serialize (assign a unique id to each individual
product) and attach that to the sale so you have a one-to-one
relationship with each product sold.  You need to think about what
happens when you have a sale on a product because of a special
purchase price since you may have old stock (higher price) that gets
sold at a loss.  I would start with a non-serialized product and let
the GL report balance over the period.

2) Instead of including the sale price in the product table, create a
new table to hold "pricing profiles".  Create a default pricing
profile for each product (fixed price, % over cost, % of total sale,
etc.).  You can subsequently set up alternate pricing profiles for
products that have a starting and ending time stamp.  The application
should search for alternates first before going to the default.

3) There are really two possibilities that make sense on this.  You
can either save a perfect text-copy of the receipt that prints to a
database table in a CLOB field, or you can save each receipt in it's
own normalized set of tables that contain header, details, footer, and
any other information on the check.  Using the text-copy approach will
take less development time, but using the normalized DB approach will
allow you to go back and report over the receipts as a whole,
independent of your inventory and sales tables.

If you want a designed database, then you need to provide more details
about what all you want to store (for instance, Supplier, what is
"supplier info"?  Just an address?  Key contacts?  etc.), and what
database platform you will be using.  Your development environment
might also be helpful.

Eric