Блог компании rdv

Как повысить эффективность управления карточками товаров и грамотно работать с остатками на маркетплейсах? Этими вопросами задается каждый второй продавец, который хочет занять верхние строчки в поисковой выдаче и увеличить продажи. Разбираемся, какие особенности бывают при работе с карточками товаров, и как их решает RDV Маркет.

Кейс 1: несколько карточек соответствуют 1 товару

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

Решение:

В личном кабинете маркетплейса, возьмем для примера Ozon, продавец заводит две позиции с разными артикулами чехол прозрачный для iPhone 7 и чехол прозрачный для iPhone 8. По факту это один товар, поскольку он подходит для обоих смартфонов.

Несмотря на то, что на маркетплейсе это две разные карточки, в 1С будут учитываться остатки по одному товару. При этом будет трансляция остатков и цен сразу на обе карточки.

Для этого в разделе "RDV:Товарный каталог", в "Управлении товарным предложением" нужно создать связку номенклатур. В этом документе отображается один товар в двух строках, артикул будет совпадать, но будут отличаться идентификаторы в личном кабинете и другие параметры, потому что на маркетплейсе одному товару соответствуют две карточки.

Если у продавца осталось, например, 50 чехлов, то при получении заказов остатки корректируются и транслируются на обе карточки маркетплейса.

Кейс 2: составные товарами и промонаборы

Это актуально тем, кто продает товары, требующие сборки, и/или комплектующие. Остатки по деталям могут использоваться в сборных товарах, часть из которых еще не собрана. Тут есть своя специфика: требуется считать количество возможных составных товаров с учетом остатков по комплектующим и транслировать остатки на маркетплейс.

Решение:

Например, поставщик торгует велосипедами на маркетплейсе Wildberries. В то же время он продает для них комплектующие: рамы, колеса, рули и сидушки. Когда у продавца есть достаточное количество комплектующих, он может собрать еще один велосипед и отправить его на маркетплейс.

Как это можно отобразить в системе 1С? В личном кабинете создаются две позиции: велосипед двухколесный и колесо, по которому передаются остатки.

Данные процессы осуществляются в документе "Управление товарным предложением". В нем указаны позиции велосипеда и шины с различными идентификаторами. На каждую позицию устанавливается цена и передается вместе с остатком.

Если продавец хочет сделать сборку, то в RDV Маркет можно создать варианты комплектации в разделе - "Варианты комплектации номенклатуры". Например, "Велосипед черный сборный", который состоит из трех частей: каркаса, сидушки и двух шин. Мы создаем вариант комплекта с указанием комплектующих - именно это увидит кладовщик в момент сборки. На основании этой информации 1С высчитывает, сколько велосипедов можно собрать.

Далее в отчете "Остатки и доступность товаров для маркетплейсов" продавец может посмотреть детальнее информацию по заказу. Рассмотрим тот же пример - "Велосипед черный сборный", по которому есть остаток на складе 1 шт. При этом 1С пишет, что для заказа доступно 15 шт. Почему так происходит? Все просто - продавец может собрать велосипеды из 3х позиций (каркас, сидушка, шина). И поскольку в наличии есть еще 14 сидушек для велосипеда, то эти данные 1С учитывает и транслирует на маркетплейс цифру 15. Если будет продана отдельно составляющая, например, шина, то остаток пересчитается.

Таким образом, работник склада в АРМ кладовщика увидит, если заказ дополнительно потребует сборки. Для этого нужно перейти в задание на сборку - собрать и отгрузить товар.

Кейс 3: Упаковки и штучные товары

Актуально, когда один товар продается как поштучно, так и упаковками (например, консервы для животных). В этом случае необходимо корректно транслировать остатки в разрезе штук и упаковок на маркетплейсах, а также отображать цены, если у продавца запланированы скидки.

Решение:

Допустим, поставщик продает на Яндекс.Маркете корм для кошек Whiskas в пакетиках. У него есть артикул и цена. Кроме того, у продавца в наличии такой же товар, который поставляется упаковками, состоящими из 24 шт. У упаковки другая цена и артикул. На странице товара на маркетплейсе можно увидеть, что эти товары относятся к одной карточке. Несмотря на это, продавец может транслировать остатки и цены как за одну штуку, так и за упаковку.

Как это реализовано в RDV Маркет? В "Управлении товарным предложением" создается товарное предложение, с помощью которого настраивается обмен по ценам и остаткам. С точки зрения учета у продавца будет один товар влажный корм Whiskas. Разница заключается в том, что он представлен в упаковке по 24 шт. и по 1 шт. В документе отображается один товар в двух строках, артикул совпадает, но отличаются упаковка и идентификаторы в личном кабинете.

Стоимость упаковки в 1С вычисляется автоматически, но при необходимости цену можно изменить. Это можно сделать в разделе "Установка цен товаров": нажать на кнопку "Создать", выбрать нужный маркетплейс и установить цену за одну штуку и упаковку. После проведения документа информация сразу уйдет на маркетплейс.

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

Описанные кейсы и их решения актуальны для продавцов, работающих по модели FBS. Это связано с тем, что при торговле с собственного склада остатки меняются ежеминутно, поэтому сотрудникам необходимо постоянно обновлять сведения и следить за их актуальностью. В этом как раз помогает RDV Маркет, где учтены все особенности работы с карточками и остатками.

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

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

В типовом функционале ERP существует ряд ограничений:

• Отсутствуют инструменты по инвентаризации ТМЦ в эксплуатации, что для крупных компаний является обязательной процедурой.

В системе в принципе нет возможности сформировать документы для проведения инвентаризации ТМЦ в эксплуатации. Из-за этого бухгалтеру приходится формировать ведомости в xls, из-за чего растет вероятность ошибок, а также увеличивается время на подготовку необходимой информации.

• Нет единого отчета, который бы аккумулировал в себе все сводные данные по учету спецодежды.

Количественные и суммовые данные разбросаны по нескольким отчетам. Например, чтобы получить информацию о количестве и стоимости ТМЦ в эксплуатации, нужно сформировать ОСВ (оборотно-сальдовую ведомость) по счету и типовой отчет "ТМЦ в эксплуатации", а затем сопоставить данные отчета в единый. При больших объемах данных такой процесс, естественно, усложняет работу пользователям и влияет на рост количества ошибок.

Кроме того, в типовом отчете "ТМЦ в эксплуатации" не отражаются те ТМЦ, по которым срок службы закончился, но сам ТМЦ еще не списан, что в свою очередь влияет на полноту отражения данных по учету.

• Не отражается движение спецодежды по счетам МЦ и 10.11 в рамках одного месяца, если она была передана в эксплуатацию в этом же месяце.

В ведении учета есть своя специфика. Представим, что в апреле была передана в эксплуатацию спецодежда. Работник несколько дней ей попользовался и передал другому. Либо другая часто встречающаяся ситуация - в одежде обнаружился брак и ее нужно было списать. И все это произошло в рамках одного месяца.

Ограничение типового функционала 1С:ERP заключается в данном случае в том, что по счетам МЦ и 10.11 не будет отображаться движение спецодежды в том же месяце, в котором произошла передача и было сделано списание или перемещение. Пользователи не смогут получить полные сведения по эксплуатации одежды в апреле, в котором она и была передана, данные будут отображены только в мае. Такой формат противоречит полноте отображения данных.

• Расчет остаточной стоимости ТМЦ, стоимость которых была погашена при передаче в эксплуатацию.

Помимо недостающей информации для корректного учета многие компании сталкиваются с необходимостью определения остаточной стоимости, которая возникает при списании ТМЦ из эксплуатации при реализации или другим причинам.

Сейчас в типовой системе 1С:ERP вся спецодежда и спецоснастка (согласно ФСБУ 5), которая передается в эксплуатацию, списывается на расходы сразу, независимо от срока службы. Проблема заключается в том, что при полном списании, когда не учитывается реальный срок службы спецодежды (в учете 2021 в системе не заложены такие документы), нельзя автоматически рассчитать остаточную стоимость, которая важна для формирования возврата средств за спецодежду и финансового результата при реализации.

Может ли автоматизация процессов в 1С решить насущные проблемы учета?

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

Рассматривая данные цели в разрезе учета спецодежды в 1С:ERP, для их достижения необходима автоматизация учета ТМЦ. Для решения вопроса оперативности, полноты и достоверности данных о ТМЦ в эксплуатации был разработан отчет "ТМЦ в эксплуатации" на базе типового отчета 1С:ERP.

Данный отчет позволяет:

• увидеть суммовые и количественные показатели в одном отчете, в разрезе всей необходимой аналитики;

• работать без ограничений по отражению ТМЦ, срок службы у которых закончился. В отчете отражаются все ТМЦ, числящиеся в учете, но с помощью настроек пользователь может сам установить отбор, показывать ему такие ТМЦ или нет;

• увидеть суммовые показатели по перемещениям и списаниям ТМЦ в том периоде, в котором они отражены по документам, независимо от даты передачи их в эксплуатацию;

• работать с полной детализацией до первичного документа, что позволяет открывать документы сразу из отчёта и вносить в него при необходимости корректировки.

Важный момент: отчет подключается к 1С как внешний инструмент и не рушит текущие процессы системы, в которой работает компания.

Разбираемся с инвентаризацией

Чуть выше мы говорили о том, что 1С:ERP в принципе нет документов по инвентаризации. Но данный процесс нельзя обходить стороной. Удачной альтернативой ручному труду будет является проведение доработки самой системы 1С, учитывая нюансы самой компании, так как тут все индивидуально.

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

Документ "Инвентаризационная ведомость для ТМЦ в эксплуатации" заполняется автоматически по данным забалансового счета МЦ по сумме и количеству с учетом данных оперативного контура, что позволяет получать актуальные данные после проведения документов перемещения и списания, независимо от формирования проводок в БУ. При этом в документе есть возможность формирования печатных форм ИНВ-3 и ИНВЕ-19.

Автоматическое заполнение реквизитов в документах по учету ТМЦ в эксплуатации

В рамках разработки отчета были доработаны механизмы, позволяющие автоматизировать:

• заполнение стоимости ТМЦ при возврате из эксплуатации, если на момент возврата не вышел срок службы или в принципе есть остаточная стоимость на счете 10.11;

• заполнение реквизитов Физическое лицо получатель при перемещении.

Разумеется, можно рассматривать альтернативные решения автоматизации. Например, если компания будет формировать оборотку, а затем загружать заполненный excel-файл в свою систему. Но учитывая объемы работ, с уверенностью можно сказать, что такой способ повлияет на рост количества ошибок.

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

Если у вас появятся вопросы - оставляйте заявку, мы подробно проконсультируем по функционалу!

Есть компания N, которая занимается продажей спортивных товаров и входит в топ-10 на рыке с неплохими оборотами. Конкуренция растет, и компания понимает, что пора расширяться за счет добавления новых категорий и брендов.

Как именно? Тут как раз и приходит идея - создать собственный маркетплейс. И большинство компаний совершают одну и ту же ошибку, считая, что это будет несложно. Давайте разбираться, почему это дикое заблуждение, и что действительно нужно для запуска собственного маркетплейса.

Не используйте для разработки ERP-систему

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

И ключевая проблема, с которой сталкиваются компании, которые имеют уже устоявшийся бизнес, заключается в уверенности, что на базе их ERP-системы можно построить полноценный маркетплейс. Нет, так сделать не получится.

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

То есть, грубо говоря, система управления заказами (OMS) сама маршрутизирует потоки (подборы товаров, идентификация позиций товаров по конкретным поставщикам и т.д.). Должны быть автоматизированы все процессы системы: управление каталогом, программы лояльности, витрина и т.д.

Все это - архитектурные задачи, которые нельзя в принципе упаковать в систему дистрибьютора. Если компания решит все-таки запустить этот процесс, то может просто сломать дистрибуцию.

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

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

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

И в конечном итоге компания жалуется на результат, потому что ожидания не совпадают с реальностью. Ждали резкого взлета в продажах, а получили не более 10% от общего оборота. Все это довольно грустно. Но выход есть.

Сделайте выбор в пользу микросервисного подхода

Как раз его используют крупные торговые площадки.

Суть микросервисной архитектуры состоит в том, что каждая отдельная функция (набор функций) выделяется в самостоятельную систему. То есть OMS (управление заказами), PIM (управление товарным каталогом), система биллинга, транспортная система, личный кабинет, программа лояльности, склад и т.д. - все это отдельные системы в единой архитектуре.

Маркетплейс включает в себя также учетные системы (бухгалтерия, казначейство, бюджетирование и т.п.), объединяя их в бэк-офис, но вся операционная часть является полностью микросервисной.

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

Даже если в карточке указан один продавец, но при этом архитектурно заложено, например, 10, соревнующихся между собой за лидерство - это уже маркетплейс. Но лучшим вариантом будет, предоставлять покупателям сразу возможность выбора товара по разным параметрам: по рейтингу, цене, условиям доставки, по скидкам и т.д.

И такое ядро не закладывается в операционную систему дистрибьютора. Максимальная глубина их аналитики - фактическая номенклатура с частичными характеристиками товара. В случае же с маркетплейсом нужно углубляться ниже, до уровня конкретной поставки товара отдельного поставщика.

Если раньше по ядру мы работали только с продуктовым каталогом (например, просто брали несколько моделей apple 10 и продавали), то сейчас нужно учитывать конкретные единицы товаров apple 10 первого, второго, третьего поставщика, а также склады, номера штрих-кодов, учет по коробкам и их перемещение, то есть большое количество признаков и параметров только одного товара.

Таким образом, если компания хочет выйти на рынок с настоящим маркетплейсом, то его нужно создавать на микросервисной платформе и становиться одним из его продавцов. Это и будет правильное архитектурное решение. Нет необходимости ломать текущие системы ERP, WMS, с которыми привычно работать в своей специфике бизнеса.

И самое главное в начале пути - вовремя обойти грабли с неверными ожиданиями и адекватно подойти к процессу создания платформы.

Как начать работу с проектом по запуску маркетплейса

Стартуем с определения стратегии развития, описания процессов и построения целевой архитектуры. Это нужно, чтобы описать целевые показатели, локальных конкурентов, архитектуру систем, а также спрогнозировать стоимость по разработке ИТ-решений.

Мы понимаем, как выстраивать внутренние процессы маркетплейса и имеем хороший опыт в разработке отдельных систем с нуля. На выходе при работе с проектом закрываем следующие задачи:

• формирование ключевых систем автоматизации маркетплейса в формате To be;

• построение общей архитектуры компонентов маркетплейса с определением потока данных и нагруженности систем;

• описание ключевых требований к платформе и функционалу, который нужен для автоматизации маркетплейса;

• формирование ключевых требований к инфраструктуре.

Давайте общаться, обсуждать детали будущего проекта, ваши и наши идеи, чтобыопределиться с дальнейшими шагами, обойдя эти ненужные грабли.

Разработка и запуск нового продукта - это всегда риск. Зайдет, не зайдет. Все зависит от возможностей (люди, деньги), компетенций, опыта, да и в целом понимания, зачем все это делать. Даже самая детально проработанная стратегия может в итоге провалиться. Главное понимать, в чем реальная польза продукт, тогда и процесс разработки пойдет увереннее.

С таким подходом мы пришли в 2019 к разработке готового решения для автоматизации торговли на маркетплейсах - RDV Маркет. Сделали его на бессмертной системе 1С. Ее мы знаем от и до, и убеждены, что для запуска нового проекта с точки зрения бизнеса - это наиболее подходящий вариант. Но об этом позже. Пока расскажем, как все начиналось, и к чему в итоге привело. Погнали.

Что было в самом начале

Начали работу в 2018 году. Нас пригласили для интеграции goods с магазином М. Видео. Работу над процессом начали с построения архитектуры OMS (система управления заказами) вместе сразработчиками и аналитиками goods.

Наша команда выступала в качестве бизнес-консультантов. Мы прописывали ТЗ для проектной команды заказчика, строили алгоритм действий, что и как должно работать. На стороне M.Видео специалисты занимались подготовкой и выгрузкой товарных предложений (фидов), а сами заказы поступали через API goods.

Конечно, были баги. В процессе боевого тестирования интеграции заметили, что до маркетплейса систематически не поступает часть заказов, а до магазина не доходят конечные платежи. Чтобы разобраться в причине сбоя, вносили корректировки в OMS и дорабатывали вместе с аналитиками проекта биллинговую систему. В итоге исправили ошибки, и рабочий процесс пошел более или менее продуктивно.Но все равно большинство операций нужно было делать вручную, постоянно перепроверять каждый заказ, чтобы передавались корректные данные.

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

Почему 1С?

Итак, М. Видео продавал через goods, а мы вплотную занимались вопросом упаковки интеграции в отдельную автоматизированную систему. Долго не раздумывали, на чем будем делать - мы знали 1С, какие у нее есть возможности, поэтому решение запилили именно на ней. Плюсы у нее весьма ощутимые.

Во-первых, с типовыми конфигурациями работает большинство компаний. Таким образом, им будет проще начать работу с нашим решением, так как все будет происходить в их привычной "среде обитания". Все операции в общем окне 1С!

Во-вторых, система надежна. Ее уровня нагрузки достаточно для работы крупных компаний с количеством пользователей > 1000. В 1С можно спокойно систематизировать и масштабировать процессы под потребности компании.

Еще один важный момент помимо технической оснащенности, что 1С оперирует понятиями бизнес-объектов. Для выстраивания рабочих процессов с маркетплейсами это только в плюс.

Да, сам интерфейс привлекательным не назовешь. Не ждите от нас крутых скринов :) Тут 1С себе не изменяет. Но для нас в данном случае важнее всего все-таки возможности системы, ее адаптивность и гибкость.

Начали работу над RDV Маркет

У нас была четкая цель - получить решение, которое встраивается в 1С и автоматизирует процессы торговли на маркетплейсе. Все просто.

Что делали.

Шаг 1. Собрали обратную связь от продавцов goods, кто на какой учетной системе работает. Для этого сделали рассылку по базе и узнали, что у большинства установлены:

• 1С:ERP;

• 1С:Комплексная автоматизация;

• 1С:Управление торговлей.

Была еще 1С УНФ (управление небольшой фирмой), но так как у нее мало функций под расширенную автоматизацию складских процессов, решили пока что ее не рассматривать. Но, возможно, придумаем что-то и с этой конфигурацией.

Шаг 2. Начали прорабатывать функционал и roadmap первой версии продукта. За основу взяли спринтовый вариант управления разработкой, с которым экспериментировали на goods. И где-то в течение первого полугодия выпустили первый релиз системы.

В функционал первой версии заложили автоматическую выгрузку товарного ассортимента в каталог (YML). Так как на примере goods поняли, что при увеличении количества товаров ручная работа с выгрузкой - это неэффективно, трата времени.

В планах было запустить 2 версии продукта. Взяли идею 1С про ПРОФ И КОРП. Собственно, отличия были соответствующие - в КОРП был шире функционал.

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

Также в первой версии мы вплотную подошли к реализации функционала по автоматизации процесса комплектации заказов и учета отгрузки товаров.

Проблема задержки товаров на складе встречается довольно часто. При нарушении сроков отгрузки происходит блокировка аккаунта продавца, соответственно, тормозится процесс продаж, и компания несет убытки. Нам было важно сделать так, чтобы подобные ситуации сводились к минимуму, поэтому настроили единое место комплектации и отгрузки (APM кладовщика), тем самым сэкономили время на сбор и отправку заказов.

Над чем работали дальше, попутно закрывая баги

Несмотря на то, что первая версия на начальном этапе решала часть проблем с ручным вмешательством, ошибки и непонимание, как это сделать, а нужно ли это вообще, естественно, возникали.

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

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

Помимо этого большой пул работ был по разработке функционала обновления остатков. Мы заложили его в релиз на будущее сразу же после окончания первой интеграции с goods. Понимали, что остатки на складах будут и их необходимо реализовывать.

Вопрос по работе с остатками стоял довольно остро. Разберем на простом примере. Магазин отправил на витрину 5 позиций, которые заказали покупатели. Но в это время в оффлайн уже было продано 2 товара из отправленных. Из-за того что на витрине маркетплейса никто не обновил остатки (в системе отображались только примерные данные), с маркетплейса было продано 5 товаров, но по факту в оформление ушло 3. То есть остальные заказы пришлось отменить. А с этим частить нельзя.

Рост отмен заказов отрицательно влияют на работу магазина, т.к. может произойти блокировка аккаунта (как и при сдвигах сроком отгрузки заказов). На сегодняшний день в текущей версии RDV Маркет реализовано автоматическое обновление остатков, что позволяет снижать или минимизировать % отмен, не доводя до критического момента.

В процессе работы над проектом пришла идея о возможности загрузки инфомоделей для товарного ассортимента (характеристики). Хотели сформировать в 1С инфомодели для каждого маркетплейса по всем категориям товаров, чтобы была возможность продавцам оперативно готовить свои каталоги и передавать их с минимум ошибок (в идеале - без) в маркетплейс. Но здесь не все так просто с получением подобного контента, поэтому идея пока висит - поставили ее в план на ближайшее будущее.

Не goods единым: с кем работаем сейчас

Goods развивался, привлекая все больше продавцов. А мы двигались дальше - хотели запартнериться с другими популярными маркетплейсами. На рынке уже активно вели свою деятельность Wildberries, Ozon и Беру (сейчас это Яндекс.Маркет). Мы начали с последнего. Причем начали довольно дерзко уверенно, сразу разместив информацию об интеграции с Беру у себя на сайте. Хотя на тот момент формального партнерства еще не было. Но так как их API была в открытом доступе, то мы успели все протестировать и настроить полноценную интеграцию с маркетплейсом.

Далее нас заметил Wildberries, который пришел к нам, когда продавал только по модели FBO (продажа со склада маркетплейса). Не так давно на WB случился прорыв - он заработал по схеме FBS (продажа со склада продавца). Здесь можно посмотреть, как мы настроили работу по новой схеме в 1С.

Чуть позже к нам присоединился Ozon - маркетплейс с непростой системой резервов. Площадка работает таким образом, что товар резервируется сразу, как только покупатель оформил заказ. Допустим, клиент неверно ввел данные карты, чтобы все исправить и оплатить покупку, ему дается 30 минут.

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

Кликайте сюда, чтобы разобраться подробнее, что и как работает в RDV Маркет.

Что дальше? Идей много. Например, хотим сделать запуск решения по одному клику на кнопку, чтобы сократить количество шагов в настройках. А также смотрим в сторону реализации мобильного приложения и ребрендинга продукта.

В общем, работаем.

Готовы ответить на вопросы, подробнее рассказать про функционал - welcome в RDV Маркет!

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

Дебиторская задолженность (далее встатье ДЗ) это долги юрлиц ифизлиц предприятию. Чем быстрее можно добиться ихпогашения, тем она более ликвидна.

Обычно должны покупатели ипоставщики, реже сотрудники, которые получили деньги избюджета компании, или государственные институты (например, налоговая), которым предприятие покакой-то причине переплатило итеперь имеет право вернуть лишнее.

Контрагенты могут задолжать как деньги, так итовары или услуги. Так, если организация перевела поставщику аванс заследующую партию, вбалансе будетДЗ, пока товары непоступят инебудут приняты насклад.

ВбухучетеДЗ это актив, часть прибыли, которой можно будет распоряжаться, только когда она превратится вденьги насчету предприятия. Поэтому отликвидности икачества дебиторки зависит платежеспособность ифинансовая устойчивость фирмы. При этом чересчур высокая ликвидность может говорить отом, что, предпочитая получать оплату как можно скорее, компания упускает сегмент крупного бизнеса итеряет из-за этого вприбыли.

Размер задолженности также должен быть оптимальным. Нулевая или небольшая задолженность говорит отом, что деньги просто лежат набалансе. Большой размер долгов дебиторов при недостатке денежных средств насчетах создает трудности вфункционировании предприятия: нечем платить сотрудникам ипоставщикам.

Как образуется задолженность

Вариантов возникновения много, приводим самые распространенные.

Состороны контрагентов:

• когда компания платит аванс поставщику или подрядчику;

• когда покупатель (вего роли может выступать филиал или дочерняя организация) сначала получает товар или услугу, аплатит потом;

• когда контрагент наносит ущерб компании икомпенсирует его несразу (например, если логистическая компания повреждает товары при транспортировке).

Состороны госструктур:

• при переплате налога;

• при вычете входного НДС (приобретая товары вцелях осуществления операций, облагаемых НДС, налогоплательщик имеет право навычет (ст.171 и172НК РФ));

• при социальных выплатах, которые возмещает ФСС (например, когда сумма выплаченных сотруднику пособий превысила страховые взносы или когда покрываются расходы напредупредительные меры (до20% сумм взносов запредыдущий год можно потратить наних)).

Состороны сотрудников иучастников предприятия:

• когда материально ответственному лицу выдаются средства нарабочие нужды;

• когда работодатель выдает сотруднику заем;

• когда участник общества задерживает платеж вуставный капитал.

Как посчитать ликвидность

Ликвидность ДЗможно оценить спомощью коэффициента ееоборачиваемости или спомощью периода ееоборота.

1. Коэффициент считают как отношение выручки кдебиторке запериод времени:

Коб.дз = ДР/ ДЗср,

где:

• Коб.дз коэффициент оборачиваемости Д;

• ДР доход компании отреализации продуктов или услуг запериод времени (обычно загод, квартал или месяц);

• ДЗср средняя дебиторская задолженность заэтотже период, т.е. суммаДЗ наначало иконец периода/2.

Тоесть расчет побалансу будет выглядеть так:

Коб.дз = 2110/ (1230на начало периода 1230на конец периода) х0,5

2. Период оборота равенДЗ наконец периода, умноженной наколичество дней расчетного периода иделенной надоход:

Поб.дз = ДЗкп хП/ ДР,

где:

• ДЗкп задолженность наконец периода;

• П период, выраженный вколичестве дней;

• ДР доход компании отреализации продуктов или услуг заэтоже период.

Тоесть расчет побалансу будет выглядеть так:

Поб.дз = 1230на конец периода хП/ 2110

Если компания много продает попредоплате и/или оплате вмомент отгрузки товара, топоказатели стоит считать наоснове выручки, полученной только отпродаж сотсрочкой платежа.

Нодаже при таком уточнении оценка только наоснове бухучета может неотразить реальную ситуацию: там неотображается ниснижение платежеспособности поставщиков, ниистечение сроков давности поистребованию задолженностей. Врезультате вДЗ включаются нетолько тедолги, которые вероятно получится вернуть, ноите, которые, скорее всего, придется списать. Поэтому качество дебиторской задолженности обычно оценивают вручную, потом наоснове этой оценки отнимают изобщей суммы просроченные, сомнительные ибезнадежные долги итолько после этого считают коэффициент оборачиваемости и/или период оборота.

Оценка качества задолженности

Основные параметры, наоснове которых можно структурироватьДЗ, чтобы оценить еекачество это нормальность/просроченность, возраст, риски невозврата исрок погашения. Поэтим признакам она делится наследующие типы.

Поотношению ксроку погашения:

• Срочная или нормальная (срок погашения еще ненаступил).

• Просроченная, может также подразделяться накатегории подлительности просрочки вднях. Например: до30, от31до60, от61до90, более 90.

Более мелкое деление помогает оценить риски невозврата: чем дольше дебитор задерживает оплату, тем меньше шансов, что онпогасит долг. Срок исковой давности повзысканию просроченной задолженности ограничен, составляет три года (ст. 196ГК РФ). Отсчет начинается сдаты, когда организация узнала онеуплате (например, день, следующий заднем платежа подоговору.

Если задолженность регулируется договором, вкотором неуказан срок возврата, тосрок давности надо начинать отсчитывать через 30дней после предъявления требования вернуть долг, ипри этом оннедолжен быть больше 10лет смомента возникновения долга (п. 2ст. 200ГК РФ).

Повероятности возврата:

• Надежная: непросроченная либо подтвержденная надежным контрагентом или обеспеченная гарантией.

• Сомнительная: та, которую могут непогасить вообще или вполном размере. Обычно это просроченная инеобеспеченная залогом, поручительством или банковской гарантией (п. 1ст. 266НК РФ), нодаже если компания изкаких-либо источников узнает офинансовых трудностях контрагента, его долг тоже стоит считать сомнительным. Поистечении срока взыскания становится безнадежной.

• Безнадежная: та, которую нельзя взыскать. Может быть просроченной систекшим сроком исковой давности, или признанной таковой порешению суда (например, при банкротстве дебитора, когда оставшиеся средства достались кредиторам предыдущей очереди), или относиться корганизации, которая уже ликвидирована (п. 2ст. 266НК РФ). Исключение для третьего случая долгИП: ондаже после исключения изреестра отвечает пообязательствам своим имуществом (ст. 24ГК РФ), если суд непризнал его банкротом.

Повеличине срока погашения:

• Краткосрочная или текущая (вбалансе относится кбыстро реализуемым активам, группаА2): погашение планируется втечение года (можно также отдельно выделить долги, которые будут оплачены втечение квартала имесяца).

• Долгосрочная (вбалансе относится кмедленно реализуемым активам, группаА3): погашение ожидается более чем через 12месяцев. Когда срок возврата долгосрочного долга становится меньше, чем 1год, онпереходит вкатегорию краткосрочных.

Степень ликвидности также можно оценить нетолько поформуле, ноиспомощью ручной группировки:

• ДЗсосроком погашения до30дней высоколиквидная.

• Безнадежная неликвидная.

• Остальная среднеликвидная.

Для тех составляющих дебиторской задолженности, которые всилу специфики деятельности предприятия имеют достаточно большой размер, можно создать отдельные строки вбалансе, чтобы онпоказывал более полную картинуфинансового состояния бизнеса.Также отражение категоризации вотчетности требуется при ведении учета поМСФО.

Поумолчанию статья вбалансе единая для всейДЗ (Торговая ипрочая дебиторская задолженность), ноили враскрытии подебиторке, или враскрытии поуправлению финансовыми рисками надо разделить финансовую инефинансовую задолженность (обычно платежи поставщикам заеще неполученный товар).

Как анализировать

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

Например, сравнивать:

• размерДЗ собщим объемом текущих активов;

• темпы ростаДЗ стемпами роста дохода;

• размер исрок оборачиваемостиДЗ саналогичными параметрами кредиторской задолженности;

• фактическую оборачиваемостьДЗ сожидаемой (согласно договорам).

Так рост дебиторки должен быть связан сростом сбыта икоррелировать сростом кредиторской задолженности. Чтобы невозникало кассовых разрывов, ликвидность иобъемДЗ должны быть сопоставимы сликвидностью иобъемомКЗ, иобъем дебиторки также недолжен быть занимать слишком большую долю втекущих активах.

Также важен удельный вес долгов низкого качества всовокупном размере долгов. Считается как отношение конкретного вида задолженности, например сомнительной, ксумме всей дебиторки. Обычно следят, чтобы небыло роста сомнительной .

Финансовую эффективностьможно оценить, сопоставив прибыль, которую приносит дебиторская задолженность, ссуммой, которую организация наней теряет (из-за инфляции, безнадежных долгов, процентов покредитам, которые пришлось взять, ит.д.).

Как повысить качество иликвидность

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

Действовать можно понескольким фронтам:

• Предупреждать риски (детальная проработка договоров, условий сотрудничества).

• Контролировать взаиморасчеты, оплаты, добиваться проведения просроченных платежей.

• Анализировать результаты.

• Корректировать кредитную политику.

Как можно работать срисками

1.Прописать вдоговоре

• неустойки (штрафы, пени), возможность удержания имущества должника идругие карательные меры вслучае неуплаты;

• особые условия перехода права собственности напродукт: переход только вмомент оплаты (чтобы при банкротстве контрагента можно было вернуть неоплаченное имсвое имущество);

• правила корректировки условий сотрудничества (цен/ гарантийных сроков/ сроков отсрочки платежей ит.п.) вслучае изменения условий рынка;

• возможность расторжения договора водностороннем порядке вслучае неисполнения второй стороной условий этого договора;

2. Создать резервный фонд насумму сомнительных долгов;

• Использовать дифференцированный подход кценообразованию: сделать работу попредоплате или оплате при получении значительно более выгодной для потребителей, чем вкредит.

• Если возможно, брать сконтрагентов депозиты.

Как получать платежи всрок ивозвращать сомнительные долги

• Назначать ответственных засоблюдение контрагентами сроков оплаты.

• Создать должностные инструкции (пошаговые алгоритмы, как добиваться проведения платежей всрок, что делать, если контрагент просрочил платеж).

• Ежемесячно сверять взаиморасчеты.

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

• Регулярно требовать провести просроченные платежи.

• Запрашивать гарантийные письма отдолжников, которые говорят, что немогут оплатить сейчас, нообещают это сделать потом.

• Предоставлять скидки задосрочное погашение просроченных задолженностей, реструктурировать долги.

• Если задолженность неполучается взыскать без суда, обращаться всуд (для этого подготовить подтверждающие долг документы акт сверки, подписанный обеими сторонами, ипризнание должником задолженности вписьменной форме иисковое заявление).

1. Регулярно анализируйте иранжируйте дебиторов (можно методом ABC-анализа), работайте сдолговыми реестрами, ищите причины появления просрочек, признаки добросовестных инедобросовестных контрагентов.

2. Оперативно меняйте условия работы сконтрагентами взависимости оттого, как они соблюдаются условия оплаты: прекращайте кредитовать должников или переходить сними навексельную форму расчетов, увеличивайте размер кредита добросовестным плательщикам.

3. Корректируйте кредитную политику компании, когда это становится необходимым иобновляйте критерии оценки надежности контрагентов, атакже инструкции поработе сдебиторкой.

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