Они сэкономят на дешевых мексиканцах которые ходят и расставляют товар
Давно известно, что расставлять товары нужно по определенным правилам, это существенно влияет на продажи.
Доходит до того, что некоторые серьезно относящиеся к этому делу производители нанимают за свой счет специальных собственных сотрудников (у нас они обычно называются «мерчендайзерами»), которые приходят в магазины, в которые товар этих производителей поставляется, и сами (а не работники магазинов) раскладывают товар по полкам по определенной системе.
Ну а уж тех, кто посылает своих сотрудников просто проверить как магазин разложил товар (магазин по договору обязан это делать определенным образом) — тех вообще тьма тьмущая.
Так что просто на «дешевых мексиканцев» полагаться не стоит. Они положат как попало. Должен быть и кто-то (ну а с AI правильно будет назвать «что-то»), кто (что) решит как раскладывать товар. Это важнее для прибыли.
использовать такие мощности просто чтобы продукты были свежими в одном супермаркете, странное обоснование. Они сэкономят на дешевых мексиканцах
Если бы люди всегда 100% ответственно подходили к своей работе — я бы с вами согласился. Но хрен знает проследят ли дешевые работники за товаром. Скорее поленятся, чем не поленятся.
Это отлично работает когда у тебя один-два-три магазина и ты имеешь возможность лично контролировать работников. Но не в случае сетей.
Тут важнее чтобы товары был 100% свежий в их огромной сети, а не сколько это обойдется.
При постановке технологии на поток — цена радикально упадет.
Кроме того, компьютеры не ходят в отпуск, да и болеют куда как меньше, чем люди, если на качестве железа не экономить и не ставить из интернета 100500 интересных игр совершенно бесплатно.
В производстве, торговле и пр. — запросто компьютерное железо может и по 10 и по 30 лет служить.
Это для товаров потребительского сегмента производители стимулируют нас заменять смартфоны как можно чаще и т.п.
А, скажем, в той же Германии до сих пор работают станки эпохи свастики и это не считается отсталым производством.
Алюминий в раствор переходит только с ощутимо кислой среде.
Варить варенье и кипятить соки в алюминиевой посуде я бы не стал.
Обычная вода с алюминием не взаимодействует.
Все правильно.
Любой хозяйке известно, что варить в аллюминевой посуде можно.
А хранить — нет.
Это вопрос не объёмов, всё-таки, а отсутствия спецификаций и нежелания разработчика поддерживать Linux.
А какая мне разница кто чего желает, кто чего может?
Факт остается фактом. Windows — поддерживает. Более никто.
И это не единственный случай, а, скорее типовой: поддержка железа в Windows наиболее обширная из всех ОС.
Ну и как следствие — место занимаемое драйверам.
Недавно заглянул на запасной тестовый сервер (на нем каждую ночь разворачивается тестовый бекап) — его никто не трогал квартал — так на нем свежие данные, всё работает, не упало. Собственно так и должно быть.
Практика (и не только моя) показывает, что ситуация, когда свежих бэкапов нет как раз именно тогда, когда они нужны — встречается.
В особо серьезных случаях вообще рекомендуется регулярно проверять не только факт того, что «файлы лежат», а и как бэкапы восстанавливаются в реальности.
А то может эти файлы только делают вид что они бэкапы, а на самом деле и сами уже повреждены. Или, к примеру, там нет всего необходимого. С таким тоже только за этот век сталкивался, пожалуй, что и десятки раз уже.
Скажем, типичны ситуации, что бэкапы автоматически делались-делались, а потом какие-то настройки в сети изменились/места не хватило/перестали успевать делаться в течение нерабочего времени а в рабочее время их делать невозможно/т.п. — и, вуаля, у вас только бэкапы 3-х месячной давности.
В IT нет госграниц. Суверенитет обеспечивается отсутствием вендор-лока.
Только для чего-то относительно универсального как СУБД.
Или чего то относительно простого как Office
Ну а теперь скажите это каким нибудь банкам или серьезным конторам типа нефтегаза.
Где потери от простоев просто фантастические.
Им нужна поддержка серьезнейшего уровня, от производителя. И они готовы за это платить.
Их тут не вендор-лок волнует — а собственнно поддержка, пусть и с локом.
А отсутствие вендор-лока при одновременном отсутствие же поддержки наисерьезнейшего уровня — подобные фирмы с потенциально огромными от простоев потерями мало когда устраивает.
В IT нет госграниц
Ага. Но только для чего-то простого/универсального.
Да как нет границ?
Возьмем ПО 1С: Предприятие.
Подстроено под особенности страны.
Есть специалисты в почти любом месте.
Может ли предложить opensource-сообщество подобное развитое ПО альтернативное?
Мы же обсуждаем каталог с товаром — там вообще нет транзакций ни в каком виде. В простейшем случае каталог загружается 1 раз при начале работы.
Ну а если каталог может изменяться в течение дня и это нужно учесть, то, по причине ограниченной многозадачности DOS, которую мы обсуждаем, и большой трудоемкости реализации многозадачности чисто силами прикладного приложения — загрузку целесообразно производить будет с блокировкой работы кассы.
Для ускорения этого процесса — можно организовать работу с дельтами — основной файл большой, долго грузится, грузится 1 раз при начале работы. И маленькие файлики с изменениями (крайне маловероятно 100% и т.п. значительное изменение каталога товара в течение рабочего дня — в любом случае это будет внештатная ситуация). Маленькие дельты грузятся с течение дня, но быстро.
Что касается транзакций при записи сведений о продажах — то там СУБД тоже не нужна.
Информация о продажах просто пишется в файлы, подобные текстовым логам. Можно «1 продажа = 1 файл».
Сервер потом эти логи собирает с касс и на своем более мощном железе переваривает и записывает в нормальную СУБД.
Может закономерно возникнуть вопрос — а как быть с оперативной информацией об остатках?
У меня тоже возникал этот вопрос когда я только начинал работать с кассами в розничных магазинах.
Разгадка проста:
Если покупатель взял товар физически и подошел к кассе — значит товар на остатках есть, проверять ничего не нужно, нужно как можно быстрее обслужить покупателя. И ни в коем случае не говорить ему фразы «я не могу вам продать этот товар, потому что компьютер мне этого не позволяет, потому что компьютер считает, что этого товара нет в наличии».
Поэтому учет остатков на кассе оперативный не нужен.
Остатки нужны только для инвентаризации и для дозаказа товара у поставщика. Но этим занимается не то ПО, что на кассах стоит.
Остатки на сервере, который собирает данные с касс, конечно есть и они там конечно нужны. Но то, что сервер узнает точные остатки на пару минут позже, а до этого остатки на смешные единицы (это же розница, не опт) расходились с действительностью — ни на что это не влияет.
В конце-то концов, покупатель уже может взять товар и гулять с ним по залу, но еще не пройти через кассу. Эту ситуацию ты все равно никак не учтешь в кассовом модуле, а разговор у нас именно о нем.
Вы ведь вряд ли будете писать свой движок СУБД под такую задачу. А что толку от возможностей экстендеров, если ваш Paradox или dBase все равно сидит сугубо в conventional
Конечно не буду писать свой движок, я просто загружу все данные при начале работы программы в хэш-таблицу, то есть в нечто вроде:
map[string]ProductStruct
Там поиск нужен только по штрихкоду.
На диске это вполне может храниться в простейших файлах CSV. Эти файлы нужны только при старте программы, то есть 1 раз
Добавьте сюда ещё хотя бы артикул и штрих-код.
Справедливо. EAN13, к примеру — это 13 десятичных цифр. +5 байт
Артикул как отдельное поле за последние 20 лет в этой сфере мне понадобился что то то ли около одного раза из примерно 200 предприятий. Его, если нужен, просто добавляют к названию.
Не говоря уже о том, что нужны ещё и категории товаров, т.к. если это спиртное, касса не должна его ночью пробивать
Это 1 бит.
Но конкретно по алкоголю все еще несколько сложнее — алкоголь при продаже должен регистрироваться в ЕГАИС.
если это весовой товар, касса должна потребовать ввести вес
Я в курсе как это работает.
Это просто зашито во все том же штрихкоде.
P.S.:
А еще можно использовать какой нибудь быстрый алгоритм сжатия.
Тексты и так хорошо сжимаются, а уж товары, чьи слова в названиях у которых повторяются «Матрешка большая/Матрешка малая красная/Матрешка малая синяя» — тем более хорошо сжимаются.
Ещё по-хорошему, должна быть единица измерения (и привязанный к ней штрих-код), т.к. один и тот же товар продаётся по-разному, вы можете сигареты продавать пачками, а можете блоками
Если это часто — да, единица измерения целесообразна.
Если это частный случай, для отдельных товаров — проще завести как отдельный товар.
И водку — бутылками, ящиками, фуфыриками.
Я вам больше скажу — даже в оптовых конторах, где такое в порядке вещей — ради ящиков далеко не всегда заморачиваются отдельной сущностью, а просто указывают в бутылках (сколько там в ящике бутылки) или просто вводят отдельное наименование:
«Бутылка, поштучно»
«Бутылка в ящике, 20 шт»
А самое главное, что фига с два вы всё вышеуканное засунете в кастомный движок за вменяемое время. Тут без СУБД никак.
Вы удивитесь, но именно что без движка СУБД я это и делаю. Правда не для целей касс, а для интернет-магазинов.
В современных языках программирования полным полно удобных библиотек с различными структурами.
Это просто и быстро.
СУБД полезна для поддержки транзакций и многопользовательской работы и хитрого поиска.
В этой задаче — однопользовательский режим, транзакций по сути нет (если идет отмена/возврат, то это просто отдельная запись, дополнительная к основной записи, — а суммирование их производится не на компьютере кассы, а уже на сервере, на куда как более мощном железе), поиск только по штрихкоду, это простейшая хеш-таблица (ключом является штрих-код, а значением все остальное), которая давным давно уже реализована для всех языков.
Так что СУБД тут не нужна. Это не только моя идея. Известное мне вполне себе развитое ПО для организации работы касс (функционирует в текстовом режиме, под Linux, без X11; то есть похожа на обсуждаемое решение) — загружает себе данные целиком, из текстового файла в формате CSV при начале работы.
Вот если бы объем данных был таковым, что нужна бы была подкачка с диска — это действительно была бы дополнительная существенная сложность. И тут, пожалуй была бы полезна и СУБД.
Но и с ней ничего страшного нет. Есть embedded СУБД, типа BerkleyDB и множество более развитых. Им доступна та память, которая доступна собственно и вашей программе, так как она в вашу программу вкомпилируется, это такой же исходный код как и ваш собственный, все собирается воедино.
Так что номенклатура в 385000 товаров
Причем, заметьте, речь идет об очень слабой машине с 64 М, где до этого Windows XP еле-еле ворочалась, это наиминимальнейшие требования для нее. А скорее всего там будет от 256 М.
У меня в проектах тоже базы на миллионы документов, которые надо поддерживать в актуальном состоянии и есть новостной раздел. Признаюсь, я про новостной раздел давно забыл, не до него, мягко говоря…
Смею предположить, что вы не собственно сайтом с миллионом документов занимаетесь.
А сначала «переваривайте» исходные миллионы документы.
Мой тезис не в этом. Мой тезис — сумма вполне адекватная для одного работника. При этом работы не сделаны.
Работы не сделаны — про это вся статья и есть.
Сумма адекватна для одного работника.
Но! Есть еще затраты и на рабочее место сотрудника и на сервер и его обслуживание и общеадминистративные затраты.
Я имел ввиду виртуализацию. Админ у них всё равно есть (основной сайт у них вполне приличный).
Делать внешний и внутрениий сайт на одном физическом сервере даже через виртуализацию вполне может быть запрещено по соображениям безопасности.
Сам по себе сервер не падает, поддержка не нужна.
Вы рассуждаете прям как «эффективный менеджер».
Мой админский опыт говорит, что зарплату мне не всегда платят «просто так».
Впрочем, если бы речь шла о малом бизнесе, очень малом, где ты сам себе админ, то вы совершенно правы — так и есть.
Она нужна только если проект развивается, обновляется, меняется.
Тут она нужна существенно больше, чем при отсутствии изменений.
Но из этого не следует, что при отстуствие изменений вообще ничего не нужно тратить на поддержание работоспособности, да хотя бы на бэкапы и их проверку.
Это понятно, что основные затраты идут только на этого гипотетического основного сотрудника.
Тем не менее остальные затраты — отнюдь не нулевые.
В принципе расчеты показывают, что сумма, запрошенная Росстатом под этот проект — близка к разумной.
Чуть больше — чуть меньше, но это уже зависит от деталей проекта, которым мы не знаем.
Зная об не очень большой эффективности в большинстве предприятий-учреждений, я бы называл эту сумму несколько оптимистичной.
Её хватило бы вполне хватило при отличной эффективности при организации работ, например, для малого предприятия, где все сотрудники на виду.
Налоги забираются не оттуда, а начисляются сверху. Вы не можете забрать из 2.5 млн 13% подоходного. Это ошибка.
10% ПФР не дополнительно, а вместо, разве нет?
Итого получается примерно 1.8 млн зарплата, 700 тыс налоги. Примерно 150 тыс в месяц.
Есть «налоги уплачиваемые работодателем». ПРФ, ФСС, ФОМС.
Есть «налоги уплачиваемые сотрудником». НДФЛ.
Однако фактически они все будут уплачиваться с той суммы, что государство выделило на этот проект.
Возьмем зарплату «начисленную, до налогоображения» в 200 000 рублей.
НДФЛ 13% будет 26000
Сумма, выдаваемая на руки, будет 174 000
Таким образом, на налоги уходит от 29% до 33% от всех расходов, связанных с зарплатой сотрудника. Остальные от 67% до 71% идет собственно «на руки сотруднику».
Чтобы полностью «утилизировать 2,5 миллионов в год, пустив их только на зарплату нужно начислить по ставке 22% ПФР сумму в 1 150 000 и по ставке 10% ПФР сумму в 848 300.
В этом случае налоги + зарплата отданная человеку на руки и составит в аккурат 2,5 миллиона.
В месяц зарплата на руки будет в этом случае 145 000.
Но это при условии, что мы игнорируем все прочие затраты — на сервер, на обслуживание сервера, на организацию рабочего места данного сотрудника, административные затраты и пр.
Вы имеете ввиду, что работ на 2.5 млн скорее всего сделано достаточно?
Я имею ввиду, что указанная сумма за указанные работы — не страшная.
Да, если просто эту сумму написать — кажется много.
Если учесть налоги и доп. затраты и раскинуть на месяц — сумма рядовая.
Завышенная она или даже заниженная — сильно зависит от конкретных работ, которых мы, нужно признать, что всё же досканально не знаем.
По моему мнению она более менее похожая на реальные затраты.
Надеюсь, до такого маразма не дошло, и никакого отдельного сервера под этот проект не стоит.
Вполне нормально держать отдельный сервер под эту задачу.
Не забывайте, что всё же речь идет об федеральном учреждении.
Там могут быть и требования связанные, к примеру, с безопасностью (да, иногда эти требования бывают мразматичными, согласен).
Отдельный сервер сейчас недорого.
Но все равно это не бесплатно.
Налоги забираются не оттуда, а начисляются сверху. Вы не можете забрать из 2.5 млн 13% подоходного. Это ошибка.
Государство выделило X рублей на некий проект. Росстат нанял сотрудника на этот проект.
По закону, если сотруднику выплачивается заплата, но нужно платить с этих денег и НДФЛ и ПФР и пр.
Как бюджетное учреждение Росстат не платит прочие налоги — налог на прибыль, к примеру, как это делают обычные, то есть коммерческие предприятия.
Но налоги, связанные с зарплатой Росстат платит. Да, из тех бюджетных денег, что он получает.
Немного нелогично выглядит. Но, если подумать, что Росстат мог нанять сотрудника (тогда эти налоги платятся), а мог нанять внешнего подрядчика (тогда бы налоги сам бы Росстат не платил), или мог бы нанять сотрудника на другую зарплату (тогда бы другие налоги по зарплате платил бы Росстат)
Налоги забираются не оттуда, а начисляются сверху.
То, что вы имеете ввиду, называется «налогооблагаемая база».
Нет, оно не начисляется сверху на то, что «выдано на руки».
Там немного хитрее.
10% ПФР не дополнительно, а вместо, разве нет?
Да че то одни источники в интернете говорят одно, другие другое.
Накопал первоисточник 03.08.2018 N 303-ФЗ
Да, вы правы.
Итого получается примерно 1.8 млн зарплата, 700 тыс налоги. Примерно 150 тыс в месяц.
Все предыдущее у меня было навскидку.
Но и в вашем расчете есть сомнения, давайте я в отдельном комментарии посчитаю точно, самому интересно.
Как тут верно заметили в соседнем комментарии habr.com/ru/post/449828/#comment_20100296
есть разные положительные и отрицательные моменты и на длинной и на короткой дистанции.
Не то, чтобы мне это «импортозамещение» нравилось.
Да и понятно что на данном этапе «импортозамещение» всё больше фикция, столь быстро просто невозможно всё импортозаместить о чем уже отрапортовали.
Но тупость всё же разная бывает, например, тупостью является — не видеть собственных экономических возможностей.
Вполне можно рассматривать это как протекционистскую политику для собственной экономики (неважно какова первопричина, но фактически получаем именно аналог «заградительных таможенных пошлин», что широко практиковались различными государствами с целью стимуляции своей экономики). Без этого нельзя, поскольку, по большому счету, мы мало чего нужного другим странам умеем делать. Но при этом все хотим иметь возможность покупать импортные товары.
Китайское «импортозамещение», порожденное их закрытым сегментом интернета породило их собственный и очень мощный IT-бизнес.
Без этого Alibaba/Aliexpress не смогли бы одной из богатейших фирм ИТ в мире.
То, что само производство в Китае — ни о чем не говорит. Amazon/eBay сделали бы китаеязычный интерфейс пользователя, сделали бы простую выплату денег китайским продавцам — и никому бы из китайцев были бы не нужны не Alibaba/Aliexpress ни Alipay.
Аналогично можно сказать и WeChat, ставший к сегодняшнему дню уже и серьезной платежной системой, хотя начинавшийся только как чат. И Baidu и пр.
Почему бы и нашей стране не воспользоваться ситуацией и не начать делать своими руками что-то нужное в какой-то отрасли. По мере роста и развития той отрасли, глядишь, сможем и конкурировать на международном рынке не только нефтью и военкой.
а то, как обширную товарную номенклатуру впихнуть в те самые 640К
Да ладно вам. Даже в самых древних еще живых и доступных в больших количествах POS терминалах уже есть хотя бы 64М. Как бы они иначе на обсуждаемой Windows XP работали?
А DOS уже давным-давно как научилась работать с памятью большей 640K. Гуглить himem.sys, память EMS и пр.
А еще существует ПО класса DOS-extender. Например, памятные DOS4G/W, CWSDPMI, знаменитый PMODE, бесплатный DOS/32 — там вообще прикладной программе с памятью работать удобно. Это все от процессора Intel 80386 требует.
Если еще более древнее железо, то даже на компьютере с процессором Intel 80286 упомянутый выше Turbo Pascal (Borland Pascal 7, точнее) в режиме DPMI умел штатно работать с памятью большей 640К
P.S.:
А давайте посчитаем на что хватит 32М (это половина от 64М, которые должны быть на компьютерах с Windows XP, иначе она бы и не запустилась; оставшиеся 32М оставляем на собственно код ПО и прочие переменные)
Название товара 80 байт (недавно программировал вывод на фискальный регистратор, там все равно длина названия ограничена во многих моделях)
Цена товара 3 байта (float не нужен, вполне достаточно с фиксированной запятой, ведь 2 разряда под копейки)
Остатки кассовые модуля для розницы — не хранят, как правило.
Получается 385 000 товаров.
Я имею опыт работы с розничными магазинами — даже 100 000 товаров — это уже серьезный магазин.
А еще можно сжать каким нибудь шустрым алгоритмом… Тексты сжимаются хорошо, тем более, что в названиях товаров много повторений.
Сканеры штрих-кодов и магнитных карт обычно эмулируют клавиатурный ввод
Я это даже программировал — в курсе.
Да зачастую эмулируют. Раньше — и аппаратно в большинстве случаев.
Но теперь уже чаще именно что программно — физически сканер подключаются все больше через USB и эмуляция идет на уровне драйвера HID.
И если, может, сам компьютер поменять особого стимула нет (если ПО и так на нем нормально работает), то перейти на новый более точный, более быстрый сканер, сканер с поддержкой современных QR-подобных двухмерных штрих-кодов — вот в этом стимул у бизнеса может быть.
Современные сканеры позволяют существенно улучшить бизнес-процессы.
Но вот в чем незадача, — современные сканеры в версии без USB, на COM могут оказаться недоступнее для приобретения (дороже, реже, под заказ за полгода, меньше выбор моделей с высоким качеством работы и т.п.)
Так что поддержка USB в ПО может оказаться и принципиальной для бизнеса.
Так что я бы предложил все же не DOS, а Linux/FreeBSD в текстовом режиме, без X11.
Интересно, а когда ИИ сможет заменить владельцев всех этих бизнесов? Ведь алгоритмизировать жадность, алчность и жажду наживы намного проще, чем труд людей у полок
Создание ИИ финансируется по воле этих самых владельцев. Без желания людей зарабатывать больше — и компьютеров-то и не было.
Трудно предположить, что владельцы возжелают профинансировать создание заменителей себя, при котором владельцев же и отрежут от получения прибыли. Только заменителей того, кто будет выполнять за них работу — но при этом обязательно с сохранением гарантированной возможности получения прибылей. Только такое и профинансировать готовы.
Если, конечно, вы придумайте какое другое социально-экономическое устройство мира, где развитие технологий стимулируется как-то иначе, то…
Пока же ничто иное и не стимулирует развитие технологий как желание предпринимателей зарабатывать.
Даже если взять в качестве примера «бессеребренечества» при развитии технологий бесплатный opensource, то копнув чуть поглубже, видим, что:
Дешевые и доступные компьютеры и доступный интернет, позволяющие каждому желающему внести свой вклад, обеспечила изначально жажда наживы производителей, а тех в свою очередь простимулировала жажда наживы тех, кто пожелал автоматизировать свой бизнес. Или профинансировано государством для военных целей, а целью войн как раз и является захват чужих ресурсов.
Да и значительная доля разработки opensource осуществляется силами людей за зарплату/гранты богачей. Отключи разрабатывающих за зарплату от opensource — и мы имели бы совсем другой уровень поделок.
Есть мнение, что вода в основе своей, транспорт (вот только не помню чего), и из самой воды мало что усваивается.
Относительно пропорций — да, собственно H2O подавляюще больше, чем полезных веществ в ней растворенных.
Однако это не означает, что эти малые количества вещества совсем не нужны.
Давно известно, что расставлять товары нужно по определенным правилам, это существенно влияет на продажи.
Доходит до того, что некоторые серьезно относящиеся к этому делу производители нанимают за свой счет специальных собственных сотрудников (у нас они обычно называются «мерчендайзерами»), которые приходят в магазины, в которые товар этих производителей поставляется, и сами (а не работники магазинов) раскладывают товар по полкам по определенной системе.
Ну а уж тех, кто посылает своих сотрудников просто проверить как магазин разложил товар (магазин по договору обязан это делать определенным образом) — тех вообще тьма тьмущая.
Так что просто на «дешевых мексиканцев» полагаться не стоит. Они положат как попало. Должен быть и кто-то (ну а с AI правильно будет назвать «что-то»), кто (что) решит как раскладывать товар. Это важнее для прибыли.
Если бы люди всегда 100% ответственно подходили к своей работе — я бы с вами согласился. Но хрен знает проследят ли дешевые работники за товаром. Скорее поленятся, чем не поленятся.
Это отлично работает когда у тебя один-два-три магазина и ты имеешь возможность лично контролировать работников. Но не в случае сетей.
Тут важнее чтобы товары был 100% свежий в их огромной сети, а не сколько это обойдется.
При постановке технологии на поток — цена радикально упадет.
Кроме того, компьютеры не ходят в отпуск, да и болеют куда как меньше, чем люди, если на качестве железа не экономить и не ставить из интернета 100500 интересных игр совершенно бесплатно.
В производстве, торговле и пр. — запросто компьютерное железо может и по 10 и по 30 лет служить.
Это для товаров потребительского сегмента производители стимулируют нас заменять смартфоны как можно чаще и т.п.
А, скажем, в той же Германии до сих пор работают станки эпохи свастики и это не считается отсталым производством.
Все правильно.
Любой хозяйке известно, что варить в аллюминевой посуде можно.
А хранить — нет.
Ка это?
Вот как раз без Стима с играми в Linux так себе.
Да он
А какая мне разница кто чего желает, кто чего может?
Факт остается фактом. Windows — поддерживает. Более никто.
И это не единственный случай, а, скорее типовой: поддержка железа в Windows наиболее обширная из всех ОС.
Ну и как следствие — место занимаемое драйверам.
Практика (и не только моя) показывает, что ситуация, когда свежих бэкапов нет как раз именно тогда, когда они нужны — встречается.
В особо серьезных случаях вообще рекомендуется регулярно проверять не только факт того, что «файлы лежат», а и как бэкапы восстанавливаются в реальности.
А то может эти файлы только делают вид что они бэкапы, а на самом деле и сами уже повреждены. Или, к примеру, там нет всего необходимого. С таким тоже только за этот век сталкивался, пожалуй, что и десятки раз уже.
Скажем, типичны ситуации, что бэкапы автоматически делались-делались, а потом какие-то настройки в сети изменились/места не хватило/перестали успевать делаться в течение нерабочего времени а в рабочее время их делать невозможно/т.п. — и, вуаля, у вас только бэкапы 3-х месячной давности.
Только для чего-то относительно универсального как СУБД.
Или чего то относительно простого как Office
Ну а теперь скажите это каким нибудь банкам или серьезным конторам типа нефтегаза.
Где потери от простоев просто фантастические.
Им нужна поддержка серьезнейшего уровня, от производителя. И они готовы за это платить.
Их тут не вендор-лок волнует — а собственнно поддержка, пусть и с локом.
А отсутствие вендор-лока при одновременном отсутствие же поддержки наисерьезнейшего уровня — подобные фирмы с потенциально огромными от простоев потерями мало когда устраивает.
Ага. Но только для чего-то простого/универсального.
Да как нет границ?
Возьмем ПО 1С: Предприятие.
Подстроено под особенности страны.
Есть специалисты в почти любом месте.
Может ли предложить opensource-сообщество подобное развитое ПО альтернативное?
Уточню:
Мы же обсуждаем каталог с товаром — там вообще нет транзакций ни в каком виде. В простейшем случае каталог загружается 1 раз при начале работы.
Ну а если каталог может изменяться в течение дня и это нужно учесть, то, по причине ограниченной многозадачности DOS, которую мы обсуждаем, и большой трудоемкости реализации многозадачности чисто силами прикладного приложения — загрузку целесообразно производить будет с блокировкой работы кассы.
Для ускорения этого процесса — можно организовать работу с дельтами — основной файл большой, долго грузится, грузится 1 раз при начале работы. И маленькие файлики с изменениями (крайне маловероятно 100% и т.п. значительное изменение каталога товара в течение рабочего дня — в любом случае это будет внештатная ситуация). Маленькие дельты грузятся с течение дня, но быстро.
Что касается транзакций при записи сведений о продажах — то там СУБД тоже не нужна.
Информация о продажах просто пишется в файлы, подобные текстовым логам. Можно «1 продажа = 1 файл».
Сервер потом эти логи собирает с касс и на своем более мощном железе переваривает и записывает в нормальную СУБД.
Может закономерно возникнуть вопрос — а как быть с оперативной информацией об остатках?
У меня тоже возникал этот вопрос когда я только начинал работать с кассами в розничных магазинах.
Разгадка проста:
Если покупатель взял товар физически и подошел к кассе — значит товар на остатках есть, проверять ничего не нужно, нужно как можно быстрее обслужить покупателя. И ни в коем случае не говорить ему фразы «я не могу вам продать этот товар, потому что компьютер мне этого не позволяет, потому что компьютер считает, что этого товара нет в наличии».
Поэтому учет остатков на кассе оперативный не нужен.
Остатки нужны только для инвентаризации и для дозаказа товара у поставщика. Но этим занимается не то ПО, что на кассах стоит.
Остатки на сервере, который собирает данные с касс, конечно есть и они там конечно нужны. Но то, что сервер узнает точные остатки на пару минут позже, а до этого остатки на смешные единицы (это же розница, не опт) расходились с действительностью — ни на что это не влияет.
В конце-то концов, покупатель уже может взять товар и гулять с ним по залу, но еще не пройти через кассу. Эту ситуацию ты все равно никак не учтешь в кассовом модуле, а разговор у нас именно о нем.
Конечно не буду писать свой движок, я просто загружу все данные при начале работы программы в хэш-таблицу, то есть в нечто вроде:
Там поиск нужен только по штрихкоду.
На диске это вполне может храниться в простейших файлах CSV. Эти файлы нужны только при старте программы, то есть 1 раз
Справедливо. EAN13, к примеру — это 13 десятичных цифр. +5 байт
Артикул как отдельное поле за последние 20 лет в этой сфере мне понадобился что то то ли около одного раза из примерно 200 предприятий. Его, если нужен, просто добавляют к названию.
Это 1 бит.
Но конкретно по алкоголю все еще несколько сложнее — алкоголь при продаже должен регистрироваться в ЕГАИС.
Я в курсе как это работает.
Это просто зашито во все том же штрихкоде.
P.S.:
А еще можно использовать какой нибудь быстрый алгоритм сжатия.
Тексты и так хорошо сжимаются, а уж товары, чьи слова в названиях у которых повторяются «Матрешка большая/Матрешка малая красная/Матрешка малая синяя» — тем более хорошо сжимаются.
Если это часто — да, единица измерения целесообразна.
Если это частный случай, для отдельных товаров — проще завести как отдельный товар.
Я вам больше скажу — даже в оптовых конторах, где такое в порядке вещей — ради ящиков далеко не всегда заморачиваются отдельной сущностью, а просто указывают в бутылках (сколько там в ящике бутылки) или просто вводят отдельное наименование:
«Бутылка, поштучно»
«Бутылка в ящике, 20 шт»
Вы удивитесь, но именно что без движка СУБД я это и делаю. Правда не для целей касс, а для интернет-магазинов.
В современных языках программирования полным полно удобных библиотек с различными структурами.
Это просто и быстро.
СУБД полезна для поддержки транзакций и многопользовательской работы и хитрого поиска.
В этой задаче — однопользовательский режим, транзакций по сути нет (если идет отмена/возврат, то это просто отдельная запись, дополнительная к основной записи, — а суммирование их производится не на компьютере кассы, а уже на сервере, на куда как более мощном железе), поиск только по штрихкоду, это простейшая хеш-таблица (ключом является штрих-код, а значением все остальное), которая давным давно уже реализована для всех языков.
Так что СУБД тут не нужна. Это не только моя идея. Известное мне вполне себе развитое ПО для организации работы касс (функционирует в текстовом режиме, под Linux, без X11; то есть похожа на обсуждаемое решение) — загружает себе данные целиком, из текстового файла в формате CSV при начале работы.
Вот если бы объем данных был таковым, что нужна бы была подкачка с диска — это действительно была бы дополнительная существенная сложность. И тут, пожалуй была бы полезна и СУБД.
Но и с ней ничего страшного нет. Есть embedded СУБД, типа BerkleyDB и множество более развитых. Им доступна та память, которая доступна собственно и вашей программе, так как она в вашу программу вкомпилируется, это такой же исходный код как и ваш собственный, все собирается воедино.
Причем, заметьте, речь идет об очень слабой машине с 64 М, где до этого Windows XP еле-еле ворочалась, это наиминимальнейшие требования для нее. А скорее всего там будет от 256 М.
Может, кому интересно:
Среди тегов, подсказываемых в поле редактирования комментария, тега
subнет, но он поддерживается все равно.Можно так написать:
Na2CO3 + H2SO4 = Na2SO4 + H2O +2CO2
Смею предположить, что вы не собственно сайтом с миллионом документов занимаетесь.
А сначала «переваривайте» исходные миллионы документы.
Работы не сделаны — про это вся статья и есть.
Сумма адекватна для одного работника.
Но! Есть еще затраты и на рабочее место сотрудника и на сервер и его обслуживание и общеадминистративные затраты.
Делать внешний и внутрениий сайт на одном физическом сервере даже через виртуализацию вполне может быть запрещено по соображениям безопасности.
Вы рассуждаете прям как «эффективный менеджер».
Мой админский опыт говорит, что зарплату мне не всегда платят «просто так».
Впрочем, если бы речь шла о малом бизнесе, очень малом, где ты сам себе админ, то вы совершенно правы — так и есть.
Тут она нужна существенно больше, чем при отсутствии изменений.
Но из этого не следует, что при отстуствие изменений вообще ничего не нужно тратить на поддержание работоспособности, да хотя бы на бэкапы и их проверку.
Это понятно, что основные затраты идут только на этого гипотетического основного сотрудника.
Тем не менее остальные затраты — отнюдь не нулевые.
В принципе расчеты показывают, что сумма, запрошенная Росстатом под этот проект — близка к разумной.
Чуть больше — чуть меньше, но это уже зависит от деталей проекта, которым мы не знаем.
Зная об не очень большой эффективности в большинстве предприятий-учреждений, я бы называл эту сумму несколько оптимистичной.
Её хватило бы вполне хватило при отличной эффективности при организации работ, например, для малого предприятия, где все сотрудники на виду.
Есть «налоги уплачиваемые работодателем». ПРФ, ФСС, ФОМС.
Есть «налоги уплачиваемые сотрудником». НДФЛ.
Однако фактически они все будут уплачиваться с той суммы, что государство выделило на этот проект.
Возьмем зарплату «начисленную, до налогоображения» в 200 000 рублей.
НДФЛ 13% будет 26000
Сумма, выдаваемая на руки, будет 174 000
ПФР 22% 44000
ФФОМС 5,1% 10200
ФСС 2,9% 5800
ФСС/несчастные случае 0,2% 400
Сумма налогов «уплачиваемая работодателем» 60400
Сумма налога «уплачиваемая сотрудником» 26000
То есть если 174 000 на руки
То на налоги 86 000
Иного нужно денег 260 000
Налоги с них составляют 33%
Скидка на ПФР до 10% начинается с начисленных 1 150 000
То есть до этой суммы налоги 33%, что составляет 379 500
После начинает 10% выплаты с ПФР.
С тех же 200 000 начисленных будет так:
НДФЛ 13% будет 26000
Сумма, выдаваемая на руки, будет 174 000
ПФР 10% 20000
ФФОМС 5,1% 10200
ФСС 2,9% 5800
ФСС/несчастные случае 0,2% 400
Сумма налогов «уплачиваемая работодателем» 44400
Сумма налога «уплачиваемая сотрудником» 26000
То есть если 174 000 на руки
То на налоги 70 000
Общая сумма расхода 244 000
Из них налогов 29%
Таким образом, на налоги уходит от 29% до 33% от всех расходов, связанных с зарплатой сотрудника. Остальные от 67% до 71% идет собственно «на руки сотруднику».
Чтобы полностью «утилизировать 2,5 миллионов в год, пустив их только на зарплату нужно начислить по ставке 22% ПФР сумму в 1 150 000 и по ставке 10% ПФР сумму в 848 300.
В этом случае налоги + зарплата отданная человеку на руки и составит в аккурат 2,5 миллиона.
В месяц зарплата на руки будет в этом случае 145 000.
Но это при условии, что мы игнорируем все прочие затраты — на сервер, на обслуживание сервера, на организацию рабочего места данного сотрудника, административные затраты и пр.
Я имею ввиду, что указанная сумма за указанные работы — не страшная.
Да, если просто эту сумму написать — кажется много.
Если учесть налоги и доп. затраты и раскинуть на месяц — сумма рядовая.
Завышенная она или даже заниженная — сильно зависит от конкретных работ, которых мы, нужно признать, что всё же досканально не знаем.
По моему мнению она более менее похожая на реальные затраты.
Вполне нормально держать отдельный сервер под эту задачу.
Не забывайте, что всё же речь идет об федеральном учреждении.
Там могут быть и требования связанные, к примеру, с безопасностью (да, иногда эти требования бывают мразматичными, согласен).
Отдельный сервер сейчас недорого.
Но все равно это не бесплатно.
Государство выделило X рублей на некий проект. Росстат нанял сотрудника на этот проект.
По закону, если сотруднику выплачивается заплата, но нужно платить с этих денег и НДФЛ и ПФР и пр.
Как бюджетное учреждение Росстат не платит прочие налоги — налог на прибыль, к примеру, как это делают обычные, то есть коммерческие предприятия.
Но налоги, связанные с зарплатой Росстат платит. Да, из тех бюджетных денег, что он получает.
Немного нелогично выглядит. Но, если подумать, что Росстат мог нанять сотрудника (тогда эти налоги платятся), а мог нанять внешнего подрядчика (тогда бы налоги сам бы Росстат не платил), или мог бы нанять сотрудника на другую зарплату (тогда бы другие налоги по зарплате платил бы Росстат)
То, что вы имеете ввиду, называется «налогооблагаемая база».
Нет, оно не начисляется сверху на то, что «выдано на руки».
Там немного хитрее.
Да че то одни источники в интернете говорят одно, другие другое.
Накопал первоисточник 03.08.2018 N 303-ФЗ
Да, вы правы.
Все предыдущее у меня было навскидку.
Но и в вашем расчете есть сомнения, давайте я в отдельном комментарии посчитаю точно, самому интересно.
Как тут верно заметили в соседнем комментарии
habr.com/ru/post/449828/#comment_20100296
есть разные положительные и отрицательные моменты и на длинной и на короткой дистанции.
Не то, чтобы мне это «импортозамещение» нравилось.
Да и понятно что на данном этапе «импортозамещение» всё больше фикция, столь быстро просто невозможно всё импортозаместить о чем уже отрапортовали.
Но тупость всё же разная бывает, например, тупостью является — не видеть собственных экономических возможностей.
Вполне можно рассматривать это как протекционистскую политику для собственной экономики (неважно какова первопричина, но фактически получаем именно аналог «заградительных таможенных пошлин», что широко практиковались различными государствами с целью стимуляции своей экономики). Без этого нельзя, поскольку, по большому счету, мы мало чего нужного другим странам умеем делать. Но при этом все хотим иметь возможность покупать импортные товары.
Китайское «импортозамещение», порожденное их закрытым сегментом интернета породило их собственный и очень мощный IT-бизнес.
Без этого Alibaba/Aliexpress не смогли бы одной из богатейших фирм ИТ в мире.
То, что само производство в Китае — ни о чем не говорит. Amazon/eBay сделали бы китаеязычный интерфейс пользователя, сделали бы простую выплату денег китайским продавцам — и никому бы из китайцев были бы не нужны не Alibaba/Aliexpress ни Alipay.
Аналогично можно сказать и WeChat, ставший к сегодняшнему дню уже и серьезной платежной системой, хотя начинавшийся только как чат. И Baidu и пр.
Почему бы и нашей стране не воспользоваться ситуацией и не начать делать своими руками что-то нужное в какой-то отрасли. По мере роста и развития той отрасли, глядишь, сможем и конкурировать на международном рынке не только нефтью и военкой.
Да ладно вам. Даже в самых древних еще живых и доступных в больших количествах POS терминалах уже есть хотя бы 64М. Как бы они иначе на обсуждаемой Windows XP работали?
А DOS уже давным-давно как научилась работать с памятью большей 640K. Гуглить himem.sys, память EMS и пр.
А еще существует ПО класса DOS-extender. Например, памятные DOS4G/W, CWSDPMI, знаменитый PMODE, бесплатный DOS/32 — там вообще прикладной программе с памятью работать удобно. Это все от процессора Intel 80386 требует.
Если еще более древнее железо, то даже на компьютере с процессором Intel 80286 упомянутый выше Turbo Pascal (Borland Pascal 7, точнее) в режиме DPMI умел штатно работать с памятью большей 640К
P.S.:
А давайте посчитаем на что хватит 32М (это половина от 64М, которые должны быть на компьютерах с Windows XP, иначе она бы и не запустилась; оставшиеся 32М оставляем на собственно код ПО и прочие переменные)
Название товара 80 байт (недавно программировал вывод на фискальный регистратор, там все равно длина названия ограничена во многих моделях)
Цена товара 3 байта (float не нужен, вполне достаточно с фиксированной запятой, ведь 2 разряда под копейки)
Остатки кассовые модуля для розницы — не хранят, как правило.
Получается 385 000 товаров.
Я имею опыт работы с розничными магазинами — даже 100 000 товаров — это уже серьезный магазин.
А еще можно сжать каким нибудь шустрым алгоритмом… Тексты сжимаются хорошо, тем более, что в названиях товаров много повторений.
Я это даже программировал — в курсе.
Да зачастую эмулируют. Раньше — и аппаратно в большинстве случаев.
Но теперь уже чаще именно что программно — физически сканер подключаются все больше через USB и эмуляция идет на уровне драйвера HID.
И если, может, сам компьютер поменять особого стимула нет (если ПО и так на нем нормально работает), то перейти на новый более точный, более быстрый сканер, сканер с поддержкой современных QR-подобных двухмерных штрих-кодов — вот в этом стимул у бизнеса может быть.
Современные сканеры позволяют существенно улучшить бизнес-процессы.
Но вот в чем незадача, — современные сканеры в версии без USB, на COM могут оказаться недоступнее для приобретения (дороже, реже, под заказ за полгода, меньше выбор моделей с высоким качеством работы и т.п.)
Так что поддержка USB в ПО может оказаться и принципиальной для бизнеса.
Так что я бы предложил все же не DOS, а Linux/FreeBSD в текстовом режиме, без X11.
Технически сложности слишком велики — не типовое решение, «не загуглить, не скопипастить». Посему всё это сделать слишком дорого.
Напротив, для одиночного магазина дешевле купить компьютер современный, чем оплачивать работу специалиста, способного это сделать.
А сети — именно что выгодно профинансировать разработку и сэкономить на 100500 компьютерах.
Создание ИИ финансируется по воле этих самых владельцев. Без желания людей зарабатывать больше — и компьютеров-то и не было.
Трудно предположить, что владельцы возжелают профинансировать создание заменителей себя, при котором владельцев же и отрежут от получения прибыли. Только заменителей того, кто будет выполнять за них работу — но при этом обязательно с сохранением гарантированной возможности получения прибылей. Только такое и профинансировать готовы.
Если, конечно, вы придумайте какое другое социально-экономическое устройство мира, где развитие технологий стимулируется как-то иначе, то…
Пока же ничто иное и не стимулирует развитие технологий как желание предпринимателей зарабатывать.
Даже если взять в качестве примера «бессеребренечества» при развитии технологий бесплатный opensource, то копнув чуть поглубже, видим, что:
Дешевые и доступные компьютеры и доступный интернет, позволяющие каждому желающему внести свой вклад, обеспечила изначально жажда наживы производителей, а тех в свою очередь простимулировала жажда наживы тех, кто пожелал автоматизировать свой бизнес. Или профинансировано государством для военных целей, а целью войн как раз и является захват чужих ресурсов.
Да и значительная доля разработки opensource осуществляется силами людей за зарплату/гранты богачей. Отключи разрабатывающих за зарплату от opensource — и мы имели бы совсем другой уровень поделок.
Относительно пропорций — да, собственно H2O подавляюще больше, чем полезных веществ в ней растворенных.
Однако это не означает, что эти малые количества вещества совсем не нужны.