CodeCanyon Active eCommerce POS Manager - Плагин WordPress

Руководство по настройке и использованию CodeCanyon Active eCommerce POS Manager

CodeCanyon Active eCommerce POS Manager стоит рассматривать не как обычный WordPress-плагин, а как POS-надстройку для Active eCommerce CMS. Это важная деталь: официальный источник прямо указывает, что POS Manager не является независимой системой и работает только внутри уже установленной Active eCommerce CMS. Поэтому это руководство построено вокруг реального сценария внедрения: как подготовить магазин на Active eCommerce CMS, установить add-on, открыть POS-доступ для администратора и продавцов, настроить товары, оформить заказ у стойки и проверить, что данные попали в общую систему заказов.

В материале не будет инструкций по покупке, вводу кода лицензии или обходу активации. Здесь разобраны рабочие вопросы, которые возникают уже после получения установочного архива: где включается надстройка, какие ограничения проверить до установки, как подготовить товары для POS, как администратору и продавцу оформлять заказы, как не потерять контроль над остатками и что делать, если в интерфейсе не видны способы оплаты, товары или покупатели.

Отдельно стоит отметить несоответствие входного типа материала и фактов из источников. Задание относит продукт к WordPress, но официальная страница товара, документация и страница разработчика описывают Active eCommerce POS Manager как add-on для Active eCommerce CMS на Laravel. Поэтому в руководстве используются термины Active eCommerce CMS, admin panel, seller panel, addon manager, POS orders и POS products. Так читатель получает честную справочную страницу, а не набор неподтвержденных WordPress-шагов.

Главная цель руководства - помочь безопасно проверить, подходит ли POS Manager вашему магазину. После чтения у вас должна быть ясная схема: что подготовить, какие настройки пройти первыми, как провести тестовую офлайн-продажу, где искать результат, когда подключать продавцов и какие альтернативы смотреть, если нужна именно WooCommerce-касса или отдельная POS-система.

Что решает POS-надстройка внутри Active eCommerce CMS

POS Manager добавляет в Active eCommerce CMS рабочее место для оформления заказов из админ-панели и панели продавца. В обычном интернет-магазине заказ создает покупатель через публичную часть сайта. В POS-сценарии заказ создает сотрудник магазина: он ищет товар, выбирает вариант, добавляет количество, указывает покупателя или данные контакта, задает доставку или бесплатную выдачу, применяет скидку и подтверждает оплату. В результате продажа фиксируется в той же экосистеме, где уже живут товары, покупатели, продавцы, статусы заказов и отчеты.

Практическая ценность такого подхода особенно заметна у магазинов, которые одновременно продают онлайн и в офлайн-точке. Если касса живет отдельно, сотрудникам приходится сверять остатки вручную, переносить заказы, исправлять расхождения и объяснять клиентам, почему товар на сайте был доступен, но фактически уже продан. POS Manager пытается закрыть именно эту проблему: офлайн-заказ создается в Active eCommerce CMS, а не в сторонней таблице или внешней кассовой программе.

Официальная страница товара описывает несколько важных возможностей: создание заказов администратором и продавцом, поиск товаров по названию или штрихкоду, фильтрацию по категориям и брендам, работу с вариантами товара, выбор покупателя, заполнение адреса доставки, бесплатную или платную доставку, скидку, оплату наличными, поддержку COD и ручных платежей, печать и загрузку POS-инвойса, отдельные списки POS Products и POS Orders, а также источники покупателя вроде Walk-in, Facebook и WhatsApp.

Ключевой вывод: POS Manager нужен не для замены всего магазина, а для добавления офлайн-канала продаж в уже работающую Active eCommerce CMS. Если у вас нет этой CMS, если магазин построен на WooCommerce, Shopify, OpenCart или другой системе, надстройка не станет универсальной кассой. В таком случае нужно смотреть решения под вашу платформу, а не пытаться устанавливать add-on в неподходящую среду.

Какие задачи закрывает add-on

В реальной работе POS Manager полезен в нескольких сценариях. Первый - розничная точка при интернет-магазине, где сотрудник продает товар посетителю у стойки и хочет сразу уменьшить остаток в каталоге. Второй - складская продажа или выдача заказа, когда менеджер сам оформляет покупку по телефону, в мессенджере или при личном визите. Третий - маркетплейс на Active eCommerce CMS, где продавцы должны оформлять только свои товары, не получая лишнего доступа к чужим заказам и клиентской базе.

Еще один важный сценарий - смешанные источники заказов. В обновлениях продукта указаны Walk-in, Facebook и WhatsApp как источники покупателей, а также возможность завершить POS-заказ по телефону или электронной почте. Это помогает не превращать каждую продажу из соцсетей или витрины в ручной заказ с неполными данными. Сотрудник фиксирует источник, указывает доступный контакт и получает запись в единой истории заказов.

При этом POS Manager не описан как полноценная складская ERP, система смен кассиров, бухгалтерская платформа или автономный офлайн-терминал. В источниках нет подтверждения, что он работает без подключения к интернету, ведет кассовые смены, поддерживает фискальные регистраторы конкретных стран или умеет синхронизироваться с внешними терминалами оплаты. Такие функции нельзя предполагать. Если они критичны, их нужно проверять отдельно в демо, документации автора или через поддержку до внедрения.

Кому подходит и кому лучше искать другое решение

POS Manager хорошо подходит владельцам и администраторам магазинов на Active eCommerce CMS, которые уже ведут каталог, заказы и продавцов внутри этой системы. Чем больше операций уже связано с CMS, тем полезнее встроенный POS: меньше ручного копирования данных, меньше отдельных таблиц, проще проверять, какой сотрудник или продавец создал заказ и почему изменился остаток.

Надстройка особенно логична для проектов с физической точкой, пунктом самовывоза, шоурумом, складской выдачей, продажами через мессенджеры и небольшим операторским отделом. В таких условиях важно быстро создать заказ, выбрать товар из существующего каталога, не перепутать вариант, указать покупателя и сразу распечатать или скачать счет. Если магазин мультивендорный, дополнительный плюс в том, что продавец оформляет свои товары из seller panel, а администратор сохраняет центральный контроль.

Продукт может не подойти, если вам нужна касса именно для WordPress или WooCommerce. В исходном задании указан тип "Плагин WordPress", но официальные источники этого не подтверждают. Для WooCommerce разумнее смотреть решения, которые прямо подключаются к WooCommerce, используют его товары и заказы, работают через WordPress-админку или отдельное веб-приложение. Также стоит искать другое решение, если требуется сложная розничная логика: несколько физических складов, смены кассиров, возвраты по кассе, фискализация, сертифицированная интеграция с банковскими терминалами, продвинутые отчеты по кассирам или гарантированный автономный режим.

Перед установкой проверьте базовую платформу. Если у вас не Active eCommerce CMS, POS Manager не должен быть первым вариантом для теста, даже если страница товара находится рядом с другими CMS-продуктами.

Как принять решение без лишнего риска

Начните не с установки, а с короткой матрицы требований. Выпишите, откуда у вас приходят офлайн-заказы, кто их оформляет, какие товары продаются у стойки, нужны ли варианты, как фиксируется доставка, какие способы оплаты допустимы, как печатается документ для клиента и кто отвечает за ошибки. После этого сравните требования с тем, что подтверждено официальными источниками. Если большая часть совпадает, можно переходить к тестовой установке на копии сайта. Если половина требований относится к кассовой дисциплине, сменам, налоговым устройствам или интеграции с внешним POS-терминалом, лучше сразу искать специализированную систему.

Не менее важно оценить команду. POS-интерфейс должен быть понятен сотрудникам, которые работают у стойки, а не только разработчику. Если продавец за день оформляет десятки заказов, лишние клики и непонятные поля быстро превращаются в ошибки. Поэтому тестирование нужно проводить не только администратору: дайте продавцу выполнить пробную продажу, найти товар, выбрать вариант, изменить количество, указать покупателя, применить скидку и распечатать документ. По итогам станет ясно, нужна ли дополнительная инструкция для персонала.

Что проверить до установки

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

Первый пункт - версия Active eCommerce CMS. Страница товара и журнал изменений указывают совместимость разных релизов POS Manager с версиями Active eCommerce CMS. Для актуального внедрения нужно сверять именно ту версию CMS, которая стоит на вашем сервере, с версией POS Manager из установочного архива и с changelog товара. Если CMS отстает, сначала проверьте план обновления самой CMS на тестовой копии. Установка add-on поверх старого ядра может привести к отсутствующим пунктам меню, ошибкам маршрутов, проблемам с заказами или несовместимости таблиц.

Второй пункт - резервная копия. POS Manager работает с заказами, покупателями, товарами, остатками и, возможно, платежной информацией. Перед установкой сделайте резервную копию файлов и базы данных, а еще лучше - разверните тестовую копию на отдельном поддомене или закрытом окружении. Это не формальность. Если после установки появятся ошибки в админ-панели или в списке заказов, откат базы данных будет намного безопаснее, чем ручное удаление таблиц и файлов add-on.

Третий пункт - права доступа. Нужно заранее решить, кто будет работать в POS: только администратор, несколько менеджеров или продавцы маркетплейса. В источниках подтверждено, что администратор может создавать заказы по in-house products, а продавец - по своим товарам. В обновлениях также отмечено ограничение видимости покупателей для продавцов. Это не отменяет проверки: зайдите под ролью продавца на тестовой копии и убедитесь, что он не видит лишние данные, не может оформить чужой товар и не получает доступ к административным разделам, которые не нужны для продажи.

Четвертый пункт - каталог. Для POS важны названия, штрихкоды, категории, бренды, варианты и остатки. Если каталог заполнен хаотично, поиск у кассы будет медленным: сотрудник начнет открывать похожие товары, ошибаться с размером или цветом, применять скидку не к тому товару. До запуска POS стоит привести к порядку хотя бы товары, которые действительно продаются офлайн. Самая полезная подготовка - создать короткий список POS-товаров и проверить каждый вариант руками.

Пятый пункт - оплаты и документы. Официальные источники говорят о cash, COD, offline payment, transaction proof, инвойсах и настройке ширины thermal printer. Но доступность конкретного способа оплаты зависит от установленного набора add-ons: в changelog отмечено, что offline payment option показывается только при наличии Offline Payment add-on. Значит, если вы планируете ручные банковские платежи или кастомные способы оплаты, проверьте зависимость заранее.

Короткий чек-лист подготовки

• Проверьте, что сайт работает на Active eCommerce CMS, а не на WordPress, WooCommerce или другой CMS.
• Сверьте версию CMS с совместимостью POS Manager в журнале изменений товара.
• Создайте резервную копию файлов и базы данных до установки add-on.
• Подготовьте тестовый товар с вариантом, остатком, категорией, брендом и понятным названием.
• Подготовьте тестового покупателя и отдельный сценарий Walk-in или заказа по телефону.
• Решите, будет ли POS доступен продавцам, и проверьте seller panel на отдельной учетной записи.
• Проверьте, нужны ли Offline Payment add-on, GST add-on или другие зависимые модули.
• Подготовьте принтер или хотя бы браузерную печать, чтобы проверить POS invoice.

Установка через Addon Manager и первая проверка

Официальная документация описывает установку достаточно коротко: Active eCommerce CMS должна быть уже установлена на сервере, затем администратор входит в админ-панель, открывает Addon Manager, нажимает Install New Addon, выбирает zip-архив add-on и запускает установку. После установки пункт POS Manager должен появиться в боковом меню админ-панели и seller panel. Этого достаточно для базового старта, но для безопасного внедрения одного факта появления меню мало.

После установки не переходите сразу к реальной продаже. Сначала проверьте, что админ-панель открывается без ошибок, список add-ons показывает POS Manager активным, боковое меню не сломалось, а существующие заказы и товары доступны. Затем откройте POS Manager от имени администратора и убедитесь, что поиск товаров возвращает ожидаемый тестовый товар. Если список пустой, проблема может быть не в установке, а в том, что товары не импортированы или не включены для POS.

Следующий шаг - проверка продавца. Создайте или используйте тестовую seller-учетную запись, у которой есть собственный товар. Войдите в seller panel и проверьте, появился ли POS Manager в боковом меню. Продавец должен находить только свои товары. Если он видит чужие товары или покупателей, это повод остановиться и проверить права, настройки продавца, версию CMS и логику обновления, потому что для мультивендорного проекта утечка данных опаснее, чем временно недоступная кнопка.

Если после установки пункт меню не появился, не нужно переустанавливать add-on несколько раз подряд. Сначала очистите кеш приложения и браузера штатными средствами CMS, проверьте, не установлена ли несовместимая версия Active eCommerce CMS, посмотрите журналы ошибок сервера и убедитесь, что zip-архив не был распакован или изменен вручную. Если установка выполнялась на рабочем сайте без тестовой копии, временно отключите add-on только штатным способом, восстановите резервную копию при критической ошибке и обратитесь к автору через поддержку с точным описанием симптома.

Первичная проверка после установки

1. Откройте админ-панель под администратором и убедитесь, что меню POS Manager доступно.
2. Откройте Addon Manager и проверьте, что POS add-on отображается как установленный.
3. Найдите тестовый товар по названию и, если используется штрихкод, проверьте поиск по нему.
4. Добавьте товар в корзину POS, измените количество и выберите вариант, если он есть.
5. Проверьте вход продавца в seller panel и доступность POS только для его товаров.
6. Создайте тестовый заказ с минимальной суммой и понятной пометкой, чтобы потом легко удалить или отменить его.

Хороший тест установки заканчивается не сообщением "установлено", а найденным тестовым заказом в списке POS Orders и понятным изменением остатка по товару.

Карта настроек после установки

Настройка POS Manager начинается с вопроса, какой именно офлайн-процесс вы хотите перенести в CMS. Не стоит включать все возможности сразу. Для первой рабочей версии обычно достаточно подготовить POS-товары, проверить доступ администратора, проверить доступ продавца, настроить допустимые оплаты, уточнить доставку или самовывоз, выставить ширину печати и провести несколько тестовых заказов. Только после этого можно подключать дополнительные источники покупателей и расширять процесс.

В интерфейсе Active eCommerce CMS названия пунктов могут отличаться в зависимости от версии, поэтому в руководстве используются подтвержденные источниками зоны: POS Manager, POS Products, POS Orders, выбор товара, выбор варианта, список товаров справа, shipping information, скидка, Pay With Cash, invoice printing и seller panel. Если у вас в панели названия немного отличаются, ориентируйтесь на смысл, а не на буквальное совпадение каждого слова.

POS Products и импорт товаров

В обновлениях продукта отмечен отдельный раздел POS Products в admin и seller panels, а также полный список товаров и импорт. Это означает, что после установки стоит не просто открыть кассовый экран, а понять, какие товары должны попадать в POS. Для небольшого магазина можно начать со всего офлайн-ассортимента. Для маркетплейса лучше двигаться осторожнее: сначала импортировать несколько товаров продавца, проверить варианты и остатки, затем масштабировать процесс.

Главная ошибка на этом этапе - пытаться использовать POS как чистый поиск по всему каталогу, не подготовив карточки товаров. Для розницы критичны короткие названия, корректные варианты, остатки и штрихкоды. Если у товара есть размер или цвет, сотрудник должен видеть вариант до подтверждения заказа. Если варианты похожи, добавьте в название или атрибуты достаточно отличий. Если товар продается и онлайн, и офлайн, проверьте, что остаток меняется после POS-заказа так, как ожидает склад.

Роли администратора и продавца

Разделение ролей - одна из самых важных частей настройки. Администратор может оформлять in-house products, продавец - свои товары. Если на сайте работает несколько продавцов, POS не должен превращаться в общий список чужих товаров и клиентов. В обновлениях также указано, что sellers restricted to viewing only their own customers, а при совпадении телефона или email адрес покупателя может подгружаться автоматически. Это удобно, но требует аккуратной проверки приватности.

Сделайте тест с двумя продавцами. У каждого должен быть отдельный товар и отдельный покупатель. Войдите под первым продавцом, попробуйте найти товар второго, затем попробуйте найти покупателя второго по имени, телефону и email. Если система подгружает данные только при совпадении контакта в рамках бизнес-логики, зафиксируйте это в инструкции для персонала. Если продавец видит лишнее без явной причины, не запускайте POS до выяснения настройки.

Доставка, скидка и статус оплаты

Официальная страница указывает, что сотрудник может выбрать free shipping или paid shipping, добавить discount и подтвердить заказ. Также отдельно сказано, что все orders from POS Manager будут в paid status. Это удобно для продаж у стойки, где оплата уже получена, но может быть рискованно для заказов из мессенджеров, когда клиент только обещал оплатить переводом. Поэтому договоритесь, какие сценарии можно оформлять как оплаченные, а какие нужно проводить через COD или ручной платеж с подтверждением.

Не используйте POS-заказ как черновик неоплаченной заявки, если бизнес-процесс требует строгого разделения оплаты и бронирования. В таком случае лучше создать отдельную внутреннюю процедуру: либо использовать статус заказа после создания, либо фиксировать источник и комментарий, либо не проводить заказ через POS до фактической оплаты. Смысл POS - быстро закрыть продажу, а не заменить CRM для неопределенных лидов.

Печать и ширина термопринтера

В changelog указана динамическая настройка thermal printer, при которой admin и seller могут выставлять print width, а более поздние обновления улучшают дизайн POS invoice. На практике это значит, что печать нужно тестировать на вашем реальном принтере и браузере. Не все термопринтеры одинаково интерпретируют ширину, поля, масштаб и логотип. Если чек уходит за край бумаги или текст становится мелким, настройте ширину, проверьте масштаб печати в браузере и распечатайте несколько тестов с разным набором товаров.

Для бухгалтерии и клиентской поддержки важно, чтобы печатный документ был читаемым: название магазина, номер заказа, товары, количество, скидка, доставка, способ оплаты и итог должны быть понятны без открытия админ-панели. Если в документе не отображается валюта, проверьте версию POS Manager: в журнале изменений есть исправление, связанное с иконкой валюты в invoice.

Работа с товарами, вариантами и поиском у стойки

Кассовый интерфейс ценен только тогда, когда сотрудник быстро находит нужный товар. В официальной документации для admin и seller panel описан поиск по названию или barcode, фильтрация по category, subcategory, sub sub category и brand, а также выбор variation. Это не просто набор удобств. Для магазина с большим каталогом именно поиск и фильтры определяют скорость обслуживания и количество ошибок.

Перед запуском составьте список товаров, которые чаще всего покупают офлайн. Проверьте, как они ищутся по короткому названию, полному названию, штрихкоду и категории. Если сотрудник должен вводить длинные фразы, переименуйте товар или добавьте более понятные элементы в карточку. Если бренд важен для поиска, убедитесь, что он заполнен. Если товар имеет варианты, проверьте, что каждый вариант отличается не только на складе, но и в POS-интерфейсе.

Для товаров с вариантами есть отдельный риск: сотрудник может добавить базовый товар, не выбрав нужный размер или цвет. В документации шаг выбора variation стоит до добавления товара в заказ. Это стоит закрепить в локальной инструкции: сначала товар, затем вариант, затем количество, затем корзина. Если процесс нарушается, остатки по вариантам могут расходиться с фактической продажей. Особенно это важно для одежды, обуви, техники с комплектациями и любых товаров, где SKU различаются внутри одной карточки.

Как подготовить каталог для POS

Начните с короткой ревизии карточек. Для каждого офлайн-товара проверьте название, категорию, бренд, остаток, цену, варианты и штрихкод. Если товар продается в нескольких единицах измерения или упаковках, проверьте, как это отражено в CMS. Если продукт часто продается с ручной скидкой, заранее решите, кто имеет право ее применять и как она должна подтверждаться. Если товар не должен продаваться у стойки, не добавляйте его в POS Products, даже если он доступен на сайте.

Полезно завести отдельную процедуру "проверка перед сменой". Сотрудник или менеджер открывает POS Products, проверяет наличие популярных товаров, смотрит товары с низким остатком, пробует поиск по нескольким примерам и подтверждает готовность к продажам. Это занимает несколько минут, но предотвращает ситуацию, когда первый клиент у стойки обнаруживает, что нужного SKU нет в POS или он открывается без варианта.

Фильтры и сортировка как инструмент продаж

Страница товара упоминает фильтрацию discounted products, low stock, sorting by total sales и rating-based sorting. Эти возможности полезны не только для навигации. Сотрудник может быстрее найти товар со скидкой, предложить популярный товар, избежать продажи позиции с критически низким остатком или подготовить витрину под текущую кампанию. Но использовать такие фильтры нужно осознанно: low stock может означать "продать последнее" или "не трогать, потому что товар нужен для онлайн-заказа".

Если у вас есть менеджер магазина, закрепите правила. Например, товары с низким остатком продаются офлайн только после проверки на складе; товары со скидкой можно предлагать в первую очередь; товары с высоким рейтингом подходят для допродажи, но только если они есть в наличии. POS-интерфейс дает сигнал, а коммерческое правило должно быть описано внутри команды.

Покупатель, источник заказа и адрес доставки

POS Manager поддерживает несколько типов покупательских сценариев: зарегистрированный клиент, Walk-in customer, покупатель из Facebook или WhatsApp, а также заказ с минимальными контактными данными вроде телефона или email. Для офлайн-продаж это важно, потому что не каждый посетитель готов создавать полноценный аккаунт. Но чем меньше данных вы собираете, тем сложнее потом найти заказ, обработать возврат, подтвердить гарантию или связать продажу с историей покупателя.

Лучший подход - собирать ровно столько данных, сколько нужно для вашего процесса. Для быстрой покупки у стойки может хватить Walk-in и чека. Для доставки нужен адрес и телефон. Для заказа из мессенджера нужен источник, контакт и понятная shipping information. Для постоянного клиента лучше использовать Registered Customer, чтобы история покупок не распалась на разные записи.

В обновлениях продукта отмечено, что данные покупателя могут автоматически подгружаться, если phone number или email совпадает с существующим customer. Это удобно для повторных продаж, но требует дисциплины. Сотрудник должен внимательно проверить, что найден именно тот человек, особенно если в базе есть похожие номера, общие корпоративные email или семейные аккаунты. Ошибка в покупателе может привести к отправке документа или заказа не тому человеку.

Как выбрать источник заказа

Если клиент стоит у стойки и забирает товар сразу, используйте Walk-in или аналогичный источник, если он доступен в вашей версии. Если заказ пришел из WhatsApp или Facebook, фиксируйте источник не ради статистики, а ради последующей проверки: менеджеру будет проще понять, где искать переписку, подтверждение оплаты и адрес. Если клиент уже зарегистрирован, используйте Registered Customer, чтобы заказ попал в его историю.

Не смешивайте источники случайно. Если все продажи отмечать как Walk-in, вы потеряете понимание, какие каналы реально приводят покупателей. Если все продажи оформлять как зарегистрированных клиентов без проверки контакта, база быстро наполнится дублями. Раз в несколько недель проверяйте POS Orders по источникам и смотрите, не превратилась ли классификация в формальность.

Адрес и доставка

Документация по созданию заказа указывает шаг выбора customer и заполнения shipping information в modal. Это значит, что доставка не должна оставаться "потом уточним", если заказ создается в POS. Сотрудник должен заполнить данные до подтверждения, иначе заказ попадет в систему как оплаченный, но операционный отдел будет искать адрес в переписке, звонках или памяти кассира. Для самовывоза можно использовать бесплатную доставку или соответствующий внутренний сценарий, если он есть в вашей конфигурации.

Если доставка платная, заранее решите, как сотрудник выбирает сумму. В старых обновлениях упоминался manual input for shipping cost, а в текущем описании - flat shipping control. Практический смысл один: стоимость доставки должна быть понятной, согласованной с клиентом и отраженной в заказе до оплаты. Если сумма меняется после подтверждения POS-заказа, отчетность и документ для клиента становятся менее надежными.

Оплата, инвойс и статус POS Orders

Официальное описание говорит, что POS-заказы создаются в paid status. Это удобно для оплаты наличными или другого способа, который фактически завершен в момент оформления. Но для магазина с разными каналами продаж важно определить, что именно считается подтвержденной оплатой. Наличные в кассе, COD, банковский перевод с transaction ID, ручной платеж с документом, заказ из мессенджера с обещанием оплатить позже - это разные ситуации.

Если используется Pay With Cash, сотрудник должен подтверждать заказ только после фактического получения денег. Если используется COD, проверьте, как заказ дальше проходит через вашу доставку и статусы. Если используется Offline Payment add-on, заранее настройте manual payment methods в соответствующем модуле и проверьте, появляется ли offline payment option в POS. В changelog POS Manager отдельно указано исправление, чтобы offline payment option показывался только при установленном Offline Payment add-on, поэтому отсутствие этой опции может быть нормальным результатом, а не ошибкой POS.

Инвойс - это не просто красивый документ. Для POS он выполняет роль подтверждения продажи, ориентира для клиента и внутренней проверки. Проверьте, что в документе корректно отображаются товары, варианты, количество, скидка, доставка, итог, валюта и данные магазина. Если в POS используются продавцы, проверьте, видит ли seller только свои документы и может ли печатать их с корректной шириной.

Как настроить печать без лишнего риска

Начинайте с браузерной печати на обычном принтере или PDF. Так проще увидеть структуру документа без риска испортить ленту термопринтера. Затем подключите реальный термопринтер и проверьте несколько ширин. Слишком узкая ширина приведет к переносам строк и мелкому тексту, слишком широкая - к обрезке. Если ваш принтер поддерживает несколько форматов ленты, зафиксируйте выбранный формат в инструкции для сотрудников и не меняйте его без повторного теста.

После печати сравните документ с заказом в админ-панели. Сумма, скидка, доставка и способ оплаты должны совпадать. Если есть различия, не запускайте POS на реальных продажах, пока не поймете, где расхождение: в настройке печати, в округлении, в валюте, в шаблоне invoice или в самой логике заказа.

Практический пример: офлайн-продажа товара с вариантом и скидкой

Ниже пример, который лучше провести на тестовой копии или с тестовым товаром. Он показывает не все возможности POS Manager, а типовой рабочий сценарий, где одновременно проверяются каталог, вариант товара, покупатель, доставка, скидка, оплата, инвойс и список заказов. Такой тест полезнее, чем просто открыть меню и убедиться, что экран загрузился.

Цель

Нужно оформить продажу товара у стойки через POS Manager так, чтобы заказ появился в Active eCommerce CMS, остаток по выбранному варианту изменился, покупатель и источник заказа были понятны, а сотрудник смог распечатать или скачать POS invoice. Для примера представим, что в магазине продается товар с двумя вариантами, клиент пришел лично, но просит доставку по адресу и получает небольшую скидку.

Подготовка

Что должно быть готово до теста

• В Active eCommerce CMS уже установлен POS Manager, а в меню виден POS Manager.
• Есть тестовый товар, включенный в POS Products, с заполненной категорией, брендом, остатком и вариантом.
• Есть тестовый покупатель или включен сценарий Walk-in / phone-only / email-only в вашей версии.
• Проверен допустимый способ оплаты, например Pay With Cash или COD.
• Подготовлен принтер или PDF-печать для проверки invoice.

Шаги

Маршрут оформления заказа

1. Войдите в admin panel и откройте POS Manager.
2. Найдите товар по названию, штрихкоду или фильтру категории.
3. Выберите нужный variation до добавления товара в заказ.
4. Добавьте товар в корзину POS и проверьте правый список заказа.
5. Измените quantity, если клиент берет больше одной единицы.
6. Выберите покупателя или задайте источник Walk-in, Facebook, WhatsApp или зарегистрированного клиента, если такие варианты доступны в вашей версии.
7. Заполните shipping information в modal и выберите free shipping или paid shipping по вашему сценарию.
8. Добавьте discount, если скидка действительно согласована.
9. Нажмите Pay With Cash или другой допустимый способ и подтвердите заказ только после проверки итоговой суммы.
10. Откройте созданный POS order, распечатайте или скачайте invoice и сравните его с данными заказа.

Проверка результата

Где искать следы заказа

После подтверждения откройте POS Orders или общий список заказов, если ваша версия объединяет их с другими заказами. Найдите тестовый заказ по коду, имени покупателя или источнику. Проверьте статус оплаты, состав заказа, способ оплаты, shipping information, скидку и итоговую сумму. Затем вернитесь к карточке товара и проверьте, уменьшился ли остаток по выбранному варианту. Если остаток не изменился или изменился не тот вариант, запускать реальные продажи нельзя.

Дальше войдите под продавцом, если POS будет использоваться в seller panel. Повторите похожий сценарий на товаре продавца. Продавец должен видеть свои товары, оформлять заказ, печатать invoice и не получать доступ к in-house products, чужим товарам и лишним покупателям. Такая проверка обязательна для мультивендорного магазина, потому что ошибка прав может быть незаметна администратору, но критична для продавцов.

Нюанс, который часто пропускают

Если POS-заказ автоматически считается оплаченным, тестовый заказ может попасть в отчеты как реальная продажа. Поэтому используйте отдельный тестовый товар, понятное имя покупателя, минимальную сумму или заранее согласованный способ очистки. В источниках упоминается bulk order deletion для администраторов, но не стоит полагаться только на удаление. Лучше проводить тесты в закрытом окружении или помечать их так, чтобы бухгалтерия и менеджеры не приняли их за реальные продажи.

Как проверять результат после запуска

Запуск POS нельзя считать завершенным после первой успешной продажи. Первые несколько дней нужно смотреть не только на то, проходят ли заказы, но и на качество данных. Хорошая POS-настройка оставляет после себя понятный след: кто оформил заказ, какой источник выбран, какой товар и вариант проданы, почему применена скидка, как указана доставка, какой способ оплаты выбран, что напечатано в документе и как изменился остаток.

Составьте небольшую таблицу внутренних проверок. В начале дня сотрудник проверяет доступность POS, поиск популярных товаров, принтер и способы оплаты. После нескольких продаж менеджер смотрит POS Orders, суммы, источники и остатки. В конце дня ответственное лицо сверяет наличные или ручные платежи с заказами в CMS. Если в команде несколько продавцов, проверяйте заказы по каждому seller, чтобы не смешивать ответственность.

Если проверка не показывает понятную связь "настройка - заказ - остаток - документ", POS еще не готов к работе с реальными клиентами. В таком случае не добавляйте новых продавцов и не расширяйте ассортимент до устранения проблемы.

Частые проблемы и диагностика

У POS-надстройки есть несколько типичных зон риска: установка add-on, совместимость с версией CMS, доступ продавца, импорт товаров, способы оплаты, печать и статусы заказов. Ниже перечислены проблемы, которые логично проверять в первую очередь. Это не замена поддержке автора и не утверждение, что каждая проблема обязательно есть в продукте. Это практическая диагностическая карта для класса решений, которые создают заказы внутри CMS и работают с несколькими ролями.

Меню POS Manager не появилось после установки

Симптом: add-on установлен через Addon Manager, но в боковом меню admin panel или seller panel нет POS Manager. Возможные причины: несовместимая версия Active eCommerce CMS, неполная установка zip-архива, кеш админ-панели, ошибка прав или неактивный add-on. Проверьте версию CMS по changelog, статус add-on в менеджере, журналы ошибок сервера и доступ под администратором. Не удаляйте файлы вручную. Если проблема появилась на рабочем сайте, безопаснее откатиться к резервной копии или отключить add-on штатным способом.

В POS не видны товары

Симптом: кассовый экран открывается, но поиск не находит ожидаемые товары. Возможные причины: товары не добавлены в POS Products, товар принадлежит другому продавцу, у товара нет активного остатка, фильтр категории или бренда выбран слишком узко, сотрудник вошел под seller, который не владеет товаром. Проверьте товар под администратором, затем под продавцом, сбросьте фильтры, проверьте category, brand, barcode и вариант. Исправлять нужно не код, а данные каталога и правила видимости.

Продавец видит лишние товары или клиентов

Симптом: seller panel показывает данные, которые продавец не должен видеть. Возможные причины: неправильная роль, некорректная настройка продавца, старая версия CMS или POS Manager, ошибка в тестовом сценарии, где сотрудник вошел не под той учетной записью. Проверьте на двух независимых продавцах, зафиксируйте скриншоты, сравните версии с changelog и не запускайте мультивендорный POS до исправления. При риске доступа к чужим данным лучше временно отключить seller POS и оставить оформление заказов только администратору.

Offline payment option не отображается

Симптом: сотрудник ожидает ручной платеж, но в POS нет нужного способа оплаты. В changelog указано, что offline payment option показывается только при установленном Offline Payment add-on. Проверьте, установлен ли соответствующий add-on, настроены ли manual payment methods, доступны ли bank payment, check payment или custom payment в вашем сценарии. Если модуль не установлен, отсутствие опции не является ошибкой POS Manager. Если установлен, проверьте активность метода и права доступа.

Инвойс печатается с неправильной шириной

Симптом: чек обрезается, переносы строк делают документ нечитаемым, логотип или итог съезжает. Возможные причины: неверная print width, масштаб браузерной печати, несовместимый формат бумаги, старая версия invoice-шаблона или настройки принтера. Проверьте динамическую ширину thermal printer для admin и seller, распечатайте PDF, затем реальный чек. Если документ нужен для клиента, не запускайте печать в реальной точке, пока не получите читаемый результат на вашем устройстве.

Сумма заказа и остаток не совпадают с ожиданием

Симптом: после POS-продажи сумма, скидка, доставка или остаток выглядят неправильно. Возможные причины: скидка применена на уровне заказа, доставка выбрана как free вместо paid, сотрудник выбрал не тот вариант, товар был добавлен дважды, заказ попал в paid status раньше фактической оплаты. Проверьте правый список заказа перед оплатой, затем POS order details и карточку товара. Если ошибка повторяется, остановите продажи по этому товару и разберите тестовый сценарий на копии сайта.

Безопасная эксплуатация и правила для команды

POS Manager работает с операциями, которые быстро становятся финансовыми фактами: заказ создан, товар списан, документ выдан, покупатель получил подтверждение. Поэтому безопасность здесь не только про сервер, но и про поведение команды. Чем четче описаны права, источники заказов, скидки, доставка, ручные платежи и тестовые операции, тем меньше вероятность, что POS станет источником спорных заказов.

Первое правило - минимальные права. Если продавцу нужен только POS по своим товарам, не выдавайте ему административные разделы. Если сотрудник не принимает ручные платежи, не должен иметь доступ к настройке manual payment methods. Если скидки требуют согласования, закрепите это в инструкции, а не оставляйте на личное усмотрение. POS-интерфейс должен отражать реальный регламент магазина, а не заменять его.

Второе правило - отдельные учетные записи. Не используйте общий логин "касса" для всех сотрудников, если нужно понимать, кто оформил заказ. Общий логин удобен на старте, но мешает расследовать ошибки. Лучше создать отдельные учетные записи, ограничить права и научить сотрудников выходить из панели после смены.

Третье правило - тесты отдельно от реальных продаж. Если нужно проверить новую настройку печати, новый способ оплаты или импорт POS Products, делайте это на тестовой копии или с явно тестовым товаром. Не создавайте "маленькие реальные" заказы ради проверки, если потом их придется удалять из отчетности. В источниках есть bulk order deletion, но удаление не заменяет аккуратную тестовую среду.

Четвертое правило - журнал изменений. POS Manager и Active eCommerce CMS активно обновляются, а совместимость часто привязана к конкретным версиям. Перед обновлением CMS проверьте, поддерживает ли ваша версия POS Manager новую версию ядра. Перед обновлением POS Manager проверьте резервную копию, сделайте тестовый заказ и распечатайте invoice. Не обновляйте рабочую кассу в час пик.

Когда CodeCanyon Active eCommerce POS Manager будет удачным выбором

CodeCanyon Active eCommerce POS Manager будет удачным выбором, если у вас уже работает Active eCommerce CMS, есть физическая точка или офлайн-канал продаж, а заказы нужно фиксировать в той же системе, где живут товары, остатки, покупатели, продавцы и отчеты. Его сильная сторона - нативная связь с Active eCommerce CMS: администратор и продавец могут создавать POS-заказы, выбирать товары и варианты, работать с источниками покупателей, доставкой, скидками, оплатами и инвойсом без переноса данных в отдельную программу.

Продукт стоит тестировать особенно внимательно, если у вас мультивендорный магазин. В этом случае ценность seller panel велика, но цена ошибки прав доступа тоже высока. Проверьте двух продавцов, разные товары, видимость покупателей, POS Orders, печать и отчеты до запуска на реальных продажах. Для одиночного магазина важнее скорость поиска товара, корректность вариантов, печать, paid status и сверка остатков.

Если же вам нужна касса для WordPress, подтвержденный WooCommerce POS, автономный офлайн-режим, фискальные устройства, смены кассиров или полноценная складская ERP, POS Manager не должен быть единственным кандидатом. В таких сценариях лучше сравнить платформенные решения и выбрать инструмент под фактический стек. Самый безопасный подход - проверять не название категории на странице, а реальную совместимость продукта с вашей CMS и вашим процессом продаж.

Перед рабочим запуском проведите тест по этому руководству: установка через Addon Manager, POS Products, seller panel, товар с вариантом, покупатель, источник, доставка, скидка, оплата, invoice и сверка остатка. Если каждый шаг дает ожидаемый результат, надстройку можно постепенно вводить в работу, начиная с ограниченного ассортимента и одного обученного сотрудника.