trouble with date when importing a just exported csv file.

David Carlson david.carlson.417 at gmail.com
Sat Jan 31 13:37:49 EST 2015


On 1/31/2015 10:57 AM, Larry Evans wrote:
> On 01/31/2015 08:43 AM, Wm wrote:
>> Fri, 30 Jan 2015 20:46:41 <mahfmj$tao$1 at ger.gmane.org>  Larry Evans
>> <cppljevans at suddenlink.net>
>>
>>> On 01/30/2015 12:26 PM, Tommy Trussell wrote:
>>>> On Fri, Jan 30, 2015 at 10:21 AM, Larry Evans
>>>> <cppljevans at suddenlink.net>
>>>> wrote:
>>>>
>>>>> On 01/29/2015 04:12 PM, Wm wrote:
>>>>>> Thu, 29 Jan 2015 14:34:44
>>>>>> <CA+E35_7AN=0Zc11Y8dWvbeaXsjkRZSwba4g3Efa+1purnO6y8w at mail.gmail.com>
>>>>>> Edward Doolittle <edward.doolittle at gmail.com>
>>>>>>
>>>>>>> Probably the fastest way to get something working would be to write a
>>>>>>> program to translate from the CSV format that your brokerage provides
>>>>>>> into
>>>>>>> QIF or something else for easier importing into GnuCash.
>>>>>> That is available for free, see my
>>>>>> ===
>>>>>> Subject: csv to qif / ofx
>>>>>> Date:    08 January 2015 21:27:00
>>>>>> ===
>>>>>> and similar
>>>>>>
>>>>>> is no one (not you, E) able to solve a problem using the tools
>>>>>> available
>>>>>> these days?
>>>>>>
>>>>> Thanks for the suggestion, Wm.
>>>>> Here's what I tried:
>>>>>
>>>>> * Went to the webpage:
>>>>>   http://csvconverter.gginternational.net/
>>>>> * uploaded file:
>>>>>     SHA1_transactions.csv
>>>>>   which contained only 1 line:
>>>>> 01-06-2015,buy more,Checking Account,1.5,100.0
>>>>>   where fields were:
>>>>> Date,Description,Transfer,Shares,Price
>>>>> * Then tried the mapping step on the web page, but
>>>>>   got stuck at the place shown in the attached .png.
>>>>>   As you can see, there's no obvious place to put
>>>>>   the Price field :(
>>>> I haven't worked with this on this level, but I seem to recall some
>>>> discussion saying the security price gets derived from the sum of the
>>>> buy
>>>> (or sell) transaction splits. In other words, you cannot just set the
>>>> price
>>>> of a security for a transaction;
>>> I also gave the number of Shares bought.  Please review the lines:
>>>
>>>>>     SHA1_transactions.csv
>>>>>   which contained only 1 line:
>>>>> 01-06-2015,buy more,Checking Account,1.5,100.0
>>>>>   where fields were:
>>>>> Date,Description,Transfer,Shares,Price
>>> In my previous post.  There, 1.5 Shares were bought at a price of 100.0
>>> per share.  That's all that's required in the register, which calculates
>>> the value of the Buy (if Shares is positive) or the value of the Sell
>>> (if Shares is negative).  The import interface should behave similarly.
>>>
>>>> it is derived from the results of the
>>>> splits in a fully-formed transaction.
>>>>
>>>> If my memory is wrong, my apologies.
>>> No problem.
>> It might help to think of it this way.
>>
>> In a test book use your lottery winnings to make a transfer from
>> equity:lottery to assets:share1 [1]
>>
>> you can also buy some assets:share1 using expense:share_purchases or
>> income:share_reinvestment and so on
>>
>> in gnc the expense, income and equity account types deal in money; lots
>> of different kinds of money called currencies but only money [2] not
>> units of something that isn't money.
>>
>> So, the obvious way of getting your transactions in and out is through
>> amounts of money.
>>
>> Presuming you don't have thousands of these them it becomes a simple
>> matter of adjusting the not-pure-currency (i.e. there was a number of
>> frog-legs or bags-of-recycled-paper) involved via an amount of money
>> which could, theoretically be an arbitrary 1.  But I'd suggest a best
>> guess at a realisable value is better than 1.
>>
>> Have I made things more or less confusing? :)
> Thank you for the explanation, Wm.
>
> However, my aim was to make the import process mirror the interactive
> entry of a transaction as done in the "Checkbook-Style Register":
>
> http://www.gnucash.org/features.phtml#main-feat
>
> And the actual register used would depend on which account was being
> used as the target of the import.  IOW, for a stock, it would be
> as shown in the 8.7.1 Example here:
>
> http://www.gnucash.org/docs/v2.6/C/gnucash-guide/invest-sell1.html#idm242253328896
>
> Or, in the particular case in this thread, like that shown here:
>
> http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20150129/9f0f0f99/attachment-0003.png
>
> IOW, if, instead of the column types choices being as shown in:
>
> http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20150129/9f0f0f99/attachment-0002.png
>
> they were:
>
>   None
>   Date
>   Num
>   Description
>   Transfer
>   R
>   Shares
>   Price
>   Buy
>   Sell
>   Balance
>
> Then the import would behave similar to the register, except it wouldn't
> be interactive.  For example, if all fields except:
>
>   Num, R, Buy, Sell, Balance
>
> were specified, then the import would mirror the interactive input to
> the register.
>
> This is what was proposed on the devel list here:
>
> http://lists.gnucash.org/pipermail/gnucash-devel/2015-January/038489.html
>
> IOW, if it can be done in the register, it can be done in a similar way
> in the import.
>
>>
>>
>> [1] mention of SHA1 consistently distracts my thought processes to
>> something other than stocks and shares
> I got that name from some Gnucash example.  I can't remember where.
> I guess it's short for SHAre from stock_1.
>
> [snip]
>
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>

Larry,

I am happy to see that you are looking seriously at the CSV import
process.  Please continue.

The CSV files that one of my brokers provides has "Date" "Source"
"Transaction" "Investment" "Amount" "Price" "Shares/Units" as headers. 
I do not know what other brokers provide.

It also breaks up sale transactions over two lines with the profit or
loss in a separate line.  Commissions and fees are also in separate
lines, not clearly associated to a security other than by sequence in
the file. 

Consider that (1) The Amount and Shares cannot be rounded in the
register after the import is complete, (2) Some users will track
commissions and fees as separate split lines within the transaction and
others will take net values and ignore commissions and fees, and (3)
Profit or loss amounts must be accounted for in closing transactions
that are not always sales to make the books balance.

Your solution must be able to handle these situations and possibly other
variations (including missing data) as well.

David C


More information about the gnucash-user mailing list