Hi;
I was thinking about this some more and had a couple more thoughts to toss
out here. Part is explaining where I see LSMB going and part is trying to
make sense of Peeter's requirements (please correct any misunderstandings
on my side, Peeter).
An overview of the current status and approach:
I mentioned before the separation between entry and approval (and approval
is the point where it becomes permanent and unalterable). I guess after
talking with Erik, we may have a 1.4 bug in editing drafts. That is a bug
and we need to fix it :-).
Another thought occurred to me as well, and that is that one important
concept we may want to think about here is the difference between a journal
and a presentation of data from the journal. In paper accounting, of
course, the journal is also a prime component of the audit trail. One of
the key shifts we have been trying to make starting in 1.3 has been a shift
in thinking of ledgers as primary to thinking of journals as primary. That
is not yet complete. If the journal is primary and contains as much
audit-trail information as possible, then you can think of a lot of things
as being presentations of that event stream.
The current design assumes that journal entries, once approved, are
unaltered. Anything that is calculated based on current state is deferred
for approval. So you can edit invoices until they are approved, but on
approval COGS is calculated. This reduces the need for editing existing
transactions in ways that messes up inventory quite a bit. I am not sure
it is enough to meet Peeter's needs entirely, but it gets us quite far in
that regard I think.
Now, not everything is unalterable after approval. We do allow some things
to be edited after the fact. These include internal notes, whether an item
is subject to 1099 reporting (or equivalent elsewhere) and so forth. There
may be a few other things we may add to that. But the journal basically
represents a tagged series of approved financial events of record.
Something like tax reporting status is a good candidate for something that
is editable after the fact. Number of items sold is not.
My understanding of Peeter's needs:
As I understand it, Peeter's needs boil down to four things:
1. Efficient workflow for dealing with data entry errors. At this point I
don't know how much the approval stage buys us there.
2. Ability to hide data entry errors from customer. There are legitimate
reasons I can see for this (for example, it makes it easier for the
customer to reconcile their books). We need a solution to this problem.
3. Ability to handle incomplete information on an invoice. I think we can
handle this though if you want to print the draft invoice some light
customization is required.
4. Tax period vs invoiced period for invoice. We need a solution here.
5. Ability to show or hide invoices for tax reporting. We currently do
this for line-items for 1099 and equivalents (1099 is cash-basis though and
thus US-specific). We do support equivalent accrual reports though. If
this goes by line item, the tax form subsystem may already do most of the
work here and we may need to just write more tax reporting modules. If
this is per invoice, then we have some further extensions we may want to
add.
I don't have specific proposals yet because I want to make sure I
understand the needs first.
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Ledger-smb-users mailing list
Ledger-smb-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
