Configuring Counterparty Contract Exchange Between 1C and 1C-Bitrix
In B2B online stores and wholesale portals, contracts are more than just documents. A contract defines: the price a client works at, their credit limit, and their delivery terms. Without transferring contracts from 1C to 1C-Bitrix, the site cannot display correct prices and conditions for a specific counterparty.
The role of a contract in 1C
In UT, KA, and ERP, a counterparty contract (CounterpartyContracts) is the key pricing object. The contract is linked to:
- Price type — which price list applies to this client
- Discounts — personal or contract-level discounts
- Settlement currency
- Credit limit and credit period
- Payment terms (prepayment, post-payment, days of deferral)
If a client in 1C has 3 active contracts (e.g., retail, wholesale, and special), on the site they should see prices according to the relevant contract and be able to select a contract at checkout.
Contract transfer: architecture
Standard CommerceML does not transfer contracts. Custom synchronization via a 1C HTTP service or file exchange is required.
Minimum contract data set for the website:
{
"guid": "a1b2c3d4-1234-...",
"number": "C-2024-0015",
"name": "Supply Contract No. 15 dated 01.03.2024",
"contractor_guid": "counterparty-guid",
"price_type_guid": "price-type-guid",
"price_type_name": "Wholesale",
"credit_limit": 500000,
"payment_delay_days": 14,
"currency": "RUB",
"valid_from": "2024-03-01",
"valid_to": "2025-03-01",
"is_active": true
}
In 1C-Bitrix, contracts are stored in a HighloadBlock ContractorContracts. When the catalog is opened, the user's active contract is determined and linked to the price type in the trade catalog.
Mapping a contract to a price in 1C-Bitrix
The key task: a user with a specific contract must see prices from the associated price type.
Implementation:
- Upon user login — determine their contract(s) from the HighloadBlock
- Determine the price type from the contract (
price_type_guid→ price type ID in 1C-Bitrix) - Set a session variable or user parameter
CURRENT_PRICE_TYPE - The catalog component reads this variable and displays prices of the required type
If the user has multiple contracts — provide a selection in the personal account: "Work under contract No. ...". The selection is saved in the session.
Contract synchronization: frequency
Contracts change rarely — a new contract is signed once a year, terms are revised quarterly. Synchronizing once per hour or even once per day is sufficient.
However, there is a critical scenario: a contract is terminated or has expired — the client must not continue to see wholesale prices. To handle this, add a valid_to check to the authentication logic. If the date has passed — switch the user to the base price type.
Contract at checkout
When transferring an order from 1C-Bitrix to 1C, the contract under which the order is placed must be specified. In the order XML:
<ЗначениеРеквизита>
<Наименование>ContractId</Наименование>
<Значение>a1b2c3d4-1234-...</Значение>
</ЗначениеРеквизита>
In UT, when creating a customer order, the contract is taken from this attribute. Without a contract — the order is created using the default (the counterparty's first active contract), which may lead to incorrect pricing in 1C documents.
Case study: distributor with individual terms
A medical equipment distributor: 180 dealers, each with an individual contract with their own price (discount from 5% to 40% off retail). All prices are maintained in UT as separate price types for each dealer (18 price types).
Website objective: each dealer upon login sees only their own prices; other dealers' prices are inaccessible.
Implementation:
- Contract synchronization from UT to 1C-Bitrix — every 2 hours
- Upon login — the contract is identified, and the price type GUID is extracted from it
- The GUID is mapped to a price type in 1C-Bitrix (mapping table in settings)
- The catalog displays prices of the required type
Additionally: each dealer has a "supervising manager" in UT. When an order is placed on the site, the manager is automatically added to the order (from the contract field ResponsibleManager). The manager in UT immediately sees their client's order.
Expiry and automatic renewal
When a contract is about to expire — N days before expiry, a notification is sent to the responsible manager in Bitrix24 (via REST API). A scheduled task in 1C-Bitrix checks the valid_to of all contracts daily.
// Contract expiry check agent
function checkContractExpiry() {
$soon = date('Y-m-d', strtotime('+30 days'));
$contracts = getContractsExpiringBefore($soon);
foreach ($contracts as $contract) {
notifyManager($contract['manager_id'], $contract);
}
return 'checkContractExpiry()'; // agent reschedules itself
}