POS app-open source...

[Zeljko]

Hi everybody.
Please share your opinions about creating the product's table so we can start this project.
My first suggestion was to have following fields:

a. code(barcode)
b. name
c. unit measuring
d. price-netto
e. tax
f. price-brutto
g. on-stock(number representing how much is of this product on stock)

If you think we should add something, go ahead and submit your message.

[DaveM]

Re: POS app-open source...

1- Database - let's first make all necessary tables,
We need Products table with following fields:
a. code(barcode)
b. name
c. unit measuring
d. price-netto
e. tax
f. price-brutto
g. on-stock(number representing how much is of this product on stock)

fields as it would be my way
table = sales.dbf
bcode c 22
pre c 5
first c 16 == Mr. Joe B. Jones Jr. or use last for company name
mid c 16
last c 52
sur c 5
instock n 10,2
price n 10,2
cost n 10,2
weight n 10,4 for items sold so much per pound

Inv should be posted by a table/other means and not directly touched by user. any incoming merchndise need to be input on a screen and posted to inventory by any of a number of methods.

table = inv.dbf
desc c 30
bcode c 22
count n 10,2
costeach n 10,2 can be used per pound
ppound L 1 denotes by pound

When an item is sold, it should be subtracted from inventory by some method to be determined by the group. if a return, it needs to be added back.

Need a table to cover returns to supplier for tracking?

[rmssoftware]

Re: POS app-open source...

I've alread built a small retail system with cash drawer, customer info, product sales and inventory control. What about touch screen.

[MikeC]

Re: POS app-open source...

Hi,

Just a couple of things.

I feel that a separate unique (auto)increment field should be used along side the code field.
Reason: it has been my experience that product codes WILL change sometimes even just because the case now has 48 items instead of 36. If you have to create a new product as a result (if you were using the code field as the unique identifier) you would lose all history on the product.
Date fields maybe should be added for price changes--date changed. You could go further to automate sales on an item by having a default price and then for a certain "From - To" date have the sale price come into effect. Along with this, of course, a report would have to come out stating what prices were to be changed on what days so they could be noted for employees to physically change them for customers.

Just a couple of things off the top of my head.

[Stan Mathews]

Re: POS app-open source...

Hi,

Just a couple of things.

I feel that a separate unique (auto)increment field should be used along side the code field.
Reason: it has been my experience that product codes WILL change sometimes even just because the case now has 48 items instead of 36. If you have to create a new product as a result (if you were using the code field as the unique identifier) you would lose all history on the product.
Date fields maybe should be added for price changes--date changed. You could go further to automate sales on an item by having a default price and then for a certain "From - To" date have the sale price come into effect. Along with this, of course, a report would have to come out stating what prices were to be changed on what days so they could be noted for employees to physically change them for customers.

Just a couple of things off the top of my head.

There are all sorts of issues that could be addressed depending on how complex this is to be.

Price matrix/schedule for classes of customers such as walk in vs frequent buyer/established accounts.

Cost date so that cost changes can be tracked and sales subtracted from oldest inventory. Current inventory cost could be based on actual cost of on hand inventory. Gross profitability could be computed from price charged at time of sale less actual cost of item sold.

Along with this, of course, a report would have to come out stating what prices were to be changed on what days so they could be noted for employees to physically change them for customers.

Shouldn't the system look up the price to be charged and if the sale date is within From..To period, use that price instead of the default?

My head begins to hurt when I try to consider the possibilities.

[MikeC]

Re: POS app-open source...

Stan,
:) Of course the software would know the price but usually the customer wants to see the price too...so employees would have to know when to physically change the prices marked on shelves, etc and an automatic report for this is just something to consider.

Like you said so much can be involved with any POS system...I think the main idea now is to throw out the various aspects of what a huge POS system should be so that when designing a generic application these aspects can be allowed for in future development without having to redesign the entire structure.

[DaveM]

Re: POS app-open source...

Since this is supposed to be an all inclusive POS app, All these things need to be considered and added as necessary.

I agree with those changes. Is my vote now counted??

Is it not possible to make the tables, but use different databases in the same directory for different applications?

Do we not need a user table for signing in and out? Possibly a way to track who opened what register/computer and signed in. Should we also track each thing that person did while on task? Should they have different abilities if a manager/owner/it?

LOL

Oh, who is going to make the actual first table.

Dave

[martin horzempa]

Re: POS app-open source...

Hi Guys

i am with Stan - if this is done right
it will be quite large

i just looked at the inventory control file
in my system and there are 54 fields in it
you havent yet considered price matrixes
taxable , tax vendor , multiple sales locations,
various storage options, costing methods,tender options,
customer levels,sales orders, purchase orders, and on and on

i dont want to throw cold water on your project
but if i were to attempt such a thing i believe that i
would NOT start with a blank sheet here

there are open source projects for this (that already exist)
so the first thing i would do is download one and
then take a look at their data tables , relationships,
dependencies, keys, indexes etc.

there is no sense reinventing the wheel

from there you would have a good starting point
and then could create your tables in a5 and then
provide the functionality with xbasic

one opensource project that i know of is a java
project freemercator- and there must be more
do a web search on [opensoucre POS] and i am sure you will get plenty of hits

good luck

[Zeljko]

Re: POS app-open source...

Ok folks, let's start from here.
Now we have three tables and one form.
Come with your comments and suggestions....

[DaveM]

Re: POS app-open source...

just looked at the inventory control file
in my system and there are 54 fields in it
you havent yet considered price matrixes
taxable , tax vendor , multiple sales locations,
various storage options, costing methods,tender options,
customer levels,sales orders, purchase orders, and on and on

Martin,

Mine has 48 fields, but the companion inv cost/repairs has 7 more.

Tax: We need a field to hold sales tax and a field for the tax rate. That is easy in this county and state, but some have state, county, municipality, etc. What about tracking fuel taxes.

Ok folks, let's start from here.
Now we have three tables and one form.

Maybe design should come first? Lets make sure what fields we need before we make the tables?

Dave

[Zeljko]

Re: POS app-open source...

Well, I think you guys are going too deep into subject. My intention was not to make perfect POS app but to start open source project where everybody can contribute. So far, we had a lot of comments,suggestions etc. what probably makes begginers confused.
Please folks, we don't want to start a competition here of who knows more or who can do more. Just simply DO SOMETHING, but please don't complicate too much. Let's try to go from basic database's we need.
Come up with your suggestions, or download project that I've attached and make changes....

[MikeC]

Re: POS app-open source...

Zeljko,

I don't think the intention of most here was to confuse matters....but any project such as this, which eventually could become a very large project, should allow in its design the flexibility to accomodate the many other features mentioned. If what has been mentioned is not considered from the get-go, then what most likely would happen is we would have to have several basic POS applications here each which would accommodate various aspects of differing POS apps.

I applaud the ambition of this and think that it is a terrific way to help each other and new people. And sometimes to get something done, especially with more than one person involved, is to do as you suggested--just dive in and start--matters not where at first so long as some design strategy has been thought out...knowing full well that changes will most likely have to made.

[Zeljko]

Re: POS app-open source...

Ok Mike, I agree with everything with Stan, Dave and others. Shell we finally start something otherwise I'll be too old for this :)
If someone can take my products.dbf and do necessary corrections, it would be a good start. Or, just look at it and say what you think....
(My father (God rest his soul) used to say, "It is nice to be a philosopher or politician when there is a crowed of people to listen and do the work for you")

[DaveM]

Re: POS app-open source...

Here is a beginning. Add or change what you feel necessary to do business. Lets all critique it and the changes.

I made no forms or sets yet but see a need for sets and lookups. We could also make a faster one utilizing variables and arrays co-mingled with the right forms.

I will make an exe to run it if anyone wants it once we get to that point.

Dave Mason

[DaveM]

Re: POS app-open source...

forgot zip.

I put it in directory: c:\opos and named db as opos.adb.

Dave