I suggest an accounting text first up. My reason for saying so is a
suspicion that your terminolgy might be misleading. There is no sales
tax in Australia. There is a "value-added-tax" which in Australia is
called a goods and services tax.
The absolute reference is the applicable legislation and your accountant
should be able to point you in the right direction. I did a bit of work
in this area a long time ago for a couple of clients, one of which was
an accounting firm but it was just interfacing my own invoicing/debtors
software to various banks bpay systems.
On the (possibly) non-obvious best practice side of things I can very
strongly recommend making words in the software and the database schema
mean *exactly* the same thing as they do in the problem domain. See
Domain-Driven Design by Eric Evans published in 2004 by Addison Wesley
ISBN 0321125215. The underlying thesis is that a perfect match means
future maintainers who have never seen the software before won't get
confused due to discrepancies between the software and the real world.
In my case there is no difference between "never seen the software
before" and "haven't seen the software for a while"
ymmv :)
Mike
On 14/09/2012 8:01am, Ben Finney wrote:
Howdy all,
What material should a team of programmers read before designing a
database model and export format for sending commerce transactions to a
business accounting system?
I'm especially not wanting ad hoc advice in this thread; this is surely
an old, complex problem with a lot of ground already covered. Primers on
pitfalls to avoid and non-obvious best practices are what I'd like to be
directed toward.
Constraints:
* The shop is already written, and is maintained internally. Ideally we
would use a widely-tested and third-party-maintained solution, but
that's a struggle still ahead of us. For now, we must work with our
private code base.
* None of the developer team are have much experience with the field of
business accounting, so if possible we need to learn from the past
design mistakes of others without making them ourselves.
* Our application is operating in Australia, with the sales tax tracking
requirements that come with that. Australia-specific information is
particularly desirable.
* The business has switched to a different accounting service recently;
it may well change again soon. We want to at least consider robustness
of our shop's transaction tracking design in the face of a possible
future switch to a different accounting system.
I'm happy to asnwer questions, but I'm not about to hash out the design
in this thread; that's our development team's job.
What I want is pointers to a putative “What every programmer needs to
know about storing commercial transactions for business accounting�
general guide.
Does that information already exist where I can point our team to it?
_______________________________________________
melbourne-pug mailing list
[email protected]
http://mail.python.org/mailman/listinfo/melbourne-pug
