We implemented an arbitrary spreadsheet language for manipulating metering data into one of our products at work. At first I was concerned, but throw in a little Lex and Yacc and it's not that bad . . .
When Derek is done with that, my house could really use a coat of paint . . . ----- Original Message ----- From: Linas Vepstas <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, June 07, 2002 6:05 PM Subject: Re: sales tax & more > On Thu, Jun 06, 2002 at 06:13:58PM -0400, [EMAIL PROTECTED] was heard to remark: > > On Thu, 06 Jun 2002 17:00:49 CDT, the world broke into rejoicing as > > [EMAIL PROTECTED] (Linas Vepstas) said: > > > On Thu, Jun 06, 2002 at 04:15:58PM -0500, Bill Gribble was heard to remark: > > > > In Texas, for example, retailers just make one report to the state with > > > > the total amount of tax collected. > > > > > depends on what you're selling. If you're selling airline tickets, > > > its a *lot* more complicated. (although the airlines usually handle > > > this for the travel agent, to keep the agent's job easy). > > > > Probably there's some happy medium somewhere in between in terms of > > complexity. > > > > If an airline wants to use GnuCash to manage their ticket sales, I think > > it would be reasonable to expect them to add some developers to the team > > Well, actually, now that you mention it .... > > The actual problem, as I remeber it from my airline-ticket-selling days, > is how to apply a rather complex billing formula: > > -- some customers get charged a tax, some don't. > -- some destinations have a 'gate fee'; many don't. > -- some fare types require a flat-rate markup, some a percentage, depending on contract > -- markups depend on the season. (departure date) > -- and, of course, seller's profit margin. > > This is something a smaller-to-mid-size travel agent might engage in; the > games that airlines play are fantastically far more complex. > > The problem with allowing the travel agents to do this by hand was (highly) > error prone, and we were constantly screwing it up (usually to the customers > benefit, and a loss to the business). I ended up writing > a module that worked out the pricing formulas automatically. > > What I'm trying to say is that I think Derek should work all weekend long, > starting right now, (and he better be done by monday), adding a feature > whereby one can add an arbitrarily complex spreadsheet-like formula to > a gnucash invoice. > > --linas > > > -- > pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> > PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 > _______________________________________________ > gnucash-devel mailing list > [EMAIL PROTECTED] > http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel > > _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
