Блюда не редактировать, папки не удалять...

[olegash]

говорим мы клиентам при установке р-кипер. Ибо, если отредактируете более 3 символов -получите новое блюдо в бэке, а если удалите папку - вообще белиберда получится, т. к. р-кипер, оказывается не поддерживает ссылочную целостность данных и при удалении папки, можно запросто получить ситуацию, когда для блюда - родителем является блюдо. Нормальный бэк (не SH, т. к. нему приделали костыль) это не понимает (и правильно делает, такого быть не должно). А с редактированием блюд, вообще непонятно почему при редактировании более 3 (почему не 2 или 4) символов кипер считает это новым блюдом? По логике во всех аналогичных программах, редактирование существующего блюда не добавляет новую позицию, а добавляет ее при нажатии на кнопку "добавить" и это логично. Разработчики решили по другому и теперь это очень мешает работе наших клиентов. Это только у меня так? Как вы решаете данную проблему (или ее нет на самом деле)?

[SH]

почему при редактировании более 3 (почему не 2 или 4) символов кипер считает это новым блюдом? ... Как вы решаете данную проблему (или ее нет на самом деле)?

Ее нет. Это как раз из серии "это не баг, это фича". Особенность софта. Уж кому в голову пришло, что надо именно так - покрыто мраком лет. ОбЪяснение найти можно: клиенты любят завести "Салат Цезарь", а потом переименовать его в "Салат Греческий". Сделали хоть какую-то защиту от дурака, не позволяющую вот так в лоб одно блюдо заменить другим.

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

А вот это ерунда. Уникальность шифров обеспечивается файлами menu_.db и компанией прочих файлов с подчеркиванием в конце имени. Ситуация, когда шифр удаленного блюда присваивается новому, возможна только в том случае, если поврежден, или удален, или очищен, или заменен файл с перечнем удаленных позиций. Но если такая ситуация есть - не надо на кипер наговаривать, повредить можно любую БД.

[olegash]

Сделали хоть какую-то защиту от дурака, не позволяющую вот так в лоб одно блюдо заменить другим.

Но все наши клиенты в голос говорят, что это очень неудобно (после дркгого софта). Пример:
Если клиент исправит блюдо "Обед №1" на "Обед №2" (подразумевая новое блюдо) - Sifr не меняется. А вот если он исправит его на "Комплексный обед №1" (подразумевая старое блюдо) - Sifr меняется. Где логика?. Да и бывает, часто еще и работать не начали-только меню завели, а уже куча блюд не нужных в бэке (потому, что исправляют).

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

При удалении группы может произойти такая ситуация - они не сбрасываются в _menu. Пример:
в R-Keeper v6 заводим папку "Дополнительно" ей присваевается шифр 235. Заводим в ней новое блюдо "Контейнер" ему присваевается шифр 236 родитель 235.
Удаляем блюдо контейнер (шифр 236). Удаляем папку "Дополнительно" (шифр 235).
В файл Menu_ скидывается только блюдо контейнер (шифр 236, родитель 235). Папка "Дополнительно" (шифр 235) в Menu_ НЕ СКИДЫВАЕТСЯ.
Далее заводим новое БЛЮДО "Контейнер2". Ему присваевается шифр 235.
И получается что блюдо "Контейнер" (шифр 236, родитель 235) из Menu_ находится внутри не папки "Дополнительно" (шифр 235), а внутри блюда "Контейнер2" (шифр 235).
При загрузке в 1с соответственно возникают ошибки.

[Andy]

IMHO
на данный момент ситуация лечится просто - это не клиент выбирает нас (r-keeper, обслуживание, установку, сопровождение , консультации и.т.д.), а мы выбираем клиента (вменяемый, платежеспособный, в меру требовательный и.т.д.)

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

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

[olegash]

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

[SH]

Надо придерживаться общепринятых стандартов

В Москве как-то так сложилось, что кипер и является стандартом.

На рынке, сейчас появляется много аналогичных систем и если не прислушиваться к клиенту "Р-кипер" скоро перестанет быть именем нарицательным.

Согласен. Но Вы с чем сравниваете новые системы? С RK6? А надо - с RK7.

все наши клиенты в голос говорят, что это очень неудобно

Выбирая софт, выбираешь и его фичи. Мне тоже многое не нравится в другом софте после кипера. Приходится привыкать к особенностям, если этот софт тебе нужен. А идеального варианта нет.

При загрузке в 1с соответственно возникают ошибки.

Скажем так - а кто обещал беспроблемную работу со сторонним софтом? И главный вопрос - при выгрузке в dbf ошибка сохраняется?

для такого слабого функционала надо

Это просто Вы не всем пользуетесь...

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

Как ни странно, при этом специалистов по такому вроде бы трудному софту в Москве в разы больше, чем по вроде бы легким 1с-base системам.

Честно скажу - меня не все устраивает в кипере. Но еще раз повторюсь: идеального софта нет. Пока, по-крайней мере, нет. Претензии можно предЪявить ко всем. А особенно - при переходе с другой системы, где уже ко многому привык. Будем честны - никаких стандартов на данный момент не существует. Любой софт сейчас на рынке в нашей области - сам по себе и на других не похож. Да сколько криков было хотя бы в рамках перехода с SH3 на SH4... Люди не любят учится, они в массе консервативны и хотят пользоваться привычными инструментами. Когда инструмент - не самоцель, а средство, то винить их в этом трудно... Но опять же - в такое время живем, идеала нет. И если бизнес или владелец диктует смену софта - подчиненный персонал обязан взять под козырек и переучиться, просто потому, что является наемным персоналом.

Andy, +1 по всем пунктам.