[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: workflow broken in 1.3

Hi, Erik, Michael,

On 04/09/2012 12:49 PM, Erik Huelsmann wrote:

On Mon, Apr 9, 2012 at 6:58 PM, John Locke <..hidden..> wrote:
We run into this as well.

I'm not sure exactly what makes AP transactions end up in the Draft
Approval screen, while AR transactions get posted immediately, but
that's probably the most useful solution that's not far from being
workable -- making recurring AR invoices and transactions not post

In my setup (blank 1.3.14) AR and AP transactions have the same workflow: fill out the screen, Save, Post as saved. Output: posted transaction, empty drafts screen.

Is yours different? My user is set up with *all* roles available in the application. Is yours?

Ok. "Post as saved" does the actual posting of the transaction -- if you save but don't post as saved, the transaction ends up in the transaction approval -> drafts screen.

Which seems like a reasonable place to put them, and exactly the functionality that I think Michael is looking for, for invoices.

Yea, there doesn't seem to be a Save button on the invoice screen. Given that there is one on the transactions screen, this may simply be an oversight. @Chris, can you tell us more about that?

> I do this in at least two tabs: one for the reconcilliation, one for
> editing the actual amounts.  I do the same thing for the credit card interest.
> That keeps me from most typing (and typing errors).  I can't do this
> anymore, because saving the transaction fails when there is a
> reconcilliation report open against it:

Well, without knowing what you're actually doing, it sounds to me like you're overwriting an old transaction which indeed shouldn't be edited anymore: after all, you reconciled, meaning that you verified the correct amount being on your credit card slip.

Ah, but this happens *during* reconciliation, not *after*. I struggled with this quite a bit when getting our books up to date -- if a transaction appears in the reconciliation screen, you're hosed, you can no longer edit or delete it. It is quite painful to fix.

Keeping the transaction un-posted, in draft state, works.

I'm wondering if I'm misunderstanding your intended result. From what I read, you intend to create a new transaction which is a copy of the old one, but with right amounts filled out. Is that correct?

My use case, which I think is just like Michael's, is that I have recurring transactions with varying amounts. There's not a good workflow for setting the amount of a particular transaction, without going in and editing, resaving, confirming that you want to save the existing transaction, then posting as saved.

And for invoices? forget about it. You have to copy as new.

I just hit a new scenario that needs an update to a posted transaction: making use of different entity credit accounts within a company. I've added a new company contact, and I want to re-associate invoices for one project to the new contact. No go.

Also had a case where we were working as a subcontractor, and now have a direct relationship with the main company -- we need to change the customer on the invoice to an entirely new customer. The thing is, they sent us a check to pay it with the original invoice number, so voiding the one invoice and creating a new one messes up the association in our system with our customers' accounting.

That one would make more sense to re-post, since it's a different customer entirely -- but I would very much like to be able to switch the ECA for a given invoice within a particular invoice.

Also, I think there's a solution around which has *exactly* the purpose to solve what you're trying to do: save a template transaction and copy that into real transactions periodically. The solution is the 'templatetrans' add-on. It's in  the LedgerSMB repository and you can browse its sources here: http://ledger-smb.svn.sourceforge.net/viewvc/ledger-smb/addons/1.3/templatetrans/trunk/.

Again, I have to refer to Chris for further details.

I definitely need to try this out. It was on my radar, but haven't had a chance to deploy it and check it out...

Why do you need to delete that transaction? Because the recurrence schedule generated a new transaction you just copied into another new one with the right figures? (I hope I'm getting it now.)

> In my ideal world, I'd much rather be able to mark the transaction as
> editable and do the final tweak of a few dozen cents on the
> reconciliation sheet...

+1 Yes! That would make the job quite a bit easier than having to manage each transaction independently -- being able to bulk update during reconciliation.

Not sure how to get there from here, though.

I understand where that's coming from. I need to think about a good solution that would suit both you and an auditor to propose to you. Let me sleep on it a bit.

Isn't the true problem here though that you can't enter the transaction in a non-local currency? Surely you should be able to reconcile a USD amount against a USD amount. My expectation would be that the USD amount is the same each time the bill comes in.

That definitely sounds like one scenario.

Another is leasing cloud resources that are charged per usage. We have this from both Amazon and Rackspace -- invoices that vary, sometimes substantially, month to month.

For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
Ledger-smb-users mailing list