Importing Revisited

[Perry Smith]

Let me try...

blfs,

Lets assume everything you have said is correct.  How would the program 
that reads in the "flat text file" know when the check number stops and 
the payee starts?  How would this program know where the payee stops 
and the amount starts?  How where the program know which field is the 
check number and which field is the payee? etc.

You might separate the fields with commas or colons, or pipe symbols.  
You might agree with yourself to put the fields in a particular order.  
But as soon as you do, you no longer have a simple flat text file.  The 
file now has a format -- a structure.

Its not that an xml file or a qif file is magic.  They are both just 
files of characters.  They are no "binary" files in any sense at all.  
You can look at or edit them with any text program you like.  But they 
are "structured" in the sense that there is something that allows a 
parser to know where one field stops and another field begins.  There 
are marks that identify which field is which.  etc.

Does that help?

On Jul 30, 2004, at 9:03 PM, Wiggins d'Anconia wrote:

> blfs wrote:
>> This can be implemented in a gazillion different ways,
>> but in the end there should be data in the program
>> that resembles
>> struct check{
>>     char *number;
>>     char *payee;
>>     char *amount;
>>     char *memo;
>>     char *etc;
>> };
>> Now what I am not understanding is why is it not trivial
>> to import flat text data into this program.  There are two possible 
>> explanations.  The first being that
>> there is no such animal as a check in the program.  At
>> least not one that resembles the structure above.
>> The second is the concern that just importing a bunch of
>> checks would throw the ledger out of balance.  Usually programs 
>> handle this by having a post function in the program.  The checks 
>> dont go to the GL until they are posted.
>> Can someone please enlighten me here.
>
> The point is still that gnucash is based on double entry accounting. 
> At the very least you need to have something similar to,
>
> struct transaction {
>    acct *debit;
>    acct *credit;
>    char *amount;
>    ....
> };
>
> The key being that there has to be an entry into multiple accounts, 
> and there has to be some meta data to initially create the accounts 
> for the transactions to be entered into, that is not even talking 
> about various currency differences, account types, non-trivial 
> transactions (aka transactions that may be across more than two 
> accounts, such as salary -> actual pay, taxes, soc. security, etc.). 
> So then your structure becomes even more complex because you can have 
> an arbirtrary number of debit/credit accounts... blah blah blah.   
> Still comes down to the fact that you have to have a way to represent 
> all of this, and generally single lines in a flat text file won't 
> work.
>
> Having said that, what everyone has said is that it will work, you 
> just have to make sure that there is enough data in the flat text file 
> to map to the type of structures that GnuCash uses, and then write the 
> filter.  It isn't that it can't be done, its that you are the only one 
> that understands the format you have and what information would map to 
> which parts, not to mention you are the only one that has the 
> motivation to do it since everyone else appears to prefer (or use) 
> QIF, etc.
>
> At this point I think the discussion has gone long enough, if you 
> don't trust the developers are correct, then that is the beauty of 
> open source, prove them wrong.  By the way I am not a GnuCash 
> developer, just a listener standing by...
>
> Soon to have Perl questions ;-)....
>
> http://danconia.org
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>