ck-ledger-users — Mailing list and discussion group for CK-Ledger Users

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

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

Hi, Brook,

I've just completed the release of ck-ledger 0.0.11, which
is mainly for the addition of 2 POS modules.  Please try
out the new POS features and see if it's something you
like to dip your hand into.

Cheers,
CK

C K Wu wrote:

> 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

[CK-Ledger-users] CK-Ledger v.0.0.11 released

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

Hello, folks,

I have posted a new (final pre-beta) release, v.0.0.11, of CK-Ledger, at
SourceForge.Net.

The new release incorporates 2 POS modules (POS for cashier and POS for
manager) and other minor enhancements and bug fixes.  Among the POS
features is a simple one level tax on tax facility.

Please note that Konqueror/KDE3/RedHat7.3 has problem accessing the
various features of CK-Ledger,  while Konqueror/KDE2 and other browsers
have been tested to work fine under similar circumstances.

CK-Ledger (with 11 modules, Ledger Admin, Ledger, Inventory, Service,
AP, AR, PO, SO, Quotation, POS for Cashier, POS for Manager) is modeled
on an Open Source accounting software and runs on top of phpGroupWare.
It provides accounting functionalities to SMEs and utilizes phpgw to
administer accounts/groups.  Installation Manual for CK-Ledger is
available at http://sourceforge.net/projects/ck-ledger.  Please report
error and suggestion to the mailing list,
ck-...@li....  General history and expected
development of CK-Ledger is available at the mailing list's Archive.

Cheers,
Wu Chiu Kay, aka CK Wu, aka CK (CK is the preferred alias)
Hong Kong

[CK-Ledger-users] Re: ck ledger

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

Hello, Travis,

Thanks for checking out ck-ledger.

Actually, starting from release 0.0.9, ck-ledger had started to depart
from SQL-Ledger.  So far as I can remember, Quotation is not included
in SQL-Ledger.  The upcoming POS module is not even part of
SQL-Ledger's future plan.  The SQL-Ledger's team had actually made
a request that I kept ck-ledger and SQL-Ledger separate, so I think
the current diverging path between the two projects would be beneficial
to both.

With basic functionalities, there are indeed a lot of SQL-Ledger's features
that I had not implemented, notably multi-currency, conversion of invoice,
po, so to pdf format for universal print, etc.  One important thing to note,
though,
the internal data structure of the two projects are quite different, eg database

fields of the same name could mean diff things, etc.

I don't think it is a good idea to port all features of SQL-Ledger to ck-ledger,

but if you consider a feature essential and it is fair easy to implement the
feature within the current structure of ck-ledger, by all means, dip it and
try your hand on it.

Best Regards,
CK

Travis Smith wrote:

> I noticed your project on sourceforge and am interested in checking it out
> and possibly doing development with it.  My question is, as far as the basic
> accounting modules that you've ported from SQL-Ledger (LedgerAdmin, Ledger,
> Inventory, Service, AP, AR, PO, SO, Quotation), do they have the same
> functionality as the corresponding modules in SQL-Ledger, or is there still
> some porting to be done?
>
> trav

[CK-Ledger-users] Re: ck-ledger

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

Hi, Adam,

Thanks for checking out ck-ledger.

If axisgroupware is a distribution of phpgroupware, there may
be a chance that ck-ledger is able to operate atop axisgroupware
without any modification.  If it does, could you send me a
email, I'll add this in the installation manual, so
people could apply the axisgroupware + ck-ledger combination,
if they so wish.

CK-Ledger is designed to operate against both MySQL and
PgSQL.  All releases, except 0.0.5, had been tested against
both DB engines before being posted at sourceforge.net.

I think you have also posted a query at ck-ledger forum.   Since
sourceforge.net seems to be offline/busy at the moment,
I'll answer your query here.

In deed, ck-ledger does have its own table scripts and is
available as user menu choices.  The process of building
the db table is detailed in steps 20 - 41 of the Installation
Manual   It is also repeated in the User/Administrator
column of each module's index page.

By the way, I am building 2 POS modules for ck-ledger.  There
should be a new release of ck-ledger within the next couple
of days.  You may like to check out the latest release then.

I am also sending this email to the
ck-...@li...,
so the others are awared of current development.

Best Regards,
CK

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

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

[Brook H. <ba...@we...>]

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.

> 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? 

>
> 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.

> 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.

>
> How does it sound ?
> CK
>
> [PS - I am also forwarding this to the ck-ledger-users lists to allow
> others some idea of current development.  Hope you don't mind.]

No I don't  mind and I sent this dirrectly to the list so that replies will be 
forwarded correctly to the lsit.

-- 
 -~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-
                                      Brook Humphrey           
        Mobile PC Medic, 420 1st, Cheney, WA 99004, 509-235-9107        
http://www.webmedic.net, ba...@we..., ba...@li...   
                                 Holiness unto the Lord
 -~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-

Re: [CK-Ledger-users] accno ...

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

Robert,

With project accounting, there is the issue of allocating common expenses
across diff projects.  I guess it is better to leave this as a 2nd stage
development, and merely add a comment at the index page indicating
expense allocation is to be done manually for the moment.

Since all modules do feed journals into the gl table, and we may not
be able to update the entire code base too swiftly, it may be a good
idea to do a little experiment.

1.    Start with a clean ck-ledger install.
2.    Generate a clean set of test data.
3.    Add in the attribute fields via console command.
4.    Go back to ck-ledger.
5.    Add in a few invoices, settle a few invoices, ... etc.
6.    Check to see how broken the system becomes

This would also generate a list of hidden errors or bugs to
be expected while you are progressing with the Rental module.

Would you like to work on the experiment ?

Cheers,
CK

C K Wu wrote:

> Adding fields to the gl table is definitely the best way to go about it.
> However, I would suggest generalising the setup a little bit, since the
> same feature can be utilized for product line P/L, regional P/L and/or
> departmental P/L reporting for commercial organizations.  The added
> fields could be termed something like, attrib1, attrib2, attrib3 (I think
> three attribute fields is about right).  The
> 'defaults' table will carry the captions for these fields.  Whenever
> these fields are displayed on screen or in report, the caption title will
> be extracted from the 'defaults' table.  This is how I handle the primary
> and secondary tax fields.  This way, the same code base can be
> implemented in public agencies to handle fund/project accounting,
> and in commercial business to handle product line/departmental accounting.
>
> I'll send you a separate email to cover other issues.
>
> Got to catch some zzzzzzz's.
>
> Cheers,
> CK
>
> robert del huerto wrote:
>
> > On Saturday 25 May 2002 10:46 am, C K Wu wrote:
> > > The account number is fine.  Lengthy account code can be a pain in
> > > the neck for the person performing the actual journal entry coding/input.
> > >
> >
> > I know it's a pain.  But, some people have to use fund and project accounting.
> > :(  For example, a public agency that is awarded a new grant to complete
> > certain new projects.  They would need to use the same account numbers they
> > already have plus attach a prefix to track the new grant fund and another
> > prefix for each of the different projects.  They would have to provide
> > financial statements for each fund (sometimes per project) and consolidated
> > financial statements which include all funds and projects.
> >
> > I'm wondering if you think it'd be alright for me to add fund and project
> > fields to the gl table (instead of the chart table.)
> >
> > Assuming we keep account numbers the same, we could add fund and project
> > accounting by doing this:
> >
> > $where = " WHERE 1=1 " ;
> >   if ($fund) {
> >       $where .= " AND fund = $fund_source";
> >       if ($project)     $where .= " AND project = $project_source";
> >   }
> >   if ($from)            $where .= " AND transdate >= $from_date ";
> >   if ($to)              $where .= " AND transdate <= $to_date " ;
> >   if ($source)          $where .= " AND lower(source) like lower('%$source%') " ;
> >   if ($description)     $where .= " AND lower(description) like
> > lower('%$description%') " ;
> > $where = urlencode($where) ;
> >
> > This would give you fund and fund/project views of the general ledger/journal
> > entries.  We could probably do something similar in all other modules (I
> > haven't taken a look at all the code yet.)
> >
> > What do u think?  Would there be a better way to implement this in the current
> > code?
> >
> > robert
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> CK-Ledger-users mailing list
> CK-...@li...
> https://lists.sourceforge.net/lists/listinfo/ck-ledger-users

Re: [CK-Ledger-users] accno ...

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

Adding fields to the gl table is definitely the best way to go about it.
However, I would suggest generalising the setup a little bit, since the
same feature can be utilized for product line P/L, regional P/L and/or
departmental P/L reporting for commercial organizations.  The added
fields could be termed something like, attrib1, attrib2, attrib3 (I think
three attribute fields is about right).  The
'defaults' table will carry the captions for these fields.  Whenever
these fields are displayed on screen or in report, the caption title will
be extracted from the 'defaults' table.  This is how I handle the primary
and secondary tax fields.  This way, the same code base can be
implemented in public agencies to handle fund/project accounting,
and in commercial business to handle product line/departmental accounting.

I'll send you a separate email to cover other issues.

Got to catch some zzzzzzz's.

Cheers,
CK

robert del huerto wrote:

> On Saturday 25 May 2002 10:46 am, C K Wu wrote:
> > The account number is fine.  Lengthy account code can be a pain in
> > the neck for the person performing the actual journal entry coding/input.
> >
>
> I know it's a pain.  But, some people have to use fund and project accounting.
> :(  For example, a public agency that is awarded a new grant to complete
> certain new projects.  They would need to use the same account numbers they
> already have plus attach a prefix to track the new grant fund and another
> prefix for each of the different projects.  They would have to provide
> financial statements for each fund (sometimes per project) and consolidated
> financial statements which include all funds and projects.
>
> I'm wondering if you think it'd be alright for me to add fund and project
> fields to the gl table (instead of the chart table.)
>
> Assuming we keep account numbers the same, we could add fund and project
> accounting by doing this:
>
> $where = " WHERE 1=1 " ;
>   if ($fund) {
>       $where .= " AND fund = $fund_source";
>       if ($project)     $where .= " AND project = $project_source";
>   }
>   if ($from)            $where .= " AND transdate >= $from_date ";
>   if ($to)              $where .= " AND transdate <= $to_date " ;
>   if ($source)          $where .= " AND lower(source) like lower('%$source%') " ;
>   if ($description)     $where .= " AND lower(description) like
> lower('%$description%') " ;
> $where = urlencode($where) ;
>
> This would give you fund and fund/project views of the general ledger/journal
> entries.  We could probably do something similar in all other modules (I
> haven't taken a look at all the code yet.)
>
> What do u think?  Would there be a better way to implement this in the current
> code?
>
> robert

Re: [CK-Ledger-users] accno ...

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

Robert,

I've done a little web search on 'H.U.D. Section 8'.  The search engine comes
back with info on Section 8 Housing Assistance Payment Program of
the US Department of Housing and Urban Development.  I suspect a person
in the US welfare or housing industry, after reading some of the abbreviations
in the attached Chart of Accounts (coupled with the ip address of your original
email) may be able to identify who your employer is.  So, be extra careful
about what you are sending to the ck-ledger-users list, which is very much
part of public record.  If I sound serious, I am.  Remember, Dr. Wen Ho Lee.
Afterall, Dr Lee is only backing up classified data, while what you are about
to do may be construed as exposing your employer's inferred operational
rules and procedures to the rest of the world.  [I have total confidence on US
attorneys' ability to dick up dirt and play with it in a court of law  :-( .
While,
we are all interested in contributing to the Open Source movement, it is
sometimes
necessary to protect our own interest against stupid lawyers.]  So, please,
modify the Chart of Accounts to erase any trace of your employer.  You
could still maintain characteristics that you need to work with subsequently, eg,

change Section 8 to Section Z.  In the index page of the Rental module, you
may like to add in a disclaimer indicating that the software is not related
to any real life company or organisation.  If your employer has a PR or External
Communication Department, it may be a good idea, to obtain clearance from
them for what you are about to do with ck-ledger.  Enough about stupid lawyers.

The account number is fine.  Lengthy account code can be a pain in
the neck for the person performing the actual journal entry coding/input.

At the same time, the account's category (I,E,.A,L,Q) and link field need to be
completed.  You could use the existing Chart as a guide when filling in
the link field.  At the moment, there is no hurry to establish a final
version of the new sample Chart.  Anyway, you'll probably find it
necessary to change the new sample Chart from time to time during
development.  I'll probably incorporate the new sample Chart into the
ck-ledger code only after the Rental module is completed.

Cheers,
CK

robert del huerto wrote:

> Hey, CK, what's your opinion on the account number?
>
> I asked our finance staff (they are not CPAs) if they knew of a reason to use
> more than just a 'fund', 'project', 'account' combination.  They couldn't
> think of one.  What do you think?
>
> I'm attaching a copy of our chart of accounts.  This does not include the
> funds and projects we are using.  I'll need to edit that before I send it to
> you.
>
> BTW, any errors in account numbers or descriptions are my fault.  I did a
> pretty quick editing job on the chart of accounts.  :)
>
> robert
>
>   ------------------------------------------------------------------------
>                  Name: ledger.txt
>    ledger.txt    Type: Plain Text (text/plain)
>              Encoding: 7bit

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

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

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.

The basic POS module covers special limited period pricing,
addon charge/reduction (percentage-wise) based on total sale,
accepting quasi-cash to handle credit cards, personal cheque,
smart (stored-value) card, direct bank debit, gift coupons, 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.

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.

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.

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.

e)    Provide interface/driver for conventional cash register hardware.
        I have the slightest idea on this one.

How does it sound ?
CK

[PS - I am also forwarding this to the ck-ledger-users lists to allow others
        some idea of current development.  Hope you don't mind.]


Brook Humphrey wrote:

> On Monday 20 May 2002 10:10 pm, C K Wu wrote:
> I too whould like to help. I like sql-ledger but it's in perl. Php is much
> more usable for me. One thing of not I'm not an accountant and just do books
> for my computer store but I would be willing to test and report any problems,
> provide my chart of accounts for my small store as a demo chart, etc.
>
> I can program php and do so for a living at times. I own the company and
> everything I've done so far has been gpl. So that's not an issue. I would be
> extreamly insterested in helping with the POS as I'm in need of such a
> component.
>
> Any reply whould be appriciated.
>
> --
>  -~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-
>                                       Brook Humphrey
>         Mobile PC Medic, 420 1st, Cheney, WA 99004, 509-235-9107
> http://www.webmedic.net, ba...@we..., ba...@li...
>                                  Holiness unto the Lord
>  -~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-

[CK-Ledger-users] accno ...

[robert d. h. <rd...@st...>]

Hey, CK, what's your opinion on the account number?

I asked our finance staff (they are not CPAs) if they knew of a reason to use 
more than just a 'fund', 'project', 'account' combination.  They couldn't 
think of one.  What do you think?

I'm attaching a copy of our chart of accounts.  This does not include the 
funds and projects we are using.  I'll need to edit that before I send it to 
you.  

BTW, any errors in account numbers or descriptions are my fault.  I did a 
pretty quick editing job on the chart of accounts.  :)


robert

[CK-Ledger-users] accno

[robert d. h. <rd...@st...>]

After some testing, I realized I made another mistake.  In 
class.account.inc.php, the following line:

elseif (!is_valid_account($a[accno]))   $err='<b>[[Error: Invalid Account 
Number]]</b>';

is missing '$this->'   It should read:

elseif (!$this->is_valid_account($a[accno]))   $err='<b>[[Error: Invalid 
Account 
Number]]</b>';


I'm gonna catch some zzzzzzzzzzzzzzzzzzzzz's now.


see you

Re: [CK-Ledger-users] accno

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

robert del huerto wrote:

> On Thursday 23 May 2002 04:54 am, C K Wu wrote:
> > I am afraid there is some confusion over the purpose of the 'accno'
> > and the 'id' field within the 'chart' table.
> >
>
> oops, didn't see that.  Well, I deleted my tables and edited
> /ck-ledadmin/adminsetup.php.  Inside, I changed this line:
>
> $sql = "CREATE TABLE chart ($id_field, accno int UNIQUE,description text," ;
>
> to:
>
> $sql = "CREATE TABLE chart ($id_field, accno char(20) UNIQUE,description
> text," ;
>
> Then I created the chart of accounts, master data, and sample data.
>
> I looked at table 'chart' and all of the records were there.  So, I guess that
> means the install code works with the new 'acct no' type.  :)
>

Lovely.  However, you may like to watch out for something down the road.
In some of the crowded screens (eg, invoice input), account selection box
occupies quite a portion of the screen.  When the current 4-digit account# is
expanded to 12 digits or more, there may be problem with how the browser
handles the expanded selection box.  But, the whole thing will automatically
disappear, when 1280x1024 becomes the standard display :-) .

>
> > The design of   "ap.ap_accno_id, ..... " => "chart.id" (design 1), instead
> > of, "ap.ap_accno_id,...." => "chart.accno" (design 2) is to separate
> > internal pointer structure from external interface.
> >
>
> Nice.
>
> robert
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> CK-Ledger-users mailing list
> CK-...@li...
> https://lists.sourceforge.net/lists/listinfo/ck-ledger-users

Re: [CK-Ledger-users] accno

[robert d. h. <rd...@st...>]

On Thursday 23 May 2002 04:54 am, C K Wu wrote:
> I am afraid there is some confusion over the purpose of the 'accno'
> and the 'id' field within the 'chart' table.
>

oops, didn't see that.  Well, I deleted my tables and edited 
/ck-ledadmin/adminsetup.php.  Inside, I changed this line:

$sql = "CREATE TABLE chart ($id_field, accno int UNIQUE,description text," ;

to:

$sql = "CREATE TABLE chart ($id_field, accno char(20) UNIQUE,description 
text," ;

Then I created the chart of accounts, master data, and sample data.

I looked at table 'chart' and all of the records were there.  So, I guess that 
means the install code works with the new 'acct no' type.  :)

> The design of   "ap.ap_accno_id, ..... " => "chart.id" (design 1), instead
> of, "ap.ap_accno_id,...." => "chart.accno" (design 2) is to separate
> internal pointer structure from external interface.  
>

Nice.


robert

Re: [CK-Ledger-users] accno

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

Robert,

I am afraid there is some confusion over the purpose of the 'accno'
and the 'id' field within the 'chart' table.

In the 'chart' table, the two fields ,
    id - internal (to ck-ledger, unique systemwise) record identifier
        - type: integer.
    accno - human-readable account number
                - type: text (potentially free-format).
serve different purposes.

The other ' _id' ending fields in the other tables are internal pointers
pointing back to the individual 'chart' records, so they should accord
with the 'id' field type.

The "accno" field is mainly for human consumption so it could be
structured differently according different organisational settings, eg,
additional structural validation checks (check digits, etc) can be
instituted on this field.

The design of   "ap.ap_accno_id, ..... " => "chart.id" (design 1), instead of,
"ap.ap_accno_id,...." => "chart.accno" (design 2) is to separate internal
pointer structure from external interface.  This way, the internal
pointer does not have to concern itself with the structure of the
account number, which varies installation from installation.

SQL-Ledger, actually shifts from design 2 to design 1 back at version 1.2.x (?)
.

So, ap_accno_id....., should stay as int.  Oh, and the change to
class.account.inc.php is fine.

Cheers,
CK


robert del huerto wrote:

> Okay, this is what I've changed so far...
>
> in class.account.inc.php I changed the following line:
>
> elseif (!is_numeric($a[accno])) $err='<b>[[Error: Invalid Account#, must be
> numberic]]</b>';
>
> to:
>
> elseif (!is_valid_account($a[accno]))   $err='<b>[[Error: Invalid Account
> Number]]</b>';
>
> ..and I added the following function which we can improve on later.
>
>      function is_valid_account($accno) {
>
>          return true;
>
>          }
>
> I also changed the following fields from int to char(15):
>
> gl.accno
> ap.ap_accno_id
> ar.ar_accno_id
> defaults.inventory_accno_id
> defaults.income_accno_id
> defaults.expense_accno_id
> invoice.inventory_accno_id
> invoice.income_accno_id
> invoice.expense_accno_id
> invoice.tax1_accno_id
> invoice.tax2_accno_id
> parts.inventory_accno_id
> parts.income_accno_id
> parts.expense_accno_id
> payment.dr_accno_id
> payment.cr_accno_id
> receipt.dr_accno_id
> receipt.cr_accno_id
> service.income_accno_id
> service.expense_accno_id
>
> Okay, let's see how things work now.
>
> robert
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> CK-Ledger-users mailing list
> CK-...@li...
> https://lists.sourceforge.net/lists/listinfo/ck-ledger-users

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

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

Hi, Robert,

robert del huerto wrote:

> On Wednesday 22 May 2002 07:19 am, C K Wu wrote:
> >
> > Welcome on board.  Please go ahead and develop the Rental module.
> >
>
> Thanks, I'll try.  ;)
>
> >         ....  Substantial testing will have to be made
> >         to ensure that the new 'accno' field is useable by other modules.
>
> Will do.
>
> > e)    Please ensure that you can assign copyright of your finished
> >         work to the public under GPL.
>
> I won't be working on ck-ledger at work.  All development will be done on my
> free time.  The GPL will be the license for the code.
>
> > f)    When developing the Rental module, you may like to make
> >         provision for turnover rent, rent free period and other
> >         non-recurring charges, like air-conditioning, off-hour lighting
> >         etc.  These would be useful for rentals over a commercial
> >         office/arcade complex.
>
> What we do now is to manually enter these types of transactions.  Would that
> work for you?
>

Fine by me.  But, just as a suggestion, I have seen design like this,
    Recurring charge (stable over the course of one year) kept in master table:
        - rental, municipal rate, fixed monthly water, gas, electricity charges
    Non-recurring charge (changes every month or fortnight) kept in transaction
table:
        - aircon, offhour services, overdue interest, penalty, etc.
It's your call.

>
> > g)    The collection of private household information is a rather
> >         touchy issue.
>
> The sensitive data will be kept in a separate and optional module that will
> provide HUD compliance to those that need it.
>
> I'll start off with the waiting list.  Here's a quick run down:
> - applicant is added to the waiting list and is date/time stamped
> - optional preferences are given to affect the position in the waiting list
> - applicants are transferred to newly available units based on waiting list
> sort criteria
>

With any waiting list, there is always a suspicion of official corruption,
ie buying off officials to jump ahead of the queue.  I would suggest, besides
date/time stamping, to add,
a)    audit trail on 'who' ($phpgw_info["user']["userid"]) performs a position
modification transaction
b)    control over 'who' is allowed to perform such transaction.

[BTW, you may have already guess this.  I have been a computer auditor for a
number of years,
so I am pretty interested in ensuring auditability and control of the finished
system.]

>
> Since tenants are a/r accounts, should I use the same a/r ledger to keep track
> of tenants?  Or should I put them into an a/r subsidiary ledger and track
> them in a different set of tables?  What do you think?

With ck-ledger's design, the customer(tenant) debt balance and invoice history
(ie the entire A/R module) is the equivalent of an a/r subsidiary ledger and the
'Account Receivable' in the main ledger is really serving the purpose of an A/R
control account.

>
>
> Hey, CK, will you be adding the prefix 'phpgw_ckledger_' to all of the tables?

> Is it cool if I add it to the tables I create?
>

The reason why I haven't follow phpgw's table naming convention was while
porting sql-ledger to phpgw, I was using sql-ledger's tables as a starting point,
making sure that the initial system is able to read/write sql-ledger tables
correctly.
I must admit, by now, I am not too keen on adding back the prefix, since it
involves
modifying just about everyone of the script files.  So, if you prefer, do add in
the prefix for the tables you create, but I wouldn't consider it a necessity.  If
necessary,
I'll dedicate a single release for adding back the prefix in the future.

>
> robert
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> CK-Ledger-users mailing list
> CK-...@li...
> https://lists.sourceforge.net/lists/listinfo/ck-ledger-users

Cheers,
CK

[CK-Ledger-users] accno

[robert d. h. <rd...@st...>]

Okay, this is what I've changed so far...

in class.account.inc.php I changed the following line:

elseif (!is_numeric($a[accno])) $err='<b>[[Error: Invalid Account#, must be 
numberic]]</b>';

to:

elseif (!is_valid_account($a[accno]))   $err='<b>[[Error: Invalid Account 
Number]]</b>';

..and I added the following function which we can improve on later.


     function is_valid_account($accno) {

         return true;

         }

I also changed the following fields from int to char(15):

gl.accno
ap.ap_accno_id
ar.ar_accno_id
defaults.inventory_accno_id
defaults.income_accno_id
defaults.expense_accno_id
invoice.inventory_accno_id
invoice.income_accno_id
invoice.expense_accno_id
invoice.tax1_accno_id
invoice.tax2_accno_id
parts.inventory_accno_id
parts.income_accno_id
parts.expense_accno_id
payment.dr_accno_id
payment.cr_accno_id
receipt.dr_accno_id
receipt.cr_accno_id
service.income_accno_id
service.expense_accno_id


Okay, let's see how things work now.



robert

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

[robert d. h. <rd...@st...>]

On Wednesday 22 May 2002 07:19 am, C K Wu wrote:
>
> Welcome on board.  Please go ahead and develop the Rental module.
>

Thanks, I'll try.  ;)


>         ....  Substantial testing will have to be made
>         to ensure that the new 'accno' field is useable by other modules.

Will do.


> e)    Please ensure that you can assign copyright of your finished
>         work to the public under GPL.  

I won't be working on ck-ledger at work.  All development will be done on my 
free time.  The GPL will be the license for the code.


> f)    When developing the Rental module, you may like to make
>         provision for turnover rent, rent free period and other
>         non-recurring charges, like air-conditioning, off-hour lighting
>         etc.  These would be useful for rentals over a commercial
>         office/arcade complex.

What we do now is to manually enter these types of transactions.  Would that 
work for you?


> g)    The collection of private household information is a rather
>         touchy issue.

The sensitive data will be kept in a separate and optional module that will 
provide HUD compliance to those that need it.

I'll start off with the waiting list.  Here's a quick run down:
- applicant is added to the waiting list and is date/time stamped
- optional preferences are given to affect the position in the waiting list
- applicants are transferred to newly available units based on waiting list 
sort criteria

Since tenants are a/r accounts, should I use the same a/r ledger to keep track 
of tenants?  Or should I put them into an a/r subsidiary ledger and track 
them in a different set of tables?  What do you think?

Hey, CK, will you be adding the prefix 'phpgw_ckledger_' to all of the tables? 

Is it cool if I add it to the tables I create?



robert

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

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

Hello, Robert,

Welcome on board.  Please go ahead and develop the Rental module.

At the same time, you may like to take note of the following,

a)    Please develop the rental facility as a separate module,
b)    The 'accno' field can certainly be changed to a text field.
        However, the validation (in class.account.inc.php) to ensure
        'accno' is numeric will have to be changed.  Please inform
        me the change that you have made, so I can synchronize your
        version with mine.  Substantial testing will have to be made
        to ensure that the new 'accno' field is useable by other modules.
c)    If at all possible, could you generalise your chart of account, so
        it may serve as a sample chart for government organizations
        or public agencies.  I'll lodge it with the main ck-ledger code
        as one of the sample charts.
d)    Please ensure that your software and data setup does not
        reveal the identity of the agency you are employed with.
e)    Please ensure that you can assign copyright of your finished
        work to the public under GPL.  [AFAIK, some employment
        contract allows the employer to own the total intellectual
        property right of an employee's work].
f)    When developing the Rental module, you may like to make
        provision for turnover rent, rent free period and other
        non-recurring charges, like air-conditioning, off-hour lighting
        etc.  These would be useful for rentals over a commercial
        office/arcade complex.
g)    The collection of private household information is a rather
        touchy issue.  You may like to include them as optional items,
        or inside a separate module.  In Hong Kong, we have very
        strict privacy law and the Privacy Commission is always
        breathing over the neck of data collectors.  I'll be the first to
        admit that ck-ledger does not have sufficient safeguard
        against unauthorised read access.

Happy Coding,
CK

robert del huerto wrote:

> On Tuesday 21 May 2002 05:10 am, C K Wu wrote:
> > a)    Develop a sample chart of account for your country of residence.
>
> I work for a public agency that receives funds from several different sources
> with the primary source being the government.  So, other than having a chart
> of accounts that's slightly different than the default, we need to keep track
> of different fund sources.  Additionally, we need to keep track of different
> projects within each fund group.  In other words, we need account numbers
> that look like:
>
> 10-2302-100001  Checking Account
>
> ...this being the checking account for fund 10 project 2302.
>
> Currently, I see the account number stored as an int(11) field.  Would it be a
> bad idea to change that to a text string?  The whole account no
> "10-2302-100001" could be stored in the field.  Or, two other fields could be
> added for fund and project data.  What do you think?
>
> > 5.    For Rental/FM, a demo system (www.fm-sytem.no/demo/) had already
> >         been developed atop phpgroupware.  You may like to check it,
> > although
> >         the system is geared mainly towards FM.
> >
>
> It does appear to be mostly an FM app.
>
> Here's what my agency needs in terms of a rental app that's similar to the
> needs of a commercial housing complex:
>
> - Track tenant account receivable balances
>      (charge fees and receive payments)
> - Run a monthly batch rent run
>      (charges all rents for the month)
> - Provide tenant move-in and move-out processing
> - Track unit turn-around rates
>      (how long is a unit vacant and why)
> - Provide for tenant and unit inspection generated work orders
> - Provide time-billing for work orders
> - Provide an interface to the inventory and purchase order apps
> - Provide a waiting list for applicants waiting for a unit
> - etc.
>
> In addition, we would need a wealth of information about tenants including
> their household composition, income sources, assets, medical expenses, etc.
> in order to calculate the amount of public assistance for which they qualify.
> This information would, of course, not be needed by commercial rental
> companies.
>
> What if I get started on the rental and tenant processing side and later we
> can decide whether to use www.fm-sytem.no's software or develop our own?
>
> robert
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> CK-Ledger-users mailing list
> CK-...@li...
> https://lists.sourceforge.net/lists/listinfo/ck-ledger-users

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

[robert d. h. <rd...@st...>]

On Tuesday 21 May 2002 05:10 am, C K Wu wrote:
> a)    Develop a sample chart of account for your country of residence.

I work for a public agency that receives funds from several different sources 
with the primary source being the government.  So, other than having a chart 
of accounts that's slightly different than the default, we need to keep track 
of different fund sources.  Additionally, we need to keep track of different 
projects within each fund group.  In other words, we need account numbers 
that look like:

10-2302-100001  Checking Account

...this being the checking account for fund 10 project 2302.

Currently, I see the account number stored as an int(11) field.  Would it be a 
bad idea to change that to a text string?  The whole account no 
"10-2302-100001" could be stored in the field.  Or, two other fields could be 
added for fund and project data.  What do you think?


> 5.    For Rental/FM, a demo system (www.fm-sytem.no/demo/) had already
>         been developed atop phpgroupware.  You may like to check it,
> although
>         the system is geared mainly towards FM.
>

It does appear to be mostly an FM app.  

Here's what my agency needs in terms of a rental app that's similar to the 
needs of a commercial housing complex:

- Track tenant account receivable balances 
     (charge fees and receive payments)
- Run a monthly batch rent run 
     (charges all rents for the month)
- Provide tenant move-in and move-out processing
- Track unit turn-around rates
     (how long is a unit vacant and why)
- Provide for tenant and unit inspection generated work orders
- Provide time-billing for work orders
- Provide an interface to the inventory and purchase order apps
- Provide a waiting list for applicants waiting for a unit
- etc.

In addition, we would need a wealth of information about tenants including 
their household composition, income sources, assets, medical expenses, etc.  
in order to calculate the amount of public assistance for which they qualify.  
This information would, of course, not be needed by commercial rental 
companies.

What if I get started on the rental and tenant processing side and later we 
can decide whether to use www.fm-sytem.no's software or develop our own?


robert

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

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

Hello, Robert,

Thanks for checking out ck-ledger and offering to help.
We do need any help that is available.

The current status with ck-ledger is that a new release of
ck-ledger is going to be made within the next two weeks.
The new release will carry two POS modules.  After that,
modules on HR, Payroll, time billing will be tackled.  Further
on, Rental/Facility Management (FM) System is planned.

If you like to pitch in, my suggestions are (in stepwise progression),

a)    Develop a sample chart of account for your country of residence.
b)    Provide adjustment to ck-ledger to cover specific tax requirement
        of your country, although a fair number of tax requirements
(like
        tax on tax) is difficult to implement within ck-ledger's
framework.
c)    Add your country's local language to ck-ledger.  [Local language
        capability is already built into phpgroupware].  BTW, I am
scrambling
        to find time to produce Chinese versions of ck-ledger.
d)    Take full responsibility to develop the Rental/FM modules.
Rental/FM
        is not linked to the other planned modules, and the underlying
billing facility
        is already well completed.  You could actually start on
Rental/FM at
        a very early stage.

You may also like to take note of the following points,

1.    The scheme above is not a strict requirement.  But, it helps you
to
        familiarise with the structure of ck-ledger and provide
check-points
        at which you could decide whether to proceed further.  However,
        you may have different ideas.  I am all ears.

2.    In terms of templates, you may like to check out

http://www.phpgroupware.org/cvsdemo/etemplate/doc/etemplate.html.
        Apparently, etemplate is a module within phpgroupware, that
provides
        tools for constructing templates.  [I haven't try it myself]

3.    One of the basic design of ck-ledger is that it is runnable
against Mysql and
        Postgresql.  Therefore, when coding the sql statement, you may
have to
        be careful to ensure postgresql compatibility.

4.    Again, ck-ledger is designed to run on top of phpgroupware.  You
would
        need to watch the continuing development of phpgroupware.

5.    For Rental/FM, a demo system (www.fm-sytem.no/demo/) had already
        been developed atop phpgroupware.  You may like to check it,
although
        the system is geared mainly towards FM.

I am forwarding this email to ck-...@li..., so
the others
have an ideas of what's going on.

If you have any other ideas, feel free to give me and
ck-...@li...
a email.

Best Regards,
CK


Robert Del Huerto wrote:

> Hey, ckwu.  How are you doing?
>
> I would like to help develop ck-ledger.  In fact, I've
> already begun tweaking the templates a bit to make it a
> little easier for my users to understand.  I'd like to
> deploy ck-ledger in the near future at our organization
> and test its robustness in a real production
> environment.  I'm not ready to switch our accounting
> system to ck-ledger but that is my intention.
>
> I was going to use sql-ledger but I'm not
> comfortable with perl or postgresql.  However, I feel
> at home with php/mysql.  I'm stumbling through
> templates (I've never used them before) but I'm getting
> the hang of it.
>
> BTW, once the accounting system is stable enough, I'd
> like to add a tenant a/r system to track rental units.
>
> Please let me know how I may be of assitance.  :)
>
> robert

[CK-Ledger-users] Re: Distributions

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

Hi, Geoff,

Your diagnostic is indeed right on the point.

When I was testing the initial release of ck-ledger, 0.0.5
with RedFlag Linux (a major distro in China), the problem
was the included Postgres being 6.x.x.  The way I
got around it, was to use a remote DB Server running
Postgres 7.x.x over RedHat 7.2.

With Mysql, there seems to be an indication that even
phpgroupware-0.9.12 requires Mysql-3.23+, due to
a key length limitation posted by Mysql-3.22.

I presume you could try to run a remote Postgres 7.x.x or
Mysql-3.23+ server over a non-Debian distro to
confirm if the failure of the combined (debian +
phpgroupware-0.9.14RCx + ck-ledger) system is due
to the DB version.

I have also tried the other approach of upgrading
the Postgres version of my RedFlag Linux machine,
ending with total failure.

Phpgroupware 14RC3 is definitely not stable yet.  That
actually highlights a weakness with the current phpgroupware
development process.  There are too many modules to
synchronize when upgrading to a new release.  This couples
with different underlying distros incorporating different php,
db, ldap,etc.. versions, could result in a lot of RCs being issued
before
a new release is relatively bug-free.  I had a taste of this
problem when trying to make ck-ledger runable with both
Postgres and Mysql.  I had to cut back on a lot of Postgres (7.x.x)
sql features that were not supported by Mysql (3.23.x).  A better
approach is perhaps to go back to the previous situation of
releasing the core modules under a "phpgroupware-proper" project.
The other modules will be developed as plug-ins or sub-projects
subject to separate release streams with specification indicating
which "phpgroupware-proper" version being the prerequisite.

For the moment, I'll try to keep any new release of ck-ledger,
phpgroupware-0.9.12 compatible, pending the formal release
of phpgroupware-0.9.14.  If I got a bit of time, I'll try to
setup a debian machine and check out the debian situtation.

Best Regards,
CK


geoff wrote:

> Hi CK, Had some time to fiddle with ck-ledger over the lastday or
> so: Mysql version only works with Mysql-3.23 +mainly Create table
> Select statement in reportsis the problem(Debian is still only with
> Mysql-3.22) I believe that phpgroupware 14RC3 is unstable the
> sessionskept kicking me off either that ,or again  Debian being back
> on PHP4-0.3pl1is the problem. I have gone back to
> phpgroupware-0.9.12 Debian latest Postgres distro is still back at
> 6.5.3 which againmay cause problems In essence the average debian user
> is going to have some angstwith the ck package.    Regards Geoff

[CK-Ledger-users] Re: Mysql

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

Hello, Geoff,

Earlier on, Jim had the same problem with the "phpgw_inv_statuslist"
error.
I have pasted below the reply that I made to Jim.  I am still checking
out
your earlier backup/restore problem.

Best Regards,
CK


C K Wu wrote:

> Hello, Jim,
>
> Thanks for trying out ck-ledger.
>
> I probably should have modified the installation manual when I
> made ck-ledger runnable with MySQL.  The manual was
> wriiten with Postgresql in mind.
>
> The error message "Database error:  Invalid SQL: select * from
> phpgw_inv_statuslist"
>
> was most likely caused by a problem in earlier releases of
> phpgroupware of not having created the db table
> "phpgw_inv_statuslist",
> during  phpgroupware's setup process.  This has been rectified in
> the latest, phpgroupware-0.9.14.RC3, release.
>
> To fix the problem, try the following,
>
> 1.    Make sure that you have a working phpgroupware installation
>         with the DB Type set to mysql.  (I presume you had already
>         accomplished this, as you had login to phpgroupware)
>
> 2.    # mysql phpgroupware    (assuming that the DB name used is
> phpgroupware)
>         mysql> describe phpgw_inv_statuslist ;
>
> 3.    If the phpgw_inv_statuslist is indeed missing, then create it
> via,
>         mysql> source
> /var/www/html/phpgroupware/inv/doc/create_tables.mysql
>         (the "...../create_tables.pgsql" file is for use with
> postgresql).
>         Then, retry adminsetup from the ck-ledadmin icon .
>
> 4.    However, as you were not able to locate
>         /var/www/html/phpgroupware/inv/doc/create_tables.pgsql, it
> could mean
>         that the "..../inv/doc/" folder was somehow corrupted.  In
> this case, you
>         may like to download phpgroupware-0.9.14.RC3 from
> www.phpgroupware.org
>         and re-do the entire phpgroupware/ck-ledger installation
> process.  With this
>         release, there should not be a problem of missing
> phpgw_inv_statuslits table.
>
> Please give me and the ck-ledger-users list a reply whether the steps
> above help.
>
> Best Regards,
> CK
>
>
>
> Jim Roden wrote:
>
>> Hi
>> I am trying to get ck-ledger to work and have the following
>> problem.
>> When installing the software the documentation suggests the
>> following
>> su -l -c "psql phpgroupware <
>> /var/www/html/phpgroupware/inv/doc/create_tables.pgsql"
>> I use MySQL but there id no information on how to create the
>> tables using MySQ;  also there is no
>> /inv/doc/create_tables.pgsql file.
>> when I login to phpgroupware after creating the application
>> files for ck-ledger I get the following error if I try to run
>> groupware/ck-ledadmin/adminsetup.php.
>> Database error: Invalid SQL: select * from
>> phpgw_inv_statuslist
>> Session halted.
>> Warning: 1 is not a valid MySQL-Link resource in
>> /usr/local/httpd/htdocs/phpgroupware/phpgwapi/inc/phpg
>> w_db_mysql.inc.php on line 92
>>
>> --
>> Best regards
>> Jim Roden
>> Logicomm 2000
>> Tel: +44 1543 273 690
>> Fax: +44 1543 273 691
>> http://www.logicomm.co.uk
>>
>> The information contained in this e-mail is intended for
>> the named recipients only, it may also be privileged and
>> confidential. If you are  not the intended recipient you must
>> not copy, distribute or take any action or reliance upon it.
>> No warranties or assurances are made or given as  to the
>> accuracy or currency of the information given or in relation
>> to the safety of this e-mail and any attachments.
>> No liability whatsoever is accepted for any consequences
>> arising from it.
>> * * * Viruses * * *
>> Although we have checked this e-mail and attachments with
>> the  Norton AntiVirus software for all presently known
>> viruses,
>> we advise that in keeping  with good  computing practice the
>> recipient should ensure they are actually virus free.
>> Thought for the Day:
>> God is not dead, he just moved to a better neighborhood.
>>
>> _______________________________________________
>> CK-Ledger-users mailing list
>> CK-...@li...
>> https://lists.sourceforge.net/lists/listinfo/ck-ledger-users
>
admin wrote:

> Hi Ck, Not going to make a habit of this but an installof the latest
> groupware and ck-ledger using mysqlbrings up the following error on
> the groupware pagewhen you try and initiate a ck module Database
> error: Invalid SQL: select * from phpgw_inv_statuslist Have tried it a
> few times same result Regards geoff Note have done some code to
> download /uploadbackup files to a remote host - think this is
> preferableto backing up on the same server will forward code-its not
> brain surgery but it works

Re: [CK-Ledger-users] CK-Ledger and MySQL

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

Hello, Jim,

Thanks for trying out ck-ledger.

I probably should have modified the installation manual when I
made ck-ledger runnable with MySQL.  The manual was
wriiten with Postgresql in mind.

The error message "Database error:  Invalid SQL: select * from
phpgw_inv_statuslist"

was most likely caused by a problem in earlier releases of
phpgroupware of not having created the db table "phpgw_inv_statuslist",
during  phpgroupware's setup process.  This has been rectified in
the latest, phpgroupware-0.9.14.RC3, release.

To fix the problem, try the following,

1.    Make sure that you have a working phpgroupware installation
        with the DB Type set to mysql.  (I presume you had already
        accomplished this, as you had login to phpgroupware)

2.    # mysql phpgroupware    (assuming that the DB name used is
phpgroupware)
        mysql> describe phpgw_inv_statuslist ;

3.    If the phpgw_inv_statuslist is indeed missing, then create it via,

        mysql> source
/var/www/html/phpgroupware/inv/doc/create_tables.mysql
        (the "...../create_tables.pgsql" file is for use with
postgresql).
        Then, retry adminsetup from the ck-ledadmin icon .

4.    However, as you were not able to locate
        /var/www/html/phpgroupware/inv/doc/create_tables.pgsql, it could
mean
        that the "..../inv/doc/" folder was somehow corrupted.  In this
case, you
        may like to download phpgroupware-0.9.14.RC3 from
www.phpgroupware.org
        and re-do the entire phpgroupware/ck-ledger installation
process.  With this
        release, there should not be a problem of missing
phpgw_inv_statuslits table.

Please give me and the ck-ledger-users list a reply whether the steps
above help.

Best Regards,
CK



Jim Roden wrote:

> Hi
> I am trying to get ck-ledger to work and have the following
> problem.
> When installing the software the documentation suggests the
> following
> su -l -c "psql phpgroupware <
> /var/www/html/phpgroupware/inv/doc/create_tables.pgsql"
> I use MySQL but there id no information on how to create the
> tables using MySQ;  also there is no
> /inv/doc/create_tables.pgsql file.
> when I login to phpgroupware after creating the application
> files for ck-ledger I get the following error if I try to run
> groupware/ck-ledadmin/adminsetup.php.
> Database error: Invalid SQL: select * from
> phpgw_inv_statuslist
> Session halted.
> Warning: 1 is not a valid MySQL-Link resource in
> /usr/local/httpd/htdocs/phpgroupware/phpgwapi/inc/phpg
> w_db_mysql.inc.php on line 92
>
> --
> Best regards
> Jim Roden
> Logicomm 2000
> Tel: +44 1543 273 690
> Fax: +44 1543 273 691
> http://www.logicomm.co.uk
>
> The information contained in this e-mail is intended for
> the named recipients only, it may also be privileged and
> confidential. If you are  not the intended recipient you must
> not copy, distribute or take any action or reliance upon it.
> No warranties or assurances are made or given as  to the
> accuracy or currency of the information given or in relation
> to the safety of this e-mail and any attachments.
> No liability whatsoever is accepted for any consequences
> arising from it.
> * * * Viruses * * *
> Although we have checked this e-mail and attachments with
> the  Norton AntiVirus software for all presently known
> viruses,
> we advise that in keeping  with good  computing practice the
> recipient should ensure they are actually virus free.
> Thought for the Day:
> God is not dead, he just moved to a better neighborhood.
>
> _______________________________________________
> CK-Ledger-users mailing list
> CK-...@li...
> https://lists.sourceforge.net/lists/listinfo/ck-ledger-users

[CK-Ledger-users] CK-Ledger and MySQL

[Jim R. <sa...@lo...>]

Hi 
I am trying to get ck-ledger to work and have the following 
problem.
When installing the software the documentation suggests the 
following 
su -l -c "psql phpgroupware < 
/var/www/html/phpgroupware/inv/doc/create_tables.pgsql"
I use MySQL but there id no information on how to create the 
tables using MySQ;  also there is no 
/inv/doc/create_tables.pgsql file.
when I login to phpgroupware after creating the application 
files for ck-ledger I get the following error if I try to run 
groupware/ck-ledadmin/adminsetup.php.
Database error: Invalid SQL: select * from 
phpgw_inv_statuslist
Session halted. 
Warning: 1 is not a valid MySQL-Link resource in 
/usr/local/httpd/htdocs/phpgroupware/phpgwapi/inc/phpg
w_db_mysql.inc.php on line 92



--  
Best regards
Jim Roden
Logicomm 2000
Tel: +44 1543 273 690
Fax: +44 1543 273 691
http://www.logicomm.co.uk

The information contained in this e-mail is intended for
the named recipients only, it may also be privileged and 
confidential. If you are  not the intended recipient you must 
not copy, distribute or take any action or reliance upon it. 
No warranties or assurances are made or given as  to the 
accuracy or currency of the information given or in relation
to the safety of this e-mail and any attachments. 
No liability whatsoever is accepted for any consequences
arising from it.
* * * Viruses * * *
Although we have checked this e-mail and attachments with
the  Norton AntiVirus software for all presently known 
viruses,
we advise that in keeping  with good  computing practice the
recipient should ensure they are actually virus free.
Thought for the Day:
God is not dead, he just moved to a better neighborhood.