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

День сурка...

А 200 магазинов (в среднем 2-3 кассы + 2 товароведа, есть и до 5 касс) объединенных в одной системе - это небольшой бизнес?

Плюс 60 производств, кафе и производство при магазинах.

Плюс несколько распределительных складов.

Все на одном файловом сервере!

Объем баз - больше 600 гигов, причем базы DBF оптимальные по структуре.

Одновременно с общими справочниками работает в пике около 900 пользователей (Подразделения в раздельных каталогах).

И в принципе все летает. Магазины некоторые до 8-10 лет реально работают с предыдущего поджатия до следующего, без жалоб на тормоза.

Это пример крупного клиента по количеству подразделений.
Есть другой - по количеству касс - до 15, сеть из 12-ти. С несколькими производствами при магазинах.

Есть и небольшие сети. Есть и одиночные магазины.

От FPD там только работа с базами и индексами, где быстрее его нет, все остальное написано-переписано на низком уровне, чтобы было и удобно и быстро.

Не так давно осознал, что по крайней мере в системах до 1000 пользователей, могу конкурировать с СМ+ или Рарус.

При очень дружественном интерфейсе, быстродействии и разумном ценнике.

Я понимаю, что не я первый это утверждаю. На файрберде - а это опять SQL, столько пользователей не потянешь.

Почитал форум.
Про СМ+ сложилось мнение, что изначальное стремление удовлетворить разных пользователей привело к неоправданному усложнению системы, множеству настроек. И да, за системой надо следить. Без специалиста (-ов) не обойтись.

Узнаю множество решенных вопросов для требовательных бухгалтеров из 90-х. Я с ними тоже тягался. Зачем эмулировать ФИФО-ЛИФО и т.д.

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

Партионный учет, кстати, помог при привязке к ЕГАИС, когда у многих были проблемы множественных привязок.

Тем более - для ветеринарки (пока еще не сделал).

В глубокий диспут вступать не планирую. Просто появилось окно во времени.

На вопросы - отвечу...

P.S. Это как бы уточняющая статья, может кто-то первую статью невнимательно прочитал. Я здесь больше не про программу, а про то, что на якобы "древней" системе FPD, при грамотном подходе, можно добиваться неплохих успехов без всяких сложных цепочек SQL.

Плюс, уточню, мультиплатформенность FPD. Терминал-сервера виндовые используются, так как они удобнее. Можно, и мы работали, на терминалах Linux.

P.S.S. Андрей, вопрос про большой-небольшой конечно риторический. Новых таких же у нас с вами шансов привлечь немного. Интересно, а как у вас. Какие масштабы?

Олег Николаевич, здравствуйте! Вы меня ВО ВСЁМ неверно поняли...

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

- Шутки, если их заметили связаны со скепсисом в вопросе нахождения новых и интересных клиентов, да и вообще по перспективам развития небольшого бизнеса в России, а если таковой существует и развивается, то он давно автоматизирован и в основном на продуктах от ООО "1С-Софт"

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

- В принципе я представляю "деградирующий" проект... На пике своего развития в 2007 году (по количеству пользователей) - это 15-30 оптовок, 3-10 заводов, от 60 магазинов (лень искать точные цифры)... Однако примерно 70% моих доходов и 90% задач давали 5 алкогольных оптовок, а когда начался кризис 2008 и ФСРАР "задушил" эти абсолютно налогово белые фирмы в 2010 мой проект полетел "в пропасть"... Главное: фатально упали доходы, как программиста, появилось много времени на попытки найти новых заказчиков в виртуальном мире, мозги перестали быть в тонусе из-за отсутствия требований сложных задач... Таким образом с 2010 по 2014 год ещё пытался "трепыхаться", а затем "забил"!!!

- Возможно, как более интересный мой пример "деградации" - это проект "УС Лэнд:ЕГАИС"... В принципе, сделал "во время" и вполне могу считать первой работающей программой для ЕГАИС, да и сейчас, но уже с оговорками её можно называть "лидером", что не помещало проекту фактически загнуться... Здесь мне морально гораздо спокойнее - изначально для меня это было "развлечение"...

Сейчас работа в ИТ даёт некоторые (некритичные) доходы и работаю в основном "эникейщиком"... ну и программирую скорее для самоудовлетворения. Реально осталось 2 крупных завода, оптовка, АТП, пара магазинов, а от новых потенциальных заказчиков с 2016 года, в основном отказываюсь...

Андрей, спасибо за ответ. Можете, как к коллеге ко мне тоже по имени...
Я просто как бы оттолкнулся от вашей фразы, чтобы начать разговор. Прекрасно понимаю вашу позицию и согласен с ней. Хотелось и вас в том числе порадовать возможностями FPD. Я сам не ожидал, что он столько тянет...

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

При просмотре прихода ЕГАИС проводится довольно непростая процедура (долго развивалась) сопоставления с соответствующим приходом (он через ТСД оформляется), где видны несоответствия, критичные и некритичные, привязан - не привязан и т.д. Правильность кода и особенно производителя/импортера, который от прихода к приходу зачастую меняется по некоторым позициям из- за филиалов производителя.

Кстати у вас в ветке вычитал, что через запрос по справке "А" можно получить данные по импортеру, которых нет в справочнике 2. Пока я дергаю его из справочника 1-й версии, если получается, который до сих пор веду.
Справку "А" я всегда запрашиваю для свежих приходов, но для получения даты розлива. Так что спасибо... Правда пока еще руки не дошли посмотреть.

Я терминальный режим работы в рознице запустил еще 2003 году на пяти магазинах, сведя раздельные базы в общую систему с сервером в офисе. Кстати, из другого города. Он потом много наоткрывал еще 50+.
Тогда мне клиент говорил: интернет дорогой, не очень быстрый. А вдруг интернет отключат?

Отвечал: кассы независимы от интернета. Магазин стоять не будет. Товароведы подождут. И то, что в будущем интернет будет быстрей, дешевле, надежнее...

Так оно и вышло. Хотя и в те годы они не стояли практически. Несколько раз на несколько часов.

С тех пор все сети обслуживаются удаленно.
Если есть вопросы, подключаюсь к клиенту на терминал, в программе переключаюсь на нужный склад (объект), смотрю и разруливаю ситуацию в режиме реального времени. Особенно актуально стало в последние годы с появлением ЕГАИС, в период отладки изменений.

В общем в этом ничего нового нет, одинэска до восьмерки тоже так работала, но сдыхала на 15-20 бухгалтерах, не знаю, как уж там в торговле? Движок работы с базами был не крут, и не устойчив. Это я опять в сравнение с FPD ударился...

Хочется показать, что на сегодня объективно нет нужды в SQL-сервере на каждом объекте. Но как это реализовать?

И есть ли на рынке такие предложения для вполне серьезных сетей вообще без SQL, кроме как с FPD, например? Интересно было бы узнать...

Сам по себе SQL - система достаточно древняя, созданная во второй трети прошлого века для обмена данными на супер-супер медленном интернете.

Уже полжизни жду чего-то принципиально нового, а его так и нет. Может китайцы или индусы чего-нибудь родят...
А может и у нас уже задел есть (военная тайна!)

Никому похоже это не нужно, продается то, что продается.
А клиенты прилично переплачивают и за сервера, и за серверный софт. А кого кормим? Ораклия и мелкософтию? И иже с ними...

Для начала поясните пожалуйста, что такое FPD? И чем оно лучше LetoDb?

Личные сообщения на данном форуме не приветствуются. Хотя почтовые адреса иногда "разрешают" упоминать, например мой в сообщении: https://olegon.ru/showthread.php?t=23281

Общение всегда приносит пользу... однако она будет больше при общении с оптимистами, например FinSoft (Вячеслав), который довольно успешно и сейчас продвигает свою систему: https://olegon.ru/forumdisplay.php?f=297 ... правда периодически "выпадая" из форумного формата...

Я же лишь могу выделить "грабельки", которые наверное желательно обходить... хотя и это наверное полезно, если верить эссе: https://olegon.ru/showpost.php?p=305531&postcount=81

Не, ребята, я лучше послушаю. Я слишком далек от доса и дбф. А у вас общение так хорошо получается...

Доброе утро Вячеслав!

Давай не отлынивай

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

Я подумал, что вы тоже на FPD пишите.

Finsoft "Клуб Андрея Жукова расширяется?" меня нечаянно сбил меня с толку.

LetoDb: клиент-серверная система. А я работаю на файл-серверной. У каждой свои плюсы и минусы.

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

Извините, Андрей... Но подход к построению системы совершенно разный.

Так, что такое FPD?

Рискну предположить: FoxPro for DOS

Правильный ответ мне так же интересен.