Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #29037 > unrolled thread

Guides for communicating with business accounting systems

Back to article view | Back to comp.lang.python

Contents

  Guides for communicating with business accounting systems Ben Finney <ben+python@benfinney.id.au> - 2012-09-14 01:02 +1000
    Re: Guides for communicating with business accounting systems Chris Angelico <rosuav@gmail.com> - 2012-09-14 01:30 +1000
      Re: Guides for communicating with business accounting systems Ben Finney <ben+python@benfinney.id.au> - 2012-09-14 16:28 +1000
        Re: Guides for communicating with business accounting systems Chris Angelico <rosuav@gmail.com> - 2012-09-14 16:36 +1000
          Re: Guides for communicating with business accounting systems Walter Hurry <walterhurry@lavabit.com> - 2012-09-14 14:54 +0000
    Re: Guides for communicating with business accounting systems Emile van Sebille <emile@fenx.com> - 2012-09-13 09:16 -0700

#29037 — Guides for communicating with business accounting systems

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

[toc] | [next] | [standalone]

#29043

On Fri, Sep 14, 2012 at 1:02 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> 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?

Not a guide per se, but a keyword to look for: ACID compliance. You'll
be maintaining multiple pieces of information that depend on each
other (simple example being a ledger table showing transactions and an
accounts table holding balances), and you need to guarantee that the
database is consistent.

Log aggressively. I'm sure nobody would ever dream of maintaining
customer balances without an associated ledger showing how that
balance came to be; it's less obvious but just as helpful in many
other areas. If anything happens to corrupt your data, you should be
able to recognize from internal evidence that something's wrong.

GST isn't particularly complicated, but again, be really REALLY clear
what's going on. It's better to be massively verbose in the database
and then squash things down for display than to be left wondering,
when you trace back through things, what money went where. Be aware of
your ninths/elevenths; when there's 10% tax in a $10 item, the ex tax
price is $9.090909... which will annoy everyone with 1c errors.

Don't use MySQL. :) Okay, that's hardly a *rule*, but it's a strong
recommendation.

ChrisA

[toc] | [prev] | [next] | [standalone]

#29126

Emile van Sebille <emile@fenx.com> writes:

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

Thanks, that's something to look into. And yes, in Melbourne we're still
getting phone books delivered.


Chris Angelico <rosuav@gmail.com> writes:

> GST isn't particularly complicated, but again, be really REALLY clear
> what's going on. It's better to be massively verbose in the database
> and then squash things down for display than to be left wondering

Good advice, if depressing in its prospects.

> Don't use MySQL. :) Okay, that's hardly a *rule*, but it's a strong
> recommendation.

That's another struggle we have in our future, unfortunately.

-- 
 \       “If we listen only to those who are like us, we will squander |
  `\   the great opportunity before us: To live together peacefully in |
_o__)            a world of unresolved differences.” —David Weinberger |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#29128

On Fri, Sep 14, 2012 at 4:28 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> Don't use MySQL. :) Okay, that's hardly a *rule*, but it's a strong
>> recommendation.
>
> That's another struggle we have in our future, unfortunately.

We moved from MySQL to PostgreSQL a little while ago, and haven't
looked back. I used to automatically think of MySQL when discussing
open source databasing (I've also used DB2, but not in any OSS
context), but just as there's no reason to instinctively reach for PHP
when you want a dynamic web site, there's no need to naturally grab
MySQL.

Actually I haven't used Postgres with Python yet. Should probably do
that at some point. But the MySQL bindings for Python aren't so
awesome they can't be matched by any other.

ChrisA

[toc] | [prev] | [next] | [standalone]

#29169

On Fri, 14 Sep 2012 16:36:58 +1000, Chris Angelico wrote:

> Actually I haven't used Postgres with Python yet. Should probably do
> that at some point. But the MySQL bindings for Python aren't so awesome
> they can't be matched by any other.

I have found psycopg2 excellent in every respect.

[toc] | [prev] | [next] | [standalone]

#29051

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web