Reconcile account type/sub-type in QBO + CSV imports

Closes the remaining type/sub-type-consistency vector (create/edit + IIF
were already covered). The sign convention keys off sub-type, so a
mismatched pair posts with the wrong debit/credit sign.

- New AccountClassification.DefaultSubTypeForType(type).
- QBO import: QBO Type is reliable but DetailType frequently isn't
  mappable and fell back to AccountSubType.Other (an expense-range sub-type)
  — so an unmapped Liability/Equity/Revenue account would have posted
  debit-normal. Now reconciles the sub-type to the type when they disagree.
- CSV import: type and sub-type came from independent columns; now derives
  the type from the sub-type (sub-type authoritative, matching create/edit).
- IIF import already returns consistent (type, sub-type) tuples — unchanged.

Build clean; 293 unit tests pass.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
2026-06-20 18:06:06 -04:00
parent 4df85d75db
commit 27cf4532cf
3 changed files with 29 additions and 1 deletions
@@ -565,7 +565,14 @@ public class QuickBooksOnlineService
var parentName = name.Contains(':') ? name.Substring(0, name.LastIndexOf(':')).Trim() : null;
result.TotalRecords++;
rows.Add((displayName, parentName, number, desc, MapQboAccountType(typeStr), MapQboDetailType(detailType)));
// QBO Type (high-level) is reliable; DetailType often isn't mappable and falls back to
// Other. Reconcile so sub-type's parent always matches the type — otherwise an unmapped
// liability/equity/revenue would get an expense-range sub-type and post with the wrong sign.
var acctType = MapQboAccountType(typeStr);
var subType = MapQboDetailType(detailType);
if (AccountClassification.TypeForSubType(subType) != acctType)
subType = AccountClassification.DefaultSubTypeForType(acctType);
rows.Add((displayName, parentName, number, desc, acctType, subType));
}
// Pass 1: upsert every account WITHOUT parent links so they all get IDs.