stalker20
-
Posts
15 -
Joined
-
Last visited
stalker20's Achievements
-
при двустороннем обмене заказами нашёл грабельки--если в 1С поменять количество товара или добавить товар--то всё ок. если удалить товар--то на сайте он остаётся. в модели вижу внутри private function updateDocument вижу закомментированный кусок кода, который вроде как должен эту проблему устранить, но похоже закомментировано оно не просто так--после того как их задействовал, началось непонятное удаление товара из других заказов. // foreach ($old_products as $product) { // $this->query("DELETE FROM `" . DB_PREFIX . "order_product` WHERE `order_product_id` = " . (int)$product['order_product_id']); // $this->query("DELETE FROM `" . DB_PREFIX . "order_option` WHERE `order_product_id` = " . (int)$product['order_product_id']); // $this->log("Удалены товары и опции в заказе",2); // if ($this->ERROR) return false; // } версия 1.6.4.7, с кучей своих правок, так что не настаиваю--может и я где-то что-то накосячил у кого-нибудь удаление товара в заказе работает из 1С на сайт?
-
ocstore 2.3.0.2.3. модуль 1.6.4.7 (с правками). столкнулся--двусторонний обмен заказами работает только если в обмене ZIPархивы. и ещё один багоглюк(пока не воспроизводил, да и модуль у меня немного изменён--возможно из-за моего вмешательства глюк) пока настраивал двусторонний обмен заказами(выгружать изменённые--"да", статусы не использовать, загружать заказы--"да"), положил товар в корзину, провёл оформление до момента нажатия на кнопку "подтвердить заказ", то есть заказ как таковой ещё не виден в админке, ибо его формально ещё нет--но он попал в обмен, без статуса. прикручу какую-нибудь проверку, посмотрите у себя сами
-
да. ищем в модели private function setDocumentRequisites, там добавляем что-то типа такого: $requisites['Способ доставки'] = $order['shipping_method']; и всё, способ доставки пишется в реквизиты документа, дальше на стороне 1с делаем с этим что хотим
-
в журнале кроме ругани на SEO на первый взгляд ничего интересного. можно генерацию SEO отключить, и посмотреть--не в нём ли затык. и я бы попробовал для начала грузить совсем маленькую группу--на несколько товаров, мало ли утыкается в ограничение веб-сервера. или этот же обмен настроить на выгрузку частями, хоть ваших пару тысяч товаров это не так и много, но хостинг тоже всякий бывает.
-
@mazioka , первым делом логи, изучаем логи.. если учётная система не получает succes, значит где-то что-то произошло с ошибкой. что именно--надо искать в журнале ошибок. модуль обмена обучен записывать туда почти каждый чих. найдёте где появляется ошибка--можно подумать из-за чего она и как починить.
-
задумался о обмене заказов с их статусами (для реализаци отложеной оплаты задумка). пока оставим в стороне программную реализацию, это дело техники. как оно вообще должно работать? если у меня, например, стоит "Статус для выгрузки: ожидание" и "Статус выгруженных: в обработке", то понятно--обмен выберет заказы в статусе "ожидание", созданые позже последнего обмена, и при обмене присвоит им статус "в обработке". ещё не вникал в код, возможно и сам найду ответ -- что происходит при настройках статусов в положении "не использовать"? с оглядкой на дату выгрузки и изменения будут обработаны все заказы, а вот со статусом выгруженых что произойдёт? так понимаю, что новый статус им будет сообщён учётной системой как значение реквизита, и если одноимённые статусы присутствуют в настройках сайта, то они будут присвоены, или нужно где-то указать соответствие статуса на сайте и статуса из файла обмена из учётной системы?
-
столкнулся с непонятным, подозреваю что где-то ограничения сервера кровь портят. дано: ocstore2.3.0.2.3, модуль 1.6.4.7 с изменениями(впрочем даже на чистую cms голый модуль накатывал--то же самое). сервер облачный(то есть сам себе хостер в данном случае). выгружаю товары УТ11 (на удалёнке сервер в организации, админит отдельный человек). товаров где-то так 45 тысяч, картинок грузится тысяч десять. пробовал и архивом по частям, и без архива--всё равно полная выгрузка около часа... проблема в следующем: УТшка пишет дату выгрузки, но не обновляет дату успешной выгрузки. со стороны сайта по отчётам всё норм, даты офферс и импорт обновляются. я так понимаю, где-то сессия рвётся и сайт передаёт succes, а УТшка его уже не слышит... если вслед полному обмену выгрузить обновление цен и остатков--может подтвердить успешную выгрузку, а может и не подтвердить. навскидку--если раз в пять минут запускать обновление, обычно всё успешно (за это время передаются изменения по 50..100 товарам), раз в десять минут--уже скорее всего дата успешной выгрузки не обновится. может, ткнёте носом что проверить и куда нажать, чтоб было правильно?
-
сам спросил, сам подумал, сам решил. чтобы не отходить от оригинала, в модели поправил метод addUnit (парсинг единиц позаимствовал в 1.6.4.5 в исходниках ) заменил $query = $this->query("SELECT `code`, `name` FROM `" . DB_PREFIX . "unit` WHERE `rus_name1` = '" . $this->db->escape($data['name']) . "'"); if ($query->num_rows) { $code = $query->row['code']; $full_name = $query->row['name']; } на $query = $this->query("SELECT `number_code`, `rus_name1` FROM `" . DB_PREFIX . "unit` WHERE `name` = '" . $this->db->escape($data['full_name']) . "'"); if ($query->num_rows) { $name = $query->row['rus_name1']; $code = $query->row['number_code']; } теперь unit_to_1c заполняется тем чем надо. ну а в карточку товара(или куда там захочется) это вывести уже дело техники.
-
на взгляд дилетанта -- у меня частный случай, который будет не везде применим, но у меня из учётной системы приходит без краткого, а числовой код единицы корректный. в связи с этим--а зачем мне работать с таблицей unit_to_1c, если проще прямо в таблицу product заносить number_code, а потом уже из таблицы классификатора выбирать нужные поля. ошибаюсь или в моём случае это адекватное решение?
-
в любом случае есть смысл посмотреть журнал ошибок в режиме отладки. там будет более-менее видно до какого момента import обрабатывается корректно, и на каком шаге вылетает. offers и не обработается, если import не обработался--ему некуда парсить предложения, если товаров в каталоге нет. точнее он-то обработается, но мы этого не увидим, только в логе будут сплошные "Товар не найден по Ид 13481320-a159-11e8-88f5-ac1f6b2675fb, предложение пропущено."
-
возможно, будет интересно или даже полезно, если грабли той же системы: столкнулся с той же бедой прямо вот на днях, причём по времени совпало с моим ковырянием в коде--что доставило попоболи. откатился на бэкап недельной, потом месячной давности--не помогло. вручную из админки грузится, из эски хоть в архиве хоть без--нет. включил отладку, получил в журнале десятка полтора мегабайт текста. попался на глаза вот такой фрагмент: 2020-01-09 6:24:22 - 2906C upload file: /home/блаблаблабла/public_html/image/import_files/81/8120f223b3e211e78ca80cc47a0c0685_2bc0a7101a6011ea9a23ac1f6b2675fb.jpg 2020-01-09 6:24:22 - 2914C file size: 0 2020-01-09 6:24:22 - 0049C failure 2020-01-09 6:24:22 - 0052C modeFile(): Error create file короче, попалась картинка в товаре какая-то не совсем картинистая. обработка import0_1.xml на этом заканчивалась вылетом, файл предложений обрабатывался и не находил в каталоге товаров в виду их отсутствия. после удаления картинки в эске всё заработало. что за файл и почему не смог обработаться ещё не искал.
- 5,128 replies
-
- 1
-
-
- обмен данными
- ocmod
- (and 1 more)
-
а вот кстати у меня теперь тоже так(взмахнул напильником, прикрутил к 1.6.4.7 единицы измерения из более старой версии), и в глаза бросилось несоответствие краткого наименования (name) с числовым кодом и полным названием единицы. чудится мне, что всё из-за того, что в offers у меня <БазоваяЕдиница Код="796 " НаименованиеПолное="Штука" МеждународноеСокращение="PCE"> --нет краткого наименования и parseProductUnit берёт дефолтные "штуки" и потом начинается неразбериха. решения пока не придумал--то ли довольствоваться полным названием единицы, то ли из таблицы к полному подтягивать краткое.
-
присоединюсь к ожиданию ответа. хотелось бы в 1.6.4.7 или последующих версиях увидеть работающие единицы из коробки. в более старых версиях оно же уже "почти было", и оно таки по-хорошему нужно. когда товаров мало, можно нужное поле добавить и ручками поназначать, но если уже у сайта возникла необходимость импортировать товары сотнями и тысячами из учётной системы, в рукопашную уже ничего не сделаешь.
-
Ну не настолько оно мне надо, чтобы прямо уж персонально дорабатывать))) Соблазнительно прямо на сайте справочно видеть где и сколько единиц, но в точку самовывоза (сейчас их две) всё равно придёт столько сколько нужно--хоть весь товар выбраной позиции со склада на склад довезём, для конечного покупателя это всё будет просто немного больший промежуток времени между заказом и возможностью забрать товары. Вцелом--модуль достаточно просто увязал сайт с нашей УТшкой, за что огромное человеческое спасибище. Что будет дальше, не упрётся ли наш сайт в возможности модуля или самого опенкарта--кто знает. Может, когда-то на битрикс переедем, но сейчас всё устраивает.
-
А просветите, пожалуйста, кто давно с этим модулем дружит--на ранних скринах, если не ошибаюсь, в версии 1.6.3 для опенкарт2.1 есть раздел работы со складами. насколько оно там работало, есть ли смысл пытаться перенести склады в нынешнюю версию для 2.3?
