Продавец не может опубликовать предложение, поскольку отсутствуют сведения о торговце: что требует DSA?
Отделите идентификацию трейдера, проверку платформы и поля страницы предложения, прежде чем считать заблокированный листинг одной общей проблемой соблюдения DSA.
Сигналы для наблюдения
- Сервис представляет собой онлайн-платформу, которая позволяет потребителям заключать дистанционные контракты с торговцами в Европейском Союзе.
- Указанный информационный элемент статьи 30 или проверка надежности блокируют доступ трейдера.
- Отдельное поле на странице предложения статьи 31 или требование идентификации продукта имеют владельца и дату выпуска.
Предложение торговой площадки, заблокированное из-за «отсутствующих данных о трейдере», не выявляет конкретный дефект соответствия. Сначала установите, что услуга и продавец подпадают под действие соответствующих положений Закона о цифровых услугах; затем отделите запись трейдера, требуемую статьей 30, проверку надежности платформы и поля интерфейса предложения, указанные в статье 31. Каждый из этих элементов может дать сбой, даже если два других заполнены.
Это различие важно руководителю аналитики соответствия маркетплейса, который просматривает разрешённые Telegram-группы по работе с продавцами, политике платформ и электронной коммерции. Ответ с опозданием на день может пропустить проверку при подключении продавца или окно выпуска обязательного поля листинга. Если отправлять каждый фрагмент на проверку личности, дефект интерфейса продукта может остаться без внимания.
Рассмотрим этот иллюстративный составной фрагмент, а не сообщение продавца или вывод надзорного органа:
“Предложение ЕС по-прежнему не публикуется. Сведения о трейдере снова неполные. Документы были загружены на прошлой неделе”.
Он не идентифицирует платформу, заключают ли потребители на ней дистанционный договор, статус продавца как трейдера, недостающий элемент, проверенный документ, причину отклонения, товар, рынок или владельца срока публикации.
Первый вопрос: соответствует ли это рабочему процессу статьи 30?
Статья 30 Регламента (ЕС) 2022/2065 распространяется на поставщиков онлайн-платформ, которые позволяют потребителям заключать дистанционные контракты с трейдерами. Платформа должна получить, где это применимо, имя и контактные данные трейдера, идентификационные данные, данные платежного счета, данные торгового реестра и самосертификацию предложений в соответствии с применимым законодательством Союза.
Этот список не является общим ярлыком «знай своего клиента». Платформа также должна приложить все усилия, чтобы оценить, является ли указанная информация достоверной и полной, используя свободно доступные официальные базы данных или надежные подтверждающие документы. Трейдер несет ответственность за достоверность предоставленной информации.
Таким образом, для первой заметки нужны четыре факта: модель сервиса платформы, потребительский рынок, основание считать продавца трейдером и конкретный пункт статьи 30, который система считает отсутствующим или недостоверным. Без них это лишь проблема поддержки учётной записи, возможно связанная с DSA.
Загруженный документ, непройденная проверка и приостановка — это разные состояния.
В составном сообщении говорится, что документы загружены. Это не доказывает ни принятия, ни причины отказа. Восстановите событие учетной записи в следующем порядке:
- Запись о предоставлении: какое юридическое лицо предоставило какое поле или документ, в какой версии и на какую дату?
- Запись об оценке: какой элемент платформа сочла неполным, противоречивым или устаревшим, и какая официальная запись или подтверждающий документ были использованы?
- Запрос на исправление: какое исправление было запрошено, через какое уведомление об учетной записи и в какой срок?
- Состояние сервиса: трейдер все еще проходит регистрацию, не может опубликовать одно предложение или отстранен от участия в предложениях, подпадающих под действие правил?
Статья 30 различает эти состояния. В пункте 3 рассматриваются ситуации, когда у платформы есть достаточные основания считать информацию неточной, неполной или неактуальной; затем платформа запрашивает исправление и может приостановить соответствующую услугу, если трейдер не выполнит требование. Сообщение об ошибке интерфейса само по себе не доказывает, что эта юридическая последовательность имела место.
Статья об онлайн-предложении GPSR объясняет связанную с этим проблему раскрытия информации о безопасности продукта. Используйте иерархию официальных источников, если у скриншота потеряна связь с юридическим документом или записью платформы.
Статья 31 начинается там, где в интерфейсе листинга некуда разместить доказательства.
Статья 31 озаглавлена «Соответствие по замыслу». Она требует, чтобы подпадающие под действие правил платформы разработали онлайн-интерфейс так, чтобы торговцы могли предоставлять преддоговорную информацию, сведения о соответствии требованиям и безопасности продукции, необходимые согласно применимому законодательству Союза. В ней отдельно рассматривается контактная информация экономического оператора и требуется, чтобы интерфейс позволял четко идентифицировать товар или услугу, знак, идентифицирующий торговца, и, где применимо, сведения об этикетках и маркировке.
Это создает другой проект. Если запись торговца проверена, но в форме предложения нет поля для необходимого экономического оператора, идентификатора продукта или маркировки, повторные проверки документов, удостоверяющих личность, не исправят список. Вместо этого в пакете доказательств следует указать затронутый шаблон листинга, рынок, требуемый элемент данных, текущее поведение интерфейса, последующий дисплей и владельца продукта.
Руководство по проверке скриншотов Safety Gate полезно, когда утверждение касается предположительно незаконного или отозванного товара, а не отсутствующих регистрационных данных.
Направляйте запрос только после того, как будут видны все три записи.
Обоснованная карточка маршрутизации состоит из трёх строк:
- Идентификация трейдера: информационный элемент статьи 30, представленные доказательства, юридическое лицо и состояние текущей учетной записи.
- Оценка платформы: проверенная официальная база данных или надежный источник, обнаруженное несоответствие, запрос на исправление и ответственный рецензент.
- Дизайн предложения: статья 31 или другое применимое поле листинга, затронутый интерфейс и владелец выпуска.
TOP Prospect может объединять фрагменты из Telegram-групп, которые пользователь намеренно подключает и имеет право просматривать, сохранять их источник и время, удалять очевидные дубликаты и ранжировать случай для проверки человеком. Он не может решить, кто по закону является трейдером, проверить документы, войти в учётную запись маркетплейса, признать товар законным или связаться с автором. Страница тарифов описывает эту границу обнаружения.
Вернитесь к заблокированному предложению. Если отсутствующий объект является полем идентификации или подтверждающим его документом, направьте запрос в отдел регистрации и соблюдения требований. Если учетная запись проверена, но интерфейс не может собрать или отобразить обязательное поле предложения, направьте его в отдел разработки продукта. Если модель обслуживания или статус трейдера по-прежнему неизвестны, не называйте это событие нарушением DSA. «Сведения о трейдере неполные» — ключ к поиску; запись со сбоем определяет проект.
Часто задаваемые вопросы
Применяется ли статья 30 к каждой онлайн-службе или каждой учетной записи продавца?
Нет. Речь идет об онлайн-платформах, которые позволяют потребителям заключать дистанционные контракты с торговцами. Сначала подтвердите модель обслуживания, местоположение потребителя и статус торговца.
Достаточно ли собрать сведения о трейдере для допуска по DSA?
Нет. Платформа должна приложить все усилия, чтобы оценить, является ли указанная информация достоверной и полной, прежде чем разрешить ее использование. Ответственность за точность остается за трейдером.
Являются ли записи торговцев согласно статье 30 и поля листинга статьи 31 одним и тем же?
Нет. Статья 30 касается отслеживания и оценки торговцев; Статья 31 касается поддержки интерфейса для необходимой информации о предложениях.
Доказывает ли заблокированный листинг, что продавец нарушил DSA?
Нет. Прежде чем делать такой вывод, узнайте точную причину отказа, состояние аккаунта, объем и доказательства.
Часто задаваемые вопросы
Применяется ли статья 30 к каждой онлайн-службе или каждой учетной записи продавца?
Нет. Статья 30 касается поставщиков онлайн-платформ, которые позволяют потребителям заключать дистанционные контракты с торговцами. Прежде чем использовать контрольный список, необходимо определить модель обслуживания, местоположение потребителя и то, выступает ли продавец в роли торговца.
Достаточно ли сбора информации о трейдерах для внедрения DSA?
Нет. Статья 30 требует, чтобы платформа приложила все усилия для оценки того, является ли указанная информация достоверной и полной, прежде чем разрешить трейдеру использовать услугу для покрываемых предложений. Трейдеры несут ответственность за точность предоставляемой ими информации.
Являются ли записи торговцев согласно статье 30 и поля листинга статьи 31 одним и тем же?
Нет. Статья 30 касается информации о отслеживаемости трейдеров и оценки платформы. Статья 31 касается поддержки интерфейса для преддоговорной информации, информации о соответствии и безопасности продукции, включая четкую идентификацию продукта или услуги и определенную видимую информацию о торговце или маркировке.
Доказывает ли заблокированный листинг, что продавец нарушил DSA?
Нет. Это доказывает только то, что рабочий процесс или правило платформы заблокировали публикацию. Прежде чем сделать вывод о соответствии требованиям, команда должна восстановить точную информацию об отклонении, состоянии учетной записи, юридической сфере и недействительных доказательствах.
Источники и дополнительное чтение
Как обнаруживается Signal, заслуживающий внимания
Методика показывает, как Top Prospect находит и упорядочивает Signals, которые стоит проверить, сохраняет исходный контекст Telegram, удаляет дубли и помогает определить порядок просмотра. Решение о дальнейших действиях остаётся за вами.
