Форум OlegON > Программы и оборудование для автоматизации торговли > Системы автоматизации торговли

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

28.03.2024 18:25


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

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

Я бы сейчас стал делать кроссплатформенную софтину, на волне импортозамещения... Пошла бы, как по маслу, я думаю. Т.е. Linux на рабочих местах и на сервере, втыкаете собственнику, что он теперь от Запада и лицензий на рабочие места не зависит, винду только бухам и все в шоколаде. По базе, не знаю, попробовал бы все же Postgre, ее сейчас сильно поднимут.
30.03.2015 10:32
alwaysright
 
Я тоже люблю интерфейс с кнопками. На днях запишу видеоролик, как работают быстрые клавиши и интерфейс в целом.
Перенос аналитики сам по себе ресурсы не загружает. Загружает предварительный её пересчет. Но это можно на другом серваке делать. Механизмы у нас все есть, и по кнопке и по скриптам в управлении задачами.
Единственное, что я пока не хочу делать - распределенку. Очень сложно сделать хорошо, а плохо и так у многих сделано. В совсем удаленной деревне можно вообще без бэка обойтись. Новые цены привозить на флешке, на ней же забирать чеки. А ценники и ревизии - с кассового сервера.
В меркурии очень партионный учет. Он не даст сделать расход, без строгой привязки к партии. И внутренние перемещения, жестко связанные триггерами приходы с расходами. А корректировки в офисе предыдущих дней... Нет. Боюсь, слишком многим придется пожертвовать ради распределенки. Причем именно тем, что приносит строгий порядок.
По поводу таких огромных баз данных... 1000 касс у нас не было, максимум 250. И это за 5 лет 120 гигов данных. А ведь есть механизмы архивации старых периодов... Но опять повторюсь. 120 гигов летает на 24 ядрах, 64 Гигах оперативы и ССД дисках. Из транзакционной базы какая нибудь оборотка по группе товара за год больше 5 минут не строится.
Дизайнер отчетов есть встроенный для гиков. Пишешь sql и на fastreport форма. Все в базе сохраняется, правами пользователя открывается.
Есть Бизнес-Анализ. Пользовательский генератор отчетов. Как в супермаге, но со своими ништяками. Например можно склеить два отчета по каким то полям, добавить формулы и сделать сводную таблицу. Можно результат анализа сохранить в базе, с привязкой к справочникам. Например посчитали какой нибудь коэффициент оборачиваемости и сохранили его как доп. поле в ассортименте. Удобно.
Ссылку дать не могу.
30.03.2015 12:17
OlegON
 
Кто это сказал, что в удаленной деревне можно без бека? Я для примера подразумевал отсутствие связи в принципе, но это не значит, что там одинокая касса стоит, принимать товар как? Насчет того, чем придется пожертвовать, никто не уговаривает, но имейте ввиду, что будете в конце очереди тех, кто хоть как-то сделал распределенку. Что касается того, кто и как летает, то 120 гигов должно летать на 4 ядрах, 16Гб оперативки и обычных винтах, причем, на этом же сервере будет работать что-то еще. В противном случае, ваша романтика будет разбиваться о то железо, которое будут предлагать в той нише, на которую Вы ориентируетесь. Я давно матерюсь на нищебродов, но все равно вместо серверов ставят хз что.
30.03.2015 12:20
alwaysright
 
Транзакционка то летает. Аналитике нужна мощность.
30.03.2015 12:25
OlegON
 
Нужна, транзакционка в 100 человек на том, что я сказал, может и не полететь. А давать будут барахло, а не железо, привыкайте к реалиям :(
А на том, что сказали, только уж что-то редкое не полетит.
30.03.2015 13:20
FinSoft
 
Олег, хотел спросить.
1. Что составляет основной объем базы данных в Супермаге? Я правильно думаю, что это чеки?
2. Если чеки, то они запоминаются в одной огромной таблице?
3. Партии двигаются чеками или предусмотрены какие-то сводные документы?

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

После прочтения некоторых постов на этом форуме, у меня возникли смутные подозрения насчет базовых принципов организации базы данных.
Да, и мне интересно. В меркурии партии двигаются сводными документами на основе чеков. А чеки в двух огромных таблицах. Заголовок и тело чека.
30.03.2015 13:31
Mtirt
 
Цитата:
FinSoft Олег, хотел спросить.
1. Что составляет основной объем базы данных в Супермаге? Я правильно думаю, что это чеки?
Нет, чеки обычно не самая большая таблица в Супермаге. Хотя и не маленькая.
Цитата:
FinSoft 2. Если чеки, то они запоминаются в одной огромной таблице?
Таблиц несколько: заголовок чека, товарный состав, скидки, оплата банковской картой, еще что-то...
Цитата:
FinSoft 3. Партии двигаются чеками или предусмотрены какие-то сводные документы?

После прочтения некоторых постов на этом форуме, у меня возникли смутные подозрения насчет базовых принципов организации базы данных.
Партии двигаются документами. На основании всех чеков по магазину за день создаются так называемые "Кассовые документы" (один - для всех продаж, один - для всех возвратов товара и один - для безвозмездной передачи). Они и двигают регистры. В них информация о продаже свернута в разрезе товаров.
30.03.2015 13:52
Mtirt
 
Решила ответить на сравнение функционала.
Правда не поняла, почему сравнение начинается с ретро-бонусов.
Это точно не отправная точка в торговой системе.

Цитата:
alwaysright Здравствуйте. Открываем дискуссию. Сравнивать предлагаю помодульно. Я показываю как реализовано тот или иной бизнес процесс в Меркурии, а кто нибудь мне помогает с СуперМагом.
Для начала возьмем ретробонусы. В меркурии есть специальный журнал расчета ретробонусов.



в нём документы. Каждый документ - расчет ретробонуса.



Для автоматической настройки правил расчета ретробонусов - существует журнал правил.



Правила утверждаются коммерческим директором. Менеджерам остаётся только раз в месяц нажать кнопку "Рассчитать по правилам". Снимаются вопросы сговора категорийных менеджеров с поставщиками.
После того, как бонус расчитан, создается расход "Маркетинговых услуг" на поставщика. И начисляется долг. Бухгалтерия ставит оплату к этому расходу. В финансовом модуле видно, все ли бонусы оплачены.
Ну и еще мне лень делать скриншоты, поэтому я буду просто указывать на документацию к Супермагу. (Саму документацию можно найти в Хранилище Супермаг/Документация/)
Функционал в Супермаге есть, и, по-моему, выглядит также, как вы показали. Том 3. Пункты 8. и 9. Документации.
30.03.2015 14:00
Mtirt
 
Цитата:
alwaysright Второй модуль из свеженьких. Автоматическое списание упаковочных материалов (пакетов, плёнки, и т.д.)
Категорийные менеджеры заводят в системе "Правила Списания Тары". Выглядят они примерно так



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



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

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.