Облік в інтернет-магазині з великим каталогом товарів: повний гід

Торгсофт для інтернет-магазину з великим каталогом: сервер, SQL Server, замовлення, ТТН та оплати

Інтернет-магазин із великим каталогом, кількома каналами продажів, телефонними підтвердженнями, ТТН та щоденними реєстрами оплат швидко перетворюється на складний операційний процес. Ця стаття — покроковий план, як налаштувати Торгсофт, сервер і базу даних так, щоб менеджери обробляли замовлення швидко, а власник бачив реальну картину продажів і грошей. Окремо розберемо, що вирішує сервер, що — налаштування, а що потребує звернення до розробників.

Матеріал розрахований на бізнес, який продає через власний сайт, Prom.ua, Rozetka і телефоном, відправляє десятки посилок на день Новою поштою та Укрпоштою й отримує оплати передоплатою та післяплатою. Приклади підійдуть магазинам запчастин, електроніки, аксесуарів, товарів для дому, одягу, косметики та іншим бізнесам із великим асортиментом.

Який результат має дати правильно налаштована система

Мета налаштування — конкретний робочий результат, який можна перевірити. Правильно побудована система обліку для інтернет-торгівлі виглядає так:

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

Якщо хоча б один елемент випадає, з'являється ручна робота: менеджери звіряють залишки, дублюють рахунки, переносять дані в ТТН вручну, шукають оплати в реєстрах. На великих обсягах така робота забирає години щодня.

З чого почати: опишіть свій процес до технічних робіт

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

1. Звідки приходять замовлення: сайт, Prom.ua, Rozetka, телефон, месенджери, офлайн-точка.
2. Скільки замовлень обробляється на день: до 20, 20–70, 70–200, понад 200.
3. Скільки товарів у базі: до 5 тисяч, 5–30 тисяч, 30–100 тисяч, понад 100 тисяч.
4. Скільки людей одночасно працює в програмі.
5. Де фізично розміщена база: робочий комп'ютер, локальний сервер, термінальний сервер, орендований сервер.
6. Які операції повільні: фільтр товарів, форма «Торгівля з випискою рахунка», «Замовлення віддаленого клієнта», синхронізація, звіти.
7. Які дії менеджери виконують вручну, хоча дані для них уже є в замовленні.

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

Схема роботи інтернет-магазину на Торгсофт

Для бізнесу з кількома каналами продажів корисно мислити єдиним ланцюгом, де кожна ланка передає дані наступній.

1. Товарна база

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

2. Синхронізація з каналами продажів

Товари, ціни й залишки передаються на сайт через опцію Синхронізація з інтернет-магазином, на маркетплейси — через Інтеграцію з Prom.ua та Інтеграцію з Rozetka.ua. Коли товар продано офлайн, залишок оновлюється й для онлайн-каналів.

3. Завантаження замовлень

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

4. Підтвердження замовлення

Менеджер телефонує клієнту, уточнює склад замовлення, доставку та оплату. На цьому кроці працівникові потрібні під рукою залишки, ціни, фото товару й історія клієнта. Швидкий набір номера й картку клієнта під час дзвінка дає опція Профіль клієнта та дзвінки Binotel.

5. Рахунок і відвантаження

Після підтвердження менеджер виписує рахунок у режимі «Торгівля з випискою рахунка», створює видаткову накладну, проводить оплату або фіксує післяплату.

6. Доставка

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

7. Оплата

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

8. Контроль

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

Сервер: коли звичайного комп'ютера вже недостатньо

Один комп'ютер підходить для невеликого магазину з одним користувачем і компактним каталогом. Для інтернет-магазину з кількома менеджерами, маркетплейсами, великою базою й активними синхронізаціями варто розглянути окремий сервер або термінальний режим.

Ознаки, що настав час переглянути обладнання:

• у базі десятки тисяч товарів і багаторічна історія документів;
• щодня обробляються десятки або сотні онлайн-замовлень;
• у програмі одночасно працює кілька людей;
• фільтри, звіти й вибірки за період відкриваються десятки секунд;
• база зберігається на HDD-диску;
• операційна система застаріла й не підтримує сумісні версії SQL Server;
• архіви бази створюються нерегулярно або лише вручну.

Орієнтовні технічні параметри

Наведені параметри — практичний орієнтир. Остаточні вимоги залежать від розміру бази, кількості користувачів, каналів продажів і виду діяльності.

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

Для термінального режиму діють окремі вимоги: серверна операційна система Windows Server редакцій Standard або Datacenter, статична IP-адреса, від 8 ГБ оперативної пам'яті плюс орієнтовно 150–300 МБ на кожне підключення користувача.

SQL Server: за що він відповідає

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

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

Перед переходом на іншу версію SQL Server перевірте:

• сумісність операційної системи з потрібною версією SQL Server;
• обсяг оперативної пам'яті на сервері;
• тип диска — SSD;
• наявність повної резервної копії бази;
• доступ адміністратора до сервера;
• план відкату, якщо перенесення доведеться повторити.

Де шукати вузьке місце

Симптом підказує напрямок рішення. Схема нижче — типові пари «симптом і рішення», з яких варто починати діагностику.

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

Обслуговування бази: індекси, статистики, оптимізація

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

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

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

Що підготувати перед перенесенням бази й роботами на сервері

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

Синхронізація з інтернет-магазином: правильна логіка обміну

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

Найчастіші помилки, які створюють ручну роботу:

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

Перед повним запуском зробіть тест на 20–50 товарах: кілька категорій, різні ціни, товари з фото й без, позиція «немає в наявності», замовлення з оплатою і без. Так помилки налаштувань виявляються до того, як вплинуть на весь каталог.

Prom.ua: на що звернути увагу

Для роботи з Prom.ua критичні три речі: каталог, залишки й замовлення.

• Каталог. Перевірте об'єкт синхронізації, перелік полів для вивантаження, товарні групи та відповідність характеристик. Якщо файл імпорту великого каталогу перевищує допустимий маркетплейсом розмір, використовуйте налаштування стискання файлу перед відправкою — так файл поміщається в ліміт.
• Залишки. Коли той самий товар продається офлайн, на сайті й на Prom.ua, ручне оновлення залишків призводить до розбіжностей. Залишки варто передавати через налаштовану синхронізацію, щоб не дублювати роботу вручну.
• Замовлення. Налаштуйте приймання замовлень за розкладом і правило створення рахунку. Перевірте способи оплати: замовлення з різними типами оплати мають потрапляти на правильні рахунки у фінансовому обліку.
• Статуси. Обробка замовлення в програмі змінює його статус на маркетплейсі. Скасування виконуйте через контакти рахунку, щоб статус коректно передався на Prom.ua.

Rozetka: на що звернути увагу

Для Rozetka особливо важливі категорії, характеристики, прайс-лист і статуси замовлень.

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

Режим «Замовлення віддаленого клієнта»: робоче місце менеджера

Саме в цьому режимі менеджер бачить замовлення з сайту та маркетплейсів. Щоб робота йшла швидко, налаштуйте:

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

Для великого потоку замовлень додайте внутрішній регламент: коли передзвонювати клієнту, коли створювати рахунок, коли скасовувати замовлення, що робити з клієнтом, який не відповів. Регламент знімає більшість питань «хто що мав зробити» між змінами менеджерів.

Клієнт змінив замовлення після дзвінка: як не втратити націнку

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

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

• хто має право змінювати рахунок за замовленням;
• за якою ціною додається товар і як враховується націнка каналу;
• хто перевіряє фінальний рахунок перед відвантаженням.

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

Ціна на маркетплейсі й у програмі відрізняється: порядок перевірки

Розбіжність цін має чіткий маршрут перевірки. Пройдіть його по кроках, перш ніж робити висновки.

1. Перевірте ціну товару в картці в Торгсофт.
2. Перевірте націнку й джерело цін в об'єкті синхронізації для цього каналу.
3. Перевірте ціну цієї позиції у вивантаженому файлі або прайс-листі.
4. Перевірте ціну в замовленні в кабінеті маркетплейсу.
5. Перевірте ціну в рахунку в програмі й те, чи редагувався рахунок вручну.
6. Якщо розбіжність повторюється, передайте техпідтримці номер замовлення, назву товару, знімки екрана з кабінету маркетплейсу та з програми й час синхронізації.

Такий набір даних дозволяє за одне звернення відрізнити питання налаштувань від помилки програми.

ТТН: як прибрати зайві ручні дії

Доставка — найчастіше джерело ручної роботи в інтернет-торгівлі. Менеджер не повинен переносити дані клієнта з одного вікна в інше, якщо ці дані вже є в замовленні.

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

Що автоматизується, а що залишається за менеджером

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

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

Оплати: реєстри післяплат без ручного внесення кожної суми

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

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

Ролі користувачів: доступи за процесом

Коли всі працюють під одним користувачем із повними правами, неможливо зрозуміти, хто змінив документ або видалив позицію. Ролі мають відповідати процесу.

Критерії успішного результату: узгодьте їх до початку робіт

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

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

Повний тестовий сценарій

1. Відкрийте список товарів і заміряйте швидкість фільтра.
2. Прийміть тестове замовлення з кожного каналу.
3. Перевірте, чи правильно визначився клієнт.
4. Створіть рахунок.
5. Додайте товар у рахунок вручну й перевірте ціну.
6. Сформуйте ТТН і перевірте дані одержувача.
7. Пов'яжіть оплату з рахунком.
8. Перевірте зміну залишку в усіх каналах.
9. Перегляньте журнал синхронізації на предмет помилок.
10. Створіть архів бази й переконайтеся, що він записався.

Для високого навантаження перевіряйте типовий день цілком: кілька десятків замовлень, кілька менеджерів, одночасна робота з рахунками, ТТН і оплатами.

Послуга, помилка програми чи побажання: як розрізняти

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

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

Як скласти заявку до техпідтримки, щоб її вирішили швидко

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

Така заявка містить масштаб, конкретні форми, вимірювані симптоми й межі роботи. Її можна оцінити, спланувати й перевірити результат.

Що дає предметна діагностика

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

Зони відповідальності: що робить техпідтримка, а що залишається на бізнесі

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

На стороні бізнесу залишаються: справність сервера й мережі, ліцензійна операційна система, якість даних у товарній базі, доступи до кабінетів маркетплейсів, робота API сторонніх сервісів, дисципліна менеджерів і контроль архівів. Автоматизація дає результат тоді, коли техніка, база, налаштування і люди працюють за одним правилом.

Чек-лист перед запуском або переналаштуванням

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

Висновок

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

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