QIF Import in 1.6.x

[Graham Leggett]

This is a cryptographically signed message in MIME format.

--------------msA44E479A22AFB02EF13BE011
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bill Gribble wrote:

> > When I go through the new QIF import wizard, the end result is that the
> > QIF data is imported into a brand new account, instead of applying the
> > transactions to an existing account. This new account has the name
> > "Existing Account 2" after it. It does the exact same thing for the
> > expense account as well.
> 
> this means that "Existing Account" is not 'compatible' with the account
> that you names as "Existing Account" in the QIF importer.
> 
> 'compatible' means:
>  - same Currency and Security
>  - compatible Type
> 
> and so on.  You don't want to assume that a QIF imported account with
> currency in dollars is the same as one that happens to already exist but
> has currency of Euros, for example, or that a Bank account and an
> Expense account are the same, so we change the name of the imported
> account slightly when there's a collision.
> 
> It's altogether possible that the compatibility check is failing for two
> accounts that ought to be compatible.  The way to determine that is
> first to understand what the QIF importer thought was so different about
> the account that was described in the QIF file from the account that
> already existed.
> 
> Look at "Existing Account" and "Existing Account 2" in the Account
> Editor.  What's the same and/or different about them?

When saved, the XML for the original account goes as follows:

<gnc:account version="2.0.0">
  <act:name>Straight</act:name>
  <act:id type="guid">694bd161c4e8e4a8da563c618b6b66fc</act:id>
  <act:type>CREDIT</act:type>
  <act:currency>
    <cmdty:space>ISO4217</cmdty:space>
    <cmdty:id>ZAR</cmdty:id>
  </act:currency>
  <act:currency-scu>100</act:currency-scu>
  <act:code>XXXX XXXX XXXX 6027</act:code>
  <act:slots>
    <slot>
      <slot:key>reconcile-info</slot:key>
      <slot:value type="frame">
        <slot>
          <slot:key>last-date</slot:key>
          <slot:value type="integer">1003528800</slot:value>
        </slot>
      </slot:value>
    </slot>
  </act:slots>
  <act:parent type="guid">ab28bfaf404dee5949e09216e29a8082</act:parent>
</gnc:account>

The new account created as a result of the clash goes as follows:

<gnc:account version="2.0.0">
  <act:name>Straight</act:name>
  <act:id type="guid">45d058baf4a31901b4473ce3d2b8eb31</act:id>
  <act:type>CREDIT</act:type>
  <act:currency>
    <cmdty:space>ISO4217</cmdty:space>
    <cmdty:id>ZAR</cmdty:id>
  </act:currency>
  <act:currency-scu>100</act:currency-scu>
  <act:code>XXXX XXXX XXXX 6027</act:code>
  <act:parent type="guid">08102a66afdf40d3c96e53934e2043bc</act:parent>
</gnc:account>

I cannot see anything obvious that should make these two dramatically
"different" - why would the new account be created?

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."
--------------msA44E479A22AFB02EF13BE011
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIHyAYJKoZIhvcNAQcCoIIHuTCCB7UCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BcYwggKVMIIB/qADAgECAgMEyOwwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA1MTEwMDE3NDZaFw0wMjA1MTEwMDE3NDZa
MF0xEDAOBgNVBAQTB0xlZ2dldHQxDzANBgNVBCoTBkdyYWhhbTEXMBUGA1UEAxMOR3JhaGFt
IExlZ2dldHQxHzAdBgkqhkiG9w0BCQEWEG1pbmZyaW5Ac2hhcnAuZm0wgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBALX2zJvQ/9l+sCEpkfMNNwtnMcF8vmPM2sRpibT5nR87bYWyLVCt
XXWXU+UyDOkiQJt6UahnmYZV7u40a1/osbNnjHjyNybejOuUFjHYy1gDwjsElnxYbRRA2SZc
CmrZ4V0QFI0ZKuimGryZQj77UroiIV+Qq+v+PaxDEGwiqJqnAgMBAAGjLTArMBsGA1UdEQQU
MBKBEG1pbmZyaW5Ac2hhcnAuZm0wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCO
l5bH8JXuFM+EZi01jfezzKML5iPBHx4BDj/4gl2lXw1t0v6o+9442F6TpnOVAk3LL1KTupvc
HfM+Bn71iWuD8ASCoSsmVpeoCbOv3lPGltrDgywcmM8phZyK1hHLvvJgfd4IMZbuH/rm0ZWp
WjRORFfik8yuO9DgahgjgAhkujCCAykwggKSoAMCAQICAQwwDQYJKoZIhvcNAQEEBQAwgdEx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93
bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g
U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4
MzAwMDAwMDBaFw0wMjA4MjkyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz
dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE
CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJT
QSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7Sbngn
Z4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmF
zVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ
7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwx
LTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOB
gQBzG28mZYv/FTRLWWKK7US+ScfoDbuPuQ1qJipihB+4h2N0HG23zxpTkUvhzeY42e1Q9Dps
NJKs5pKcbsEjAcIJp+9LrnLdBmf1UG8uWLi2C8FQV7XsHNfvF7bViJu3ooga7TlbOX00/LaW
GCVNavSdxcORL6mWuAU8Uvzd6WIDSDGCAcowggHGAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEV
MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRo
YXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFs
IEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwTI7DAJBgUrDgMCGgUAoIGGMBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTEyMDE5MjIyMlowIwYJKoZIhvcN
AQkEMRYEFO6ENlq7hqstlOO7y5Uh5JTO7FylMCcGCSqGSIb3DQEJDzEaMBgwBwYFKw4DAgcw
DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBQbaatU/3YD7OOnYWbmPd3mwjIeVDt
PfhmjOw+50Ve18pw91ysWBxoRNaHb4qoWU3uaOTCploh3TqvfeEfAjGfbinalTVstHqQW2CA
1K2k3jzKpfD/4MnbNIVeqXvVETG7gSn7CKDVe37kZHAxSiiqcS1c0CJdxNIeLPPa4zNVpQ==
--------------msA44E479A22AFB02EF13BE011--