Да. Второй цех, вторая торговая точка, несколько строительных площадок — объект — это ДАННЫЕ, которые вы описываете на этапе генерации, а не дополнительная редакция ПО, которую нужно покупать. Каждая запись привязана к своему объекту, списки фильтруются, показатели рассчитываются только по тем данным, которые вы определили, и ни одна строка в тарифной сетке не зависит от количества объектов. Перед началом работы важно понимать два ограничения: во-первых, нет ГЛОБАЛЬНОГО переключателя объекта, который бы мгновенно переводил всё приложение в режим одного из них; во-вторых, учётные записи не имеют привязки к конкретному объекту — если пользователь имеет право читать данные, он видит всё. На этой странице объясняется, что работает «из коробки», какую форму данных выбрать в зависимости от ваших объектов и какие функции потребуют доработки.
Ловушка — не цена, а дублирование
Сравнительные обзоры решений в отрасли демонстрируют удивительную согласованность: когда небольшая компания открывает вторую точку продаж без инструмента, заточенного под такие задачи, она просто копирует существующее решение. В результате — два независимых файла, две отдельные системы выставления счётов и никакого общего представления без ручной сводки в конце месяца. К этому добавляется более скрытая проблема: многие продукты заявляют поддержку «многоточечной работы», но на деле не обеспечивают централизованного управления — вы просто добавили ещё одну кассу, но не создали единую сеть.
Поэтому вопрос не в том, «предлагает ли программа опцию многоточечной работы», а в том, «как объект представлен в ваших данных». Это задача МОДЕЛИРОВАНИЯ, и именно здесь приложение, описанное и затем сгенерированное, принципиально отличается от готового решения «с полки»: здесь нет «высшей редакции», которую нужно разблокировать, есть лишь описание, которое нужно правильно задать один раз.
Точка — это данные, а не покупаемая функция ПО
На практике вы описываете его так же, как и всё остальное: «У меня два цеха — Северный и Южный; каждая заявка, каждый товар на складе и каждый клиент относятся к одному из них, и я хочу видеть показатели по цехам». Генератор создаёт соответствующую структуру — сущность или список значений, привязку каждой записи, экраны с фильтрацией. Ничего не угадывается: то, что вы не описали, просто не существует, а то, что описали — генерируется чётко и предсказуемо.
Один момент стоит подчеркнуть особо, поскольку он необычен: ни одна строка в тарифной сетке не зависит от количества объектов. Тарифные планы различаются по числу активных приложений и объёму генерации, но не по количеству точек, цехов или строительных площадок, за которыми следит ваше приложение. Третий объект — это не новый ценовой рубеж, а просто ещё одно значение в списке.
Какую форму выбрать для ваших точек
Существует две формы представления объектов, и они дают разный результат — поэтому лучше выбрать осознанно. Если объектов немного и они стабильны — два цеха, три магазина — объявите их как СПИСОК ЗНАЧЕНИЙ. Это наиболее удобная форма: панель фильтров получает рядом со строкой поиска отдельный селектор объекта, выбранный фильтр сохраняется в адресе страницы — значит, ссылку «заявки с просрочкой в Южном цехе» можно отправить коллеге без изменений — а также группировка по статусу автоматически расширяется возможностью группировки по объекту.
Если у каждого объекта есть полноценная карточка — адрес, ответственный, график работы, контактные данные — тогда это самостоятельные ЗАПИСИ, связанные с остальными данными. Вы получаете полноценную карточку объекта, но теряете мгновенный селектор: панель фильтров добавляет отдельное поле выбора только для списков значений, а остальные поля скрываются в полнотекстовом поиске, который и так их охватывает. И в обоих случаях показатель на дашборде можно привязать к конкретному объекту — клик по нему сразу откроет нужный список, уже отфильтрованный.
Два ограничения, о которых стоит знать до старта
Первое: глобального переключателя объекта нет. Фильтрация реализована в каждом списке отдельно — нет кнопки в верхней части экрана, которая бы переводила всё приложение в «режим Южного цеха» на время сессии. Для небольшой компании, которой как раз нужен общий обзор, это не помеха — скорее, наоборот: это исключает проблему, описанную выше. А вот для пользователя, который весь день работает с одним объектом и не хочет видеть другие, это реальный недостаток — и лучше узнать о нём заранее.
Второе ограничение серьёзнее: учётные записи не привязаны к объектам. Приложение с авторизацией включает полноценное управление пользователями — у каждого свой логин, права на чтение или редактирование. Но эти права распространяются на всё приложение целиком, а не на отдельный объект. Учётная запись с правом чтения видит всё. Если между объектами требуется строгая конфиденциальность, остаётся два пути: добавить в код механизм разграничения доступа — он будет вашим, полностью контролируемым и экспортируемым; или генерировать отдельное приложение для каждого объекта — но тогда вы снова столкнётесь с изначальной проблемой: отсутствием общего обзора. Лучше узнать об этом заранее, чем обнаружить позже.