Впровадження обліку в магазині: 7 типових помилок

Чому автоматизація магазину не запускається: 7 помилок, які найчастіше зупиняють підприємця

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

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

Що зараз ускладнює роботу роздрібної точки

Умови, у яких український ритейл працює у 2026 році, роблять кожну з описаних нижче помилок дорожчою.

Додайте до цього постійні втрати торгової точки. За оцінками дослідження Global Sources of Shrinkage, на які посилається Асоціація ритейлерів України, світовий ритейл втрачає близько 1,5 відсотка обороту через адміністративні помилки, крадіжки персоналу, списання та зовнішні крадіжки. У продуктовому сегменті показник вищий. Коли облік ведеться в таблицях і зошитах, ці втрати не видно до інвентаризації.

Проблема 1. Стартують без демоверсії та на неперевірених даних

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

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

Що зробити

1. Пройти демоверсію на 30 днів і протестувати на ній саме свої сценарії: прихід, продаж, повернення, переміщення між точками.
2. Перед імпортом очистити таблиці Excel: прибрати дублікати, звести назви до єдиного стандарту, перевірити артикули та штрихкоди.
3. Ділити файли імпорту на частини приблизно по 500 позицій, щоб контролювати зіставлення полів і характеристик.
4. Освоювати програму етапами: спочатку дерево видів товару й довідники, потім оприбуткування та інвентаризація для введення реальних залишків, і лише після впевненої роботи в режимах продажу й повернення — складні схеми, знижки та аналітика.

Проблема 2. Від складської програми чекають бухгалтерського обліку

Торгсофт побудований на прибутково-видатковій логіці реального торговельного підприємства. У ньому немає бухгалтерських проведень і плану рахунків. Спроби вести в ньому суто фінансові проведення без прив’язки до товару, облік будівельних об’єктів або розрахунок відсотка усушки овочів на складі зберігання створюють конфлікт методології й розчарування власника.

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

Проблема 3. Онлайн-канали підключають без підготовки каталогу

Очікування, що синхронізація з сайтом або маркетплейсом запрацює сама, коштує втрачених замовлень. Типові причини збоїв: у товарів відсутні обов’язкові для маркетплейсу динамічні характеристики; у програмі не налаштовані розділи синхронізації та товарні групи; на FTP-сервері сайту накопичився надмірний масив невикористовуваних файлів, який блокує обмін.

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

Що зробити

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

Проблема 4. Автоматизацію починають із програми, а обладнання й живлення лишають без уваги

Типовий сценарій зриву виглядає так. Програму встановлюють на сенсорний моноблок із увімкненими автоматичними оновленнями Windows. Через тиждень система йде в цикл перезавантажень. Принтер чеків, принтер етикеток і ваги підключені через дешевий пасивний USB-хаб без зовнішнього живлення, тому періодично втрачають зв’язок. Інтернет-канал на точці нестабільний, і друк із віддаленого сервера через RDP обривається на середині чека.

Окрему групу проблем додають відключення світла. У січні 2026 року частина торговельних мереж у Києві та області зупиняла роботу саме через непрацездатність касових систем, а покупцям радили мати із собою готівку. Магазин без резервного живлення і без здатності продавати офлайн у цей момент просто не торгує.

Що зробити

• На сенсорних моноблоках вимкнути автоматичні оновлення Windows і оновлювати систему вручну в неробочий час.
• Торговельне обладнання підключати через USB-хаби з зовнішнім живленням. Пасивні хаби для принтерів і ваг не підходять.
• Банківський термінал на віддаленому сервері під’єднувати через Wi-Fi. Стандартний COM-порт у такій схемі дає помилки зв’язку.
• Якщо принтер тимчасово зник у сеансі RDP, завершити сеанс підключення до сервера й зайти повторно.
• Забезпечити сервер і касовий вузол джерелом безперебійного живлення, а точку — резервним каналом інтернету.

Проблема 5. У продавців більше прав, ніж потрібно для продажу

Через надлишкові права дані обліку перестають відповідати дійсності швидше, ніж через технічні збої. Якщо продавцю доступна зміна гуртових і роздрібних цін, дані про прибуток перестають відповідати дійсності. Без контролю з’являються фіктивні повернення під чужими обліковими записами з вилученням готівки з каси. Ще одна поширена схема — ручне введення номера дисконтної картки з клавіатури: продаж проводиться сторонній особі, а знижка залишається в касира.

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

Що зробити

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

Проблема 6. Службові операції виконують у робочий час

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

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

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

Що зробити

1. Закріпити письмове правило: закриття періодів і створення контрольних точок виконуються лише в неробочий час.
2. Призначити відповідального за службові операції та єдиний день місяця для їх проведення.
3. Заборонити перерахунок кількості товару на складах під обмеженими обліковими записами продавців.

Проблема 7. Базу даних не обслуговують і не архівують

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

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

Що зробити

1. Регулярно виконувати службові операції Відновити та реорганізувати індекси та оновити статистики й Оптимізація бази даних у неробочий час.
2. При великих обсягах даних відключити ресурсомісткі перевірки собівартості в момент продажу.
3. Налаштувати автоматичне створення резервних копій за розкладом із вивантаженням у хмару.
4. Слідкувати за вільним місцем на системному диску та тримати сервер на джерелі безперебійного живлення.

Приклади з українського ритейлу

Найпоказовіші приклади зафіксовані взимку 2026 року. Станом на ранок 13 січня у Києві та області було зачинено близько 17 супермаркетів мережі Novus: у компанії пояснили, що без електропостачання неможлива нормальна робота торговельних залів, холодильного обладнання та касових систем. Паралельно мережі, які заздалегідь інвестували в автономність, торгували далі. Супермаркети холдингу Retail Group та торгові центри Епіцентр працювали на генераторах, а мережа ЕКО Маркет після закриття магазинів переносила товари категорії ультра-фреш до холодильних камер зі стабільним температурним режимом.

Це великі мережі з іншими бюджетами. Принцип масштабується на невеликий магазин без змін: спочатку резервне живлення каси та сервера, потім здатність приймати оплату й фіксувати продаж при обриві зв’язку, і лише потім усе інше. Для одного магазину достатньо трьох речей: джерело безперебійного живлення на касовий вузол, резервний мобільний інтернет і режим офлайн-продажу.

З чого почати, якщо в обліку вже є розбіжності

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

Повний чек-лист перед запуском і після нього

Часті запитання

Висновок

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