first draft of a merge rule set

Neil Williams linux at codehelp.co.uk
Thu Apr 15 09:00:16 EDT 2004


On Thursday 15 April 2004 4:23, Derek Atkins wrote:
> linas at linas.org (Linas Vepstas) writes:
> >> 1) Is this semantically the same object?  For example, does this
> >>    Account* and that Account* point to (semantically) the same
> >>    "Account"?

I started this whole import thing when I needed to import Palm data into 
Gnucash to create a new invoice. One of the principle checks was always going 
to be "Have I imported this data already?". The imported data cannot have a 
GUID initially, so one needs to be assigned but this should only be done 
after a semantic check on existing data, looking for the same job, the same 
customer, the same day of the claim etc. There needs to be a check that says 
this data is very similar to existing data (e.g. same job, same customer but 
worked the following day) but is still new. This would enable the new data to 
be added to an existing invoice rather than creating another entire invoice 
for the same customer and the same job.

> >> 2) Do these semantically equivalent objects have the same or
> >>    different data in them?
> >
> > I don't understand what your saying.  What's an example of
> > 'semantically equivalent objects' that would have different data?

Invoice ID: assigned by gnucash
Customer ID: identical
Job ID: identical
Hours worked: identical
Mileage claimed: identical
*day of claim*: previous +1.

That is a new invoice item, not a duplicate (or a whole new invoice).

> >>    This is more a question to determine
> >>    if you have any work to do once you determine that you've got
> >>    a duplicate in the import queue.
> >
> > I don't get this either.  If you've got two transactions that
> > are identical, you've got work to do.  If they are almost nearly

? If the import data is an exact match for the main data, there can be no work 
to do, once that is determined. The import data is just ignored - in code I'd 
simply delete that part of the import tree. The remaining data would then be 
appended according to content.

> > identical, you've got exactly the same work to do.  Only if

almost nearly identical -> gui box for user confirmation. Simple choice for 
user: 
Is this a duplicate?
(Yes = main overrules import, No = import overrules main).
If yes, the data is deleted from the import tree. The relevant data in the 
main GNBook is untouched.
If no, the import data is either appended or it replaces the relevant data in 
the main GNCBook, depending on the kind of data. e.g. an account name would 
have to be overwritten, a near-duplicate invoice item would be appended.

That is why the nature of the data must be retained (as meta-data) during the 
import - the function must know how to deal with the data if the import is 
subsequently allowed.

> > they are significantly different do you have to stop and popup
> > a gui to ask the user.

If they are syntactically different, you don't need any user involvement - 
this is an import, so new data is determined to be appended to the existing 
file by the very fact that the user has chosen to execute an import.

-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20040415/19d7fcdc/attachment.bin


More information about the gnucash-devel mailing list