7 октября 2026 года в блоге Ozon Tech вышел разбор Ольги Сумериной о тестировании 1С. Его ключевая мысль полезна и владельцу магазина: отсутствие технической ошибки при проведении документа ещё не доказывает, что учёт изменился правильно. Для приёмки доработки нужен заранее определённый результат, который могут проверить и разработчик, и бухгалтер.

Что показал технический кейс

Автор рассматривает неверное распределение НДС, отрицательную себестоимость, повторение счетов-фактур в книге продаж, неполное сторнирование и потерю аналитики при переносе остатков. В этих примерах проблема обнаруживалась на уровне движений, настроек и истории операций, хотя отдельное действие в интерфейсе выполнялось.

Особенно показателен перенос остатков: общий итог может совпасть, а разбивка по договорам и другим аналитическим признакам — потеряться. В другом примере ошибка проявлялась после корректировки ранее проведённого документа и не воспроизводилась на чистых новых данных. Это технические примеры автора, а не сообщение о массовом сбое расчётов Ozon.

Как поставить задачу интегратору

До изменения системы опишите хозяйственный сценарий понятными словами. Например, магазин получил партию, продал часть товара и затем оформил возврат. Для каждого шага нужно определить, какой показатель изменится, в каком отчёте он виден и с каким исходным документом связан.

Не ограничивайтесь требованием «загрузить файл без ошибок». Передайте исполнителю обезличенный пример и ожидаемые итоги. Если формат выгрузки маркетплейса меняется, отдельно укажите, какие поля влияют на классификацию операций. Тогда спор после обновления можно разбирать по конкретной строке, а не по общему впечатлению от оборота.

Включите историю, а не только новый заказ

Для собственного приёмочного набора полезно выбрать несколько реальных по структуре цепочек: обычную продажу, исправление, возврат и запись на границе периода. Копия для испытаний должна быть отделена от рабочей базы, а персональные данные — ограничены необходимым минимумом. Проводить эксперименты с закрытым периодом непосредственно в рабочем учёте не следует.

Проверяйте не только денежную сумму, но и товар, договор, склад и период, если они участвуют в вашей модели. Это редакционные рекомендации по организации приёмки. Настройки счетов и налоговый результат определяет ответственная бухгалтерская команда; статья не предлагает менять их по универсальному шаблону.

Зафиксируйте, что считается готовностью

В итог проверки включите версию изменения, исходный пример, ожидаемый результат и обнаруженные расхождения. По спорным записям сохраните связь с документом источника. Такой небольшой протокол позволяет повторить проверку после следующего обновления и отделить ошибку загрузки от ошибки учётной модели.

Для магазина с автоматической финансовой загрузкой смежная задача — сверка перехода на методы начислений Ozon. А сопоставление артикула и SKU помогает не потерять товарный разрез. Кейс Ozon Tech относится к контролю программного результата и не вводит новых обязательств продавцов маркетплейса.