On Mon, Dec 11, 2006 at 10:21:36PM -0500, Derek Atkins wrote:
> Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
>
> >I'm not disagreeing about Invoices. AFAICT, Invoices already have the
> >design feature that I think SXs should have - they use real accounts,
> >transactions, and splits, and just note in the transaction KVP that
> >this is an invoice transaction.
>
> Not at all. An unposted invoice has no Account, Transaction,
> or Split objects.. It has references, but it uses a GncEntry
> object as the line item entries.. A GncInvoice is like a Transaction,
> and a GncEntry is like a Split, but no, it doesn't re-use the
> core engine objects.
Ah, I see. I really don't know the business code well enough to
comment on Invoices then.
> >Invoices basically reuse the engine objects. But SXs have:
> >
> >struct TTInfo_s
> >{
> > /* FIXME add notes field */
> > char *description; /* owned by us */
> > char *num; /* owned by us */
> > gnc_commodity *common_currency; /* not freed */
> >
> > GList *splits; /* list of template splits, owned by us */
> >};
> >
> >which look suspiciously like a Transaction, and
> >
> >struct TTSplitInfo_s
> >{
> > char *action; /* owned by us */
> > /* FIXME: What about the split's KvpFrame */
> > char *memo; /* owned by us */
> > char *credit_formula, *debit_formula; /* owned by us */
> > Account *acc;
> >};
> >
> >which looks suspiciously like a Split. And then the whole duplicated
> >accounts setup. I'm just saying SXs could use the real engine
> >objects, just like Invoices. The only difference is that the engine
> >has to learn that "real" SX transactions aren't _that_ real. :)
>
> Except Invoices don't either, for the same reason that it's causing
> trouble that SXes do -- it complicates all the code when EVERYONE has
> to be aware that a foo-object is really part of a bar-object. Much
> easier to just have foo object and bar object and then use KVP GUIDs
> to link back and forth.
I can see your point, but I just don't agree that the benefit of not
requiring the engine to know how to provide a list of transactions
that excludes SXs is greater than the benefit of reusing the
data-structures and constraint code.
I'm not saying the same argument holds for invoices.
> >Just to clarify, as for the GUI, I'm not suggesting that the register
> >is a good place to edit or view the SX data structure - just the real
> >transactions it would link to.
>
> Except an SX isn't a real transaction, it's a Template Transaction.
Well, I think of an SX as different from, and containing many,
template transactions, but I think your point is just that template
transactions aren't "real". My point is just that the difference
between a template transaction and a "real" transaction is 95%
semantic and 5% syntactic, and that therefore, it's better to adjust
the syntax just a little to represent both concepts than to duplicate
95% of the syntax to represent the "not real" transaction.
-chris
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
