exchange1c Модуль Модуль обмена для opencart v2.3 по стандарту CommerceML [Поддержка]

[rassigor]

if (!$data['product_id']){                     $this->ERROR = "parseDocumentProducts(): Товар '" . $data['name'] . "' не найден в базе по Ид '" . $data['product_guid'] . "'";                     return false;                 }

 

 

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

Змінено 13 травня 2018 користувачем rassigor

[IronMann]

В ‎12‎.‎05‎.‎2018 в 05:21, Kirillove сказал:

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

Сделайте уже наконец Доставку...

 

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

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

[rassigor]

Вот пример как сделана доставка в другом модуле) просто и легко

Выгружается в теги коды,  а я уже в 1с их ловлю и добавляю доставку,  оплату 

Змінено 13 травня 2018 користувачем rassigor

[IronMann]

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

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

[IronMann]

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

надо сделать мораторий на новые хотелки,  все новые хотелки только платно,  а вам сосредоточиться только на отладке функционала

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

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

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

Змінено 13 травня 2018 користувачем IronMann

[Kirillove]

Не успел я все сделать, только половина сделал того что планировал, доделаю и выпущу новую версию только к числу 15 мая.

[Kirillove]

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

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

Вот чем я сейчас и занимаюсь, выкидываю "глючное" и доделываю...

И по доставке тоже буду делать... 

У меня с адресом конечно головняки, надо как-то сайт привязать к FIAS

[IronMann]

Вы о чем? Адрес контрагента?

Не надо его ни к чему привязывать. В 1С он может передаваться из модуля как строка, т.н. "адрес в свободной форме". А если есть огромное желание его причесать, то делать это надо либо на этапе ввода заказа в интернет-магазине, либо на этапе записи заказа в базу данных интернет-магазина. После определенных исканий я в и тоге пришел к тому, что в интернет-магазине нужно использовать сервис dadata.ru

Уже есть модули, которые используют этот сервис в режиме "подсказки", т.е. предлагая варианты ввода правильных значений на этапе ввода адреса. Это процентов на 70% решает вопросы с адресом.  В планах есть написать ТЗ на Fraud модуль, который помимо функций первичной фильтрации мутных заказов и отсечки по Black List заказов от неадекватов, будет выправлять адреса во всех проходящих через него заказах, при помощи того же dadata.ru

 

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

Змінено 13 травня 2018 користувачем IronMann

[PRScreen]

В 11.05.2018 в 20:33, Kirillove сказал:

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

Проблема обнаружилась у хостера - при смене сервера они зачем-то поменяли настройки, и кодировка сайта оказалась CP1251 вместо UTF-8. Но и после правки кодировки модуль глючило. Пришлось откатиться на 1.6.3.11, тогда заработало, как было.

[sem6336]

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

 

 

Fatal error: Uncaught exception 'Exception' with message 'Error: Unknown column 'middlename' in 'field list'<br />Error No: 1054<br />SELECT `firstname`,`lastname`,`middlename`,`company`,`company_inn`,`company_kpp` FROM `oc_customer` WHERE `customer_id` = '0'' in /var/www/u0430242/data/www/sport-magic.com.ru/system/library/db/mysqli.php:40 Stack trace: #0 /var/www/u0430242/data/www/sport-magic.com.ru/system/library/db.php(16): DB\MySQLi->query('SELECT `firstna...', Array) #1 /var/www/u0430242/data/www/sport-magic.com.ru/admin/model/extension/exchange1c.php(188): DB->query('SELECT `firstna...') #2 /var/www/u0430242/data/www/sport-magic.com.ru/admin/model/extension/exchange1c.php(7061): ModelExtensionExchange1c->query('SELECT `firstna...') #3 /var/www/u0430242/data/www/sport-magic.com.ru/admin/model/extension/exchange1c.php(7232): ModelExtensionExchange1c->getCustomerInfo(Array) #4 [internal function]: ModelExtensionExchange1c->queryOrders(Array) #5 /var/www/u0430242/data/www/sport-magic.com.ru/system/storage/modification/s in /var/www/u0430242/data/www/sport-magic.com.ru/system/library/db/mysqli.php on line 40

Змінено 14 травня 2018 користувачем sem6336

[sem6336]

Если все заказы удалить, то никакой ошибки нет... Не знаю, поможет это в решении проблемы или нет.

[pasha2203]

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

[IronMann]

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

 

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

 

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

 

Ну и в заключении, обозначу, что мой корыстный интерес в происходящем - это получение надежного и стабильного инструмента для связи УНФ и ocStore. У меня тоже есть хотелки, главная из которых - чтобы весь типовой функционал УНФ был по максимуму использован в типовом ocStore 2.3.2.3. Чтобы был полностью двунаправленный обмен заказами, с доставкой. И в этом плане, я готов предложить свой опыт профессиональной разработки информационных систем Виталию, включая опыт управления требованиями. Делаю это безвозмездно. Я не владею хорошо тонкостями программирования на PHP в разрезе Опенкарта и методикой написания модулей в нем, иначе бы все давно уже сделал сам. Но вот в плане сопряжения информационных систем и баз данных, требований к интерфейсу, пользовательских сценариев - разбираюсь более чем хорошо. И с SQL дружу. Если Виталию мой опыт будет полезен, хорошо. Нет, значит нет.

Змінено 14 травня 2018 користувачем IronMann

[pasha2203]

7 часов назад, IronMann сказал:

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

 

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

 

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

 

Ну и в заключении, обозначу, что мой корыстный интерес в происходящем - это получение надежного и стабильного инструмента для связи УНФ и ocStore. У меня тоже есть хотелки, главная из которых - чтобы весь типовой функционал УНФ был по максимуму использован в типовом ocStore 2.3.2.3. Чтобы был полностью двунаправленный обмен заказами, с доставкой. И в этом плане, я готов предложить свой опыт профессиональной разработки информационных систем Виталию, включая опыт управления требованиями. Делаю это безвозмездно. Я не владею хорошо тонкостями программирования на PHP в разрезе Опенкарта и методикой написания модулей в нем, иначе бы все давно уже сделал сам. Но вот в плане сопряжения информационных систем и баз данных, требований к интерфейсу, пользовательских сценариев - разбираюсь более чем хорошо. И с SQL дружу. Если Виталию мой опыт будет полезен, хорошо. Нет, значит нет.

Не соглашусь с вами ни кто ничего не снимал ни каких хотелок...Обычная человеческая благодарность

[IronMann]

Цитировать весь мой пост было не обязательно.

[Kirillove]

В 12.05.2018 в 13:36, IronMann сказал:

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

 

Заодно, это объяснит, почему ваш коллега-конкурент, поднял цену на свой платный модуль с 1800 до 5000 рублей, т.е. почти в три раза, и вопросом конкуренции с вашим модулем даже не парится. При том, что его модуль, по заявленной функциональности уступает вашему в разы. 

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

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

Змінено 15 травня 2018 користувачем Kirillove

[pasha2203]

10 часов назад, IronMann сказал:

Цитировать весь мой пост было не обязательно.

а я думаю что на оборот

[pasha2203]

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

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

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

Вы правы

Змінено 15 травня 2018 користувачем pasha2203

[Kirillove]

Не вырезал еще связанные опции, но убрал склады, водные знаки..

Исправил несколько ошибок....

Пока выложу вдруг кто протестирует, и выявит еще ошибки, 

Модуль остается бетой, не осилил я все почистить, завтра продолжу...

[rassigor]

По 2.1 будете чего нить делать? Или хороним? 

[IronMann]

3 часа назад, pasha2203 сказал:

а я думаю что на оборот

Цитирование большого поста СРАЗУ под сами постом, есть некоторое компьютерное дурновкусие.

[IronMann]

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

Не вырезал еще связанные опции, но убрал склады, водные знаки..

Исправил несколько ошибок....

Пока выложу вдруг кто протестирует, и выявит еще ошибки, 

Модуль остается бетой, не осилил я все почистить, завтра продолжу...

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

 

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

[sem6336]

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

Не вырезал еще связанные опции, но убрал склады, водные знаки..

Исправил несколько ошибок....

Пока выложу вдруг кто протестирует, и выявит еще ошибки, 

Модуль остается бетой, не осилил я все почистить, завтра продолжу...

Здравствуйте, помогите мне пожалуйста, очень надо... я Вам в icq писал. Спасибо

[Kirillove]

В 16.05.2018 в 06:01, IronMann сказал:

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

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

 

[IronMann]

Совершенно согласен, что водяные знаки нужно накладывать только на большие изображения.

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