Консумация???

[SH]

ЭЭэ, в кубах квадратики подтащить?

В кубах можно многое, но вот на конкретно этом примере видно, что не все.

из штатных средств

Из штатных средств используем только transp32 А дальше делаем, что хотим. Так что можем сварганить в общем-то любой отчет из данных, имеющихся в RK6. Если кому надо будет - обращайся.
Кстати, раз уж речь зашла - поделись, есть ли аналог transp32 в семерке? Как-нибудь вообще со стороны данные можно выдрать?

[BoniX]

Конечно обменов в разные базы полно. sql (microsoft, firebird), и прочая, гляну точнее отпишусь обо всем спектре обмена )
Но вообще зачем? Если в семерке мы рисуем абсолютно любые кубы (в отличие от пяти (или сколько их там) стандартныех в шестерке) выбирая поля любых таблиц. На основе кубов строится любой отчет - экранная/печатная форма на кассе в пределах текущей смены, экранная форма кубов для менеджера с любыми фильтрами...

[SH]

Но вообще зачем?

Например, если нужно составить консолидированный отчет с данными одновременно из R-Keeper и 1С. Отчеты R-Keeper же не вещь в себе, это всего лишь источник данных. Их потом хочется использовать в общем анализе деятельности предприятия.
Ну и вдогонку - а в семерке поставленная в топике задача как решается?

[BoniX]

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

Приложение R-Keeper v7 позволяет осуществить расчет величины консумационного вознаграждения (и начисляемых бонусов) различными способами.

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

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

Значение консумации (бонуса) определяется в приложении менеджера. Если используется режим с Исп. Правил расчета, оно рассчитывается на основании правил расчета в справочнике Типы Цен на странице Консумация (Бонусы) (см. п. Свойства Правила расчета). Правило расчета значения консумации (бонуса) может представлять собой формулу или задаваться непосредственно значением - в одноименном свойстве правила расчета.

Если используется режим без Исп. Правил расчета, значение консумации (бонуса) вводится в свойстве Консумация (Консумация (%)) или Бонус (Бонус (%)) соответствующего типа цены в справочнике Меню. Блок схема расчета значения консумации (бонуса). (см. Схема расчета значения консумации и бонуса).

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

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

База консумации (бонуса) - это величина, от которой берется процент консумации (бонуса). В зависимости от расстановки соответствующих флагов (свойства правила расчета Чистая цена и Скидки / Наценки), база консумации (бонуса) представляет собой: «цену блюда без учета модификаторов», «цену блюда с учетом модификаторов» или «цену блюда с учетом модификаторов и с учетом скидок / наценок». Результат расчета процента от базы консумации (консумации), дает сумму консумации (бонуса).

Если консумация представляет собой фиксированную сумму, а не процент, сумма консумации - это произведение значения консумации на количество порций блюда.

Если тип цены использует режим «Без использования правил расчета» и выставлен флаг Консумация - Процент (Бонус - Процент), можно определить значение консумации (бонуса), которое по умолчанию будет подставлено в свойство блюда Консумация (%) Бонус (%) в справочнике Меню при создании новых блюд.

Если у блюда несколько консумантов, сумма консумации делится на их количество.

От полученной расчетной суммы вычисляется процент консуманта. Полученный в результате этого действия результат - это сумма выплаты консуманту (консумантам). По умолчанию (без определения значения в свойстве консуманта Процент - используется значение 100 %).

kons.JPG

Честно говоря, нужно пробовать, ибо таким не занимался. ) Но вот я бы обобщенно попробовал так:
Делаем классификацию блюда "Сомелье" (типа свободных групп категорий блюд, только в блюде можно выбрать из каждой группы классификацию (или наоборот, оставить пустой), а не одна, как в рк6. Естественно чем больше групп тем больше комбинаций.) Зато как гениально режутся на несколько фр блюда, сказка
menu_klass.JPG


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

[BoniX]

Да, касательно обмена скрин:
ex_bd.JPG
А еще, касательно "рукастых" товарищей с головой (к сожалению не настолько силен в программинге и надобности уж такой экзотики не было) - есть скрипты.
Которые позволяют сделать когда угодно и что угодно кому угодно в любую, так сказатЬ, таблицу.

[SH]

Бум знать.

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

Специально уточню. Это касается и открытых столов в смене? Или только отчетов?

[BoniX]

Не, скрипты ведь как раз вяжутся к кассовой части, обработчики на прокатывание карты, заход в заказ и т.д. например:

Версия для печати
Скрипт для немецкой сети ресторанов Kochloffel. Когда пользователь вводит сумму валюты к оплате и жмет на кнопку "Оплатить", система проверяет, чтобы введенная сумма была больше или равна сумме заказа (то есть фактически запрещаются комбинированные оплаты заказа).
Скрипт прикрепляется к событию OnBeforeCheckViewEdit компонента CheckView формы редактирования заказа (в случае немецкого контракта - редактирования заказа в режиме быстрого чека).

Текст скрипта:
view sourceпечать?
procedure CheckViewOnBeforeCheckViewEdit(Sender: TObject; AEditType: TEditType; AObjectBef, AObjectAft: TObject; var AAllow: boolean; var AMessage: string);
var i: integer;
it: TCheckItem;
begin
if not SYS.ObjectInheritsFrom(AObjectAft, 'TPayLine') then Exit;

// Проверяем, что в заказе нет платежей другими валютами
// (сдачу можно давать только этой же валютой)
for i := 0 to RKCheck.CurrentOrder.Sessions.LinesCount - 1 do begin
it := RKCheck.CurrentOrder.Sessions.Lines[i];
if SYS.ObjectInheritsFrom(it, 'TPayLine') then begin
if TPayLine(it).Sifr <> TPayLine(AObjectAft).Sifr then begin
AAllow := False;
AMessage := 'Сдачу нужно давать той же валютой, что и основной платеж';
Exit;
end;
end;
end;

// Запрещаем вносить платеж, если он меньше суммы заказа
if (TPayLine(AObjectAft).BasicSum > 0)
and (TPayLine(AObjectAft).BasicSum < RKCheck.CurrentOrder.UnpaidSum)
then begin
AAllow := False;
AMessage := 'Нельзя платить меньше суммы заказа';
end;
end;

[SH]

Класс!