QSF Import of gncCustomer and gncInvoice

[Georgi Mirchev]

I do understand your point of view, but my idea is to get results out of 
the door. Doing everything right will be a lot of work, and I'm not 
prepared to do it all. At least not now.
The current code has a lot of things implemented, and with several bug 
fixes and with 50-100 additional lines of code I achieved the following:
1. import of gncCustomer, gncAddress, gncInvoice, gncEntry and Account
2. referencing between the the imported objects so that all of them are 
connected - i.e. the addresses belong to customers, the entries belong 
to invoices, the owner of the invoice is a customer and each entry 
references an account
The referencing between imported and target book is not complete, so all 
of these have to be imported in one file. But it WORKS.

I'm preparing patches now, in case someone finds the code useful. If you 
choose not to import all patches, you can import only the bug fixes and 
the correct code, and leave the code that is some kind of hack out. Thus 
it could be at least partially integrated into gnucash.

The code really has a lot of issues, and is far from ready, so this 
really is a distraction for 2.0. Thus I'll submit some entries in the 
bugzilla with the patches attached, so that they can be handled after 
2.0 is out of the door.

Derek Atkins wrote:

>Georgi Mirchev <manager at mirchevideas.com> writes:
>
>  
>
>>It turned out that I just can't use the same parameter for the invoices. 
>>The "owner" param returns gncOwner object, and is used by the rest of 
>>GnuCash, so nothing can be changed here.
>>Instead I added "owner-qof" that is of type QOF_TYPE_CHOICE, and works 
>>with entities. It works fine with customers, and will work fine with the 
>>other 3 objects that can be owners of an invoice. The import of 
>>customers/addresses works fine now.
>>    
>>
>
>I still don't think that's the right answer...  I have no objection to
>changing the definition of a GncOwner (although you DEFINITELY need to
>be careful about how it's done, because if done "incorrectly" it will
>take a LOT of effort to change the code everywhere where it assumes it
>knows how a GncOwner is implemented).
>
>  
>
>>I'm working on the collections now, so that I can import the invoice 
>>entries. In order to get any entries in, I had to add a kludge. The QOF 
>>iterates over all parameters of the imported object, calling their 
>>getters and trying to determine the time. Guess what happens when the 
>>getter doesn't actually return an entity, like in the case of parameter 
>>that is of type gncOwner. So the QOF book merger code now checks 
>>specifically for "gncOwner". Kludge, but works. Unless we add additional 
>>param flag "has QofInstance", so that it is compatible with QOF, or  we 
>>add dummy QofInstance to gncOwner, I can't see how to resolve that.
>>    
>>
>
>... and this is DEFINITELY not the right answer.  We shouldn't
>special-case anything inside QOF.
>
>  
>
>>There is an issue that seems to be a little more complex. During the 
>>merge of two books the entries from the first are "copied" into the 
>>second, then the first book and it's entries are destroyed. The problem 
>>is that the "copy" often is just pointer copy. The reason is that 
>>although we have clone functions in the gnc objects, the QofObject 
>>doesn't specify a 'clone' callback, so QOF cannot clone any objects. I 
>>think this needs to be added, so that QOF can safely clone an object 
>>whenever needed.
>>What do you think?
>>    
>>
>
>I think, as Chris said, that these APIs are only half baked and really
>require a lot of thought and effort to make work correctly.  I would
>recommend you sit back and come up with a reasonable design before you
>jump head-first into coding it up.  come up with a page or two
>describing how you think it should work.  Be detailed, but not
>loquatious.
>
>Once you have a design we can talk about the merits, work that out,
>and then you're welcome to go full-bore into it.
>
>Keep in mind that we're really trying to get 2.0 out the door, so
>don't expect many cycles on something like this which really is a 2.0
>distraction.
>
>-derek
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: manager.vcf
Type: text/x-vcard
Size: 527 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060602/5a9f36c7/manager.vcf