Аргументы iiko против R-Keeper: ну полная лажа

[Admin]

Здесь вопрос не в деньгах,

У вас в воронеже рестораторы другие чтоле? КМК у вас мало опыта и вы достаточно молоды и поэтому воспринимаете мир пока с другой точки зрения. Для вас нужно чтоб все было правильно, если система может, то ее нужно использовать. И вот поэтому у вас и дос набор батников, и вайн теперь костыль. Юношеский максимализм так сказать. Это хорошо, помогает развиваться.

Для заведений быстрого обслуживания-это не реально.

Реально. Т.к. там обычно не одна касса, поэтому этот критерий сведен к минимуму. За 10 лет не видел ни одного закрывшегося заведения, пока не работала касса.

И таки да - возвращатемся к теме топика, а то опять понесло.

[Scaramouche]

Реально. Т.к. там обычно не одна касса, поэтому этот критерий сведен к минимуму. За 10 лет не видел ни одного закрывшегося заведения, пока не работала касса.

Я же нигде не утверждал, что заведение закроется, но то, что продажи либо ополовинятся, либо выручка упадет на две трети в день. Основная выручка быстрого питания делается в короткий срок в обед, и если техника не будет работать, потери могут быть такие, как я перечислил выше. В столовых больше одного рабочего места иметь не всегда реально не только по финансовым причинам, просто иногда банально негде. Поэтому горячий резерв-это очень актуально (может не во всех точках,но убеждать клиента я считаю стоит).
Я сам выступал и на стороне заказчика по другому софту,и хочу сказать, что внедренцы одинаково наплевательски относились к своей работе (те с кем я сталкивался), причем не важно местный он или аж из самого дефолт-сити. Никто не заинтересован в результате, всем тупо нужна подпись в акте приемке, а там хоть трава не расти. Вот как раз от таких внедрений у людей и складывается плохое впечатление о самом продукте.
А насчет вайна, можно зная размер ... руки измерять длину, но сподручней как то рулеткой.
Извиняюсь за оффтопик.
Возвращаясь к теме. По Киперу 7 очень большая проблема найти инфу, не то, что его попробовать. И я так и не понял в актуальном хаусе при изменении к/карты задним числом изменяется ли списание автоматически или нет?

[SH]

Я крепостной, мне не выгодно делать плохо, я всегда под боком.

Это заблуждение. Многие, напротив, демонстрируют свою незаменимость. И, что характерно, многим начальникам это нравится больше, чем плюющий в потолок "бездельник", у которого все сделано хорошо.

---------- Добавлено в 01:24 ---------- Предыдущее сообщение было размещено в 01:23 ----------

таки да - возвращатемся к теме топика, а то опять понесло.

Забей, я потом тему почищу.

---------- Добавлено в 01:27 ---------- Предыдущее сообщение было размещено в 01:24 ----------

По Киперу 7 очень большая проблема найти инфу, не то, что его попробовать

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

я так и не понял в актуальном хаусе при изменении к/карты задним числом изменяется ли списание автоматически или нет?

В хаусе нельзя изменить к/карту, если по ней сделано списание. Это фича.

[leopold1984]

В хаусе нельзя изменить к/карту, если по ней сделано списание. Это фича.

Фича? УУУУУУ
Как все запущено.
Хотя этот спор из области теологии.

[SH]

Хотя этот спор из области теологии.

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

---------- Добавлено в 03:02 ---------- Предыдущее сообщение было размещено в 02:57 ----------

leopold1984, кстати, что в iiko нет контроля (протокола), кто и когда делает изменения в технологических картах - это правда?

[Scaramouche]

В хаусе нельзя изменить к/карту, если по ней сделано списание. Это фича.

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

[leopold1984]

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

---------- Добавлено в 03:02 ---------- Предыдущее сообщение было размещено в 02:57 ----------

leopold1984, кстати, что в iiko нет контроля (протокола), кто и когда делает изменения в технологических картах - это правда?

Нет.

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

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

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

[Roman Avramov]

Приветствую всех на форуме.

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

Ситуация следующая. В OLAP-отчетах iiko доступны для выбора две колонки, относящиеся к типам оплат - "Тип оплат (комб.)" и "Тип оплат". Они ведут себя идентично для чеков, оплаченных одним типом оплаты. Для комбинированных типов оплат в одном чеке (часть наличными, часть картой) они ведут себя по-разному: первая колонка отображает тип оплат в виде "Наличные; Карта", а добавление второй колонки приводит к разделению чека по типам оплат по разным строкам отчета. Если в отчет по себестоимости добавлена колонка "Тип оплаты", то себестоимость нужно как-то искусственно разносить между частями чеков, оплаченными разными типами оплат. Наша система этого не делает и показывает одинаковую себестоимость для частей чека, оплаченных разными типами оплат. Это хорошо видно на скриншоте. В нижней строке эти задвоенные себестоимости суммируются, что приводит к некорректному результату.

При группировке по колонке "Тип оплат (комб.)" разделения чека не происходит, и мы порекомендовали воспользоваться этой колонкой - если такой отчет все же нужен. Мне сложно предположить, зачем он нужен по бизнесу в таком же виде. Сам Семенов пишет, что этот отчет случайно сконструировала его управляющая. Да, в iiko можно сконструировать некорректный OLAP-отчет, или неправильно интерпретировать его цифры, если ты не понимаешь, что делаешь. Универсального правильного алгоритма разнесения себестоимости по типам оплат нет. Здесь хорошее обсуждение этой темы. В ближайшей версии мы постараемся снизить вероятность того, что пользователь "выстрелит себе в ногу". Вероятнее всего, мы ограничим в OLAP-отчетах возможность одновременного добавления полей "Себестоимость" и "Тип оплаты".
Про нашу скорость реакции - отдельная тема. Мы дали ответ в тот же день, когда нам предоставили подключение к базе клиента. Переписку на эту тему можно почитать здесь.

Всего неделю не отслеживал, а тут такое.
Скажу пару слов про пост в ЖЖ. Судя по истерике человек далек от ИТ,чтение инструкций, а затем лишь использованию программы видимо считает, что это удел трУсов. Поливание грязи на все ПО(которое было заявлено в посте) кроме кипера наводит мою паранойю на мысль, что данный пост поход на заказной.

Я немного общался с Андреем Семеновым ранее. Не думаю, что это заказной пост. У него действительно есть проблемы, но они явно не вселенского масштаба. Если интересно, что у него было, но лень копаться в 200 с лишним комментариях, я могу сбросить сюда сводку.
Про то, что у него стало хорошо, Андрей вряд ли напишет.

[Scaramouche]

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

А почему нельзя было разбивать себестоимость пропорционально типам оплаты?В примере это было бы 50%/50% Возможно по факту это было бы не корректно, но цифры бы сходились и не было бы такого непонимания и обвинений в ошибках. Лично меня без пояснений данный скриншот тоже бы прилично озадачил.

Если интересно, что у него было, но лень копаться в 200 с лишним комментариях, я могу сбросить сюда сводку.
Про то, что у него стало хорошо, Андрей вряд ли напишет.

Да, было бы очень кстати, так как по ошибкам в айке информации по нулям.

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

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

А лицо, которое закрывает период и редактирует карты одно и то же?

[sibgaba]

Нет.

Для ясности:
Нет - значит "Не правда, протокол изменений есть" или
Нет - значит "Нет протокола изменений"?