On Mon, Mar 3, 2014 at 11:02 AM, Benedict White <ledgersmb@ourhobbies.co.uk> wrote:

On 03/03/14 03:53, Chris Travers wrote:
> Ok, this may seem a little long-winded but it might be worth providing
> a basic introduction here.  We try to keep relatively close to the
> paper world because the techniques of paper accounting are robust,
> transparent, and time tested.
> In the paper accounting world you have journals and ledgers.  The
> journals are where you enter your transactions and the ledgers are
> aggregations of what was entered.  The general ledger is thus the
> financial side of your books aggregated from all your journals
> (general, sales, purchase, payroll, receipts, disbursements, etc).
>  You may have various special ledgers as well (showing such things as
> inventory or share ownership).
> This distinction is blurred in the software world but it is still a
> useful distinction to keep in mind.  Stuff gets entered into journals.
>  It gets presented in ledgers.  We are moving more towards this
> approach with the financial rewrite I am hoping to complete for 1.5.
> The big thing missing from the general journal/ledger is an ability to
> connect directly to any other information.  So for a few directors or
> banks who loan money, you can track who is owed using separate chart
> of accounts entries.  Misc expenses might be ok too as long as you
> don't have to track who the money was owed to and they are paid at the
> same time they are accrued.  However for expenses, I would just go
> with AP transactions against a generic vendor if they are paid right
> there.  This helps ensure that your AP reports show the expenses.

So just to clarify, I would say set up a vendor for one offs, and post a
purchase order against that?

That's what I do but there's no point in purchase orders against a generic vendor.  Just post invoices. 

How would I then pay the person who had incurred that expense on behalf
of the company?

You have a couple options.  Unfortunately we don't have a journal for that yet.  There are some workarounds in 1.4 but they are not exactly elegant and were designed in fact for paying one vendor on behalf of another.

1.  You can have a separate liabilities payment account you can "pay" the invoice against and then track who you owe money to there, for example, using source fields, and then issue a GL transaction paying off the employee, with the same source but adding a suffix (like ' payment').  This would allow you to run GL reports and determine how much was owed to whom and for which expenses, but it would be a pain to administer.

2.  You could keep a paper journal and ledger of money owed to employees, and use GL transactions for this.  Paper is far underrated for things that don't get high transaction volume or complex reporting requirements.

3.  You could pay employees on presentation of the source document, and note that in the payment source so you don't ever owe your employees a balance you have to track.

To be honest I would tend towards solution 2 or 3.

(Sorry for being a bit slow on the uptake, I am also reading a book on
book keeping as well as reading the manual)

Definitely don't apologize for that.  I've been there too.  My recommendation though is that as you do this, if you work through the examples on paper, LedgerSMB may start to make a bunch more sense.

(I still fall back on paper when working out logic of some journal entries.)

OK, but could we get an expenses claim form integrated into the system
somehow in a future version, so that it would record a debt owed to an
employee who had gone and bought something, to be reimbursed from either
a bank to bank or petty cash payment?

Yep.  It's on my radar.  Unfortunately, the pressing development on my side for 1.5 is likely to be removing the financial logic inherited from SQL-Ledger and re-engineering it.  I have started to get into it and I think it won't be as bad as I thought.   The reason I mention this is that adding something like this, although possible right now is likely to be a lot easier after that point.

If it is urgently needed, I would probably accept a paid project to do it now, but otherwise the best thing to do, if you are interested in helping ensure that it gets included in that rewrite would be to join the -devel list, where design and requirements discussions will take place during the rewrite.

I expect to commence the rewrite as soon as we get to 1.4 rc1, which should be soon now.

Best Wishes,
Chris Travers

Kind regards

Benedict White

Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
Ledger-smb-users mailing list

Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.