Customer invoice sync test
Planning example. Stacksync support for the required connection and record operations needs a technical review.
Starting event: A change to the selected Invoice or Customers and Invoices record needs a defined result in the other system.
- Start with Campfire Invoice and Workday Customers and Invoices. 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 or vendor sync test
Planning example. Stacksync support for the required connection and record operations needs a technical review.
Starting event: A change to the selected Vendor or Suppliers record needs a defined result in the other system.
- Start with Campfire Vendor and Workday Suppliers. Use the record-matching and field-ownership rules from your mapping worksheet.
- Resolve business-unit and payment-term references before purchasing 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 a supplier shared across subsidiaries and an inactive supplier referenced by an open bill.
If it fails: Review rejected supplier changes before retrying dependent bills; do not reactivate a supplier merely to make a write pass.
Journal or ledger entry sync test
Planning example. Stacksync support for the required connection and record operations needs a technical review.
Starting event: A change to the selected Journal Entry or Journal Entries record needs a defined result in the other system.
- Start with Campfire Journal Entry and Workday Journal Entries. Use the record-matching and field-ownership rules from your mapping worksheet.
- Resolve chart-of-account, currency, entity, and dimension references before 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: Verify balanced debits and credits, dimension requirements, and rejection for a closed period.
If it fails: Reconcile posting status and use the finance-approved reversal or adjustment process instead of replaying a posted entry.
Worker lifecycle planning for Workday and Campfire
This is an evaluation scenario; connector and operation support require confirmation.
Starting event: A worker joins, moves, or leaves in Workday; a downstream process in Campfire needs the approved context.
- Identify the worker and employment record represented by Workers or Suppliers. Retain effective dates and organizational scope.
- Determine what Bill or Invoice represents: an operational task, a user identity, or a reporting row. Define a relationship; do not map these records as if they were the employee itself.
- Require the process owner to approve any access, payroll, or account action and assign an exception owner.
Expected result: Rehires and concurrent assignments keep distinct employment context; delayed updates do not reverse a newer effective state.
If it fails: Inspect employment identity and effective dates before retrying the downstream action.