POS Sync

POS Sync imports products and inventory from a connected point-of-sale system into CMS Max. It can also keep product information updated automatically.

#Connect a POS system

1. Install and activate Ecommerce, Liquor Max when applicable, and RMH (Retail Management Hero), NCR, Clover POS, or KORONA POS from Plugins. Only one POS connector can be installed at a time.
2. Open eCommerce > POS Sync > Settings.
3. Enter the credentials supplied for your POS connector on the Credentials tab.
4. Save the settings before fetching products or editing mappings.

Saved Store Keys, Access Keys, API tokens, and passwords appear as masked values when you reopen connector settings. Anyone who can access the settings page can use the eye icon beside a sensitive field to reveal or hide its value. Edit the value in place to change it. Other connection fields remain visible. For RMH and NCR, the Endpoint, Loyalty Engine Endpoint, and Access Key are discovered when you save and appear under Advanced.

The Automation tab controls the product-and-inventory schedule, the inventory-only schedule, and supported order exports independently. Native NCR Counterpoint also has separate image filename and content-verification schedules. The lightweight filename scan defaults to midnight each day, while full content verification defaults to 2:00 AM each Sunday so image downloads do not compete with the main catalogue import. Disable the applicable schedules to pause automatic imports; manual sync actions remain available. Leave order exports disabled unless the connected POS account is ready to receive CMS Max orders. Native NCR Counterpoint, Clover, and KORONA order export are not available yet. When enabling a supported export, choose exactly one Order Fulfilment Workflow:

• POS Order Processing (SubmitCart) sends the complete captured order to bLoyal using SubmitCart. Choose this when RMH or another local POS fulfils the web order.
• CMS Max Fulfilment (Inventory Only) sends only an inventory reduction. Choose this only when CMS Max fulfils the order itself.

When order export is enabled, CMS Max exports only after payment has been captured, and never exports a cancelled order. In POS Order Processing (SubmitCart), CMS Max sends the customer, products, applied discounts and their available CMS Max reason codes, pickup or shipping details, externally calculated tax, and captured payment. Coupon discounts appear at order level, while supported product and customer-group savings appear on their merchandise lines. bLoyal normally identifies the order source store and device from the API key. A legacy store key may need a device-code override. For pickup, a configured default location is sent; otherwise CMS Max asks bLoyal which location has stock for the entire cart and uses it only when there is exactly one match. bLoyal creates the downstream sales and inventory activity, so CMS Max does not send a separate inventory adjustment. In Inventory Only, CMS Max sends the inventory reduction and does not send a complete order. Orders awaiting payment or fraud review are withheld. If Authorize.Net later approves a reviewed payment, CMS Max releases that order automatically. Manual-payment orders are released when an administrator selects Mark as Paid on the order. The Manual Payment Tender Code is not a gateway credential; it tells bLoyal/RMH which payment type, such as CASH, to record for those manually confirmed orders. It is not used for Stripe or other captured gateway payments. Leave it blank when only captured gateway payments need export; manual orders cannot export until the corresponding tender is configured. Paya ACH orders are not exported. CardPointe's Hold Payment mode is not eligible for automatic POS order export because it authorizes the card without capturing payment.

If a customer-group discount cannot be represented as exact per-unit cents, CMS Max keeps it at order level so the captured payment remains balanced.

For POS Order Processing, every exported product must have a SKU and a quantity greater than zero so bLoyal can identify and process it correctly in RMH. If any product is missing a SKU or has an invalid quantity, CMS Max fails the whole export instead of sending an incomplete paid order. Taxed orders are likewise withheld if their original merchandise-versus-shipping tax allocation is unavailable, preventing CMS Max from guessing an incorrect allocation. Orders containing a fulfilment tip are also withheld because the current bLoyal SubmitCart schema has no supported tip field. These cases remain visible in Order Export History for correction and retry. If an export reaches a terminal failure, CMS Max emails the store's configured admin order-notification recipients with the reason and a link to review and retry it. Customers are not emailed about internal POS export failures.

CMS Max records an order as Accepted by bLoyal only after bLoyal acknowledges the selected request. SubmitCart must also return a cart identifier. This confirms that bLoyal accepted responsibility for downstream processing; it does not by itself confirm that RMH has downloaded the order. Open Order Export History from the POS Sync dashboard to inspect the acknowledgement identifier and response, or retry an eligible failed export.

Refunds and cancellations are not exported automatically in this first order-export release. Until return export is added, staff must mirror every CMS Max refund or cancellation in bLoyal/RMH so its sales, inventory, and loyalty records remain correct. If a partially refunded order is still waiting to export, CMS Max sends the original captured order so staff can apply the matching return downstream.

After saving valid bLoyal credentials, use Automation > Orders to configure optional legacy source overrides and a default pickup location. CMS Max loads searchable choices from bLoyal and verifies selected values before saving. Leave the source store and device blank when the API key already identifies them. For an older store key, bLoyal may require Web1 as the device code even when its device list does not include a web-cart device. A single pickup location can be left blank; CMS Max will confirm it can fulfill the cart before submitting. For multiple pickup stores, choose a pickup-capable default location. Customer choice among multiple available pickup locations is a separate follow-up. If bLoyal is temporarily unavailable, existing saved values remain displayed and are not erased. Inventory-feed provisioning is separate from these SubmitCart settings. Enter a Manual Payment Tender Code only for offline payments confirmed manually by an administrator.

For NCR Counterpoint, obtain the HTTPS API endpoint, company alias, and API username and password from the Counterpoint installer. The CMS Max developer API key is configured centrally and is never entered into an individual tenant. The installer must place the matching signed XML key file on the Counterpoint API server and assign the Counterpoint user an API role permitting Items, Item Categories, Inventory Locations, and Inventory GET requests. If Use Location-Specific Pricing is enabled, the role must also permit GET /Item/{ItemNo}/Inventory/{LocId}. A temporary self-signed certificate can be accepted through the application environment while the permanent certificate is arranged, but the endpoint must remain HTTPS. On the first save, CMS Max selects the main/default Catalog & Pricing Location when available, otherwise it uses the first location returned by Counterpoint. The complete company item list remains authoritative; by default this location supplies location-specific prices when an item exists there, and company pricing is retained when it does not. If the merchant uses the same prices at every location, turn off Use Location-Specific Pricing under Credentials to use company prices and skip the extra location item requests. Changing this setting marks the next product fetch as a full fetch. CMS Max also selects every accessible Inventory Location. Reopen Credentials to review the discovered locations and remove service, damaged-stock, display, or other locations whose inventory should not be sold online. The location fields are required after this initial discovery. CMS Max adds the selected locations' Counterpoint QTY_AVAIL values together. Existing NCR sites already connected through bLoyal continue using their saved connection. Native conversion is unavailable until their product and category identities can be migrated without losing storefront links.

The Counterpoint API role also needs permission for GET /Item/{ItemNo}/Inventory/{LocId} when location-specific pricing is on. Incremental product fetches use it to confirm that a saved location price still belongs to an existing location record; if the record was removed, the company price applies.

After saving a native Counterpoint connection, the API password remains filled in on Credentials. It is masked until you select the reveal button. Only administrators with access to this settings page should open or reveal it. Once credentials have been verified and saved, changes to unrelated sync settings can be saved during a Counterpoint API outage; changing the connection details still requires a successful API check.

For Clover, follow the complete Clover setup and first sync guide. Select the merchant's API environment and use a Merchant ID plus a merchant-specific inventory token.

Clover order export is not available yet, so CMS Max keeps it disabled even though catalogue and inventory synchronization can run normally.

For KORONA, follow the complete KORONA setup and first sync guide. On the first credential save, CMS Max loads all active Price Groups and chooses the most likely standard retail group. Combine All Locations is the default inventory mode, but you can instead use one warehouse location or disable stock tracking.

#Check the POS status

Open eCommerce > POS Sync > Dashboard and select Check POS Status in the Connection section. For RMH and legacy NCR connections through bLoyal, the check confirms that the login domain and credentials work, that the POS has enabled the product, inventory, category, and department change feeds CMS Max expects, and that the selected order workflow has the required endpoint. For native NCR Counterpoint, it checks Items, Item Categories, and inventory access for every selected location. With location-specific pricing enabled, it also checks per-item location inventory access when an item is available to sample; otherwise it warns that this permission remains unverified. For Clover, it checks product, category, and item-stock access. For KORONA, it checks the saved credentials, Products, Commodity Groups, selected Price Group, organizational units, selected inventory mode, and stock permission.

The check runs in the background so the dashboard remains responsive while the POS answers. The result remains visible in the Connection section as Ready, Action needed, or Unavailable. Select View Details to see the individual checks. Before the first import, the product check notes that the catalog assignment will be confirmed by the first product sync. If a completed product sync receives no products, the check warns that the default catalog assignment needs attention. The details also note when no positive inventory has been received, but zero stock alone does not make an otherwise working inventory feed unhealthy.

The POS status check is read-only. It does not reset or acknowledge change feeds, advance Counterpoint timestamp or KORONA revision cursors, or update POS data. Run it manually after configuring a connection or changing its POS permissions or inventory location.

When automatic monitoring is configured by CMS Max, active POS connections are checked hourly if Enable Automated Sync is on for either products or inventory. Busy connections are checked later so the check does not interrupt a sync. Failed checks notify the support team with the tenant, POS, and diagnostic details. An unchanged failure sends a daily reminder rather than an alert every hour; a new failure or a failure that returns after recovery alerts again. Warnings remain visible in the dashboard but do not send failure alerts. Pausing the connection or disabling both automated schedules excludes it from monitoring.

#Configure mappings

Open Product Mappings to choose how POS fields populate CMS Max products. When Ecommerce brands are enabled in store settings, the separate Brand Mapping section beneath the other product fields lets you enter POS source paths; its CMS Max destination is always Brand. For KORONA, this can be a custom product field; inspect View Raw POS Record for its exact path. For bLoyal, map Brand to ProductBrandName; POS Sync resolves it from the product's Product Brand assignment after Enable Brands is turned on under Sync Rules. Supplemental spreadsheet attributes are not read by POS Sync. When store-level brands are off, the Brand mapping and Brand Rules controls are hidden without deleting saved choices. Category Mappings appears when Enable Categories is on under Sync Rules.

When Ecommerce product tags are enabled, use Tag Mappings for KORONA, Clover, RMH/bLoyal, or NCR Counterpoint. Fetch products, enter a tag group name, and add one or more field paths from a sample POS product. Use the </> button beside the sample product to inspect its imported fields. New KORONA mappings start with tags.*.name; Clover mappings start with tags.elements.*.name. These paths map every tag name in the connector's array, while an indexed path maps only one. Saving reuses an existing group with that name or creates a filterable group. Changing the name of a linked group renames it. If a linked group has been deleted, enter a replacement group name or remove its mapping before saving. Optional fallback paths are used when the primary paths have no value. A product sync creates tag values from those fields and replaces the product's assignments within mapped groups; tags in other groups stay assigned. Clear a mapping to stop managing its group. The sample value is a preview of the fetched record, so fetch again after changing POS data.

1. Fetch products if no sample records are available yet. Product, category, and tag mapping editors appear after the fetch, and their field choices come from the fields present in the fetched POS records.
2. To create a starting point automatically, select Suggest with AI. Your POS connector queues an analysis of field names and sample values from up to 10 products spread evenly across the imported catalogue using the configured AI provider. You can leave the page while it runs; the suggestions load when the analysis finishes or when you return. Clover suggestions retain Clover's documented field semantics while assessing how the individual merchant populates optional and display fields. KORONA uses connector-owned selectors instead, so AI suggestions are not shown on its mapping screen.
3. Select a sample POS product or category to preview the mapped CMS Max values.
4. For a sample product, select View Raw POS Record to inspect every imported field and its dot-notation field path.
5. Review the AI Mapping Suggestions box to see the chosen POS path, confidence, reason, and real source examples for each field. Only medium- and high-confidence suggestions are shown. Fields owned by a connector's separate inventory feed are not suggested as product mappings. Existing mappings remain unchanged during this review.
6. Leave the suggestions you want checked, then select Apply Suggested Mappings to update those fields in the editable mappings below. Existing mappings for other fields are kept. Adjust the source and fallback fields as needed.
7. Save the settings before starting a sync. Applying an AI proposal to the form does not save it automatically.

Changing saved mappings marks affected imported products for another update. The dashboard will show when updates are waiting to be applied. Connector settings and manual product/category controls cannot be changed while a POS sync is queued or running. The settings page shows a warning, temporarily disables the affected controls, and checks more frequently until the run finishes so it unlocks automatically. The sync monitor detects runs that have stopped reporting progress, marks them finished, and then unlocks the form. Save the settings before starting another sync.

The imported products table shows each configured product mapping in its own column. If no mappings have been saved, it shows the connector's default mapping columns and values instead. Use the column manager to show, hide, or reorder those columns. RMH and NCR do not include Quantity in their default product mappings because bLoyal supplies authoritative stock through its separate inventory feed.

When the category and department change feeds are enabled, routine product syncs also receive taxonomy changes. With category updates enabled in Sync Rules, changing a POS category or department name updates the linked CMS Max category, its mapped content, and the public URLs beneath it. CMS Max creates redirects from existing category and product URLs to their new locations. A disabled category or department feed falls back to the classifications included with each product.

#Choose product rules

For native NCR Counterpoint, enable Get code descriptions from files under Credentials if the merchant provides attribute-code files. Otherwise, expand Counterpoint brand codes under Sync Rules before enabling Missing Brands → Create and enter readable brand names manually. Several codes can have the same name—for example, KNM and KENMORE can both become Kenmore. Codes without a file or manual description keep their original text, so review imported brand codes before applying products to the site.

Use the Sync Rules tab to control new and existing products separately. These rules determine visibility, inventory handling, category creation, and which POS-owned fields may overwrite CMS Max values.

Under Category Rules, turn Enable Categories off to stop creating, assigning, updating, or source-archiving CMS Max categories. Products are not archived merely because their POS category hierarchy is deleted while category management is off, and products previously archived with a deleted category hierarchy remain archived. This also hides the category-specific controls, Category Mappings tab, and POS Sync > Categories navigation. Existing imported category records, mappings, and category preferences remain available if categories are enabled again. Newly configured connections default to not creating missing POS categories; when creation is enabled, new CMS Max categories default to Draft. Existing connections retain their previous category-creation behaviour until the setting is saved.

For native Counterpoint, open Category Mappings and choose a source under Product categories. New connections start with Counterpoint categories, which uses the category and subcategory already assigned in Counterpoint. Fields on each product lets you choose the fields for a main category, an optional subcategory beneath it, and an optional separate category. Pick an Example product to see its actual value beside each field name; the fields used by one merchant may not suit another. If a product has no main-category value, it falls back to its standard Counterpoint category. If separate product fields hold readable category names, expand Category names (optional) to select them. Otherwise, enable file descriptions under Credentials, or enter code-to-name pairs under Category code names (optional) when file descriptions are off. Unlisted codes remain visible as codes so they can be reviewed later. Changing the category source, profile paths, or code names makes the next product fetch a full fetch so existing items can be recategorized.

Under Tag Mappings, enter a tag group name and choose the POS item field that supplies its values. You do not need to create the group separately: saving reuses a group with that name or creates a filterable group, and product sync creates its values. A newly created group appears as a storefront filter after its first product sync; there is no separate step to make it public. Existing groups retain their current filter setting. Editing the name of an existing mapping renames that group. Counterpoint attribute slots such as ATTR_COD_1 through ATTR_COD_6 are merchant-defined; preview their imported values and lookup descriptions to decide which fields represent Finish, Style, Size, Capacity, or Condition. The sample-value column shows the POS code beside its description when available. Condition comes from its configured item field, not an assumed meaning of the SKU suffix.

For Counterpoint, Credentials → Code descriptions → Get code descriptions from files lets CMS Max refresh attribute and profile names from text files on the API server during product fetches. The filenames default to ATTRCODES.txt and PROFCODES.txt, but you can change each to match the files supplied by your POS provider. Only those filenames are requested. Each description is used only for the attribute or profile fields marked valid in the file. Downloaded attribute labels are used for tag values and brand names; downloaded profile labels are used for category names. For categories and brands, a downloaded name takes priority and a saved manual name fills any gap. The manual category- and brand-code editors are hidden while file sourcing is on; their saved names remain available if file sourcing is turned off. Manual tag names continue to override downloaded descriptions. When either file changes, the next product fetch rechecks the full catalogue so existing products can pick up the updated labels. Leave the option off to use manual names or raw codes without requesting files.

Linked Category Details controls whether CMS Max or the POS owns category names, mapped content, URLs, and parents. CMS Max ownership preserves editorial changes while products and category links continue syncing. POS ownership updates POS-created and manually linked CMS Max categories whenever their POS category changes.

When Ecommerce brands are available, turn on Enable Brands under Brand Rules to import POS brands. Create New CMS Max Brands controls whether an unmapped POS brand can create one; New Brand Visibility defaults to Public and can be set to Draft. Existing Product Brand Assignments controls whether the POS can change a linked product's brand. POS Sync > Brands lists each distinct imported POS brand and lets you link it to an existing CMS Max brand. Scheduled product imports check for Product Brand name changes. Connector-created brand names and URLs follow those changes; manually linked CMS Max brand names are preserved. Turning brand sync off stops POS brand processing without removing existing brand assignments. If Ecommerce brands are later re-enabled, the next bLoyal product sync automatically performs the complete product import required to recover Brand details omitted while the feature was unavailable. A newly created public brand receives its brand URL and product-list content immediately. Brand assignment does not change the product's own URL.

Native Counterpoint starts with ATTR_COD_2 as its Brand mapping, matching the available Items with Web Info export. Counterpoint attribute slots can differ by merchant, so inspect a fetched raw item and change the Brand source under Product Mappings before enabling brand creation when necessary. ITEM_VEND_NO is the vendor number and is not used as a brand fallback.

For existing products, Category Assignment defaults to Sync, keeping each product assigned to the CMS Max category linked to its current POS category. Connections configured before this release also adopt Sync on their next sync unless Don't change is selected. Choose Don't change only when manual CMS Max product-category assignments should persist even if the POS category changes. This setting does not rename or move the categories themselves.

For RMH and legacy NCR connections through bLoyal, Product Availability includes Only Sync Web-Enabled Products. Leave it on to archive products that bLoyal marks as unavailable for the web. Native NCR Counterpoint provides Only Sync E-commerce Items; when enabled, items without Counterpoint's E-commerce Item setting are archived. Disable the applicable rule and run Re-fetch All Products & Inventory to restore previously archived products. Clover and KORONA do not expose an equivalent website-availability setting. Clover items marked unavailable remain in the catalogue as out of stock.

When Liquor Max is active, Name can update all products, only non-liquor products, or no existing products. New native NCR Counterpoint, Clover, and KORONA connections default to Non Liquor Products so Liquor Max names remain intact while ordinary product names continue updating from the POS. A POS-owned name change also updates the public URL during product follow-up and creates a redirect from the previous URL.

Missing Categories has the same Non Liquor Products scope when Liquor Max is active. It creates categories only for POS categories marked Excluded from LiquorMax; liquor products retain the taxonomy supplied by the Central catalogue. New native NCR Counterpoint, Clover, and KORONA connections with Liquor Max active use this scope by default. Intentionally unlinked categories that are outside the selected creation scope are not counted under Needs Attention. This is separate from archiving a POS category, which excludes its products from synchronization entirely.

Products configured to use Liquor Max are still created when their POS record has no usable GTIN. CMS Max skips Central enrichment for those products and lists them in the missing-liquor-data dashboard until a GTIN is supplied or Liquor Max is disabled for the product.

When Liquor Max is active, New Product Rules > Visibility defaults to Draft if No Liquor Data for every Nexus connector unless another visibility rule has been saved. New POS products that use Liquor Max start as drafts while Central enrichment runs. Products that receive beverage data become public. Configure POS category exclusions before the first product import so non-liquor products start public. Newly imported products in POS categories excluded from Liquor Max use Public. If you exclude a category after its products were imported as drafts, those existing products remain drafts under the default Don't change update rule; publish them from Products if they should be visible. Products without beverage data remain drafts on later POS updates while Don't change is selected. If Liquor Max is turned off, the saved choice remains available in settings, and new products use Public instead.

If Existing Product Rules > Visibility is set to Public while Draft if No Liquor Data is selected, a warning explains that the next POS update can publish a new draft product before it has liquor data. Select Don't change to keep it draft until Central adds beverage data.

POS product creation and updates keep products with a zero price as drafts. Add a valid price in the POS before publishing the product through a POS sync.

For native Counterpoint, the default price mapping uses REG_PRC and falls back to PRC_1 when the regular price is missing or zero and Price 1 is positive. A custom mapping with no positive fallback retains a zero price.

Native NCR Counterpoint also provides an Images rule. It is disabled by default. When enabled, the separate image schedules download the item's primary Counterpoint image as the featured image and add its alternate images to the gallery in the background. For condition-suffixed item numbers with no exact images, CMS Max also checks matching images under the base model number. If the current featured image was uploaded separately but has the same filename and byte size as Counterpoint, it is reused rather than uploaded again. Later filename scans add, rename, or remove images previously imported from Counterpoint while preserving unrelated CMS Max gallery images. Full content verification also detects an image replaced without changing its filename. Counterpoint stores images separately from item records, so product imports do not download images or wait for image processing.

After enabling Images and applying products, use Sync Images on the POS Sync Dashboard to start a manual filename scan. Its dropdown offers Full Image Verification for checking whether existing files changed without being renamed. The first scan may download many files; run it when the POS is quiet. Both actions process images in the background, with results shown in recent activity.

Imported products, categories, and brands can be linked to a different CMS Max record from the imported catalog pages. In an RMH hierarchy, a department is the parent and a category is its child. The Categories list sorts names alphabetically at each level while keeping children beneath their parent. Filter categories by type to show only departments, or select a department to inspect its categories. The Products count includes and links to products anywhere beneath that hierarchy level, while Direct Products counts and links to only the products assigned exactly there; both include archived products. Select a brand product count to open the Products page filtered to that brand, including archived products. Liquor Max policy confirmations use those same totals. Excluding a POS category archives its imported child categories and affected imported products after confirmation.

For KORONA, CMS Max imports the complete Commodity Group ancestry and assigns each product to its leaf group. Subsequent runs request only products and Commodity Groups newer than their saved revisions; groups deleted from KORONA are returned as inactive and archived in CMS Max. The mapping screen describes the automatic KORONA behavior while retaining its editable source paths: Automatic GTIN from Product Codes scans the available product codes for a recognizable GTIN, and Current Price from Selected Price Group selects the newest price in the configured Price Group whose start date has arrived. If a different field is required, save a custom mapping. From an imported KORONA product's action menu, select Open in KORONA to edit that source record in KORONA Studio.

KORONA scheduled prices update the CMS Max regular price. CMS Max does not infer a sale from an older price or automatically translate KORONA promotions, because the product price timeline does not identify a reliable regular-price/sale-price pair. Existing CMS Max sale prices and dates are preserved by default. Only enable Sale Price and Dates ownership when an intentional custom mapping supplies those fields.

CMS Max uses the first recognizable UPC/EAN/GTIN from KORONA's product-code list rather than assuming the first code is a barcode. A KORONA product with Track Inventory disabled also remains untracked and sellable in CMS Max, even when the selected location returns a zero stock record. KORONA typed descriptions are not copied into CMS content by default, and KORONA's Listed and Sales Lock flags are not treated as website visibility controls; configure an intentional custom mapping or manage those website fields in CMS Max when needed.

KORONA sectors and sales-tax rates do not correspond to TaxJar product tax-category codes. During onboarding, configure CMS Max's default tax behavior and assign any exempt or specially categorized products in CMS Max. A KORONA sector named “Tax Free” is not automatically trusted as a CMS Max exemption.

After fetching Counterpoint products, use Discovered category codes on Category Mappings to open POS Sync > Categories. This list identifies profile codes and standard item-category fallback codes separately. For placeholder names, use Set storefront name. To combine codes that truly mean the same thing, select the same CMS Max Category for both; the second link is shown as Shared category and cannot overwrite the category name. Archiving a POS category also excludes its products, so do not use Archive just to hide a label.

#Run a sync

Open eCommerce > POS Sync > Dashboard and select Sync Products & Inventory for routine use. This fetches available POS changes, applies them to CMS Max, updates inventory, and performs any required follow-up work.

Native Counterpoint routine syncs request only items and location inventory changed since the last safely completed boundary, with a fifteen-minute overlap. CMS Max performs a complete daily audit and does not advance either boundary when a run fails. KORONA routine product, Commodity Group, and inventory syncs request only records newer than the last successfully imported revision. Inventory keeps a separate revision for every warehouse location so single-location and combined-location stock remain accurate. No acknowledgement is sent to either native Counterpoint or KORONA. If a request fails before all pages are safely applied, CMS Max keeps the previous cursor or revision and safely replays the records on the next attempt. Each routine KORONA sync also re-evaluates already-stored scheduled prices, so a future KORONA price becomes active after its start time even when merely reaching that time does not create another product revision.

When the POS reports that a product has been deleted, the next product sync archives its linked CMS Max product. If the POS later returns that product, CMS Max restores the same linked product unless it was manually excluded from synchronization.

The More sync options menu also provides narrower maintenance operations:

• Fetch Product Changes from [POS] Only downloads POS changes without applying them. Before the first import, its label is Fetch All Products from [POS].
• Apply Fetched Products to Site applies previously fetched changes and appears only when work is waiting.
• Sync Inventory from [POS] refreshes inventory without running a product import.
• Re-fetch All Products & Inventory performs a complete re-import and should be reserved for recovery or configuration changes that require every record to be reconsidered.

Do not start another sync while saved settings have changed. Save the settings first so the run uses the values shown on screen.

#Monitor a sync

The dashboard shows the current or latest run in ordered stages: fetching from the POS, updating products, updating beverage data when Liquor Max is active, and product follow-up. It shows counts where the work size is known, including the number of products in an active follow-up job. Where no reliable total exists, the stage moves without showing a misleading percentage or completion estimate. Narrow operations such as Fetch products retain the full stage layout but mark stages that are outside that operation as Not included. A completion notification appears when an active run finishes while the dashboard is open.

While inventory is being synchronized, the dashboard also shows whether CMS Max is requesting inventory, updating linked product stock, confirming receipt with the POS, verifying an uncertain confirmation, or checking for another page. These steps include the inventory batch number and may repeat when the POS returns inventory in more than one page. The total number of batches is not known in advance, but an increasing batch number confirms that processing is continuing. Native Counterpoint additionally shows the current inventory location, its position in the selected location list, and the API page being requested. bLoyal feeds require an acknowledgement for each batch; if that response is lost, CMS Max checks whether the feed advanced before retrying. Native Counterpoint and KORONA advance their saved cursor only after the returned inventory has been applied and require no acknowledgement.

Native Counterpoint product fetches also show the current company product or location-pricing page. Counterpoint does not report a total page count, so the increasing page number confirms that a long initial fetch is continuing without presenting an unreliable percentage.

If the POS is not ready to provide another data sync, the current run shows Waiting for POS and the time until CMS Max tries again. The sync resumes automatically from its unfinished step, so completed product fetching is not repeated; no manual action is required.

Temporary POS request failures appear as a warning on the active run. The warning shows how many requests have failed, confirms that CMS Max is continuing to retry, and includes a short description of the latest issue. An inventory warning clears after the POS accepts the affected batch. These request failures do not mean the overall sync has failed.

For KORONA, temporary connection failures, service failures, and rate limits retry automatically. A daily API limit waits for the normal queued retry rather than holding a worker open. Authentication, permission, missing-account, and other permanent failures appear with a safe action-oriented message in the sync activity.

Use Recent Runs for totals and the outcome of each run. Choose All types or a specific run type to narrow the list; View more runs continues within that selection. Products or categories that could not be matched or updated appear under Imported POS Catalog > Needs Attention with the recorded reason.

Open the products processed during a run and select View Changes to compare every captured CMS Max product value before and after that sync. Price and sale-price changes are displayed as currency. Newly created products are recorded without repeating all of their initial values, so they do not show this action. Older events created before change tracking was introduced continue to show their changed field names but do not have a before-and-after comparison.

#Schedule automatic updates

Open Settings > Automation to configure two schedules:

• Product Updates (includes inventory) processes product changes and refreshes inventory. Choose a frequency that fits the POS provider's request allowance and how quickly catalogue changes need to appear.
• Additional Inventory Updates refreshes stock without processing the product catalog. Turn this off if the product update schedule refreshes stock often enough.

Each schedule can run at an interval or at a chosen time daily, on selected weekdays, or on a chosen day each month. A monthly date that does not exist in a shorter month runs on that month's last day. Schedules use the site's configured timezone. The dashboard shows when each automatic run is due next.

For native NCR Counterpoint, Image Filename Scan defaults to a daily midnight run. It scans linked imported products in bounded batches, compares the available filenames, and downloads only new or renamed files. Verify Existing Image Contents defaults to Sunday at 2:00 AM. It first checks response validators or Counterpoint's file size and modification date using a one-byte request. The complete image is downloaded only when that metadata changes or the server provides no reliable metadata, in which case CMS Max compares the downloaded contents. Configure content verification for a quiet period at the store.

#Recover from a problem

1. Open the failed run on the dashboard and review its summary.
2. Resolve any credential, mapping, or matching issue shown under Needs Attention.
3. Run Sync Products & Inventory again. Successfully completed records are not duplicated.
4. Use Re-fetch All Products & Inventory only when a complete source re-import is required.

Contact CMS Max support before clearing imported data on a production site.