ck-ledger-users Mailing List for CK-Ledger

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi, folks,

Please be informed that this mailing list will be turned off starting 
Nov 1, 2004.
Please report bugs and suggestions to CK-...@go... .

Cheers,
CK

Hi, folks,

Just a reminder that this mailing list will be switched off starting Nov 
1, 2004.

Cheers,
CK

Hello, folks,

Apparently, some of the links embedded in the invitation email are not 
working properly.
An alternative way is to go directly to, 
http://groups-beta.google.com/group/CK-ERP-en
and click on the "Join this group" link .   At the same time, it seems 
that you may need
to register as a google group user before you are eligible to join the 
group.

Cheers,
CK

Hi, folks,

With the transformation of CK-Ledger to CK-ERP and the rush to release 
v.0.9.1, I must apologize for letting the general picture of CK-ERP to 
blur out a bit.  I hope what follows will clear the picture,

a)   CK-ERP.org is now operational and being hosted by a website agent 
here in Hong Kong.  However, the site is dedicated to serving the 
community in the Greater China region.  Much of the material is in 
Chinese.  CK-ERP.sourceforge.net will remain to be the focal point for 
English materials.

b)   Because of some mysterious reasons, I was not receiving 
notification on new postings from sourceforge.net.  I have decided to 
move all discussions to CK-...@go....  This group is "only 
members can post, anyone may join, anyone can read".  All existing 
members of ck-...@li... will receive invitation 
to join the group shortly.   After everything stabilises, I'll close off 
the ck-ledger-users mailing list along with CK-ERP's open forums.  This 
is expected to occur around the end of Oct 2004.  Hope this arrangement 
is better for everyone concerned.

c)   I am also trying to re-establish the descriptive website for CK-ERP 
that runs above SiteMgr.  However, a better design is necessary since 
each major upgrade of the underlying phpgroupware seems to require a 
rebuilt of the site, which is quite a chore in itself.

d)   In terms of developement, the immediate plan is still to convert 
the vendor and employee records to utilize the new contact 
infrastructure.  In the medium term, there is a long list of 
enhancements to work on.  Only if I got the time to complete them all.  :(

e)   CK-ERP is getting fairly big and complex, more detail division of 
labour and scheme of collaration is required.  Any suggestion in this 
regard is most welcome.  Btw, feedback on your experience with CK-ERP is 
most than welcome.

Please send your comment and suggestions to CK-...@go....

Cheers,
CK

Hi, Prashant,

Thank you for your interest in CK-ERP.

 From the error message that you posted, it's likely that you are using 
a M$ Windows machine.  If so, you are most certainly going to encounter 
problems one way or another.  CK-ERP had been and will continue to be 
developed mainly for use within a LAMP/LAPP (Linux + Apache + 
Mysql/Postgresql + PHP) environment.  My best advice is for you to setup 
a Linux machine using one of the more popular (free-of-charge) Linux 
distributions and resume your installation there.  You should find the 
going much smoother.

Cheers,
CK

Prashant Bhele wrote:

>hi,
>
> my self prashant from india, I use your software
>ck-erp. I follow your instruction for setup. But i got
>some error at the time of configuring your software
>through phpgroupware(first 2 step working properly).
>which is I send to you.
> please send me reply as early as possible
>
>prashant
>
>=======================================================
>
>Warning: opendir(h:/apache/php/php.exe): failed to
>open dir: Invalid argument in
>h:\apache\htdocs\phpgroupware\ck-admin\adminmd5.php on
>line 26
>
>Warning: readdir(): supplied argument is not a valid
>Directory resource in
>h:\apache\htdocs\phpgroupware\ck-admin\adminmd5.php on
>line 27
>
>
>0 MD5 Checksum Created 
>
>=======================================================
>
>  
>

hi,

 my self prashant from india, I use your software
ck-erp. I follow your instruction for setup. But i got
some error at the time of configuring your software
through phpgroupware(first 2 step working properly).
which is I send to you.
 please send me reply as early as possible

prashant

=======================================================

Warning: opendir(h:/apache/php/php.exe): failed to
open dir: Invalid argument in
h:\apache\htdocs\phpgroupware\ck-admin\adminmd5.php on
line 26

Warning: readdir(): supplied argument is not a valid
Directory resource in
h:\apache\htdocs\phpgroupware\ck-admin\adminmd5.php on
line 27

0 MD5 Checksum Created 

=======================================================

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Hi all,

Quick bit of DotGNU SPAM.

GetDotGNU.com is a new web portal dedicated to DotGNU (see
http://www.dotgnu.org/) and its projects: phpGroupWare, Portable.NET
(see http://www.dotgnu.org/pnet.html) & DGEE
(http://www.dotgnu.org/dgee.html). The site features news articles and
editorials, forums, downloads, screenshots, and many other great
features. 

All phpGroupWare users and contributors are encouraged to check out the
site.

Cheers

Dave Hall (aka skwashd)
API Coordinator
phpGroupWare

PS Sorry if you get hit in the Xpost flood.

Hello, folks,

I have posted a new release, v.0.9.1, of CK-ERP, at SourceForge.Net.

This release provides a new CRM module, which features,

. customer contract
. customer service centre
. helpdesk functionalities
. sale call tracking utilities

CK-ERP (with 17 modules, Admin, Contact Management, Customer 
Relationship, Ledger, Bank Reconciliation, Inventory, Service, AP, AR, 
PO, SO, Quotation, POS for Cashier, POS for Manager, HR, Staff Self 
Service, Payroll) is an open source accounting/ERP/CRM system that runs 
on top of phpGroupWare. Operating platform can either be LAMP or LAPP. 
It provides accounting and back office functionalities to SMEs and 
utilizes phpgw to administer accounts/groups. Please report error and 
suggestion to the mailing list, ck-...@li... 
<mailto:ck-...@li...> . General history and 
expected development is available at the mailing list's Archive.

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

SGksDQoNCkkgdGhpbmsgSSBoYXZlIHJlc29sdmVkIHRoZSBhYm92ZSBwcm9ibGVtIGJ5DQpt
eXNlbGYuIFBsZWFzZSBpZ25vcmUgbXkgbWVzc2FnZS4gDQoNCkJ1dCBqdXN0IG9uZSB0aGlu
ZywgSSB0aGluayB0aGUgaW5zdGFsbCBtYW51YWwgaXMNCm5vdCBxdWl0ZSByaWdodCBvciBt
eSBzeXN0ZW0gaXMgd2VpcmQuDQoNCkJlY2F1c2UgZm9yIHBvaW50IDI0IC0gUGljayBBZG1p
bi9TZXR1cCAtIEkNCmNhbm5vdCBzZWUgYW55IG9uIHRoZSBjay1hZG1pbiBzY3JlZW4gYW5k
IEkNCmNhbm5vdCBzZWUgYW55IFdlbGNvbWUgdG8gQWRtaW5pc3RyYXRpb24gcGFnZSBidXQN
CkkgY2FuIHNlZSB0aGUgZXJyb3IgZGVzY3JpYmVkIG9uIHBvaW50IDIxLg0KDQpCeSBjaGFu
Y2UgSSBjaGFuZ2VkIHRoZSBVUkwgdG8NCmNrLWFkbWluL2FkbWluZmlsdGVyIHRoZW4gaXQg
c2hvd3MgdGhlIGluc3RhbGwNCnNjcmVlbiwgdGhlbiBJIGNhbiBmb2xsb3cgdGhyb3VnaC4N
Cg0KQW55d2F5LCB0aGFuayBhIGxvdC4gSSB0aGluayB0aGlzIGlzIGEgZnVuY3Rpb24NCnJp
Y2ggc29mdHdhcmUuIA0KDQpDaGVlcnMsDQoNCi0gVGFrDQoNCg0KDQorKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrDQpIaSBhbGwsDQoNCkkgYW0gYSBuZXdiaWUgdG8gTGludXgg
YW5kIENLLUVSUC4gSSBoYXZlDQppbnN0YWxsZWQgcGhwZ3JvdXB3YXJlICBsYXRlc3QgdmVy
c2lvbiBsYXN0IG5pZ2h0DQphbmQgbG9va3MgT0sgdG8gbWUuIEkgY2FuIGFkZCBhZGRyZXNz
IGV0Yy4NCg0KVGhlbiBJIGluc3RhbGwgQ0stRVJQIGFjY29yZGluZyB0byB0aGUgbWFudWFs
IEkNCmhhdmUgZG93biBsb2FkZWQgYXMgYmVsb3cgYW5kIHdhcyBmaW5lIHVwIHRvIHN0ZXAN
CjIzIGFuZCAyNC4NCg0KSSBjYW4ndCBmaW5kIHRoZSCTV2VsY29tZSB0byBBZG1pbmlzdHJh
dGlvbpQgcGFnZQ0KYW5kIHRoZXJlZm9yZSBjYW5ub3QgqFBpY2sgQWRtaW4vU2V0dXAgY2hv
aWNlIGF0DQp0aGUgdG9wIGxlZnQgaGFuZCBjb3JuZXIuqA0KDQpJIGhhdmUgdHJpZWQgYWxs
IDE2IGljb25zIGJ1dCBjYW5ub3QgZmluZA0KYW55dGhpbmcgYXMgZGVzY3JpYmVkLg0KU2ln
bmVkIG9uIGFzIGRlbW8uDQoNCkNhbiBhbnlvbmUgYXNzaXN0ID8/IG1hbnkgdGhhbmtzDQoN
CmNvcHkgb2YgcGFydCBpbnN0cnVjdGlvbnM6Og0KPT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PQ0KMjEuQ2hvb3NlIHRoZSAoQ0stRVJQJ3MpIEFkbWluaXN0cmF0aW9u
IG1vZHVsZQ0KKGNhc3RsZSBpY29uIHdpdGggk2FiYWN1c5QgYmFja2dyb3VuZCkuDQogICAg
IFtUaGUgZm9sbG93aW5nIGVycm9yIG1lc3NhZ2UgKG9yIHNvbWV0aGluZw0Kc2ltaWxhcikg
d2lsbCBzaG93IHVwLA0KICAgICAgICAgICAgICAgRGF0YWJhc2UgZXJyb3I6IEludmFsaWQg
U1FMOg0KU0VMRUNUIGNoZWNrc3VtIEZST00gY2tfbWQ1IFdIRVJFDQpzY3JpcHQ9Jy9jay1h
ZG1pbi9pbmRleC5waHAnDQogICAgICAgICAgICAgICBNeVNRTCBFcnJvcjogMTE0NiAoVGFi
bGUNCidja2VycC5ja19tZDUnIGRvZXNuJ3QgZXhpc3QpDQogICAgICAgICAgICAgICBTZXNz
aW9uIGhhbHRlZC4NCiAgICAgQnV0IGRvbid0IHdvcnJ5LCB0aGlzIGlzIGR1ZSB0byB0aGUg
YWJzZW5jZQ0Kb2YgdGhlIGNoZWNrc3VtIHRhYmxlIHdoaWNoIHdpbGwgYmUgY3JlYXRlZCBp
biBhDQpsYXRlciBzdGVwXQ0KMjIuWW91IG1heSBoYXZlIHRvIGNsaWNrIGFsbCAxNiBpY29u
cyB0byBmaW5kIG91dA0Kd2hpY2ggaWNvbiByZWxhdGVzIHRvIHdoaWNoIG1vZHVsZS4NCjIz
LlJlYWQgaW4gZGV0YWlsIHRoZSCTV2VsY29tZSB0byBBZG1pbmlzdHJhdGlvbpQNCnBhZ2Uu
DQoyNC5QaWNrIEFkbWluL1NldHVwIGNob2ljZSBhdCB0aGUgdG9wIGxlZnQgaGFuZA0KY29y
bmVyLg0KMjUuQ2hvb3NlIGFjdGlvbiA0IJYgRGVsZXRlIGFsbCBEYXRhIGFuZCBEYXRhIFRh
Ymxlcy4NCjI2LlByZXNzIJNTdGFydCBBY3Rpb26UIGJ1dHRvbi4gDQo9PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNClJlZ2FyZHMsDQoNClRhayANCg==

SGkgYWxsLA0KDQpJIGFtIGEgbmV3YmllIHRvIExpbnV4IGFuZCBDSy1FUlAuIEkgaGF2ZQ0K
aW5zdGFsbGVkIHBocGdyb3Vwd2FyZSAgbGF0ZXN0IHZlcnNpb24gbGFzdCBuaWdodA0KYW5k
IGxvb2tzIE9LIHRvIG1lLiBJIGNhbiBhZGQgYWRkcmVzcyBldGMuDQoNClRoZW4gSSBpbnN0
YWxsIENLLUVSUCBhY2NvcmRpbmcgdG8gdGhlIG1hbnVhbCBJDQpoYXZlIGRvd24gbG9hZGVk
IGFzIGJlbG93IGFuZCB3YXMgZmluZSB1cCB0byBzdGVwDQoyMyBhbmQgMjQuDQoNCkkgY2Fu
J3QgZmluZCB0aGUgk1dlbGNvbWUgdG8gQWRtaW5pc3RyYXRpb26UIHBhZ2UNCmFuZCB0aGVy
ZWZvcmUgY2Fubm90IKhQaWNrIEFkbWluL1NldHVwIGNob2ljZSBhdA0KdGhlIHRvcCBsZWZ0
IGhhbmQgY29ybmVyLqgNCg0KSSBoYXZlIHRyaWVkIGFsbCAxNiBpY29ucyBidXQgY2Fubm90
IGZpbmQNCmFueXRoaW5nIGFzIGRlc2NyaWJlZC4NClNpZ25lZCBvbiBhcyBkZW1vLg0KDQpD
YW4gYW55b25lIGFzc2lzdCA/PyBtYW55IHRoYW5rcw0KDQpjb3B5IG9mIHBhcnQgaW5zdHJ1
Y3Rpb25zOjoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCjIxLkNo
b29zZSB0aGUgKENLLUVSUCdzKSBBZG1pbmlzdHJhdGlvbiBtb2R1bGUNCihjYXN0bGUgaWNv
biB3aXRoIJNhYmFjdXOUIGJhY2tncm91bmQpLg0KICAgICBbVGhlIGZvbGxvd2luZyBlcnJv
ciBtZXNzYWdlIChvciBzb21ldGhpbmcNCnNpbWlsYXIpIHdpbGwgc2hvdyB1cCwNCiAgICAg
ICAgICAgICAgIERhdGFiYXNlIGVycm9yOiBJbnZhbGlkIFNRTDoNClNFTEVDVCBjaGVja3N1
bSBGUk9NIGNrX21kNSBXSEVSRQ0Kc2NyaXB0PScvY2stYWRtaW4vaW5kZXgucGhwJw0KICAg
ICAgICAgICAgICAgTXlTUUwgRXJyb3I6IDExNDYgKFRhYmxlDQonY2tlcnAuY2tfbWQ1JyBk
b2Vzbid0IGV4aXN0KQ0KICAgICAgICAgICAgICAgU2Vzc2lvbiBoYWx0ZWQuDQogICAgIEJ1
dCBkb24ndCB3b3JyeSwgdGhpcyBpcyBkdWUgdG8gdGhlIGFic2VuY2UNCm9mIHRoZSBjaGVj
a3N1bSB0YWJsZSB3aGljaCB3aWxsIGJlIGNyZWF0ZWQgaW4gYQ0KbGF0ZXIgc3RlcF0NCjIy
LllvdSBtYXkgaGF2ZSB0byBjbGljayBhbGwgMTYgaWNvbnMgdG8gZmluZCBvdXQNCndoaWNo
IGljb24gcmVsYXRlcyB0byB3aGljaCBtb2R1bGUuDQoyMy5SZWFkIGluIGRldGFpbCB0aGUg
k1dlbGNvbWUgdG8gQWRtaW5pc3RyYXRpb26UDQpwYWdlLg0KMjQuUGljayBBZG1pbi9TZXR1
cCBjaG9pY2UgYXQgdGhlIHRvcCBsZWZ0IGhhbmQNCmNvcm5lci4NCjI1LkNob29zZSBhY3Rp
b24gNCCWIERlbGV0ZSBhbGwgRGF0YSBhbmQgRGF0YSBUYWJsZXMuDQoyNi5QcmVzcyCTU3Rh
cnQgQWN0aW9ulCBidXR0b24uIA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PQ0KDQpSZWdhcmRzLA0KDQpUYWsNCg==

Hi all,

A XSS exploit was found in the phpgroupware wiki module.  0.9.16.003
fixes the problem.  

There are some other general bug fixes and documentation updates in the
release.  PHP5 users should be happier too :)

All users are encouraged to upgrade asap.

Latest version are available at http://download.phpgroupware.org/now or
update from CVS - see http://download.phpgroupware.org/cvs

Cheers

Dave Hall (aka skwashd)
on behalf of the The phpGroupWare Crew

PS The release would have been out earlier if it wasn't for several
problems with sf.net ... grrrr

Hello, folks,

I am sorry I did not mention this earlier.

If you are contemplating actuall use of CK-ERP in your environment,
please hold off for a while.  Currently, I am modifying the customer,
vendor and employee table layout to make use of the new ck-contact
infrastructure.  If you set up your CK-ERP data tables now, you would
face significant data migration problem with newer releases of CK-ERP.

Hope I haven't cause too many problems.

Cheers,
CK

Hi, folks,

I am contemplating adding input validation against "...<..>..." within 
CK-ERP environment to minimize the risk of crosss site scripting.

However, I am mindful of the following situation,

page request
-> phpgwapi (requiring <..>)
-> ck-erp modules (rejecting request because of embedded <..>)
-> [in case of normal exit] phpgwapi (requiring <..>)

Would this happen in real operation ?  If so, is it a rare occasion, 
that I can handle as special cases ?

Any suggestions or comments welcomed.

Cheers,
CK

Hello, folks,

I have just rebuilt http://ck-ledger.sourceforge.net
to house CK-ERP's demo site temporarily.  Once
I got a separate MySQL database to hold the
CK-ERP demo data, the site will be relocated.
However, since SF.net is running php 4.1.2, which
does not support md5_file(), the demo, at the moment,
is a customised version that suppresses MD5 script checksum
verification.  It also means that if you are interested
in test driving CK-ERP, at your own machine, your php
version needs to be 4.2 or above.

Cheers,
CK

Thanks, mate.  :)
CK

Dave Hall wrote:

>Hi CK,
>
>I have moved this to the dev list.  Our users don't really need to know
>all the technical details of how it all works :)
>
>I know this thread has died a little, but I have been busy.
>
>On Sat, 2004-07-31 at 16:14, C K Wu wrote:
>  
>
>>Brian Johnson wrote:
>>
>>    
>>

Hi CK,

I have moved this to the dev list.  Our users don't really need to know
all the technical details of how it all works :)

I know this thread has died a little, but I have been busy.

On Sat, 2004-07-31 at 16:14, C K Wu wrote:
> Brian Johnson wrote:
> 
> >C K Wu (ck...@ch...) wrote:
> >  
> >
> >>Hi, Brian,
> >>
> >>    
> >>
> >>>You know I like ck-ledger, but the inability to still not use the phpgw
> >>>addressbook table directly causes me concern.  I know that any parallel
> >>>contact storage system that relies on a sync mechanism is bound to encounter
> >>>occasional problems.
> >>>
> >>>Perhaps it is due to my misunderstanding of how the "systemwide unique id"
> >>>works
> >>>
> >>>
> >>Systemwide unique id means unique across all transactions.  Say, a newly
> >>inserted customer
> >>record gets id 123, the next inserted invoice gets id 124, the next
> >>timesheet gets id 125,
> >>so on and so forth.  As far as I can tell, addressbook only maintains id
> >>uniqueness within
> >>individual type of transaction, ie no organisation record could have
> >>duplicate id, but a person
> >>record can have the same id as an organization record.
> >>    
> >>
> >
> >Persons and organizations do not overlap id numbers in the current
> >addressbook.  They are both listed in the central table phpgw_contact and
> >contact_id is a primary field with an index whick prevents a person from
> >sharing the same id as anorganization.
> >
> >However, that is still only uniquieness within that app, not across multiple
> >apps .. so still may not provide what you want.
> >  
> >
> You are absolutely right.

It would be possible to include a linking table within CK-ERP.  This
would provide the unique id within CK-ERP.  I have not looked at the db
design for CK-ERP, so maybe I am missing something.  I would have had a
look at CVS, but CVS is not available for either ck-ledger or ck-erp on
sf.net and ck-[erp|ledger].sf.net are both down.

> 
> >How do you do it?  Search multiple tables to ensure an id is not reused?  Or
> >maintain a record somewhere that contains the next id to be used (wouldn't
> >this system create a performance bottleneck?)?
> >
> >
> With Postgresql, all id is assigned from a single sequence.
> With MySQL, all id is assigned from one single auto-increment column.
> 
> The design is simple and efficient.  However, it requires all 
> id-assigning scripts to abide by the rule.
> Any single script that does not conform to the rule will screw up the 
> design.  That's why I think
> it is very difficult to implement within phpgw.

Yes this is true, but any system, regardless of what the business rules
are, will fail if those rules are not observed.  

The auto increment feature is optional.  Where it is used, then the
database should do the job, not the script calling it.  Inserting a
value into an auto increment field is wrong.  If you find them, let you
know and we will fix it.

3rd Normal Form design principles recommend that all primary keys should
be integers, to increase performance and such PKs must be unique.  The
auto increment feature ensures such ids are unique, but there is no
requirements to use the feature.  If you don't use auto increments, then
it is up to the application logic to maintain such unique ids, which has
some overhead and can cause problems.

I agree with Brain and others that CK-ERP really should use the API
where the feature is already implemented.  This should reduce the amount
of work in maintaining CK-ERP.  As I have offered and done in the past,
I am willing to assist CK (and others) in getting CK-ERP working with as
much of the API that is practical.  I won't be writing code for CK's
project but will be willing to provide advice.  The amount of time I can
spend on this will vary, depending on my workload.  A public cvs would
make this a lot easier :)

Cheers

Dave

-- 
Dave Hall (aka skwashd)
API Coordinator
phpGroupWare

Brian Johnson wrote:

>C K Wu (ck...@ch...) wrote:
>  
>
>>Hi, Brian,
>>
>>    
>>
>>>You know I like ck-ledger, but the inability to still not use the phpgw
>>>addressbook table directly causes me concern.  I know that any parallel
>>>contact storage system that relies on a sync mechanism is bound to encounter
>>>occasional problems.
>>>
>>>Perhaps it is due to my misunderstanding of how the "systemwide unique id"
>>>works
>>>
>>>
>>>
>>>      
>>>
>>Systemwide unique id means unique across all transactions.  Say, a newly
>>inserted customer
>>record gets id 123, the next inserted invoice gets id 124, the next
>>timesheet gets id 125,
>>so on and so forth.  As far as I can tell, addressbook only maintains id
>>uniqueness within
>>individual type of transaction, ie no organisation record could have
>>duplicate id, but a person
>>record can have the same id as an organization record.
>>    
>>
>
>Persons and organizations do not overlap id numbers in the current
>addressbook.  They are both listed in the central table phpgw_contact and
>contact_id is a primary field with an index whick prevents a person from
>sharing the same id as anorganization.
>
>However, that is still only uniquieness within that app, not across multiple
>apps .. so still may not provide what you want.
>  
>
You are absolutely right.

>How do you do it?  Search multiple tables to ensure an id is not reused?  Or
>maintain a record somewhere that contains the next id to be used (wouldn't
>this system create a performance bottleneck?)?
>
>  
>
With Postgresql, all id is assigned from a single sequence.
With MySQL, all id is assigned from one single auto-increment column.

The design is simple and efficient.  However, it requires all 
id-assigning scripts to abide by the rule.
Any single script that does not conform to the rule will screw up the 
design.  That's why I think
it is very difficult to implement within phpgw.

Cheers,
CK

>  
>
>>>I know that the existing addressbook has a hook to allow other apps to prevent
>>>deletion of addressbook contacts and I know that the addressbook system does
>>>use a unique id for each of it's entries .. so I don't nderstand the problem
>>>
>>>Could you explain it more please?
>>>
>>>Secondly, the version that I am currently running does not have "phpgw_"
>>>preceding the table names, does the current version?
>>>
>>>
>>>
>>>
>>>      
>>>
>>One of the enhancement with CK-ERP is to use standardised table prefix.
>>The default
>>prefix is "ck_".   But the system implementer could change it to
>>whatever he/she prefers.
>>But since it is a system crashing modification if made post
>>implementation, the prefix
>>is embedded in the script, ckapi.inc.php, and script modification is
>>required to effect the change.
>>
>>Cheers,
>>CK
>>
>>    
>>
>>>_______________________________________________
>>>Phpgroupware-users mailing list
>>>Php...@gn...
>>>http://lists.gnu.org/mailman/listinfo/phpgroupware-users
>>>
>>>
>>>
>>>
>>>      
>>>
>>
>>_______________________________________________
>>Phpgroupware-users mailing list
>>Php...@gn...
>>http://lists.gnu.org/mailman/listinfo/phpgroupware-users
>>
>>
>>    
>>
>
>
>
>_______________________________________________
>Phpgroupware-users mailing list
>Php...@gn...
>http://lists.gnu.org/mailman/listinfo/phpgroupware-users
>
>
>  
>

Hi, Brian,

>You know I like ck-ledger, but the inability to still not use the phpgw
>addressbook table directly causes me concern.  I know that any parallel
>contact storage system that relies on a sync mechanism is bound to encounter
>occasional problems.
>
>Perhaps it is due to my misunderstanding of how the "systemwide unique id"
>works
>
>  
>
Systemwide unique id means unique across all transactions.  Say, a newly 
inserted customer
record gets id 123, the next inserted invoice gets id 124, the next 
timesheet gets id 125,
so on and so forth.  As far as I can tell, addressbook only maintains id 
uniqueness within
individual type of transaction, ie no organisation record could have 
duplicate id, but a person
record can have the same id as an organization record.

>I know that the existing addressbook has a hook to allow other apps to prevent
>deletion of addressbook contacts and I know that the addressbook system does
>use a unique id for each of it's entries .. so I don't nderstand the problem
>
>Could you explain it more please?
>
>Secondly, the version that I am currently running does not have "phpgw_"
>preceding the table names, does the current version?
>
>
>  
>
One of the enhancement with CK-ERP is to use standardised table prefix.  
The default
prefix is "ck_".   But the system implementer could change it to 
whatever he/she prefers.
But since it is a system crashing modification if made post 
implementation, the prefix
is embedded in the script, ckapi.inc.php, and script modification is 
required to effect the change.

Cheers,
CK

>_______________________________________________
>Phpgroupware-users mailing list
>Php...@gn...
>http://lists.gnu.org/mailman/listinfo/phpgroupware-users
>
>
>  
>

Hi, Tony,

I must apologise for missing your emails earlier.  Apparently, my ISP=20
mail server's ip
was being blacklisted and I got a total blackout for messages coming=20
from sourceforge.net.
That causes me to miss your postings to the mailing list hosted at=20
sourceforge.net .

By now, you probably noticed that I have released the first version of=20
CK-ERP.

To check out the invoicing features of CK-ERP, you could visit the demo=20
site at,
http://ck-ledger.sourceforge.net , which runs CK-Ledger 0.7.1 at the mome=
nt.
I'll upload CK-ERP 0.8.1 within the next day or two.  If I can=20
successfully apply
for a separate MySQL database to host CK-ERP, the demo site will be moved
a litter later.

I would certainly advise against inserting invoice transaction into the=20
database directly
because invoices are fully linked to the other transactions, notably=20
accounting entries,
payments and receipts.  Perhaps, you could download the new CK-ERP softwa=
re
and test out the software first before deciding how to handle your=20
specific case.

My brain is stuffed now having rushed to meet the July release deadline=20
for CK-ERP.
I'll try to give your a more detail reply a little while later.

Cheers,
CK

Tony Charles wrote:

> =20
> Hello.
> =20
> I'm thinking of using CK-ERP for my new business, but I'm not sure how=20
> easily it will integrate into my (planned) invoicing process.
> =20
> I will charge my customers a very small fee each time they use my=20
> service. It doesn't make sense to invoice for each transaction, so=20
> I'll keep track of the transactions in my own MySQL table - and only=20
> invoice for the total amount after each 30 day period. (I'll also=20
> defer the invoicing process a few times, if the customer owes less=20
> than =A35).
> =20
> 1) Is is okay for my invoicing script (Perl) to directly add=20
> invoices into the relevant CK-ERP table? I haven't installed CK-Ledger=20
> yet, because I'm waiting for CK-ERP (due in a week or two, right?=20
> :)). Can I assume that it will be easy to set things up in this way?=20
> Will I break anything in CK-ERP, if I enter transactions directly into=20
> the MySQL tables without telling CK-ERP about it? Do others do this=20
> kind of thing?=20
> =20
> 2) And what happens to an invoice once it has been entered into=20
> CK-ERP? Is there a "Print Invoice" function, for example? Can CK-ERP=20
> automatically issue reminders, if the invoice goes unpaid? (I'm=20
> planning to extend the Perl script so it handles these functions, but=20
> if CK-ERP does similar things, then I should obviously wait!)=20
> =20
> 3) Does it make sense for me to post a single transaction against the=20
> CK tables - which summarises all the transactions by a customer over=20
> the last 30 days? Or... should I be entering each small transaction=20
> into the CK tables as it is done by the customer, and then enter the=20
> invoice as a special record?
> =20
> 4) How is an invoice even implemented in CK-ERP/Ledger? What module=20
> handles invoicing, if any?
> =20
> Thank you!!!
> =20
> Tony
> =20
> Ps. I assume CK-ERP will still run on MySQL???
> =20
> =20
> =20
> =20
> =20

Hello,  folks,

I have posted the first release, v.0.8.1, of CK-ERP,
at SourceForge.Net
(http://sourceforge.net/projects/ck-erp) .

This release focuses on three main areas:

a) The previous CK-Ledger is totally rewritten.
Specifically, a new module, ck-api, is developed to
encapsulate most of the common processing logics.
Hopefully, this will speed up future development of
new functions and features. It will also allow much
faster porting of CK-ERP across to the new gen
platform, if and when it is ready.

b) Security is tightened up. Transactions are now
concurrent edit/delete safe. Transaction filtering is
re-structured to minimize the risk of SQL injection.
Script MD5 checksum is verified before frontline
scripts are allowed to execute. Transaction deletion
is validated before being executed. Full transaction
post-insert, post-edit, pre-delete images are stored
in the log table and viewable only to users with
auditor's role. Obviously, this will increase the size
of the log table immensely. I have done a crude
benchmark. With a Duron 1800+, 1G ram, and 80G hard
disk, response time for a log table with 500,000
records is bearly tolerable. Any feedback on actual
performance is gratefully welcomed.

c) ck-contact. A new module models on phpgroupware's
addressbook. Facility is provided to import contact
records from phpgw's addressbook. This should minimize
duplicate data entry effort. However, semantically
there are some differences between data fields
embedded in the addressbook and ck-contact.
Nevertheless, if some functionalities could be
developed to syncronize addressbook vs ck-contact, it
would allow a combined phpgw + ck-erp to handle both
frontline business communication and backend record
processing within a unified computing environment. My
next attention will be devoted to converting customer,
vendor and employee record to make use of the
ck-contact features. I hope members of the phpgw team
would perhaps consider taking up the challenge of
implementing the synchronization. By the way, the
reason for not utilizing the addressbook data directly
is that one of the design goal of CK-ERP (and of
CK-Ledger) is that all transactions must have a
systemwide unique id, which I think is very difficult
to guarantee within the current addressbook.

Contribution from Jerre Cope in providing the sample
school band chart of account is greatly appreciated.

Unfortunately, because there are substantial
differences between CK-ERP and CK-Ledger's data
structure, direct upgrade of CK-Ledger data to run
within CK-ERP is not possible. Manual data
transportation is required.

CK-ERP (with 16 modules, Admin, Contact Mgmt, Ledger,
Bank Reconciliation, Inventory, Service, AP, AR, PO,
SO, Quotation, POS for Cashier, POS for Manager, HR,
Staff Self Service, Payroll) runs on top of
phpGroupWare. Operating platform can either be LAMP or
LAPP. It provides accounting and back office
functionalities to SMEs and utilizes phpgw to
administer accounts/groups. Please report error and
suggestion to the mailing list,
ck-...@li...
<mailto:ck-...@li...> .
General history and expected development is available
at the mailing list's Archive.

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

_________________________________________________________
必殺技、飲歌、小星星...
浪漫鈴聲  情心連繫
http://us.rd.yahoo.com/evt=22281/*http://ringtone.yahoo.com.hk/

Hi all,

All phpGroupWare versions earlier than 0.9.16.002 set header admin and
setup passwords as plain text cookies. This release fixes this security
problem.

The project considers the potential to exploit this flaw to be
relatively minor.

Latest version are available at http://download.phpgroupware.org/now

All users are encouraged to upgrade asap

Cheers

Dave Hall (aka skwashd)
on behalf of the The phpGroupWare Crew

2002	Jan	Feb (18)	Mar (3)	Apr (6)	May (19)	Jun (8)	Jul (10)	Aug (10)	Sep (17)	Oct (10)	Nov (8)	Dec (12)
2003	Jan (15)	Feb (9)	Mar (16)	Apr (7)	May (5)	Jun (1)	Jul (6)	Aug (8)	Sep (42)	Oct (8)	Nov (22)	Dec (3)
2004	Jan (14)	Feb (8)	Mar (8)	Apr (1)	May (2)	Jun	Jul (13)	Aug (4)	Sep (6)	Oct (5)	Nov	Dec
2006	Jan	Feb	Mar	Apr	May (4)	Jun	Jul	Aug	Sep	Oct	Nov	Dec

ck-ledger-users Mailing List for CK-Ledger

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