On 9/13/2012 8:02 AM Ben Finney said...
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?
The only standard I'm aware of is the EDI specification which I first
encountered in the mid 70's and which is updated routinely. The full
spec is the size of a telephone book (do they even still make those?)
and both trading partners select from it the documents they intend to
exchange. The back end integration is then left to both parties. If
your data structure is sufficient to supply the content expected in the
EDI specs for the documents you'd expect to exchange you should be OK on
your database model.
Unfortunately, the spec resembles the RS232 spec in that it leaves the
details as an implementation issue to be settled between the two trading
partners. Another problem is that the spec is privately (through an
association) controlled and I've often had issues getting my hands on
the proper documentation when I wasn't working with a trading partner.
(I didn't want to pay the association fees to join and thereby gain
access to the documentation directly.)
There's a good overview at http://www.linktionary.com/e/edi.html
HTH,
Emile
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?
--
http://mail.python.org/mailman/listinfo/python-list
