Guides for communicating with business accounting systems

[Emile van Sebille]

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?
>