Развлекательный центр, каток, игровые автоматы. Нужна альтернатива (R|Game)Keeper #380677

Есть контора у которой основной вид деятельности - недвижимость. Списание по средней. Есть принадлежащий этой конторе развлекательный центр: кинотеатр, каток, игровые автоматы (не азартные, а типа компьютерных игр). Сейчас это все начинает работать. На системе RKeeper/GameKeeper. Эта программа в части учета бара нам не подходит. Думаем ставить вместо нее 1С Трактир. По остальной, кроме бара, деятельности вопрос открыт. Внимание вопрос! Как преимущество этой программы заявляется, что она умеет работать с пластиковыми картами, то есть: Каток (коньки) игровые автоматы работают примерно так - приходит клиент, платит рублей 300, ему выдают карту где зачислены эти 300р. Он с этой картой играет в любом автомате, катается на коньках, и т.д., ну и затем либо получает оставшиеся деньги, либо доплачивает. Есть ли среди 1Сных решений готовое решение для учета такой деятельности, именно с использованием пластиковых карт? (необходимо готовое на сегодня решение)

..

кто знает конфы для работы с игровыми автоматами? кто знает конфы для работы с пластиковыми картами?

"... преимущество ... умеет работать с пластиковыми картами ..." Ну скорей всего речь идет не о платежных картах VISA и т.п., а о внутренних - типа дисконтных. Если я прав, то невижу никакого преимущества, ибо "докрутить" дисконт в программу - не так уж и сложно (в некоторых типовых есть). "Есть ли ... готовое решение для учета такой деятельности ..." Думаю именно для такой деятельности - нет. Посмотрите что пользуют конкуренты - возможно их программисты вам и помогут. К тому же непонятно как связаны пластиковые карты с игровыми автоматами? Там насколько знаю - жетоны.

Работа с пластиковыми картами означает, что можно по карточке определять постоянного посетителя со всеми вытекающими из этого - скидками, кредитом или предоплатой. С настоящими пластиковыми картами (типа VISA) работают банковские терминалы, которые подключаются к кассовой машине для оформления оплаты. Для ресторана 1С Трактир может оказаться лучше R_Keeper-а только тем, что его можно конфигурировать. Что же касается кинотеатра, то под него конфигурацию проще написать самим (особенно, что касается заказа билетов и учёта заполнения зала).

>> Ну скорей всего речь идет не о платежных картах VISA и т.п., а о внутренних >> - типа дисконтных. Если я прав, то невижу никакого преимущества, ибо >> "докрутить" дисконт в программу - не так уж и сложно (в некоторых типовых есть). Всё верно. Пластиковые карты не платежные, а типа локальных депозитных. >> К тому же непонятно как связаны пластиковые карты с игровыми автоматами? >> Там насколько знаю - жетоны. Очень просто - обычные игровые автоматы это куча жетонов, причем в каждый автомат разные жетоны. А здесь в автоматах стоят считыватели карт. То есть приходит человек в игровой зал, платит 500р, ему дают карту на которую зачислено 500р. Он играет в любом автомате, катается на катке. >> Если я прав, то невижу никакого преимущества, ибо "докрутить" дисконт в >> программу - не так уж и сложно (в некоторых типовых есть). Вы правы, но "докрутить" понятие растяжимое, в том числе и во времени. Необходимо работать уже сейчас. >> Для ресторана 1С Трактир может оказаться лучше R_Keeper-а только тем, что >> его можно конфигурировать. Возможно. Ведь в ресторанах, как правило, партионный учет. У нас списание по средней. Т.к. напомню развлекательный центр принадлежит напрямую конторе (как отдел, а не дочернее предприятие) у которой это не профильная деятельность. В RKeeper списания по средней этого нет. Можно делать это после выгрузки в 1С, но использовать программу, где будут совершенно разные цифры, мы не видим смысла. Поэтому замена на 1С трактир вопрос практически решенный. Кинотеатры идут отдельным софтом. Вопрос остается только по учету движений в игровых автоматах с использованием пластиковых карт (оборудование нацелено на пластиковые карты, а не жетоны).

Вы уважаемый видите только одну часть управление игровым залом - карты. А на самом деле - там все намного намного сложнее. Оставьте софт на том месте где он правильно стоит. На текущий момент что R что Game Kepeer практически лучшее решение как для бара так и для игровых автоматов. А то что у вас Списание по-средней, так кто Вам мешает в таком случае грузить напрямую из DBF R-Keeper данные о продажах и так проводить списание как хочется? Не ищите себе приключений на одно место. Когда у Вас будет "переиндексация" базы на баре Вам заказчик не то что про карты вспомнит... Или когда у Вас не сойдется баланс карт. Вы вообще в курсе что карты могут находиться у клиента сколь угодно долго и на ней должен сохраняться баланс? И этот баланс необходимо учитывать. В общем не торопитесь принимать такое решение. Автор, Вы не представляете о чем говорите. R-Keeper - это ФРОНТ офис. В нем отражаются операции ПРОДАЖ, а есть складская система STORE HOUSE которая и позволяет вести учет приготовления и отпуска блюд. Так вот в R-Keeper никакого "по-средней" или еще как-то нет. Есть дисконтная система, которую на 1С-ке очень трудно реализовать в таком объеме, есть работа с картами пластиковыми (причем как платежными так и дисконтными), есть анализ (RK-Кубы) - чего тоже в 1С сложновато реализовать. И все это работает очень и очень СТАБИЛЬНО, чего нельзя сказать о решении на базе 1С.

какая мне разница фронт это или бэк офис, если в моей компании учет ведется по средней, а в системе RKeeper/StoreHouse учет партионный? Брать RKeeper чтобы потом в его DBF ковыряться? За переиндексацию на баре значит убьют, а за кривые данные из dbf нет. Ты видать никогда в dbf напрямую не лазил, раз такими фразами кидаешься "так кто Вам мешает в таком случае грузить напрямую из DBF R-Keeper данные о продажах". да и какой смысл брать данные из dbf RKeeker и грузить их в 1С чтобы считать списание по средней? Это тоже самое что купить бухгалтерию парус оттуда выгружать данные в 1С бухгалтерию чтобы считать сами цифры уже в 1С. >> Автор, Вы не представляете о чем говорите. R-Keeper - это ФРОНТ офис. В нем >> отражаются операции ПРОДАЖ, а есть складская система STORE HOUSE которая и >> позволяет вести учет приготовления и отпуска блюд. Так вот в R-Keeper >> никакого "по-средней" или еще как-то нет. прекрасно понимаю где фронт офис, где бэк. также понимаю что RKeeper-овский бэк офис StoreHouse мы использовать не можем, причину уже говорил. чего не понимаю, так это есть ли смысл брать фронт-офис RKeeper? какой к нему бэк-офис брать, если списание у нас по средней? п.с. >>Есть дисконтная система, которую на 1С-ке очень трудно реализовать в таком объеме Что вы имеете ввиду?

up

upp

ппц.. за +1 второй половиной ответа смешал просто все в кучу. постарайся хотя бы понять чего, где, и на что надо менять. RK - бар. фронт. GR - автоматы. фронт. может где-то большее чем фронт. SH - бэк. Если надо чтобы срочно работало, то лучше расслабься и получай удовольствие. Оно, в принципе, работает очень и очень неплохо.

еще один  дебил неужели так непонятно излагаю StoreHouse нам НЕПОДХОДИТ, потому что в организации списание ПО СРЕДНЕЙ, чего в StoreHouse не предусмотрено можно отказаться от бэк-офиса SH, но использовать фронт RK но тогда надо что-то использовать как бэк ЧТО? предположим свою же основную бухгалтерию, выгружать из RK в бухгалтерию так выяснилось что и выгрузки нормально нет так что есть, выгружает с проводками Д41-К20, что есть полнейший абсурд в принципе. Но даже если выгрузку доделать, то иметь фронт в виде RK и бэк в виде основной бухгалтерии, которая итак переделана вдоль и поперек, и 90% данных не относятся никак к общепиту, то все это очень не радует. Итак, все теже, вопросы: 1. какие варианты (адекватные) есть для большой организации, в которой а. списание по средней, и б. общепит не является основной деятельностью пока склоняемся к 1С Трактиру. В итоге Трактир Фронт -> Трактир Бэк -> Своя Бух 2. Какие есть решения 1С для учета пластиковых карт (схема описана выше) с дисконтной системой?

Борис, Вы скатываетесь на необоснованные обзывания людей, у которых стаж на данном форуме, да я думаю и вообще по работе с 1С, гораздо больше чем у Вас. Это характеризует Вас на данном форуме не с лучшей стороны. Итак теперь попробую Вам объяснить еще раз. 1) Существует выгрузка от ООО "Респешн" ( которая через OLE сервер SH запрашивает данные из складской системы и загружает их в программу проводками. Почему выгружается именно проводка в корреспонденции с 20 Вы даже не удосужились понять. На самом деле это сделано в связи с отстуствием на 41 счете субсчета без аналитики, позволяющего отразить Приготовление блюда. Я прекрасно это менял и доработка данного момента заняла ну максимум 15 минут. Так что это далеко не абсурд как Вы пишете в . 2) Данные в DBF RK очень даже не кривые. Есть файл menu.dbf которые содержит данные о составе меню. Причем учтите что там может быть далеко не тот товар который у Вас на остатке, а скажем блюдо, которое готовится из нескольких продуктов или коктейль который также готовится из нескольких спиртных напитков. Также существует файл, отражающий продажи позиций из меню с указанием периода. Я реализовывал работу шиномонтажа на RK (людям важна была дисконтная система и стабильность работы). Так вот был создан в УСН справочник Меню, к нему был создан подчиненный справочник Нормы списания, и документ Отчет о продажах, который загружался из DBF содержащего данные о продажах и списывал составляющие согласно справочника Нормы списания. И списывалось как ни странно П0-СРЕДНЕЙ. Таким образом утверждение о кривости DBF зависит только от кривости Ваших рук. 3) Вы не считаете что >да и какой смысл брать данные из dbf RKeeker и грузить их в 1С чтобы считать >списание по средней? >Это тоже самое что купить бухгалтерию парус оттуда выгружать данные в 1С >бухгалтерию чтобы считать сами цифры уже в 1С. и >пока склоняемся к 1С Трактиру. В итоге Трактир Фронт -> Трактир Бэк -> Своя Бух это по сути одно и то же ;)) 4) И еще хочется отметить, что самостоятельно будет сложновато реализовать Вложенность блюд (блюдо в блюде), технологические потери и прочее.

Товарищ leshikkam, сами же пишете, что выгрузку меняли >> Я прекрасно это менял и доработка данного момента заняла ну максимум 15 >> минут. Так что это далеко не абсурд как Вы пишете в . а потом пишете >> Так что это далеко не абсурд как Вы пишете в . Мы звонили разработчикам выгрузки, дабы спросить какие у них были аргументы на эту проводку, они сами сказали что это ошибка. А вы спорите насчет абсурдности. >> Данные в DBF RK очень даже не кривые....Таким образом утверждение о кривости >> DBF зависит только от кривости Ваших рук. Товарищ leshikkam, представьте, что вы покупаете в магазине батон. Вы можете печь его дома, сами. Но вы покупаете его. Потому что проще и быстрее и пеньше проблем заплатить 10-20 рублей и купить его. И сразу можете его есть. Так же у моей компании с учетной системой. Мы вполне можем заплатить чтобы РАБОТАТЬ, а не иметь гемморой по поводу dbf и т.д. Я сам программист, причем не 1С, а по образованию. И прекрасно понимаю, чем может грозить лазя в dbf можно запросто заиметь головняк на том, что они могут начать помечать удаленные записи как-то по своему, например, введут поле ThisRecDeleted. Или решат новые поля добавить или старые переименовать. Нам нужна система, за которую платишь деньги и она работает. >> Так вот был создан в УСН справочник Меню, к нему был >> создан подчиненный справочник Нормы списания, и документ Отчет о продажах, >> который загружался из DBF содержащего данные о продажах и списывал >> составляющие согласно справочника Нормы списания. И списывалось как ни >> странно П0-СРЕДНЕЙ. Мы также можем написать выгрузку, которая будет списывать все по средней. Разве я спрашивал о том как написать выгрузку по средней? Я сказал еще в посте , что бэк офис SH не списывает по средней. Следовательно, он нам не походит. Свою бухгалтерию как бэк тоже не можем. Зачем использовать программу RK, к которой надо как бэк брать пустую бух, к которой писать выгрузку и пр, когда нам нужна учетная система которую взял и работает

ФУ !!! Как низко пал автор. Пока тут содрагаете воздух уже могли б нанять 1С-ника который бы прикрутил вам считыватель к вашей конфе 1С. За неделю реально прикрутить, так что - кто ищет тот находит.

считыватель чего?

разве я спрашивал про какой-то считыватель? или как сделать выгрузку ? вопрос то простой, с чего я и начал. 1. Какие конфы есть для деятельности "игровые автоматы не на жетонах, а на пластиковых картах". 2. Какую схему использовать если а. есть RKeeper (который можно заменить и поставить любое другое решение, но т.к. он есть по умолчанию его первым рассматриваем), б. списание в конторе по средней в. деятельность "общепит" не профильная. схему которая работает у всех, и там где могут сказать "RKeeper отличная и удобная программа, так все прекрасно считает", т.е. RK -> SH -> бух использовать не можем, изза пункта б, т.к. никому ни в $ не в пился бэк офис, где цифры будут совершенно не те, что в бухгалтерии после выгрузки в неё. схему RK -> бух тоже использовать не можем, т.к. бухгалтерия скажем так холдинга, просто пока развлекательный центр не выделен в дочку, а существует как отдел в конторе (и так будет еще год). И выгружать туда данные совершенно непрофильного общепита чтобы внутри эксперементировать и совершать работу над ошибками совершенно неприемлимо. поэтому схема будет фронт -> бэк -> бух если как фронт брать RK, то что брать в бэк? кроме как пустую бухгалтерию ответа пока не нахожу. Но и такой вариант никого не устроит, взять фронт, для которого самим разрабатывать бэк, когда задача стоит взять поставить и чтобы работало. Даже выгрузки нормальной не существует из RK в бухгалтерию. поэтому здесь приходим к Трактир фронт -> Трактир бэк -> бух что скажете?