Должен ли платить экосбор агент

Что это такое, чем регулируется, куда сдавать

Ну первое, нужно ли платить экосбор в 2023 году, официальная инфа – да, нужно.

За неуплату в ст. 8.41.1 КоАП предусмотрены штрафы, для ООО он составляет трехкратный размер не уплаченной суммы экосбора, но не менее 500 тыс. рублей.

Экологический сбор регулируется Постановлением Правительства РФ от 08.10.2015 N 1073 (последняя его редакция от 23.08.2018) “О порядке взимания экологического сбора” (вместе с “Правилами взимания экологического сбора”).

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

(далее…)

Read More

БИНОМ: WEB приложение по обмену с 1С и Маркетплесайми

В виду отсутствия решений на платформе 1с fresh – было принято решение разрабатывать собственное программное WEB решение с нуля.

Сформулированы и поставлены следующие задачи:

  • Настроить серверную среду (настройка операционной системы на удаленном сервере, установка и настройка необходимых библиотек, модулей и интерпретаторов);
  • Создать закрытую и публичную части приложения;
  • Создать БД и осуществить ее первичное наполнение вводными данными (изображения, описания, характеристики продукции, артикулы и т.д.);
  • Автоматизировать обмен между программой учета (1сfresh) и программой обмена (автоматические обработки данных из выгруженных 1с таблиц, их последующая запись/перезапись в базу данных приложения);
  • Автоматизировать формирование документов обменов (фидов) на основе обработанных и записанных данных в БД приложения для площадок: Сбермегамаркет, OZON, Яндекс.Маркет, согласно техническим спецификаций каждой из площадок;
  • Создать публичную часть приложения (веб сайт), который будет представлять из себя быстрый комбайн, состоящий из корпоративного сайта, витрины продукции (с описанием и характеристиками), с заявленными РРЦ ценами, автоматически обновляемыми из программы учета, с возможностью быстрого перехода на Маркетплейсы по конкретному артикулу для осуществления покупки

Кратко по реализации задачи
Сервер:

  • Были установлены и настроены следующие компоненты:
  • В качестве ОС была выбрана Linux Cent OS 7.0, проверенная и стабильная ОС.
  • На нее установенны следующее ПО:
  • Веб сервер: Apache HTTP 2.4.6;
  • Сервер БД: MySQL 5.7.23;
  • PHP интерпретатор: версии 5.4.16 (а также все необходимые расширения к нему)
  • SSI
  • Zend Guard Loader
  • Библиотека для работы с табличными данными форматов xls, xlsx, csv: PHPExcel
  • Система управления контентом (для публичной части сайта): WordPress
  • В качестве базы для создания витринной части установленно расширение WooCommerce

Заполнение БД первичными данными
Произведено создание сущностей в WooCommerce, перенсены артикулы из 1С, описания товаров, и их характеристики с профильных сайтов ТМ, изображения.

Автоматизация обмена между 1cfresh и приложением

Остатки

Так как изначальная идея создать отдельный, но общий склад под МП была отметена, в виду желания сотрудников контролировать остатки индивидуально по каждому МП – в 1С завел склады: “Сбермегамаркет”, “OZON”, “Яндекс.Маркет”. На стороне 1с настроил формирование и отправку отчета по FTP с остатками по расписанию (каждый час, начиная с 7:30 до 22:00), в формате xls: Ostatki_MP (XLS).xls
В шапке отчета не указанно название склада, так как я заранее определил порядок колонок, и обработчик на стороне веб сервера привязывается к идентификатору колонки.

В приложении создал поддериктории: www/binom.shop/mp.binom.shop | www/binom.shop/oz.binom.shop| www/binom.shop/yandex.binom.shop, для соответствующих складов и дополнительные подбазы к ним.

Для каждой директории при обработке таблицы введены дополнительные зависимости, идентификаторов колонок “остаток” в таблице из 1С и колонок “_stock” в БД приложения (чтобы в зависимости от того, для какой директории происходит сверка, значения записывались в нужные колонки БД приложения).

Приложение читает таблицу и производит сверку данных из первой колонки “артикул”, с данными из своей БД из ячеек колонки  “_sku”.

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

Данные процедуры выполняются автоматически, для каждой директории (склада). На сервере созданы CRON задания. Каждый час происходит чтение и обработка выгруженной таблицы из 1С по описанному алгоритму.

Сам процесс записи данных в БД приложения после сверки происходит фрагментарно (чтобы в случае сбоя, начинать процесс перезаписи с испорченного фрагмента, а не полностью) по 20 значений за проход.
Для этого каждый час запускается php cкрипт-триггер, который инициализирует обработку данных. А каждые 2 минуты запускается php экшн, который проверяет завершена обработка или нет, если не завершена (по причине сбоя, или из-за ресурсных ограничений) – он ее возобновляет с фрагмента, на котором процесс был остановлен.

Дополнительно
По площадке Яндекс.Маркет в связи с тем, что для ряда товаров вместо артикула на площадке указывался код из 1С (это не артикул), а на МП этот код идет в колонку “_sku”, в БД приложения производится индивидуальная выгрузка кодов номенклатуры из 1с, их связь с артикулами, а в файл фида (выгрузки для МП), в столбец “_sku” записывается код номенклатуры (не артикул), с прописанным условием – если столбец “код номенклатуры” заполнен для конкретного артикула.

По остаткам доступно несколько схем (так как ваши предпочтения менялись): загрузка остатков из 1С в приложение с общего склада (любого), загрузка остатков из 1С с отдельных для каждого МП складов.

Цены

На МП можно передавать 2 типа цен – “цена со скидкой”, “цена без скидки”. В нашем случае вытягивать из программы учета в эти типы цен нечего, так как в эти поля ставятся вручную выведенные и специально завышенные цены, а ррц проставляются в формате акций. Участие в акциях осуществляется в интерфейсе самих МП и туда ничего передать нельзя.

Поэтому было принято решение автоматизировать самое рутинное – ввод двух типов цен на все МП. В качестве файла для обработки была взята удобная для сотрудников (созданная ими же) таблица, в которой они высчитывали два типа цен по своим формулам, а после вбивали их на площадки. Таблица вида: MP_PRICE.xls

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

После связи товаров, происходит запись из ячеек в колонки пользовательской таблицы “Текущая цена” в ячейки столбца “_regular_price” в БД приложения. И из ячеек в колонки “цена без акции” в ячейки колонки “_sale_price” соответственно. Аналогично алгоритму с остатками – с учетом дополнительных зависимостей для директорий. Процесс записи данных в БД приложения также фрагментарный, и состоит из 2 процессов, как и в случае с остатками.

Итог: по одному складу (Маркетплейсу), ежечасно идет 2 задачи, состоящие, каждая из двух процессов, один из которых воспроизводится каждый час, другой каждые 2 минуты. Таких складов на данный момент – 3 шт.

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

Дополнительно
По площадке Яндекс.Маркет в связи с тем, что для ряда товаров вместо артикула на площадке указывался код из 1С (это не артикул), а на МП этот код идет в колонку “_sku”, в БД приложения производится индивидуальная выгрузка кодов номенклатуры из 1с, их связь с артикулами, а в файл фида (файла выгрузки для МП), в столбец “_sku” записывается код номенклатуры (не артикул), с прописанным условием – если столбец “код номенклатуры” заполнен для конкретного артикула.

Автоматизация обмена между приложением и Маркетплейсами

После вышеописанных процессов, приложение формирует фиды (файлы), в которые заносит обработанные данные из своей БД: информацию об остатках, ценах, передает артикулы, и названия товаров. Соотношение товаров на стороне МП также проходит по ячейкам из столбца “_SKU” (артикулах).
Фид формируется для 3-х площадок согласно техническим требованиям каждой из них:
Сбермегамаркет: https://min-lb-vip.goods.ru/mms/documents/assortment/%D0%9F%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D0%B0%20%D0%B7%D0%B0%D0%BF%D0%BE%D0%BB%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F%20XML%20%D1%84%D0%B8%D0%B4%D0%B0.pdf
Ozon: https://seller-edu.ozon.ru/work-with-goods/zagruzka-tovarov/created-goods/fidi?utm_source=Products
Яндекс.Маркет: https://yandex.ru/support/marketplace/assortment/auto/url.html

Также проработаны неочевидные особенности, выявленные в момент обкатки приложения. А именно:

Ozon разделяет склады для крупногабаритного товара и не крупногабаритного и не умеет принимать информацию об остатках для разных складов с одного фида. В связи с этим, в приложении добавлен дополнительный признак “Normal” и “KGT для товаров, а также генерируется не один, а сразу 2 фида, для товаров с двумя признаками, в зависимости от признака, сущность попадает либо в выгрузку для КГТ товаров либо в выгрузку для обычных товаров. Оба фида обновляются и генерируются ежечасно.

В фид для Сбермегамаркета добавлена переменная “EAN” и “model”, которая дополнительно подтягивает для каждой сущности штрихкод и модель и выгружает это в МП.

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

Площадки в свою очередь обрабатывают файлы по собственному расписанию.
Так Озон, гарантированно обрабатывает фид раз в 6 часов (на практике чаще раз в 1-2-часа).
Яндекс.Маркет – каждый час, но оставляет за собой право снизить расписание обхода загруженных к ним файлов, в зависимости от частоты и регулярности изменений в последних (чем реже изменения – тем реже обход).
Сбермегамаркет обещает обрабатывать фид сразу после изменений, на практике – это ложь, которую подтверждают все специалисты. Из моих наблюдений обновление происходит раз в 4-6 часов, но бывает и очень часто. Частота обновлений на стороне площадок от нас фактор не зависящий. В любом случае, даже при худшем сценарии, сотрудник освобождается от рутинной работы.

Внешняя оболочка

У приложения есть оболочка, которая является сайтом комбайном: binom.shop

Сайт Binom.shop

На нем есть и информация о компании, и витрина с товарами, с их характеристиками, изображениями (оптимизированными до формата WebP), возможностью скачать инструкции к товару.

А также узнать актуальную розничную цену производителя, РРЦ выгружаются из 1С автоматически, ежедневно.

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

Жду одобрения площадки от Яндекса, для предоставления API сравнения, если одобрят, можно будет проводить сравнения средствами Яндекс витрины прямо на страницах сайта.

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

Ниже общая схема проекта

 

UPD: сотрудники сообщили, что цены из своих пользовательских таблиц они будут проставлять одинаковыми для всех МП – 3 директории для загрузки пользовательских прайсов объеденены в одну.

Перейти на главную

Read More