Priceman: automatic price and markup calculation based on rules

What this solution does

Automatic retail price calculation based on defined rules

Retail prices cease to be static values entered manually. You define the logic: which base price to use for calculation, what markup percentage to apply, the rounding target, and the minimum price threshold. The module applies these rules to the entire catalog and executes recalculation on a scheduled basis.

This solves the issue of scattered markup rules that often exist only in the owner's memory or in third-party scripts. While manual adjustment is feasible for a small assortment, it becomes impossible with thousands of items and frequent 1C data exchanges, leading to significant deviations from intended pricing. The module converts these agreements into a single configuration: rules are set once, applied uniformly across the catalog, and remain fully transparent. For any price, you can trace which rule generated it and the data it was based on.

Profile configuration and priority

The profile defines two parameters: which items to process and the logic for calculation. Item filtering is performed via information blocks, sections (with or without nested items), and a complex condition tree using AND/OR operators based on properties, prices, and dates.

A table of rules is stored within the profile, with the execution order set manually. Upon execution, the system checks rules sequentially and applies the first matching one.

The Priceman module automatically calculates prices and markups based on defined rules. Rules operate on continuous ranges of source prices where adjacent intervals connect without gaps. The calculation base is a percentage with an explicitly defined meaning: markup on purchase cost (e.g., 1000 becomes 1300) or target margin (1000 becomes 1428). Even with the same percentage value of 30%, the resulting figures will differ. A fixed amount can also be added or used instead of a percentage to cover packaging, logistics, or commission costs. A custom rounding template can be set for each specific range.

To protect the catalog from errors on non-standard items, rules include strict constraints. The price cannot be lower than the purchase cost, purchase cost plus a percentage, a minimum markup in rubles, another price type, or a numeric product property such as the Minimum Retail Price (MRP), below which the supplier prohibits sales. The price also cannot exceed the Recommended Retail Price (RRP), defined as a separate price type or product property.

Thresholds are implemented to minimize unnecessary changes. If a price changes by less than a specified amount or percentage, the rule leaves it untouched. If the change exceeds the set limit, the price is not updated; instead, the item is moved to an error slice with the calculated value, while the catalog retains the original price. This helps identify faulty exports, such as when purchase costs arrive in kopecks instead of rubles. The module supports the creation of seasonal rules.

Pricing rules have a defined validity period. Seasonal markups, such as for the New Year, or temporary discounts, like those for a two-week period in August, are automatically enabled and disabled based on the schedule. Rules outside their active period are excluded from calculations and marked as inactive in the rules list, ensuring that issues are not attributed to incorrect date ranges.

Rounding templates and the creation of attractive prices are managed separately and can be reused by multiple profiles and rules. Configuration options include rounding steps (1, 0.5, 10, 100), specific price endings (e.g., …90, …99, …990, …999), and rounding direction: down, up, or according to mathematical rules.

The process is divided into two distinct stages: calculation and price application. The 'Calculate' action generates a draft document without modifying the current prices in the catalog. Each line in the report includes a 'Why' column detailing the applied rule, the base price, the rounding result, and any active limits.

Users can either post the entire document or deselect specific lines to exclude individual items. Products that should never be subject to a specific profile are added to the profile's exceptions list. These exceptions are respected by both manual runs and automated processes.

Products without a base price are not assigned a value of zero. Instead, they are placed in an error report and remain untouched. The system supports a run document and allows for rollback of changes.

Each calculation run is saved as a document. It records the profile, the rule snapshot at the time of calculation, the trigger source, statistics, and a list of all modified lines with 'before' and 'after' values.

The rollback feature compares the current price with the recorded 'after' value. If the price has been manually edited or updated via data exchange after installation, the module does not silently overwrite it. Instead, it detects the conflict and prompts the user to choose: overwrite or skip.

The document retention period is configurable.

Automatic Recalculation

The schedule can be set via a global preset or individually for each profile. In addition to the schedule, recalculation is triggered by changes to the source price. Modified items enter a queue and are processed in batches with a delay, preventing a single exchange of thousands of items from generating an equal number of runs.

Profiles support an active period and a dry-run mode: calculations occur according to the schedule, but prices are not applied until the results are reviewed.

Integration with 1C

This is the only area where the module requires user configuration rather than operating out of the box. Familiarization with this setup is recommended prior to purchase.

The standard exchange with 1C imports its own set of price types and deletes all others it does not recognize. Consequently, a scheme where the module applies a markup to the same price type updated by 1C is fundamentally unviable: either the exchange will overwrite the calculation, or markups will compound on top of each other, causing prices to skyrocket to their maximum limits within a week.

The only viable approach requires separating ownership of price types:

Price Type Owner Present in 1C Export

Purchase (or base from 1C) 1C Yes, this is the calculation source

Retail (for the storefront) Module No

A separate price type not included in the exchange is required for the storefront. The module protects these prices: if the exchange attempts to delete a price of this type, the deletion is rejected. The exchange itself completes successfully without causing system errors.

If a price type received from 1C is selected as the target, the profile form immediately displays a warning. Calculations for such a type will be overwritten by the next exchange, as 1C does not delete these prices but overwrites them. Matching the source and target types is prohibited at the form level.

Product offers

The module automatically calculates prices and markups for products with trade offers, applying them directly to the offers. The Bitrix core independently computes the parent product's price based on these offer values, making manual writing of the parent price redundant as the core will overwrite it within the same request. The module accounts for this behavior, and its default mode automatically determines the correct target for price assignment, allowing a single profile to handle both simple products and products with offers.

Multi-currency Support

Source prices in different currencies are converted to the profile's currency, ensuring that calculation rule ranges remain meaningful across a multi-currency catalog.

Access Levels

The module implements its own access control system, assigned to user groups via the 'Access' tab in module settings:

View profiles and documents without modification rights.

Configure profiles and calculate: rules can be edited, but catalog prices remain unchanged.

Full access: includes the ability to set prices with rollback functionality.

All price operations—calculations, setting, and rollback, performed manually or automatically—are recorded in the module's event log. The log supports filtering by profile and period, displays counters for processed and modified items, and includes links to run documents. Records of price updates or rollbacks are duplicated in the 1C-Bitrix core system log, allowing administrators to track changes in their standard location.

The module automatically reports the results of automatic runs via a banner in the administrative panel, email to specified addresses, or both simultaneously. Notification settings allow users to receive alerts for every run, only when changes or errors occur, or exclusively for errors. No notifications are sent for manual runs, as the results are immediately visible on the screen.

Environment requirements:

1C-Bitrix Site Management, main module version 20.0.0 or higher. The module is written in D7.

Information Blocks and Trade Catalog modules are required (edition with online store).

PHP version 8.1 or higher.

A free price type for the storefront is required, which is not exported from 1C. Details are in the "How it works with 1C" section.

Automatic recalculation is performed by an agent, so agents on the site must be configured to run via cron. If agents are running in hit mode, the module will display a warning on its settings page.

General iT can install and configure this module and check how it works on your website.