Record Data and Synchronization

As a consultant setting up a new environment,
I want to see all source records tracked for a given Data Template,
so that I can verify the correct records are in scope before triggering the first exchange.

Steps:

1. In the master company, open Global Master Record Data.
2. In the Data Template Filter field, enter or look up the template code (for example, CUST-MAIN).
3. Review the list. Each row is one source record in scope. Check that the Primary Key values and Table Caption match your expectations.
4. Use the Show Only Records changed since filter to narrow the view to records modified after a specific date.

Notes: This page is read-only. The master side does not show synchronization status columns; those appear only on subscriber companies.

As a consultant troubleshooting a data mismatch,
I want to see the exact field values the master has captured for a specific record,
so that I can confirm what was sent to subscribers.

Steps:

1. Open Global Master Record Data and locate the record by filtering on the template and scrolling to the relevant row.
2. In the Field Values subform at the bottom of the page, review each field: the Field Caption, the Value (stored as text), whether it is a Primary Key Field, and the Last Date Modified.
3. For fields with large binary content (images, attachments), select the field value row and choose Blob from the Line menu to open the text preview of the stored content.
4. If the field value appears empty or incorrect, use Update Record Data (see US-05) to refresh the snapshot from the source record.

As a master company administrator,
I want to rebuild the record set for all templates in one batch,
so that the stored field values reflect the current state of the source data after a data migration or bulk change.

Steps:

1. In the master company, search for Create / Update Global Master Record Data (under Tasks).
2. On the request page, optionally filter to specific template codes if only a subset needs refreshing.
3. Run the report. Progress is shown per template.
4. After completion, open Global Master Record Data and verify that Change DateTime values have been updated for the records you expected.

Notes: The report only processes Released templates owned by the current master company. Field templates are excluded. Running this report after a major data load ensures the record set is aligned before triggering the first exchange.

As a consultant using a template with selective exchange,
I want to add a single master record to the record set for a specific subscriber,
so that only that subscriber receives the record in the next exchange.

Steps:

1. Navigate to the source record (for example, open the Customer card for customer 10000).
2. On the source record page, find the Assign Subscribers action (visible on master companies where a selective-exchange template covers this table).
3. Select the record and choose Assign Subscribers. A list of subscribers that do not yet have this record selected is shown.
4. Mark the desired subscribers and confirm. The system inserts a Record Selection entry and cascades it to any sub-templates.
5. Verify the selection appears under Global Master Selected Record Data, filtered by the template and subscriber.

Notes: The Assign Subscribers action is available for G/L Accounts, Customers, Vendors, Items, Dimension Values, and Jobs by default. Other tables require an extension.

As a master company user,
I want to refresh the captured field values for one or more specific records,
so that a change I just made to the source record is picked up for the next exchange without waiting for the automatic update.

Steps:

1. Open Global Master Record Data and filter to the relevant template.
2. Select the row or rows you want to refresh (multi-select with Shift/Ctrl).
3. Choose Update Record Data in the ribbon and confirm.
4. The field value snapshot is rebuilt from the live source record and the Change DateTime is updated to now.

Notes: The Update time of change for Record Data and Field Values action provides a lighter alternative: it bumps the timestamp without rebuilding field values, which forces the record into the next exchange without re-reading the source.

As a consultant,
I want to remove a specific record from the synchronized set for a subscriber using selective exchange,
so that the subscriber no longer receives updates for that record.

Steps:

1. On the master, open the relevant Data Template and navigate to its subscriber list (Global Subscriber Data Templates).
2. Locate the subscriber and choose Record Data to open the selected record view.
3. From the Global Master Selected Record Data page, identify the record to remove.
4. Deleting the Record Selection entry triggers the creation of an Obsolete Record ID for that subscriber, which will cause the record to be removed from the subscriber company at the next exchange.

Notes: Removing a record selection is only possible on templates configured for Exchange only Selected Records. On templates without selective exchange, all records matching the template filters are always in scope.

As a master company administrator,
I want to see whether a specific record has been synchronized in each subscriber company,
so that I can identify which subscribers are lagging behind.

Steps:

1. In the master company, open Global Subscriber Data Templates from the partner or template card.
2. For each subscriber row, choose Record Data to open either the Global Master Record Data or Global Master Selected Record Data view filtered to that subscriber and template.
3. On the subscriber page, look at the Data Synchronized and Data Synchronized On columns for the record in question.
4. Alternatively, switch to the subscriber company and open Global Master Record Data directly, filtering to the template and enabling Show Only Not Sync. Records to see all pending items.

As a subscriber company user,
I want to reset the Skip Synchronization flag for records that were automatically skipped after too many failed attempts,
so that the synchronization engine tries again on the next run.

Steps — Single record:

1. Open Global Master Record Data on the subscriber and locate the skipped record (enable Show Only Skip Sync. Records).
2. Select the row and choose Set "Skip Synchronization" from the ribbon.
3. In the menu, choose Reset "Skip Synchronization" for selected record data. The flag is cleared and the attempt counter is reset to zero.

Steps — Bulk reset:

1. Multi-select all skipped records (or use Select All while the Skip filter is active).
2. Choose Set "Skip Synchronization" → Reset "Skip Synchronization" for selected record data.
3. Optionally, choose Reset Synchronization Fields → include sub records if needed to also reset the field-level sync markers.

Notes: The maximum number of attempts before a record is auto-skipped is configured in the Global Master Setup. A scheduled task can also be configured to reset attempts automatically after a configured number of hours.

As a subscriber company user,
I want to manually mark a record so it is excluded from all synchronization runs,
so that I can prevent a known-problematic record from blocking the rest of the sync queue.

Steps:

1. Open Global Master Record Data on the subscriber and locate the record.
2. Select the row and choose Set "Skip Synchronization" from the ribbon.
3. Choose Set "Skip Synchronization" to yes for selected record data and confirm.
4. The Skip Synchronization column is set to Yes. The record will not be processed in any automatic or manual sync run until the flag is reset.

Notes: You cannot set Skip Synchronization on a record that has already been successfully synchronized (Data Synchronized = Yes). The action guards against accidental skipping of already-applied records.

As a subscriber company user,
I want to see all pending delete and rename signals and understand which ones have failed,
so that I can investigate and mark errors as reviewed when no further action is needed.

Steps:

1. On the subscriber company, search for Global Master Record Actions.
2. Enable Show Only Non Reviewed Errors to focus on actionable items. Each row shows the action type (Delete or Rename), the affected record ID, the error text, and whether the action has been executed.
3. To retry a failed delete, select the row and choose Execute Record Actions.
4. If the error is expected (for example, the record never existed in this subscriber), select the row and choose Set Error Reviewed. This marks the entry as acknowledged and removes it from the non-reviewed error count.
5. Use Show Record to jump directly to the BC record involved.

As a consultant evaluating whether manual maintenance is needed,
I want to understand when the master record set updates itself automatically,
so that I can advise clients on setup requirements.

Explanation:
When the master company has Master Auto Update Record Set enabled in the Global Master Setup, the GMDS app registers itself on every database event (insert, modify, delete, rename) for tables covered by a Data Template. Whenever a user saves a change to a Customer, Vendor, Item, or any other tracked table, the system immediately updates the corresponding record entry and all its field values. The Change DateTime on the record entry is bumped, which ensures the record is included in the next exchange.

If Auto Update is not enabled, or if a bulk data load bypasses database triggers, the consultant must run Create / Update Global Master Record Data manually to bring the record set up to date before triggering an exchange.

As a subscriber company user,
I want to see which Data Templates I am subscribed to and what their last exchange date was,
so that I can confirm data is flowing correctly.

Steps:

1. On the subscriber company, search for Global Subscriber Data Templates.
2. The list shows every template this company is subscribed to. The Data Logged column indicates whether an IC File Log has been created, and Data Logged On shows when. The Error Text column captures any send-side error from the last transfer.
3. From a row, choose Record Data to open the Global Master Record Data page filtered to that template, showing all synchronized records with their current status.
4. Use Obsolete Record IDs to see any pending delete requests for records that have been removed from the master's record set.
5. Use Rename Records to see any pending rename requests propagated from the master.

As a subscriber company user,
I want to immediately apply the stored field values for a specific record to the local BC record,
so that I do not have to wait for the next scheduled synchronization run.

Steps:

1. Open Global Master Record Data on the subscriber and locate the record (filter by template, primary key, or use Show Only Not Sync. Records).
2. Verify the record has Data Synchronized = No and is not marked Skip Synchronization.
3. Select the row and choose Synchronize Record Data from the ribbon. Confirm the action.
4. The system immediately applies each field value to the corresponding BC record (inserting the record if it does not yet exist) and marks the entry as synchronized.
5. A summary message shows how many records succeeded and how many encountered errors.

As a master company user,
I want to understand what happens when I rename a source record (for example, change a customer number),
so that I know what subscribers need to do to complete the rename.

Explanation:
When a source record's primary key changes on the master, the GMDS app intercepts the rename event and writes a Record Action of type Rename. The action stores both the old and new primary key values. On the next exchange, the action is sent to all subscribers. On the subscriber company, during the synchronization run, the app locates the record under the old key and renames it to the new key using a BC Rename call. The field values are then applied on top.

If the rename fails (for example, the old key no longer exists on the subscriber), an Error Text is recorded on the Record Action and the entry appears on the Global Master Record Actions page with Has Error = Yes. The consultant can investigate using Show Record, then either retry the action via Execute Record Actions or acknowledge the error using Set Error Reviewed.

As a master company user,
I want to understand what happens when I delete a source record on the master,
so that I know what action the subscriber will take and how to verify it.

Explanation:
When a source record is deleted from the master, the GMDS app writes a Record Action of type Delete (and, for templates that have already been exchanged, also creates an Obsolete Record ID entry per subscriber). On the next exchange, the delete signal is sent. On the subscriber, the synchronization run finds the corresponding GM record entry, deletes the local BC record, and removes the subscriber's GM record entry.

If the delete fails (for example, the record is blocked by a related document), the error is captured on the Record Action. The consultant can review it on Global Master Record Actions, investigate the blocking situation, and either manually delete the record before retrying or mark the error as reviewed if the subscriber's data is acceptable as-is.

As a subscriber company administrator,
I want to run a full update-and-sync cycle on demand,
so that I can apply all pending IC File Log content and synchronize all unsynchronized records in a single action.

Steps:

1. On the subscriber company, search for Update and Synchronize Company with Global Master Data (under Tasks).
2. The report requires no request-page input. Run it directly.
3. The job performs three steps in order: (a) resets retry counters for records that have been skipped long enough, (b) applies any pending IC File Log content to the local record set, (c) runs the synchronization loop across all subscribed templates.
4. After completion, open Global Master Record Data and enable Show Only Not Sync. Records to verify that the queue has been processed.

Notes: This report can also be scheduled as a job queue entry so the sync runs automatically at regular intervals without manual intervention.