Guides for communicating with business accounting systems
Emile van Sebille
emile at fenx.com
Thu Sep 13 12:16:46 EDT 2012
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?
>
More information about the Python-list
mailing list