Одностороннє вивантаження 1С: де рветься обмін
Одностороннє вивантаження 1С — це схема, де каталог, ціни та залишки йдуть з облікової системи на сайт, а зворотного потоку немає. Воно працює рівно до того моменту, поки довідники з обох боків збігаються.
Обмін ламається зазвичай не першого дня, а через кілька місяців — коли хтось править картку вручну або в 1С з'являється нова група номенклатури.
Перше вузьке місце — розбіжність довідників. В обліковій системі номенклатура живе з ієрархією груп, властивостями та характеристиками, а на сайті ті самі позиції збираються з торговельних пропозицій.
Якщо ключ зіставлення (артикул, код, зовнішній ідентифікатор) змінюється або дублюється, обмін перестає впізнавати наявну картку та створює нову замість оновлення старої.
Звідси ростуть дублі товарів у каталозі та розсинхрон залишків. Обмін пише кількість за своїм ключем, а покупець дивиться на іншу позицію, де залишок не оновлювався тижнями.
Помилки обміну номенклатурою при цьому накопичуються мовчки: пакет дійшов, відповідь записано, а частина рядків не застосувалася — і у звіті цього ніяк не видно.
Другий клас збоїв — завислі пакети вивантаження. Дані йдуть порціями, і якщо сесія обривається на середині, частину вже записано, а частину — ні; повторний запуск або дублює позиції, або пропускає їх.
Ручні правки поверх вивантаження додають своє: наступна порція затирає опис і характеристики, і менеджер править те саме щодня.
Розбираємо, як це закривається: зіставлення за стійким ключем, журналювання кожної порції зі зрозумілим статусом, захист ручних полів від перезапису.
Що дає кероване вивантаження каталогу
Кероване вивантаження — це коли обмін перестає бути «одним великим скриптом» і стає регламентованим циклом із явним контрактом: які сутності, у якому порядку, що робити при конфлікті. Такий контракт описується до першого вивантаження, а не правиться за фактом збою. Далі ефекти вимірюються, а не декларуються.
Швидкість оновлення каталогу задається способом відбору даних. Інкрементальний обмін за часом зміни замість повного прогону знімає основне навантаження: нічне вивантаження, яке раніше розтягувалося на години й наздоганяло правки до ранку, укладається у вікно між викладками. Вікно, у якому на сайті висить застаріла ціна, скорочується до хвилин.
Частка ручних правок падає завдяки карті відповідності полів: за 1С закріплено ціни, залишки, номенклатуру, за сайтом — описи, зображення, рекламні атрибути. Перезапис чужих полів виключено, тому менеджери не відновлюють контент після кожного обміну. Контроль розбіжностей ведеться за журналом: скільки позицій оновлено, скільки пропущено і чому.
Стійкість обміну забезпечують ідемпотентність і запис порціями з фіксацією прогресу: повторний запуск після збою не створює дублів і продовжує з місця зупинки.
Зникає цілий клас відмов — «обмін упав на середині, каталог залишився в частковому стані»: незавершена порція відкочується, а сайт продовжує працювати на попередньому зрізі.
Варіанти обміну та їхні технічні обмеження
Схему обміну визначають три параметри: обсяг номенклатури, допустиме відставання залишків і готовність контуру 1С віддавати дані назовні.
Каталог можна вивантажувати повністю вночі, а залишки — порціями кожні кілька хвилин: вибір диктує не зручність, а ціна помилки в конкретній вітрині.
Схеми передавання даних
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Повне вивантаження | Каталог змінюється рідко, обсяг помірний | Кожен прогон перекладає весь масив — зростають час і навантаження, відкат лише повним повтором |
| Порційний обмін | Каталог великий, потрібні лише змінені позиції | Потребує надійної ознаки зміни та міток часу; розсинхрон відстежити складніше |
| Обмін за розкладом | Ціни та залишки достатньо оновлювати раз на 10-15 хвилин | Між запусками дані застарівають; при перекритті вікон завдання накладаються |
| Обмін за подіями | Потрібна швидка реакція — замовлення, резерви, статуси | Залежить від доступності джерела; на піку дає сплески запитів |
| Проміжна база | Прямий доступ до робочої 1С недопустимий, потрібна ізоляція контуру | З'являється окремий вузол для супроводу; затримка на один перенос більша |
На практиці схему збирають із двох-трьох режимів: каталог іде повним вивантаженням, залишки — порціями за розкладом, замовлення — за подіями.
Дивимося ваш контур, заміряємо добовий обсяг змін і фіксуємо набір режимів, який тримає затримку в потрібних межах без навантаження на робочу базу.
Порядок впровадження: від аудиту до передавання
Одностороннє вивантаження ламається не на налаштуванні обміну, а на розбіжності довідників і на повторних запусках, які плодять дублі.
Тому роботу ведемо послідовно: спочатку фіксуємо, що саме і з якою періодичністю йде з облікової системи до каталогу, і лише потім вмикаємо обмін.
- Аудит довідників і джерел. Дивимося номенклатуру, склади, ціни, залишки, одиниці виміру: де дубльовані коди, порожні ключі, позиції без руху, групи з ручним сортуванням. Визначаємо перелік об'єктів, що вивантажуються, і допустиму розбіжність між базами.
- Схема відповідності полів. Збираємо карту «поле джерела → поле приймача» з типами, розрядністю та правилами нормалізації: що робити з порожнім значенням, як приводити одиниці, як зберігати зовнішній ключ, щоб повторний запис оновлював позицію, а не створював другу.
- Налаштування одностороннього каналу. Обмін будуємо лише на читання з облікової системи — облік залишається єдиним джерелом правди, каталог не може записати туди дані. Налаштовуємо розклад, пакетне вивантаження та журналювання кожного сеансу.
- Тестовий контур. Розгортаємо копію каталогу, проганяємо повний обсяг, потім серію коротких вивантажень. Заміряємо час проходу, дивимося поведінку при обриві зв'язку, повторному запуску та зміні ціни в середині сеансу.
- Перевірка вивантаження. Звіряємо кількість позицій, ключові атрибути та ціни за контрольною вибіркою; окремо перевіряємо сценарії відкату — обмін має коректно доводити перерваний сеанс без втрати й без задвоєння записів.
- Запуск і передача документації. Виводимо обмін у робочий режим із моніторингом і оповіщенням про збої, віддаємо карту полів, опис регламенту, порядок перезапуску та правила внесення змін до довідників.
Кожен крок закінчується узгодженим результатом, тому перенесення в робочий контур іде без сюрпризів. Опишіть вашу задачу — повернемося з оцінкою та планом за етапами.
Комплект налаштувань і документів на виході
Після запуску одностороннього вивантаження у замовника залишається не «налаштований обмін», а комплект артефактів, за якими інтеграцію можна експлуатувати, перевіряти та передавати іншому інженеру.
Не зафіксоване письмово за пів року перетворюється на усне знання й іде разом з автором налаштування.
- Правила зіставлення — за якою ознакою пов'язуються товари, контрагенти, склади та ціни: де ключем слугує код з 1С, де артикул, і як вирішується дубль.
- Налаштування обміну — склад об'єктів, що вивантажуються, розмір порції, розклад, поведінка при розриві з'єднання, глибина журналу та рівень логування.
- Схема потоків даних — що і в який бік рухається, які поля на сайті закриті від запису, щоб 1С залишалася джерелом істини.
- Інструкції для співробітників — що робить менеджер при розбіжності ціни чи наявності, як завести новий товар, до кого ескалювати.
- Регламент запуску обміну — порядок першого повного вивантаження, ручний прогон після збою, вікна, коли обмін допустимо зупиняти.
- Опис захисту даних — задіяні облікові записи, обмеження доступу до вузла обміну, зберігання та зміна ключів.
- Лист приймання — контрольні операції, за якими робота приймається: звірка позицій, цін, залишків і журналу обміну.
Документи пишуться під ваш контур: імена об'єктів, складів і правил — ваші, а не абстрактні. Новий інженер розгортає та перевіряє обмін за цими матеріалами, не відновлюючи логіку за логами.
Кейс: як прибрали розсинхрон залишків і цін
Дистриб'ютор із каталогом на кілька тисяч товарних позицій вів облік у 1С, а вітрину — на сайті. Обмін між системами існував роками, але збирався з частин: окремі вивантаження для цін, залишків і характеристик, запуск за розкладом, без контролю повноти прогону.
Що було
Залишки та ціни розходилися з обліком у 12–15% позицій: менеджери продавали товар, якого вже не було, і вручну правили до третини карток. Підтримка отримувала десятки звернень на місяць саме через невірні ціни.
Гірше інше: обмін падав на середині пакета та залишав каталог частково оновленим. Повний прогон займав близько сорока хвилин, і все це вікно вітрина показувала застарілі залишки.
Що змінили і що стало
Перебудували одностороннє вивантаження: одна черга, фіксований порядок пакетів, перевірка повноти та повторний прогон лише невдалих. Дані пишуться в буферну таблицю та перемикаються після завершення пакета — каталог не залишається в проміжному стані.
Частка позицій із розбіжністю пішла в частки відсотка, оновлення залишків скоротилося до кількох хвилин, ручні правки стали поодинокими. Звернення до підтримки щодо каталогу рахуються одиницями на місяць, а відмови обміну більше не залишають вітрину напіоновленою.
Що робити, якщо обмін уже налаштований і дає збої
Плаваючі збої обміну майже ніколи не означають, що інтеграція зламалася — вона деградує: частина об'єктів проходить, частина осідає в черзі. Перший крок — відокремити джерело від транспорту. Якщо дані не змінювалися, а помилка повторюється, річ у правилах зіставлення, а не в каналі.
Діагностика розбіжностей іде за ключами, а не за кількістю рядків. Звіряємо контрольні суми за групами номенклатури, залишками складів і сумами документів за один і той самий період — так видно, де розходяться не дані, а зіставлення довідників.
Журнал обміну в 1С і протокол реєстрації змін показують, які об'єкти потрапили до пакета, а які відсіклися на фільтрі.
Частковий обмін небезпечніший за повну відмову: при скиданні стану замовлення та оплати задвоюються. Тому перезапуск вивантаження робимо ідемпотентним — кожному запису присвоюємо зовнішній ключ, повторне надсилання оновлює об'єкт, а не створює новий.
Порядок відновлення один: довідники, потім документи та рухи, в кінці — залишки та ціни. Порції обмежуємо за часом і обсягом, щоб вивантаження йшло у фоні та не блокувало менеджерів у години пік. Після проходження черги звіряємо контрольні суми повторно — це і є критерій, що обмін закрито.
Щоб збій не повторився, ставимо контроль розбіжностей за розкладом і оповіщення при відхиленні. Тоді застаріла ціна чи залишок не доходять до покупця.
Технічні питання, які ставлять до старту
До старту робіт виринають ті самі сумніви: чи не постраждає каталог, чи стане сайт, хто відповідає за дані після запуску. Розбираємо їх коротко і по суті.
Чи потрібен двосторонній обмін?
Одностороннє вивантаження з облікової системи на сайт закриває більшість задач. Зворотний потік — замовлення, статуси, резерви — проєктується окремим контуром: сайт не отримує права писати до облікової системи напряму, лише передає документи.
Що буде з ручними правками каталогу?
Джерело істини одне. Поля, якими керує облікова система, перезаписуються при кожному вивантаженні; описи, метатеги та медіа позначаються як ручні й не затираються. На старті робимо інвентаризацію правок — інакше перше ж повне вивантаження зітре накопичене.
Сайт доведеться зупиняти?
Ні. Запис іде порціями, збій лікується повтором з останньої успішної позиції, важкі повні вивантаження ставимо в години низької активності — каталог залишається доступним покупцям.
Як зіставляються довідники?
За зовнішнім ключем — ідентифікатором з облікової системи, а не за назвою: збіг за іменем ламається на перейменуваннях і дублях. Якщо бази вже роз'їхалися, готуємо звіт за неоднозначними позиціями та розбираємо їх до ввімкнення обміну.
Хто відповідає після запуску?
За коректність даних — джерело, за приймання, перетворення та відображення — інтеграційний контур. Моніторинг обміну з оповіщеннями залишається на підтримці; при змінах в обліковій системі оновлюємо правила зіставлення.
Обговорімо схему обміну під вашу задачу
Оцінка обміну виходить достовірною, коли видно вихідну картину: які дані йдуть з 1С, як часто змінюються і що вже налаштовано на боці сайту.
Якщо обмін уже працює, надішліть те, що є, — описувати конфігурацію з нуля не доведеться, а обговорення задачі почнеться з конкретики, а не з уточнювальних кіл.
Що корисно надіслати і що ми уточнимо при розборі:
- Перелік об'єктів одностороннього вивантаження: номенклатура, ціни, залишки, контрагенти, статуси замовлень. За кожним зазначаєте, що критично для сайту, а що передавати не потрібно.
- Поточний регламент обміну: за розкладом чи за подією, раз на годину чи при зміні запису, де стоїть черга і що відбувається при недоступності однієї зі сторін.
- Правила зіставлення та очищення даних: за яким ключем пов'язуються позиції, як обробляються дублі та застарілі картки, які вже видалені в обліковій системі.
- Доступи та контури: який сервісний користувач дозволений до вивантаження, чи є окреме середовище для тестових прогонів, хто підтверджує запуск у робочому режимі.
- Вимоги до захисту даних: які поля закриті від публікації, хто отримує доступ до персональних даних із замовлень і як це фіксується в журналах.
- Логи та спірні випадки: якщо обмін уже працював, покажіть помилки та місця, де дані переставали збігатися — за ними точніше видно обсяг доопрацювань.
На дзвінку уточнимо очікувану частоту оновлення, поведінку системи при збої та обсяг історичних даних для первинного завантаження.
У відповідь надсилаємо оцінку обміну, поетапний план робіт із порядком впровадження та регламент підтримки: що контролюємо самі, як відстежуємо розбіжності та в які строки реагуємо.
Опишіть задачу у вільній формі — повернемося з оцінкою та планом.
