IronMann

Коллеги, кто использует Unishop 2.1 на ocStore 2.3.0.2 и пользуется Unishop новостным модулем? Есть пара вопросов.

Сбросил документ тебе в скайп.

Я бы всё таки поставил фильтр на выгрузку заказов, в зависимости от их статусов в ИМ. Дело в том, что если в 1С будет улетать ЛЮБОЙ измененный заказ (т.е. без фильтрации), то УНФ, в частности, будет воспринимать этот заказ как новый/изменённый и будет производится совершенно ненужная транзакция на перезапись существующих данных. Идеологически не верно.  К тому же, предположим, заказ может редактироваться в ИМ (это возможно через админ. панель), но выгружаться по логике должен только после пересогласования. А так, будет просто выгружаться на этапе пересогласования, которых может быть много, и каждй раз портить данные в базе 1С. Второй момент, даже более важный. Заказ может проходить ручной или автоматический Anti-Fraud (проверка на мошенничество, проверка на мусорный заказ или заказ от заведомо нежелательных персонажей). При наличии фильтра на выгрузку, такие заказы не пройдут и могут быть вообще просто удалены в админке ещё на этапе нахождения в ИМ, т.е. даже не попадут в 1С, а если выгружать всё без фильтра - будут сразу выгружаться и загаживать базу 1С.

В список событий на изменение статуса загружаемых изменённых в 1С заказов, можно добавить, на будущее ещё событие "просрочка оплаты", о котором мы с тобой говорили недавно.

И вопрос - модуль в начале выгружает изменённые в ИМ заказы, а потом загружает данные изменённых заказов 1С, или делает наоборот - в начале обрабатывает изменения со стороны 1С, а потом выгружает в обратную сторону свои данные?

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

Сам в PHP и MVCL не силен настолько, чтобы написать модуль с нуля, но мог бы всю алгоритмику и интерфейс разработать, если кто-нибудь захочет тандем составить. Если это вообще, конечно, кому-то кроме меня в перспективе нужно.

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

Я понял, спасибо! Как раз этот момент и интересовал.

Не совсем к исходной постановке вопроса, но в моей практике, "левые" заказы это:

1)  Заказы, состоящие из бестолковых данных типа ФИО "dffdfdfdgdfg" адрес: "flglghlghlbdf" , которые создаются людьми "мимо проходил, дай, посмотрю, как здесь магаз работает".

2) Заказы от людей, попавших за те или иные действия в  "чёрный список".

3) Заказы, сгенерированные спам-ботами.

Критерии фильтрации - регулярные выражения для п.1, ФИО / адрес / телефон / e-mail  для п.2 и IP лист для п.3

"Вшитый" в сборку ocStore бесплатный фрод-модуль фильтрует только по IP.

Проблема не так, чтобы стоит остро, но в плане хотелок на будущее, данный набор требований может послужить как ТЗ для фрод-модуля.

Если кто использовал Anti-Fraud модули - в какой момент они срабатывают?

Моей просьбой к Виталию, озвученной ему чуть ранее, будет реализовать включение в модуль передачи в заказ (обратная операция тоже возможна) доставки.

У меня дистанционная (посылочная) торговля и доставка является составной частью любого заказа.

На стороне 1С УНФ, все доставки и прочие услуги (типа предпродажной подготовки) находятся в группе "Услуги для покупателей" и им так же назначен вид "Услуги". Можно настроить отбор и как любой товар выгружать из УНФ в ИМ эти услуги. Они будут выгружаться как вид номенклатуры "Услуга" и тип номенклатуры "Услуга" - это видно в файлах выгружаемых данных. Модуль сейчас загружает услуги как обычные товары, создает для них категории и потом на витрине магазина эти услуги видятся как обычные товары.

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

Я предлагаю следующее - на уровне модуля, ввести в настройки модуля подраздел "Услуги (доставка, предпродажная подготовка, прочеее)".

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

В модуле, сделать настраиваемую таблицу соответствия типов доставки, которые назначены у вас в ИМ названиям услуг, которые импортированы из 1С.

При выгрузке заказов, модуль будет сопоставлять вид доставки из заказа назначенной ему позиции услуги из 1С и передавать как позиция в заказе. Цену данной позиции модуль будет брать так же из цены доставки, прописанной в заказе в ИМ.

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

В ‎07‎.‎02‎.‎2017 в 09:57, sunlit сказал:

Это же и 1с настроенную нужно в комплект ставить + корректно заполненную номенклатуру. Да и не выйдет тут так чтобы "поставил и полетело" - нужно вникать, причем довольно глубоко.

Больше скажу - вникать нужно не просто глубоко, а ОЧЕНЬ глубоко. И даже больше не в технику настройки, сколько вообще в технологию ведения своего бизнеса.

Например, в процессе тонкой настройки модуля на работу со своей УНФ, я понял, как мне нужно "причесать" свой справочник номенклатуры, какие дополнительные реквизиты и свойства назначить товарам, чтобы и справочник не был перегружен и "витрина" в виде инет-магазина была достойной и юзабельной.

В ‎06‎.‎02‎.‎2017 в 20:53, allcoments сказал:

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

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

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

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

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

Статус "Pending". В исходном переводе, звучит как "Ожидание" и везде считается как статус нового заказа. Но всё дело в том, что формально он не является статусом только что созданного заказа. А всё дело в том, что по логике работы опенкарта, в процессе создания заказа, он проходит обработку модулем оплаты. И либо он сразу оплачивается, модуль получает данные о прохождение платежа (например, карточная транзакция) и модуль присваивает заказу статус "Processing", либо оплата ожидается и "Pending" ни что иное, как "Ожидание оплаты".

Статус "Processing". В ocStore, ему назначен перевод "В обработке". Только не уточнено, какой. И неправильно считается, что это обработка заказа, в смысле его проверки. А вот по логике опенкарта, этот статус присваивается после того, как пришла оплата. Что у нас делается, после того, как заказ оплачен? Он комплектуется. По этому, более логичным будет назначить данному статусу перевод "Комплектуется".

Статус "Shipped". Переведён как "Доставлено". Русский язык достаточно ясно подразумевает, что для этого слова, заказ должен находится в точке назначения, а вот логика работы опенкарта говорит о том, что этот заказ вышел из точки отправления. По этому, более правильным переводом, будет являться "Отправлен".

Статус "Complete". Переведён как "Сделка завершена". В общем, перевод правильный, но надо отметить, что по логике работы опенкарта, этот статус присваивается заказу, который доставлен и принят покупателем. Я видел системы, которые отслеживали получение заказа по почтовому треку и разумно считали, что момент завершения сделки есть момент получения заказа покупателем. В торговых системах, которые передают статус заказа в явном виде в CMS, можно разделить события Shipped и Completed. Но на данный момент, УНФ несколько в этом моменте ущербен и статусы не передаёт. Он на них только намекает:

1) Самими фактом отдачи данных в CMS (т.е. при изменении статуса в УНФ, заказ в CMS отдается, но реквизитов статуса там нет).

2) Передачей информации вида Проведён - true/false из которых модуль может почерпнуть информацию, рассмотрен заказ или нет.

3) Передачей информации о полной оплате заказа.

4) Передачей информации о полной отгрузке заказа.

В принципе, этого достаточно, чтобы сделать вполне работоспособный механизм смены статусов в CMS на основании данных от УНФ. В том числе и по статусу Completed, который может означать комбинацию двух событий: Заказ полностью оплачен и Заказ полностью отгружен.

 

По предложению автора темы, выношу свои исследования по работе модуля с конфигурацией УНФ 1.6 в данную тему.

Краткая предыстория. Я веду переписку с Виталием и параллельно глубоко изучаю заложенные в УНФ и CMS наборы схем бизнес-логики, применение этих схем в различных видах организации интернет-магазинов и самое главное - как с наименьшими трудозатратами и наиболее красиво совместить УНФ и CMS в рамках одной информационной структуры, объединить достоинства и обойти недостатки двух этих различных систем. Это уровень исследования всех возможных закоулков опенкарта и УНФ, вплоть до таблиц и значений базы данных и перехвата кода на уровне отладчика. По этому, возможно, тем, кто только начал погружаться в этот вопрос, некоторые вещи могут показаться сходу не до конца понятными, но будем разъяснять по ходу.

Теперь по существу. По поводу заказов. После анализа и моделирования различных возможных схем выгрузки заказов из CMS в УНФ, я пришёл к тем же выводам, что и Виталий - выгружать необходимо изменённые данные, за временной период от момента предыдущего сеанса обмена до текущего сеанса. Были идеи настроить выгрузку как фильтр событий "событие: статус до / статус после", но после более глубокого понимания логики, заложенной в опенкарте, решение склонилось в сторону выгрузки изменений за автопериоды. В УНФ заложена точно такая же логика, причём жёстко.

По поводу изменений админки. Насколько вижу, Виталий оставил событийную обработку "событие: статус до / статус после" для новых заказов, при этом, предполагая, что будут выгружаться так же ВСЕ изменения, т.к. фильтров на них там нет. В этом виде, это будет работать плохо. Объясню, почему. Во первых, в опенкарте нет формально такого понятия, как "новый" заказ. Есть таблица истории, где появляется запись вида "заказ - время - статус". В силу этого, если выгружаются ВСЕ изменения, т.е. вся таблица историй заказов за период, все новые заказы и так попадут в выгрузку, и даже в не зависимости, какой у них вообще статус.

Далее, нет смысла создавать доп. запись о переходе статуса от "новый" к "выгруженный". Модуль и так увидит заказ со статусом "новый" и выгрузит его, а в следующую временную выборку, этот заказ (если он не изменялся) уже не попадет. В смене статуса при выгрузке смысла нет. Для простоты понимания, рассматривайте УНФ как модуль в составе CMS. И в рамках двухстороннего обмена заказами, УНФ возвращает CMS данные заказов, причём полные, включая статусы, товарные позиции, общую сумму заказа, данные о полной оплате и данные о полной отгрузке. Соответственно, новый заказ после выгрузки будет обработан в УНФ, получит там новый статус и с этим новым статусом будет возвращён в CMS. Это и будет статус после выгрузки.

Далее. По поводу выгрузки ВСЕХ изменений, т.е. всех записей в истории заказов за период. Я считаю, что это делать не следует. Нужно сделать настраиваемый набор статусов выгружаемых заказов. Объясняю, почему. Далеко не все заказы, которые появляются в CMS нужно выгружать в УНФ. В первую очередь это касается Fraud заказов, которые могут быть залеплены в магазин просто от балды мимом проходящим, либо сознательно размещаемым скриптами-ботами продвинутыми конкурентами. Такие заказы должны удаляться администратором CMS простым действием "Удалить" в админке и естественно, выгружать их в УНФ никакой надобности нет. Т.е. фильтр на выгрузку нужен. Скажу больше, у себя я ввожу в CMS статус "New"  и все заказы с данным статутом обязательно проходят модерацию модулем Anti-Fraud и последующую ручную модерацию администратором магазина. Можно, конечно, выгружать и левые заказы и гасить их уже в УНФ, но зачем загаживать базу данных УНФ? Тем более, что даже количество кликов мышью по удалению заказа в УНФ больше, чем количество кликов в CMS.

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

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

Я тоже в начале выгружал по первой абы-кабы. А теперь - выгружаю строго выборками. Т.е. причесал раздел товарного справочника - добавил его выборку в план обмена.

В ‎24‎.‎07‎.‎2016 в 22:38, gavi сказал:

Адаптировал модуль под opencart 2 (проверял на 2.1). Выкладываю сюда, надеюсь, автор не будет против.

Как адаптировать данный прекрасный модуль для ocStore 2.3?

Камрад gavi, может, снова поможете?

Поставь любую предыдущую версию. В b19 очевидно ошибка, у меня после обновления на b19 тоже самое. Откатился на b18, ошибки нет.

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

Лучше по умолчанию выключено, пока модуль в статусе беты.  Когда выйдет в релиз и не надо будет уже ничего отлаживать и смотреть - тогда можно по умолчанию очистку включить. Отладочные опции м.б. вообще имеет смысл вынести в отдельную закладку или отдельный раздел основных настроек.

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

А что у вас за конфа? У меня УНФ. Я создал доп. реквизит Модель (строка, 64 байт). При обмене, в SKU карточки товара ИМ попадает значение поля Артикул из справочника номенклатуры, а в поле Модель - значение доп. реквизита Модель.

В процессе работы с модулем, обнаружил достаточно важный момент, который кажется пока ещё не оговаривался - передача в 1С типа доставки.

Сейчас вид доставки выбранный в ИМ не передается из магазина в 1С никак.

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

Быстро же, можно передавать вид доставки ИМ из магазина в 1С через комментарий к заказу.

Для этого, в admin\model\tool\exchange1c.php

строку: ,'Комментарий' => $order['comment']

заменяем на строку: ,'Комментарий' => $order['comment'] . " | Доставка: " . $order['shipping_method']

В результате, в комментарии к заказу видим тип доставки, выбранный в клиентом в ИМ и вбиваем в заказ соответствующую услугу.

Виталий, день добрый!

Добавь, пожалуйста, в список паттернов для SEO тегов паттерн {model} с соответствующим содержанием из карточки товара. Объясняю, почему. У многих в поле Артикул содержится свой внутренний код, а идентификатор модели от производителя они держат как раз в поле Модель. Придя на сайт, покупатель ищет гораздо чаще товар по коду производителя, а не по внутреннему артикулу.

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

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

Во сколько вы оцениваете стоимость этой доработки?

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

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

Мне к примеру, нужен двунаправленный обмен статусами заказов с УНФ. В УНФ есть механизм приема этих статутов со стороны сайта, так же выгружается информация, чтобы была возможность менять статусы на сайте в процессе обмена. Пока это в полном объеме не реализовано нигде. В исходном модуле, ещё под опенкарт 1.5, этого не будет никогда. Во втором модуле, являющимся дописанной, зашифрованной и продаваемой версией первого, продавец достаточно виртуозно, но при этом ясно тоже даёт понять, что это сделано не будет. Я передал техническую информацию и предложения по бизнес-логике третьему разработчику, который сейчас готовит свою версию модуля, может быть, он это сделает. А может и не сделает.