Оплаченные заказы Shopify → рабочие таблицы склада, без ручного заноса
Двусторонний пайплайн между двумя магазинами Shopify и рабочими Google-таблицами склада: заказы, треки, статусы и отмены проставляются сами каждые 30 минут — со сверкой, бэкапами и самолечением.
Каждый оплаченный заказ переносился в таблицу руками
US-бренд товаров для активного отдыха продаёт через два магазина на Shopify, товар едет из Китая. Вся логистика — отгрузки, склады, треки — жила в двух больших Google-таблицах, которые вели двое операционистов. Каждый оплаченный заказ они переносили туда вручную: номер заказа, товар, склад отгрузки, дату, трек-номер.
Это часы работы в день и постоянное отставание таблицы от реальности. Отсюда весь типовой набор: заказы терялись, отменённые продолжали числиться активными, треки не доезжали до строки. Ошибка находилась не в момент ввода, а тогда, когда по таблице уже приняли решение.
И главное — почему это не автоматизировали раньше. Таблица здесь не база данных, а живой рабочий инструмент человека: ручные правки прямо в ячейках, формулы, условное форматирование, свой сложившийся порядок строк, выпадающие списки. Любой наивный «дописать строку в конец» ломает этот порядок и обесценивает таблицу для тех, кто в ней работает.
Пайплайн из двух половин: Python тянет, Apps Script аккуратно кладёт
Половина на Python отвечает за «что записать»: забирает оплаченные заказы обоих магазинов через Shopify Admin API, нормализует данные и собирает пакет строк. Половина на Google Apps Script отвечает за «как записать так, чтобы человек не заметил вмешательства» — и именно она оказалась сложной частью.
Оплаченные заказы двух магазинов, инкрементальная выборка каждые 30 минут
Карты названий товаров, склад отгрузки, статусы отмен и частичных возвратов
Что вставить, что обновить, что пометить отменённым — решается до записи
Advanced Sheets Service: вставка в середину сетки, протяжка формул, форматирование
Операционист видит заказ на своём месте — порядок строк и ручные правки целы
Нормализация на стороне Python
Магазина два, книги две, а написание одного и того же товара везде своё — исторически сложившееся. Поэтому карты названий сделаны пер-табличными: у каждой книги свой словарь соответствий, который правится без изменения кода. Там же определяется склад отгрузки и разбираются нетривиальные статусы — частичный возврат и отмена это не одно и то же, и в таблице они выглядят по-разному.
Advanced Sheets Service вместо SpreadsheetApp
Первый приёмник был написан на привычном
SpreadsheetApp
— объектной модели Apps Script. На книгах такого размера он стабильно уходил в OOM.
Приёмник переписан на
Advanced Sheets Service:
вместо обхода ячеек — батчевые запросы к Sheets API. К моменту выхода на боевые
книги приёмник дошёл до 69-й версии — почти каждая новая версия закрывала очередное
поведение Google, о котором нет ни строчки в документации.
Вставка в середину сетки и протяжка формул
Заказ должен встать не в конец листа, а на своё место — туда, где его ждёт человек по сложившемуся порядку строк. Google протягивает формулы соседних строк только при дописывании в конец; при вставке в середину строка приезжает «голой». Приёмник протягивает формулы сам, красит отменённые заказы через условное форматирование, заранее наращивает запас строк, чтобы не упереться в конец сетки на очередном прогоне.
Схлопывание перекрывающихся правил валидации
Отдельная находка: при вставке строк правила выпадающих списков размножаются и начинают перекрываться. Накопившись, они доводят книгу до состояния, когда она просто перестаёт открываться. Приёмник схлопывает перекрывающиеся диапазоны правил в один — это не «оптимизация», а условие того, что таблица останется рабочей.
Обвязка эксплуатации: шесть таймеров
Пайплайн работает без присмотра, поэтому вокруг него собран контур эксплуатации на systemd-таймерах:
- Постинг — каждые 30 минут, новые и изменившиеся заказы
- Экспорт файла дня — каждые 20 минут, срез для работы вне таблицы
- Healthcheck — жив ли контур, доезжают ли записи
- Суточная сверка — построчное сравнение книги с Shopify
- Ночной бэкап — снимок книг до любых записей следующего дня
- Прогон тестов приёмника — на реальном окружении, а не только в CI
Сверху — уведомления операционисту в Telegram, самовосстановление потерянных записей, ретраи на флаки Apps Script и отдельный тест, который падает, если справочник бизнес-правил разошёлся с кодом. Последнее звучит мелко, но именно оно не даёт документации превратиться в художественную литературу.
Переезд на боевые книги «вторым контуром»
Писать роботом в таблицу, от которой зависит ежедневная работа двух человек, страшно — и правильно. Переезд сделан параллельным контуром: бот какое-то время писал в боевые книги одновременно с копиями-эталонами, расхождения ловились сверкой, а откат сводился к выключению одного таймера. Ни одного «большого включения» не было.
Ничего экзотического — вся сложность в поведении Google
Выгрузка оплаченных заказов обоих магазинов, HTTP-клиент на urllib без лишних зависимостей
Приёмник на Advanced Sheets Service: вставка в середину, протяжка формул, форматирование
Чтение состояния книги для сверки и экспорта, батчевые правки
Шесть таймеров, блокировка от наложения прогонов, OnFailure-алерты
Уведомления операционисту: что записано, что разошлось, что упало
Тысяча с лишним тестов, включая проверку расхождения справочника бизнес-правил с кодом
Сравнение до и после
интервал автоматического постинга, оба магазина
711 проблемных ячеек до запуска бота — и ровно 711 после
таймеров: постинг, экспорт, healthcheck, сверка, бэкап, тесты
Ручной перенос заказов в таблицы исчез как класс работы. Оплаченные заказы обоих магазинов появляются в рабочих книгах сами — вместе с треком, складом, статусом и пометкой отмены, если заказ отменили.
Метрика «ноль новых ошибок» стоит объяснения, потому что она важнее скорости. Перед запуском книга была проинвентаризована: 711 проблемных ячеек — наследие лет ручной работы. После запуска бота проверка повторилась и дала ровно те же 711. Автоматизация не добавила в живой рабочий документ ни одной новой ошибки — при том, что писала в него каждые полчаса.
Суточная сверка против Shopify ловит расхождения сама и отдаёт их списком: в одном из прогонов 28 расхождений были помечены решёнными. Это принципиально другой режим работы — человек не ищет, что разошлось, а разбирает готовый список.
«Всё через Shopify — гораздо быстрее и удобнее, стало гораздо легче».
Операционист, подключившийся к пайплайну вторым — после того, как первый отработал на боевых книгах.
Отдельно отмечу срок: около пяти недель от первого MVP до записи в боевые книги. Из них львиная доля ушла не на «выгрузить заказы из Shopify» — это делается за день, — а на то, чтобы запись в живую человеческую таблицу была безопасной.
Где ещё ложится та же методология
Этот кейс — не «интеграция с Shopify». Это типовая задача «источник истины в API → живая таблица, в которой работают люди». Она встречается в каждой второй компании, и почти везде её пытались решить дописыванием строк в конец листа — и отказались, потому что это ломает работу:
- → Маркетплейсы (Wildberries, Ozon) → таблицы закупок и поставок, которые ведут менеджеры
- → CRM / 1С → сводные книги руководителя с ручными комментариями и своими формулами
- → Логистика и трекинг — статусы перевозчиков в реестр отгрузок без ручного копирования
- → Платёжные и биллинговые системы → финансовые реестры, где сверка важнее скорости
- → Любая «таблица-легенда», которую годами вёл человек и которую нельзя просто заменить на дашборд
- Приёмник на Apps Script с вставкой в середину сетки, протяжкой формул и схлопыванием правил валидации
- Пер-табличные карты нормализации названий, которые правит сам оператор — без релиза кода
- Суточная сверка против источника истины со списком расхождений вместо «кажется, что-то не так»
- Переезд «вторым контуром»: параллельная запись в боевую и эталонную копию, откат = выключенный таймер
- Тест, который падает при расхождении справочника бизнес-правил с кодом — документация не устаревает молча
Если люди у вас переносят данные из системы в таблицу руками — это снимается
Причём без «переезда на нормальную систему»: таблица остаётся той же, порядок строк и формулы не ломаются, а данные приезжают сами. Начинается всё с разбора одной книги и одного источника — дальше добавлять дешевле.
Аудит за 5 000 ₽ — с конкретным отчётом и сметой
Расскажу что внедрить в вашем бизнесе в первую очередь, какая будет окупаемость, и нужен ли вообще AI для вашей задачи (иногда — нет).
Или просто напишите свой вопрос — отвечу в течение 2 часов