Yandex Delivery: calculation, pickup point selection on map, orders, and tracking

Fixes following feedback on version 0.7.13

• The pickup point map uses the buyer's location instead of the warehouse city. For cities without coordinates in Bitrix, server-side determination via the Yandex Delivery API has been added with city and region verification based on pickup point addresses and caching. If the API is unavailable or the city is ambiguous, a fallback center determination in the map is retained.

• Fixed saving of group access permissions in new Bitrix core versions after the Save and Apply buttons.

• A non-zero markup cannot be saved with the type None: the form explicitly requires selecting a percentage or a fixed amount.

• Own warehouses are excluded from the self-pickup point selection. A check has been added for saving and previously saved settings: an invalid source is not sent for calculation, and a hint to select a real drop-off point is displayed on the warehouses page.

• When changing the checkout city, the previously selected pickup point, its address, and options are reset so the order does not remain tied to a point in the previous city. A standard cart recalculation in the same city preserves the selection.

Fixed: the checkout page went blank after selecting a pickup point

• If the "Delivery address" property is bound only to courier services (the template does not output it for self-pickup, as is the case, for example, in Aspro templates), selecting a point on the map caused the entire checkout form to disappear from the screen. Now the form remains in place, and the pickup point address is written only to the address field that the template actually outputs.

• The "Delivery address" field, when self-pickup is selected, hides only its own row: adjacent fields and the checkout form no longer hide on any template.

Notifications for the module's admin page

• Notifications after actions in the module's admin section ("order created", "warehouse saved") are passed via session, not via the address bar, and are bound to their specific action: when working in multiple tabs, the message is not lost, does not appear in a neighboring tab, and is not overwritten by the next action.

• The update will automatically copy the fixed checkout script to /bitrix/js/yandekslogistika.delivery/; reinstalling the module is not required.

Fixed issues identified by the Marketplace security automated check

• The pickup point selected by the buyer is now validated on the server before saving the order and before creating the request: the point must exist in Yandex Delivery and pass the store widget filters (operators, point types, fitting room, post-payment, order payment method). It is no longer possible to enter an arbitrary point ID in the order form—the buyer will see an error and select another point.

• Pickup options hidden from the buyer ("Do not show buyer options") are resolved by the server based on "default" settings, not values from the order form: enabling hidden fitting or partial pickup via POST is not allowed. The API link "partial pickup implies fitting" is accounted for: hidden fitting is not enabled via partial pickup, and if fitting is hidden and not enabled by default, partial pickup is also hidden.

• Manual packaging of cargo units from the request card is saved with a signature and verified against the order cart: it is not possible to enter box composition, weight, or dimensions via the checkout form; unsigned values are ignored, and the request is assembled based on the cart. Packaging manually defined prior to the update must be saved again in the request card.

• The pickup point map page opens only with a signed token issued by the server when the delivery tile is displayed during order checkout. The token is bound to the buyer's session: a copied token does not work in another browser. The self-pickup point selection mode (store data) is available only to staff with rights to the module.

• Price calculation by point on the map is performed only for the current buyer's cart (parameters are taken from their session, not from the request address), so it is not possible to calculate costs for arbitrary weight and total amount.

• Request rate limiting for the map and price calculation is tracked per buyer session, by IP, and in the core cache for the site, not within the session. A new setting "Daily API call limit from the Pickup Point widget" ("Connection and Cache", default 20,000) has been added: once exhausted, the widget returns only cached responses and does not consume the store's token quota.

• The update will automatically re-copy the updated checkout script to /bitrix/js/yandekslogistika.delivery/; reinstalling the module is not required.

The 'Select Pickup Point' button opens a map. Previously, if a pickup profile was already selected:

• On checkout templates where the delivery method description is displayed within the tile (a list with toggles), the button only worked before the 'Pickup from Pickup Point / Locker' profile was selected. After selecting the profile, clicking the button was intercepted by the template as a re-selection of the same delivery, and the map did not open. Now, the button opens the map of pickup points in both cases.

• The update will automatically copy the corrected checkout script to /bitrix/js/yandekslogistika.delivery/; reinstalling the module is not required.

The text and styling of the 'Select Pickup Point...' call-to-action can be configured:

• In the module settings ('Checkout' → 'Text for selecting pickup point' and 'CSS style for call-to-action'), you can replace the hint displayed in the pickup tile before a point is selected, as well as its styling. Leaving fields empty retains the original text and the red bold style.

In the Yandex Delivery cabinet, the store order number is now displayed.

• Previously, the "Order Number" column in the cabinet contained a module service key in the format yd-121909-226975, requiring manual matching of the request to the order. Now, the store order number is sent there—the same number seen by the buyer and printed on documents.

• In the module settings ("Business Rules" → "Order Number for Yandex Delivery"), you can choose what to send: the store order number (default), the internal order ID, or the previous service key (if you are already matching requests by that key).

• This setting applies only to new requests; the number in the cabinet for previously created requests remains unchanged.

• The service "Request Identifier" (displayed in the cabinet as "ID in Delivery") is issued by Yandex Delivery itself and cannot be replaced with the order number: tracking, labels, acts, and cancellations rely on it. Both numbers are now displayed side by side in the request card.

The "Create Request" button accurately shows the result

• Previously, after clicking, a green message "Ready. Requests created: 0; skipped: 0" always appeared—whether the request was successfully created or rejected by Yandex Delivery. A failed creation looked successful, and the reason had to be found in the requests table below on the page.

• Now, counters show the actual result, and rejections are displayed as a red error message with the error text and shipment number. If there are multiple shipments, it shows how many requests were created and exactly which ones failed.

• If an order has no Yandex Delivery shipments, the module states this explicitly instead of showing "Created: 0".

Failed requests are no longer lost silently

• The module automatically creates a request when the order transitions to the status specified in "Business Rules" → "Create request on order status". Previously, if Yandex Delivery rejected the request (e.g., buyer's phone not provided, module not configured, or temporary service error), the order status changed without creating a request, and the manager would only discover this by manually opening the request card.

• Now, each such rejection is logged in the Bitrix Event Log («Settings» → «Tools» → «Event Log»), with the event type «Yandex Delivery: order not created». The record displays the order number, status, shipment number, and the error text from Yandex Delivery.

• A separate record is also created for another silent case: the order has reached the required status, but it contains no shipments with module profiles, so no order will be created.

Orders with multiple items no longer hit the pickup point limit

• The module still declares the order as a single shipment—this keeps delivery costs lower, and for standard orders, nothing changes.

• Previously, if such a shipment did not meet the pickup point restrictions, all pickup points became unavailable for selection: an order with two boxes of 13 kg each could not be delivered, even though each box individually met the restrictions.

• Now, in this case, the module automatically recalculates the order by boxes—one per item—and offers delivery at its actual cost. The price will increase only where delivery would otherwise be impossible.

• The same logic applies when creating an order, so the order is sent to Yandex Delivery in the same box configuration used to calculate delivery for the customer.

• You can still manually specify your own packaging in the order card—it takes precedence over automatic packaging. The «Auto-distribute (1 box = entire cart)» button gathers everything into one box, as the module does by default; the new «One box per item» button distributes the order by items—for orders that do not fit within a single box's pickup point restrictions.

Free delivery is also free on the pickup point map

• The pickup point selection widget considers delivery discounts from «Cart Working Rules» (including «Free delivery from order amount»). Previously, the map showed the Yandex Delivery tariff, but after selecting a point, the cart would reset the cost to zero—the customer would see two different prices.

• When the cost is zero, the point card displays «free» instead of «0 RUB».

• Changes to the module's business rules and cart rules are applied in the widget immediately, without waiting for the price cache to expire.

Live mode by default

• Test mode ("Connection" → "Test mode") is no longer enabled by default: a new installation immediately works with the live Yandex Delivery circuit. For already installed stores, the mode does not change—the saved setting remains in effect.

An order for self-pickup from a pickup point is placed with a mandatory "Delivery Address"

• Previously, when a pickup point was selected, the "Next" button during checkout could respond with "Fill in the required field 'Delivery Address'": the self-pickup field was hidden, and the mandatory check was enabled for most stores. Now, the address of the selected point is automatically recorded in the "Delivery Address"; it is included in the order and documents. When switching to a courier, the pre-filled address is removed.

• The pickup point map opens for the buyer's city without a Yandex Maps key: the city coordinates are now correctly passed to the widget again.

Module settings are no longer lost upon reinstallation

• A confirmation step with the 'Save module data' checkbox enabled has been added when uninstalling the module: the token and connection settings, pickup addresses, order status mapping, and request history remain in the system. Previously, data was always deleted, causing all store settings to be reset when updating via 'uninstall → install'.

• Reinstalling on top of saved data automatically applies them without requiring reconfiguration.

Courier call for pickup

• Fixed the 'missing required field 'parameters'' error when calling a courier: the mandatory cargo parameters block has been added to the request.

• The courier call form now includes fields for 'Volume, m³', 'Weight, kg', and 'Movers required' — these are sent to Yandex Delivery.

Order placement

• Until the buyer specifies a city or address, courier delivery displays the hint "Specify the city or delivery address" instead of "Calculation service temporarily unavailable"; invalid API requests are eliminated with every recalculation.

• The "Delivery address" field no longer remains hidden after switching from self-pickup to courier or other delivery types — including on non-standard order checkout templates.

• New setting "Property code: location" (Checkout tab) — which order property to use to obtain the buyer's city for the pickup point map. Empty means auto-detection, as before.

• Calculation accuracy: the updated cost calculation, taking the order payment method into account, is now available for stores updated with the package from version 0.7.6.

Pickup point map

• The map opens in the city selected by the buyer during order checkout — now even without a configured Yandex Maps API key (coordinates for major cities are embedded in the module).

• The map no longer requests points without area boundaries — this could exhaust server memory on hosting with typical limits.

Access and diagnostics

• New "Access" tab in module settings: module access rights can be granted to a user group (view or full access) — store managers can work with Yandex Delivery orders without full administrator rights.

• API request log: each record includes a request identifier (trace_id) for contacting Yandex Delivery support; the new "Detailed log" option supplements records with request and response bodies, masking buyers' personal data.

• The Yandex Delivery order includes the module identifier — the order source is visible in Yandex Delivery statistics.

Try-on and partial purchase during order checkout

• The buyer can select try-on and partial purchase — under the selected pickup point or under the courier delivery cost. This selection is sent to the Yandex Delivery order.

• In pickup points, options are displayed only where they are actually available.

Payment method — per order

• New setting "Postpaid payment systems" (tab "Business rules"): select payment systems for which the buyer pays upon receipt. The payment method in the order is determined by the specific order: if paid — "paid in advance"; if not paid but with a postpaid payment system — "postpayment upon receipt". If nothing is selected, the global setting works as before.

• For postpayment, pickup points that do not accept payment upon receipt are always hidden from the map — previously, the buyer could select such a point, and the order would not be placed.

• If postpaid payment systems are configured, the map and delivery cost adjust according to the payment system selected by the buyer during order checkout.

Pickup point selection widget

• Operators and point types hidden in the module settings are no longer displayed in the widget filters.

• A new setting has been added to remove unnecessary filter groups from the widget.

• The pickup point card no longer extends beyond the map boundaries — long descriptions are collapsed.

Fixing the selection of self-pickup points

• The list of drop-off points now displays Yandex Delivery sorting centers, not just pickup points.

• Sorting centers are displayed at the beginning of the list and marked with the type "Sorting Center".