Коли вибраний Поштомат не з’являється в замовленні PrestaShop, простежте той самий ідентифікатор пункту від мапи до зчитування замовлення. Саме відображення назви поруч із кнопкою означає лише те, що інтерфейс отримав вибір. Потрібно ще підтвердити збереження на боці магазину, поведінку після зміни доставки та прив’язку даних до правильного кошика.
Посібник призначений для осіб, які обробляють замовлення та впроваджують доставки InPost. Він допомагає зібрати конкретний матеріал для діагностики. Розділяє проблему мапи, збереження даних та інтеграції checkout; не припускає, що кожна відсутність пункту є наслідком помилки того самого модуля.
1. Збережіть ідентифікатор, а не лише адресу пункту
Вулиця, місто й опис локації допомагають клієнту, але інтеграції потрібен однозначний ідентифікатор. У даних Geowidget для цього слугує поле name; окремо присутні адреса, тип і координати. Структуру цих даних описує офіційна документація PointInterface.
У прикладі використаємо позначення TEST-PUNKT-A. Це навмисно вигаданий ідентифікатор для опису потоку, а не реальний Поштомат. У реальній спробі виберіть доступний пункт на мапі та занотуйте його справжнє позначення. Не вводьте прикладний код у виробничу етикетку.
У зверненні про проблему також запишіть версію PrestaShop, теми, модуля InPost і checkout. Важлива конкретна версія та можливі модифікації. Назва «one page checkout» описує тип процесу, але не вказує на один конкретний інтерфейс інтеграції.
2. Перевірте наступні етапи збереження
Очікуваний потік можна записати просто:
вибір пункту на мапі → отримання даних сторінкою → запит на збереження → збереження в кошику → створення замовлення → зчитування пункту обслуговуванням.
Кожна стрілка означає окрему подію. Документація API Geowidget описує вибір пункту та передавання даних до функції, що обробляє вибір. Далі саме застосунок магазину має правильно використати отриману інформацію.
Картка діагностики: той самий пункт у наступних місцях
Етап
Що перевірити
Що означає розбіжність
Мапа
Чи callback або подія вибору містить ідентифікатор позначеного пункту.
Відсутність даних спрямовує діагностику до віджета, скриптів і його конфігурації.
Вигляд checkout
Чи показана назва відповідає вибраному пункту, також після закриття мапи.
Інший пункт або старий опис вказують на проблему оновлення інтерфейсу.
Запит до магазину
Чи передано ідентифікатор пункту до правильного endpoint у поточній сесії.
Відсутність запиту або даних вимагає перевірки інтеграції JavaScript.
Відповідь і збереження
Чи відповідь означає успіх операції, а пункт збережено в правильному кошику.
HTTP 200 з помилкою застосунку не є правильним збереженням.
Замовлення
Чи зчитування для кошика, з якого створено замовлення, повертає той самий пункт.
Інший кошик або відсутність прив’язки спрямовує діагностику до фінального етапу покупки.
Обробка відправлення
Чи панель і підготовлюване відправлення використовують той самий ідентифікатор.
Правильне збереження з помилковим виглядом вимагає перевірки зчитування або подальшої інтеграції.
3. Чому назви на екрані та HTTP 200 недостатньо
У браузері відкрийте вкладку Network, виберіть пункт і знайдіть запит на збереження. Перевірте відповідь застосунку, а не лише колір рядка. Сервер може коректно доставити документ JSON, у якому міститься інформація про невдале збереження. Статус HTTP стосується транспортної відповіді; її вміст пояснює результат операції.
У вихідних кодах InPost Paczkomaty Pro 2.8.7 дані пункту зберігаються в таблиці модуля, пов’язаній з id_cart. Інформація для замовлення зчитується через його кошик. Тому не слід діагностувати відсутність пункту виключно шляхом пошуку окремої колонки з Поштоматом у головній таблиці замовлень.
У перевіреній обробці Geowidget v5 інтерфейс показує вибраний пункт ще до завершення збереження. Тому під час приймання інтеграції перевірте також відповідь success, значення machine та подальше зчитування. Не вважайте саме розблокування кнопки покупки доказом того, що база прийняла вибір.
Для діагностики можна зберегти анонімізований фрагмент відповіді та час операції. Повні HAR-файли часто містять cookies, адреси й дані форм; не публікуйте їх публічно. Технічна особа має отримати матеріал із видаленими секретами та персональними даними.
4. Повторіть спробу після зміни перевізника й адреси
Потік «я вибрав пункт і одразу купив» — це лише один сценарій. Клієнт може змінити перевізника, повернутися до адреси, увійти в обліковий запис або повторно перерахувати доставку. Кожен такий крок може перебудувати фрагмент сторінки та змінити дані кошика.
У версії 2.8.7 перевірений hook зміни адреси не виконує автоматичного очищення пункту. Обробка зміни перевізника видаляє збереження при явному переході на іншого перевізника поза InPost; проміжне значення нуль не трактується однаково. Це причина перевіряти конкретні переходи, а не припускати, що кожна зміна міста змусить зробити новий вибір.
Демонстраційний сценарій приймання інтеграції — для виконання в копії магазину
Крок
Приклад
Критерій приймання
Вибір пункту
Гість вибирає TEST-PUNKT-A у демонстраційному кошику.
Вигляд, відповідь збереження та пов’язані дані містять той самий ідентифікатор.
Зміна перевізника
Клієнт перемикає доставку на перевізника поза InPost, потім повертається.
Магазин не прив’язує випадково попередній вибір до неправильної доставки; подальший вибір є однозначним.
Зміна адреси
Клієнт змінює місто й знову переглядає варіанти доставки.
Інтерфейс чітко показує актуальний пункт і дозволяє його виправити; ми не припускаємо автоматичного очищення без перевірки.
Телефон
Клієнт відкриває мапу, вибирає пункт і повертається до checkout.
Можна працювати з мапою, зчитати вибір і підтвердити покупку без втрати пункту.
Тестове замовлення
На копії магазину завершуємо процес після підтвердженого збереження.
Обслуговування зчитує справді вибраний пункт із правильного замовлення, без створення виробничого відправлення.
Таблиця визначає очікуваний перебіг спроби. Це не звіт про відправлену посилку й не результат тесту всіх checkout. У реальному прийманні замініть вигадані позначення пунктом із сервісу та запишіть результат кожного кроку.
5. Вкажіть шар для виправлення, перш ніж змінювати модуль
Якщо мапа не передає дані, почніть з її конфігурації та помилок скриптів. Якщо запит на збереження формується, але завершується помилкою, перевірте endpoint, сесію кошика та відповідь сервера. Якщо збереження правильне, а зникає лише під час покупки, зосередьтеся на переході кошик–замовлення та інтеграції фінальної форми.
Якщо панель показує пункт правильно, але інший інструмент доставки його не бачить, перевірте спосіб отримання даних цим інструментом. Не копіюйте вручну випадковий ID до замовлення без підтвердження, який саме пункт вказав клієнт.
При запланованій зміні кошика використайте також контрольний список one page checkout у PrestaShop. Пункт отримання має бути одним із явних критеріїв приймання поряд з оплатами, адресами та мобільними покупками.
Наступний крок: порівняйте вимоги своєї доставки з InPost Paczkomaty Pro. До звернення щодо інтеграції додайте версії, кроки зміни доставки та інформацію, на якому етапі ідентифікатор перестає збігатися.
Перевірено 13.09.2026. Основа: вихідні коди InPost Paczkomaty Pro 2.8.7 та документація Geowidget. Сценарій і позначення є демонстраційними; виробничого відправлення або тесту сумісності кожного checkout не виконувалося.
Модуль InPost Paczkomaty Pro створений для тих, хто хоче надсилати посилки через поштомати, завдяки вбудованій мапі та системі повного вибору списку поштоматів клієнти зможуть легко й швидко вибрати місце отримання посилки з поштоматів InPost.
Патрик Марек — власник PrestaDev.pl і програміст, який спеціалізується на PrestaShop. Уже багато років займається створенням, розвитком і підтримкою інтернет-магазинів. Поєднує роботу над кодом магазину та модулів із налаштуванням серверного середовища, у якому працюють ці рішення.
Проєктує та розвиває модулі PrestaShop, адаптує наявні функції, а також готує інтеграції з оптовими складами та зовнішніми сервісами. Працює над імпортом і оновленням даних про товари, автоматизацією обслуговування каталогу, процесом оформлення замовлення та інструментами, що підтримують щоденну роботу власника магазину.
Його досвід також охоплює оновлення та міграції магазинів, діагностику помилок, аналіз продуктивності, а також налаштування серверів і сервісів, необхідних для роботи PrestaShop. Під час розв’язання проблем враховує залежності між модулями, темою, PHP, базою даних і налаштуваннями хостингу.
У блозі ділиться знаннями, що випливають із багаторічної програмістської практики та роботи з технічним бекендом магазинів. Посібники зосереджені на конкретних проблемах, способах їх перевірки та обмеженнях описаних рішень. Вони допомагають власникам магазинів і технічним спеціалістам підготувати зміни, оцінити їх обсяг і перевірити результат.
Коментарі (0)