ck-ledger-users Mailing List for CK-Ledger (Page 10)
Status: Beta
Brought to you by:
ckwu
Menu
▾
▴
ck-ledger-users — Mailing list and discussion group for CK-Ledger Users
You can subscribe to this list here.
| 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
|
|
From: JobsExcite S. <su...@jo...> - 2002-10-30 22:40:55
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD> <BODY> <DIV align=center><FONT size=2><FONT face=Verdana><STRONG><FONT color=#0000ff><U><FONT size=6>Job Hunting</FONT><FONT size=7><EM>? </EM></FONT></U></FONT></STRONG></FONT></FONT></DIV><FONT size=2><FONT face=Verdana><STRONG><EM><U><FONT color=#0000ff size=7></FONT></U></EM></STRONG> <DIV dir=ltr style="MARGIN-RIGHT: 0px" align=left><BR>Come and Visit </FONT><A href="http://www.jobsexcite.com/"><FONT face=Verdana>JobsExcite.com </FONT></A><FONT face=Verdana>and post your resume for <STRONG>Free</STRONG>. <STRONG>JobsExcite </STRONG>is simply the best way to ensure that your resume is seen by hiring managers across the country looking for your specific skills. More than hundreds of Employers nation-wide posting new and real jobs on JobsExcite on Daily bases. </FONT></FONT></DIV> <DIV><FONT face=Verdana size=2></FONT> </DIV> <DIV> <P align=center><FONT face=Verdana color=#0000ff size=4><B>******** FREE Membership! ********</B></FONT></P> <UL> <LI><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>Post your resume for thousands of employers to access. </FONT> <LI><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>Search our Jobs database for employment opportunities that meet your skill set.</FONT> <LI><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>Receive up to date job openings that match your career profile criteria via email.</FONT> <LI><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>Receive Email on every job posted in our database which matches your technical skills via our instant application feature. </FONT> <LI><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>Automatically Apply online for multiple job openings at once via the "Job Cart". </FONT> </LI> <LI><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2> Online Technical Support, and communication via "Chat" or "Service request" by clicking on the support page. </FONT> </LI></UL></DIV> <DIV><FONT face=Verdana size=2>We have expanded the Job Seekers section to include Account Profile, Work Info, Education, Skills, and Resume tabs. Please complete all of the require fields in each of the tabs in order for the employers to view your resume.</FONT></DIV> <DIV align=center><STRONG><FONT face=Verdana color=#0000ff size=4> <A href="http://www.jobsexcite.com/"><IMG height=62 src="http://www.jobsexcite.com/jobsexcite.gif" width=152 border=0></A></FONT></STRONG></DIV></BODY></HTML> <BR><FONT face="Arial, Helvetica, sans-serif" size=2><I>If you have received this mailing in error, or do not wish to receive any further mailings pertaining to this topic please <a href="http://remove.jobsexcite.com/removeme.php?email=ck-ledger-users%40lists.sourceforge.net.">click here</a> and we will remove your email from our mailing list. We respect all removal requests.</I></FONT><br><br><center><img src="http://remove.jobsexcite.com/redline.php?email=ck-ledger-users%40lists.sourceforge.net.&docemailed=1003.htm"></center> |
|
From: C K Wu <ck...@ch...> - 2002-10-30 16:45:52
|
Hi, Folks, Marc had produced the English lang files for CK-Ledger v.0.2.3, and posted them at www.netspan.ch for downloading by anyone interested. If you like to try your hand in translating the embedded phrases to your native tongue (or other target languages), Marc had listed in the email below the general procedure involved. A big hand for Marc. At the same time, I would appreciate it very much, if after the translation, you would send me the resultant lang files, and I'll include them in the future releases of CK-Ledger. Cheers, CK Marc Lutolf wrote: > Hi CK, > > Attached I am sending you a zip file with a complete set of English lang > files for CK-Ledger ver. 0.2.3. The files are still a bit "raw" and have not > been extensively tested. However, I am releasing them because I think this > will help highlight whatever still needs tweaking in the source, and more > importantly they may help anyone interested in creating translations to get > started. Pending publication on sourceforgeI have also placed the zip file > in the downloads section of this site: www.netspan.ch, where it can be > downloaded. > > Installation: The zip contains 11 folders with lang files, one folder for > each CK-Ledger module. > > 1. Back up your data. > 2. Unzip the zip file in the top level phpGroupware directory, where the > CK-Ledger modules are. > > Creating Translations > > The lang files were created using the Developer Tools module in > phpGroupware. However, this module has some problems and is not too well > documented. I recommend creating translations MANUALLY, as follows (it's not > any slower than using Developer Tools): > > The English lang files have the structure > > [phrase key] <--TAB--> [module name] <--TAB--> en <--TAB--> [phrase] > > that is, each row has 4 entries separated by tabs. To create a translation > > 1. Copy the corresponding English file and rename it according to the > language you are translating to. For instance, a German lang file will be > named phpgw_de.lang > 2. Open the new file with your favorite text editor. > 3. Replace the third entry in each row (in the English file: "en") with the > 2 letter code for your language, e.g. "de", "fr", "sp" etc. > 4. Replace the fourth entry ([phrase]) with your translation. > > Careful not to remove any of the TABS!! > > Cheers, > > Marc > > ------------------------------------------------------------------------ > Name: en-lang.zip > en-lang.zip Type: WinZip File (application/x-compressed) > Encoding: base64 |
|
From: C K Wu <ck...@ch...> - 2002-10-29 12:27:44
|
Hi, Anibal and Marc, While I have promised Anibal to send him/her the English lang files, now that Marc generously offers to produce the English lang files, I am feeling a bit lazy :-) . So, to avoid duplication of work, I'll go back to program the hr and payroll modules. I would also appreciate it very much, if, after the language translation, you would send me the respective lang files so I could incorporate them into future releases of CK-Ledger. Marc had also highlighted the fact that "]" will cause problems with the Developer_Tools. I got a taste of the mess this morning, myself, trying to figure out a workaround. I came to the same conclusion that it was not worth the effort. So, I'll try to isolate the "["s and "]"s from lang() strings in future and to rework the old codes when they are being updated progresssively. Btw, I am not too good at distinguishing genders from Western names. Cheers, CK Marc Lutolf wrote: > Anibal, > > I am generating English lang files to be translated based on the latest > release. I'll be happy to send them to you as they're done, if you give me > an email address. > > Marc > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > CK-Ledger-users mailing list > CK-...@li... > https://lists.sourceforge.net/lists/listinfo/ck-ledger-users |
|
From: Marc L. <mf...@ne...> - 2002-10-29 09:24:23
|
Anibal, I am generating English lang files to be translated based on the latest release. I'll be happy to send them to you as they're done, if you give me an email address. Marc |
|
From: C K Wu <ck...@ch...> - 2002-10-28 06:40:21
|
Hello, folks, I have posted a new release, v.0.2.3, of CK-Ledger, at SourceForge.Net. New features include new tax calculation logic, service package, alternate service, assembly with service components, attribute replication at AP/AR journal screen, new icons, additional lang() calls, log record for update to defaults table and adminbuilt rewrite. Other enhancements and bug fixes are also included. Special thank is due to Marc Lutolf of Switzerland for proposing the new tax calculation logic. When installing CK-Ledger on top of phpgroupware-0.9.14 and RedHat8.0, there may be a problem with login being returned a blank page with cd=3D5 at the url. The workaround is to change line 159 within [phpgroupware folder]/login.php, from, if (getenv(REQUEST_METHOD) ....... to, if ($_SERVER[REQUEST_METHOD) ..... To allow better ordering of screen menu icons, comment out line 941 within [phpgroupware folder]/phpgwapi/inc/class.common.inc.php. The line reads, =93ksort($GLOBALS['phpgw_info']['user']['apps']);=94. This workaround is provided by Dave Hall of Australia at php...@gn.... Please note that Konqueror/KDE3/RedHat7.3 has problem accessing the various features of CK-Ledger, while Konqueror/KDE3/RedHat8.0 and other browsers have been tested to work fine under similar circumstances. Mandrake 8.2, with KDE upgraded to v.3.0.2 also functions properly. 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. Operating platform can either be LAMP or LAPP. It provides accounting functionalities to SMEs and utilizes phpgw to administer accounts/groups. Installation Manual and Features List are available at http://sourceforge.net/projects/ck-ledger. (Just click on the [Docs] label at the header menu line above the brief project description.) 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 |
|
From: C K Wu <ck...@ch...> - 2002-10-18 09:37:15
|
Hi, Anibal, Thank you for your interest in CK-Ledger. Certainly. No problem. However, please hold off your translation effort for a while. Since, Marc Lutolf of Switzerland mentioned his effort to produce German translation, I had realized a large number of the screen messages (notably, all error messages) had not been output utilizing the lang() call, so I am scrambling to put all the necessary lang() calls back in. They will be included in the next release, which should be available within the next fortnight. Btw, the next release, will include significant change to tax handling in the various screens. I'll send you the lang files after the next release. Cheers, CK Anibal Silva wrote: > Hi! > W=B4re from Portugal and we have installed the ck ledger in our phpgrou= pware server, > and we would like to produce the portuguese lang files! > Can u send us the english lang files, so we can translate them? > > Best regards, > Anibal > -- > _______________________________________________ > An=EDbal Jorge Neves da Silva > Cria=E7=F5es Digitais, Lda > Produtos e Servi=E7os Inform=E1ticos > Vilas do Solar, Lt 221-222 > Loja 5-6 > 2670-077 > St=BA Ant=F3nio dos Cavaleiros > > tel:219896144 > fax:219896148 |
|
From: C K Wu <ck...@ch...> - 2002-10-15 11:12:41
|
Hello, John,
Thank you for your interest in CK-Ledger.
At the moment, external interface is not a priority area for CK-Ledger.
However, given the different types of technology and
organizations (Commerce/One, Rosetta/Net and MS Web Service / Biztalk)
claiming to be aiming at standardization of the business process, I
would definitely wait a long while before tackling the problem of
external interface.
PS - I am sending a copy of this reply to
ck-...@li...
so the other list members are aware of current development and
discussion.
Cheers,
CK
John Gibson wrote:
> Have you guys considered the requirements of EDI in this
> project? We are working on a project at the moment that will
> allow large companies to talk to the accounting programmes
> of small companies. These accounting programmes are just
> not designed to allow the functionality that EDI requires. But
> millions of people are using them. An EDI-friendly Linux
> accounting programme would open up a great many
> opportunities.
>
> John Gibson
|
|
From: C K Wu <ck...@ch...> - 2002-10-07 05:31:12
|
Hi, folks,
Thought you may be interested in the latest effort in multi-language support.
Cheers,
CK
C K Wu wrote:
> Hi, Marc,
>
> Lovely. Glad to know that you've fixed the developer_tools module.
> I'll probably need to borrow your modifications when developing
> the Chinese translations. [Actually, if it is an enhancement, I guess
> you may like to post a patch at gnu's phpgroupware project page.]
>
> Your enhancement of the string handling is definitely a good one.
> Please go ahead with the modification. If you don't mind, could
> you send me a list of the strings involved after you have completed
> the modifications. I'll add these to the next release.
>
> Come to think about it. There are quite a few places where I
> haven't slotted in the proper lang() call, and place the string text
> right into the program script. Typically, this is true of all the error
> messages despatched by the validation functions. I'll search for
> all such string texts and ensure the lang() are in place in the next
> release.
>
> Great work.
>
> Cheers,
> CK
>
> Marc Lutolf wrote:
>
> > Hi CK,
> >
> > Since I wasn't getting much response to my queries on the mailing list about
> > developer_tools, I spent some time looking at the code and think I have
> > corrected the problem. I think I have also figured out how this module
> > works.
> >
> > This is not the most intuitive of modules, but I think I can work with it,
> > so I'd like to begin setting up some language files for CK-Ledger, starting
> > with the AR module. However, I have a small problem. It turns out there are
> > quite a number of strings like this one in the code:
> >
> > $message1 = lang("<b>All Invoices already settled</b>")
> >
> > If you agree, I'd like to change these into
> >
> > $message1 = "<b>".lang("All Invoices already settled")."</b>"
> >
> > What do you think of this idea?
> >
> > Cheers,
> >
> > Marc
|
|
From: C K Wu <ck...@ch...> - 2002-10-07 05:23:50
|
Hi, JD, Thanks for checking out CK-Ledger. The "invalid due date" message is issued based on the formatting of the due date field, which requires "yyyy-mm-dd". You could view the various test ar invoices and so's to see the required format. To see if there are any specific condition or setting with your local machine, try the following approach, Go to: AR->Customer Invoice[with tax]-> Search among posted invoices -> List of Invoices [with Tax] -> Copy/Modify (any invoice) -> Copy Invoice [With Tax] -> Click Post Invoice and check if you get an exact duplicate of the original test invoice. If yes, repeat the above process, but change the [Due Date] field only to your desired value and see if you get a new invoice posted with everything the same except the [Due Date] field. There have been some discussion about the current setup in terms of customer contact handling. It involves a strategic decision as to how closely CK-Ledger should be tied with Phpgroupware. Already there are two contact management modules inside Phpgroupware and situation is still evolving. I am currently developing a personnel module for CK-Ledger and the whole issue of contact management will certainly be examined in greater detail. Cheers, CK Constant Computer Services wrote: > With both customer invoice and sales order, > when I try to "post", I get an invalid due date. > > I've checked all the settings and just can't see why. > > btw, very nice product (definate candidate for > "linux open source soho" killer ap). > > If you integrated (used their code - whatever) > groupware's address book to replace your > current customer detail handling, this would > be a very good thing, I think. > > Regards > J.D. > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > CK-Ledger-users mailing list > CK-...@li... > https://lists.sourceforge.net/lists/listinfo/ck-ledger-users |
|
From: Constant C. S. <cc...@tp...> - 2002-10-06 20:35:04
|
With both customer invoice and sales order, when I try to "post", I get an invalid due date. I've checked all the settings and just can't see why. btw, very nice product (definate candidate for "linux open source soho" killer ap). If you integrated (used their code - whatever) groupware's address book to replace your current customer detail handling, this would be a very good thing, I think. Regards J.D. |
|
From: C K Wu <ck...@ch...> - 2002-09-30 14:41:12
|
Hi, Marc, Thank you for the detail description of the European VAT scene. I'll certainly read through the attached manual to see if there is any additional enhancement that can be added to ck-ledger. Cheers, CK Marc Lutolf wrote: > Hi CK, > > My experience with sales tax/VAT is limited to some European countries and, > (somewhat) to the US. You can pretty much consider the US states as separate > countries as far as sales tax issues go. |
|
From: C K Wu <ck...@ch...> - 2002-09-30 14:33:56
|
Hi, Marc, Thanks for the valuable suggestion. I am not too familiar with javascript, so in general I tend to avoid using it. I'll look into the suggested approach and see how best to implement the feature. Cheers, CK Marc Lutolf wrote: > Hi CK, > > You are certainly right that the invoice screen get crowded, and I wouldn't > advocate adding buttons to it. My preference with large input screens is to > tie an onChange to the input fields or dropdowns that either > > 1. triggers a javascript that essentially does a recalc of the whole screen. > This may sound like overkill, but I find it tends to be easier than writing > different scripts to update only certain fields. And though your page gets a > little bloated, running javascript on the client tends to be faster than a > submit and refreshing the page. Also, a recalc is nothing fancy, so you > usually don't have to worry about different browser versions. > > or > > 2. If the page doesn't contain enough information to do the recalc, I tie a > submit to make it go away and do whatever database queries are necessary to > do the update. > > I should mention at this point that I am thinking in terms of a Cold Fusion > app working with some javascript. Presumably with PHP it would also work, > but I'm no PHP guru, so take it with a grain of salt. > > In my first suggestion I see tying a script to the dropdown that would, on > changing the dropdown value, fill the input field with the appropriate > value. Manual input would be disallowed, such as in the View option for > looking at invoices. Choosing the "manual input" option of the dropdown > would free the input field for manual input. The problem is that you need to > trigger an onChange for this to work (unless you are happy with a value of > zero). Hence my suggestion of a blank default in the dropdown. The advantage > is that the user *always* sees exactly what value he has in the input field. > The downside is that the user is always forced (unless he is happy with > zero) to at least one click. > > Suggestion 2 is as you describe it. I don't see any special need for a blank > default for the dropdown here, as in suggestion 1. > > Cheers, > > Marc > > -----Original Message----- > From: C K Wu [mailto:ck...@ch...] > Sent: 30 September 2002 08:51 > To: mf...@ne...; ck-...@li... > Subject: Re: [CK-Ledger-users] Invoice Tax Field Handling > > Hi, Marc, > > The Tax Field in the invoice screen is probably the most difficult > area in terms of screen design. > > Suggestion 1 of allowing independent tax manual input in combination > of a submit button have the drawback of adding more to the > already rather crowded screen row. You'll probably notice that I have > avoided adding row insert button (in this screen) which was introduced in > v.0.2.1. > > Suggestion 2 is the current design with the added comment of > "Recal tax after changing Qty/Discount/UP Rate". This is effectively > saying the system has no way of telling whether the user wish to retain > the previous tax figures (due to its being a manual override) after a > Qty/Discount/UP Rate field change. So, user beware. However, > with the further suggested "manual input" dropdown choice, this is > a whole new ball game. I'll check to see if the added "manual input" > dropdown choice is the answer that I've looking for or if some other > keying sequence may have been overlooked. > > You have also rightly pointed out that it may not be desirable to > save the dropdown choice just to allow the detection of a > "current" transaction. I think we should put this aside for the > moment pending how the Service Aggregate feature works out. > > If everything works fine, I hope to see the "manual input" dropdown > choice as part of the next release. > > Cheers, > CK > > Marc Lutolf wrote: > > > Hi CK, > > > > You raise some interesting points. Let me first state my opinion, and then > > explain it. > > The short answer is: Of course I'm looking to solve my own little problem, > > but standing back I think conceptually a "Service Plan" is the way to go, > > and on the other hand leave the copy/modify the way it is. Also, the tax > > rate dropdowns on invoices should have as a default value a blank. > > > > ------------------------------------------------- > > In detail: > > The copy/modify presently does just that, it copies an existing invoice, > > one-to-one. It doesn't "generate a new invoice based on the latest data, > but > > that has the same structure as the previous one". You rightly point out > the > > problem of reconstructing the tax. Apart from manual input there is also > the > > question of whether the value used in the template is the customer or item > > rate. > > > > In short, there is no way of knowing what the correct "current value" of > the > > tax is. Conceivably one could get around this by saving the tax dropdown > > value initially chosen in the invoice transaction. This, by the way, would > > also solve the problem that the dropdown currently always defaults to the > > first row, which can be slightly confusing. > > > > In order to have a consistent behaviour, though, a fourth value would have > > to be created for the dropdown: "manual input". The behaviour needs to be > > forced in one of two ways. > > > > 1. You allow manual entry into the tax field only if "manual entry" is > > chosen in the dropdown. This means tying a submit to the dropdown. > > > > 2. You allow manual entry whatever the dropdown contains, and have the > > script check the value when saving and then decide which dropdown value > the > > tax value corresponds to. There are different ways to do this. You may > carry > > the "current" item and customer rates as hidden fields in order in order > to > > do a quick comparison, or you get the values fresh from the database as a > > couple of queries during the save. > > > > Once we have the dropdown value, of course, it is easy to construct a > > "current" transaction. You simply take the current values in the case of > > customer or item rates, But the dropdown is not really posting data, so I > > don't know that it is worth the effort at this point to save it. To save > it > > in order to have the dropdown remembered when the transaction is called up > > again makes sense (but from the above it takes a bit of code!), but to > save > > it only so that a "current" transaction can be created (and thus perhaps > > confusing a lot of users) seems to me not to make sense. |
|
From: C K Wu <ck...@ch...> - 2002-09-30 14:27:09
|
Hi, Marc, Thanks for the suggestion. These will be factored into the next round of ck-ledger enhancement. Cheers, CK Marc Lutolf wrote: > Hi CK, > > Great news that there will be service plan functionality! Since the > terminology appears ambiguous you might also consider "Service Bundle" or > "Service Package". > > As to the pricing differences: > > $UP[service plan] < Sum($UP[constituent service items]) > > There are at least two solutions here I could see: > > 1. One creates a discount field within the service plan definition, similar > to the discount field on the invoice form. This would allow the user to > define some sort of global discount for the service plan. > > 2. One does nothing, and forces the user to define component items such that > > $UP[service plan] = Sum($UP[constituent service items]) > > This means that some components would have 2 definitions: one sold > separately and one sold as part of a service package. This may not be as > farfetched as you might think, because some users may consider attaching > different discounts to each component sold as part of a service plan. It > would also make it possible to introduce price variations in one component, > say a domain name registration, without disturbing the price of that > component in the service plan, and thus the service plan price. > > Given that, in addition, there is already the discount field in the invoice > creation form, I would suggest the second. > > Marc > > -----Original Message----- > From: C K Wu [mailto:ck...@ch...] > Sent: 30 September 2002 07:50 > To: mf...@ne...; ck-...@li... > Subject: Re: [CK-Ledger-users] Service Plan/Aggregate > > Hi, Marc, > > I am breaking the reply into different emails, so other list members can > follow our discussion more readily. > > Service Plan will definitely be part of the next release. My initial > concern > was that some users will misinterpret Service Plan to be an independent > item with its own unit price (UP) and also, > > $UP[service plan] < Sum($UP[constituent service items]) > > Indeed, the wording, service plan, comes from some local Hongkong ISP > offerings, e.g., SME package plan A with monthly charge of HK$1000, > covering broadband and IDD phone, with broadband and IDD phone, > individually priced at HK$600 per month. > > I am changing the terminology to Service Aggregate, so there is less > chance of a user misinterpretation. > > I'll try to re-focus on Service Plan, itself, as a pricing mechnanism later > when Assembly sales/purchase is being handled. > > Cheers, > CK |
|
From: C K Wu <ck...@ch...> - 2002-09-30 07:43:58
|
Hi, Marc, I've thought about the possibility of users' overlooking the need to pick the right tax choice (item vs customer). However, if I understand most countries' tax rule correctly, normally only specific sector of the economy is required to look into the customer's identity, and charges VAT/Sales tax accordingly. For example, import/export firms may have to decide the identity of a foreign customer, as it would affect the level of subsequent tax rebate and therefore, what to charge as a tax provision in combination with the import/export duty. This may also be true for companies selling to the agricultural sector. You would notice that I have eliminated such user discretion in the POS module, because I believe the cash sale sector is rarely required to make such distinction. However, your suggestion is a good one. I'll inclined to add this as an optional feature subject to activation by system admin via a "Ledger Admin -> Defaults" setup choice. What's your thought on these ? Cheers, CK Marc Lutolf wrote: > > Up to here I have been arguing against changing the present behaviour of > copy/modify (perhaps with the exception of the dropdown issue), and that > conceptually the user shouldn't expect it to automatically "generate a new > invoice based on the latest data, but that has the same structure as the > previous one". But if it's not to be used for that, then what is it supposed > to do? > > The answer is that the user makes a one-to-one copy with the expectation of > *manually* adjusting it in order to: > > 1. Create the same invoice with current unit prices, taxes etc., essentially > doing manually what I am arguing against doing automatically. (!) > 2. Create an invoice in structure similar to, but not equal to, the template > invoice. In other words, drop and/or add one or more items. > > At this point we come to your suggestion of a "refresh unit price from > database" button, which would then be construed as an added help for > invoices with lots of single items (a feature!). It would presumably be a > single button, rather than one per row. I don't see that anybody would want > to recalc only some rows, and if so, then they'd just have to readjust > manually. > > We are then left with the problem of the taxes again, which I went into > above. However, there is another option: purposely leaving the taxes blank, > and have them calculated when the transaction is saved. > > But this can create a problem, because the user might just pass over those > fields and hit the save button, not realizing the dropdowns are at the first > value, and thinking (somehow) they will result in the same value as the > template transaction. > > The simple solution to this is to add a blank field as the default selected > by the dropdown, and force the user to make a choice before he saves. This > can be achieved by checking the dropdown itself when save happens, or > checking whether there is a value in the tax field. > > My own preference would actually be to have the tax fields automatically > recalculated each time an item is added or the dropdown value changes. > > ------------------------------------------------- > > If the idea of a blank value for the dropdown makes sense in the above case, > I think it also makes sense in the case of adding a new invoice transaction, > for the same reasons. Note that in a later release ck-ledger may want to > have default tax rate assignments for certain accounts, invoices or items, > and thus reduce the amount of manual clicks on the tax dropdowns. But right > now, in my view, you are forced to always pay attention to those dropdowns. > Yes, the current default (item rate) is probably the most common case, but > you still need to check each time. So I think forcing you to actually choose > can avoid errors. > > Sorry if this has gotten a bit long, but you did ask for my thoughts! > > Marc > > -----Original Message----- > From: C K Wu [mailto:ck...@ch...] > Sent: 28 September 2002 14:12 > To: mf...@ne... > Cc: ck-...@li... > Subject: Re: [CK-Ledger-users] Service invoicing question > > Hello, Marc, > > Marc Lutolf wrote: > > > First of all congratulations on the new release. The fact that this is > > classified as beta (rightly so, I suppose), doesn't do justice to the well > > thought out planning that has clearly gone into its creation. This is a > very > > nice app and getting even nicer by leaps and bounds! > > > > Thank you for the compliment. > > > > > My question: I'm trying to apply this to a situation of a hosting provider > > and am working at defining the product costs. > > > > One problem is that customers need to be billed at regular intervals. I > > don't think the script does this (yet). Is that correct? > > > > Yes. You're right. Recurring invoice is not supported at the moment. The > consideration > is the same with recurring journal. Initially, I don't wish to complicate > the > system design too much. At the same time, invoice copy/modify is available > to release the burden of repetitive invoice generation. However, I am > starting > work on the payrol module, which definitely will have to support recurring > and non-recurring components of a payrol payment. After completing the > payrol module, I'll try to back-port the recurring/non-recurring design > to invoice/journal generation. > > > > > Second issue: product prices. This is a business where typically an > invoice > > will contain a series of services, such as domain names, mail accounts > etc. > > The question is how best to generate reoccuring invoices with the same > > services. Here are some possibilities: > > > > 1. Copy/modify the original invoice to create a new one with the same > items. > > The problem I see here is that the unit price stays the same (because it's > > taken from the invoice template), even if I have since changed the unit > > price of the item itself. For my purposes it would be better if it took > the > > line item info from the service definitions. > > > > Agree. > > > > > 2. Create a ficticious product with an assmbly that contains the services > as > > components. > > This is a bit of a reach because ck-ledger doesn't support services as > > components of other services. Terminology aside I suppose this might be > > doable. However, it will force me to indicate a COG account for the > > "product". Since this is a concept not really appropriate for services, I > > would have some dummy COG account being filled with 0 each time an invoice > > goes out. A bit of a kludge, I think. > > > > Purchase and Sale of Assembly, at the moment, does not work properly. > However, the general concept of a Service Plan may work. A service plan > comprises various service components and the final price is the summation > of the component prices. Since it does not involve inventory in/out, it > would > be easier to implement. However, this will involve explaining to users > that the copying of a service item will have $unit price maintained the > same, > while the copying of a service plan will retrieve the latest $unit price > from > database. Some users may object to such interpretation of "copy" . > > > > > There may be othe ways of handling this situation. Any thoughts on this? > > > > Marc > > > > A third possibility is to add a new button at the bottom of the invoce > page, labeled "refresh unit price from database". This will adjust all unit > price > according to the latest service definition and have item totals > recalculated. > However, > the complication here is deciding whether to recalculate tax at the same > time. > If the existing tax is a manual input overriding the system default, then > auto-tax-recal, will > require user re-inputting the manual figure, a bit of a chore. If tax is > maintained > the same, then in vast majority of the case, user will have to click the tax > recal button > at each row to adjust the tax according to the new totals, thus, another > chore. > Your thoughts on these ? > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > CK-Ledger-users mailing list > > CK-...@li... > > https://lists.sourceforge.net/lists/listinfo/ck-ledger-users |
|
From: C K Wu <ck...@ch...> - 2002-09-30 06:50:01
|
Hi, Marc, The Tax Field in the invoice screen is probably the most difficult area in terms of screen design. Suggestion 1 of allowing independent tax manual input in combination of a submit button have the drawback of adding more to the already rather crowded screen row. You'll probably notice that I have avoided adding row insert button (in this screen) which was introduced in v.0.2.1. Suggestion 2 is the current design with the added comment of "Recal tax after changing Qty/Discount/UP Rate". This is effectively saying the system has no way of telling whether the user wish to retain the previous tax figures (due to its being a manual override) after a Qty/Discount/UP Rate field change. So, user beware. However, with the further suggested "manual input" dropdown choice, this is a whole new ball game. I'll check to see if the added "manual input" dropdown choice is the answer that I've looking for or if some other keying sequence may have been overlooked. You have also rightly pointed out that it may not be desirable to save the dropdown choice just to allow the detection of a "current" transaction. I think we should put this aside for the moment pending how the Service Aggregate feature works out. If everything works fine, I hope to see the "manual input" dropdown choice as part of the next release. Cheers, CK Marc Lutolf wrote: > Hi CK, > > You raise some interesting points. Let me first state my opinion, and then > explain it. > The short answer is: Of course I'm looking to solve my own little problem, > but standing back I think conceptually a "Service Plan" is the way to go, > and on the other hand leave the copy/modify the way it is. Also, the tax > rate dropdowns on invoices should have as a default value a blank. > > ------------------------------------------------- > In detail: > The copy/modify presently does just that, it copies an existing invoice, > one-to-one. It doesn't "generate a new invoice based on the latest data, but > that has the same structure as the previous one". You rightly point out the > problem of reconstructing the tax. Apart from manual input there is also the > question of whether the value used in the template is the customer or item > rate. > > In short, there is no way of knowing what the correct "current value" of the > tax is. Conceivably one could get around this by saving the tax dropdown > value initially chosen in the invoice transaction. This, by the way, would > also solve the problem that the dropdown currently always defaults to the > first row, which can be slightly confusing. > > In order to have a consistent behaviour, though, a fourth value would have > to be created for the dropdown: "manual input". The behaviour needs to be > forced in one of two ways. > > 1. You allow manual entry into the tax field only if "manual entry" is > chosen in the dropdown. This means tying a submit to the dropdown. > > 2. You allow manual entry whatever the dropdown contains, and have the > script check the value when saving and then decide which dropdown value the > tax value corresponds to. There are different ways to do this. You may carry > the "current" item and customer rates as hidden fields in order in order to > do a quick comparison, or you get the values fresh from the database as a > couple of queries during the save. > > Once we have the dropdown value, of course, it is easy to construct a > "current" transaction. You simply take the current values in the case of > customer or item rates, But the dropdown is not really posting data, so I > don't know that it is worth the effort at this point to save it. To save it > in order to have the dropdown remembered when the transaction is called up > again makes sense (but from the above it takes a bit of code!), but to save > it only so that a "current" transaction can be created (and thus perhaps > confusing a lot of users) seems to me not to make sense. |
|
From: C K Wu <ck...@ch...> - 2002-09-30 05:50:31
|
Hi, Marc,
I am breaking the reply into different emails, so other list members can
follow our discussion more readily.
Service Plan will definitely be part of the next release. My initial concern
was that some users will misinterpret Service Plan to be an independent
item with its own unit price (UP) and also,
$UP[service plan] < Sum($UP[constituent service items])
Indeed, the wording, service plan, comes from some local Hongkong ISP
offerings, e.g., SME package plan A with monthly charge of HK$1000,
covering broadband and IDD phone, with broadband and IDD phone,
individually priced at HK$600 per month.
I am changing the terminology to Service Aggregate, so there is less
chance of a user misinterpretation.
I'll try to re-focus on Service Plan, itself, as a pricing mechnanism later
when Assembly sales/purchase is being handled.
Cheers,
CK
Marc Lutolf wrote:
> Hi CK,
>
> -------------------------------------------------
>
> I have to say I'm not unhappy that the assembly cannot presently be used to
> solve my problem; I didn't really like that idea. :)
> A Service Plan concept would fit the bill exactly. If I understand you
> correctly, a plan would simply be an item/service that in turn is composed
> of other items/services, and whose unit price is the aggregate price of all
> the components. But if such a thing exists, I presume an invoice would be
> created by adding a plan item to an invoice transaction I create, and the
> script would then explode it into its components. Is this interpretation
> correct? If so, then copy/modify would not be needed to create a similar
> invoice, because sticking the plan item into a new invoice would be almost
> as fast, and conceptually more correct than trying to bill by creating a
> copy of an invoice.
>
> -------------------------------------------------
|
|
From: C K Wu <ck...@ch...> - 2002-09-30 05:04:48
|
Hi, Sigurd,
Thank you for the suggestion.
While phpgroupware is a superb software, I have stated clearly
at the very outset of ck-ledger that I do not subscribe to phpgroupware's
team culture. The bickering within the phpgroupware team is perhaps
inevitable with a large open source development team. We have already
seen Angles and Miles Lott leaving the core team. In fact, if the bickering
continues, I'll consider pulling ck-ledger off the phpgroupware platform.
Cheers,
CK
Sigurd Nes wrote:
> How about implementing ck-ledger as a native application of phpgroupware
> - I think both Phpgroupware and ck-ledger would derive advantage from
> ck-ledger being part of phpgroupware. One most certainly would have to
> rearrange the modules into one super-module with several sub-modules.
> This is pretty easy - in addition one would have to add some security
> mechanism in addition to the standard ACL - but again - this is pretty
> easy. I have already done the similar exercise to my application
> "property" - which is a facilities management application with six
> sub-modules. Each user has unique rights within each submodule - one
> module even has roles (for invoice handling). Each user can set their
> preferred sub-module as "start-page"
> I have implemented this as follows:
>
> startpage:
>
> $start_page=$GLOBALS['phpgw_info']['user']['preferences']['property']['d
> efault_start_page'];
> (the preferences is set from /inc/hook_settings.inc.php)
>
> The array for rights and roles are buildt from the table fm_admin and
> put into two arrays: one for the values - and the other for where to
> find the values - and then passed on as appsession variables.
>
> The table fm_table is listed in /workorder_admin.php and populated from
> /add_admin.php
>
> I produce the arrays in /index.php before redirecting to the users
> startpage
>
> to pass on the variables:
>
> $GLOBALS['phpgw']->session->appsession('admins','property',$admins);
>
> $GLOBALS['phpgw']->session->appsession('module_order','property',$module
> _order);
>
> to fetch the information from the arraay (in /inc/header.php):
> $admins =
> $GLOBALS['phpgw']->session->appsession('admins','property');
> $module_order =
> $GLOBALS['phpgw']->session->appsession('module_order','property');
>
> $admin_equipment=$admins[$module_order['equipment']]['equipment']['admin
> '];
>
> Regards
>
> Sigurd Nes
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> CK-Ledger-users mailing list
> CK-...@li...
> https://lists.sourceforge.net/lists/listinfo/ck-ledger-users
|
|
From: Sigurd N. <sig...@on...> - 2002-09-29 15:06:36
|
How about implementing ck-ledger as a native application of phpgroupware
- I think both Phpgroupware and ck-ledger would derive advantage from
ck-ledger being part of phpgroupware. One most certainly would have to
rearrange the modules into one super-module with several sub-modules.
This is pretty easy - in addition one would have to add some security
mechanism in addition to the standard ACL - but again - this is pretty
easy. I have already done the similar exercise to my application
"property" - which is a facilities management application with six
sub-modules. Each user has unique rights within each submodule - one
module even has roles (for invoice handling). Each user can set their
preferred sub-module as "start-page"
I have implemented this as follows:
startpage:
$start_page=$GLOBALS['phpgw_info']['user']['preferences']['property']['d
efault_start_page'];
(the preferences is set from /inc/hook_settings.inc.php)
The array for rights and roles are buildt from the table fm_admin and
put into two arrays: one for the values - and the other for where to
find the values - and then passed on as appsession variables.
The table fm_table is listed in /workorder_admin.php and populated from
/add_admin.php
I produce the arrays in /index.php before redirecting to the users
startpage
to pass on the variables:
$GLOBALS['phpgw']->session->appsession('admins','property',$admins);
$GLOBALS['phpgw']->session->appsession('module_order','property',$module
_order);
to fetch the information from the arraay (in /inc/header.php):
$admins =
$GLOBALS['phpgw']->session->appsession('admins','property');
$module_order =
$GLOBALS['phpgw']->session->appsession('module_order','property');
$admin_equipment=$admins[$module_order['equipment']]['equipment']['admin
'];
Regards
Sigurd Nes
|
|
From: Marc L. <mf...@ne...> - 2002-09-29 11:31:58
|
Hi CK, You are right about the complexity of the VAT issue. I neglected to mention that in the UK example I gave the tax on alcohol is not VAT. VAT is actually levied on top of that, which probably lends more weight to your argument for throwing special cases into a catchall manual tax input. Whereas the world is getting to the point of agreeing more or less on what good accounting practice is, we are far from agreeing on taxes! Marc |
|
From: C K Wu <ck...@ch...> - 2002-09-29 11:06:59
|
Hi, Marc, Thank you for the valuable suggestion and detail discussion. Obviously, there are a number of design decisions to make here. I'll give it a detail thought and come back to you in a little while. PS - see comment on VAT below. Marc Lutolf wrote: > Hi CK, > > You raise some interesting points. Let me first state my opinion, and then > explain it. > The short answer is: Of course I'm looking to solve my own little problem, > but standing back I think conceptually a "Service Plan" is the way to go, > and on the other hand leave the copy/modify the way it is. Also, the tax > rate dropdowns on invoices should have as a default value a blank. > > ------------------------------------------------- > In detail: > The copy/modify presently does just that, it copies an existing invoice, > one-to-one. It doesn't "generate a new invoice based on the latest data, but > that has the same structure as the previous one". You rightly point out the > problem of reconstructing the tax. Apart from manual input there is also the > question of whether the value used in the template is the customer or item > rate. > > In short, there is no way of knowing what the correct "current value" of the > tax is. Conceivably one could get around this by saving the tax dropdown > value initially chosen in the invoice transaction. This, by the way, would > also solve the problem that the dropdown currently always defaults to the > first row, which can be slightly confusing. > > In order to have a consistent behaviour, though, a fourth value would have > to be created for the dropdown: "manual input". The behaviour needs to be > forced in one of two ways. > > 1. You allow manual entry into the tax field only if "manual entry" is > chosen in the dropdown. This means tying a submit to the dropdown. > > 2. You allow manual entry whatever the dropdown contains, and have the > script check the value when saving and then decide which dropdown value the > tax value corresponds to. There are different ways to do this. You may carry > the "current" item and customer rates as hidden fields in order in order to > do a quick comparison, or you get the values fresh from the database as a > couple of queries during the save. > > Once we have the dropdown value, of course, it is easy to construct a > "current" transaction. You simply take the current values in the case of > customer or item rates, But the dropdown is not really posting data, so I > don't know that it is worth the effort at this point to save it. To save it > in order to have the dropdown remembered when the transaction is called up > again makes sense (but from the above it takes a bit of code!), but to save > it only so that a "current" transaction can be created (and thus perhaps > confusing a lot of users) seems to me not to make sense. > > BTW: I also want to point out that there are cases in which the tax is on a > per unit basis, rather than as a % of value. For instance, in the UK the tax > on alcohol is a fixed amount per bottle (or litre), irregardless of the > value of the bottle. > I've thought about implementing some of the more pedestrian tax rules. However, it's a case of system complexity vs user convenience. I finally decided to put in the catch-all feature of allowing manual tax input. Actually, I got a feeling that VAT is something of a programmer employment creation exercise. There is a joke going around like this: "Programmers would no longer need to worry about future employment if legislators mean what they say and actually vote to have VAT be charged on an ability-to-pay basis, ie, link VAT charged on an item to the customer's monthly payrol." Cheers, CK > > ------------------------------------------------- > > I have to say I'm not unhappy that the assembly cannot presently be used to > solve my problem; I didn't really like that idea. :) > A Service Plan concept would fit the bill exactly. If I understand you > correctly, a plan would simply be an item/service that in turn is composed > of other items/services, and whose unit price is the aggregate price of all > the components. But if such a thing exists, I presume an invoice would be > created by adding a plan item to an invoice transaction I create, and the > script would then explode it into its components. Is this interpretation > correct? If so, then copy/modify would not be needed to create a similar > invoice, because sticking the plan item into a new invoice would be almost > as fast, and conceptually more correct than trying to bill by creating a > copy of an invoice. > > ------------------------------------------------- > > I don't quite understand this sentence; > > "However, this will involve explaining to users > that the copying of a service item will have $unit price maintained the > same, > while the copying of a service plan will retrieve the latest $unit price > from > database." > > If my interpretation of a plan item as described above is correct, then > presumably any change of a component item would generate a recalc of the > unit price of the plan item, which actually may not even be manually > editable. So I don't see how the behaviour you describe should come about. > But I do agree that if it worked like that, a lot of users would get > confused as to what a "copy" was exactly. > > ------------------------------------------------- > > Up to here I have been arguing against changing the present behaviour of > copy/modify (perhaps with the exception of the dropdown issue), and that > conceptually the user shouldn't expect it to automatically "generate a new > invoice based on the latest data, but that has the same structure as the > previous one". But if it's not to be used for that, then what is it supposed > to do? > > The answer is that the user makes a one-to-one copy with the expectation of > *manually* adjusting it in order to: > > 1. Create the same invoice with current unit prices, taxes etc., essentially > doing manually what I am arguing against doing automatically. (!) > 2. Create an invoice in structure similar to, but not equal to, the template > invoice. In other words, drop and/or add one or more items. > > At this point we come to your suggestion of a "refresh unit price from > database" button, which would then be construed as an added help for > invoices with lots of single items (a feature!). It would presumably be a > single button, rather than one per row. I don't see that anybody would want > to recalc only some rows, and if so, then they'd just have to readjust > manually. > > We are then left with the problem of the taxes again, which I went into > above. However, there is another option: purposely leaving the taxes blank, > and have them calculated when the transaction is saved. > > But this can create a problem, because the user might just pass over those > fields and hit the save button, not realizing the dropdowns are at the first > value, and thinking (somehow) they will result in the same value as the > template transaction. > > The simple solution to this is to add a blank field as the default selected > by the dropdown, and force the user to make a choice before he saves. This > can be achieved by checking the dropdown itself when save happens, or > checking whether there is a value in the tax field. > > My own preference would actually be to have the tax fields automatically > recalculated each time an item is added or the dropdown value changes. > > ------------------------------------------------- > > If the idea of a blank value for the dropdown makes sense in the above case, > I think it also makes sense in the case of adding a new invoice transaction, > for the same reasons. Note that in a later release ck-ledger may want to > have default tax rate assignments for certain accounts, invoices or items, > and thus reduce the amount of manual clicks on the tax dropdowns. But right > now, in my view, you are forced to always pay attention to those dropdowns. > Yes, the current default (item rate) is probably the most common case, but > you still need to check each time. So I think forcing you to actually choose > can avoid errors. > > Sorry if this has gotten a bit long, but you did ask for my thoughts! > > Marc |
|
From: C K Wu <ck...@ch...> - 2002-09-28 12:11:10
|
Hello, Marc, Marc Lutolf wrote: > First of all congratulations on the new release. The fact that this is > classified as beta (rightly so, I suppose), doesn't do justice to the well > thought out planning that has clearly gone into its creation. This is a very > nice app and getting even nicer by leaps and bounds! > Thank you for the compliment. > > My question: I'm trying to apply this to a situation of a hosting provider > and am working at defining the product costs. > > One problem is that customers need to be billed at regular intervals. I > don't think the script does this (yet). Is that correct? > Yes. You're right. Recurring invoice is not supported at the moment. The consideration is the same with recurring journal. Initially, I don't wish to complicate the system design too much. At the same time, invoice copy/modify is available to release the burden of repetitive invoice generation. However, I am starting work on the payrol module, which definitely will have to support recurring and non-recurring components of a payrol payment. After completing the payrol module, I'll try to back-port the recurring/non-recurring design to invoice/journal generation. > > Second issue: product prices. This is a business where typically an invoice > will contain a series of services, such as domain names, mail accounts etc. > The question is how best to generate reoccuring invoices with the same > services. Here are some possibilities: > > 1. Copy/modify the original invoice to create a new one with the same items. > The problem I see here is that the unit price stays the same (because it's > taken from the invoice template), even if I have since changed the unit > price of the item itself. For my purposes it would be better if it took the > line item info from the service definitions. > Agree. > > 2. Create a ficticious product with an assmbly that contains the services as > components. > This is a bit of a reach because ck-ledger doesn't support services as > components of other services. Terminology aside I suppose this might be > doable. However, it will force me to indicate a COG account for the > "product". Since this is a concept not really appropriate for services, I > would have some dummy COG account being filled with 0 each time an invoice > goes out. A bit of a kludge, I think. > Purchase and Sale of Assembly, at the moment, does not work properly. However, the general concept of a Service Plan may work. A service plan comprises various service components and the final price is the summation of the component prices. Since it does not involve inventory in/out, it would be easier to implement. However, this will involve explaining to users that the copying of a service item will have $unit price maintained the same, while the copying of a service plan will retrieve the latest $unit price from database. Some users may object to such interpretation of "copy" . > > There may be othe ways of handling this situation. Any thoughts on this? > > Marc > A third possibility is to add a new button at the bottom of the invoce page, labeled "refresh unit price from database". This will adjust all unit price according to the latest service definition and have item totals recalculated. However, the complication here is deciding whether to recalculate tax at the same time. If the existing tax is a manual input overriding the system default, then auto-tax-recal, will require user re-inputting the manual figure, a bit of a chore. If tax is maintained the same, then in vast majority of the case, user will have to click the tax recal button at each row to adjust the tax according to the new totals, thus, another chore. Your thoughts on these ? > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > CK-Ledger-users mailing list > CK-...@li... > https://lists.sourceforge.net/lists/listinfo/ck-ledger-users |
|
From: C K Wu <ck...@ch...> - 2002-09-28 10:33:58
|
Hello, folks, I must apologise for forgetting to put in the following acknowledgement when releasing v.0.2.1. The design of attribute accounting was arrived at after detail discussion and with valuable contribution from Robert del Huerto of US. Cheers, CK |
|
From: Marc L. <mf...@ne...> - 2002-09-28 09:11:52
|
First of all congratulations on the new release. The fact that this is classified as beta (rightly so, I suppose), doesn't do justice to the well thought out planning that has clearly gone into its creation. This is a very nice app and getting even nicer by leaps and bounds! My question: I'm trying to apply this to a situation of a hosting provider and am working at defining the product costs. One problem is that customers need to be billed at regular intervals. I don't think the script does this (yet). Is that correct? Second issue: product prices. This is a business where typically an invoice will contain a series of services, such as domain names, mail accounts etc. The question is how best to generate reoccuring invoices with the same services. Here are some possibilities: 1. Copy/modify the original invoice to create a new one with the same items. The problem I see here is that the unit price stays the same (because it's taken from the invoice template), even if I have since changed the unit price of the item itself. For my purposes it would be better if it took the line item info from the service definitions. 2. Create a ficticious product with an assmbly that contains the services as components. This is a bit of a reach because ck-ledger doesn't support services as components of other services. Terminology aside I suppose this might be doable. However, it will force me to indicate a COG account for the "product". Since this is a concept not really appropriate for services, I would have some dummy COG account being filled with 0 each time an invoice goes out. A bit of a kludge, I think. There may be othe ways of handling this situation. Any thoughts on this? Marc |
|
From: C K Wu <ck...@ch...> - 2002-09-27 13:33:59
|
Hello, folks, I have posted a new major release, v.0.2.1, of CK-Ledger, at SourceForge.Net. New features include attribute accounting, allowing Profit&Loss reporting against different attributes (fund, project, department, region, etc). Log table is added. System wide transaction id is re-designed. Transaction posting and test data generator is rewritten. Other enhancements and bug fixes are also included. To allow better integration with external software, attribute tables (fund, project, department, ...) are designed to require only an id, a short and a long description field. Which table to use can be changed by setting values in the [LedgerAdmin->defaults] screen. Attribute table maintenance can also be hidden from user by setting [yes/no] flag on the same screen. Project accounting could, for instance, be based on phpgw/project's project table. Please note that Konqueror/KDE3/RedHat7.3 has problem accessing the various features of CK-Ledger, while Konqueror/KDE2/RedHat7.2 and other browsers have been tested to work fine under similar circumstances. Mandrake 8.2, with KDE upgraded to v.3.0.2 also functions properly. 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. Operating platform can either be LAMP or LAPP. It provides accounting functionalities to SMEs and utilizes phpgw to administer accounts/groups. Installation Manual and Features List are available at http://sourceforge.net/projects/ck-ledger. (Just click on the [Docs] label at the header menu line above the brief project description.) 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 |
|
From: C K Wu <ck...@ch...> - 2002-09-24 17:49:34
|
Hi, Davide, Thank you for your interest in ck-ledger. An italian version of ck-ledger is not yet available. However, since ck-ledger works as plug-in modules to phpgroupware, the language infrastructure embedded in phpgroupware is open to ck-ledger. There are in fact specific tools to perform translation within phpgroupware and I believe there is already effort to produce an italian version of phpgroupware itself. If you like to localize ck-ledger for use in Italy, more information is available from www.phpgroupware.org (Section - Documentation, Subtopic - translation) and from the mailing list, php...@gn.... However, in terms of actual translation, you may like to hold off for a little while. I am releasing a major new release, v.0.2.1 in a few days' time. PS - I am sending a copy of this reply to ck-...@li..., so the others are aware of current development. Cheers, CK Davide Barbieri wrote: > Hi CK, > > I'm giving a try to ck-ledger. It looks pretty good. > Thank you for your effort. > > I live in Italy, and if I'm going to use it I'd prefer > to localize it (eg. having invoices written in italian, etc.). > > Is ck-ledger already i18n compliant? > > Thank you very much, > Davide > -- > Davide Barbieri - pa...@pr... > "Gli amici si vedono nel momento del reboot" |
3 messages has been excluded from this view by a project administrator.
