Contact
StandardQuickBooksRefId__ctextPrimary_Billing_Contact__ccheckbox
The data model behind Tally for QuickBooks, generated from the managed package metadata. Salesforce objects on top, QuickBooks mirrors beneath them, documents and their line items in the middle, reference lists below and the plumbing at the bottom.
Each card shows the fields that matter most. Open one to see every field it ships with, their types and what they point at.
QuickBooksRefId__ctextPrimary_Billing_Contact__ccheckboxQuickBooks_Taxable__ccheckboxQuickBooksRefId__ctextQBO_Sync_Status__ctext · formulaLast_Synced__cdatetimeQuickbooks_Card_Id__ctextAccount_Number__cencryptedTokenization_Status__cpicklistQuickBooksRefId__cext idSyncToken__ctextDisplay_Name__ctextId__cext idBalance__cnumberVendor1099__ccheckboxQBO_RefId__ctextSubTotal__cΣ roll-upStatus__cpicklistInvoice_Id__ctextSubTotal__cΣ roll-upAmount_Paid__ccurrencyPayment_Status__ctextQBO_Ref_Id__ctextSub_Total__cΣ roll-upPayment_Method__ctextQuickBook_RefId__cext idStatus__cpicklistTotal_Amount__cnumberAmount__ccurrency · formulaRate__ccurrencyQuantity__cnumberQBO_Line_Id__cext idAmount__ccurrency · formulaAmount__ccurrencyStatus__cpicklistAmount__ccurrency · formulaQuantity__cnumberType__cpicklistAmount__cnumberAccountType__cpicklistFullyQualifiedName__ctextTotal_Tax_Value__cΣ roll-upTax_Value__cnumberId__cext idEntity__cmultipicklistValue__ctextLabel__ctext · formulaOAuth access + refresh tokens, realm id, and a mirror of QBO company preferences.
Endpoints, defaults and feature switches: product sync direction, sales receipt sync, the Custom Fields API, card and ACH options.
Package-shipped defaults: client id and secret, auth, token and callback URLs.
One checkbox per attribute — field-by-field control over what syncs on a customer.
One row per trigger, by name, with an IsActive box: turn a trigger off without a deploy.
Correlation id, direction, payloads, stack trace and duration. Record ids are stored as text, so a log can be written even when its record is gone.
A platform event that carries an opportunity id and the action that triggered it.
The invoice and purchase order product tables subscribe to it: product lines published here appear on the open form.
Each pattern answers a constraint of keeping two systems in sync when both of them think they own the data.
01
Each QuickBooks entity gets its own __c object instead of being packed into Account or Opportunity. Account ships with no packaged fields. Each mirror stores the QuickBooks id of its record, and several also keep the SyncToken__c version stamp QuickBooks requires on every update.
02
Four line-item objects, payments, tax rates and custom field values hang on master-detail. The subtotals on invoices, estimates and sales receipts are roll-up summaries the platform computes, and deleting a document deletes its lines with it.
03
Documents reference customers, tax codes and products through lookups. Retiring a class or deleting a product does not take the invoices that used it along with it. Ownership is kept for lines only.
04
Invoices, estimates, sales receipts and purchase orders store the parent object name and record id as text (for example Parent_Object__c and Parent_Record_ID__c) instead of a hard lookup. That is what lets a document start from an opportunity, a work order or a custom object without the package depending on objects your org may not have.
05
QuickBooks nests sub-customers, sub-classes and sub-accounts. Their mirrors carry a self-lookup (Parent_Customer__c, Parent_Class__c, ParentRef__c), and Parent_Invoice__c links each recurring invoice to the invoice it was generated from.
06
Tokens, configuration, logs and events carry no lookups. Log__c stores record ids as text, so a failed sync can still be logged after its record is gone. Custom settings and metadata sit outside the data model entirely.