Jump to content

stalker20

Новичок
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

1 Обычный

About stalker20

  • Rank
    Пользователь

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. при двустороннем обмене заказами нашёл грабельки--если в 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С на сайт?
  2. ocstore 2.3.0.2.3. модуль 1.6.4.7 (с правками). столкнулся--двусторонний обмен заказами работает только если в обмене ZIPархивы. и ещё один багоглюк(пока не воспроизводил, да и модуль у меня немного изменён--возможно из-за моего вмешательства глюк) пока настраивал двусторонний обмен заказами(выгружать изменённые--"да", статусы не использовать, загружать заказы--"да"), положил товар в корзину, провёл оформление до момента нажатия на кнопку "подтвердить заказ", то есть заказ как таковой ещё не виден в админке, ибо его формально ещё нет--но он попал в обмен, без статуса. прикручу какую-нибудь проверку, посмотрите у себя сами
  3. да. ищем в модели private function setDocumentRequisites, там добавляем что-то типа такого: $requisites['Способ доставки'] = $order['shipping_method']; и всё, способ доставки пишется в реквизиты документа, дальше на стороне 1с делаем с этим что хотим
  4. в журнале кроме ругани на SEO на первый взгляд ничего интересного. можно генерацию SEO отключить, и посмотреть--не в нём ли затык. и я бы попробовал для начала грузить совсем маленькую группу--на несколько товаров, мало ли утыкается в ограничение веб-сервера. или этот же обмен настроить на выгрузку частями, хоть ваших пару тысяч товаров это не так и много, но хостинг тоже всякий бывает.
  5. @mazioka , первым делом логи, изучаем логи.. если учётная система не получает succes, значит где-то что-то произошло с ошибкой. что именно--надо искать в журнале ошибок. модуль обмена обучен записывать туда почти каждый чих. найдёте где появляется ошибка--можно подумать из-за чего она и как починить.
  6. задумался о обмене заказов с их статусами (для реализаци отложеной оплаты задумка). пока оставим в стороне программную реализацию, это дело техники. как оно вообще должно работать? если у меня, например, стоит "Статус для выгрузки: ожидание" и "Статус выгруженных: в обработке", то понятно--обмен выберет заказы в статусе "ожидание", созданые позже последнего обмена, и при обмене присвоит им статус "в обработке". ещё не вникал в код, возможно и сам найду ответ -- что происходит при настройках статусов в положении "не использовать"? с оглядкой на дату выгрузки и изменения будут обработаны все заказы, а вот со статусом выгруженых что произойдёт? так понимаю, что новый статус им будет сообщён учётной системой как значение реквизита, и если одноимённые статусы присутствуют в настройках сайта, то они будут присвоены, или нужно где-то указать соответствие статуса на сайте и статуса из файла обмена из учётной системы?
  7. столкнулся с непонятным, подозреваю что где-то ограничения сервера кровь портят. дано: ocstore2.3.0.2.3, модуль 1.6.4.7 с изменениями(впрочем даже на чистую cms голый модуль накатывал--то же самое). сервер облачный(то есть сам себе хостер в данном случае). выгружаю товары УТ11 (на удалёнке сервер в организации, админит отдельный человек). товаров где-то так 45 тысяч, картинок грузится тысяч десять. пробовал и архивом по частям, и без архива--всё равно полная выгрузка около часа... проблема в следующем: УТшка пишет дату выгрузки, но не обновляет дату успешной выгрузки. со стороны сайта по отчётам всё норм, даты офферс и импорт обновляются. я так понимаю, где-то сессия рвётся и сайт передаёт succes, а УТшка его уже не слышит... если вслед полному обмену выгрузить обновление цен и остатков--может подтвердить успешную выгрузку, а может и не подтвердить. навскидку--если раз в пять минут запускать обновление, обычно всё успешно (за это время передаются изменения по 50..100 товарам), раз в десять минут--уже скорее всего дата успешной выгрузки не обновится. может, ткнёте носом что проверить и куда нажать, чтоб было правильно?
  8. сам спросил, сам подумал, сам решил. чтобы не отходить от оригинала, в модели поправил метод 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 заполняется тем чем надо. ну а в карточку товара(или куда там захочется) это вывести уже дело техники.
  9. на взгляд дилетанта -- у меня частный случай, который будет не везде применим, но у меня из учётной системы приходит без краткого, а числовой код единицы корректный. в связи с этим--а зачем мне работать с таблицей unit_to_1c, если проще прямо в таблицу product заносить number_code, а потом уже из таблицы классификатора выбирать нужные поля. ошибаюсь или в моём случае это адекватное решение?
  10. в любом случае есть смысл посмотреть журнал ошибок в режиме отладки. там будет более-менее видно до какого момента import обрабатывается корректно, и на каком шаге вылетает. offers и не обработается, если import не обработался--ему некуда парсить предложения, если товаров в каталоге нет. точнее он-то обработается, но мы этого не увидим, только в логе будут сплошные "Товар не найден по Ид 13481320-a159-11e8-88f5-ac1f6b2675fb, предложение пропущено."
  11. возможно, будет интересно или даже полезно, если грабли той же системы: столкнулся с той же бедой прямо вот на днях, причём по времени совпало с моим ковырянием в коде--что доставило попоболи. откатился на бэкап недельной, потом месячной давности--не помогло. вручную из админки грузится, из эски хоть в архиве хоть без--нет. включил отладку, получил в журнале десятка полтора мегабайт текста. попался на глаза вот такой фрагмент: 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 на этом заканчивалась вылетом, файл предложений обрабатывался и не находил в каталоге товаров в виду их отсутствия. после удаления картинки в эске всё заработало. что за файл и почему не смог обработаться ещё не искал.
  12. а вот кстати у меня теперь тоже так(взмахнул напильником, прикрутил к 1.6.4.7 единицы измерения из более старой версии), и в глаза бросилось несоответствие краткого наименования (name) с числовым кодом и полным названием единицы. чудится мне, что всё из-за того, что в offers у меня <БазоваяЕдиница Код="796 " НаименованиеПолное="Штука" МеждународноеСокращение="PCE"> --нет краткого наименования и parseProductUnit берёт дефолтные "штуки" и потом начинается неразбериха. решения пока не придумал--то ли довольствоваться полным названием единицы, то ли из таблицы к полному подтягивать краткое.
  13. присоединюсь к ожиданию ответа. хотелось бы в 1.6.4.7 или последующих версиях увидеть работающие единицы из коробки. в более старых версиях оно же уже "почти было", и оно таки по-хорошему нужно. когда товаров мало, можно нужное поле добавить и ручками поназначать, но если уже у сайта возникла необходимость импортировать товары сотнями и тысячами из учётной системы, в рукопашную уже ничего не сделаешь.
  14. Ну не настолько оно мне надо, чтобы прямо уж персонально дорабатывать))) Соблазнительно прямо на сайте справочно видеть где и сколько единиц, но в точку самовывоза (сейчас их две) всё равно придёт столько сколько нужно--хоть весь товар выбраной позиции со склада на склад довезём, для конечного покупателя это всё будет просто немного больший промежуток времени между заказом и возможностью забрать товары. Вцелом--модуль достаточно просто увязал сайт с нашей УТшкой, за что огромное человеческое спасибище. Что будет дальше, не упрётся ли наш сайт в возможности модуля или самого опенкарта--кто знает. Может, когда-то на битрикс переедем, но сейчас всё устраивает.
  15. А просветите, пожалуйста, кто давно с этим модулем дружит--на ранних скринах, если не ошибаюсь, в версии 1.6.3 для опенкарт2.1 есть раздел работы со складами. насколько оно там работало, есть ли смысл пытаться перенести склады в нынешнюю версию для 2.3?
×

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.