Повернення в PrestaShop: як оформити часткове повернення замовлення?

Часткове повернення в PrestaShop слід обліковувати на рівні конкретних позицій і кількості із замовлення. Спочатку визначте, що саме клієнт повертає і за скільки він фактично це придбав. Потім окремо зафіксуйте звернення, отримання відправлення та повернення коштів. Завдяки цьому повернення одного товару не перетворюється на скасування всього замовлення, а наступний працівник служби підтримки бачить, що вже виконано.

Цей посібник призначений для власників магазинів і команд післяпродажного обслуговування. Він показує процес і демонстраційний розрахунок для кошика з трьома позиціями. Суми та товари є прикладовими; вони не походять із замовлення клієнта.

1. Почніть із замовлення, позиції та кількості

Повідомлення «повертаю горнятко» недостатньо для безпечного обліку. У замовленні можуть бути два горнятка, інший колір тієї самої моделі або товар, придбаний у наборі. У зверненні мають бути вказані номер замовлення, правильна позиція, варіант і кількість одиниць, що повертаються. Працівник, який приймає звернення, також повинен перевірити попередні повернення, що стосуються цієї покупки.

Основою суми є запис історичного замовлення. Поточна ціна в каталозі могла змінитися після покупки, а знижка могла випливати з акції на товар, коду кошика або умов покупки. Використання сьогоднішньої ціни або ігнорування попереднього розрахунку дає хибний результат, навіть якщо сама форма повернення працює правильно.

• Ідентифікуйте клієнта та замовлення у спосіб, прийнятий у магазині; сам публічний номер замовлення не повинен розкривати його дані.
• Вибирайте позицію та варіант із замовлення, замість того щоб переписувати назву з актуальної картки товару.
• Перевірте придбану кількість, раніше повернену та ту, що залишилася до обліку.
• Зафіксуйте дату отримання заяви незалежно від пізнішої дати доставки посилки.

2. Розділіть статус звернення, посилки та коштів

Найчастіші непорозуміння починаються з одного статусу «повернення завершено». Для складу це може означати отримане відправлення, для бухгалтерії — оформлений документ, а для клієнта — кошти на рахунку. Ці події не є тотожними.

Наведена нижче таблиця — це запропонована схема роботи, а не знімок інтерфейсу чи обов’язкові назви статусів модуля.

Отримання товару не повинно автоматично означати повторну доступність для продажу. Спочатку оцініть його стан і визначте складське рішення. Так само документ коригування або запис про відшкодування в панелі сам по собі не є доказом переказу.

3. Приклад: одне горнятко з кошика, на який поширюється знижка

Припустімо, замовлення таке: пляшка за 100 zł, два горнятка по 50 zł і плед за 100 zł. Вартість товарів становить 300 zł. Знижка на кошик — 30 zł і в цьому прикладі вона пропорційно охоплює всі товари. Доставка коштувала 15 zł, тож клієнт заплатив 285 zł. Він повертає одне горнятко.

50 zł мінус 5 zł призначеної знижки дає 45 zł за горнятко, що повертається. Ми не віднімаємо всю знижку 30 zł від однієї одиниці і не повертаємо клієнту ціну до застосування коду. Однак спосіб розподілу знижки потрібно співвіднести з її фактичними умовами: знижка виключно на пляшку не повинна зменшувати вартість горнятка.

Таблиця обчислює товарну частину, а не визначає остаточну суму до повернення. Вартість первинної доставки, вартість зворотного відправлення та можлива етикетка для повернення потребують окремого визначення. У разі часткової відмови від договору не застосовуйте без аналізу автоматичне правило «завжди повертаємо всю доставку» або «ніколи її не повертаємо». Не утримуйте плату за етикетку лише тому, що таке поле існує в системі.

Якщо клієнт пізніше поверне друге горнятко, служба підтримки повинна бачити першу виплату. Контроль залишкової кількості та суми потрібен при наступних зверненнях, а також під час виправлення невдалої операції.

4. Відмова від договору та рекламація

У разі типової інтернет-покупки споживач, як правило, може відмовитися від договору без зазначення причини протягом 14 днів; існують законодавчі винятки. Натомість рекламація через невідповідність товару договору стосується проблеми з товаром і має власні підстави та можливі вимоги. Форма повинна дозволяти розпізнати тип справи, замість того щоб трактувати кожну рекламацію як звичайне повернення покупки. Пояснення: UOKiK — строки відмови і UOKiK — невідповідність товару договору.

UOKiK також розрізняє витрати на доставку замовлення та витрати на повернення товару. У разі відмови, що стосується всього договору, значення має, зокрема, найдешевший звичайний спосіб доставки, запропонований продавцем. Правила для повної відмови не слід бездумно переносити на кожну конфігурацію часткового повернення. Деталі та приклади: UOKiK — витрати при відмові. Налаштування модуля потрібно адаптувати до чинних правил і конкретної ситуації; саме встановлення не забезпечує юридичної відповідності процесу.

5. Як підтвердити фактичне повернення коштів?

Перед виплатою перевірте первинний спосіб оплати, ідентифікатор транзакції, валюту та залишкову можливу суму. Для автоматичної інтеграції потрібна правильна конфігурація відповідного оператора. Сама наявність його назви у списку не означає, що конкретне замовлення можна обробити через API.

Після доручення виплати збережіть ідентифікатор відшкодування та зчитайте його результат. Якщо виникне timeout, не доручайте одразу другу виплату: спочатку перевірте першу операцію на боці оператора. Запит міг надійти, попри відсутність відповіді в панелі. У разі ручного повернення додайте підтвердження виконання, а вже потім позначайте справу відповідно до прийнятого процесу.

Повідомлення «ми доручили повернення» повинно означати надіслане доручення. Повідомлення про завершену виплату повинно випливати з підтвердженого статусу. Не обіцяйте клієнту, що кошти вже на його рахунку, якщо система підтверджує лише прийняття запиту.

6. Де допомагає модуль Zwroty i odstąpienia Pro?

Zwroty i odstąpienia Pro упорядковує звернення, позиції, що повертаються, розрахунок та історію справи. Обсяг, перевірений у коді версії 1.3.29, охоплює обчислення сум для вибраних кількостей, а також урахування знижок, доставки, зборів і залишкової суми замовлення. Модуль має шляхи ручного розрахунку та автоматичні інтеграції, використання яких залежить від конфігурації та первинної оплати.

Описаний приклад є демонстрацією процесу та арифметики. Він не є тестом виплати в кожного оператора і не підтверджує сумісність із будь-якою версією зовнішнього платіжного модуля.

Контрольний список перед закриттям справи

• Збігаються позиція, варіант і кількість отриманих одиниць.
• Розрахунок спирається на замовлення та враховує правильну знижку.
• Доставка та інші розрахунки мають окремо зафіксовану підставу.
• Історія охоплює попередні виплати та ідентифікатор поточної операції.
• Документи, стан складу та повідомлення клієнту відповідають тому, що фактично виконано.

Хочете впорядкувати цей процес у своєму магазині? Подивіться, як обробляється часткове повернення в модулі Zwroty i odstąpienia Pro. Під час вибору конфігурації вкажіть використовуваний спосіб оплати та спосіб обробки зворотних відправлень.

Змістова перевірка: 13 вересня 2026 року. Демонстраційний приклад, без даних клієнтів. Матеріал підготовлено на основі документації UOKiK і коду модуля; він не описує виконану транзакцію повернення.