Обмен данными OpenCart 2.x и 1С по стандарту CommerceML

[Blade]

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

Напишу сразу во всех ветках) прошу указать одну ветку рабочую, а то непонятно где писать и ждать ответа

 

Что по задумке должен выводить этот мод ? (я его переделал под Coloring)

 

<file path="catalog/view/theme/coloring/template/product/product.tpl">

 

   <operation>

<search><![CDATA[<strong><?php echo $product_stock; ?></strong>]]></search>

<add position="replace"><![CDATA[<strong id="stock"><?php echo $product_stock; ?></strong>]]></add>

</operation>

<operation>

<search><![CDATA[<span ><?php echo $price; ?></span>]]></search>

<add position="replace"><![CDATA[<span id="price"><?php echo $price; ?></span>]]></add>

</operation>

<operation>

<search><![CDATA[<span class="tax"><?php echo $text_tax; ?> <?php echo $tax; ?></span>]]></search>

<add position="replace"><![CDATA[<span class="tax" id="tax"><?php echo $text_tax; ?> <?php echo $tax; ?></span>]]></add>

</operation>

<operation>

<search><![CDATA[<span class="points"><?php echo $text_points; ?> <strong><?php echo $points; ?></strong></span>]]></search>

<add position="replace"><![CDATA[<span class="points" id="points"><?php echo $text_points; ?> <strong><?php echo $points; ?></strong></span>]]></add>

</operation>

 

 

и второй вопрос - прошу ответить на вопрос в скайпе и на почте  :-)

 

 

зы 11 версия ураган ! работает супер.После 6 это первая которая так адекватно и безошибочно работает. Спасибо !

[Kirillove]

код в 1С = код товара на сайте. Артикул = модель на сайте. Выгрузить так, чтоб оба значения присутствовали в карточке товара, как и в 1С

По-умолчанию 1С не выгружает код товара, необходимо дорабатывать саму 1С, мой модуль содержит константу для чтения кода из поля, для примера: "<Код>ЦБ00-000654</Код>" в каталоге товара, значение тоже указал примерное какое может быть, но это поле просто записывается в массив $data['code'] для дальнейших реализаций в будущих версиях. Этот код бывает и кириллицей, так что его нужно обязательно как-то обрабатывать.

 

Код товара на сайте это поле "model", а артикул - это "sku". Модель на сайте иногда отображается из поля "model", это зависит от шаблона.

Реализовать это не сложно.

[Kirillove]

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

Завтра исправлю ошибку.

Ошибку можно посмотреть тут: 

[konstantinod]

Виталий вопрос под версию 2.3 работать будет?

[Kirillove]

Виталий вопрос под версию 2.3 работать будет?

Версия 1.6.2.b12 нет

[Kirillove]

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

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

[IronMann]

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

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

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

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

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

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

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

Змінено 5 лютого 2017 користувачем IronMann

[IronMann]

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

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

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

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

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

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

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

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

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

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

 

[Kirillove]

В 04.01.2017 в 09:38, konstantinod сказал:

Виталий вопрос под версию 2.3 работать будет?

Уже в процессе разработка под opencart 2.3

Пока только на стадии переделки, файлы будут отдельные это точно. Посмотреть можно на моем тестовом сервере для opencart 2.3.0.2.CMS

логин/пароль: demo/demo

[Kirillove]

В 05.02.2017 в 18:44, IronMann сказал:

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

Добавлю в настройках заказа какой статус будет присвоен при:

1. оплата
2. отгрузка
3. оплата и отгрузка

При этом поле date_modification не будет изменен, иначе заказ обратно полетит в 1С.

А вот если статус был изменен модулями в opencart, например модулем доставки или модулем оплаты, тогда это поле должно быть модифицировано и заказ полетит в 1С.

[IronMann]

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

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

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

Змінено 12 лютого 2017 користувачем IronMann

[Kirillove]

6 минут назад, IronMann сказал:

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

Сначала 1С получает заказы а затем отправляет

10 минут назад, IronMann сказал:

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

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

Надо фильтр? Давай сделаем скажи как?

[IronMann]

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

[IronMann]

18 часов назад, Kirillove сказал:

Добавлю в настройках заказа какой статус будет присвоен при:

1. оплата
2. отгрузка
3. оплата и отгрузка

При этом поле date_modification не будет изменен, иначе заказ обратно полетит в 1С.

А вот если статус был изменен модулями в opencart, например модулем доставки или модулем оплаты, тогда это поле должно быть модифицировано и заказ полетит в 1С.

Ты эту дату  date_modification держишь в какой либо дополнительной таблице? Я просто думал, что будет более изящно не держать эту дату отдельно в какой-либо созданной дополнительной таблице, а использовать те же таблицы, в которых ИМ хранит у себя историю заказов. Модуль обрабатывает отданные со стороны 1С заказы, проверяет наличие событий, устанавливает статусы привязанные к событиям и сохраняет запись об этом в истории заказов.

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

Смотрим дальше. Как ты пишешь, если сначала 1С получает заказы а затем отправляет, соответственно, модуль в начале отправляет заказы, а потом получает. Значит в текущем сеансе, эти изменения статусов в 1С уже выгружены не будут (т.к. выгрузка в 1С уже состоялась). В следующем сеансе, если на эти статусы настроены фильтры, они попадут в 1С. И это не плохо, а хорошо - это даже очень хорошо!  Объясняю, почему. Смотри, сейчас, когда я вижу по заказам документы оплаты и отгрузки, я обычно руками выставляю этим заказам в УНФ статусы - есть полная оплата, значит ставлю статус "в работе, оплачен", после того, как эти оплаченные заказы отгружаю, ставлю руками статус "выполнен". Если же те же самые заказы с указанными статусами будет передавать модуль - мне не надо будет больше делать смену статусов руками! Эту работу будет делать за меня модуль. Ещё один участок рукоделия будет автоматизирован.

 

Змінено 13 лютого 2017 користувачем IronMann

[Kirillove]

В 13.02.2017 в 21:18, IronMann сказал:

Ты эту дату  date_modification держишь в какой либо дополнительной таблице?

Она хранится в настройках opencart, можно еще сказать реестр (как в винде), таблица setting. 

 

В 13.02.2017 в 21:18, IronMann сказал:

в которых ИМ хранит у себя историю заказов

они тоже хранятся в настройках opencart

 

В 13.02.2017 в 21:18, IronMann сказал:

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

Так в принципе все и работает, при изменении статуса (документа) 1С выгружает его на сайт и уже там модуль должен принять документ определить статус и либо обновить документ если были изменения либо просто изменить статус.

 

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

[IronMann]

Да, я тебя понял. Сейчас попробую систематизировать решение.

 

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

Действие: модуль должен перезаписать состав заказа и установить ему статус, соответствующий текущему статусу заказа в 1С. В историю заказов внести запись о смене статуса  (даже если он одинаковый с предыдущим) в поле комментария к записи указать причину события ("Заказ был изменен").

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

 

2. 1С передает в ИМ изменение статуса заказа. Изменение производится на стороне 1С, в подавляющем количестве случаев в ручную.

Действие: модуль переустанавливает статус заказа в ИМ и вносит в историю заказов запись о смене статуса. По сути, делается всё тоже самое что и в п.1, но только состав не меняется. Можно тупо забить и объединить п.1 и п.2, а можно - проверять, менялся ли состав заказа, чтобы не выполнять ненужных операций перезаписи.

Чтобы заказ эхом не улетал обратно в 1С, временем изменения установить время начала текущего сеанса минус секунда.

 

3. 1С передает в ИМ одно из четырех событий (полная оплата, полная отгрузка, полная оплата и полная отгрузка, просрочка оплаты).

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

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

ВАЖНО! При наложении в рамках одного сеанса изменения статуса в 1С заказа с событием - приоритет установки нового статуса в ИМ отдавать событию.

 

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

Действие: модуль стандартно отрабатывает выгрузку согласно своим настройкам. Ничего особо оговаривать не требуется - либо возможность менять состав заказа через админку ИМ используется и разрешается в 1С настройками, либо нет.

 

5. ИМ передает в 1С измененный статус заказа.

Действие: модуль стандартно отрабатывает выгрузку заказа согласно своим настройкам выгрузки.

 

Думаю, изложил.

Змінено 16 лютого 2017 користувачем IronMann

[Kirillove]

В 06.06.2016 в 14:44, SergeyYPerm сказал:

 

Тогда получается что я могу и сам через фтп кидать картинки? Модуль проверит что на сайте есть картинка и вставит ссылку в карточку товара?

Именно такая идея которую я буду воплощать

[Kirillove]

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

 

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

[IronMann]

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

 

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

[Kirillove]

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

Также проверил загрузку заказов, тоже сначала ошибка с кодировкой была а потом все поправил. Заказы "Мой склад" не выгружает, так что обмен статусами невозможен. Синхронизацию настраивал с "Битрикс"

 

 

История событий:

 

 

Товар на моем сервере доступен по ссылке:

http://ocstore21021.ptr-print.ru/gruppa-001-25/tovar-001-194.html

ссылка может действовать не долго

[rassigor]

Планирую в течении 2-3 недель открывать магазин на Open Cart, подскажи какая ситуация с модулем? Есть примерные сроки на 2.3? 

Тестировал на 2.1 все работает нареканий не каких нет. Сейчас думаю на какой версии запускать магаз

[rassigor]

Вот такая штуковина заработает? РАсширенная выгрузка

http://1c.1c-bitrix.ru/ecommerce/download.php?id=5045363

Сегодня попробую накачу, сообщу о результатах

[rassigor]

Поставил модуль от Битрикса. Он лучше гораздо стандартного. Все заработало, единственный в модуле поправил строку с кодировкой, почему то сайт не корректно кодировку выдавал.

Выкладываю CF для обновления. 

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

 

 

 

В общем модуле  Б_ОбменССайтомСервер  надо 

Добавить вот эту строчку 

 

 Если лКодировка="ml" тогда
        лКодировка="UTF8";
        КонецЕсли;

добавить надо в двух местах

 

 

чтобы было вот так.

 

надо код поменять 

Попытка
        
        HTTPОтвет = Соединение.ОтправитьДляОбработки(ПолноеИмяФайла, СокрЛП(ПараметрыЗапроса), ИмяФайлаОтвета, СокрЛП(Заголовки));
        ContentType = HTTPОтвет.Заголовки.Получить("Content-Type");
        лКодировка     = Прав(ContentType, СтрДлина(ContentType) - (Найти(ContentType, "charset=")+7));
        
    Исключение
        
        СообщитьПодробно(ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()), ПараметрыОбмена);    
    КонецПопытки;
    
    ФайлОтвета = Новый Файл(ИмяФайлаОтвета);
    
    Если ФайлОтвета.Существует() Тогда
        Если лКодировка="ml" тогда
        лКодировка="UTF8";
        КонецЕсли;
        ЧтениеТекста = Новый ЧтениеТекста(ИмяФайлаОтвета, лКодировка);          
        ТекстОтвета = ЧтениеТекста.Прочитать();
        
        Если НЕ ПустаяСтрока(ТекстОтвета) Тогда
            ОтветСервера = ТекстОтвета;
        Иначе
            СообщитьПодробно("Получение данных с сервера: Получен пустой ответ сервера.", ПараметрыОбмена);    

        КонецЕсли;
        
    Иначе
 

 

1Cv8.cf

User manual 6 UF.docx

Змінено 27 лютого 2017 користувачем rassigor

[Kirillove]

12 часов назад, rassigor сказал:

Поставил модуль от Битрикса. Он лучше гораздо стандартного. Все заработало, единственный в модуле поправил строку с кодировкой, почему то сайт не корректно кодировку выдавал.

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

[rassigor]

Подскажи как обстоит дело с единицами измерений? Они выгружаются? Мне надо чтобы была упаковка и базовая единица соотвественно цены будут с учетом пересчета, как это  вывести в карточке заказа?