Уявіть: ваш товар з ПДВ 20% потрапляє в кошик покупця з Польщі, де ставка 23%. Якщо податки рахуються за єдиною українською ставкою, ви втрачаєте конкурентоспроможність або платите зайве. Це часта біль при виході на міжнародні ринки. Ми вирішуємо такі задачі за допомогою штатних механізмів Бітрікс без костилів. За 9 років налаштували податки для 50+ інтернет-магазинів, і в 80% випадків проблема криється в неузгодженості прапорців VAT_INCLUDED та IS_IN_PRICE.
Проблеми, які вирішуємо
Типова ситуація: магазин на Бітрікс виходить на експорт, але податки продовжують рахуватися за єдиною ставкою. Або товари з ПДВ 0% для Польщі потрапляють в кошик з українським ПДВ 20%. Корінь проблем — неправильне налаштування податкових груп і відсутність прив'язки до регіону покупця. Аудит виявляє до 15% товарів з неправильними налаштуваннями. Ми це чинимо.
Як влаштовані податкові групи в Бітрікс
Бітрікс реалізує регіональні ставки через механізм груп платників податків (tax groups). Таблиця b_sale_tax зберігає податкові групи, b_sale_tax_rate — ставки всередині груп з прив'язкою до регіону. Кожна ставка може бути прив'язана до країни, регіону або міста. Детальніше — Документація Бітрікс по податкових ставках.
Структура b_sale_tax_rate: TAX_ID (посилання на групу), COUNTRY_ID, REGION, CITY, RATE, IS_PERCENT (Y/N), IS_IN_PRICE (Y/N — аналог VAT_INCLUDED), ACTIVE.
Приклад створення групи з регіональними ставками
// Створити групу $taxResult = \Bitrix\Sale\Tax::add([ 'NAME' => 'ПДВ', 'ACTIVE' => 'Y', 'LID' => 's1', ]); $taxId = $taxResult->getId(); // Ставка для Білорусі \Bitrix\Sale\TaxRate::add([ 'TAX_ID' => $taxId, 'COUNTRY_ID' => 'BY', 'RATE' => 20, 'IS_PERCENT' => 'Y', 'IS_IN_PRICE' => 'Y', 'ACTIVE' => 'Y', ]); // Ставка для Росії \Bitrix\Sale\TaxRate::add([ 'TAX_ID' => $taxId, 'COUNTRY_ID' => 'RU', 'RATE' => 20, 'IS_PERCENT' => 'Y', 'IS_IN_PRICE' => 'Y', 'ACTIVE' => 'Y', ]); Як податки прив'язуються до замовлення?
Визначення застосовуваної ставки відбувається в момент розрахунку кошика. Бітрікс читає адресу покупця з властивостей замовлення (b_sale_order_props_value) — шукає властивість з типом LOCATION або TEXT з кодом країни/регіону. Прив'язка податкової групи до магазину налаштовується в /bitrix/admin/sale_tax.php. Кожна група може бути активною для конкретного сайту (LID). При розрахунку кошика модуль sale викликає \Bitrix\Sale\Tax::getList() з фільтром по LID і застосовує першу відповідну ставку по країні/регіону з адреси.
Чому важливо узгодити VAT_INCLUDED та IS_IN_PRICE?
Якщо в каталозі ціни з ПДВ (VAT_INCLUDED = Y), а регіональна ставка нижча (наприклад, 0% для експорту), кошик повинен перерахувати ціни. Бітрікс це робить автоматично через механізм податків модуля sale, але тільки якщо IS_IN_PRICE = Y в b_sale_tax_rate та VAT_INCLUDED = Y в b_catalog_product узгоджені.
Розбіжність цих полів — головне джерело невірного ПДВ при регіональних ставках. Перевірочний запит для пошуку неузгоджених товарів:
SELECT cp.IBLOCK_ELEMENT_ID, cp.VAT_INCLUDED, cv.RATE FROM b_catalog_product cp LEFT JOIN b_catalog_vat cv ON cp.VAT_ID = cv.ID WHERE cp.VAT_ID IS NOT NULL AND cp.VAT_INCLUDED != 'Y'; Всі знайдені позиції потрібно привести до єдиного правила перед налаштуванням регіональних ставок. Економія від правильного налаштування становить від 10 000 до 50 000 UAH на місяць.
| Тип товару | VAT_INCLUDED | IS_IN_PRICE ставки | Результат |
|---|---|---|---|
| З ПДВ | Y | Y | Ціна з ПДВ, ставка застосовується |
| З ПДВ | Y | N | ПДВ нараховується зверху — подвійний податок |
| Без ПДВ | N | Y | ПДВ не віднімається — ціна без податку |
Як автоматично визначити регіон покупця?
Проблема: покупець не завжди заповнює адресу до розрахунку кошика. Для автоматичного визначення регіону по IP використовуємо модуль seo — клас \Bitrix\Seo\Ip2Location. Він опитує сервіс геолокації і повертає країну/регіон. Обробник підставляє код країни у властивість замовлення, і податки розраховуються вірно. Автоматичне визначення в 5 разів швидше за ручний вибір зі списку та виключає помилки.
AddEventHandler('sale', 'OnSaleBasketBeforeSaved', function($basket) { $order = $basket->getOrder(); if (!$order) return; $ip = $_SERVER['REMOTE_ADDR']; $location = \Bitrix\Seo\Ip2Location::getLocationByIp($ip); if ($location && $location['COUNTRY_CODE']) { $propertyCollection = $order->getPropertyCollection(); $prop = $propertyCollection->getItemByOrderPropertyCode('COUNTRY'); if ($prop) { $prop->setValue($location['COUNTRY_CODE']); } } }); Типові помилки при налаштуванні регіональних податків
| Помилка | Причина | Рішення |
|---|---|---|
| Податок не перераховується при зміні регіону | Ставка не прив'язана до регіону в b_sale_tax_rate | Додати записи з REGION або CITY |
| Подвійний ПДВ у кошику | VAT_INCLUDED товару та IS_IN_PRICE ставки не співпадають | Синхронізувати прапори через SQL-запит |
| 0% ПДВ для експорту не застосовується | Не створена окрема податкова група для експорту | Створити групу з RATE=0 і прив'язати до країни |
Як ми це робимо: реальний кейс з нашої практики
У нашого клієнта, магазину електроніки, було завдання: продажі в Україні та Польщі. У Польщі ПДВ 23%, але кошик рахував український 20%. Після аудиту з'ясували: податкова група одна, ставка прив'язана тільки до України. Додали ставку для Польщі з RATE=23 і прив'язали до COUNTRY_ID='PL'. Додатково налаштували автоматичне визначення регіону через IP. Результат: податки розраховуються коректно для кожного покупця, економія на переплаті склала до 15 000 UAH на місяць для клієнта.
Процес роботи
- Аналітика — розбираємо поточні податкові налаштування та торгові сценарії.
- Проектування — схема податкових груп та ставок під вашу географію.
- Реалізація — створення груп, налаштування автоматичного визначення регіону, інтеграція з 1С (якщо потрібен обмін через CommerceML).
- Тестування — перевірка розрахунків для кожного регіону в тестовому середовищі.
- Деплой — застосування змін на бойовому сайті, навчання персоналу.
Що входить в послугу
- Аудит поточної податкової конфігурації
- Створення до 10 податкових груп та ставок
- Налаштування автоматичного визначення регіону по IP
- Інтеграція з 1С УТ/ЕРП через CommerceML
- Документація по змінах
- Безкоштовна підтримка 1 місяць після здачі
Оцінка вартості та термінів
Вартість розраховується індивідуально залежно від кількості країн, ставок та складності інтеграції. Орієнтовні терміни — від 2 до 7 робочих днів. Якщо ви хочете позбутися помилок в розрахунку ПДВ — зв'яжіться з нами. Ми проведемо аудит і запропонуємо оптимальне рішення. Отримайте консультацію безкоштовно.