Здравствуйте, Павел.

К сожалению, мы не можем давать гарантии по срокам появления той или иной функциональности в системе.

По поводу SMS-рассылок решение еще не принято. Во-первых, мы пока получили слишком мало обращений пользователей по этому вопросу и не представляем четко, насколько это будет востребовано. Во-вторых, это приведет к необходимости корректировки тарифных планов. Как вы представляете оплату за объем отправленных SMS? Это должен быть какой-то месячный пакет (например, 300 рублей за 100 сообщений), или же оплата за каждое сообщение по факту его отправления?

Да, я думаю, что как опция в интерфейсе продавца - это разумный вариант. 

Здравствуйте, Андрей.

Расскажите, пожалуйста, подробнее, что вы подразумеваете под автоматизацией периодических услуг? Какие именно действия должны автоматизироваться?

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

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

В любом случае, это следствие какой-то глобальной задачи.

Несомненно, ваша просьба не является бредом, потому что она важна для вашей работы. 

"Большая Птица" - это массовый сервис. И в этом она отличается от 1С, конфигурации которой франчайзи дорабатывают под нужды заказчика. К сожалению, в случае массового сервиса такая модель изменений неприменима - мы просто не сможем поддерживать сотни различных версий системы, на каждую из которых, фактически, пришлось бы заводить отдельный проект по части разработки. Да и цена вопроса для кастомизированного сервиса была бы абсолютно другая.

По поводу УПД мы получили большое количество обращений от пользователей, поэтому и включили его в планы.

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

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

С другой стороны, сумму конторских расходов они не знают. Поэтому неопределенность по поводу бонусной части зарплаты будет присутствовать в любом случае, видят они закупочную цену или нет.

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

Здравствуйте.

Проблема лежит несколько глубже, чем просто запретить определенному пользователю доступ к типу цен в конкретном документе. Фактически, это частный случай назначения прав пользователям на разные экземпляры объектов учета (это в первую очередь определенные элементы справочников и документы) системы. Я настроен против такого подхода, так как он порождает огромное количество неочевидных следствий. Но это в глобальном плане.

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

К сожалению, подход "сделаем, авось пригодится" для мобильных приложений применим еще менее, чем для десктопных :) Пока вырисовываются такие кейсы для мобильного использования: торговый представитель (работает с заказами, продажами, взаиморасчетами), розничный интерфейс продавца (по смыслу аналогичен десктопному), складские операции (возможно, оприходование, как вы указываете, и инвентаризация). 

Общая же проблема такая: мобильные устройства по своей природе плохо подходят для работы с большими объемами данных (в системе это отчеты), со сложными формами (документы), с редактированием данных в режиме таблицы (многострочные части).

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

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