Немного об автоматизации торговли и текущих тенденциях разработки : Системы автоматизации торговли

Для масштаба небольших магазинов со среднедневным оборотом 100+ время расчета совпадает с вашим. Не думаю что пол-часа для 200 - это много. Менеджер может работать в нескольких окнах (сессиях) одной программы. Запустил и занимается другими делами.

Если мы говорим о Проф-анализе, то помимо того, что сами рабочие базы вполне аналитичны, можно делать и дополнительный подсбор данных, для еще большего ускорения анализа.
Запустить анализ данных хоть в ночь, например за год по всем, выбрав глубину анализа. Как вариант, указывается имя файла, по завершению сбора программа завершает работу автоматически. Если результирующая база большая, она автоматом бьется на файлы по 2 гига.
Указанный "сбор" выкладывается в общий доступ для всех менеджеров. А они уже быстро выводят отчеты в нужном для каждого разрезе. А там все еще быстрее, не на порядок, не в 10 раз, а еще быстрее.
Против получаса сбора данных, как в данном примере, анализ на базе "сбора" занимает чуть больше минуты. То есть в 25 раз быстрее. На разных примера цифры могут отличаться.

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

Не совсем понял про привязку расходов к приходным накладным. Одна продажа может быть с нескольких приходов. Есть еще перемещения между складами/магазинами. Тогда партия сохраняется, но числится уже на другом складе. Как в этом случае при делении по магазинам на отдельные части? У нас центральная база общая...

Вячеслав, давайте обменяемся контактами, если вы не против.
Как я уже писал Андрею, на моем одно-фамильном сайте есть e-mail

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

Тигин Олег, пока Вячеслав просыпается и готовит ответ на Ваш подход последних 2 сообщений позвольте чуть написать?

1. По общим тенденциям продвижения программ в Рунет полезно перечитать тему: https://olegon.ru/showthread.php?t=19409 Где "до кучи" можно будет понять былое "величие" моих систем;

2. Так же полезно прочитать тему: https://olegon.ru/showthread.php?t=11140 Где поначалу пытался помочь "рознице" в её автоматизации, а потом проникся, что ей это не нужно!

3. По Вашим последним сообщениям и "наезда" по подходу к справочнику "товара" с системе "УС Land"... Во первых "в итого" для пользователя имеем идентичный результат, но у меня партия (товар) не имеет жесткой привязки к приходной ТТН и её атрибутам, а в зависимости от задач может быть мельче, чем приход или объединять несколько приходов... Максимальный уровень разбивки "изменение поставщика и цены закупа" у товара (партии). Чем мой подход легче и понятнее для пользователя?

Я не программист, а эникейщик, т.е. решатель любых задач, связанных с ИТ! Вот и прискакала задача по Меркурию, а до кучи всплыли несколько халявщиков, которые пользуют в оптовках "УС Land" ХЗ каких версий, но это их также затрагивает и устроили разборки со мной по телефону. Пока интеграцию через API делать не собираюсь - оптовки будут работать через Web, но в учетке нужно разделить обороты и клиентов по признаку работы с Меркурием, что делается элементарно:

У партии (товара) указывает признак прохождения через Меркурий, а у клиентов, их торговых точек признак подключение площадок, тогда:

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

У Вас и Вячеслава скорее всего это также решается, но через опу:

1. При выписке выбирается товар;
2. По товару выходит список всех приходов (партий);
3. Выбираете партию поступившую через Меркурий

Андрей, если с Меркурием будут работать через web, то зачем в учетной системе заморачиваться с разделением оборотов? В Меркурии только количественный учет. У меня есть пользователи, которые работают с Меркурием через Web уже больше года. Другой вопрос о целесообразности интеграции этой работы в учетную систему. Это убыстрило бы процесс, но я бы скорее всего, как и в случае с Егаис, не стал бы тащить всю эту фигню в основной учетный контур.

И еще такой момент. Работа с Меркурием в основном на аутсорсе, так как могут только "сертифицированные специалисты". То есть это посторонний для фирмы человек, кто его в приходные накладные пустит? Во всяком случае, на данный момент своих сотрудников никто не сертифицировал...

Вячеслав - доброе утро! и напоминаю, что я "эникейщик", в частности мне платят за знание юридической стороны вопросов

1. Есть 3 приказа, определяющие типы продукции. Для "моих" не нужен специалист, а тем более ветврач, а достаточно уполномоченного лица... коим первое время, пока не смогу решать проблемы и обучать юзеров по телефону буду "я";

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

3. Так же будет важно "списание" оборотов на правильные получатели;

4. По api - это тот же ЕГАИС, но с меньшими средствами отладки и постоянно меняющимися, зачастую без информирования структурами команд в запросах... Для меня пока это "перебор"

P.S. В общем гемор... а пока отключаюсь - нужно поменять резину у авто.

Юрист, который подрабатывает эникейщиком и на досуге пописывает программки.

Если у вас все магазины в одной центральной базе, то тогда понятно. Ну тогда вам, наверное, сложнее, чем мне. В том числе и масштабировать сеть. У СМ+ как я понял, также. Но у них оракл. Это еще одна отдельная тема, дискутировать на которую не вижу смысла... Для SQL так наверное логичнее, в одной базе.

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

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

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

Я тоже про ветеринарку заинтересован в информации. У меня РЦ запустилось с охлажденной птицей, требуют интеграции!!!

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

Из предыдущего сообщения я не понял главного. Две записи в расходе делает оператор? Или оператор делает одну запись, а программа сама формирует две записи? Если второе, то получаем классическое проведение документа, которое приводит к проблемам при изменениях задним числом. С чем собственно и боролись, делая расчет движений по партиям на лету.