IronMann

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

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

А-а... Ясненько, понятненько....

@sergiosinicin,

Они и так нормальные.

Берем любой как заготовку и делаем решение под клиента.

У кого нибудь модуль удаляется описанной автором процедурой: http://(адрес сайта)/export/exchange1c.php?module=remove ?

У меня выводится таблица с сообщением об ошибке: Fatal error: Call to a member function link() on null in C:\Program Files\VertrigoServ\www\admin\controller\error\not_found.php on line 16

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

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

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

Что касается моих смелых заявлений про "некие абстрактные дешёвые решения" - 1С UMI (мастер создания сайта интегрирован, к примеру, в УНФ 1.6), Адвантшоп, 1С-Битрикс: Управление сайтом - Малый бизнес. Всё это укладывается в планку порядка 40 косарей и ниже и имеют законченные рабочие модули интеграции с 1С. Просто мониторю рынок и много времени найти эту информацию не занимает. Привожу эту информацию совершенно не в качестве агитации, а просто чтобы иллюзию величия и желание стричь суммы с четыремя нулями за кастомные работы развеять. Извините, если что не так. Это опять же из разряда "мы найдём программиста и он нам напишет систему (напишем сами)" или "мы научимся работать в 1С и решать там наши задачи".

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

в индивидуальных же решениях в цене будет 4 нолика

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

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

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

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

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

В настоящий момент, здесь на форуме представлено три модуля обмена данными ocS и 1C. Первоисточник (в стадии вечного допиливания), слегка причёсанный зашифрованный и платный вариант первого, будем считать вторым, и третий, сделанный путём глубокого анализа и переписывания первого.

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

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

При попытке добавить товар в корзину, появилась вот такая ошибка:

Без установленного модуля, ошибки не возникает.

А что именно выгружается? Двусторонний обмен статусами заказов с сайтом производится?

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

Относительно конфигурации УНФ 1.6, с которой веду работы по тестированию модуля. Там есть таблица соответствия статусов, но она заточена на обработку входящих статусов, т.е. конфигурация получает статус из orders.xml с сайта, она ищет прописанный ему в настройке обмена соответствующий статус в конфигурации и устанавливает его. Это однонаправленный обмен, т.к. по сути обрабатываются только изменения статуса заказа, происходящие на сайте. С точки зрения бизнес-логики, это полезно для:

1) Создания нового заказа (статус - новый)

2) Изменения заказа на сайте, например, если есть возможность менять состав заказа через личный кабинет клиента (статус - заказ изменён).

3) Отмена заказа, которая производится через сайт (статус - отмена заказа).

В обратную сторону, УНФ 1.6 передаёт магазину ТОЛЬКО следующие данные и ничего другого:

1) Наличие, номер и дата, привязанного к заказу документа оплаты

2) Наличие, номер и дата, привязанного к заказу документа отгрузки

Причём, никакой конкретики (полная/частичная оплата или отгрузка) УНФ 1.6 не передаёт. Там есть ещё одна ошибка, но на глобальную суть вопроса она пока кардинально не влияет. У меня нет рабочей УТ-шки, на которой производится тестирование модуля автором, по этому, не знаю, как это работает там.

Текущая версия модуля эти данные от УНФ 1.6 пока не обрабатывает, т.е. смена статусов в обратную сторону не производится. Если оформить изложенную выше информацию в виде технического требования, то думается, в разделе настроек модуля (речь идёт пока только относительно УНФ 1.6), должна быть таблица соответствия комбинации признаков наличия документов оплаты и отгрузки в заказе из 1С соответствующему статусу заказа в магазине. Почему именно комбинации, потому, что некоторые магазины работают наложкой, т.е. отгрузка у них предшествует оплате. Чтобы совсем было понятно, моё видение соответствия состояний заказа из 1С, текущим дефолтным статусом ocStore, чисто для примера:

1) Не оплачен, не отгружен - "Ожидание"

2) Оплачен, не отгружен - "Оплачен"

3) Не оплачен, отгружен - "Доставлено"

4) Оплачен, Отгружен - "Сделка завершена"

ardashev06, по "Мой склад" ничего подсказать не могу. Тестирую указанный модуль с конфигурацией 1С УНФ.

Проверь, стоят ли у тебя везде у товаров уникальные артикулы.

Откуда и куда? Обмен заказами с 1С, как ни странно, двунаправленный.

OcStore версия 2.1.0.2.1

работает пока в отладочном режиме на локальной машине, под управлением VertrigoServ версии 2.44 64-bit.

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

В смежной теме, я написал, что решил посмотреть на код вызывающий ошибку, и на свой страх и риск, в блоке под комментарием "settings" строчку вызывающую ошибку из беты 8

я заменил на аналогичный код из беты 7.

В бете 8 ошибку вызывает условная конструкция с функцией unserialize().

"Notice: unserialize(): Error at offset 0 of 2 bytes in C:\Program Files\VertrigoServ\www\export\exchange1c.php on line 64"

Разумеется, дополнительное условие с этой функцией в бете 8 вами реализовано не просто так, моих знаний на понимание зачем пока не хватает,

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

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

В версии b8 вылезает ошибка "Notice: unserialize(): Error at offset 0 of 2 bytes in C:\Program Files\VertrigoServ\www\export\exchange1c.php on line 64"

В версии b7 такой проблемы не наблюдается. В коде это блок отвечает за раздел настроек. Это ошибка в моих настройках связки 1С/OC? Если да, что надо установить/поменять?

P.S. Да простит меня автор модуля, я взял кусок кода для этого блока "settings" из беты 7 и заменил им аналогичный в бете 8. Там всё дело в одной строчке с функцией unserialize(). Всё заработало! Автор, разумеется, не просто так добавлял этот код, но у меня он явился причиной ошибки, описанной выше.

Ко мне вопрос? Да как обычно указываю. Бета версия 7 с аналогичными настройками работает. Значит, дело не в них.

УНФ 1.5 - модуль версии b8 не работает. Симптомы, такие же как выше.

При попытке обратится к установленному модулю для тестового ответа - пишет про ошибку в строке 64.

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

Может кому будет интересно.

Исходная информация - пытаюсь подружить связку ocStore 2.1.0.2.1 + 1С УНФ 1.5.

Для обмена данными, сейчас использую модуль уважаемого Kirillove.

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

Вторым замеченным нюансом является передача поля адреса в Контрагента. Комбинация полей Страна, Регион, Город, Индекс и Адрес передаются в поле "Юридический адрес" справочника Контрагентов. Это просто для справки. Выглядит довольно криво, буду пытаться решить это на уровне ocStore путём формирования адресной строки нужного мне формата, а для модуля, в качестве пожелания, конечно, будет лучше, если адрес передавался бы в поле "Адрес доставки" справочника контрагентов.

Переданный в УНФ список товарных позиций с ценами позициям не содержат тип данных цен. Можно оставить как есть, можно выбрать тип цен непосредственно в заказе, если нужно, а можно - всё таки передавать тип цены в УНФ, благо, в настройках модуля же указано соответствие цен сайта типам цен 1С.

Но больше, конечно, напрягают другие вопросы. В наибольшей степени - в 1С не передаются данные о методе доставки. Честно говоря, пока слабо себе представляю, как это может быть сделано в существующих формах и полях формы заказа УНФ. Сейчас, информация о типе доставки в УНФ присутствует у меня в виде номенклатурных позиций с типом "Услуга" и стоимость этой позиции непосредственно определяет менеджер, обрабатывающий заказ в УНФ. Красивым решением, была ба трансформация в модуле обмена типа доставки в соответствующий элемент справочника номенклатуры. Настройка бы была примерно в том же виде, что и тип цен для обмена данными по товару. Т.е. таблица соответствия - тип доставки, товарная позиция 1С. Но это уже кастомизация модуля. В качестве костыля сошла бы просто передача типа доставки в поле "Комментарий" к заказу. Причём, костыль этот может быть реализован как в модуле обмена данными, так и в модуле ввода заказа. Идеологически правильнее, разумеется, чтобы это было в модуле обмена данными.

Такие вот первичные наблюдения.

Я понял. Примерно что-то подобное и ожидал... Дело в том, что у меня в базе клиентов есть полные тёзки, при этом совершенно разные люди. Отличаю их по адресу. ИНН, разумеется, никто в заказах физиков не указывает. :)

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

Объявляется тендер на проведение разовых работ по адаптации OcStore 2.0

под действующие процессы работающего интернет-магазина.

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

В этом отношении, существующий алгоритм работы OcStore 2.0 для действующего порядка работы перегружен лишними не нужными шагами.

Что хотелось бы видеть в переработанном варианте, после набора товаров в корзину:

Шаг 1. Вывод публичного соглашения на экран, подтверждение и продолжение работы.

Шаг 2. Ввод данных покупателя. ФИО, индекс, адрес, контактный телефон получателя и емейл получателя. (Все поля обязательны к заполнению).

Шаг 3. Вывод содержимого заказа и адресных данных. Подтверждение заказа.

Как видно, схема оформления заказа предельно упрощена по сравнению с дефолтной. Убраны в частности блоки Новый/старый покупатель (вообще не нужно), Платёжная информация (плательщик и получатель считается одним и тем же лицом), Способ доставки и Способ оплаты (это согласует оператор обрабатывающий заказ в 1С и связывающийся с клиентом). Основной упор делается на корректном заполнении данных покупателя.

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

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

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

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

Конфигурация:

1С УНФ 1.4.8.3

OpenCart 1.5.6.1

+ vqmod 2.4.1

+ OpenCart Exchange 1C 1.5.1

Хочется через штатный механизм УНФ обмена с сайтами выгружать номенклатуру с фото, свойствами и остатками на сайт и импортировать с сайта заказы.

С кондачка, реализовать задачу не получилось.

При установленных чек-боксах (в авторском видео по установке Exchange 1C) только сбрасываются все категории и товары, импорта данных не происходит.

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

Логи, получаемые от модуля OpenCart Exchange 1C в системном логе магазина error.txt , мало информативны. Из них, я только понял, что импортируется содержимое import.xml и возникает ошибка импорта данных из offers.

Прошу ответить тем, кому удалось подружить УНФ и OpenCart через OpenCart Exchange 1C.

Спасибо.

Хорошо. Сужаю и конкретизирую круг задач 1-го этапа.

1. Создание магазина "под ключ" на базе типового ядра с минимальными доработками. Основным требованием является разработка индивидуального графического оформления, "шкуры", грубо говоря.

2. В плане интеграции с 1С УНФ:

а) портирование (выгрузка) данных из справочника номенлатуры в магазин.

б) портирование данных заказа из магазина в 1С УНФ.

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