gnutaxes-dev

[Gnutaxes-dev] CUSTOM WEB BASED ACCOUNTING AND TAX PREPARATION APPLICATION

[BSH A. S. Inc. <bs...@so...>]

My name is Steve Emerson and I own and operate an accounting services =
company located in Hamilton, Alabama.  I am looking to implement a web =
based bookkeeping software application that I would provide for my =
clients.  My clients would be able to access my website through the =
internet and view their accounting information and eventually my retail =
clients could possibly "scan in" their sales, similar to large retail =
stores.  I currently use MAS 90 software by Sage Software, Inc. ( =
www.sota.com ) and I would like the web based application created to use =
the MAS 90 program and data files.  I am also looking at using Tax And =
Accounting Software Corporation's software (www.taascforce.com ).  I =
have found a few companies that use a web based application similar to =
what I would like to implement.  These are www.tadonline.com .  If you =
want to check out the demo of this program, you can use my user name and =
password.  These are :  Username - BSH and Password - 8687.  The other =
four companies are www.virtualgrowth.com , www.netledger.com , =
www.imageglobe.com and www.interacct.com .

I would also like a web based software application for my tax =
preparation software.  I am currently using TaxWise by Universal Tax =
Systems, Inc. out of Rome, Georgia.  You can find more information on =
this company and their products at www.taxwise.com .  This web based =
application would be similar to H & R Block ( www.handrblock.com ), =
TurboTax ( www.turbotax.com ) and PrepTax ( www.preptax.com ).

I would be interested in custom accounting and tax preparation software =
designed by your company, if you can design such software.

I would like to have my web server in a co - hosting facility.  I am =
currently talking with Eddie with Super Servers out of Atlanta, Georgia =
( www.sswh.com ) about his co - hosting service.  If you have any ideas =
on this, please let me know.

I currently have two non-networked Gateway E-5000, G6-300 workstation =
computers running Windows NT Workstation 4.0.  I had these computers =
custom built through Gateway at the beginning of 1998.  I would like to =
network my workstations within my office to a central database (server). =
 I would like to have the option of upgrading and I would be interested =
in a leasing program.

You can contact me any time for more information and with your questions =
about my ideas on this project.

Thanks,

Steve Emerson
President
BSH Accounting Services, Inc.
P.O. Box 280
3041 County Highway 42
Hamilton, AL  35570
(877) 684-8483 ext. 1
(877) 684-8485 (FAX)
www.bshaccountingservices.com
www.domybookkeeping.com
www.domytaxesnow.com

[Gnutaxes-dev] Re: GnuTaxes...

[Jim P. <jph...@er...>]

Below is a reply from myself to Pehr Anderson who had some questions
regarding the portability of gnuTaxes.  I thought my reply did a pretty
good job of describing the relationships between the processing engine and
the user interface.  So here it is in case anyone else was wondering.

- Jim

Jim Phillips wrote:

> pehr anderson wrote:
>
> > Dear Jim,
> >
> > GnuTaxes is a great idea! I love it.
> > You mention Gnome, KDE & Motif front ends.
> > I strongly encourage you to clearly define
> > an implementation path on your website.
> > The best open source projects use the
> > benevolant dictator model. You must be
> > willing to dictate!
> >
> > >From what I know of the history of the Gnucash project
> > there were major issues resulting from confusion
> > over which development tools were and were not allowed.
> > Ideally a project has as few dependencies as possible
> > and follows a single path to completion.
> >
> > Once a vibrant and robust development community
> > is built up, then a project can start flushing out
> > alternative inerfaces and such.
> >
> > To meet your end-goals of cross-platform sufficiency,
> > you really only have two options, Java or Python.
> > Python has a built in gui called tkinter based which
> > uses TK/TCL. Python is definitely the path I recommend.
> >
> > C is portable but compilation environments are different
> > once you get outside of unix.  Python works
> > transparently on Windows, Linux, Unix, & MAC.
> >
> >         -pehr
> >
> > Good luck! and thanks for adding to the pool.
>
> Thanks for your advice, but I _sort_ of disagree with you.  Several of
> your comments I do agree with, but as far as the platform independence
> mechanisms, I'm pretty sure we'll be able to do it the way I'm currently
> envisioning.  Here's what I'm thinking (and I'll point out another
> project that does pretty much the same thing - www.jabber.org).
>
> The bulk of the programming logic will have no knowledge of a user
> interface.  This will be the part that actually parses the forms,
> computes the values, merges the data with the PDF files, and transmits
> the data to the eFile system or whatever other electronic clearing
> house.  All of this functionality will be coded in standard ANSI C in a
> manor that is as easily portable as possible.
>
> The other part of the application is the interview system.  This is
> where the platform dependence and need for multiple clients show
> themselves.  I actually _want_ clients written for a specific platform
> because I personally hate having to use applications that are designed
> to be cross-platform compliant.  I prefer to use applications which take
> full advantage of the features my environment offers.  And you just
> can't write a good cross-platform application that still takes full
> advantage of the specific features of a particular platform.  But at the
> same time, I do want to have some control over the creation of the
> clients.  So the gnuTaxes library I spoke about before will expose a
> very specific API for handling the interview.  The only thing that the
> client should be doing is displaying dialogs and gathering user input.
> So the API will have essentially two functions.  read_dialog (); and
> write_data (); (or something like that).  The read_dialog function will
> be the clients way of asking the application for the next dialog to
> display (it will be returned as an XML document structured very much
> like the <dialog></dialog> block already defined.  The client will then
> parse and display that individual dialog and wait for user input.  Once
> the user inputs data and clicks a button, the client will call
> write_data (); and send the data back to the application in a second XML
> document (which I haven't yet defined).  That's it.  That's all there is
> to the GUI.  Basically just something that knows how to parse a specific
> XML document and display that as a page of a wizard, and something that
> can create an XML document from a few input fields.  By doing this it
> should be extremely easy for people to write a large number of different
> client GUIs that take advantage of whatever platform their written to.
>
> Somewhere down the road, I might want to expose some more advanced
> options to the clients, such as the ability to display the tax form
> graphically as it's being filled in, or '']he ability for the user to
> hop around inside the interview without having to use the "Back"
> button.  But that's a long way off.
>
> As far as any portability issues between *nix and Win32, my way of
> thinking is that Win32 already has gobs of tax programs, so I'm not too
> concerned, but we'll probably use something like Cygwin to port it
> anyway and then someone can write a GUI to take advantage of the
> features that Win32 offers.  As for other systems such as BeOS or MacOS,
> or other non-*nix OS's, well, again the primary target is *nix, but
> we're going to try to write our code with portability in mind.  For
> really really thin clients, we'll provide them a web interface using a
> PHP3 module.
>
> As far as using Java or Python?  Well, I'm not a big fan of interpreted
> languages.  I still am yet to be convinced that Java will have a place
> in the client niche (servers yes, but they've got the horsepower to
> handle java).  I don't know a whole lot about Python personally, but if
> it is indeed an interpreted language, the the same logic applies - that
> just requires too much horsepower.  I'd rather have highly tuned
> compiled applications which take advantage of the users environment.
> gnuTaxes will use some run-time scripting code already for computing
> values within the forms and for running custom actions in the interview,
> but I'm still undecided on which scripting language to specify -
> probably will wind up being either perl or creating our own (I've used
> javascript so far in my samples, because I know javascript from all the
> web development I've done in the past).
>
> Again, thanks for your input and hopefully, this has cleared up some
> questions you had.
>
>    - Jim

[Gnutaxes-dev] Development announcements

[Jim P. <jph...@er...>]

A couple of quick announcements:

First and foremost, I'd like to welcome Praveen Yajman onto the
development team as the first officially joined up developer.

Second, I want to point out that I've been working hard the last couple
of days to make some progress on gnuTaxes.  Specifically, I've very
nearly solidified the XML schemas.

I've also done my best do document them and online docs can now be found
at http://gnutaxes.sourceforge.net/docs which take a shot at describing
the processing system and the XML schemas.  I need someone who has
written a DTD (or XMLSchema) to take that documentation and actually
write up a DTD or Schema that any future code can be validated against.
I tried to figure it out myself but couldn't figure out exactly how DTD
works and couldn't find any good tutorials on it.

As soon as we get the schema for the interview process defined and fully
documented, we'll move to version 0.0.2 and pound out the form
definition system.

  - Jim

[Gnutaxes-dev] XML DTDs

[Jim P. <JPh...@ma...>]

Ok, I guess this is really the first message on this list intended at making
progress towards something solid.  If you've seen my very basic
interview.xml document so far you'll see that as of yet there is not a
really well defined method for scripting this out.  I haven't figured out
what a good method for doing this is.  I'm torn between two routes.  
 
The first route (and I think the sexiest route) is to define a scripting
language ala XSL such that we have a predefined API for handling just about
anything we might need to do.  It might look something like:
 
<gnuTaXSL:compute-add result="field2" value1="$field1" value2="5000"/>
The above would take the value of $field1 and add 5000 filling in the
variable $field2 with the result.
 
Of course, implementing a parser might prove tricky (I wouldn't even know
how to begin except maybe to see how the various XSLT engines do it).
Alternatively, we could set up the XML such that we can pick and choose from
all the various scripting languages out there and so something like:
 
<gnuTaxes:script language="javascript">
    field2 = field1 + 5000;
</gnuTaxes:script>
 
Suggestions?
 
 
Jim Phillips - Facilities Manager	
MATRA Systems, Inc.	
Phone:	  +1 (770) 931-0038 	 FAX:	  +1 (770) 931-0038 	
URL:	   http://www.matrasys.com/ <http://www.matrasys.com/>
E-Mail:	   jph...@ma... <mailto:jph...@ma...>

We can fix this, but you're gonna need a butter knife, a roll of duct tape,
and a car battery...	
 

[Gnutaxes-dev] Welcome

[Jim P. <jph...@er...>]

This is the first message on this list.

Jim