1. У OpenPapyrus идеология иная — это готовый продукт. Мы понимаем, что многим нравится иметь возможность самостоятельно заточить готовое решение по примеру конфигураций в 1С. Собственно, одна из причин публикации opensource-варианта — дать возможность специалистам почувствовать независимость от оригинальных разработчиков. С другой стороны, такие решения очень сложны, и мы отдаем себе отчет в том, что дорога будет долгой.
2. Скорость работы в многопользовательской среде сильно снижается. В зависимости от того, как пойдет с open-вариантом papyrus'а, мы планируем организовать поддержку других СУБД.
3. Понял. Товарные группы, склады и многие иные объекты иерархические.
Видео-ролики на сайте есть (правда с некоторыми какие-то проблемы были). Иной вопрос, можно ли там увидеть то, что непосредственно требуется. По прямым запросам мы обычно удаленные презентации устраиваем.
Что касается вопроса про реселлера: на первый взгляд OpenPapyrus здесь хорошо подходит: работа с заказами, платежами, расчетом комиссионных и т.д. хорошо отлажена, но наверняка конкретно у вас есть множество собственных нюансов, потому буду осторожен.
Здравствуйте.
1. OpenPapyrus с 1С никак не соотносится. На уровне маркетинга — почти чистая конкуренция с решениями на платформе 1С. Исключение составляют случаи, когда предприятия используют 1с только для бухучета — в этом случае OpenPapyrus обеспечивает хорошие инструменты для экспорта и импорта данных.
2. Движок БД nosql: Pervasive SQL (только низкоуровневый доступ, ранее называвшийся btrieve)
3. Насчет «групп на уровне интерфейса» не понял (я не разбираюсь в 1С).
Для небольшого магазина правильнее всего использовать решение Papyrus Retail
поскольку, имея всю необходимую функциональность, оно включает развитый pos-модуль, что избавляет от необходимости покупать специализированные pos-терминалы, требующие еще и отдельного кассового модуля (фронтол или сет ритейл, например).
Впрочем, это решение и для больших супермаркетов годится, ибо поддерживает практически все типы специализированного оборудования.
Любопытно. У нас аналогичный поиск есть, только чуть меньше функционала:
операторы ||, && («трусы&&incanto», «кукуруза||фасоль»)
и оператор нечеткого поиска! ("! кукуруза" — найдется «кукуруза», «какуруз.», «кукурузн.» и т.д.)
Эта штука уже лет десять в системе, но пользуются очень не многие. Кстати, посмотреть как такая фильтрация работает можно на примере Universe-HTT. Кнопка товары и в поле «Наименование» ввести строку.
И, кстати, как вы воюете с проблемой скорости поиска по сложным текстовым критериям? В большом справочнике (несколько сотен тыс наименований) это — действительно проблема.
А чего обсуждать при вводе десятичного разделителя? Если поле ввода предполагает ввод числа, то за разделитель сойдут и точки и запятая. Мне совсем не понятно зачем некоторые программы ограничивают ввод либо тем либо другим.
По опечаткам. Поле ввода — не последняя инстанция в контроле правильности ввода. Существует проверка при commit'е формы (диалога), далее — при проведении транзакции система не имеет права закладываться на то, что кто-то ей предоставил верные данные — следовательно имеем, как минимум, третий эшелон обороны от некорректного ввода.
Здесь же речь идет только о том, что бы увеличить производительность сотрудников и снизить их утомляемость (раздражение) в узко очерченной области.
Секунду! Ввод single-даты я не рассматривал. Для этого существует отдельный тип поля ввода со своим календарем и своими же правилами. Здесь речь идет только о вводе периода. То есть, никакой такой путаницы нет и быть не может. Если в поле ввода периода пользователь указал 12, то это значит, что он хочет отчет с 12-го числа текущего месяца по 12-е же число текущего месяца. А если при вводе в поле даты (например в задаче) он указал 12, то система воспринимает это как, скажем, due date 12 числа текущего месяца.
Соответственно, поле ввода даты (из примера) будет иметь метку «Дата исполнения», а поле ввода периода, скажем, в фильтре отчета о продажах — «Период».
Собственно по дате — перед написанием статьи посмотрел много разных систем — подавляющее большинство допускают ограниченный ввод. Так чем период то хуже? Более того, транзактивные учетные данные очень часто требуют ввода даты (изложенные консенсус уже сложился), а период обычно вводится при получении отчетов. Так зачем напрягать пользователя больше там, где ответственность меньше?
Согласен, не рассмотрел указанный аспект — а надо было. Дело в том, что во многих случаях порядок следования даты/месяца/года разруливается контекстно. К сожалению, в противоречивых случаях приходится закладываться на какой-то один предпочтительный порядок.
Собственно, мы так и поступаем.
[Я пока не в теме — разбираюсь. Хочу уточнить что бы унифицировать в своей голове подходы к проблеме, используемые разными людьми и компаниями]
Портироваться на linux — да, планируем.
Пока считаем, что лицензия GPL.
2. Скорость работы в многопользовательской среде сильно снижается. В зависимости от того, как пойдет с open-вариантом papyrus'а, мы планируем организовать поддержку других СУБД.
3. Понял. Товарные группы, склады и многие иные объекты иерархические.
Что касается вопроса про реселлера: на первый взгляд OpenPapyrus здесь хорошо подходит: работа с заказами, платежами, расчетом комиссионных и т.д. хорошо отлажена, но наверняка конкретно у вас есть множество собственных нюансов, потому буду осторожен.
1. OpenPapyrus с 1С никак не соотносится. На уровне маркетинга — почти чистая конкуренция с решениями на платформе 1С. Исключение составляют случаи, когда предприятия используют 1с только для бухучета — в этом случае OpenPapyrus обеспечивает хорошие инструменты для экспорта и импорта данных.
2. Движок БД nosql: Pervasive SQL (только низкоуровневый доступ, ранее называвшийся btrieve)
3. Насчет «групп на уровне интерфейса» не понял (я не разбираюсь в 1С).
поскольку, имея всю необходимую функциональность, оно включает развитый pos-модуль, что избавляет от необходимости покупать специализированные pos-терминалы, требующие еще и отдельного кассового модуля (фронтол или сет ритейл, например).
Впрочем, это решение и для больших супермаркетов годится, ибо поддерживает практически все типы специализированного оборудования.
операторы ||, && («трусы&&incanto», «кукуруза||фасоль»)
и оператор нечеткого поиска! ("! кукуруза" — найдется «кукуруза», «какуруз.», «кукурузн.» и т.д.)
Эта штука уже лет десять в системе, но пользуются очень не многие. Кстати, посмотреть как такая фильтрация работает можно на примере Universe-HTT. Кнопка товары и в поле «Наименование» ввести строку.
И, кстати, как вы воюете с проблемой скорости поиска по сложным текстовым критериям? В большом справочнике (несколько сотен тыс наименований) это — действительно проблема.
Здесь же речь идет только о том, что бы увеличить производительность сотрудников и снизить их утомляемость (раздражение) в узко очерченной области.
Соответственно, поле ввода даты (из примера) будет иметь метку «Дата исполнения», а поле ввода периода, скажем, в фильтре отчета о продажах — «Период».
Собственно, мы так и поступаем.