Коротко о главном
Если остаток Wildberries FBS после исправления снова становится неверным, восстановите последовательность изменений по одному товару и виртуальному складу. История помогает найти момент расхождения; файл загрузки и журнал интеграции помогают объяснить его причину. Исправлять нужно источник повторной записи, а новое количество определять по актуальному свободному запасу.
- Разбирайте один вариант товара и один склад: общий итог магазина скрывает последовательность изменений.
- Остаток после события нельзя складывать с остатками соседних строк или считать поступлением товара.
- Рост количества после загрузки — повод проверить исходный файл, а не доказательство приёмки.
- Закрывайте проблему после проверки следующего обычного обновления, когда старое значение не возвращается.
1. Зафиксируйте конкретное расхождение
Начните с короткой записи: какой вариант товара проверяется, на каком виртуальном складе, в какое время заметили неверное количество и с чем его сравниваете. Название товара без баркода и варианта недостаточно: похожие позиции могут иметь разные доступные остатки.
Сохраните исходные сведения до следующей корректировки. Для расследования нужны две точки: последнее объяснимое состояние и первое необъяснимое. Если известно только текущее число, не назначайте виновником последнее действие менеджера: между ним и обнаружением ошибки могли пройти другие обновления.
Ниже — предложенный порядок внутреннего разбора для российского продавца FBS. Он посвящён повторной записи количества. Инвентаризация физического склада и расследование недостачи требуют отдельных документов и проверок.
2. Скачайте историю и сохраните оригинал
В российской инструкции WB указан путь «Свой склад → Поставки и заказы → Управление остатками». Откройте меню с тремя точками напротив товара и выберите «Скачать историю изменений»: получите XLSX. Доступен период последних трёх месяцев; данных ранее 30 апреля 2026 года нет.
В истории есть время, событие, номера заказа и поставки, виртуальный склад и данные варианта товара. Количество показывает остаток после события. Среди событий описаны заказы, корректировки, загрузки и изменения через кабинет, приложение или API. Для изменений в кабинете и приложении указан пользователь.
Работайте с копией выгрузки. Отберите нужный склад и вариант, затем расположите события по времени. При сопоставлении с другими журналами сначала проверьте часовой пояс. Если несколько событий имеют одинаковое время и порядок нельзя установить, отметьте неопределённость вместо придуманной последовательности.
3. Читайте переходы между состояниями
Значения 12, 11 и 12 в соседних строках не означают движение 35 единиц. Это состояния, которые нужно сопоставить последовательно. Переход с 11 на 12 даёт изменение плюс одна единица, но сам расчёт не объясняет, почему оно произошло. Приёмку подтверждает документ склада, а не арифметика истории.
Не рассчитывайте изменение для первой доступной строки, если предыдущее состояние неизвестно. Для остальных переходов выпишите предполагаемую причину и подтверждение: конкретный заказ, содержимое отправленного файла или запись в журнале обмена. Пометка «вероятно, интеграция» остаётся гипотезой, пока не найдено соответствующее действие.
Отдельно проверяйте операции без изменения числа. Повторная отправка того же количества может показать, что работает ещё один источник обновлений. Это полезная зацепка, даже если именно эта запись не создала расхождение.
4. Учебный пример: старый файл вернул занятую единицу
Представим один вариант и один склад. В 10:00 свободны 12 единиц. До 10:08 поступают два заказа по одной единице; отмен, возвратов и пополнений нет. В промежутке менеджер загружает файл, подготовленный до первого заказа. В таблице условные описания событий, а не точные названия строк выгрузки WB.
По условиям примера свободный запас должен составлять 12 − 1 − 1 = 10 единиц. После старой загрузки отображается 11: лишняя единица возникла в переходе 10:03 → 10:05. Это вывод из заданных условий, а не универсальная формула для любого отчёта. В реальной проверке сначала подтвердите оба заказа и отсутствие других событий.
| Время и действие | После, шт. | Что проверить |
|---|---|---|
| 10:00 — исходная запись | 12 | Свободный запас |
| 10:03 — первый заказ | 11 | Заказ на 1 шт. |
| 10:05 — старый файл | 12 | Дата подготовки |
| 10:08 — второй заказ | 11 | Заказ на 1 шт. |
5. Найдите источник повторного значения
Для подозрительной загрузки сопоставьте время события с временем подготовки и отправки файла. Проверьте конкретную строку: правильны ли склад, вариант и расчёт доступного количества. Файл может быть успешно принят и при этом содержать устаревшие данные.
Если изменение пришло через API, попросите ответственного за интеграцию найти соответствующую отправку в её журнале. Нужны товар, склад, переданное количество, время и результат обработки. Само указание API не определяет конкретную программу или сотрудника; для этого необходимо сопоставление с вашими системами.
Составьте короткий список всех способов записи остатка: учётная система, сервис обмена, ручные файлы и правки менеджеров. Назначьте основной источник и порядок исключений. Не удаляйте все подключения ради диагностики: согласованная точечная проверка должна учитывать действующую обработку заказов.
6. Проверьте исправление на следующем обновлении
Сначала устраните причину: исправьте расчёт в исходной системе, исключите повторную отправку старого файла или согласуйте действия двух операторов. Затем пересчитайте доступное количество с учётом событий, произошедших во время разбора. Возвращать число из вчерашней строки только потому, что оно когда-то было верным, нельзя.
Проверьте одну проблемную позицию после согласованного обновления, затем после следующего обычного цикла обмена. Зафиксируйте ожидаемое и фактическое состояния, учтите новые реальные заказы. Для проверки не нужны искусственные покупки или произвольное завышение наличия.
Завершённый разбор содержит найденный переход, подтверждённую причину, исправленный источник и результат повторной проверки. Если причину установить не удалось, сохраните выгрузку, время, идентификаторы товара и склада, описание ожидаемого результата для обращения в поддержку. Исключите секреты интеграций и лишние персональные данные. Начните с одной позиции: доказанный механизм полезнее массового изменения остатков наугад.
Источники и методика
Источники ниже помогают проверить определения и возможности отчётов. Методика разбора и учебные расчёты подготовлены редакцией HelpStat. Доступность отчётов и условия работы проверяйте в своём кабинете. Расчётные примеры в статье — учебные, а не результаты клиентов.
