Re: [CK-Ledger-users] Re: I would like to help

[C K Wu <ck...@ch...>]

Hi, Brook,

Brook Humphrey wrote:

> On Friday 24 May 2002 10:20 pm, you wrote:
> > Hi, Brook,
> >
> > Thanks for checking out ck-ledger and offering to help.
> > In fact, you come in at the perfect moment.
> >
> > The POS module should be ready for release within a week.
> > After that, if you wish, you could take over the POS module,
> > and I'll move on to hr, payroll, time billing and the Chinese
> > versions that I am dying to produce.
>
> I will do what I can Like I said I con do php but I am no accountant. Also to
> mention I am not even familiar with the laws dealing with accounting and
> whatnot. I just know I need to keep track of inventory and sales and A nice
> POS settup whould be real nice.
>
> I would probably be the most help in the usability aspect of the POS.
>
> >
> > The basic POS module covers special limited period pricing,
> > addon charge/reduction (percentage-wise) based on total sale,
>
> Does ck-ledger also handle an automatic markup at differnt levels of pricing
> based on percentage for each item by itself? If this is not clear I can word
> it better.
>

If you are referring to something like,
$10 items    - priced at 110% of cost.
$100 items    - priced at 120% of cost.

The answer is no.  But, it would certainly be something to consider as an
enhancement.
The features that I am building is to allow special blanket discount during say,
Christmas season or special surcharge during Easter Sunday for restaurants.

>
> > accepting quasi-cash to handle credit cards, personal cheque,
> > smart (stored-value) card, direct bank debit, gift coupons, etc.
>
> Doese this mean that the credit cards could be processed in real time over the
> net through different authorization services like authorize.net or whatever?

No, there are too many interfacing issues to consider (for me at least),
ie diff authorization services, diff credit card / smart card readers.
Bank card reader may be diff in diff countries. Etc..

>
>
> >
> > As far as I can see, from here on, there are five possible areas
> > of enhancement,
> >
> > a)    Sale Promotion Plans:  I have already added "sales_plan_id"
> >         fields in the relevant tables.
> >
>
> Yes this whould be good to impliment. I think I could handle this.
>
> > b)    Composite Pricing:  ie, when disparate parts are
> >         purchased all at the same time, the total price will be
> >         reduced significantly.  I have been trying to combine
> >         this with the idea of an assembly (already implemented
> >         in ck-ledger).  However, I couldn't find a easy clear cut
> >         design.  You would probably have better idea on this.
> >
>
> Are you saying for instance if someone should by all the parts to make a
> computer but not actually by a perbuilt computer they whould get a discount
> on pricing for the overall purchase?
>
> I whould normally write this up as a assebly also but in this case I'm not
> sure. An assembly also whould include labor costs which this does not incure.
>

This is a safeguard, rather than a pricing utility.  This is to avoid a customer,
coming back to the shop and yell,

"My neighbor bought the same keyboard, monitor, cpu box as 'a workstation' at
10% less than what I paid.  Your system should automatically detect that
I had purchased all the workstation parts in one go and automatically give me
the 'workstation' pricing.".

You'll probably find it implemented on the supermarket docket receipts.
However, most of them are being implemented in a rather twisted manner.

BTW, I can't remember if I have guarded service items (say, labour)
as part of an assembly.  If so, it's a simple exercise of relaxing the design
to include service items.

>
> > c)    Incentive scores:  to allow small shops to create their own
> >         customer loyalty program (similar to airline's frequent
> >         flyer program).  However, there seems to be an undercurrent
> >         within the accounting profession requiring disclosure of
> >         potential liabilities under these kinds of program.  So, it's
> >         somewhat unstable, in terms of interfacing with the General
> >         Ledger.  Perhaps, facility to allow small shops to join
> >         one of the existing programs will be sufficient.
>
> This sounds good where you whould have many local business' able to pass
> savings on to other locals.
>
> >
> > d)    PDA interface:  a interface to allow the relevant info
> >         to be displayed at the salesperson's palm pilot via a shop
> >         floor wireless LAN.  This will allow the salesperson, manning
> >         the shop floor, to answer questions like (in realtime),
> >         "I am a gold card member, am I entitled to 50% discount ?"
> >         "I came in two months ago, and it was much cheaper."
> >         "What's my total purchase now, and at this level, do I have any
> > discount?"
> >         "I am a senior citizen, if I purchase all three items as a set,
> >             on Easter Sunday, using 3x$10 cash coupons, 7x$1.5 gift
> > certificates,
> >
> >             how much cash do I need to pay ?"
> >         Brian Johnson from Canada may have some ideas on this one.
> >
>
> This sounds good I'm not such a big shop but I could see the uses for this.
>
> > e)    Provide interface/driver for conventional cash register hardware.
> >         I have the slightest idea on this one.
>
> I don't currently have this kind of hardware but I may be able to get
> something working. If I am it whould not be right away.
>

Everything should become clearer when the POS module is released.
Perhaps, we could discuss your preference then.

Cheers,
CK