Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • Sign Up

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[
  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 тысяч, картинок грузится тысяч десять. пробовал и архивом по частям, и без архива--всё равно полная выгрузка около часа... проблема в следующем: УТшка пишет дату выгрузки, но не обновляет дату успешной выгрузки. со стороны сайта по
  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_nam
  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_2bc0a7101a6011ea9a23ac1f6b26
  12. а вот кстати у меня теперь тоже так(взмахнул напильником, прикрутил к 1.6.4.7 единицы измерения из более старой версии), и в глаза бросилось несоответствие краткого наименования (name) с числовым кодом и полным названием единицы. чудится мне, что всё из-за того, что в offers у меня <БазоваяЕдиница Код="796 " НаименованиеПолное="Штука" МеждународноеСокращение="PCE"> --нет краткого наименования и parseProductUnit берёт дефолтные "штуки" и потом начинается неразбериха. решения пока не придумал--то ли довольствоваться полным названием единицы, то ли из таблицы к полному подтягивать краткое
  13. присоединюсь к ожиданию ответа. хотелось бы в 1.6.4.7 или последующих версиях увидеть работающие единицы из коробки. в более старых версиях оно же уже "почти было", и оно таки по-хорошему нужно. когда товаров мало, можно нужное поле добавить и ручками поназначать, но если уже у сайта возникла необходимость импортировать товары сотнями и тысячами из учётной системы, в рукопашную уже ничего не сделаешь.
  14. Ну не настолько оно мне надо, чтобы прямо уж персонально дорабатывать))) Соблазнительно прямо на сайте справочно видеть где и сколько единиц, но в точку самовывоза (сейчас их две) всё равно придёт столько сколько нужно--хоть весь товар выбраной позиции со склада на склад довезём, для конечного покупателя это всё будет просто немного больший промежуток времени между заказом и возможностью забрать товары. Вцелом--модуль достаточно просто увязал сайт с нашей УТшкой, за что огромное человеческое спасибище. Что будет дальше, не упрётся ли наш сайт в возможности модуля или самого опенкарта--кто
  15. А просветите, пожалуйста, кто давно с этим модулем дружит--на ранних скринах, если не ошибаюсь, в версии 1.6.3 для опенкарт2.1 есть раздел работы со складами. насколько оно там работало, есть ли смысл пытаться перенести склады в нынешнюю версию для 2.3?
×
×
  • Create New...

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.