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