Scheduled invoices - slots

[Lionel Elie Mamane]

On Fri, Dec 19, 2003 at 10:09:08AM -0500, Derek Atkins wrote:
> Lionel Elie Mamane <lionel at mamane.lu> writes:

>>    I realise now that deleting an invoice is not possible. It think
>>    it should, at least if it is not posted (maybe never has been
>>    posted) and is the "last one". It permits the user to say "oh
>>    no, I didn't want to create an invoice, cancel!". (Whether it is
>>    possible to do in a safe manner is another question)

> See, I disagree.  You have an opportunity to cancel the invoice
> during the "create invoice" process.  When you're setting up the
> invoice you can hit "cancel" and the invoice will not be created.
> But once you create it, why should you be able to destroy it?  That
> could result in lost data!

Any delete operation could result in lost data. But deleting a
transaction is possible. Unix has an unlink() system call, and a
/bin/rm that calls it.

And frankly, deleting an invoice that has never been posted (or where
the user already has explicitly taken the "dangerous" action to unpost
it), the "lost data" is minimal.

> I think it's much easier to just mark it "invisible" so it doesn't
> actually show up in the standard queries and then all will be happy.

Its number won't be re-used, then. Leaving a "hole" in your numbering,
which my small-business running family tells me is a big
no-no. Numbers should be consecutive, and strictly increasing
temporally (a later invoice has a bigger number than a previous
invoice).

> Don't forget that you can always just re-use the invoice -- change
> the owner and clear all the items.  Voila!  You've got yourself a
> new invoice. :)

Hm. So I have to hang a note on my screen to remember that the next
time I want to do an invoice, I have to recycle that old one. If there
is more than one accountant working on this, I have to hang notes on
the other's screens. Doesn't sound very user-friendly to me.

>>  - I don't think it would be good UI that the scheduled invoice
>>    silently changes because some other invoice is modified. Or should
>>    the "edit invoice" function check that no scheduled invoice depends
>>    on the to-be-edited invoice?

> Well, I think the 'schedule invoice' should be tied to the 'edit
> invoice' in the first place.  You have to be able to edit the
> scheduled invoice somehow -- why create a completely separate
> interface to do it?

If we can use one interface to do both, then the better. But we at
least need an UI element that lists the scheduled invoices, because we
can't expect the user to remember what invoice serves as 'master
invoice' for the scheduling. An 'is a master for scheduling' choice in
the "find invoice" dialog would be enough. But the idea to have the
scheduling as data attached to the invoice starts to make sense.

What I insist on is a "clean mental model" for the user. I see
essentially two models:

 - A scheduled invoice is something completely external to the invoice
   system. It creates invoices. Editing scheduling data is working on
   *another* object than an invoice.

   Scheduling happens in other dialogs than creating / editing
   invoices. That's the model the scheduled transactions have taken.

 - The scheduling is data that is part of the invoice itself. Editing
   scheduling data is just like editing amounts / client to be
   invoiced / ...

The first approach is inherently more powerful, because as an external
object, a template invoice can be a layer of abstraction upwards. It
can contain a list of clients to invoice (not just one), it can
contain formula's (whose result depends on the phase of the moon, the
Dow Jones index, inflation rate in Sudan, ...) for the amounts, ... It
is also more difficult to use, because of this added complexity.

The second approach is more limited, because the scheduled stuff *is*
the invoice, lives on the same abstraction level. If an invoice can
only have a fixed amount (not a formula), then the "later instances"
will have the same amount. It can be only *one* client. (Unless we
change the very notion of what an invoice is, but we cannot go very
far in this direction: An invoice *must* have a fixed amount that
doesn't depend on data that might become available later. In
accounting practice, there is no notion of one invoice sent to many
customers, so one invoice = exactly one client is a requisite.)

As long as we don't take something that is a mix between the two
models, I'm fine with it.

> It wouldn't be that hard to check and warn the user "this invoice is
> being used as a template".

OK.

>>    It would really be confusing for the user if scheduled invoices
>>    depend on a 'real' invoice and transactions do not.

> Why?

Consistency. Principle of least surprise. Why do scheduled invoices
and scheduled transactions behave so differently? This will bite users
that are used to one, and start using the other.

Unless the UI makes it clear. Yes, I start to believe it makes sense.

>>  - What if the invoice the scheduled invoice is based on is unposted?

> So what?  So you auto-post it after you copy it?  What's the big
> deal?  Or you just require it to be "posted".  However I can see
> where that might not be a good idea in all cases, so you need to
> store the post-to account with the schedule data.

And scheduled invoices just got even more confusing for the user. Some
invoicing data is inherited from a "master invoice", but some other
not. This is a mix between the two models, and feels confusing to me.

> I can also see how you might want to use a single template for
> multiple customers, so you may need to store the customer
> information as well.

And then different customers get different amounts, so we store the
amounts in the scheduling data, too?

This starts to look a lot like a "template invoice" to me :-)

>> I think creating a "template invoice" data structure is really what
>> we need.

> I still disagree.  I'm willing to be convinced otherwise, but I'd
> like to see some technical reasons why.

My reasons are not technical, they are user-oriented. I want a clean
mental model for users to think about what they are doing. Now that I
have realised that your approach fits in a clean mental model, I'm OK
with it.

A more technical reason would be to make the cool things I have
mentioned before possible.

The situation now is:

 - I have a clean mental model to think about your approach

 - This simple approach fulfils my needs.

So I'm willing to implement that simplified approach: Less work for me
(as the developer). Enhances the chances I actually finish this in the
limited time I have available.

>> One thing I don't understand currently is what a "slot" is. Why have

>> ? What's the difference?

> A slot is part of a kvp.

KVP? Google, google. Ah, OK, extension mechanism. XML re-implemented
on top of XML because XML wasn't flexible enough. I see.

> So you can create invoices without touching anything.  An unposted
> invoice is just floating out there in the ether, completely detached
> from anything truly financial (just like a template transaction).
> Sure, it's a small UI change to let the user know they're editing a
> "template invoice" vs. a "normal invoice", but that's EASY to do,

If I understand your past statements correctly, an invoice would be
*both* a "normal invoice" and a "template invoice", not one *or* the
other.

In my second model "let the user know (s)he is editing a 'template
invoice'" would simply be a toggle button 'repeat this' and
information filled in (end date / repetition rate / etc). Do I get my
idea across?

> and much less work than creating a new type of "template invoice".
> So, convince me why you need to duplicate this functionality?

I wanted to "duplicate" it because in my view (first model) it was to
be something more general, one level of abstraction upwards. Second
model suits me just fine, and I'm going to do that.

One thing that's left to discuss is: What will the invoices created by
the scheduling look like?

 - A normal invoice without scheduling?

 - A normal invoice without scheduling plus a note "this invoice was
   created by the scheduling of invoice N° XXX", with eventually a
   button to edit this "master invoice"?

 - An invoice with the note "this invoice was created by the
   scheduling of invoice N° XXX", and possibility to edit the
   scheduling? Thus making the scheduling information shared between
   the master invoice and its instances. This sounds not so good to
   me, because it makes it unclear which one is repeated / scheduled,
   which one is the master and which one is the instance.


On the GUI side, I'm somewhat lost. Practical example: How do I know
what happens when this or this button is pressed? I've looked at a
Glade tutorial, it says the callbacks are configured in the "signals"
pane of the properties window of this widget. Except that for most of
your buttons, this thing is empty! (Example: sched-xact.glade,
"Scheduled Transaction Editor", OK button. Or "Scheduled Transaction
List", New / Edit / Delete).

I'm also heading for a purely no-confirmation scheduling, because
simpler, suits my needs and to ask confirmation, I need GUI
programming and previous paragraph.

-- 
Lionel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20031221/a2cd64ad/attachment-0001.pgp