Цель сверки — выявить расхождения между структурой сайта и данными в 1С (товары, услуги, цены). Подготовка данных включает выгрузку актуального каталога из 1С и формирование списка URL сайта. Алгоритм сопоставления строится на привязке URL по параметрам (slug, ID) и проверке статусов страниц. Критерии расхождений: наличие в 1С без страницы на сайте, страница на сайте без данных в 1С, устаревшие цены. Формирование отчета требует группировки ошибок по типам (технические, контентные, коммерческие). Исправление проблем включает создание недостающих страниц, обновление контента и синхронизацию цен. Автоматизация процесса подразумевает настройку периодических проверок и уведомлений о критичных ошибках. Ограничения метода требуют учета редиректов, дублей и специфических URL-структур.
Цель сверки: выявление расхождений между структурой сайта и данными в 1С
Основная задача контрольной сверки — найти несоответствия между тем, что отображается на сайте для пользователя, и тем, что хранится в базе данных 1С. Эти расхождения возникают из-за разницы в логике работы двух систем: сайт ориентирован на индексацию поисковиками и удобство чтения, а 1С — на учет товаров, услуг и финансовых операций. Без регулярной проверки эти системы расходятся.
Типичные проблемы, которые выявляет сверка, делятся на три группы. Первая группа — наличие в базе данных 1С карточек товаров или услуг, для которых на сайте нет соответствующих страниц. Это может быть связано с удалением позиций из ассортимента без обновления базы сайта или ошибочным созданием новых номенклатурных единиц. Вторая группа — страницы на сайте, которые не имеют привязки к данным в 1С. Такие элементы часто появляются при ручном создании посадочных страниц или ошибках при переносе контента, что приводит к потере коммерческих сигналов для поисковиков. Третья группа — расхождение в актуальных данных: цены, остатки или статусы товаров в 1С отличаются от того, что отображается на сайте. Это критично для интернет-магазинов и сервисов, где пользователь принимает решение о покупке на основе текущих условий.
Игнорирование этих расхождений ведет к прямым финансовым потерям. Если цена в карточке товара в 1С снижена, а на сайте отображается старая стоимость, компания теряет конкурентное преимущество и может получить жалобы клиентов. Отсутствие страниц для актуальных товаров снижает индексацию сайта и лишает поисковики возможности показывать релевантные результаты по запросам пользователей. Кроме того, расхождения мешают автоматическим системам анализа (например, AI-поиску), так как они не могут корректно сопоставить сущности без четкой структуры данных.
Сверка позволяет систематизировать работу над сайтом и базой данных. Она превращает хаотичные правки в управляемый процесс: сначала выявляются проблемы, затем приоритизируются по степени влияния на бизнес-задачи (продажи, трафик), после чего выполняются необходимые изменения. Такой подход заменяет ручную проверку повторяемым алгоритмом, который фиксирует ошибки индексации, битые ссылки и несоответствия коммерческих факторов. Результатом работы становится структурированный список проблем с указанием их типа и критичности, что позволяет специалисту сосредоточиться на решении наиболее важных задач.
Подготовка данных: выгрузка актуального каталога из 1С и формирование списка URL сайта
Первый этап построения сверки — получение двух исходных массивов для сравнения. С одной стороны это список всех страниц, доступных поисковым системам и пользователям, с другой — актуальная база товаров или услуг из информационной системы 1С. Без корректной подготовки этих данных дальнейший анализ невозможен, так как любые расхождения будут интерпретироваться ошибочно.
Для формирования списка URL сайта используется инструмент веб-скрейпинга или специализированные модули (например, на базе Python с библиотеками requests и BeautifulSoup). Скрипт проходит по главной странице и всем внутренним ссылкам, сохраняя структуру папок и параметров. Важно учитывать динамические параметры в адресах: фильтры по категориям, цене, бренду или региональным маркерам. Если сайт использует SPA-архитектуру (Single Page Application), стандартный скрейпинг не сработает, потребуется эмуляция браузера через headless режим или использование API сайта.
Выгрузка данных из 1С выполняется через механизм обмена данными или прямое подключение к базе по протоколу ODBC/OLE DB. В конфигурации создаются отчеты, которые формируют текстовые файлы (CSV, XML) с полями: артикул, название, цена, статус наличия и ссылка на карточку товара в интернет-магазине. Критически важно убедиться, что ссылки в 1С совпадают по структуре с реальными URL на сайте. Часто встречается ситуация, когда в базе хранится устаревшая ссылка после редизайна сайта или перехода на новую структуру каталога.
После получения файлов их необходимо привести к единому формату. В файле со списком страниц удаляются дубликаты и фильтры без контента (например, пустые категории). В выгрузке из 1С проверяется корректность кодов ошибок и статусов товаров. Если в базе есть товары с нулевой ценой или статусом «недоступен», но на сайте они отображаются как активные, это уже сигнал о расхождении, которое будет зафиксировано на следующем этапе сопоставления.
Алгоритм сопоставления: привязка URL по параметрам (slug, ID) и проверка статусов страниц
Сопоставление данных из двух источников — списка страниц сайта и выгрузки из 1С — требует строгого алгоритма. Основная задача этого этапа — найти соответствие между каждым товаром или услугой в базе учета и его представлением на сайте. Без точной привязки дальнейший анализ будет невозможен, так как нельзя корректно оценить расхождения, если неизвестно, какой именно элемент из 1С сравнивается с какой страницей сайта.
Первый шаг — определение ключа сопоставления. В идеальном случае используется уникальный идентификатор товара (SKU или ID), который присутствует и в базе 1С, и в URL-адресе страницы на сайте (в параметре slug). Если такой прямой связи нет, приходится использовать комбинацию характеристик: название категории, артикул производителя и основные параметры товара. Важно учитывать, что структура URL может меняться: один и тот же товар может иметь разные ссылки при обновлении структуры сайта или использовании синонимов. Скрипт должен уметь работать с несколькими вариантами ключей, начиная от самого надежного (ID) до менее точных (название + категория).
Второй шаг — проверка статусов страниц. После того как URL сопоставлены, необходимо сверить их состояние. Статус страницы на сайте определяется через проверку HTTP-кода ответа (200 — страница доступна, 404 — не найдена, 301/302 — редирект) и наличие контента в ответе. В базе 1C статус товара может быть «Активен», «Недоступен» или иметь нулевую цену. Расхождение возникает, когда товар активен в 1С, но страница на сайте возвращает ошибку 404, либо наоборот — страница существует, а в 1С товар скрыт. Также проверяется соответствие цены: если в 1C цена обновлена, а на сайте отображается старая стоимость, это фиксируется как расхождение коммерческого фактора.
Третий шаг — обработка исключений и дублей. Часто на сайте существуют страницы-дубликаты или категории без контента, которые не имеют аналогов в 1С. Алгоритм должен маркировать такие случаи отдельно, чтобы они не мешали анализу основных расхождений. Если страница на сайте ведет на архивный товар (редирект), скрипт должен отслеживать целевую страницу и проверять её статус относительно текущих данных в 1С. Это позволяет выявить устаревшие ссылки, которые могут снижать качество сайта и индексацию.
Результатом этого этапа становится таблица соответствий, где каждая строка содержит ID товара из 1С, URL страницы на сайте, статус HTTP-ответа, текущую цену в базе и цену на странице. Эта таблица служит основой для формирования отчета о расхождениях. На этом этапе не требуется глубокий анализ контента — достаточно зафиксировать факт наличия или отсутствия соответствия и технические параметры страниц. Дальнейшая работа будет строиться именно на этих данных: выявлении битых ссылок, устаревших цен и отсутствующих товаров.
Критерии расхождений: наличие в 1С без страницы на сайте, страница на сайте без данных в 1С, устаревшие цены
При сопоставлении каталога сайта с данными из 1С выявляются три основных типа несоответствий. Каждый из них требует отдельного подхода, так как причины их возникновения и последствия для бизнеса различаются.
Первый тип — товары или услуги, записанные в базе 1С, но отсутствующие на сайте. Это наиболее частая ситуация при работе с интернет-магазинами или каталогами услуг. Причины могут быть разными: товар снят с производства, услуга временно не предоставляется, страница удалена после рефакторинга кода или произошла ошибка при переносе данных. Если в 1С есть запись о товаре, а на сайте нет соответствующей страницы (или она возвращает ошибку 404), поисковые системы теряют возможность индексировать актуальную информацию. Пользователь, кликнувший по ссылке из поиска или каталога, получает ошибку, что снижает доверие и конверсию.
Второй тип — страницы на сайте, не отраженные в 1С. Это может быть устаревший контент, который был удален из базы данных, но остался в файловой системе сайта, либо новые посадочные страницы, созданные вручную для SEO-продвижения и еще не переданные в учетную систему. Также сюда относятся тестовые страницы или страницы с ошибками 403/500, которые роботы сканируют как обычные ресурсы. Наличие таких страниц создает «шум» в данных: поисковики могут индексировать мусор, а рекламные кампании будут показывать клики по несуществующим товарам.
Третий тип — расхождения в коммерческих параметрах, прежде всего ценах. В 1С хранится актуальная себестоимость или рекомендованная розничная цена, которая может меняться ежедневно. На сайте же цена часто обновляется не синхронно с базой данных, а вручную или через отдельный модуль. Если на странице указана старая цена, это прямой финансовый ущерб при продаже и нарушение условий договора с клиентом. Кроме того, поисковые системы могут ранжировать страницу ниже конкурентов, если видят несоответствие цены в тексте страницы и в атрибутах товарного предложения (schema.org).
Для каждого типа расхождений необходимо определить приоритет исправления. Отсутствие товара на сайте при его наличии в 1С требует либо создания страницы с информацией о снятии с продаж, либо удаления записи из каталога в 1С. Лишние страницы на сайте нужно проверять на релевантность: если они не несут ценности для пользователя и поисковика, их следует удалить или редиректить на актуальные аналоги. Расхождения в ценах требуют настройки автоматической синхронизации или регламентных заданий, которые будут обновлять данные на сайте при изменении цен в 1С.
Важно учитывать технические нюансы: иногда страница существует, но заблокирована для индексации через robots.txt или meta-тег noindex. В этом случае расхождение формально есть (в 1С товар есть, а поисковик его не видит), но фактически проблема решается настройкой доступности. Также следует проверять редиректы: если старая страница перенаправляет на новую, то в 1С может сохраняться запись о старом товаре, хотя на сайте он уже недоступен. Такие ситуации нужно выявлять и приводить базу данных в соответствие с текущей структурой сайта.
Формирование отчета: группировка ошибок по типам
Результат сверки — не просто список найденных несоответствий, а структурированный отчет, разделенный на логические блоки. Это необходимо для того, чтобы команда разработки или контент-менеджера могла сразу понять масштаб задачи и распределить ресурсы. В основе группировки лежит классификация расхождений по их природе: технические проблемы, влияющие на доступность; контентные ошибки, связанные с несоответствием смыслов; коммерческие факторы, нарушающие условия покупки.
Технические ошибки требуют немедленного вмешательства разработчиков или системных администраторов. Сюда относятся битые ссылки (404), страницы, заблокированные для индексации, но присутствующие в базе 1С, а также проблемы с редиректами. Если в 1С есть товар, а на сайте по соответствующему URL возвращается ошибка доступа или страница не индексируется, это технический барьер. Такие расхождения снижают общую видимость сайта и могут привести к потере трафика, так как поисковые системы не могут корректно обработать запросы на несуществующие или недоступные адреса.
Контентные ошибки касаются качества информации на страницах и их соответствия данным в базе. К ним относятся устаревшие описания товаров, отсутствие ключевых характеристик, несоответствие названий в 1С и на сайте, а также проблемы с мета-тегами (title, description). Если в 1С товар имеет название «Видеокарта RTX 3060», а на сайте страница называется просто «Товар №12345», поисковик не сможет связать запрос пользователя с нужной страницей. Также сюда относятся страницы-пустышки: URL существует, но контент отсутствует или слишком общий, что ухудшает пользовательский опыт и снижает доверие.
Коммерческие факторы — это ошибки, влияющие на возможность совершить покупку. Сюда входят устаревшие цены в 1С по сравнению с актуальными данными на сайте (или наоборот), отсутствие информации о наличии товара, неверные условия доставки или оплаты. Если в базе 1С цена обновлена до новой, а на сайте отображается старая стоимость, это создает конфликт ожиданий клиента и повышает риск возвратов или жалоб. Также к этой группе относятся страницы с формами заявки, которые не работают корректно из-за отсутствия данных о товаре в 1С, что блокирует конверсию.
После классификации каждый тип ошибок должен быть оценен по степени критичности. Технические ошибки часто имеют высокий приоритет, так как они полностью блокируют доступ к ресурсу. Контентные расхождения могут иметь средний приоритет: их можно исправить при следующей публикации или обновлении карточки товара в 1С. Коммерческие ошибки требуют оперативной реакции, особенно если речь идет о ценах на популярные товары или условиях акции. Приоритизация позволяет сфокусироваться на исправлении наиболее вредных проблем первыми.
В отчете важно указывать не только тип ошибки, но и конкретные примеры: URL страницы, ID товара в 1С, ожидаемое значение и фактическое. Это упрощает работу исполнителя, так как ему не нужно вручную искать информацию о расхождении. Для автоматизации процесса можно настроить скрипт, который будет генерировать отчет в формате CSV или JSON с колонками для типа ошибки, приоритета, ссылки на страницу и ID записи в 1С. Такой формат удобен для интеграции с системами управления задачами (например, Jira или Trello), где каждый пункт отчета можно превратить в отдельную карточку задачи.
Ограничения метода группировки заключаются в том, что автоматическая сверка не может оценить смысловую ценность контента. Скрипт заметит, что текст на странице отличается от описания в 1С, но не поймет, является ли это ошибкой или уместным изменением стиля. Также алгоритм не сможет определить тонкие нюансы юзабилити, например, неудобное расположение кнопки «Купить» или плохую читаемость шрифта. Поэтому после автоматической группировки отчет должен быть проверен специалистом, который подтвердит или скорректирует классификацию ошибок.
Практический пример: при сверке каталога интернет-магазина выявлено 50 расхождений. Из них 10 — технические (битые ссылки), 20 — контентные (устаревшие описания), 20 — коммерческие (неверные цены). Отчет формируется в виде таблицы с колонками: тип, приоритет, URL, ID в 1С, комментарий. Команда разработки получает список из 10 технических ошибок и исправляет их за один день. Контент-менеджеры обновляют описания для 20 товаров, а отдел продаж проверяет цены на оставшиеся позиции. Такой подход позволяет быстро привести сайт в соответствие с данными базы и улучшить его показатели.
Итоговый отчет должен быть понятным и actionable (действенным). Избегайте формулировок вроде «некорректные данные», вместо этого пишите конкретно: «цена в 1С отличается от цены на сайте» или «на странице отсутствует описание характеристик». Это экономит время исполнителей и снижает количество уточняющих вопросов. Если расхождение связано с редиректом, укажите его тип (301, 302) и целевой URL, чтобы разработчик мог настроить правильный перенаправление.
Для долгосрочной работы полезно настроить автоматическую отправку отчета по расписанию, например, раз в неделю или после каждого обновления базы в 1С. Это позволит отслеживать динамику исправления ошибок и не допускать накопления проблем. Если критичная ошибка (например, битая ссылка на главный товар) обнаружена вне графика, система должна отправлять уведомление в мессенджер или на email ответственного сотрудника. Такой подход превращает сверку из разовой задачи в часть регулярного процесса поддержки сайта.
Исправление проблем: создание недостающих страниц, обновление контента, синхронизация цен
После формирования отчета сверки перед вами окажется список расхождений. Каждый пункт требует конкретного действия, но порядок их выполнения зависит от критичности для бизнеса. Начинать следует с устранения ошибок, блокирующих продажи или нарушающих техническую целостность сайта, а затем переходить к оптимизации контента.
Первым шагом является создание недостающих страниц. Если в 1С есть карточка товара или услуги, но на сайте нет соответствующей страницы, это прямая потеря потенциальных клиентов. Алгоритм действий: берете URL из отчета сверки (или формируете его по шаблону slug), создаете страницу с использованием стандартной структуры шаблона категории или отдельного шаблона для карточки. Обязательно заполните базовые SEO-поля: заголовок H1, мета-описание и уникальное описание товара/услуги. Не копируйте текст из 1С слово в слово, если там нет маркетинговых формулировок — адаптируйте его под стиль сайта, добавляя призывы к действию.
Второй этап — обновление контента на существующих страницах. Сверка часто выявляет устаревшие описания или отсутствие актуальных данных. Проверьте, соответствуют ли тексты на сайте текущим условиям работы компании. Если в 1С изменились характеристики товара (например, добавился новый цвет или размер), эти данные должны быть отражены на странице. Для этого используйте механизмы динамического подтягивания данных из CRM или вручную обновляйте блоки «Характеристики» и «Описание». Важно не перегружать страницу лишней информацией, а сохранять баланс между полнотой данных и читабельностью.
Третий шаг — синхронизация цен. Расхождения в ценах между сайтом и 1С могут привести к потере доверия клиентов и проблемам с показом в поиске (особенно в Google, где важна актуальность коммерческих факторов). Настройте автоматический скрипт или используйте плагины CMS, которые будут подтягивать цены из 1С при каждом обновлении базы. Если синхронизация невозможна автоматически, установите регламент: проверка цен раз в неделю и их внесение вручную с фиксацией изменений. Следите также за наличием актуальных акций и скидок — они должны быть отражены как на сайте, так и в 1С.
При исправлении проблем важно учитывать ограничения метода. Например, если страница на сайте создана, но не индексируется из-за технических ошибок (битые ссылки, блокировки robots.txt), простое создание страницы не поможет. Сначала устраните технические барьеры, затем обновляйте контент. Также помните, что изменение URL или контента может повлиять на позиции в поиске — для таких страниц предусмотрите период наблюдения и мониторинг переходов.
Для контроля качества исправлений используйте инструменты аналитики: проверяйте, растут ли переходы на новые страницы, увеличивается ли время на сайте после обновления контента. Если цена изменилась, следите за конверсией — иногда резкое изменение цены может временно снизить количество заявок. В таких случаях стоит добавить поясняющий текст или временную метку изменения условий.
В долгосрочной перспективе эффективнее всего внедрить регулярный цикл исправлений: еженедельная сверка, ежемесячный аудит контента и квартальная проверка технической базы. Это позволит поддерживать сайт в актуальном состоянии без накопления ошибок. Автоматизируйте рутинные задачи — например, отправку уведомлений о новых расхождениях или создание черновиков страниц для быстрого наполнения.
Автоматизация процесса: настройка периодических проверок и уведомлений о критичных ошибках
Полная синхронизация каталога сайта с данными из 1С требует перехода от разовых ручных сверок к циклическому процессу. Настройка автоматического мониторинга позволяет выявлять расхождения сразу после их возникновения, а не через недели или месяцы. Это критически важно для коммерческих сайтов, где устаревшая цена или отсутствующая карточка товара ведут к потере заявки.
Основой системы является планировщик задач (cron-задачи на сервере или аналогичные механизмы в облачных средах). Скрипт сверки запускается по расписанию: например, раз в сутки для проверки наличия страниц и цен, а раз в неделю — для глубокого анализа структуры. При каждом запуске скрипт выгружает актуальный список товаров/услуг из 1С, формирует список URL сайта и сравнивает их. Если расхождение обнаружено (товар есть в базе, но нет на сайте или цена изменилась), система генерирует событие.
Уведомления должны быть настроены с учетом приоритета ошибки. Критичные проблемы — отсутствие посадочной страницы под активный товар, изменение цены без обновления на сайте, битая ссылка на услугу — требуют немедленного внимания. Для таких случаев настраивается мгновенное оповещение в мессенджер или на email ответственного специалиста. Менее важные несоответствия (например, устаревший текст описания, не влияющий на продажу) могут накапливаться и обрабатываться в следующем цикле.
Важно разделить типы уведомлений по источнику данных. Если расхождение возникло из-за изменений в 1С (новый товар добавлен менеджером), система должна сразу предупредить разработчика или контент-менеджера о необходимости создания страницы. Если проблема в отсутствии товара в 1С, но страница на сайте существует, это сигнал к удалению устаревшего контента или перенаправлению URL. Автоматизация не заменяет принятие решения, но экономит время на поиск проблемы.
Для оценки эффективности автоматизации отслеживайте метрики: время реакции на ошибку (от момента появления расхождения до начала исправления), количество пропущенных заявок из-за битых ссылок и долю страниц, требующих обновления контента. Цель — свести время простоя страницы к нулю. Если система настроена правильно, вы получаете отчет о состоянии сайта не как итог месяца, а как текущий статус в реальном времени.
Ограничения автоматизации связаны с качеством исходных данных. Скрипт может корректно сопоставить URL по slug или ID, но он не поймет контекст: например, что товар временно снят с продажи и его страницу нужно скрыть, а не удалить. Такие нюансы требуют ручной настройки правил в скрипте или интеграции со статусами товаров в 1С. Также автоматизация не учитывает сезонные изменения спроса или маркетинговые акции, требующие временного отключения страниц.
Ограничения метода: учет редиректов, дублей и специфических URL-структур
Автоматическая сверка каталога работает по жестким правилам сопоставления данных. Скрипт сравнивает URL сайта с записями в базе 1С, опираясь на точное совпадение адресов или идентификаторов (slug, ID). Однако реальные сайты часто содержат элементы, которые нарушают эту строгую логику. Если алгоритм не настроен специально, он будет трактовать такие ситуации как ошибки.
Первой проблемой являются редиректы. При проверке скрипт видит страницу по старому адресу и получает ответ 301 или 302 на новый URL. Без специальной настройки правил сопоставления система посчитает это расхождением: в базе есть запись по старому адресу, а на сайте «показывает» новый. Это приведет к ложному срабатыванию алертов о битых ссылках или устаревших страницах.
Второй критический момент — дубли страниц и специфические URL-структуры. В интернет-магазинах часто используются фильтры, сортировка и параметры запроса (например, ?sort=price&filter=category). Каждый такой вариант формирует отдельную страницу с уникальным URL. Если сверка не настроена на игнорирование параметров или группировку по основной странице категории, скрипт создаст тысячи ложных ошибок, указывая на дублирование контента там, где его нет.
Также стоит учитывать динамические URL и кэширование. Некоторые CMS генерируют адреса с хешами или временными метками. Если база 1С хранит товар под статическим slug, а сайт выдает адрес с параметром сессии, сопоставление не пройдет. Скрипт должен быть запрограммирован на нормализацию URL: удаление лишних параметров и сравнение только базовой структуры пути.
Еще одно ограничение связано с состоянием страниц. Автоматизация фиксирует наличие записи в базе и доступность ресурса по HTTP-запросу, но не анализирует бизнес-логику. Страница может быть доступна технически (код 200), но содержать сообщение «Товар временно недоступен» или иметь скрытый блок с ценой. Скрипт интерпретирует это как ошибку контентной части, хотя на деле это штатная ситуация управления ассортиментом.
Для корректной работы метода необходимо заранее определить правила обработки исключений. В конфигурации проверки нужно задать список допустимых параметров URL, которые игнорируются при сверке. Также следует настроить обработку кодов редиректов: если страница возвращает 301 на другой адрес из каталога, система должна считать это корректным переходом, а не ошибкой.
Оценка качества сверки требует анализа логов сопоставления. Если количество ложных срабатываний превышает определенный порог (например, более 5% от общего числа проверенных страниц), значит, алгоритм не учитывает специфику URL-структуры сайта. В этом случае требуется пересмотр правил нормализации адресов или добавление исключений для конкретных категорий товаров.
Итоговый отчет должен содержать не только список ошибок, но и классификацию их типа: технические (битые ссылки), логические (неправильное сопоставление редиректов) и контентные (отсутствие данных). Без четкого разделения этих групп невозможно понять, где нужно исправлять код сайта, а где настраивать логику скрипта сверки.
Вопросы и ответы
Как сопоставить товары из 1С и страницы сайта, если URL-адреса отличаются?
Используйте уникальный идентификатор (ID) или slug товара как ключевое поле для привязки. Если сайт использует динамические ссылки с параметрами, настройте скрипт сверки на фильтрацию по этим параметрам перед сравнением.
Что делать, если в 1С есть товар, но на сайте он заблокирован или удален?
Такой расхождение фиксируется как «товар в базе без публичной страницы». Это требует проверки: либо страницу нужно восстановить и активировать, либо удалить запись из каталога 1С, если товар действительно не продается.
Как часто следует проводить автоматическую сверку?
Частота зависит от скорости обновления цен и ассортимента. Для интернет-магазинов с частыми изменениями оптимально — раз в сутки или несколько раз в день. Для каталогов с редкими изменениями достаточно еженедельной проверки.
Можно ли сверять цены без доступа к API 1С?
Да, но потребуется выгружать данные через стандартные механизмы обмена (например, через файл XML или CSV) и загружать их в промежуточную таблицу для сравнения с текущими ценами на сайте.
