IronMann

Не могу поставить 1.6.4.1 на "голый" ocStore 2.3 - при включении модуля в списке модулей, выдается большой лог ошибок.

Такое же примерно было с 1.6.3.12, пока DjPrizrak  не поправил файлы. Может, кто подскажет быстрое решение?

Вот здесь - opencartforum.com/files/file/3123-modul-obmena-dlya-opencart-v2x-s-torgovoy-sistemoy-po-standartu-commerceml/?tab=changelog

от участника DjPrizrak   совет, как изменить файлы дистрибутива, чтобы ставился 1.6.3.12 на ocStore 2.3

Правишь файлы, снова пакуешь дистрибутив, ставишь.

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

Из личного опыта работы с модулем, я понял, что 70% проблем в некорректном составе исходных данных, по этому вплотную занялся причесыванием всех товарных справочников. Зато потом не будет проблем с экспортом на любую выбранную платформу, если в этом будет необходимость.

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

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

Типы данных в полях БД меняете, что тоже не есть хорошо. Другие модули, обращающиеся к этим данным, перестанут быть работоспособными.

В ‎08‎.‎03‎.‎2017 в 18:54, chamaerops сказал:

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

В общем, буду ставить и тестить..

Обязательно освойте и используйте в УНФ отборы для выгрузки!

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

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

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

Честно говоря, в вашем случае, я бы лучше сделал выгрузку номенклатуры из БД магазина в ексель, а потом из екселя загрузить номенклатуру в справочник в УНФ через функционал загрузки данных из табличного документа. Это всё делается на уровне приложений Микрософт офиса. А дальше, имхо, лучше конечно вести приходы и списания в УНФ, а не на сайте.

2 часа назад, indaled сказал:

Доброго дня!

Озадачился вопросом, возможно ли удалять (или делать неактивными) товары которых нет в файле импорта.

Те например при первой выгрузке на сайт ушло 1000 товаров, а в следующей их осталось 900 (те из 1с они были удалены). Как сделать так чтобы остались только эти 900 ?

 

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

 

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

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

Winrar поставьте свежий, а не времён царя Гороха, и всё совершенно нормально откроется.

А как информация по складам может в дальнейшем в интернет-магазине на базе Опенкарта быть использована? Мультимагазин?

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

Хотя нет, пожалуй, действительно может и модуль не забирает значения, т.к. в import.xml полное наименование есть.

<ЗначениеРеквизита>

  <Наименование>Полное наименование</Наименование>

     <Значение>123456 полное наименование </Значение>

</ЗначениеРеквизита>

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

Совершенно очевидно, что это не проблема модуля, раз указанных данных нет в offers.xml.

Даже не совсем понятна подоплёка этой задачи...

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

Спасибо, за высказанные мнения, учту.

Хочется только немного поправить коллегу toporchillo. Я думаю, что если техническое задание выполнено на достаточно профессиональном уровне, когда заказчиком сформулирована исходная идея и выполнена вся аналитика и постановка задачи - то авторское право принадлежит ему.

А так, да, наверное, как получится договориться.

Не хочу новую тему открывать, спрошу здесь.

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

Имеет ли разработчик право продавать потом оплаченные заказчиком доработки всем желающим?

Да нет, вроде, это означает, что картинки 3 и 4 просто нет.

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

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

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

Возможно, вам поможет бесплатный модуль "Мульти Доставка", он делает как раз то, о чём пишет deeman - создает множество разных типов доставки с выбором радиокнопками и при этом - прописывает в заказ тип доставки. https://opencartforum.com/topic/19535-multidostavka-free/?page=5

Что именно битое?

Проверил архив - с файлом всё в порядке. Используйте WinRAR 5.31 и выше или unrar свежий бесплатный.

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

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С измененный статус заказа.

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

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

8 минут назад, Kirillove сказал:

Пока тормознулась разработка для 2.3 так как сейчас вносятся большие изменения для 2.1
 

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

2 часа назад, Kirillove сказал:

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

Да, это решение уже давно назревает.

У тебя прототип этого присутствует в закладке "Товары" в виде абзаца "Запись свойств товара определяемыми пользователем из торговой системы".

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

Кому нужно для OpenCart/ocStore 2.3 - берите. Надеюсь, автор не будет против.

При адаптации старался ничего не покорёжить, но проверяйте работу тщательно!

multiflat_v2_opencart_2_3.rar

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

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

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

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

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

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

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

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

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

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