Как провести отчёт о реализации Ozon в 1С и не перепутать выручку с выплатой
Я разбираю, какие суммы из отчёта Ozon относятся к продажам, какие — к расходам и почему вознаграждение площадки нужно учитывать отдельно. Показываю порядок переноса в 1С, проверки загрузки и сверки с актом без привязки к конкретной конфигурации.
При переносе отчёта Ozon в 1С я сначала проверяю, не попала ли банковская выплата в сумму продаж. Деньги уже на счёте, поэтому очень легко принять именно их за выручку и закрыть вопрос. Но площадка могла удержать своё вознаграждение, зачесть другие услуги и учесть возвраты ещё до перечисления. Если внести только поступивший остаток, часть хозяйственных операций просто исчезнет из учёта. Внешне всё выглядит спокойно: банк сходится, задолженность не мешает, а продажи и расходы отражены неправильно.
В моих магазинах я разделяю проверку продаж, документов площадки и движения денег, даже когда они относятся к одному периоду. У этих данных разный смысл, и дата выплаты сама по себе не объясняет, когда была реализация. Поэтому вопрос «как провести отчёт о реализации Озон в 1С» для меня начинается не с выбора кнопки, а с определения содержания операции. Я не знаю вашу конфигурацию, договор и учётную политику, поэтому готовые проводки здесь скорее навредят. Ниже я покажу порядок, с которым можно подготовить данные и предметно обсудить перенос с бухгалтером.
Что отчёт о реализации подтверждает в учёте
Отчёт помогает установить, какие продажи и возвраты площадка отразила по вашему договору за указанный период. При посреднической схеме он раскрывает операции с товарами продавца, а не превращает перечисленную площадкой сумму в самостоятельную продажу. Для учёта мне нужны сведения о реализации, возвратах и расчётах, подтверждённые соответствующими документами. При этом состав полей и приложений я проверяю в конкретном комплекте, а не восстанавливаю по памяти. Название файла ещё не гарантирует, что внутри есть всё необходимое для отражения операции.
Я начинаю с организации продавца, контрагента, договора, периода и статуса документа. Когда магазинов несколько, особенно неприятно загрузить корректный отчёт в чужую организацию или отнести его к другому договору. Затем проверяю, нет ли исправленного документа и не был ли этот отчёт уже перенесён раньше. Отдельно смотрю даты операций и даты документов: они нужны для проверки периода признания по применяемым правилам учёта. Простое совпадение месяца в названии файла с открытым периодом базы для меня недостаточно.
Сам отчёт я рассматриваю вместе с документами на услуги, корректировками и сведениями о расчётах. Не пытаюсь извлечь из одной итоговой строки весь смысл взаимоотношений с площадкой. Если сначала нужно понять устройство исходного документа, в статье о том, как читать отчёт о реализации Ozon, я разбираю его проверку при закрытии месяца. Здесь моя задача уже другая: сохранить этот смысл при переносе в учётную систему. Хорошо прочитанный отчёт тоже можно неверно загрузить, если неправильно настроено соответствие полей.
Юнит-экономика по каждому товару: себестоимость, реальная выплата Ozon, комиссия, реклама и прибыль. Убыточные помечаются сразу — их не приходится высматривать в таблице.
Какие суммы становятся выручкой, а какие расходом
В основе выручки лежат продажи покупателям, а не остаток денег после удержаний площадки. Возвраты и корректировки реализации нужно учитывать в соответствии с их содержанием и периодом, не пряча их в общей сумме перечисления. При этом сумма расчётов с покупателями и бухгалтерская выручка могут различаться на предъявленный НДС, если он применим. Поэтому я отдельно проверяю, какие показатели отчёта содержат налог и как они перенесены в базу. Налоговый учёт тоже нельзя автоматически вывести из бухгалтерского результата: порядок зависит от режима и действующих правил.
Агентское или иное посредническое вознаграждение по договору относится к отдельной операции — услуге площадки продавцу. Оно не становится скидкой покупателю лишь потому, что Ozon удержал его из денег за проданный товар. Поэтому я разделяю признание продаж, отражение расхода на вознаграждение и погашение соответствующей задолженности удержанием или зачётом. Название услуги беру из договора и первичных документов, а не заменяю все удержания словом «комиссия». Представление НДС по этой услуге и возможность его вычета бухгалтер проверяет отдельно, с учётом документов и условий применения вычета.
С логистикой, хранением, рекламой и другими начислениями действует тот же принцип: сначала установить содержание, потом выбрать способ отражения. Не каждое удержание является расходом, а не каждое поступление — выручкой от продажи товара. Например, корректировку расчётов или компенсацию нельзя классифицировать только по знаку суммы в выгрузке. Себестоимость проданного товара также не заменяется расходами площадки: это отдельная часть учёта запасов и финансового результата. Если её не видно в отчёте Ozon, это не означает, что при расчёте прибыли её можно пропустить.
Как по шагам проверить расчёт перед переносом
Сначала я собираю продажи, которые должны быть признаны за проверяемый период, и определяю, что именно означает исходная сумма в отчёте. Она может уже учитывать часть корректировок, поэтому повторно вычитать их нельзя. Затем выделяю возвраты и исправления, которые по своему содержанию относятся к проверяемому расчёту, и уменьшаю продажи только на ещё не учтённые суммы. После этого отдельно обрабатываю НДС, если он применим, чтобы получить сопоставимый показатель бухгалтерской выручки. На этом этапе я не вычитаю ни вознаграждение площадки, ни банковские выплаты.
Дальше из выручки для управленческой проверки результата я вычитаю себестоимость реализованных товаров с учётом корректировок по возвратам. Следом вычитаю признанное вознаграждение площадки, а затем прочие расходы, относящиеся к выбранному периоду и расчёту. Суммы беру на единой основе по НДС: вычитаемый налог не должен незаметно стать расходом в одной строке и отсутствовать в другой. Так я получаю результат после перечисленных затрат, но не называю его чистой прибылью, если остальные расходы и налоги ещё не учтены. Этот расчёт нужен для проверки экономики, а не для воспроизведения суммы к выплате.
Расчёты с площадкой я проверяю отдельно, начиная с остатка задолженности на начало периода. К сумме, которую площадка должна продавцу, добавляю признанные обязательства по продажам, затем учитываю возвраты и корректировки с соответствующим знаком. Из полученного остатка вычитаю документально подтверждённые удержания и зачёты, а после них — фактические перечисления продавцу. Здесь нужны суммы расчётов, включая НДС там, где он входит в обязательство, а не показатели выручки без налога. Если движение идёт в обратную сторону или долг возник у продавца, я сохраняю направление операции, а не превращаю любую строку в вычитание.
Получившийся конечный остаток я сравниваю с данными сверки по тому же договору и на ту же дату. Если остаток не совпал, ищу конкретное движение: выплату, удержание, возврат, исправление или неверно перенесённый начальный долг. Не подгоняю расходы под желаемый итог, потому что это замаскирует источник расхождения. Для такой проверки удобно держать рядом исходный документ, рассчитанный показатель и сумму, отражённую в базе. Тогда видно, на каком переходе возникла ошибка: при чтении отчёта, классификации операции или переносе в 1С.
Отчёт о прибыли: продажи, вознаграждение Ozon, себестоимость, реклама и услуги площадки — с изменением к прошлому периоду. Внизу словами сказано, какая статья съела прибыль, чтобы не сводить это в уме.
Как загрузить отчёт о реализации Ozon в 1С или внести его вручную
Перед автоматической загрузкой я выясняю, какие документы создаёт обработка и какие движения они формируют. Поддержка файла ещё не означает, что загрузчик правильно понимает продажи, возвраты, вознаграждение и остальные услуги. Я проверяю соответствие организации, договора, номенклатуры, складов и налоговых реквизитов, а также правила обработки исправлений и повторной загрузки. Сначала переношу выбранный отчёт в тестовую копию базы или другим согласованным с бухгалтером безопасным способом. Затем сравниваю созданные документы с исходными суммами, а не ограничиваюсь сообщением об успешном импорте.
Если нужно внести отчёт реализации Ozon в 1С вручную, я начинаю с той же подготовленной расшифровки операций. В конфигурации, где предусмотрен учёт продаж через посредника, бухгалтер выбирает соответствующий механизм и заполняет сведения о реализации и возвратах в необходимой детализации. Вознаграждение и остальные услуги отражаются так, чтобы их содержание, задолженность и налоговые показатели оставались различимыми. Банковское поступление после этого закрывает расчёты, а не создаёт повторную продажу. Названия документов и порядок действий зависят от конфигурации, поэтому универсальный маршрут по меню я здесь не предлагаю.
Отчёты Ozon в 1С я проверяю одинаково независимо от способа переноса: загрузчик экономит ручной ввод, но не отвечает за смысл выбранных настроек. Особенно внимательно смотрю, не создаются ли услуги повторно при отдельной загрузке закрывающих документов. SellOps я сделал для аналитики своих магазинов, потому что не нашёл готового сервиса, которому доверял бы при проверке расчётов. В описании устройства сервиса можно посмотреть, как он устроен, но аналитическую проверку я не считаю заменой первичным документам и бухгалтерскому учёту. Для передачи бухгалтеру мне нужна понятная расшифровка расхождений, а не просто другой красивый итог.
Какие ошибки искать и с каким актом сверять результат
Самая неприятная ошибка — отразить выплату как выручку, а затем ещё раз признать удержанное вознаграждение расходом. Если между продажами и выплатой было только это удержание, выручка окажется занижена на сумму вознаграждения. После отдельного отражения расхода финансовый результат тоже будет ниже правильного на эту сумму: удержание уже уменьшило ошибочно выбранную базу выручки. При наличии возвратов, других услуг и переходящей задолженности искажение становится сложнее, но механизм остаётся прежним. Его денежный размер нужно считать по пропущенным и повторно отражённым операциям, а не оценивать по общему впечатлению от выплаты.
Совпадение суммы в банке с выплатой Ozon не подтверждает правильность учёта реализации. Продажи, услуги площадки и погашение задолженности должны оставаться отдельными по смыслу операциями. Если вознаграждение уже отражено при переносе отчёта, повторное признание той же услуги по акту задвоит расход. Перед проведением закрывающего документа проверьте, что именно уже создано в базе.
Когда мне предлагают сверить результат «с актом», я сначала уточняю, какой документ имеется в виду. Акт оказанных услуг или другой закрывающий документ на услуги нужен для проверки соответствующих расходов, их состава и налоговых реквизитов. Я сопоставляю его с отражёнными услугами по организации, договору, периоду, содержанию и суммам, отдельно проверяя НДС, где он применим. Общая сумма продаж не обязана совпадать с итогом такого акта, потому что документы описывают разные операции. Если есть исправления, нужно учитывать их связь с исходным документом, а не складывать все найденные версии.
Акт сверки взаиморасчётов отвечает на другой вопрос: какие движения и остаток задолженности отражены у сторон. Здесь я сравниваю начальный остаток, начисления, зачёты, перечисления и конечный долг, предварительно согласовав направление знаков. Один и тот же долг у продавца и площадки может показываться с противоположных сторон расчётов, поэтому простое сравнение колонок вводит в заблуждение. Выплата также может закрывать задолженность другого периода, а часть текущих продаж — оставаться неоплаченной. Подробности этого разрыва я объясняю в статье о том, почему заказы ещё не означают выплату от Ozon.
Среди ошибок переноса я отдельно ищу задвоенные отчёты, потерянные возвраты, неверный договор и смешение сумм с НДС и без него. Проверяю, не была ли уже учтена услуга другим документом и не попало ли исправление в базу как новая независимая операция. Если итог сходится, но внутри есть встречные ошибки, это тоже не считается успешной проверкой. Поэтому я сверяю отдельные виды операций и выборочно прослеживаю их от строки источника до отражения в учёте. Любое необъяснённое расхождение оставляю отдельным вопросом, а не закрываю случайной корректировкой.
Завтра я бы начал с одного уже перенесённого отчёта и собрал рядом документы на услуги, сведения о выплатах и данные сверки за сопоставимый период. В рабочей таблице разделил бы продажи, возвраты, вознаграждение, прочие операции и движение задолженности, сохранив ссылку на источник каждой суммы. Затем проверил бы, какие документы созданы в 1С и не отражена ли одна операция повторно разными способами. С найденными расхождениями уже можно идти к бухгалтеру: обсуждать конкретную сумму и её происхождение, а не просить «как-нибудь свести Озон». После такой проверки перенос остальных отчётов имеет смысл повторять только с исправленными настройками и понятным порядком контроля.
Как передавать коды маркировки в Ozon на FBS и что делать с УПД
Разбираю путь кода от получения товара до сборки заказа FBS, передачи сведений в Ozon и проверки возврата. Объясняю, почему УПД не заменяет код в отправлении, где искать причину ошибки и что меняется при работе по FBO.