Просмотр полной версии : Блюда не редактировать, папки не удалять...
говорим мы клиентам при установке р-кипер. Ибо, если отредактируете более 3 символов -получите новое блюдо в бэке, а если удалите папку - вообще белиберда получится, т. к. р-кипер, оказывается не поддерживает ссылочную целостность данных и при удалении папки, можно запросто получить ситуацию, когда для блюда - родителем является блюдо. Нормальный бэк (не SH, т. к. нему приделали костыль) это не понимает (и правильно делает, такого быть не должно). А с редактированием блюд, вообще непонятно почему при редактировании более 3 (почему не 2 или 4) символов кипер считает это новым блюдом? По логике во всех аналогичных программах, редактирование существующего блюда не добавляет новую позицию, а добавляет ее при нажатии на кнопку "добавить" и это логично. Разработчики решили по другому и теперь это очень мешает работе наших клиентов. Это только у меня так? Как вы решаете данную проблему (или ее нет на самом деле)?
почему при редактировании более 3 (почему не 2 или 4) символов кипер считает это новым блюдом? ... Как вы решаете данную проблему (или ее нет на самом деле)?
Ее нет. Это как раз из серии "это не баг, это фича". Особенность софта. Уж кому в голову пришло, что надо именно так - покрыто мраком лет. ОбЪяснение найти можно: клиенты любят завести "Салат Цезарь", а потом переименовать его в "Салат Греческий". Сделали хоть какую-то защиту от дурака, не позволяющую вот так в лоб одно блюдо заменить другим.
если удалите папку - вообще белиберда получится, т. к. р-кипер, оказывается не поддерживает ссылочную целостность данных
А вот это ерунда. Уникальность шифров обеспечивается файлами menu_.db и компанией прочих файлов с подчеркиванием в конце имени. Ситуация, когда шифр удаленного блюда присваивается новому, возможна только в том случае, если поврежден, или удален, или очищен, или заменен файл с перечнем удаленных позиций. Но если такая ситуация есть - не надо на кипер наговаривать, повредить можно любую БД.
Сделали хоть какую-то защиту от дурака, не позволяющую вот так в лоб одно блюдо заменить другим.
Но все наши клиенты в голос говорят, что это очень неудобно (после дркгого софта). Пример:
Если клиент исправит блюдо "Обед №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с соответственно возникают ошибки.
IMHO
на данный момент ситуация лечится просто - это не клиент выбирает нас (r-keeper, обслуживание, установку, сопровождение , консультации и.т.д.), а мы выбираем клиента (вменяемый, платежеспособный, в меру требовательный и.т.д.)
переход на r-keeper после другого софта - процесс связанный со многими проблемами (в том числе и саботажем персонала). Поиск неполадок и неудобств в программе - один из способов показать что переход на другую систему автоматизации - зло вселенского масштаба.
Неудобства указанные выше (переменования, удаления) - никого из пользователей со стажем не беспокоят. Их волнуют совершенно другие вопросы. Убедится в этом можно просмотрев архив сообщений форумов за несколько лет.
Блин, писал - писал нажал не на ту кнопку и все стер, а автовосстановление восстановило мое сообщение в каком-то нечитаемом формате. Напишу кратко. На рынке, сейчас появляется много аналогичных систем и если не прислушиваться к клиенту "Р-кипер" скоро перестанет быть именем нарицательным. А все эти неудобства разработчик может исправить, но не хочет. Кол-во символов при котором редактирование считается новым блюдом в настраиваемый параметр (по умолчанию он почему-то равен 3). С группами сделать пару несложных проверок на совпадение кода.
Просто р кипер требует очень много времени, а для такого слабого функционала надо, чтобы поставил и забыл. А то получается надо быть специалистом "кипера", чтобы знать все его "фичи", которых в нем не мало и они плохо документированы. Надо придерживаться общепринятых стандартов и будет счастье всем.
Надо придерживаться общепринятых стандартов
В Москве как-то так сложилось, что кипер и является стандартом.
На рынке, сейчас появляется много аналогичных систем и если не прислушиваться к клиенту "Р-кипер" скоро перестанет быть именем нарицательным.
Согласен. Но Вы с чем сравниваете новые системы? С RK6? А надо - с RK7.
все наши клиенты в голос говорят, что это очень неудобно
Выбирая софт, выбираешь и его фичи. Мне тоже многое не нравится в другом софте после кипера. Приходится привыкать к особенностям, если этот софт тебе нужен. А идеального варианта нет.
При загрузке в 1с соответственно возникают ошибки.
Скажем так - а кто обещал беспроблемную работу со сторонним софтом? И главный вопрос - при выгрузке в dbf ошибка сохраняется?
для такого слабого функционала надо
Это просто Вы не всем пользуетесь...
р кипер требует очень много времени ... получается надо быть специалистом "кипера", чтобы знать все его "фичи", которых в нем не мало и они плохо документированы.
Как ни странно, при этом специалистов по такому вроде бы трудному софту в Москве в разы больше, чем по вроде бы легким 1с-base системам.
Честно скажу - меня не все устраивает в кипере. Но еще раз повторюсь: идеального софта нет. Пока, по-крайней мере, нет. Претензии можно предЪявить ко всем. А особенно - при переходе с другой системы, где уже ко многому привык. Будем честны - никаких стандартов на данный момент не существует. Любой софт сейчас на рынке в нашей области - сам по себе и на других не похож. Да сколько криков было хотя бы в рамках перехода с SH3 на SH4... Люди не любят учится, они в массе консервативны и хотят пользоваться привычными инструментами. Когда инструмент - не самоцель, а средство, то винить их в этом трудно... Но опять же - в такое время живем, идеала нет. И если бизнес или владелец диктует смену софта - подчиненный персонал обязан взять под козырек и переучиться, просто потому, что является наемным персоналом.
Andy, +1 по всем пунктам.
В Москве как-то так сложилось, что кипер и является стандартом.
Ди не только в Москве, а и в других регионах. Это называется "попал в нужное время в нужное место". Это наверное один из первых софтов, автоматизирующий направление HoReCa.
Согласен. Но Вы с чем сравниваете новые системы? С RK6? А надо - с RK7.
Да РК7 по внешнему виду и заявленному функционалу намного более продвинутый софт, но по нему ведутся активные доработки вот уже много лет и ставить его рано.
Выбирая софт, выбираешь и его фичи. Мне тоже многое не нравится в другом софте после кипера. Приходится привыкать к особенностям, если этот софт тебе нужен. А идеального варианта нет.
Идеального варианта нет, согласен и никогда не будет. Но можно к нему приблизиться. Ну вот никто меня не переубедит, что редактирование должно являться созданием новой позиции. Клиенты просто боятся, что - то исправлять в РК, потому, что появится много блюд ненужных. Почему блюдо нельзя редактировать? Сделали бы этот параметр настраиваемым. Ну нигде я такого не встречал. Весь софт работает по такому принципу, даже Винда.
Скажем так - а кто обещал беспроблемную работу со сторонним софтом? И главный вопрос - при выгрузке в dbf ошибка сохраняется?
Именно при выгрузке в dbf она и сохраняется (причем это не одна ошибка в экспорте, а это грубейшее нарушение "фундамента" БД). Не в обиду UCS будет сказано, что, наверное из-за таких вот "детских" ошибок Рарус, в своих бэках прекратил поддержку импорта из РК.
Это просто Вы не всем пользуетесь...
Да там и пользоваться то нечем, собственно. Функционал у программы простейший. А вот настройка ее требует глубоких и специфических знаний. Потому, что используются везде свои протоколы, БД (разные), куча параметров различных, которые зачастую перекрывают друг друга. И, главное все это не документировано. Вся информация разбросана по ftp, форуму, History, а части вообще нет. Звонишь в техподдержку,а там одни говорят оно, потом переключают на других, эти другое говорят-сами уже запутались. Причем сам-то по себе софт не сложный для установки-убивает его запутанность и нелогичность. Не все могут себе позволить заниматься только Кипером (одним им сыт не будешь), а он требует к себе повышенного внимания. Только и жди, что опять какие-нибудь "грабли" вылезут.
Еще раз хочу повторить, что я ни вкоей мере не хаю кипер-все имеет право на жизнь, просто хочется обсудить все достоинства и недостатки. А может я чего не так понимаю и делаю.
по нему ведутся активные доработки вот уже много лет и ставить его рано
Нет, уже можно. Тут Москва в отстающих, мало активных специалистов. В некоторых регионах уже вовсю ставят только его.
Рарус, в своих бэках прекратил поддержку импорта из РК.
Во как! Вот это новость! Что, "Управление рестораном" больше не поддерживает R-Keeper?
Да там и пользоваться то нечем, собственно. Функционал у программы простейший. А вот настройка ее требует глубоких и специфических знаний. Потому, что используются везде свои протоколы, БД (разные), куча параметров различных, которые зачастую перекрывают друг друга. И, главное все это не документировано. Вся информация разбросана по ftp, форуму, History, а части вообще нет. Звонишь в техподдержку,а там одни говорят оно, потом переключают на других, эти другое говорят-сами уже запутались. Причем сам-то по себе софт не сложный для установки-убивает его запутанность и нелогичность. Не все могут себе позволить заниматься только Кипером (одним им сыт не будешь), а он требует к себе повышенного внимания. Только и жди, что опять какие-нибудь "грабли" вылезут.
Надо принимать во внимание, что это софт с 15-летней!!! историей. Никто не мог в свое время сесть и предугадать все возможные потребности. Разработка велась, обеспечивая совместимость с предыдущими версиями настолько, насколько это возможно. Новичкам сейчас легче, они стоят на плечах гигантов.
Еще раз повторюсь, что сравнивать с современными системами следует именно RK7 - это попытка все переосмыслить заново.
Но при всех упомянутых недостатках и у RK6 есть неоспоримые преимущества. Он таки отлично работает. Из-за широкой распространенности, все баги и фичи становятся известны почти моментально. Если не ставить самые последние билды, вероятность столкнуться с неизвестными граблями стремится к нулю. Доверие к R-Keeper 6 - не в кредит, оно честно им заработано. И на самом деле, ни по одному другому аналогичному софту нет столько доступной информации, в том числе и про грабли.
Это не голословно, мы все время пытаемся заниматься альтернативным софтом. Недостатки есть у всех, и на самом деле, предпочитаешь тот софт, про чьи недостатки известно.
Во как! Вот это новость! Что, "Управление рестораном" больше не поддерживает R-Keeper?
Не совсем правильно выразился. Просто надо было доп. функционал от загрузки в Общепит. Позвонил в Рарус, а мне сказали, что ничего больше доделывать не будем, что есть - тем и пользуйтесь. А загрузку из РК7 они вообще не планируют. Вот и думай, что хочешь.
А по поводу 7-ки, если посмотреть обращения на трекер, баги даже в базовом функционале-это не печатается, это не работает... Да и в 6-ке еще куча "багов" - чего уж говорить про 7. И на фоне всего этого просто убивает отношение UCS к дилерам. Оно очень надменное и грубое. Разработчик всегда прав. Нормальной документации по продукту нет, а мне говорят -вы должны это знать. Я же не экстрасенс. Дайте нормальную тех. документацию-вопросов будет на порядок меньше. А некоторые кадры из UCS (не будем называть фамилий) вообще могут послать подальше. Был прецендент, мне говорят -если вы не можете прочитать информацию на английском, я вам переведу. А там в 7 словах 5 ошибок. И это на тех. сайте UCS. Жесть. Зачем, спрашивается тогда грубить... Да и функционал, даже у 7 насколько мне известно до сих пор нет нормального бронирования столиков-а его многие просят. А KDS, а Delivery - без слез не взглянешь. Надежно он работает если его не трогать и ничем не пользоваться. Как только пытаешься добавить функционал- вылезают "грабли".
надо было доп. функционал от загрузки в Общепит. Позвонил в Рарус, а мне сказали, что ничего больше доделывать не будем, что есть - тем и пользуйтесь.
Ну Общепит они вообще неохотно делают, все фишки в "Управлении Рестораном".
загрузку из РК7 они вообще не планируют.
Печально, потому что это хорошая альтернатива Shouse там, где люди вынуждены учиться самостоятельно.
на фоне всего этого просто убивает отношение UCS к дилерам. Оно очень надменное и грубое. Разработчик всегда прав. Нормальной документации по продукту нет, а мне говорят -вы должны это знать. Я же не экстрасенс. Дайте нормальную тех. документацию-вопросов будет на порядок меньше. А некоторые кадры из UCS (не будем называть фамилий) вообще могут послать подальше. Был прецендент, мне говорят -если вы не можете прочитать информацию на английском, я вам переведу. А там в 7 словах 5 ошибок. И это на тех. сайте UCS. Жесть. Зачем, спрашивается тогда грубить...
Сказать нечего - к сожалению, в Ваших словах много правды, которая относится не только лично к Вам. На личный неудачный опыт не списать.
даже у 7 насколько мне известно до сих пор нет нормального бронирования столиков-а его многие просят.
Говорят (с) - будет, поэтому мы например не стали писать свой аналогичный модуль, хотя собирались. Но слишком долго собирались :(
А KDS, а Delivery - без слез не взглянешь.
Это да. Но по Доставке уже есть альтернативы.
только пытаешься добавить функционал- вылезают "грабли"
Тут спорно, ибо есть много проектов, где "пытаются намазать слишком маленький кусочек масла по слишком большому куску хлеба".
Надо не забывать, что на большом обЪекте всегда должно быть предварительное изучение требований по автоматизации, и выбор уже поставщика решения, исходя из требований. Но, как правило, стоимость решения, удовлетворяющего всем поставленным условиям, превышает бюджет заказчика, особенно когда сравнивают по цене с R-Keeper (а он, в общем-то, далеко не самый дорогой продукт - так, средненько). И начинается - давайте поставим R-Keeper, там вроде тоже все есть - и начинается натягивание софта на требования. А он тупо не всегда подходит. Как пример: есть Windows-серверы, но они имеют свою четкую нишу. И разумные люди не реализуют любой серверный проект на Windows, только потому что это "тоже сервер, в нем весь функционал заявлен". Да, заказчику не всегда удается обЪяснить, или же у него не всегда деньги есть, но тут уже извините...
В своих рамках R-Keeper работает очень хорошо. Подавляющее большинство примочек было сделано под конкретного заказчика, которого результат удовлетворил. Право слово, по той же Доставке, у меня за десять лет, кажется, три или четыре инсталляции.
SH,во первых, спасибо за конструктивную беседу. За то, что вы ведете нормальный диалог-без наездов и по делу. А то некоторые упрутся, как бараны и начинают твердить, что SH - это круто, а все остальное г...о. Я так не считаю. Один вообще мне сказал, что SH-это стандарт де-факто для некоторых университетов. Я долго смеялся. Этот диалог - лирика, можно долго об этом говорить. Постараюсь в дальнейшем говорить только по делу. Вот по моим вопросам, может кто подсказать, как решить проблему?
Такие беседы необходимы! Я считаю, что все недостатки системы должны быть известны. Только так баг превращается в фичу :) У клиента не возникает чувства неудовлетворенности, что ему "впарили" не работающий как надо, продукт.
Мне очень нравится R-Keeper и StoreHouse, как комплекс автоматизации. Я с удовольствием изучаю все доступные альтернативы. Положа руку на сердце - достойных мало. Но они есть. Главное, повторюсь, принимать осмысленный выбор решения. Этим мало кто, на самом деле, занимается, большинство ставят один продукт и превозносят его до небес. А закзачика слушать надо, и ставить то, что ему нужно, а не то, что ты продаешь.
Вот по моим вопросам, может кто подсказать, как решить проблему?
По существу. Боюсь, что обе проблемы не решаемы, по-крайней мере, стандартными методами! Это действительно особенность софта. Транспорт, в своих разработках по интеграции, мы решаем через введение промежуточной базы. Мы это делаем для других целей, но думаю, что описанную проблему с шифрами такой подход должен решить. Да, это как раз подход не из коробки и может быть не очень дешев. Но - решаемо. Просто у каждого решения есть цена. Она, к сожалению, не всегда очевидна, но если заказчик хочет получить работающее решение - придется смириться и платить.
А вот что делать с редактированием - не представляю. Точнее, опять же, есть простой (и дорогой) вариант - сделать свой Редактор-лайт, чисто для редактирования названий. Кстати, хорошая мысль, может, кто-нибудь и воплотит. По идее, в том же BDE-Editor это должно быть возможно (http://www.carbis.ru/forum/showthread.php?t=5315&p=40963&viewfull=1#post40963), вопрос только в удачном интерфейсе. Да, это костыль, но увы :(
Опять не на ту кнопку нажал.
---------- Добавлено в 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 не хотим-не нравится он, да и дорого очень для такого функционала. А это все время на создание и тестирование.
А ведь это базовый функционал
Не согласен. Такого не было никогда, это магазинный функционал, который многие в последнее время прикручивают к фаст-фуду. Удобно, согласен - но это как раз из тех вещей, что 15 лет назад нельзя было предусмотреть.
---------- Добавлено в 13:51 ---------- Предыдущее сообщение было размещено в 13:48 ----------
использовать SH не хотим-не нравится он, да и дорого очень для такого функционала
Я знаю только одну альтернативу с таким же функционалом - это "1С-Рарус: Управление рестораном". Стоит оно столько же. Недостатки у него тоже есть. Это мое поле, я тут точно знаю, что говорю :) Хаус стоит своих денег, Общепитом после него реально невозможно пользоваться, не потому, что все по-другому, а потому, что не хватает возможностей.
---------- Добавлено в 13:53 ---------- Предыдущее сообщение было размещено в 13:51 ----------
загрузку для стороннего бэка придется писать самим ... А это все время на создание и тестирование.
Ну, мы можем написать :) надо только понять ТЗ и рынок сбыта, возможно, ценник в итоге будет разумный.
---------- Добавлено в 13:57 ---------- Предыдущее сообщение было размещено в 13:53 ----------
Очень много внимания надо уделять RK6-это не правильно. Данные проблемы должен решать разработчик.
Разработчик, вообще говоря, никому ничего не должен. Он делает продукт, Вы решаете, приобретать его или нет. Пока разработчику достаточно довольных клиентов, он может игнорировать недовольных.
Это же бизнес. Если решение вопросов, нужных 1% или даже 5% клиентов стоит столько же, сколько 100% или 95% клиентов - такие вопросы могут быть не решены никогда, ибо нерентабельно.
olegash
Вам +++++++Почет и уваженье за грамотность изложение и отстаивание своей позиции ...
Вам ------------Думаете слишком широко и всеобъемлюще - сосредоточтесь на чем либо одном:
или зарабатывать деньги (посылаю клиента в ж...пу, с его часто надуманными проблемами - способов сделать это мягко ооооочень много)
или сделать всех счастливыми (почти всегда ценой своих нервов, времени, денег, и.т.д.)
P.S. я выбрал первый вариант и мир преобразился (чего и Вам искренне советую......)
Скажу больше, я пытался идти по второму варианту. Некоторым известно, чем это кончилось. Хорошо, что компания выжила (а я извлек уроки).
Тут или бизнес - или благотворительность.
а потому, что не хватает возможностей.
А можно хотя бы один пример чего есть в Sh, но нет в Общепите. Всегда считал наоборот. Рарус самодостаточный продукт, его достаточно для ведения всего управленческого и бухгалтерского учета, а SH нет. Как в SH организованы расчеты с контрагентами, а банк есть? Общепит при даже беглом знакомстве создает впечатление профессионального софта (и формы все по ГОСТам и документы все правильные и философия правильная (IMHO). SH наоборот, а-ля 90-х годов. Помню ставил его, где-то хотел отсортироваь колонку какую-то-не тут то было, не дает. А по внешнему виду даже видно, что софт устаревший и не развивается функционал, а только баги исправляют.
Вам ------------Думаете слишком широко и всеобъемлюще - сосредоточтесь на чем либо одном:
или зарабатывать деньги (посылаю клиента в ж...пу, с его часто надуманными проблемами - способов сделать это мягко ооооочень много)
или сделать всех счастливыми (почти всегда ценой своих нервов, времени, денег, и.т.д.)
Вы правы, черт побери. Бабло главней.
P.S. я выбрал первый вариант и мир преобразился (чего и Вам искренне советую......)
Наверное надо последовать вашему варианту и не забивать голову всякойхренью Тем более пока есть такие программы, как РК-работа будет всегда. ++++++++ разработчику.
Как в SH организованы расчеты с контрагентами
Легко, причем даже два варианта есть - один документированный и правильный, а вторым в лайт-варианте я пользуюсь :)
а банк есть?
Нет, потому что это - программа складского учета. А не управленческого.
можно хотя бы один пример чего есть в Sh, но нет в Общепите.
Я думаю, что достаточно взять различия самого Раруса между двумя продуктами - Общепитом и Управлением Рестораном. Вы думаете, разница в цене в четыре раза просто так?
Навскидку - в Общепите не было нормальной работы с излишками. Возможно, уже поправили. Но год (или даже два, еще вторая версия была - сейчас третья) назад я был на семинаре по "Управлению рестораном" и многое проговаривалось, чего нет в Общепите, но есть в УР.
Sh4 - это сродни RK7, полностью переработанный продукт. У него есть еще один плюс, помимо функционала - скорость работы.
---------- Добавлено в 15:15 ---------- Предыдущее сообщение было размещено в 15:11 ----------
Нет у них на сайте сравнения, странно. И оказывается, УР уже подешевело, а Общепит, напротив, подорожал. Возможно, они двигаются в сторону сращивания продуктов.
У них принципиальное отличие, что Общепит - это допиленная бухгалтерия с минимумом функционала общепита, а УР - абсолютно самостоятельный продукт, только управленческий учет, с большим уклоном в складской.
Powered by vBulletin® Version 4.2.6 LTS Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot