sales tax & more

[Jennifer R. Garrison Stuber]

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 <linas@linas.org>
To: <cbbrowne@acm.org>
Cc: <gnucash-devel@gnucash.org>
Sent: Friday, June 07, 2002 6:05 PM
Subject: Re: sales tax & more


> On Thu, Jun 06, 2002 at 06:13:58PM -0400, gnucash@cbbrowne.com was heard
to remark:
> > On Thu, 06 Jun 2002 17:00:49 CDT, the world broke into rejoicing as
> > linas@linas.org (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!) <linas@linas.org>
> PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>