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

[Scaramouche]

Выделено из другой темы, после этого сообщения (http://www.carbis.ru/forum/showthread.php?t=7061&p=58420&viewfull=1#post58420) - SH

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



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

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

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


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

[SH]

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


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


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


Чем чище данные , тем проще поймать.
146% :ok: Многие не понимают и рассуждают (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":drinks:

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

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

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

[VampireKB]

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

[Scaramouche]

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

[VampireKB]

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

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

[Scaramouche]

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

[VampireKB]

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

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

[Scaramouche]

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

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

[VampireKB]

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

Люди-идиоты .
Если им надо,они и без,по вашему мнению, багов и\или косяков сделают всё красиво,т.к. начальство всегда тупее персонала(тенденция такая..) .
Как пример она дура(управляющая) в поле скидка ставила не "скидка 5%",а скидку "накопительная" и спрашивала почему у гостей скидка не идёт.

[Scaramouche]

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

[VampireKB]

С вами все понятно. Внедряйте дальше. Убедительная просьба не реагировать на мои сообщения. На этом форуме достаточно компетентных людей, которые мне уже помогли. Ваш флуд мимо кассы.
Вам уже всё на пальцах расписали "что и как,и где посмотреть",но вы ни в какую. так что нам обоим друг про друга всё понятно:)

[SH]

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

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


персонал может сослаться на глюки программы
И тут все равно еще раз скажу: Shouse не глючит. Точка. Наворотить фигни можно, скорее всего, в любой программе. Руки дойдут - проверю, что там происходит в закрытом периоде, любопытно самому.
UPD. Проверил. Да, все, как я и писал - остатки по количеству меняются.

[Scaramouche]

Проверил. Да, все, как я и писал - остатки по количеству меняются.
Я уже запутался. Где остатки меняются, при изменении ед. изм.?
Если да, тогда учет в норме, я просто отталкивался от ваших слов, что остатки не изменяются(количественные) .
Основное правило учета-это замкнутость системы , ничто ниоткуда не возникает и не пропадает.

Shouse не глючит.
Я не говорил, что она глючит, я лишь говорил, что если программа так работает, то что то не ладно. Я sh еще не запускал. А вот в вашем видео от вас же это частенько проскакивало, что очень странно и списывает, куда делся в отчете отказ клиента в отчете в вашем видео я так и не понял в 2 из 3 отчетов он есть , в 3-м нет, но на данный момент это не принципиально. Мне очень понравилось, что вы рассказывали не предвзято, на меня это произвело впечатление.

[SH]

Где остатки меняются, при изменении ед. изм.?
Если провернуть такую операцию по изменению коэффициентов и базовой единицы, то, допустим, если на остатке были яйца в количестве 360шт на сумму 2160 по цене 6 рублей, то станет 9000 ш. по цене 24коп, при этой сумма остатков - 2160руб - не изменится.


Основное правило учета-это замкнутость системы , ничто ниоткуда не возникает и не пропадает.
И это правило в Shouse соблюдается железно.


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


Мне очень понравилось, что вы рассказывали не предвзято, на меня это произвело впечатление.
Спасибо. У меня претензий к комплексу RK+SH очень много :) Просто к другим еще больше.

[Scaramouche]

Если провернуть такую операцию по изменению коэффициентов и базовой единицы, то, допустим, если на остатке были яйца в количестве 360шт на сумму 2160 по цене 6 рублей, то станет 9000 ш. по цене 24коп, при этой сумма остатков - 2160руб - не изменится.
Значит все нормально,хотя и немного странно.

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




Просто к другим еще больше.
Т.е. к отчетности в айке больше претензий? Я просто до бэка все еще никак не доберусь.

[Admin]

такс, давайте этот междусобойчик в отдельную тему, Лех, отклепай ее с нужного момента. А то попкорн засох уже :)

[sibgaba]

SH 5 ??? уже ??

А что, внезапно? :)

Ну пока еще не ага, но к декабрю собираются зарезилить...