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? -- \ “I went to a general store. They wouldn't let me buy anything | `\ specifically.” —Steven Wright | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list