Что сейчас:
- Розничный магазин автокрасок.
- 2-3 тысячи позиций товаров.
- 10-15 поставщиков.
- Учёт в эксельке.
Пора вкатиться в автоматизацию, но тревожно. Главный критерий при выборе:
Автоматическое изменение отпускных цен при изменении цен поставщиков. То есть провёл накладную, если цены изменились, мои розничные цены скорректировались с учётом заданной наценки (индвидуальная для каждого товара / группы товаров).
Это прям основное.
Далее опционально:
- Ручное редактирование остатков.
- Интеграция с онлайн-кассой.
- Маркировка.
- Печать ценников.
- Возможность для одной позиции товара указать различные внутренние коды от разных поставщиков.
- Учёт нескольких штрихкодов производителя на один и тот же товар.
- ЭДО.
- Аналитика.
1С, конечно, не хочется. Что-то живое и с нормальной поддержкой.
Всем неравнодушным почтение и бокалы 🎩
1
показ
1.9K
открытий
Sql бд и любой живой фрейворк. Схема бд тут незатейливая. Бд вам за 5-10тр на фрилансе сделают. Интерфейс и бизнес логику еще за 30-40. За интеграцию с кассой и эдо еще надо будет заплатить. Но кассу может проще самому сделать. Аналитика на сводных таблицах или bi сами или за 5тр на фрилансе. Несколько отчетов на sql. Но надо подождать бюджетного программиста. Если денег больше, то ждать меньше. Писал такие программы лет 15. Сейчас интересно только, что нибудь подсказать, если нужно. 1с стандартно, но много лишнего, голова с непривычки вспухнет.
Всегда в таких случаях хочется спросить. ЗАЧЕМ?! Зачем изобретать велосипед (тем более для частного случая), который изначально будет намного паршивее и дороже того, что уже есть и зарекомендовало себя на рынке?
И кто потом этот велосипед будет сопровождать? Это заведомо путь в никуда.
Бизнесу важно быстрее запустить учетный продукт в своем контуре, а не играться в ИТ-компанию.
Никто не предлагал изобретать партионный учет. Он давно изобретен. Я просто обратил внимание, что его схема в sql бд незатейлива.
Из того, что есть на рынке 1c, МойСклад, сбис, мое дело ... автор поста затрудняется выбрать, т.к. нужен большой шаг мозгами, что бы разобраться в этих универсальных решениях сползая со знакомого эксела. Возможно кто то поможет автору сделать этот переход на этих инструментах.
Я в свое время сделал около 200 внедрений своего самопала с партионным учетом в ритейле. Некоторые инсталяции отработали до 10 лет. Поэтому можно найти энтузиаста из действующих фрилансеров или начинающих команд, которые захотят повторить этот трек на современном инструментарии и сделать при удаче новый тиражный сервис.
Я не предлагал магазину становится ит компанией. Я просто обратил внимание на то, что при удачном стечении обстоятельств предлагаемый путь может сработать и предложил посильную помощь в этой попытке.
Просто сейчас я двигаю другой самопал на sql в банке из топа уже 20 лет и поэтому занятся в полную силу в одиночку этим проектом не могу.
С фрилансерами я работаю более 10 лет, поэтому немного понимаю эту культуру.
Сейчас для маленького магазина нужно несколько табличек с примитивными отношениями, потом ему понадобится что-то еще - опять новые таблички, обычно сбоку бантиком. Уже назревает проблема, что при разработке с нуля не понята вся масштабность схемы БД. Думаю вы согласитесь, что 1С на учете во многих отраслях съела собаку, и как минимум схема таблиц (а вернее, предметно-ориентированных сущностей) гораздо продуманнее и с должным уровнем нормализации. Представьте, что после череды итераций разработки хотелок магазина у вас уже ~50-100 табличек. Сравните их поддержку в чистом sql и через 1С. В 1С удобная и понятная абстракция даже неподготовленному пользователю позволяет быстро оценить взаимосвязь основных предметных сущностей или добавить новую сущность (табличку) без каких-либо особых проблем.
Более того, нет зависимости от конкретной СУБД: чтобы сэкономить, отличный вариант использовать PostgreSQL (у 1С есть свой официальный форк).
А когда дело идет не просто про OLTP-систему, а про методологию, отчетность, ЭДО, работу с торговым оборудованием и прочее, то тут просто несоизмеримый отрыв.
Как-раз таки ваш кейс с продвижением самопала, как я понял, примечателен тем (для банка в особенности), что благодаря нему решается конкретная узкая задача, скорее всего связанная с простотой, быстродействием и эффективностью. У меня есть пример из жизни, когда крупнейший застройщик России вместо 1С:Документооборота выбрал какое-то малоизвестное специализарованного решение, максимально приближенное к простым табличкам и нативному sql. Проблема была в скорости загрузки и обработки большого (по сути, BigData) количества операций. Тут соглашусь, есть кейсы, где 1С не применима, но даже в них часто при прямых руках можно достигнуть приемлемой производительности.
Автор поста явно не погружен в мир учетных решений, поэтому вообще бесполезно неподготовленному что-то там вычитывать в интернете, потому что продажники каждого вендора пообещают золотые горы.
Брать надо то, что на слуху, давно зарекомендовало себя и на рынке есть много специалистов, кто может помочь с доработками.
Более того, чтобы со временем в учетном контуре организации не было зоопарка систем, сразу надо подумать, под стек какого вендора придется прогнуться. Уверен, что автор для ведения бухгалтерии и расчета ЗП уже использует (или собирается) решения от 1С. В этом случае выбор еще более очевиден.
Кадры решают все в каждом конкретном случае. 1с на слуху, но там вся мощь sql не используется, поэтому возможны варианты. Проблему с зоопарком сейчас решают инструментами типа zapier или n8n.io и ни под кого не надо прогибаться. Бухгалтерию сейчас решают сервисы и держать буха при магазинчике можно только по инерции. Торгового оборудования тут одна касса. Весы с файфай и приложением мне за 10тр на фрилансе сделали если топиктартер надумает краску разливать по весу. Можно не в эксплорере, а в спец. инструментах со схемой бд работать, в том же еrwin, которому уж лет 30. Методология и отчетность торговли тут известна сотню лет и решается несложными sql запросами. На остальное достаточно часового ролика в ютуб про работу со сводными таблицами. Ну и мозги кадра, что бы всем этим современным инструментарием правильно распорядится.
Что ела ранее 1с и что она вынуждена сейчас поддерживать то отдельная тема. Мы говорим о подходе не обремененным тяжелым наследием.
Учетных кадров, которые хоть как-то знакомы с 1С, на рынке больше всего. Мощь SQL нужна для работы с большими данными, для построения больших специфичных пакетных запросов с оптимальным планом выполнения, но в нашем случае такого явно не требуется. По поводу всех этих отдельных сервисов - да, модно, стильно, молодежно. Сам являюсь большим фанатом таких no(low)-code решений и частенько использую их для быстрой наколенной (!) автоматизации, где важна именно скорость запуска прототипа (MVP). Google App Script - отдельная любовь. Но это все разрозненные облачные сервисы без единой экосистемы, каждый из которых требует своего особого подхода к настройке (ведь это совершенно разные продукты от разных вендоров) и имеет разную сетку тарификации с разными бесплатными квотами. Сейчас уже не редки случаи, когда по тех. причинам отваливается масса казалось бы никак не связанных облачных сервисов. И я бы сильно не хотел, чтобы моя инфраструктура была подвержена таким рискам, и в один прекрасный день все бы встало колом без возможности как-то на это повлиять. Знаю многих владельцев, кто никогда в жизни не отдаст свою бухгалтерию на аутсорс, и уж тем более в облако.
"Весы с файфай и приложением мне за 10тр на фрилансе сделали" - прямо сейчас в прайсе 1С:Розница 8 ПРОФ. Электронная поставка - 13 000 руб., где уже все это есть из коробки (кроме, наверное, особых специфичных железок).
А учитывая, что учет в ближайшее время может масштабироваться, то со всеми этими отдельными сервисами можно со временем поймать знатного геморроя. У 1С, пускай и специфичная, но своя реальная экосистема, где одни и те же знания будут пригождаться постоянно.
Долго еще можно накидывать про "за" и "против". Тут уже задача автора поста понять, что ему кажется ближе и проще.