Customer reporting workflow
Object-specific availability and field permissions determine this mapping. Use the restrictions shown for each record type.
Starting event: A change to the selected Customer or Proposed customer table in PostgreSQL (choose its name) record needs a defined result in the other system.
- Start with NetSuite Customer and PostgreSQL Proposed customer table in PostgreSQL (choose its name). Use the record-matching and field-ownership rules from your mapping worksheet.
- Resolve person or company type, legal entity, business role, and any billing account before transactions.
- Test a normal update and one failed or repeated update in the supported direction. Keep both record IDs with the test results.
Expected result: Test an individual buyer, a company buyer, and one company with multiple billing relationships. Do not merge these into a single generic contact.
If it fails: Hold ambiguous customer matches for review and resolve customer type before retrying dependent records.
Customer invoice reporting workflow
Object-specific availability and field permissions determine this mapping. Use the restrictions shown for each record type.
Starting event: A change to the selected Invoice or Proposed customer invoice table in PostgreSQL (choose its name) record needs a defined result in the other system.
- Start with NetSuite Invoice and PostgreSQL Proposed customer invoice table in PostgreSQL (choose its name). Use the record-matching and field-ownership rules from your mapping worksheet.
- Resolve the customer or supplier, account codes, tax, currency, and accounting period before posting.
- Test a normal update and one failed or repeated update in the supported direction. Keep both record IDs with the test results.
Expected result: Test a posted invoice, a partial payment, tax rounding, and a closed accounting period. Compare financial totals within the same entity and currency.
If it fails: Determine whether a transaction posted before retrying. Follow the approved adjustment process for posted records.
Supplier bill reporting workflow
Object-specific availability and field permissions determine this mapping. Use the restrictions shown for each record type.
Starting event: A change to the selected Vendor Bill or Proposed supplier bill table in PostgreSQL (choose its name) record needs a defined result in the other system.
- Start with NetSuite Vendor Bill and PostgreSQL Proposed supplier bill table in PostgreSQL (choose its name). Use the record-matching and field-ownership rules from your mapping worksheet.
- Resolve supplier, expense/account codes, entity, currency, and accounting period before bill lines.
- Test a normal update and one failed or repeated update in the supported direction. Keep both record IDs with the test results.
Expected result: Test a duplicate supplier document number in another entity, a partially paid bill, and a closed period.
If it fails: Verify whether the bill was approved or posted before retrying; use the approved adjustment process for posted bills.
Reconcile NetSuite business records with PostgreSQL
Validate the selected objects and operations even where connector-level direction is documented.
Starting event: A finance-owned record in NetSuite needs operational visibility through a selected destination dataset.
- Select Customer or Vendor with the correct legal entity, period, and currency.
- Define a reporting relationship in PostgreSQL; do not equate customer records, ledger accounts, and posted transactions.
- Decide whether the process only reports a financial state or requests an approved accounting action, and maintain a separate transaction ID for each action.
Expected result: Totals reconcile within the same entity/currency/window; a repeated handoff creates no duplicate financial transaction.
If it fails: Verify posting and settlement state before retrying. Use the approved adjustment path for already-posted transactions.
