Всем привет.
Столкнулся с тем, что на платформе нет возможности изменить даты снятия аб платы с продавца или просто поставить одну дату для всех!
Чтобы не смотря на дату авторизации продавца, аб плата снималась в одну дату у всех.
Вообще странно, конечно, что для российского бизнеса не предусмотрена такая простая, но очень важная функция.
Спасибо, добавили в “список вещей, которые потенциально можно сделать”. Сразу скажу, что пока не могу обещать это в одной из ближайших версий. Будет зависеть и от количества запросов, и от многих других факторов.
А можете рассказать поподробнее, почему эта функция для вас важна? Сейчас вроде самый честный подход — если оплата на маркетплейсе помесячная, то продавцы платят за то время, которое реально использовали.
У нас готовится к релизу модуль “Календарь” который будет ядром для разных функционалов и любой разработчик спожет к нему подключаться и использовать его.
На данный момнет мы его интегрировали с:
Блокировка чекауте способа доставки в нерабочее время,
Информирование о том что доставка будет осуществлена в рабочие время
Для складов “ЛОГИСТИКА: ФУЛФИЛМЕНТ, КРОССДОКИНГ, СВОЙ СКЛАД, ПУНКТЫ ПВЗ” добавили настройки
Входит в экосистему пакета "Быстрый старт “Последняя миля или DBS – delivery by seller” для контроля работы с заказом продавца и примерок на складе
Продавцы и так будут платить за фактически отработанное время, просто при фиксированной дате снятия аб платы, оплата будет меняться в зависимости от первоначальной регистрации, т.е. аб плата будет меньше, ну а далее уже сниматься помесячно, но в одну дату у всех.
Данная функция значительно упростит работу админа и бухгалтера, т.к. будет установлена единая дата для всех поступлений по оплате аб платы, а дата будет привязана к периоду закрытия месяца.
Тогда Вам нужно не статусы менять, а формировать счет из 1С и делать проверку на оплату, а далее авотматим блокировать магазин продавца
Не совсем понял мысли…
на платформе предусмотрены тарифы, которые меняются в полуавтоматическом режиме, т.е. приходит уведомление о превышении порога предусмотренным тарифом ,далее в ручном режиме переводишь продавца на новый тариф. Блокировка магазина тут предусмотрена при неоплате об платы
Тогда смысл вообще этой функции по подсчету месячного оборота, если все делаешь через 1С?
На самом деле я вообще не вижу смысла в этих тарифах. Ну давайте смотреть правде в глаза, никто уже практически не продает товар без гарантий так как государство обязало маркетплейсов нести полную ответственность за работу своих продавцов. То есть если подали жалобу, то отвечать будет маркетплейс и всем будет пофигу, что делал это вендор. И так же будет пофигу на договор оферты, так как он противоречит с законодательству
По хорошему использовать модель когда взяли деньги с заказа, дождался закрытия сделки, подсчитал и выплатил все, и отчитался в налоговую.
Почитайте описание этого модуля
Тут же совсем другое спрашивают, вы чтото глобус натягиваете.
Вопрос в абонентской плате в один день.
Пожелание правильное, с точки зрения бухгалтерии особенно.
Все верно и я привел пример возможной реализации этого запроса через работу календаря.
А так же пример использования другой бизнес схемы в которой функционал тарифов вовсе не участвует и даже сказал бы что он мешает. Просто вводит в заблуждение при регистрации вендора и избавиться от зависимости этого функционала досточно затруднительно
На самом моделей ведения бизнеса с маркетплесом не так уж и много, и все они имеют место быть. Тут даже не смотря на законодательства и тд, суть во взаимодействии и расчетах между площадкой и вендорами, а именно бухгалтерским учетом.
Т.е. есть три сценария, везде отталкиваемся от собственной даты снятия аб платы у продавца и от того, что по бухгалтерии закрывается календарный месяц, а не расчетный:
Согласен, что есть простой для пользователя но непростой для разработчиков. Дело в том, что для какого то действия нужен тригер, к примеру вы как админ заходите на площадку и каким то чудом получаете отчет о продажах вендоров на площадке за день и о их задолженности. Так вот тригером отправки этих сведений является АДМИН в момент когда проходит регистрацию.
Для тарифов такая же ерунда, которая смотрит на сумму и в случае превышении блокирует админку, а для вашего функционала необходим внешний тригер - КРОН КОМАНДА - которая запустит процесс генерации счетов и отчетов на период “День”, “Месяц”, “Квартал” в определенное время ориентируясь на дату в календаре и тут сам календарь будет говорить в какое время выполнять задачу.
Вы все продаете ваш календарь))
Я чуть позже ознакомлюсь с вашим проектом.
Не продаю, а привожу в пример. Для наших коллег будет конечно же еще та делема учесть все за и против. Если будет запускаться функционал автоплатежа, то в любом случае запускать по крон, иначе заспамить можно платежный сервис. ТАк же если вдруг вендор не оплатил, то надо отправить уведомление десятого числа с напоминалкой о необходимости оплатить. И таких мелочей потребуется решить не мало.
ждем релиза )))
