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

[SH]

по нему ведутся активные доработки вот уже много лет и ставить его рано

Нет, уже можно. Тут Москва в отстающих, мало активных специалистов. В некоторых регионах уже вовсю ставят только его.

Рарус, в своих бэках прекратил поддержку импорта из РК.

Во как! Вот это новость! Что, "Управление рестораном" больше не поддерживает R-Keeper?

Да там и пользоваться то нечем, собственно. Функционал у программы простейший. А вот настройка ее требует глубоких и специфических знаний. Потому, что используются везде свои протоколы, БД (разные), куча параметров различных, которые зачастую перекрывают друг друга. И, главное все это не документировано. Вся информация разбросана по ftp, форуму, History, а части вообще нет. Звонишь в техподдержку,а там одни говорят оно, потом переключают на других, эти другое говорят-сами уже запутались. Причем сам-то по себе софт не сложный для установки-убивает его запутанность и нелогичность. Не все могут себе позволить заниматься только Кипером (одним им сыт не будешь), а он требует к себе повышенного внимания. Только и жди, что опять какие-нибудь "грабли" вылезут.

Надо принимать во внимание, что это софт с 15-летней!!! историей. Никто не мог в свое время сесть и предугадать все возможные потребности. Разработка велась, обеспечивая совместимость с предыдущими версиями настолько, насколько это возможно. Новичкам сейчас легче, они стоят на плечах гигантов.
Еще раз повторюсь, что сравнивать с современными системами следует именно RK7 - это попытка все переосмыслить заново.

Но при всех упомянутых недостатках и у RK6 есть неоспоримые преимущества. Он таки отлично работает. Из-за широкой распространенности, все баги и фичи становятся известны почти моментально. Если не ставить самые последние билды, вероятность столкнуться с неизвестными граблями стремится к нулю. Доверие к R-Keeper 6 - не в кредит, оно честно им заработано. И на самом деле, ни по одному другому аналогичному софту нет столько доступной информации, в том числе и про грабли.
Это не голословно, мы все время пытаемся заниматься альтернативным софтом. Недостатки есть у всех, и на самом деле, предпочитаешь тот софт, про чьи недостатки известно.

[olegash]

Во как! Вот это новость! Что, "Управление рестораном" больше не поддерживает R-Keeper?

Не совсем правильно выразился. Просто надо было доп. функционал от загрузки в Общепит. Позвонил в Рарус, а мне сказали, что ничего больше доделывать не будем, что есть - тем и пользуйтесь. А загрузку из РК7 они вообще не планируют. Вот и думай, что хочешь.
А по поводу 7-ки, если посмотреть обращения на трекер, баги даже в базовом функционале-это не печатается, это не работает... Да и в 6-ке еще куча "багов" - чего уж говорить про 7. И на фоне всего этого просто убивает отношение UCS к дилерам. Оно очень надменное и грубое. Разработчик всегда прав. Нормальной документации по продукту нет, а мне говорят -вы должны это знать. Я же не экстрасенс. Дайте нормальную тех. документацию-вопросов будет на порядок меньше. А некоторые кадры из UCS (не будем называть фамилий) вообще могут послать подальше. Был прецендент, мне говорят -если вы не можете прочитать информацию на английском, я вам переведу. А там в 7 словах 5 ошибок. И это на тех. сайте UCS. Жесть. Зачем, спрашивается тогда грубить... Да и функционал, даже у 7 насколько мне известно до сих пор нет нормального бронирования столиков-а его многие просят. А KDS, а Delivery - без слез не взглянешь. Надежно он работает если его не трогать и ничем не пользоваться. Как только пытаешься добавить функционал- вылезают "грабли".

[SH]

надо было доп. функционал от загрузки в Общепит. Позвонил в Рарус, а мне сказали, что ничего больше доделывать не будем, что есть - тем и пользуйтесь.

Ну Общепит они вообще неохотно делают, все фишки в "Управлении Рестораном".

загрузку из РК7 они вообще не планируют.

Печально, потому что это хорошая альтернатива Shouse там, где люди вынуждены учиться самостоятельно.

на фоне всего этого просто убивает отношение UCS к дилерам. Оно очень надменное и грубое. Разработчик всегда прав. Нормальной документации по продукту нет, а мне говорят -вы должны это знать. Я же не экстрасенс. Дайте нормальную тех. документацию-вопросов будет на порядок меньше. А некоторые кадры из UCS (не будем называть фамилий) вообще могут послать подальше. Был прецендент, мне говорят -если вы не можете прочитать информацию на английском, я вам переведу. А там в 7 словах 5 ошибок. И это на тех. сайте UCS. Жесть. Зачем, спрашивается тогда грубить...

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

даже у 7 насколько мне известно до сих пор нет нормального бронирования столиков-а его многие просят.

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

А KDS, а Delivery - без слез не взглянешь.

Это да. Но по Доставке уже есть альтернативы.

только пытаешься добавить функционал- вылезают "грабли"

Тут спорно, ибо есть много проектов, где "пытаются намазать слишком маленький кусочек масла по слишком большому куску хлеба".
Надо не забывать, что на большом обЪекте всегда должно быть предварительное изучение требований по автоматизации, и выбор уже поставщика решения, исходя из требований. Но, как правило, стоимость решения, удовлетворяющего всем поставленным условиям, превышает бюджет заказчика, особенно когда сравнивают по цене с R-Keeper (а он, в общем-то, далеко не самый дорогой продукт - так, средненько). И начинается - давайте поставим R-Keeper, там вроде тоже все есть - и начинается натягивание софта на требования. А он тупо не всегда подходит. Как пример: есть Windows-серверы, но они имеют свою четкую нишу. И разумные люди не реализуют любой серверный проект на Windows, только потому что это "тоже сервер, в нем весь функционал заявлен". Да, заказчику не всегда удается обЪяснить, или же у него не всегда деньги есть, но тут уже извините...
В своих рамках R-Keeper работает очень хорошо. Подавляющее большинство примочек было сделано под конкретного заказчика, которого результат удовлетворил. Право слово, по той же Доставке, у меня за десять лет, кажется, три или четыре инсталляции.

[olegash]

SH,во первых, спасибо за конструктивную беседу. За то, что вы ведете нормальный диалог-без наездов и по делу. А то некоторые упрутся, как бараны и начинают твердить, что SH - это круто, а все остальное г...о. Я так не считаю. Один вообще мне сказал, что SH-это стандарт де-факто для некоторых университетов. Я долго смеялся. Этот диалог - лирика, можно долго об этом говорить. Постараюсь в дальнейшем говорить только по делу. Вот по моим вопросам, может кто подсказать, как решить проблему?

[SH]

Такие беседы необходимы! Я считаю, что все недостатки системы должны быть известны. Только так баг превращается в фичу У клиента не возникает чувства неудовлетворенности, что ему "впарили" не работающий как надо, продукт.
Мне очень нравится R-Keeper и StoreHouse, как комплекс автоматизации. Я с удовольствием изучаю все доступные альтернативы. Положа руку на сердце - достойных мало. Но они есть. Главное, повторюсь, принимать осмысленный выбор решения. Этим мало кто, на самом деле, занимается, большинство ставят один продукт и превозносят его до небес. А закзачика слушать надо, и ставить то, что ему нужно, а не то, что ты продаешь.

Вот по моим вопросам, может кто подсказать, как решить проблему?

По существу. Боюсь, что обе проблемы не решаемы, по-крайней мере, стандартными методами! Это действительно особенность софта. Транспорт, в своих разработках по интеграции, мы решаем через введение промежуточной базы. Мы это делаем для других целей, но думаю, что описанную проблему с шифрами такой подход должен решить. Да, это как раз подход не из коробки и может быть не очень дешев. Но - решаемо. Просто у каждого решения есть цена. Она, к сожалению, не всегда очевидна, но если заказчик хочет получить работающее решение - придется смириться и платить.
А вот что делать с редактированием - не представляю. Точнее, опять же, есть простой (и дорогой) вариант - сделать свой Редактор-лайт, чисто для редактирования названий. Кстати, хорошая мысль, может, кто-нибудь и воплотит. По идее, в том же BDE-Editor это должно быть возможно, вопрос только в удачном интерфейсе. Да, это костыль, но увы

[olegash]

Опять не на ту кнопку нажал.

---------- Добавлено в 14:22 ---------- Предыдущее сообщение было размещено в 14:07 ----------

А закзачика слушать надо, и ставить то, что ему нужно, а не то, что ты продаешь.

+100500. Но не все заказчики могут сформулировать тех. задание правильно, а некоторые вещи подразумевают "по умолчанию". Поставили мы клиенту недавно РК6. Ему нужна работа с весовым товаром через штрихкод. Данный функционал есть в программе - есть. А он не работает. Второе и последующее сканирование товара РК воспринимает как штучный. Клиент в шоке-мы тоже. UCS надо отдать должное выложили исправление (пока в тестовой версии, за что им спасибо, но естественно мы не будем его ставить -подождем финальную). А ведь это базовый функционал, а вы говорите 7-ка. 6-ке уж 15 лет, а базовый функционал не работает. т.е все дилеры и клиенты являются бета-тестерами продукта.
По поводу моих вопросов-буду уповать на решение проблем во фронте - это правильней. А то наставишь костылей, не дай бог еще хуже получится. Запрос на форуме UCS есть-правда надежды на рещение мало, а ведь это не сложно сделать.

---------- Добавлено в 14:48 ---------- Предыдущее сообщение было размещено в 14:22 ----------

Еще по поводу костылей.
Использовали купоны, вылезла такая проблема, когда выгружаются нулевые суммы продаж.
Вот проблема:
файл ARcheck.dbf
Поле PAYSUM. Тип этого поля число 16.6 (16 знаков в том числе 6 знаков после запятой).
А содержится там значение не совподающее с типом, не 6 знаков после запятой, а вот такое: ".7105427358E-14"
Соответственно 1С воспринимает его как 0.71, а не как 0.000000000000007105427358
Значение 0.000000000000007105427358 при типе число(16.6), должно быть такми 0.000000, а не таким 0.000000000000007105427358 или таким .7105427358E-14.
Сколько таких проблем еще вылезет-неизвестно... Очень много внимания надо уделять RK6-это не правильно. Данные проблемы должен решать разработчик. Эту, кстати решили в последней версии. Да и вообще таких проблем не должно быть-это "детские ошибки". Фундамент изначально должен быть спроектирован правильно. Поэтому, я думаю и решено было написать программу с нуля (RK7). Надо бы внедрять его, но страшно пока. Как бы клиенты не разорвали. Да и загрузку для стороннего бэка придется писать самим, т.к. использовать SH не хотим-не нравится он, да и дорого очень для такого функционала. А это все время на создание и тестирование.

[SH]

А ведь это базовый функционал

Не согласен. Такого не было никогда, это магазинный функционал, который многие в последнее время прикручивают к фаст-фуду. Удобно, согласен - но это как раз из тех вещей, что 15 лет назад нельзя было предусмотреть.

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

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

Я знаю только одну альтернативу с таким же функционалом - это "1С-Рарус: Управление рестораном". Стоит оно столько же. Недостатки у него тоже есть. Это мое поле, я тут точно знаю, что говорю Хаус стоит своих денег, Общепитом после него реально невозможно пользоваться, не потому, что все по-другому, а потому, что не хватает возможностей.

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

загрузку для стороннего бэка придется писать самим ... А это все время на создание и тестирование.

Ну, мы можем написать надо только понять ТЗ и рынок сбыта, возможно, ценник в итоге будет разумный.

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

Очень много внимания надо уделять RK6-это не правильно. Данные проблемы должен решать разработчик.

Разработчик, вообще говоря, никому ничего не должен. Он делает продукт, Вы решаете, приобретать его или нет. Пока разработчику достаточно довольных клиентов, он может игнорировать недовольных.
Это же бизнес. Если решение вопросов, нужных 1% или даже 5% клиентов стоит столько же, сколько 100% или 95% клиентов - такие вопросы могут быть не решены никогда, ибо нерентабельно.