Importing payroll information

R. Victor Klassen rvklassen at gmail.com
Thu Jan 16 21:28:00 EST 2014


Well, because I wrote the code to generate the payroll records, I have the memo fields for the splits contain descriptions that correspond to the various deductions, so that I don’t need to generate a separate pay stub, but can use the one that my custom cheque format for gnu cash generates.   It would be nice to get rid of the blank line, and had I more time to spend on it I might actually figure out how to modify the GNUcash code to do so - possibly by extending QIF so that nothing changes unless a magic new entry appeared in the QIF.   Having perused the code some, in an effort to figure out what it wanted as input, I don’t feel I have the time to figure it out just now.

GNUCash doesn’t handle payroll.  And what I’ve done is only enough to handle the easy cases in my jurisdiction.  It works for us, since we hire mostly students and pay little more than minimum wage.   So I only need to handle one tax bracket (I do check to make sure that is always sufficient).  The complexity of handling all possible jurisdictions is daunting.  Over the course of the year I expect to refine it so as to be able to generate the reports I need.

At this point I consider the matter closed, but will entertain questions, if there are those who wish to learn more about what I’ve learned along the way.


On Jan 16, 2014, at 6:38 PM, David Carlson <david.carlson.417 at gmail.com> wrote:

> On 1/16/2014 9:25 AM, Derek Atkins wrote:
>> Oh, right, the QIF Importer will put the M field into the Transaction
>> Notes field, not the Split Memo, assuming you also have a P field. If
>> you don't have a P field then it will promote M to the Description.  You
>> are right that there may not be a way to populate the "main split" memo
>> field.
>> 
>> -derek
>> 
>> "R. Victor Klassen" <rvklassen at gmail.com> writes:
>> 
>>> Not clear to me just how it supports it.  Perhaps you have a different
>>> spec that explains it to you, but I’m not finding it in the Wikipedia
>>> spec.
>>> 
>>> Putting it in the M field appears to have no effect.  
>>> 
>>> 
>>> On Jan 15, 2014, at 11:01 AM, Derek Atkins <warlord at MIT.EDU> wrote:
>>>> I don't understand your issue.  Just supply a memo for the "default
>>>> split".  QIF supports that!
>>>> 
>>>> -derek
>>>> 
>>>> -- 
>>>>      Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>>>>      Member, MIT Student Information Processing Board  (SIPB)
>>>>      URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>>>>      warlord at MIT.EDU                        PGP key available
>>> 
>>> 
> I used to think that all 'automatic' methods of transaction generation
> intentionally left the transaction notes field blank because there was a
> plan in the future to fill that field with the contents of the current
> account register split memos, similar to the way Accounts Receivable
> transactions are displayed. 
> 
> I know that field is not copied from the source transaction when a
> scheduled transaction is created by copying an existing transaction.  I
> also note that when the OFX importer imports transactions it tends to
> fill that field with import status notes rather than actual transaction
> text, at least when importing files from my banks.
> 
> As to the existence or not of a QIF 'Spec' , I think that Intuit always
> considered it to be their property, and when they stopped supporting
> that method in their 'Quicken' product line, they removed their
> documentation from their website.  Thus whatever can be found on the
> Internet today should be considered 'hearsay' rather than 'official'.  I
> think that is why it is difficult to impossible to find out how some of
> the more esoteric transactions such as stock or option purchases, sales,
> short sales, etc. should actually be formatted to import correctly into
> any financial program, be it Quicken or any other third party software. 
> For what it may be worth, I think that Moneydance seemed to have it
> figured out when I tried their software several years ago.  That is a
> subscription product, and I am not endorsing it.
> 
> David C
> _______________________________________________
> 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.



More information about the gnucash-user mailing list