Автоматизация магазина автозапчастей: как связать 1С, МойСклад и веб-каталог кросс-кодов

Рынок автозапчастей — это одна из самых информационно насыщенных и технически сложных отраслей ритейла и дистрибуции. В отличие от стандартного интернет-магазина одежды или электроники, где активный номенклатурный ряд редко превышает 10 000 SKU, автозапчасти оперируют миллионами уникальных позиций. Ситуация усложняется наличием сотен брендов-производителей (оригиналов и аналогов), постоянными заменами артикулов (кросс-кодами), зависимостью от цен и остатков десятков внешних дистрибьюторов в реальном времени, а также выраженной спецификой отдельных ниш. Например, подбор деталей для японских праворульных автомобилей (JDM) требует расшифровки по номеру кузова (Frame), а китайская спецтехника и грузовики (Shacman, FAW, Liugong, Sany) часто поставляются без стабильных каталогов от заводов, что порождает хаос в учете.

Коротко: Автоматизация магазина автозапчастей строится на связке 1С:УНФ как мастер-системы для финансов и себестоимости, МойСклад как оперативного фронт-офиса для заказов и продаж, и отдельной базы кросс-кодов на PostgreSQL для миллионов аналогов. Ключевые задачи — нормализация OEM-номеров, асинхронный опрос API дистрибьюторов с кэшированием в Redis и поддержка JDM и китайской спецтехники через специализированные каталоги.

В этом подробном руководстве мы разберем, как спроектировать и внедрить эффективную ИТ-архитектуру для бизнеса в сфере автозапчастей. Мы свяжем учетные системы семейства 1С и облачный сервис МойСклад с веб-каталогом кросс-кодов и внешними API дистрибьюторов в единую отказоустойчивую систему.

Специфика учета автозапчастей: японский правый руль и китайская спецтехника

Для построения эффективной автоматизации необходимо понимать особенности товаров, с которыми работает магазин. Попытка внедрить коробочную розничную CRM без учета специфики автобизнеса неизбежно приведет к коллапсу ИТ-системы.

1. Архитектура кросс-кодов (аналогов). Покупатели ищут запчасти по уникальному каталожному OEM-номеру, присвоенному заводом-изготовителем. Проблема в том, что оригинальная деталь часто стоит дорого. Задача системы автоматизации — в момент поискового запроса выдать не только оригинал, но и неоригинальные варианты от сторонних брендов (Brembo, TRW, CTR, Sangsin). База данных должна хранить миллионы связей между этими номерами (кроссы) и мгновенно выдавать их пользователю.
2. Специфика JDM (японский правый руль). Японские праворульные автомобили для внутреннего рынка (Toyota Mark II, Nissan Skyline, Subaru Legacy) не имеют стандартного 17-значного VIN-кода. Вместо него используется номер кузова — Frame-код (например, JZX100-0123456), состоящий из модели кузова и серийного номера. Европейские и американские каталоги, включая стандартную базу TecDoc, не умеют расшифровывать Frame-коды. Чтобы магазин мог работать с JDM-сегментом, веб-каталог должен интегрироваться со специализированными японскими EPC-системами через API (например, Laximo) для получения схемы узлов конкретного автомобиля и выгрузки оригинального OEM-артикула детали.
3. Специфика китайской спецтехники и грузовиков. Спрос на запчасти для брендов Shacman, Howo, FAW, Liugong, SDLG, Shantui и XCMG огромен, но этот рынок характеризуется полным отсутствием стандартизации. На заводе в Китае на одну и ту же модель самосвала Shacman X3000 в разные месяцы сборки могут установить совершенно разные тормозные колодки, диски сцепления или турбины. Оригинальные каталоги запчастей от заводов часто доступны только на китайском языке. Автоматический переводчик без доработки технического глоссария превращает термины в нечитаемый набор слов (например, «масляный радиатор» переводится как «коробка охлаждения масла»). Кроме того, китайские производители могут изменить артикул детали без уведомления дистрибьюторов. В базу данных приходится внедрять фотофиксацию деталей и учет физических параметров (диаметр вала, количество шлицев, число зубьев).

1С:УНФ vs МойСклад: сравнительный анализ для автобизнеса

Выбор учетной системы — фундамент проекта. В сегменте малого и среднего автобизнеса основная конкуренция разворачивается между локально-облачным решением 1С:УНФ (Управление нашей фирмой) и облачным SaaS-сервисом МойСклад. Рассмотрим их применимость для автозапчастей.

Критерий сравнения	1С:УНФ (Управление нашей фирмой)	Облачный сервис МойСклад
Тип развертывания	Локальный сервер или облако (1С:Фреш)	Полностью облачное SaaS-решение
Производительность каталога	Высокая. Легко справляется с базой от 500 000 SKU на PostgreSQL/MS SQL	Средняя. При объеме каталога свыше 100 000 SKU интерфейс и API могут замедляться
Сложные кросс-коды	Можно реализовать внутри базы через доработку конфигурации	Хранение миллионов кросс-кодов невозможно. Требуется внешняя БД
Сложные валютные закупки	Отличный учет ГТД, таможенных сборов и распределения стоимости логистики по весу	Базовый валютный учет. Расчет себестоимости импорта требует внешних вычислений
Интеграция с API дистрибьюторов	Требуется написание кастомных HTTP/SOAP клиентов на встроенном языке 1С	Простая интеграция через вебхуки и готовые коннекторы, но есть лимиты по API
Кассовая зона (РМК)	Мощное встроенное рабочее место кассира, поддержка маркировки	Очень простое, интуитивное веб- и мобильное приложение для продавцов
Стоимость владения	Выше среднего (требуются услуги 1С-программиста и администрирование серверов)	Низкая (фиксированная абонентская плата по тарифам)

• МойСклад идеально подходит для быстрого старта, небольших розничных сетей и интернет-магазинов с собственным складом до 50 000 наименований, работающих преимущественно с российскими дистрибьюторами по дропшиппингу. Он предлагает красивый интерфейс, быстро настраивается и не требует содержания штата разработчиков.
• 1С:УНФ необходима средним и крупным компаниям, которые самостоятельно импортируют запчасти из Китая, ОАЭ или Японии контейнерами. В 1С можно настроить сложную калькуляцию себестоимости (цена закупки + пошлина + доставка карго за килограмм + обрешетка), а также хранить номенклатуру объемом более 500 000 SKU без потери производительности.

Гибридная архитектура (Best Practice): Чтобы объединить преимущества обеих систем, продвинутые компании внедряют гибридный контур:

• Мастер-система (1С:УНФ): Здесь ведутся закупки, рассчитывается реальная себестоимость импорта с учетом ГТД, хранятся полные финансовые отчеты и управленческий баланс.
• Оперативный фронт (МойСклад): Синхронизируется с 1С. В МойСклад стекаются заказы с сайта, через него розничные менеджеры оформляют продажи, резервируют товары на физических складах и пробивают чеки через облачные кассы.
• Каталог и кроссы (PostgreSQL): Сверхбольшая база данных аналогов и веб-каталог хостятся на быстром VPS отдельно, не перегружая учетные системы миллионами транзитных артикулов, которых нет на складе.

Архитектура кросс-кодов и каталогов: TecDoc, OEM и локальные базы

Связующим звеном ИТ-контура магазина является база кросс-кодов. Профессиональный каталог запчастей строится по реляционному принципу. База данных TecDoc — это золотой стандарт для европейских и корейских машин. Однако официальная покупка лицензии TecDoc стоит дорого, а объем локальной базы данных в формате MS SQL или PostgreSQL составляет более 250 ГБ и содержит сотни таблиц (модели, типы двигателей, производители, артикулы деталей, критерии применимости).

Если ваш магазин специализируется на JDM или китайской технике, стандартного TecDoc будет недостаточно. Приходится проектировать собственную локальную базу данных кросс-кодов в PostgreSQL:

CREATE TABLE brands (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL UNIQUE,
    normalized_name VARCHAR(100) NOT NULL UNIQUE
);

CREATE TABLE parts (
    id SERIAL PRIMARY KEY,
    brand_id INT REFERENCES brands(id) ON DELETE RESTRICT,
    oem_original VARCHAR(100) NOT NULL,
    oem_normalized VARCHAR(100) NOT NULL,
    title_ru VARCHAR(255) NOT NULL,
    CONSTRAINT unique_brand_oem UNIQUE (brand_id, oem_normalized)
);

CREATE TABLE part_crosses (
    id SERIAL PRIMARY KEY,
    part_id_1 INT REFERENCES parts(id) ON DELETE CASCADE,
    part_id_2 INT REFERENCES parts(id) ON DELETE CASCADE,
    CONSTRAINT unique_cross_pair UNIQUE (part_id_1, part_id_2)
);

CREATE INDEX idx_parts_oem_norm ON parts(oem_normalized);
CREATE INDEX idx_crosses_p1 ON part_crosses(part_id_1);
CREATE INDEX idx_crosses_p2 ON part_crosses(part_id_2);

Когда пользователь ищет аналог на сайте, система должна найти кроссы первого уровня (прямые аналоги) и кроссы второго уровня (аналоги аналогов). Для этого в PostgreSQL применяется рекурсивный запрос (CTE):

WITH RECURSIVE crosses_search AS (
    SELECT p.id, p.brand_id, p.oem_original, p.oem_normalized, 0 AS recursion_depth
    FROM parts p
    WHERE p.oem_normalized = '9091901191'
    UNION
    SELECT p2.id, p2.brand_id, p2.oem_original, p2.oem_normalized, cs.recursion_depth + 1
    FROM crosses_search cs
    JOIN part_crosses pc ON (pc.part_id_1 = cs.id OR pc.part_id_2 = cs.id)
    JOIN parts p2 ON (p2.id = CASE WHEN pc.part_id_1 = cs.id THEN pc.part_id_2 ELSE pc.part_id_1 END)
    WHERE cs.recursion_depth < 2
)
SELECT DISTINCT id, brand_id, oem_original, oem_normalized FROM crosses_search;

Ограничение глубины рекурсии значением 2 критически важно. Если глубина поиска будет больше, система начнет связывать неподходящие запчасти через цепочки неточных замен.

Схема интеграции: объединяем 1С, МойСклад и веб-каталог

Для стабильного функционирования магазина все ИТ-компоненты должны работать асинхронно. Веб-сайт не должен зависать при сбоях в работе сервера 1С или превышении лимитов запросов в МойСклад.

Ниже представлена схема взаимодействия элементов системы:

graph TD
    User["Пользователь на сайте"] -->|1. Поиск детали| Web["Веб-сайт / Каталог"]
    Web -->|2. Поиск кросс-кодов| PG["База кроссов (PostgreSQL)"]
    Web -->|3. Проверка остатков в рознице| MS["МойСклад (API)"]
    Web -->|4. Параллельный запрос прайсов| Dist["API Дистрибьюторов (Emex, Rossko, etc.)"]
    
    MS -->|Синхронизация заказов покупателей| MS_CRM["МойСклад (CRM/WMS)"]
    MS_CRM -->|Списание остатков / Фискализация| POS["Рабочее место кассира (РМК)"]
    
    1C["1С:УНФ (ERP)"] -->|Импорт накладных / Себестоимость| MS_CRM
    1C -->|Выгрузка мастер-данных номенклатуры| PG
    
    Dist -->|Цены и сроки доставки| Web
    PG -->|Список OEM и аналогов| Web

Пошаговый сценарий обработки поискового запроса пользователя:

1. Клиент вводит на сайте артикул детали или расшифровывает свой Frame/VIN.
2. Сайт нормализует строку поиска и обращается к локальной базе кросс-кодов PostgreSQL, получая список OEM-номеров всех аналогов.
3. Веб-каталог делает быстрый запрос в МойСклад API, чтобы проверить, есть ли эти детали на собственном складе или в розничных магазинах компании.
4. Параллельно сервер сайта инициирует асинхронный опрос API дистрибьюторов (Rossko, Emex, Autopiter, Forum-Auto).
5. Полученные цены нацениваются по прогрессивной шкале маржинальности, суммируются и выводятся на экран клиента в виде единой таблицы: в топе — детали из наличия на собственном складе (доставка за 1 час), ниже — заказные позиции со сроком ожидания от 1 до 5 дней.

Алгоритмы нормализации OEM-номеров: борьба с хаосом в артикулах

Одной из главных причин, почему клиенты интернет-магазинов не находят нужные детали, а менеджеры заказывают не те запчасти, является хаос в написании артикулов. Поставщики и автопроизводители записывают один и тот же номер по-разному. Дополнительная проблема в РФ и странах СНГ — кириллические омоглифы. Менеджеры часто путают раскладку клавиатуры и пишут русскую букву «С» вместо латинской «C», «А» вместо «A», «Х» вместо «X». Для базы данных 90919-C1191 (латинская C) и 90919-С1191 (русская С) — это две разные строки.

Чтобы решить эту проблему раз и навсегда, все входящие поисковые запросы от пользователей и все импортируемые прайс-листы поставщиков должны проходить через функцию нормализации перед поиском в БД. Ниже представлен пример реализации такой функции на TypeScript:

function normalizeOem(rawOem: string): string {
  if (!rawOem) return '';
  let oem = rawOem.toUpperCase().trim();
  const homoglyphs: { [key: string]: string } = {
    'А': 'A', 'В': 'B', 'С': 'C', 'Е': 'E', 'Н': 'H',
    'К': 'K', 'М': 'M', 'О': 'O', 'Р': 'P', 'Т': 'T',
    'Х': 'X', 'У': 'Y', 'З': '3'
  };
  for (const [cyrillicChar, latinChar] of Object.entries(homoglyphs)) {
    oem = oem.replace(new RegExp(cyrillicChar, 'g'), latinChar);
  }
  oem = oem.replace(/(?<=\d)O(?=\d)/g, '0');
  oem = oem.replace(/[^A-Z0-9]/g, '');
  return oem;
}

В PostgreSQL поиск всегда ведется по полю oem_normalized, проиндексированному с помощью B-Tree индекса. При этом пользователю на экране всегда демонстрируется оригинальное начертание артикула oem_original (с дефисами и пробелами), чтобы сохранить визуальное удобство чтения номеров деталей.

Интеграция с дистрибьюторами и веб-парсинг прайсов по API

Качественный интернет-магазин запчастей предлагает товары партнеров по модели дропшиппинга. Импортировать миллионы строк прайсов от крупных дистрибьюторов в локальную базу данных 1С или МойСклад каждые несколько часов технически нецелесообразно. К моменту завершения импорта 10-20% позиций уже будут проданы у поставщика, либо их цена изменится. Единственный рабочий путь — веб-проценка в реальном времени (On-the-fly API Querying).

Решение: Асинхронные запросы с таймаутом и кэшированием в Redis

Для обхода ограничений на бэкенде сайта разворачивается сервис на Node.js, использующий библиотеку Redis для кэширования результатов поиска на короткий срок (2–4 часа). Пример реализации параллельного асинхронного опроса API с жестким лимитом по времени выполнения (Timeout):

import axios from 'axios';

interface PriceResult {
  distributor: string;
  price: number;
  deliveryDays: number;
  stock: number;
}

async function queryDistributorApi(url: string, oem: string, timeoutMs: number): Promise<PriceResult[]> {
  const controller = new AbortController();
  const id = setTimeout(() => controller.abort(), timeoutMs);
  try {
    const response = await axios.get(`${url}/search?oem=${oem}`, { signal: controller.signal });
    clearTimeout(id);
    return response.data;
  } catch {
    clearTimeout(id);
    return [];
  }
}

export async function getLivePrices(oem: string): Promise<PriceResult[]> {
  const TIMEOUT_MS = 1500;
  const apiEndpoints = [
    { name: 'Rossko', url: 'https://api.rossko.ru/v2' },
    { name: 'Emex', url: 'https://api.emex.ru/v1' },
    { name: 'ForumAuto', url: 'https://api.forum-auto.ru/v1' }
  ];
  const promises = apiEndpoints.map(api => 
    queryDistributorApi(api.url, oem, TIMEOUT_MS)
      .then(results => results.map(r => ({ ...r, distributor: api.name })))
  );
  const allResults = await Promise.allSettled(promises);
  const flatPrices: PriceResult[] = [];
  for (const result of allResults) {
    if (result.status === 'fulfilled') {
      flatPrices.push(...result.value);
    }
  }
  return flatPrices;
}

Этот подход гарантирует, что если у дистрибьютора «Emex» зависнет сервер, ваш сайт продолжит функционировать и покажет цены от других поставщиков ровно через 1.5 секунды после начала поиска.

Бизнес-кейсы: автоматизация JDM и китайской спецтехники на практике

Кейс 1: Магазин автозапчастей «JDM-DV» (Владивосток)

• Исходная ситуация: Магазин специализируется на деталях для японских праворульных автомобилей (Toyota, Nissan, Subaru). Собственный склад насчитывает 40 000 SKU. Менеджеры вручную заходили в японские оригинальные программы, искали схемы, выписывали OEM-номера деталей, а затем проверяли их наличие в 1С:УНФ. На обработку одной заявки уходило до 15-20 минут.
• Решение: На сайт магазина был интегрирован модуль расшифровки Frame-кодов через API Laximo. Теперь клиент вводит на сайте кузов автомобиля (например, JZX100-0123456), система мгновенно определяет машину: *Toyota Mark II, 1999 год, двигатель 1JZ-GTE*. Клиенту выводится интерактивная взрыв-схема узлов. При клике на деталь сайт автоматически извлекает OEM-номер 16100-46010, прогоняет его через функцию нормализации, обращается к остаткам в МойСклад и выводит цену оригинальной помпы Aisin со своего склада, а также предлагает аналоги из прайсов местных дистрибьюторов.
• Результат: Время оформления заказа сократилось до 1 минуты. Менеджеры больше не подбирают запчасти вручную по телефону — 85% заказов оформляются клиентами самостоятельно через сайт. Уровень возвратов снизился с 11% до 0.8%.

Кейс 2: Дистрибьютор деталей для китайских грузовиков «SinoParts-Ural»

• Исходная ситуация: Компания поставляет запчасти для тяжелых самосвалов Shacman X3000 и погрузчиков Liugong. Складской учет велся в МойСклад. Из-за отсутствия каталогов запчастей со стороны китайских заводов и постоянных модернизаций техники на сборочных линиях возникла острая проблема пересортицы. Например, выжимной подшипник с одним каталожным номером поставлялся в трех разных модификациях с разным диаметром посадочного отверстия.
• Решение: Была внедрена связка 1С:УНФ (мастер-база) + МойСклад (складской терминал) + кастомный веб-каталог на Node.js. В 1С:УНФ карточки номенклатуры были доработаны: в них добавили обязательные поля физических характеристик (диаметр, длина, количество шлицев) и реальные фотографии деталей со склада приема в Китае.
• Контроль упаковки: На складе отгрузки МойСклад интегрировали с ТСД (терминалами сбора данных). При упаковке заказа кладовщик сканирует штрихкод детали. На экране ТСД появляется изображение детали и список критических замеров. Без подтверждения соответствия система блокирует печать транспортной накладной.
• Результат: Проблема пересортицы полностью решена. Процент ошибок при отгрузках снизился до нуля. Автоматическое обновление закупочных цен с B2B-платформы 1688.com позволило сохранять маржинальность бизнеса на уровне 28% независимо от резких колебаний курса юаня к рублю.

Что я делаю для этой сферы

• [ ] Проектирую и внедряю отказоустойчивую архитектуру ИТ-контура для автозапчастей на базе 1С:УНФ, МойСклад и PostgreSQL.
• [ ] Разрабатываю кастомные веб-каталоги запчастей с поддержкой поиска по VIN/Frame, интерактивными взрыв-схемами и личными кабинетами покупателей.
• [ ] Интегрирую сайты и учетные системы с API крупнейших дистрибьюторов автозапчастей (Autopiter, Emex, Rossko, Forum-Auto) и сервисами подбора аналогов.
• [ ] Настраиваю автоматические парсеры каталогов китайских заводов спецтехники (1688, закрытые EPC-порталы) с обходом блокировок и интеллектуальным переводом терминов.
• [ ] Разрабатываю алгоритмы динамического ценообразования с учетом веса, габаритов деталей и стоимости международной логистики.

Готовое решение по теме

Готовы обсудить вашу задачу?

Свяжитесь со мной напрямую для бесплатной технической консультации по вашему проекту:

• Telegram: @ваш_аккаунт — оперативный ответ, обсуждение архитектуры.
• VK: vk.com/ваш_профиль — группа с кейсами и отзывами.
• Каталог услуг: chimitdorzhi.tech — подробное portfolio и прайс-лист на разработку.

Часто задаваемые вопросы (FAQ)

Какая система лучше подходит в качестве основной (мастер-базы) — 1С или МойСклад?

Для полноценного развития бизнеса основной (мастер-базой) должна быть 1С:УНФ (или 1С:ERP). В ней хранится вся финансовая история, ведется расчет себестоимости сложного импорта с учетом логистики, формируется официальная отчетность и налоговый учет. МойСклад при этом выступает в роли оперативного фронт-офиса. В него выгружаются остатки из 1С, менеджеры работают в его простом интерфейсе, проводят розничные продажи, а заказы с сайта резервируют товары напрямую в МойСклад. Такая связка гарантирует высокую скорость работы менеджеров без перегрузки тяжелой базы данных 1С.

Как работает база данных кросс-кодов и где взять актуальные соответствия?

База кросс-кодов хранит связи эквивалентности между оригинальными деталями автопроизводителей и их аналогами от сторонних заводов. Получить данные о кроссах можно тремя путями:

1. Подключиться к коммерческим API (Laximo, DocZap) — это быстро, но требует абонентской платы за каждый запрос.
2. Приобрести и развернуть локальную копию базы данных TecDoc на своем сервере (PostgreSQL).
3. Постепенно формировать собственную базу кроссов, импортируя CSV-файлы соответствий, которые регулярно присылают дистрибьюторы автозапчастей вместе со своими прайс-листами.

Что делать с дублированием артикулов у разных брендов?

Это распространенная техническая проблема. Например, артикул W712 используется масляным фильтром бренда Mann-Filter, но точно такой же артикул может быть у свечи зажигания или тормозных колодок другого бренда. Если искать в базе данных только по строке W712, пользователь получит кашу из несовместимых товаров. Решение: Поиск в базе данных и запросы к API дистрибьюторов всегда должны выполняться по связке «Бренд + Нормализованный Артикул» (например, MANN-FILTER + W712), а не по одиночному номеру детали.

Как избежать зависания сайта при опросе внешних API дистрибьюторов?

Если опрашивать 10 дистрибьюторов по очереди, страница подбора на сайте будет грузиться слишком долго. Решение:

1. Опрашивать API строго параллельно (асинхронно) с помощью Node.js Promise.allSettled.
2. Устанавливать жесткий таймаут выполнения запроса (например, 1500 мс). Если API какого-то поставщика не ответило за это время, сайт игнорирует его данные и отображает результаты от остальных.
3. Внедрить кэширование результатов в Redis с небольшим временем жизни (TTL) — например, 2-3 часа. Если другой клиент ищет этот же артикул в течение этого времени, данные мгновенно отдаются из кэша.

Как решить проблему с подбором запчастей для китайских грузовиков, если нет каталогов?

Поскольку оригинальных структурированных EPC-каталогов для многих китайских брендов спецтехники в свободном доступе нет, вам необходимо:

1. Настроить автоматический веб-парсинг закрытых дилерских порталов Китая и оптовой платформы 1688.com с помощью headless-браузеров (Playwright) и китайских резидентных прокси.
2. Накапливать собственную базу данных характеристик деталей (диаметры отверстий, количество шлицев, длина) и качественных фотографий.
3. Привязывать детали не к VIN-коду машины, а к моделям установленных узлов: марке двигателя (например, Weichai WP12), коробке передач (Fast Gear) или ведущим мостам (Hande).

Какая погрешность возникает при расчете цен по формуле веса и как её компенсировать?

В прайс-листах поставщиков информация о цене доставки рассчитывается по весу, но в каталоге вес детали часто отсутствует или указан неверно. Решение:

1. Настроить в системе категории весовых заглушек. Если вес детали в базе равен нулю, система автоматически берет среднее значение веса для этой группы товаров (например, для генератора — 5 кг, для фильтра — 0.3 кг).
2. Заложить в формулу розничной цены дополнительную страховую маржу (около 5–8%) на логистику.
3. Настроить складской бизнес-процесс: при фактическом поступлении детали на ваш склад кладовщик обязан взвесить её и внести точный вес в карточку товара в 1С/МойСклад.

Пошаговый план автоматизации на 30 дней

Реализация проекта автоматизации требует четкой последовательности действий. Попытка делать всё одновременно затянет внедрение на долгие месяцы.

Неделя 1: Аудит, проектирование БД и маскировка запросов

• [ ] Провести инвентаризацию остатков и составить реестр брендов автозапчастей.
• [ ] Развернуть базу данных PostgreSQL на выделенном сервере и применить SQL-схему таблиц.
• [ ] Написать и протестировать бэкенд-функцию нормализации OEM-артикулов (удаление спецсимволов, перевод homoglyphs).
• [ ] Получить доступ к рабочим API-ключам дистрибьюторов (Rossko, Emex, Autopiter).
• [ ] Настроить сервер Redis для кэширования результатов проценки.

Неделя 2: Настройка учетных систем 1С и МойСклад

• [ ] Настроить структуру складов и прав доступа в МойСклад.
• [ ] Настроить типовой модуль обмена данными между 1С:УНФ и МойСклад.
• [ ] Создать в 1С:УНФ дополнительные реквизиты номенклатуры (OEM, применимость, фото).
• [ ] Настроить импорт накладных в 1С с расчетом себестоимости.
• [ ] Протестировать синхронизацию заказов (сайт -> МойСклад -> 1С).

Неделя 3: Разработка кросс-движка и интеграция API

• [ ] Реализовать в бэкенде сайта параллельный опрос API дистрибьюторов с лимитом ожидания 1500 мс.
• [ ] Написать алгоритм рекурсивного поиска аналогов в локальной базе PostgreSQL.
• [ ] Интегрировать API расшифровки VIN/Frame для подбора оригинальных деталей.
• [ ] Разработать формулу динамического ценообразования с учетом веса деталей и наценки.
• [ ] Наполнить локальную базу кросс-кодов первыми тестовыми 100 000 связей.

Неделя 4: Разработка интерфейса, тестирование и релиз

• [ ] Разработать удобный интерфейс поиска на сайте с выводом таблицы остатков и аналогов.
• [ ] Настроить интеграцию с платежными шлюзами и сервисами фискализации.
• [ ] Провести нагрузочное тестирование системы поиска при одновременных запросах от пользователей.
• [ ] Обучить складской персонал работе с терминалами сбора данных (сканирование штрихкодов, проверка фото).
• [ ] Запустить ИТ-контур в эксплуатацию (Production) и настроить ежедневный мониторинг логов ошибок API.