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

У меня "гибче"...

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

1. По умолчанию приоритет у всех партий одинаковый. И списывается с самой "старой" позиции = ФИФО.

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

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

Таких "вкусностей" много в программе. Это все людям реально нужно, не прибамбасы какие-то...

И поэтому, когда я прочитал у Андрея Жукова (История одного внедрения), что в 21 веке от клиента требуют, чтобы он заводил новую карточку товара при смене поставщика или при изменении приходной цены, я в ступор впал...

Андрей, карточка должна быть одна!!! Это же анализ, в том числе. Партии должны быть разными!!!
Карточку можно и нужно разрешать править, это отдельная тема. Цену и поставщика в каждом приходе, да и остальные реквизиты, можно и нужно разрешать править.

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

Если ваша программа позволяет приходовать "неправильно" (на ваш взгляд), то клиент-то в чем виноват. Вот вы его "учил-учил" как правильно, "учил-учил" - ему это надоело, он и пропал... Вы уж извините за прямоту....

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

Олег, то есть фифо у Вас есть, я просто не так понял один из предыдущих постов. Меня больше интересует, что такое "партия" в Вашем случае.

В Купце партия - это строка приходной накладной. Когда выполняется построение аналитических отчетов, распределение расходов по партиям закупки выполняется "на лету" в хронологическом порядке. Можно задать конкретную партию прихода в расходе, но это редкий случай. Соответственно, можно спокойно поменять цену, поставщика и т.п. в приходной накладной в открытом для изменений периоде, отчеты останутся корректными. В закрытых периодах сохраняется сводная информация, которая используется программой автоматически по мере обнаружения. Это один из способов оптимизации производительности.
Расчет распределения по партиям "на лету" требует вычислительных ресурсов, особенно в рознице, где велик процент пересортицы. Например, оборотка по всему ассортименту с расчетом маржи за месяц для сети из 16 продуктовых магазинов составляет примерно 3 минуты.

Если магазинов будет 200, то это уже долго и надо дополнительно оптимизировать. Конечно, время сократится, если поставить нормальный сервер и серверную операционку вместо обычного компьютера "под сервер". Но все равно, некоторые тяжелые отчеты, видимо, придется перенести в автомат на ночное время.

Как у Вас хранится информация и распределение по партиям на физическом уровне, если не секрет?

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

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

У нас каждая касса работает локально. Разрыв сети и интернета на ней не сказывается, за исключением ЕГАИС для алкоголиков, по закону нельзя... Чеки (в виде легких файлов по каждому чеку) улетают "наверх" по запросу "сверху", по защищенному каналу.
В этом тоже "мудрость" стабильности. Касса сама никуда не ломится, и соответственно не подвисает, если что-то не так.
А так как они почти все под Линукс, то стабильность приближается к 100%.

Товароведы - через терминал.
ТСД на приемке - все WiFi, в терминальном режиме. Т.е. приход оформляется сразу в базу. Разрыв связи (если что) ничего не рушит. Потом можно и без ТСД, в крайнем случае, добить...

Учитывая тенденцию внедрения систем типа ЕГАИС алко, ветеринарки, отсутствие интернета проще не закладывать в алгоритмы программы. Я так и решил, еще ровно 15 лет назад. Сейчас вижу только подтверждение своих мыслей.

1. Что толку, что вы забили алкоголь в промежуточную программу, если торговать все равно нельзя без подтверждения в ЕГАИС.
2. Приход практически переведен на ТСД. ТСД терминально смотрит заказ поставщику в основной базе этого магазина. Что-то помимо заказа - не пропустит. Зачем заморочки по загрузке заказов в ТСД, выгрузке из ТСД (это уже и в огород СМ+). Все и так прекрасно работает.
3. Приходная (и зачастую расходная) цена берется из спецификации поставщика (из общей базы опять же напрямую с сервера). Расходная, если изменилась, меняет прайс. Т.е. приход после ТСД готов к использованию - без заморочек.
Кстати, при этом на кассах остается прежний прайс. Пока товаровед не проведет все необходимые операции (ценники, весы). Только по команде товароведа касса получит свежий прайс. Наличие которого (уже лежащего локально на кассе в сторонке), она проверяет перед каждым новым чеком.

Я похоже уже пошел что-то из своих ноу-хау раскрывать, хотя мне кажется, что это все и так очевидно...

У меня за всю историю (терминальную) только один клиент был иногородний, довольно крупный, который не понимал этого, все твердил, что мы типа несовременные, у нас нет SQL-сервера в каждом магазине, а вдруг интернета не будет... В конце концов таки ушел на SQL...
С 1996 года: 7 лет - 4 магазина по-отдельности, с дубляжом в офисе. с 2003-2016, 13 лет работы, базы в офисе, новый терминальный режим работы - вырос до 50+. За 20 лет и супруги устают друг от друга. Не факт, правда, что после развода жизнь становится лучше...
Так он так и не оценил на момент перехода, какой сервис ему предоставлялся терминально ему, в том числе и с нашей стороны. Дальше - скромно промолчу... Когда есть с чем сравнить, я имею ввиду персонал в первую очередь, а не менеджмент, люди "на земле" они же ежедневно вынуждены "кушать" даже микронные неудобства...

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

Одна только проблема, клиент (высший менеджмент) нас практически не видит, все и так работает, за что платить?
Точнее, почему теперь нужно платить больше?
Модуль ЕГАИС должен чего-то стоить или нет?
Разруливание проблем с ЕГАИС должно чего-то стоить дополнительно?

Это в первую очередь та тема, зачем я здесь...
Но я уже понял, что такую тему вслух обсуждать практически неприлично и рискованно...
Я имею ввиду сравнить не только возможности разных программ для мелких и крупных сетей, но и стоимость их владения.
1. Входной билет разнесенный на 10 лет, например.
2. Пуско-наладка, разнесенная или как то иначе.
3. Стоимость поддержки сверху
4. Стоимость поддержки "на земле"

Ммм... Меня не надо агитировать за терминальный режим работы, я сам его постоянно использую с 2000 года где-то. И я тоже не люблю sql сервера.

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

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

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

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

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

Я так рассуждаю: Порвут провайдера, за час перепротянет..., если это гипер. У меня и такие есть.

Поэтому ваши рассуждения, возможно, отстали от жизни минимум на два года. Без интернета ЕГАИС стоит. Кассы по закону - стоят... Магазины без алкоголя сейчас - нонсенс, я про себя, т.к. занимаюсь в основном продуктовкой...

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

И опять-же, СМ+ гарантирует работу гиперам, ну и пусть гарантирует. На то у него и ценник соответствующий.
Все равно спиртное не продадут без интернета...

А вот средние, тем более мало-форматные магазины, для них такой подход, самое то, они и на завтра оприходование отложат. Магазин ведь не стоит. Товар в зал выносится. Ну денек без изменения цен и без новых позиций поторгуют... Обработку чеков у меня можно отложить хоть на неделю, пока все приходы не забьют...

Я поделился опытом, навязывать что-то намерений не было...

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

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

Кстати, а кто Вам сказал, что без интернета нельзя продать алкоголь? Приглашаю Андрея Жукова, который нам весь мозг здесь егаисом проел, дать разъяснения по этому вопросу.