Выскажите свое мнение про Рарус Управление рестораном 3 и Рарус Общепит 8 #527650

сабж

Рарус Общепит 8 больше нет

а это что?

Я так понимаю, вы знакомы с этой отраслью не по наслышке. Хотелось бы услышать ваших советов по этой теме.

хороший рарус - мертвый рарус. я в их поделках устал косяки выгребать на ровном месте.

На базе бухии лучше не брать. Внимательно смотрел только 2 версию на 7.7. Ни остатки, ни себестоимость считалась не правильно. Остальные версии не понравились своей неуклюжестью.

Хорошо, Асторовский общепит лучше?

Я предопчитаю брать типовую конфу- проблем быть не должно. Нет ни багов в релизе (их минимум) и нет зашифрованных модулей.

Любую программу лучше проверить на тестовых данных (еще лучше на реальных и сравнить). Иногда делал прогонку на данных. Проверял: приход, калькуляции, марочные отчеты, списания, питание сотрудников, инвентаризация, отчеты по продажам, валовой прибыли, товарные отчеты, оборотные ведомости по складу. Как считаются специи: сахар, соль, перец. Проверить расчеты по вложенным калькуляциям (п/ф и т.д.). Проверить, формы калькуляционной и технологической карты. Проверить на наличие скрытых механизмов превращения одного ингредиенты в другой.

Ни то ни другое к Рарусу не относится. )

это 1С: Общепит 8 совсем другой продук (другая схема лицензирования и платного сопровожденияя

Ну дык и я про тоже.

у Камина хорошие вещи для общепита - погляди в эту сторону.

Посмотрел вторую версию (демо). Специи считаться не будут. Многие расчеты по вложенным калькуляциям (КК) будут давать ошибки. Нет вида номенклатуры (как компоненты бум учитывать?). Нет дополнительных единиц измерения. Блюда ведутся справочником, а не документами (КК - это документ, и на одно и то же блюдо может быть несколько карт, но это придирка).

У Камина только производственный учет.

курим вот это

Достойная вещь?

Уже смотрю ) Пока благоприятное впечатление. Но есть придирки: 1) аналоги в базе. - с ними нужно быть предельно осторожным, но лучше без них. 2) "коэффициенты естественной убыли" - нельзя отдавать программе расчет норм 3) "возвратные отходы" - это скорее актуально для "комбинатов питания" 4)  можно все же в документах с номенклатурой сделать точность не 3 знака, а 4. 5) Категории - это конечно хорошо для номенклатуры, но, боюсь, маловато. Есть виды номенклатуры, которые по разному обрабатываются в учете. Дальше только прогон и проверка.

Я так понимаю все против решение где и УУ и БУ в одной базе?

Интересная штуковина. Правда, без просмотра демки не взял бы. + Со специями так и не понял, что там намудрили. Отдельный учет - э то хорошо, но настораживает фраза: "т.е. когда при выпуске продукции не происходит списание специй и солей по партиям товаров" из:

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

1 - можно не использовать 2 - можно не использовать 3 - можно не использовать 4 - для чего 4 знака? 5 - есть типы номенклатуры (товар, услуга, тара) и типы товаров (Товар, Полуфабрикат, Продукция, Специя, Соль)

1-3 не так, нужно: нельзя использовать ) 4 - точность. Три знака мало. 5 - где компоненты, или они в карты не входят и в расчетах не участвуют? Отдельный учет по соли и специям очень не есть гуд.

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

Ок.

Под компонентами что подразумевается? Модификаторы или что-то другое?

Нет. Ингредиенты, которые достаются условно бесплатно: лед, вода и т. д. В картах они указываются и технологи в своих расчетах их учитывают, но в движениях продукции они не участвуют.

+ в движениях по номенклатуре не участвуют.

Как с отрицательными остатками боритесь, когда по нормам закладки должно списаться больше, чем есть на складе?

В карточке продукта у номенклатуры флаг "Не учитывать"

Ок )

Это разве должно так быть, если нет на складе и списывать? На текущий момент ведется контроль остатков и списать в минус система не даст.

Да, причин может быть множество: 1) Ошибка в расчетах технолога 2) несоблюдение технологии 3) отдельно выделю недокладку в блюда - это приводит к излишкам (плюсам по складу) и минусам по учету. Часто этой дыркой пользуются и воруют. 4) Привезли товар другого качества. 5) Ошибки ввода данных в систему.

А что в этом случае предполагается делать пользователям?

Или делать оприходования или поступления, или исправлять ошибки. Если у Вас есть предложения, можем их рассмотреть

С оприходованием поступления возникает проблема: на основании чего мы это поступление делаем, если основания нет - возникает фиктивная операция искажающая учет. Я реализовывал это несколько иначе - закрывал возникающие минусовые позиции в ноль, ну и вел их отдельный учет, но в большинстве своем бухгалтера такую штуку не принимали. Думаю, в определенном роде это решение оптимально, т. к. позволяет 1) фиксировать такие спорные случаи по списаниям и их потом уже анализировать. 2) Не заниматься исправлениями "задним" числом, если, конечно, не ошибки ввода. 3) Списание не стопорится и мы можем посмотреть остатки с учетом этих минусов. 4) Если сравнивать с другими системами, где такого контроля нет, то мы можем получить более адекватную картину по складу (идеальных норм не будет никогда) и его контролировать (делать инвентаризацию).

+ ПС Те бухгалтера, которые не принимали - искали потом работу )

+ Изменения "задним" числом калькуляций не допускалось (кроме явных описок и ошибок). Это необходимо было для контроля работы сотрудников заведения начиная от технолога, шеф-повара, заканчивая управляющим, поварами, официантами.

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

Ну и еще: 5) Сокращались немного трудозатраты по учету. Учетчикам не приходилось думать, как их закрывать, а только искать причину у себя. + 6) Забыл еще пересортицу добавить. Есть еще несколько таких причин, но они носят уже более частный характер.

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

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

Об этом думали, но почти сходу отказались. Кто будет контролировать этого человека, который будет говорить системе от какого продукта можно отказаться, а от какого нет? (вопрос риторический :-) )

Согласен, но опять возникает вопрос применимости данного варианта для тиражного решения. Вообще продукт развивается и открыт для конструктивных предложений ;-)

+ Тут есть несколько моментов. Т. к. по сути меняется технология производства, то должна быть пересчитана калькуляция на блюдо. В одном заведении, где такое допускалось придумал костыль для быстрого ввода таких калькуляций, но это только как исключение (наценка была предостаточной, что бы идти на поводу у гостей :-) )

Да. Наш продукт отдельно никогда не продавался, а только входил, как часть консалтинга :)

а что скажете о трактир от софт баланс?

О, вспомнил. Есть несколько вещей полезных: 1) Можно ли делать перемещение и списание по блюдам? 2) Можно ли посмотреть разблюдовку списания - посмотреть на сам расчет списанных количеств ингредиентов исходя из закладки в блюдо?

Слышал только положительные отзывы. Их продукты давно на рынке.

1 - имеется ввиду перемещение ингредиентов, необходимых для приготовления блюд? Если это, то в данном случае используются механизмы ввода на основании и заполнения из документов. 2 - сейчас точно не могу сказать (нет под рукой программы), но по-моему есть такая печатная форма или отчет.

Ок, спасибо.

Да. Что бы не казалось все так радужно с тиражными системами сделаю несколько замечаний. Обычно, когда открывают новый ресторан или автоматизируют уже работающий ищут автоматизированную систему управления для них. Заказчиком может быть учредитель, для снижения (как он думает) производственных издержек. У него возникает картинка в уме (логичная такая), что если поставить такую систему и в ней считать все, то можно увидеть и проконтролировать затраты. При этом собственно в учете и в его особенностях он (учредитель) не разбирается. И учет снова ведут бухгалтера, которым важна картинка, или производственники, которым вообще ничего в учете не нужно, ну может разве что кроме тех. карт и калькуляционных карт (но это всего лишь общепитовские формы, нужны они им для проверок СЭС, но не для учета). С другой стороны заказчиками могут выступать собственно бухгалтера (реже правда, им это не нужно). Они хотят от систему не учета (еще раз: интерес бухгалтера облегчить свою работу по производственному документообороту и регламентированной отчетности), а красивые отчеты и красивую картинку, при этом, что там собственно с учетом в подавляющем большинстве случаев (в общепите) во внимание не принимается. Именно из таких представлений (хотелок) потребностей и строются тиражные учетные системы для общепита. Более четко их ограничу. Основные минусы тиражных систем (подавляющего их большинства и на базе 1С и не на базе 1С): 1) Построение красивой картинки (можно посмотреть посты и ; "минуса" возникают ежедневно! и упускать их из внимание нельзя, как и править задним числом движение ингредиентов с нормами) 2) Попытки автоматизировать расчет нормы списания таких как:   г) Коэффициенты отходов по продуктам Есть, правда, пара систем, где пункт 1 учитывается, но насколько полно не знаю, не видел (сужу по описаниям), а потому и не буду их упоминать :)

Вот интересная система: