Re: deleting draft transactions

On Mon, Jul 13, 2015 at 8:02 PM, Michael Richardson <..hidden..> wrote:

Erik Huelsmann <..hidden..> wrote:
> Heh. I'm not sure one is correlated to the other :-) . So, lets start with
> your situation: how many people are there in your business and how many are
> there in your "accounting department"?

> If the answer is - as I suspect - "I'm alone" (like me, in most of my
> businesses), then Draft versus Posted transactions are not for you. Draft and
> Posted transactions implement a principle which is called "separation of
> duties". It ensures - in companies of size "2+" - that no single person can
> cook the books (usually heavily associated with fraud).

Yeah, I thought I understood the goals --- and I agree that they generally
aren't for me. They significantly get in my way: having auto-post might be
nice.

And it exists: in the Defaults screen, set "Separate duties" to "No". After you do, all transactions should immediately post. (Note the *should*, because I've not used this mode.)

If I could do *trial* reconciliations with drafts, and then be able to edit
them... wow that would rock.

The question is, given the state of draft/posts, it's not obvious that they
actually help companies of size 2+.

Big companies don't expect draft transactions to turn up anywhere other than that they be reviewed by a second person before being posted. That goes for *every* transaction. Now, your user has all permissions so you don't notice the difference, but with LedgerSMB's permission system, you can set up users who can create transactions and others who can promote them from draft to posted. This enforces the so called "four-eye principle".

[ snip ]

> That's a bug too (registered it under
> https://sourceforge.net/p/ledger-smb/bugs/1392/). No, the (draft)
> transactions aren't a work in progress, but badly suffering from the fact
> that nobody started drawing state transition diagrams and discussing the
> required state changes before writing the code that's behind it. (It'd be
> very unfortunate if all you could do with a not-acceptable draft transaction
> is to delete it.)

okay, I'd like to help with this.

Ok. Great! I think the first step is to get a state transition diagram before diving into the code, though. Having a diagram like that helps a lot when running around in the maze that the code can be sometimes.

> I wouldn't expect these to be bugs because you entered in 1.3 and upgraded.
> I'm expecting (although I haven't verified) the same problems with
> 1.4-created transactions.

I'm considering for a number of reasons to start a new database for 2016.
I'm considering whether I should do that for Jan 1, 2015, since I've only
gotten up to March 31, 2015 today.

Ok. Surely you can start a new database, but once you have either 1.4.13 installed - which allows you to delete the draft transactions - you should be able to delete the draft transactions and complete your figures. Or are you referring to the FX schema change which you want to use as a reason to start anew? If that's the case, I can't really blame you; I'm still debating myself what the best way would be to migrate from the old to the new schema.

What I'm thinking about now is how to best transition what data I can port
directly to a new database, and how. My chart of accounts, I think that I
can re-create just fine.

When I last moved systems (from Excel to LedgerSMB), I recreated all customers. Then, I recreated all open items and inventory. Then I calculated the difference between the target balance and the actual balance in the new system and posted that in one migration transaction.

The contacts would seem to be the biggest benefit to this, and I'm thinking
also about how it might be nice to able to sync the contacts with other
systems (Gmail, bbdb.el come to *my* mind). I may work on this part.

It'd be great to have contacts synchronizable (backed up) to other cloud services! Lets discuss your intended direction and how to make your goals fit best with the overall direction for the project.

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.