Изменение даты снятия аб платы


#1

Всем привет.

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


#2

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

А можете рассказать поподробнее, почему эта функция для вас важна? Сейчас вроде самый честный подход — если оплата на маркетплейсе помесячная, то продавцы платят за то время, которое реально использовали.


#3

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

На данный момнет мы его интегрировали с:
Блокировка чекауте способа доставки в нерабочее время,
Информирование о том что доставка будет осуществлена в рабочие время
Для складов “ЛОГИСТИКА: ФУЛФИЛМЕНТ, КРОССДОКИНГ, СВОЙ СКЛАД, ПУНКТЫ ПВЗ” добавили настройки
Входит в экосистему пакета "Быстрый старт “Последняя миля или DBS – delivery by seller” для контроля работы с заказом продавца и примерок на складе
https://marketplace.cs-cart.com/poslednyaya-milya-ili-dbs-delivery-by-seller-dlya-cs-cart-multi-vendor.html


#4

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

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

#5

Тогда Вам нужно не статусы менять, а формировать счет из 1С и делать проверку на оплату, а далее авотматим блокировать магазин продавца


#6

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


#7

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

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


#8

Почитайте описание этого модуля


#9

Тут же совсем другое спрашивают, вы чтото глобус натягиваете.

Вопрос в абонентской плате в один день.

Пожелание правильное, с точки зрения бухгалтерии особенно.


#10

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

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


#11

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

  1. Если все привязывать к расчетному периоду (и аб плату и продажи), то бухгалтерская нагрузка умножается на 2, т.к. нужно будет закрыть и расчетный и календарный периоды
  2. аб плата остается расчетным периодам, а продажи привязываются к календарному. Это чуть усложняет расчеты опять же, а именно по закрытию оплаты аб платы, нужно высчитывать по каждому продавцу, процесс не сложный 30т.руб / 30 дней и * на отработанные дни в месяце, но все же
  3. и самый простой, это привязка и аб платы и расчета продаж к календарному месяцу

#12

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

Для тарифов такая же ерунда, которая смотрит на сумму и в случае превышении блокирует админку, а для вашего функционала необходим внешний тригер - КРОН КОМАНДА - которая запустит процесс генерации счетов и отчетов на период “День”, “Месяц”, “Квартал” в определенное время ориентируясь на дату в календаре и тут сам календарь будет говорить в какое время выполнять задачу.


#13

Вы все продаете ваш календарь))
Я чуть позже ознакомлюсь с вашим проектом.


#14

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


#15

ждем релиза )))