Сравнение функционала Меркурия и Супермага : Системы автоматизации торговли

1. Дело не в сообществе, а в том, что клиенты любят многое делать под себя (отчетность)
2. Тут сказать нечего, у меня столь же исторически сложилось предубеждение против Firebird. Точнее, против его использования в больших нагруженных проектах. А в небольших я люблю MySQL.
3. Вот я про распределенную БД. Сильная сторона Супермага - файловый обмен в распределенной структуре. Что я думаю о том, как это сделано - второй вопрос, но он есть и работает. Можно хоть на флешке отвезти при потери связи с какой-то деревней. Тут у вас серьезный минус, которым Супермаг выдавливает 1С и, соответственно, обыгрывает вашу систему.
4. 5. Вот тут, судя по всему, собака порылась в неразвитой аналитике? Поскольку сущности транзакций и документов часто различаются, переносить документы в аналитику нельзя либо без существенных потерь в производительности, либо без остановки пользователей. OLAP можно прикрутить практически к любой БД с открытой структурой. В Супермаге перенос аналитики выполняется одной кнопкой или по расписанию.

Спорить о разнице скриншотов и местах, куда надо попасть мышкой в той или иной программе, можно до хрипоты и в целом это больше религиозные споры с минимальным результатом. Аналогично не раз уже схлестывались тут и с Астором и с кем-то еще по вопросам отражения бизнес-процессов в софте. Сравнивать разное очень трудно. Сказать, что лучше - тем более, поскольку на вкус и цвет. Эргономика тоже вкусоцветовая, но я, например, люблю горячие клавиши, которых в Супермаге нет. Собственно, я бы вообще предпочел консоль :) Это к чему - начните с глубокого, ядра программы, а все остальное, при сильном ядре, навешивается достаточно быстро. Представьте себе юзера, работающего на ужасных каналах данных, старом железе с 1000 кассами и 6 терабайтами данных. Обычно сразу слабые места вылезают.

Я бы сейчас стал делать кроссплатформенную софтину, на волне импортозамещения... Пошла бы, как по маслу, я думаю. Т.е. Linux на рабочих местах и на сервере, втыкаете собственнику, что он теперь от Запада и лицензий на рабочие места не зависит, винду только бухам и все в шоколаде. По базе, не знаю, попробовал бы все же Postgre, ее сейчас сильно поднимут.

Я тоже люблю интерфейс с кнопками. На днях запишу видеоролик, как работают быстрые клавиши и интерфейс в целом.
Перенос аналитики сам по себе ресурсы не загружает. Загружает предварительный её пересчет. Но это можно на другом серваке делать. Механизмы у нас все есть, и по кнопке и по скриптам в управлении задачами.
Единственное, что я пока не хочу делать - распределенку. Очень сложно сделать хорошо, а плохо и так у многих сделано. В совсем удаленной деревне можно вообще без бэка обойтись. Новые цены привозить на флешке, на ней же забирать чеки. А ценники и ревизии - с кассового сервера.
В меркурии очень партионный учет. Он не даст сделать расход, без строгой привязки к партии. И внутренние перемещения, жестко связанные триггерами приходы с расходами. А корректировки в офисе предыдущих дней... Нет. Боюсь, слишком многим придется пожертвовать ради распределенки. Причем именно тем, что приносит строгий порядок.
По поводу таких огромных баз данных... 1000 касс у нас не было, максимум 250. И это за 5 лет 120 гигов данных. А ведь есть механизмы архивации старых периодов... Но опять повторюсь. 120 гигов летает на 24 ядрах, 64 Гигах оперативы и ССД дисках. Из транзакционной базы какая нибудь оборотка по группе товара за год больше 5 минут не строится.
Дизайнер отчетов есть встроенный для гиков. Пишешь sql и на fastreport форма. Все в базе сохраняется, правами пользователя открывается.
Есть Бизнес-Анализ. Пользовательский генератор отчетов. Как в супермаге, но со своими ништяками. Например можно склеить два отчета по каким то полям, добавить формулы и сделать сводную таблицу. Можно результат анализа сохранить в базе, с привязкой к справочникам. Например посчитали какой нибудь коэффициент оборачиваемости и сохранили его как доп. поле в ассортименте. Удобно.
Ссылку дать не могу.

Кто это сказал, что в удаленной деревне можно без бека? Я для примера подразумевал отсутствие связи в принципе, но это не значит, что там одинокая касса стоит, принимать товар как? Насчет того, чем придется пожертвовать, никто не уговаривает, но имейте ввиду, что будете в конце очереди тех, кто хоть как-то сделал распределенку. Что касается того, кто и как летает, то 120 гигов должно летать на 4 ядрах, 16Гб оперативки и обычных винтах, причем, на этом же сервере будет работать что-то еще. В противном случае, ваша романтика будет разбиваться о то железо, которое будут предлагать в той нише, на которую Вы ориентируетесь. Я давно матерюсь на нищебродов, но все равно вместо серверов ставят хз что.

Транзакционка то летает. Аналитике нужна мощность.

Нужна, транзакционка в 100 человек на том, что я сказал, может и не полететь. А давать будут барахло, а не железо, привыкайте к реалиям :(
А на том, что сказали, только уж что-то редкое не полетит.

Олег, хотел спросить.
1. Что составляет основной объем базы данных в Супермаге? Я правильно думаю, что это чеки?
2. Если чеки, то они запоминаются в одной огромной таблице?
3. Партии двигаются чеками или предусмотрены какие-то сводные документы?

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

Да, и мне интересно. В меркурии партии двигаются сводными документами на основе чеков. А чеки в двух огромных таблицах. Заголовок и тело чека.

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

Решила ответить на сравнение функционала.
Правда не поняла, почему сравнение начинается с ретро-бонусов.
Это точно не отправная точка в торговой системе.

Ну и еще мне лень делать скриншоты, поэтому я буду просто указывать на документацию к Супермагу. (Саму документацию можно найти в Хранилище Супермаг/Документация/)
Функционал в Супермаге есть, и, по-моему, выглядит также, как вы показали. Том 3. Пункты 8. и 9. Документации.

Спорный функционал. Хотелось бы увидеть нормативную базу на основании которой вы это делаете. Потому как на месте персонала магазина, в котором это используется, я бы отказалась платить недостачу, так как расчетные данные не подтверждаются документами. Да и источников ошибок хватает: программа считает подложки для печенья, подложек в наличии не было, печенье расфасовали в мешочки. В итоге магазин платит недостачу.
Бесплатный (для покупателя) упаковочный материал учитывается в Супермаге двумя способами: регистрация в чеке по нулевой цене и инвентарь. С первым способом всё понятно: строгий количественный учет. Во втором способе идет простое списание на издержки предприятия по мере израсходования материалов.