Google Таблицы удобно использовать для регулярной сверки отправлений FBS, но «скопировать ответ API в лист» недостаточно. При повторном запуске появятся дубли, при ошибке посередине — неполная таблица, а сохранённый в ячейке ключ откроет доступ к кабинету другим редакторам. Ниже — контракт одной односторонней выгрузки, а не готовый скрипт для любого кабинета.
Коротко. Выберите конкретный метод списка FBS-отправлений в действующей документации Seller API и зафиксируйте версию запроса. Сначала собирайте все страницы ответа во временный набор, затем проверяйте полноту и только после этого обновляйте основной лист по постоянному ключу строки. Повтор одного и того же периода не должен увеличивать число строк.
Определите, что означает строка
Для анализа товаров полезна гранулярность «отправление × позиция заказа». В схеме нужны идентификатор отправления, идентификатор позиции, offer_id и/или SKU, количество, статус, время события в Ozon и время загрузки. Если одна позиция представлена несколькими одинаковыми строками, заранее решите, складывать количество или сохранять разные идентификаторы позиции. Один только SKU не годится как ключ: один товар может входить в несколько отправлений.
| Поле | Для чего нужно | Проверка |
|---|---|---|
| ID отправления и позиции | Повторная загрузка без дублей | Ключ не пуст и устойчив между запусками |
SKU или offer_id | Сопоставление с вашим справочником | Не подменять один идентификатор другим |
| Количество | Сверка единиц | Число, а не текст; возврат/отмена не стирают историю |
| Статус и время события | Анализ изменений | Часовой пояс записан явно |
| Время загрузки | Диагностика задержки | Не выдавать его за дату заказа |
Это проектная схема. Имена полей и наличие ID позиции нужно сверить с выбранным методом Seller API; при отсутствии отдельного ID придётся определить составной ключ и проверить его на реальных отправлениях.
Доступ и настройки
Начните с настройки доступа к Seller API. Для этой задачи нужен доступ только к чтению. Секрет не помещают в ячейки, исходный код, URL запроса или журнал ошибок. В Apps Script настройки можно хранить в Script Properties, но это не защищённый сейф от редакторов проекта: доступ к редактированию скрипта выдавайте ограниченному кругу людей. При увольнении или смене подрядчика пересмотрите права и перевыпустите ключ по внутренней процедуре.
Отдельно храните ID таблицы, выбранный период, часовой пояс, время последнего успешно завершённого запуска и версию контракта полей. Не переводите указатель периода вперёд после частичного ответа.
Загрузка без потери прежних данных
- Захватите блокировку запуска. Если предыдущий процесс ещё работает, не начинайте второй параллельный импорт.
- Запросите период с небольшим перекрытием по времени, чтобы поздно изменённое отправление не выпало между запусками. Перекрытие безопасно только при обновлении по ключу.
- Последовательно получите все страницы ответа. Признак конца страниц и лимит размера страницы берите из документации выбранного метода, а не из соседнего API.
- Запишите результат во временный набор, проверьте обязательные поля, число уникальных отправлений и суммарное количество единиц.
- Обновите основной лист по ключу. Если ответ или запись оборвались, прежний основной лист и маркер успешного периода должны сохраниться.
Для примера отправление DEMO-1 содержит SKU-A × 2 и SKU-B × 1. Первый запуск создаёт две строки и три единицы. Повтор этого же периода обновляет те же две строки — не создаёт четыре строки и шесть единиц. Если статус позиции поменялся, меняется её строка, а не добавляется копия с новым временем загрузки.
Расписание, ошибки и контроль
Плановый запуск делайте через time-driven trigger с зафиксированным часовым поясом проекта. Apps Script имеет квоты и ограничения времени выполнения, поэтому большой период разбивайте на проверяемые части, не обещая, что любой объём завершится за один запуск. Разделяйте причины отказа: 401/403 требуют проверки доступа, 429 — ожидания и ограниченных повторов, 5xx — ограниченных повторов с увеличением паузы. Не запускайте бесконечный цикл запросов и не записывайте секрет в сообщение об ошибке.
Перед регулярным расписанием испытайте пять случаев: один ручной запуск, повтор того же периода, пустой ответ, более одной страницы и ошибка на второй странице. Сравните число уникальных отправлений и сумму единиц с выгрузкой кабинета за тот же период и часовой пояс. Запишите расхождения и причины; совпадение числа строк само по себе не доказывает совпадение товаров.
Результат. Таблица воспроизводимо обновляется, повторный импорт не удваивает строки, неполный импорт не стирает прежний результат, а расхождение с кабинетом видно до использования данных в управленческом отчёте.
Что изучить дальше
- Если ещё нет доступа к API, начните с ключа и первого запроса Seller API.
- Если задача — менять остатки, а не только читать отправления, используйте отдельную схему синхронизации склада; права записи и цена ошибки здесь другие.
- Если отчёт нужен для плана закупок, сначала определите, какие статусы считать продажей, отменой и возвратом, а затем сопоставляйте выгрузку с помесячным планом по SKU. Ссылка ведёт на рабочий черновик, который пока не принят к публикации.
Источники и ограничения
Документация Ozon Seller API — обязательный источник для выбора действующего метода, прав, пагинации и полей. Схема выше не содержит готового URL метода именно потому, что эти детали должны быть подтверждены перед кодированием. Сервисы Properties, Lock и квоты Apps Script проверены по документации Google; фактический запуск на тестовом кабинете и сверка с Ozon ещё не выполнены. До этого статья остаётся noindex.