Нюансы работы SH4

[Scaramouche]

Выделено из другой темы, после этого сообщения - SH

------------------

Тут все очень сильно завязано на особенности логики Shouse, адаптированной к высокой скорости работы. Фишка в том, что документы не меняются. В документе нет товара - только ссылка на него, какая единица записана "на сейчас", такая и отобразится. Можно ругаться и говорить, что это баг, но это как раз самая настоящая фича. Неверные данные будут только в том случае, если пользователь задаст неверные коэффициенты пересчета - виновата ли в этом программа? Я считаю, что нет.

Вы когда-нибудь видели лицо бухгалтера, который обнаружил, что сданные в органы отчетность за прошлый период отличается от тех, что в базе?
В таблице детализации документа как минимум есть код товара, кол-во и должна быть единица измерения базовая и выбранная, это позволяет достоверно хранить данные и отображать их без каких-либо последствий после изменений в НСИ товаров.
Пользователь не знает что храниться в базе, ему это не объяснить, он должен видеть актуальную информацию, если вместо 360 шт. яиц он затем увидит 9000 шт. в накладной прошлого квартала, сколько времени ему потребуется докопаться до сути, даже при условии, что он знает об этой "фиче". Программа виновата всегда, защита от дурака должна быть везде где это только возможно, это вам ответит любой разработчик.
Я просто сводил эти косяки к тому , что в sh и так обширное поле для злоупотреблений, а так можно списать еще и на программу. Весь мой спич про данные сводился к этому. Чем чище данные , тем проще поймать.

Вопрос по sk7: база у него в DOS/Windows варианте та же , т.е. UDB или что то другое?

---------- Добавлено в 13:46 ---------- Предыдущее сообщение было размещено в 13:38 ----------

Поэтому, чтобы отказаться от кипера с хаусом, нужны железобетонные аргументы. Пока их никто не предъявил.

Я не собираюсь менять р-кипер. В моем случае надо правильно выбрать, т.к. внедрение будет с нуля. Вопрос по тормозам на айко меня очень сильно беспокоит. Это после внедрения не заметно, но после 1 года эксплуатации может оказаться,что никто об архивировании данных и не думал, т.е база пухнет запросы отрабатывают медленнее, при разделения на оперативный и архивный период данная проблема легко решается, но решена ли она для айки я не знаю. Еще один камень в айку от меня это то, что если я не ошибаюсь, она на .net во фронте написана на c#. Если это так, то потребуются гораздо более производительные компьютеры на фронт, чем для кипера.

[SH]

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

Да. Поэтому я еще раз подчеркну: подобные ошибки сданную отчетность не изменят!

Пользователь не знает что храниться в базе, ему это не объяснить, он должен видеть актуальную информацию, если вместо 360 шт. яиц он затем увидит 9000 шт. в накладной прошлого квартала, сколько времени ему потребуется докопаться до сути, даже при условии, что он знает об этой "фиче".

Если знает - 0 минут 5 секунд. Есл не знает - да, будет копаться долго. Но простите, это ничем не отличается от любой другой ошибки оператора. Защита от дурака - ооок, закрыть период можно, те данные, которые должны быть неизменными - останутся неизменными.

Я просто сводил эти косяки к тому , что в sh и так обширное поле для злоупотреблений, а так можно списать еще и на программу.

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

Чем чище данные , тем проще поймать.

146% Многие не понимают и рассуждают (sibgaba, в твой огород!), что пользователь должен выбирать. Нифига, пользователь должен ходить по струнке.

Вопрос по sk7: база у него в DOS/Windows варианте та же , т.е. UDB или что то другое?

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

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

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

[Scaramouche]

Да. Поэтому я еще раз подчеркну: подобные ошибки сданную отчетность не изменят!

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

Защита от дурака - ооок, закрыть период можно, те данные, которые должны быть неизменными - останутся неизменными.

Это приемлемое решение.

146% Многие не понимают и рассуждают (sibgaba, в твой огород!), что пользователь должен выбирать. Нифига, пользователь должен ходить по струнке.

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

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

Этот момент не понял. По схеме в айко кассовый компьютер является автономным , т.е оперативная база в формате ms sql compact на самой кассе, обмен происходит с центральной базой на центральном компьютере заведения. Вы имели в виду что вообще все приложения и базы на одном компьютере?
По поводу UDB формата гуляет слух что есть служебные утилиты от разработчика или что то в этом роде, где можно получить доступ к базе на изменение данных, это так?

[SH]

По поводу UDB формата гуляет слух что есть служебные утилиты от разработчика или что то в этом роде, где можно получить доступ к базе на изменение данных, это так?

Служебные утилиты от разработчика конечно же существуют. Гуляют? Не видел. Можно поставить простой эксперимент: взять скопировать UDB, потом закрыть чек, а потом подложить скопированную UDB. В RK6 аналогичный финт проходит. В RK7 касса откажется запускаться. Аналогично с правленым. Там контроль целостности неплохой. Да, ломается все, но тут стоимость взлома довольно высока. Разработчики на этот раз сделали все, чтобы нельзя было просто данные стереть или изменить.

---------- Добавлено в 20:55 ---------- Предыдущее сообщение было размещено в 20:46 ----------

не только отчет по остаткам не изменятся, но и продажи и расходование ингредиентов?

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

По схеме в айко кассовый компьютер является автономным , т.е оперативная база в формате ms sql compact на самой кассе, обмен происходит с центральной базой на центральном компьютере заведения. Вы имели в виду что вообще все приложения и базы на одном компьютере?

Возможно, уже все спуталось в сознании моем...

[sibgaba]

Многие не понимают и рассуждают (sibgaba, в твой огород!), что пользователь должен выбирать.

А все равно не согласен Просто когда мы с тобой когда обсуждали эту тему, я пиво пил, а ты кальян курил. Вот поэтому и не смогли прийти к общему знаменателю В след раз надо будет водку кушать, что бы "Vodka - connecting people"

Про SH и пример с яйцом - ИМНО проблема выеденного яйца не стоит (уж простите за каламбур). Реально правильный коэффициент для яйца нужно проставить 1 раз. Других таких не очевидных товаровпочти нет. Ну может еще яйцо перепелиное (если им работают). Я обычно делаю это во время обучения, когда рассказываю про заполнение справочника товаров. А дальше просто им пользуемся. Был момент когда эта проблема вылезла на уже работающих объектах: Во всех барах есть бутылочное вино, которое не идет в розлив и как правило его измеряют тупа штуками. Когда, в прошлом году, появилась алкогольная декларация, то для ее нужд ко всему вину пришлось добавить "Л" с соответствующим коэффициентом. Некоторые бухи, не смотря на подробные разъяснения, умудрились там накосячить. Но говорить о том что "доп ед измерения" и "коэффициент пересчета" это есть зло - нельзя. Это еще один инструмент (и во многих случаях оч удобный инструмент). Например в 1С (в базовых конфах) неичего такого нет и для товара может быть только одна ед изм. А если учесть что количество в 1С хранится с точностью до 3-х знаков - то на кондитерских производствах имеем такой головняк! В SH это решается изящно и красиво.

Вот вам еще пример: был у меня в практике 1 шеф повар, который хотел во что бы то ни стало, в к/к измерять растительное масло граммами. Оператору склада, приходовать килограммами масло, которое поступает в 1-5 литровых бутылках, ну ни как не удобно. Заставить ее каждый приход пересчитывать в уме/на калькуляторе - сами понимаете не выход. А вот тут доп единица измерения "Решает"!

В SH5 пошли еще дальше, там кроме базовой ед, будет еще понятие "ед. для построения отчетов" и вот тогда наступит мир во всем мире

[VampireKB]

В SH5 пошли еще дальше, там кроме базовой ед, будет еще понятие "ед. для построения отчетов"

SH 5 ??? уже ??

[Scaramouche]

Про SH и пример с яйцом - ИМНО проблема выеденного яйца не стоит (уж простите за каламбур).

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

[VampireKB]

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

Как разработчик,вы должны понимать,что ф-ции можно запретить правами доступа.

[Scaramouche]

Как разработчик,вы должны понимать,что ф-ции можно запретить правами доступа.

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

[VampireKB]

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

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

тогда в любой программе куча багов )) Например то что кассир имеет право оплачивать чужие столы без подтверждения официанта ))