Оплаченные заказы Shopify → рабочие таблицы склада, без ручного заноса
Двусторонний обмен между двумя магазинами Shopify и рабочими Google-таблицами склада: заказы, треки, статусы и отмены проставляются сами каждые 30 минут — со сверкой, бэкапами и самолечением.
Каждый оплаченный заказ переносился в таблицу руками
Бренд товаров для активного отдыха из США продаёт через два магазина на Shopify, товар едет из Китая. Вся логистика — отгрузки, склады, треки — жила в двух больших Google-таблицах, которые вели двое операционистов. Каждый оплаченный заказ они переносили туда вручную: номер заказа, товар, склад отгрузки, дату, трек-номер.
Это часы работы в день и постоянное отставание таблицы от реальности. Отсюда весь типовой набор: заказы терялись, отменённые продолжали числиться активными, треки не доезжали до строки. Ошибка находилась не в момент ввода, а тогда, когда по таблице уже приняли решение.
И главное — почему это не автоматизировали раньше. Таблица здесь не база данных, а живой рабочий инструмент человека: ручные правки прямо в ячейках, формулы, условное форматирование, свой сложившийся порядок строк, выпадающие списки. Любой наивный «дописать строку в конец» ломает этот порядок и обесценивает таблицу для тех, кто в ней работает.
Обмен из двух половин: Python забирает, Apps Script аккуратно кладёт
Половина на Python отвечает за «что записать»: забирает оплаченные заказы обоих магазинов через Shopify Admin API, приводит данные к единому виду и собирает пакет строк. Половина на Google Apps Script отвечает за «как записать так, чтобы человек не заметил вмешательства» — и именно она оказалась сложной частью.
Оплаченные заказы двух магазинов: каждые 30 минут забираются только новые
Справочники названий товаров, склад отгрузки, статусы отмен и частичных возвратов
Что вставить, что обновить, что пометить отменённым — решается до записи
Вставка строки в середину таблицы, протяжка формул и форматирования соседних строк
Операционист видит заказ на своём месте — порядок строк и ручные правки целы
Нормализация на стороне Python
Магазина два, книги две, а написание одного и того же товара везде своё — исторически сложившееся. Поэтому карты названий сделаны пер-табличными: у каждой книги свой словарь соответствий, который правится без изменения кода. Там же определяется склад отгрузки и разбираются нетривиальные статусы — частичный возврат и отмена это не одно и то же, и в таблице они выглядят по-разному.
Advanced Sheets Service вместо SpreadsheetApp
Первый приёмник был написан на привычном
SpreadsheetApp
— стандартной объектной модели Apps Script. На таблицах такого размера ему стабильно не хватало памяти.
Приёмник переписан на
Advanced Sheets Service:
вместо обхода ячеек — пакетные запросы к Sheets API. К моменту выхода на боевые
книги приёмник дошёл до 69-й версии — почти каждая новая версия закрывала очередное
поведение Google, о котором нет ни строчки в документации.
Вставка в середину сетки и протяжка формул
Заказ должен встать не в конец листа, а на своё место — туда, где его ждёт человек по сложившемуся порядку строк. Google протягивает формулы соседних строк только при дописывании в конец; при вставке в середину строка приезжает «голой». Приёмник протягивает формулы сам, красит отменённые заказы через условное форматирование, заранее наращивает запас строк, чтобы не упереться в конец сетки на очередном прогоне.
Схлопывание перекрывающихся правил валидации
Отдельная находка: при вставке строк правила выпадающих списков размножаются и начинают перекрываться. Накопившись, они доводят книгу до состояния, когда она просто перестаёт открываться. Приёмник схлопывает перекрывающиеся диапазоны правил в один — это не «оптимизация», а условие того, что таблица останется рабочей.
Обвязка эксплуатации: шесть таймеров
Обмен работает без присмотра, поэтому вокруг него собран контур эксплуатации на systemd-таймерах:
- Постинг — каждые 30 минут, новые и изменившиеся заказы
- Экспорт файла дня — каждые 20 минут, срез для работы вне таблицы
- Healthcheck — жив ли контур, доезжают ли записи
- Суточная сверка — построчное сравнение книги с Shopify
- Ночной бэкап — снимок книг до любых записей следующего дня
- Прогон тестов приёмника — на реальном окружении, а не только в CI
Сверху — уведомления операционисту в Telegram, самовосстановление потерянных записей, повторные попытки при сбоях Apps Script и отдельный тест, который падает, если справочник бизнес-правил разошёлся с кодом. Последнее звучит мелко, но именно оно не даёт документации превратиться в художественную литературу.
Переезд на боевые книги «вторым контуром»
Писать роботом в таблицу, от которой зависит ежедневная работа двух человек, страшно — и правильно. Переезд сделан параллельным контуром: бот какое-то время писал в боевые книги одновременно с копиями-эталонами, расхождения ловились сверкой, а откат сводился к выключению одного таймера. Ни одного «большого включения» не было.
Ничего экзотического — вся сложность в поведении Google
Выгрузка оплаченных заказов обоих магазинов, запросы через urllib без лишних зависимостей
Запись в таблицу: вставка в середину, протяжка формул и форматирования
Чтение состояния таблицы для сверки и выгрузки, пакетные правки
Шесть расписаний, защита от наложения запусков, оповещения при сбое
Уведомления операционисту: что записано, что разошлось, что упало
Тысяча с лишним тестов, включая проверку расхождения справочника бизнес-правил с кодом
Сравнение до и после
интервал автоматического постинга, оба магазина
711 проблемных ячеек до запуска бота — и ровно 711 после
таймеров: постинг, экспорт, healthcheck, сверка, бэкап, тесты
Ручной перенос заказов в таблицы исчез как класс работы. Оплаченные заказы обоих магазинов появляются в рабочих книгах сами — вместе с треком, складом, статусом и пометкой отмены, если заказ отменили.
Метрика «ноль новых ошибок» стоит объяснения, потому что она важнее скорости. Перед запуском книга была проинвентаризована: 711 проблемных ячеек — наследие лет ручной работы. После запуска бота проверка повторилась и дала ровно те же 711. Автоматизация не добавила в живой рабочий документ ни одной новой ошибки — при том, что писала в него каждые полчаса.
Суточная сверка против Shopify ловит расхождения сама и отдаёт их списком: в одном из прогонов 28 расхождений были помечены решёнными. Это принципиально другой режим работы — человек не ищет, что разошлось, а разбирает готовый список.
«Всё через Shopify — гораздо быстрее и удобнее, стало гораздо легче».
Операционист, подключившийся вторым — после того, как первый отработал на боевых книгах.
Отдельно отмечу срок: около пяти недель от первой рабочей версии до записи в боевые таблицы. Из них львиная доля ушла не на «выгрузить заказы из Shopify» — это делается за день, — а на то, чтобы запись в живую человеческую таблицу была безопасной.
Где ещё ложится та же методология
Этот кейс — не «интеграция с Shopify». Это типовая задача «источник истины в API → живая таблица, в которой работают люди». Она встречается в каждой второй компании, и почти везде её пытались решить дописыванием строк в конец листа — и отказались, потому что это ломает работу:
- → Маркетплейсы (Wildberries, Ozon) → таблицы закупок и поставок, которые ведут менеджеры
- → CRM / 1С → сводные книги руководителя с ручными комментариями и своими формулами
- → Логистика и трекинг — статусы перевозчиков в реестр отгрузок без ручного копирования
- → Платёжные и биллинговые системы → финансовые реестры, где сверка важнее скорости
- → Любая «таблица-легенда», которую годами вёл человек и которую нельзя просто заменить готовым отчётом
- Запись через Apps Script: вставка в середину таблицы, протяжка формул и объединение правил проверки данных
- Справочники названий по каждой таблице, которые правит сам оператор — без обновления кода
- Ежедневная сверка с главной системой и список расхождений вместо «кажется, что-то не так»
- Переезд в два контура: параллельная запись в боевую и эталонную копию, откат — просто выключить расписание
- Тест, который падает при расхождении справочника бизнес-правил с кодом — документация не устаревает молча
Если люди у вас переносят данные из системы в таблицу руками — это снимается
Причём без «переезда на нормальную систему»: таблица остаётся той же, порядок строк и формулы не ломаются, а данные приезжают сами. Начинается всё с разбора одной книги и одного источника — дальше добавлять дешевле.
Разбор по теме:Синхронизация остатков 1С с Wildberries и Ozon: как выбрать периодичность обмена и что ставить вокруг него
Похожие кейсы
Разбор компании по открытым источникам: что видно снаружи
Методика из 12 шагов на бесплатных источниках (WHOIS, DNS, SSL/crt.sh, URLscan, Wayback) плюс собственные…
Авто-сборка еженедельных отчётов клиентам
Сценарий в n8n на 8 клиентов: собирает цифры со всех площадок, AI-комментарий, отчёт в PDF или Notion уходит…
Лендинг на Astro с оценкой заявок: конверсия в демо 4,6%
Многошаговая форма, оценка заявки в n8n по группам A/B/C/D, данные компании из Dadata по ИНН и СПАРК. B и…
Аудит за 5 000 ₽ — с конкретным отчётом и сметой
Расскажу что внедрить в вашем бизнесе в первую очередь, какая будет окупаемость, и нужен ли вообще AI для вашей задачи (иногда — нет).
Или просто напишите свой вопрос — отвечу в течение 2 часов