Редактирование отчетов Report32 или как добавить свои данные в отчет (FastReport)

[mnekin]

Есть задача по отчетам.
Сервер 6,9708
Менеджер 6,96
В ресторане имеется наценка "Обслуживание +15%", т.е. в этой наценке сидит зарплата официанта.
Например:
8% официанту + 7% ресторану = Обслуживание +15%

Так вот, официанты есть новички с зарплатой 3%, а есть гуру официанты с зарплатой в 8%. Сейчас это считается вручную, но т.к. официанты получают зарплату каждый день, то нужно тут как-то автоматизировать процесс и вывести на печатную форму суммы зарплат официантов.

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

Я посмотрел формы в RKCLIENT - тут я думаю не получиться вытащить какие либо поля, в формах просто катастрофически мало переменных.
Будем смотреть в сторону Отчетов по закрытым дням, там FastReport 4,12. Ну нам это подходит, можно наваять что угодно. Делов-то на пару дней (я не супер программист, но отчеты и формы под Shelter v2 написал штук 10, был грешок и на Shelter1 и на SH4). Смотрим отчет Скидки по официантам, вот на основе него и будем писать отчет.
Но тут встал в ступор, т.к. я ни фига не вижу откуда подцепляется DataSet1 и какие поля доступны этому Dataset1, видать зашито в DLL или EXE, да и описания этого отчета я не нашел. Это-то и осложняет немногим задачу, т.к. придется организовывать свои подключения к необходимым Paradox базам и вести выборку уже в форме, костыль, но реализуемо.

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

[SH]

1. Я бы поковырял консумантов.
2. Если писать свое, я бы писал на основе oldres или dbf.

[mnekin]

1. Я бы поковырял консумантов.

Не совсем понял, как это реализовать в RK6, если процент у официантов разный?

2. Если писать свое, я бы писал на основе oldres или dbf.

Так и будет, пишется на основе отчета "Скидки по официантам" где все необходимые данные есть кроме процента официанта, а он находиться в файле personal.db
А вот oldres, нам тут не нужен.

[SH]

Не совсем понял, как это реализовать в RK6, если процент у официантов разный?

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

А вот oldres, нам тут не нужен.

А я бы взял dcheck со скидками, разобрал бы его, по check посмотреть официанта, по db разобрать шифры.

[mnekin]

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

Тоже были попытки, но ничего толкового в этом не нашел.

А я бы взял dcheck со скидками, разобрал бы его, по check посмотреть официанта, по db разобрать шифры.

Не совсем правильное решение, dcheck по умолчанию лежит на RK сервере в oldres, не всегда доступен для менеджерского компа, если конечно его специально не копировать из ENDDAY на менеджерский при закрытие дня, а это дополнительные костыли.
И опять же нам понадобиться personal.db из папки RK6/DB или DATABASE

[SH]

а это дополнительные костыли.

Как бы да, но этими костылями постоянно пользуемся.
Более того, при недоступности oldres часто прописываем батник при закрытии дня, который копию endday делает чисто на всякий случай, для удобства.

[sibgaba]

Консумация в данном случае не вариант.

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

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

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

Если включить смекалку, то есть один вариант

Заводя персонал, в поле ФИО, можно так же забить одну цифру, которая равна проценту данного официанта:
Иванов 5
Петров 7

Далее берем подходящий отчет Кипера (мне кажется вам подойдет Другое - Скидки по официантам)
1. Средствами FastRep парсим ФИО, что бы выделить из него ставку. Запоминаем ее в некую переменную Х.
2. Для, всех строк со скидками, название которых равно "Обслуживание +15%", добавляем поле "Зарплата" и высчитываем его значение по формуле: Наценка/15*Х
3. Для красоты, все строки скидок значение которых не равно "Обслуживание +15%" можно скрыть в печатной форме.

Профит!

[mnekin]

Заводя персонал, в поле ФИО, можно так же забить одну цифру, которая равна проценту данного официанта:
Иванов 5
Петров 7

Далее берем подходящий отчет Кипера (мне кажется вам подойдет Другое - Скидки по официантам)
1. Средствами FastRep парсим ФИО, что бы выделить из него ставку. Запоминаем ее в некую переменную Х.
2. Для, всех строк со скидками, название которых равно "Обслуживание +15%", добавляем поле "Зарплата" и высчитываем его значение по формуле: Наценка/15*Х
3. Для красоты, все строки скидок значение которых не равно "Обслуживание +15%" можно скрыть в печатной форме.

Профит!

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

Тут надо отдельным DATASET подключать базу personal.db

[sibgaba]

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

Дело конечно хозяйское... Через поле "Пейджер" тоже не очень удобно будет, система будет постоянно ругаться что есть 2 работника с одним пейджером (не критическая ошибка). Можно через группы доступа мутить (их там как раз 8), но они хранятся в БД в виде Byte, а с ним в FastRep работать не удобно будет.

Если не хотите в ФИО писать процент - зашифруйте его:

А = 3
Б =7

Получится :
Иванов А
Петров Б

[mnekin]

Дело конечно хозяйское... Через поле "Пейджер" тоже не очень удобно будет, система будет постоянно ругаться что есть 2 работника с одним пейджером (не критическая ошибка). Можно через группы доступа мутить (их там как раз 8), но они хранятся в БД в виде Byte, а с ним в FastRep работать не удобно будет.

Оп-па, вот об этом не подумал, спасибо за подсказку.

Если не хотите в ФИО писать процент - зашифруйте его:

А = 3
Б =7

Получится :
Иванов А
Петров Б

Вот для чего нужен форум, одна голова хорошо, а много лучше.
Этот вариант будет поинтереснее.