Scheduled invoices - slots

[Derek Atkins]

Lionel Elie Mamane <lionel at mamane.lu> writes:

> I fear that we'll have nasty unexpected side-effects:
>
>  - If an invoice is deleted, we have a dangling pointer. So, we need
>    to update the "delete invoice code" so that it checks that it is
>    not the base for a scheduled invoice.
>
>    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!

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.

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. :)

>  - 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?  It wouldn't be that hard to check and warn the
user "this invoice is being used as a template".

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

Why?

>  - 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.  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.

> 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.  Invoices are already "outside" the
CoA and other financial data, so they are already "special" in the
same way that template transactions are special.  So I don't see why
we need to create yet another "special" special invoice.

>   If I follow the model of the template transactions, a template
> invoice would be an invoice that sits in <gnc:template-invoices> (or
> <gnc:template-generic_term_for_invoices_and_bills_and_other_stuff>),
> and whose splits have a <slot> child like:
>
[snip]
>
> One thing I don't understand currently is what a "slot" is. Why have
>
> <slot>
>   <slot:key>account</slot:key>
>   <slot:value type="guid">c533a0e91262752c9e0a3607f44a0b62</slot:value>
> </slot>
>
> and not
>
> <suitable-prefix:account type="guid">c533a0e91262752c9e0a3607f44a0b62</suitable-prefix:account>
>
> ? What's the difference?

A slot is part of a kvp.  The template transaction is using a kvp
because it cannot use a real transaction or real split storage
mechanisms.  You cannot set the "account" directly because, well, it
would then attach the transaction to a real account which would
invalidate the fact that it's a template transaction.

For invoices this is NOT the case -- which is why I maintain we do not
need "template invoices".  For invoices, the fact that you're attached
to an account has no meaning until you actually post the invoice, and
even then it just creates an "invoice transaction" -- not a direct
mapping from the itemization to the CoA.

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, and
much less work than creating a new type of "template invoice".  So,
convince me why you need to duplicate this functionality?

> Lionel

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available