Till
-
Публикаций
57 -
Зарегистрирован
-
Посещение
Посетители профиля
1 565 просмотров профиля
Достижения Till
-
А це десь у модулі вказано, чи це на стороні НП ліміти? Бо покищо все ж тільки 20 шт трекає. Клієнти забирають посилки, статус замовлень міняється на фінальний - той, який не відслідковується, і тільки тоді починає трекати більш нові замовлення з ТТН.
-
Так, я зрозумів, дякую)) Просто раніше в магазі був один кінцевий статус, який зараз став проміжковим і необхідним для відстежування, тому й виникла необхідність їх зміни. Зіштовхнувся ще з проблемою - це ліміт ТТН на відстежування. Всього 20 штук (визначив по логам). Відслідковується тільки 20 найдавніших ТТН, і доки їх статус не стане кінцевим (той який не відстежується, наприклад "Отримано"), то більш свіжі замовлення з ТТН не оновлюються. На практиці доводиться просто чекати, доки хтось з замовників забере посилку, щоб почали трекатись більш новіші по черзі. Або в деяких випадках зменшувати кількість статусів для відстеження, але це не буде рішенням, якщо в магазі значна кількість замовлень в день, або 20+ активних посилок в кабінеті НП (наприклад. їдуть чи очікують на відділенні).
- 5 446 ответов
-
- 1
-
-
- новая почта
- модуль доставки
- (и ещё 9)
-
Короч, треба обов'язково таке зробити, інакше кожного разу модуль буде стукатись до старих замовлень із статусом, який обраний для відслідковування. Змінити статуси, почистити кеші, запустити задачу cron на оновлення статусів. Все запрацювало, дуже дякую за підказку з логами))
-
Спробуйте збільшити memory_limit (в налаштуваннях PHP хостингу або в файлі php.ini). Не вистачає пам'яті на опрацювання.
-
Доброго дня! Дякую, зробив так. У журналі помилок з'являються записи з табличними даними замовлень: 2025-04-27 6:02:08 - Nova Poshta API tracking orders: 2025-04-27 6:02:08 - Array ( [20450597595576] => Array ( [order_id] => 5974 [invoice_no] => 0 [invoice_prefix] => INV-2020-00 [novaposhta_cn_number] => 20450597595576 ...... і т.д. ... 2025-04-27 6:02:09 - Nova Poshta API response: {"success":true,"data":[{"Number":"20450597595576","StatusCode":"3" ......т.д.... 2025-04-27 6:02:09 - Nova Poshta API documents: 2025-04-27 6:02:09 - Array ( [0] => Array ( [Number] => 20450597595576 [StatusCode] => 3 [DateCreated] => [Status] => Номер не знайдено .......... т.д. ........ Це дуже старі замовлення, у яких модуль не знаходить дані по ТТН (із-за давності). По ходу, модуль почав зрівнювати номери ТТН і статуси замовлень з самого початку, відколи був встановлений. І опрацьовує дані порційно, тому треба ще багатенько часу, доки він дійде до нових (бо зараз номери замовлень від 18700+). Можливо, варто поставити виконання задачі cron на кожні 2-3 хвилини, доки до актуальних замовлень не дійде? Чи массово змінити статуси всім старим замовленням на ті, які не мають відслідковуватись модулем
-
Теж така проблема. Зроблені і прописані налаштування статусів і відповідностей по інструкції, але змін не відбувається. Задача Cron запускається і виконується, також запускав напряму із адмінки модуля. Логи помилок в адмінці сайту і серверу чисті.
-
Модуль Модуль CheckBox пРРО для Opencart [Поддержка]
Till ответил в теме пользователя nazar_kachurak в Модули обмена данными
Дякую. Та договір є, але контроль оплати не підключали. Мені просто менеджер подав інформацію так, ніби я взагалі не зможу приймати наложки, якщо у мене нема НоваПей. Та й є, наче, інфа про те, що зараз контроль оплати можна підключити тільки у тому випадку, якщо заключати договір з НоваПей. Не маю бажання працювати з НоваПей, бо вже є Монобанк. А розділяти кошти по декільком рахункам ФОП це головняк і незручність. До того ж, Монобанк не бере комісій за зарахування післяплат з отримувача коштів)) Більш того, НоваПей дуже "сирий" і навіть зареєструватись там ще той гемор виявився))) -
Модуль Модуль CheckBox пРРО для Opencart [Поддержка]
Till ответил в теме пользователя nazar_kachurak в Модули обмена данными
Вітаю! А хтось чув щось зрозуміле на рахунок того, що Нова Пошта мудрує з наложками, і буде забороняти зарахування на банківську карту (в моєму випадку - ключ-карту рахунку)? І ніби тільки все через НоваПей треба буде робити. Бо звучить як маячня і необрунтоване залякування задля примусового збільшення бази клієнтів свого банку. -
Модуль Модуль CheckBox пРРО для Opencart [Поддержка]
Till ответил в теме пользователя nazar_kachurak в Модули обмена данными
Доброго дня! У мене та ж ситуація. Очистив і оновив все що міг, але результату це не дало. ocStore 3.0.2.0 -
Модуль Модуль CheckBox пРРО для Opencart [Поддержка]
Till ответил в теме пользователя nazar_kachurak в Модули обмена данными
@nazar_kachurak Вітаю! А чи реально зробити функціонал передплати у модулі? Бо вже тривалий час ситуація така, що багато підприємців відправляють наложкою товари тільки по частковій передплаті. Чи можна додати на сторінку чеків /admin/index.php?route=sale/receipt функціонал створення чеків з передоплатою, де суму передоплати вказує продавець і вона, наприклад, зараховується як платіж на рахунок (чи ключ-карту), а решта коштів виписується чеком як накладений платіж при отриманні клієнтом посилки (чи на іншому єтапі, як вже налаштувати модуль НП)? -
Модуль Модуль CheckBox пРРО для Opencart [Поддержка]
Till ответил в теме пользователя nazar_kachurak в Модули обмена данными
Дякую, це я зрозумів)) Та як це в модулі на опенкарт реалізувати?)) Бо наразі функціонал заточений лиш під 1 варіант. -
Модуль Модуль CheckBox пРРО для Opencart [Поддержка]
Till ответил в теме пользователя nazar_kachurak в Модули обмена данными
Вітаю! А я трохи не зрозумів, як бути, коли є декілька варіантів оплат. У мене, наприклад, однієї безготівки 3 варіанти: - На рахунок (або ключ-карту) - Еквайринг Моно - ВейФоПей А також чи можна робити чеки з частковою передплатою в модулі? -
Дякую) Та, на жаль, це для мене занадто складно. Я, по суті, в коді мало що тямлю))
-
Дуже дякую)) Напевно, я ще щось накрутив (або ні), то в мене в цьому плані виходить все ок: ставлю ціну 0.99 (саме з крапкою), і в картці товару і в БД йде значення "1". Якщо вказувати 0,99 (з комою), то дійсно є проблема. Але Опенкарт сам замінює знак коми на крапку по замовчуванню в полі вводу ціни, тобто, проблем наче не має виникнути. А факапи з масовим оновленням товарів з файлу від постачальника, де він (постачальник) використовує у цінах коми для значення "тисячі" й так були))
-
Доброго дня! Ситуація наступна: Зробив округлення акційних цін товарів в адмінці (Адмінка-Каталог-Товари-вкладка Акції) до цілого числа, щоб були без копійок (бо вказуємо знижки у відсотках за допомогою модулів, і воно проставляє копійки). Але в БД записуються значення все одно з копійками. Тому виникають деякі косяки, якщо покупець купує декілька позицій даного товару. Підкажіть, будь ласка, як по-нормальному округляти ціни в БД? Чи нормальним буде зміна типу поля ціни в таблиці БД з decimal на integer? На тестовому магазі наче працює нормально, але на робочому трішки очкую одразу робити ці правки, бо хз чи щось може вилізти. Може щось не врахував. Копійки на сайті відсутні взагалі для користувача, тобто всі ціни та розрахунки вказані цілим числом, валюта одна, без конвертувань.
