Последние сообщения

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

Вы будете как агент, налог оплачивается с вашего процента. Только ПСН тут не сработает

Какие есть юридические аспекты при открытии маркетплейса в РФ? Подскажите, плз, кто знает. Я ИП, до этого успешно продавал своё ПО через вебсайт, теперь есть необходимость продавать через сайт и чужое ПО, т.е. запустить маркетплейс.

Какие есть юр моменты? ИП достаточно для этого? Нужно ли заявлять другую область деятельности? Как переводить деньги авторам продуктов? У кого был опыт — поделитесь.

Антон Силуанов

Про движение денег

Деньги кому будете выплачивать — физлица или юрлица/ИП? из каких стран?

Если речь о РФ и выплаты юрлицам — проще всего получать все деньги на ип и потом выплачивать просто на их расчетные счета.

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

Про налоги

Добавляете на сайт «агентский договор» (оферту) — и тогда в вашу «налогоблагаемую базу дохода» попадает только ваша комиссия. Не путайте это с усн 15% доходы минус расходы — это другое! Гуглите про «Агентский договор» — он дает выгодное налогоблажение.

ИП на усн 6% продал товар за 1000 руб, ваша комиссия 20%

ваш налогооблагаемый доход 20% от 1000 руб = 200 руб

6% усн налога от 200 руб. будет = 12 руб.

также не забывайте уменьшать усн налог на сумму уплаченных взносов ПФР/ОМС 

Какие есть юридические аспекты при открытии маркетплейса в РФ? Подскажите, плз, кто знает. Я ИП, до этого успешно продавал своё ПО через вебсайт, теперь есть необходимость продавать через сайт и чужое ПО, т.е. запустить маркетплейс.

Какие есть юр моменты? ИП достаточно для этого? Нужно ли заявлять другую область деятельности? Как переводить деньги авторам продуктов? У кого был опыт — поделитесь.

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

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

Дальше перекладывайте на продавцов уплату налогов, вы выступаете в качестве комиссионера (адвоката или импресарио, это в законе есть)
И все равно стоит это обсудить с юристом и бухгалтером

Спасибо за ответ, а можно ли будет использовать парсер от Python на PHP сайте?

Валерий Людимов

Да, можно просто написать API на Python и поднять сервис на отдельном поддомене или порту, а далее в JSON-формате возвращать данные на сайт и делать с ними дальнейшие операции.

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

1. Каждый запрос рандомизируем заголовки (request headers) и User-Agent. Обязательно. Тут без вариантов.

2. Делаем запросы исключительно через proxy + каждый запрос рандомизируем их. В идеале иметь пулл из ~20 проксей. Крайне желательно чтобы прокси были приватными.

3. Если уперлись в капчу, то делаем повторный запрос с другой прокси, если сайт ни в какую не хочет нас пускать к контенту, то разгадываем капчу. Либо реализуем разгадывание руками пользователя (т.к у вас интерфейс есть), либо с помощью любого сервиса разгадывания капчи, типа capmonster.cloud/ru или rucaptcha.com.

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

Спасибо за ответ, а можно ли будет использовать парсер от Python на PHP сайте?

Зависит от ваших текущих знаний. Написать парсер сайтов можно на любом языке программирования, при желание. Удобнее всего, на мой взгляд сделать это на Python с использозованием библиотеки — crummy.com/software/BeautifulSoup/bs4/doc/ либо на NodeJS.

Python / Request / BeautifulSoup4 либо NodeJS / Axios / node-html-parser. Если осмелитесь писать на PHP, что на мой взгляд крайне не удобно, то guzzle + phpQuery, как вы уже сами и написали.

Также, сейчас на многих сайтах используется технология SPA и клиентский рендеринг. Если в кратцы — то контент на сайт подгружается через API и рендерится с помощью JS. Если в тупую обратиться к такому сайту с сервера (например через curl), то с высокой долей вероятности мы получим пустую страницу.

Для таких сайтов нужно использовать эмуляторы браузеров, например seleniumhq.org или pptr.dev. Биндинги есть на Python и NodeJS, возможно и на PHP.

Тоже изучаю тему денежных потоков для маркетплейса

Схема когда все платежи принимает маркетплейс

Есть вот такие варианты в ГК РФ

— агентский договор

— договор комиссии

— договор подряда

На практике РФ видел агентский договор у некоторых маркетплейсов

Если исполнители юр лица на УСН то все просто, за исключением если у них ОСН, то тогда будут нужны счет фактуры для НДС

Сложности возникают если исполнители физ лица из РФ, у юр лица как у налогового агента может возникнуть обязанность заплатить 13% НДФЛ за физиков. Банки подняли тарифы и ужесточили контроль если со счета юр лица в банк делать перевод физ лицу.

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

Хотя с другой стороны наверняка остались еще комиссионные магазины, которые уж точно не платят НДФЛ беря товар на реализацию от физиков.

Находил юридические разъяснение по НДФЛ такую формулировку:

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

Для РФ удобное решение для физ лиц это безопасная сделка от яндекс кассы, kassa.yandex.ru/secure-deal

Она сама переведет деньги на карту исполнителя, а вам на счет придет только комиссия маркетплейса.

Комиссия кажется была около 3-4%, но еще они требуют внести залог 200 000 руб перед началом работы, на случай если будут chargeback для покрытия расходов.

Хотя потом менеджер сказал что вроде можно снизить до 50 000 руб, но нужны согласования и оценка рисков. И карты исполнителей кажется только из РФ

Cервис объявлений Юла (мейл ру) запустил услугу безопасная сделка с оплатой с картой онлайн, через дочернюю НКО деньгимейлру.

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

Партнерки делают выплаты физ лицам вебмастерам через solar-staff.com/rates

Они выступают как подрядчики, и потом используя юр лицо в другой стране выплачивают деньги вебмастерам, НДФЛ тогда обязаны платить сами физ лица. Берут немало 6-12%

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

Еще нужно не забывать если вы будете принимать платежи по картам для всех исполнителей на свое ООО у вас возникают риски chargeback и штрафы.

Например у вашего маркетплейса небольшая комиссия 10%.

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

Как этого избежать?

— внедрять Антифрод системы для платежей с карты

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

— Делать длительную задержку денег для выплат исполнителям.

Есть другая схема: заказчик платит напрямую исполнителю.

Например Etsy в странах где не работает их платежная система, покупатели платят напрямую на paypal аккаунт продавца.

Сам Etsy исполнителям ежемесячно выставляют счет за свои услуги и получает оплату позже.

Paypal тут удобен тем что:

— исполнители могут быть с разных стран ( там где официально нельзя — есть сервисы посредники paypal).

— покупатели доверяют ему

— есть встроенная система защиты покупателя и продавца

— Разные валюты поддерживает

— можно принимать платежи по картам, у кого нет paypal аккаунта

— Используя api paypal Можно автоматизировать автоматическое списание комиссии с аккаунта paypal продавца bпри каждой продаже или по другому событию получать комиссию маркетплейса на ваш аккаунт

Мне видется второй вариант с paypal гораздо удобнее на начальном этапе + он позволяет работать международно.

А потом уже можно открыть юр лицо где нибудь в европе.

— подключить серъезные международные платежи вроде adyen, braintree, stripe

— внедрить антифрод системы + KYC

— разобраться с налогами

— подключить международные выплаты для исполнителей, через swift, payoneer, paypal (в рф нет массовых платежей для бизнеса), недавно нашел сервис www.paymentrails.com/pricing

И только тогда запускать все платежи через компанию и безопасную сделку

Да и еще момент, у меня крутился сервис, годами собирающий терабайты данных на скорости 4к-10к событий в секунду (time series), хранить это в классической базе я не стал, а организовал хранилище на файлах, поверх которых в базе данных собирается агрегированная выжимка и индексы.

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

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

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

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

Отсюда архитектура — отдельно дубовые парсеры-загрузчики (их можно размещать буквально где угодно, они получают команду на загрузку и молотят, выдавая json-чики пакетами в виде результата), отдельно узлы-обработчики, которые на каждый пакет данных от загрузчиков делает нужные запросы в базу данных (или заранее кеширует в памяти, но тут нужно считать, что дешевле — апгрейдить сервер базы данных или держать на дисках кеш-дампы запросов и обновлять их параллельно БД, в этом случае кстати БД остается как конечное хранилище и аналитики). Ну и про базу данных, они на запись медленные только если там индексы распиханы по максимуму, хороший способ, если загрузка в базу редкая (например раз в сутки длится час) то можно отключить на это время индексы, провести загрузку, вернуть индексы — это кратно ускоряет процесс ЗАГРУЗКИ но не проверки целостности и поиск данных, т.е. подходит именно когда анализ проводится не в БД.

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

Это расширения-блокировщики и браузеры типа Opera где они уже нативно встроены.

Люди их ставят из-за того что вебмастерам мало встроенной аналитики DST Multivendor и они навешивают на сайт еще GA, метрику и piwik.
Бороться с этим можно только одним способом — прикрутить свою аналитику, или купить модуль DST Analitics который работает уже на стороне сервера, а все остальное выпилить.

Проблема вот какая. Есть магазин, установлена метрика, аналитика и поставил еще piwik.

У всех систем не считаются некоторые визиты. Т.е. у меня допустим по метрике 81 заказ, а в ЦМС их 115. 34 заказа не посчитались. Грешил на метрику, поставил piwik — тоже самое, и самое интересное, что ЦМС — DST Multivendor, там есть встроенная система аналитики, но она так же не видит эти визиты.

Т.е. человек реально сделал заказ, но не в аналитики DST Multivendor, не в метрике, не в piwik мы его не увидим(гугл как то криво настроен, но там тоже этих визитов нет).

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

Вот куда уходят эти визиты, почему ни одна система их не видит. Это сервер? там апач + нгинкс стоит, или что-то еще?

Андрей Живов

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

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

Проблема вот какая. Есть магазин, установлена метрика, аналитика и поставил еще piwik.

У всех систем не считаются некоторые визиты. Т.е. у меня допустим по метрике 81 заказ, а в ЦМС их 115. 34 заказа не посчитались. Грешил на метрику, поставил piwik — тоже самое, и самое интересное, что ЦМС — DST Multivendor, там есть встроенная система аналитики, но она так же не видит эти визиты.

Т.е. человек реально сделал заказ, но не в аналитики DST Multivendor, не в метрике, не в piwik мы его не увидим(гугл как то криво настроен, но там тоже этих визитов нет).

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

Вот куда уходят эти визиты, почему ни одна система их не видит. Это сервер? там апач + нгинкс стоит, или что-то еще?