Просмотр полной версии : Организвция игросети с несколькими юрлициами
Как правильно реализовать схему работы при нахождении в ИЦ нескольких юрлиц? Например: есть ООО (с ФР) - Лабиринт и ИП (с принтером) - игровые автоматы. Стоит 1 касса. С неё должны активироваться и пополняться карты на оба юрлица. Причем заранее неизвестно какая сумма, по какой карте будет потрачена в Лабиринте или в ИА. Т. е. клиент купил карту-пополнил счет, но сумма проигранная в Лабиринте должна пройти по ФР, а сумма по автоматом через принтер. Как быть в такой ситуации?
Т. е. клиент купил карту-пополнил счет, но сумма проигранная в Лабиринте должна пройти по ФР, а сумма по автоматом через принтер. Как быть в такой ситуации?
Никак.
Мы же на момент приема денег не знаем как гость их потратит, соответственно и не можем заранее разделить чеки по принтерам.
Варианты:
1. Городить некое подобие комиссионной схемы. Все деньги принимаем на 1 Юр лицо и пробиваем по ФР, по итогам смены в отчетах смотрим какая часть очков прошла по аппаратам второго Юр лица и бухи делают взаиморасчет.
2. Делать по 2 карты (для игры на одних аппаратах и на других). Но это естественно бред.
3. Менять налогообложение Юр лиц и что то придумывать в бухгалтерии.
В любом случае, адекватное решение этого вопроса лежит вне области ПО GK
В любом случае, адекватное решение этого вопроса лежит вне области ПО GKНу почему же вне области. Если немного дополнить функционал GK, то что-то и можно придумать. Если бы касса одновременно поддерживала работу с несколькими ПУ (чего как я понял нет), то можно было бы в программе вести учет потрат и внесений отдельно по юрлицам. Т. е. клиент вносит столько-то на одно юрлицо и столько то на другое. Соответственно контроллеры списывают очки, с соответствующего юрлица. Останется вопрос корректного возвращения денег по юрлицам при закрытии счета. Ну или хотя бы можно было продавать, например на Лабиринт билет, который бы проходил через ФР. Наверное еще что-то можно придумать. Так, что как раз-таки все упирается в UCS.
И снова здравствуйте.
Я так понял из Вашего сообщения, что ООО - это арендатор, а ИП - субарендатор (или друг, сват, брат арендатора).
Выручка Арендатора (лабиринт) - фискализируется.
Выручка ИП (игровые аппараты) - не фискализируется.
Банально простой путь:
1. ДЛЯ ООО - Лабиринт, как ТОВАР или УСЛУГА - продается на кассе за фиксированную цену, т.е. за НАЛ (К примеру: Лабиринт 30 мин -100 руб, Лабиринт 1 час -180 руб, Лабиринт БЕЗЛИМИТ -250 руб)
Тем самым предопределяем выбор посетителя. При продаже печатается фискальный чек за ЛАБИРИНТ, сумма попадает в фискальную память (Z-отчет).
2. ДЛЯ ИП - Для игры на аппаратах - карта продается по схеме: ЗАЛОГОВАЯ ЦЕНА КАРТЫ (ОЧКИ-ДЕНЬГИ), т.е. продажа Пакета Стандартный ХХ руб. + Сумма пополнения (ОЧКИ-БОНУСЫ), т.е. Ручное пополнение Бонусов (На кассе все просто - Выбор пакета - Ручной бонус).
Нефискальный принтер ИП - не нужен, при вышеизложенном варианте пополнения (продажи) карты, в фискальную память будет попадать только ее ЗАЛОГОВАЯ стоимость, если она имеется, при пополнении карты Бонусами - на фискальном принтере печатается чек, но сумма не заносится в фискальную память, тем самым налогом не облагается. Но хранить полученные средства за пополнение надо отдельно, от средств полученных за лабиринт!!!!!!!!!!!!
Если есть иные нюансы во взаимоотношениях ООО и ИП или вопросы по моему изложению, то напишите.
Чуть не забыл о ГЛАВНОМ.
При такой схеме взаиморасчетов с посетителями, КАССИРЫ - должны быть "в доску" проверенными (своими до мозга) людьми. Конечно же как возможность контроля на предмет "НЕ УКРАДИ" - есть ОтчетыGK, но почему назвал их "в доску" своими - на случай внеплановой налоговой проверки. Налоговиками делается вот что. Проверка кассовой дисциплины: Контрольная закупка, Уведомление о ВП, Снятие Х-отчета, походу - Проверка даты и времени на фискальном терминале, Сверка наличности в кассе с показаниями X-отчета. Ваши кассиры имеют достаточную выдержку и самообладание?
---------- Добавлено в 02:45 ---------- Предыдущее сообщение было размещено в 02:14 ----------
olegash (http://www.carbis.ru/forum/member.php?u=5122) Так в чем проблема, в последних версиях GK - все заложено, но немного в другой плоскости, в плоскости - налогообложения прибыли.
Есть понятие - Арендованное оборудование, в недрах логики GK - рассчитывается и заносится цена за 1 игру, каждого арендованного игрового аппарата, т.е. это себестоимость для ООО, из расчета суммы договора\ на кол-во аппаратов\ время использования (для бухгалтерии желательно произвести расчеты и учесть нюансы для каждого арендованного оборудования: расчет энергопотребления (пиковое - стандартное), затраты на обслуживание и регламентные работы, если это оборудование является - аттракционом (по договору работы производит арендатор), метраж используемого аппаратом полезного пространства по отношению к арендной плате за кв м арендуемой площади.
А в целом логика обычная:
Заключаем договор между ООО и ИП, что ООО использует оборудование ИП, делясь после уплаты налога чистой прибылью с ИП. Или платит ФИКСУ за ежесуточное (недельное, месячное) использование оборудования ИП, тогда налоги платит ИП.
И прошу всех админовGK прислушаться к моей просьбе: Старайтесь не увлекаться обходными схемами, старайтесь объяснить собственникам Ваших РЦ - держаться в границах логики заложенной в самой программе учета GAME-KEEPER, решая ХОТЕЛКИ Ваших работодателей - Вы сами открываете ДЫРЫ для возможности злоупотребления персоналом.
Если Ваш центр или специфика бизнеса работодателя, нуждается в дополнениях к существующему функционалу GK, напишите здесь в форуме, обсудим, сформулируем ТЗ и получим РЕЗУЛЬТАТ нас удовлетворяющий.
Если бы касса одновременно поддерживала работу с несколькими ПУ (чего как я понял нет), то можно было бы в программе вести учет потрат и внесений отдельно по юрлицам. Т. е. клиент вносит столько-то на одно юрлицо и столько то на другое. Соответственно контроллеры списывают очки, с соответствующего юрлица.
Это костыль, жутко неудобный для гостя.
Я еще раз настаиваю на том что эта проблема должна решаться не на кассе м/у гостем и кассиром, а в бухгалтерии. Способы для этого есть. То что бухи не хотят этим заниматься, а хотят получить просто готовый результат, не вникая в технологию, и плевать им на то как это будет работать - так это, к сожалению, общая беда...
Я так понял из Вашего сообщения, что ООО - это арендатор, а ИП - субарендатор (или друг, сват, брат арендатора).
Выручка Арендатора (лабиринт) - фискализируется.
Выручка ИП (игровые аппараты) - не фискализируется.Да, пимерно так.
Банально простой путь:
1. ДЛЯ ООО - Лабиринт, как ТОВАР или УСЛУГА - продается на кассе за фиксированную цену, т.е. за НАЛ (К примеру: Лабиринт 30 мин -100 руб, Лабиринт 1 час -180 руб, Лабиринт БЕЗЛИМИТ -250 руб)
Тем самым предопределяем выбор посетителя. При продаже печатается фискальный чек за ЛАБИРИНТ, сумма попадает в фискальную память (Z-отчет).
2. ДЛЯ ИП - Для игры на аппаратах - карта продается по схеме: ЗАЛОГОВАЯ ЦЕНА КАРТЫ (ОЧКИ-ДЕНЬГИ), т.е. продажа Пакета Стандартный ХХ руб. + Сумма пополнения (ОЧКИ-БОНУСЫ), т.е. Ручное пополнение Бонусов (На кассе все просто - Выбор пакета - Ручной бонус).
Нефискальный принтер ИП - не нужен, при вышеизложенном варианте пополнения (продажи) карты, в фискальную память будет попадать только ее ЗАЛОГОВАЯ стоимость, если она имеется, при пополнении карты Бонусами - на фискальном принтере печатается чек, но сумма не заносится в фискальную память, тем самым налогом не облагается. Но хранить полученные средства за пополнение надо отдельно, от средств полученных за лабиринт!!!!!!!!!!!!При такой схеме, мы имеем кучу недостатков:
1. ООО Может захотеть прикупить себе в дальнейшем аппараты и тогда мы уже не сможем продавать билеты.
2. Нельзя работать по тарификации в ООО (т. е. только стандартная цена за определенное время-клиент не может заплатить за фактическое время нахождения в зоне).
3. Нарушается сам механизм бонусов. Непонятно какие бонусы должны попадать в кассу, а какие нет. То же и со статистикой.
Так в чем проблема, в последних версиях GK - все заложено, но немного в другой плоскости, в плоскости - налогообложения прибыли.
Есть понятие - Арендованное оборудование, в недрах логики GK - рассчитывается и заносится цена за 1 игру, каждого арендованного игрового аппарата, т.е. это себестоимость для ООО, из расчета суммы договора\ на кол-во аппаратов\ время использования (для бухгалтерии желательно произвести расчеты и учесть нюансы для каждого арендованного оборудования: расчет энергопотребления (пиковое - стандартное), затраты на обслуживание и регламентные работы, если это оборудование является - аттракционом (по договору работы производит арендатор), метраж используемого аппаратом полезного пространства по отношению к арендной плате за кв м арендуемой площади.Если бы этот механизм был развит, может он бы и имел место быть. Но логика программы не рассчитывает тех параметров, которые вы описали-все это надо делать вручную. А это может зависеть от многих параметров и меняться от времени использования. Т. е. опять ручные расчеты...
старайтесь объяснить собственникам Ваших РЦ - держаться в границах логики заложенной в самой программе учета GAME-KEEPER, решая ХОТЕЛКИ Ваших работодателей - Вы сами открываете ДЫРЫ для возможности злоупотребления персоналом.Я всегда считал, что софт должен подстраиваться под бизнес, а не наоборот. И чем гибче настройка программы под меняющийся и растущий бизнес, тем она более конкурентна на рынке.
Это костыль, жутко неудобный для гостя.Ну не такой уж и неудобный. По крайней мере введение понятия юрлиц (и поддержки нескольких ПУ) в логику GK мы решаем многие проблемы и увеличиваем гибкость программы.
Вообще поддержкой работы с юрлицами страдает весь софт UCS. Хотя в последнее время, в связи с реалиями бизнеса, разработчик стал уделять этому внимание. Например в RK7 прекрасно уживаются юрлица на одной кассе. Согласен, что там немного другой принцип работы, но и там порой возникают нюансы, которые UCS решает по мере поступления. Вот и в SH5 заявлена работа с юрлицами. Так, что необходимость введения юрлиц в логику GK считаю небезосновательной. Другое дело, что RK7 - это флагманский продукт компании....
Я всегда считал, что софт должен подстраиваться под бизнес, а не наоборот.
Я немного в сторону уведу. Формально, Вы правы. А фактически, не вижу возражения на следующее замечание:
на момент приема денег не знаем как гость их потратит
Очень часто бизнес (что характерно, чем крупнее бизнес, тем больше этим страдает) не имеет четко выраженного понимания порядка собственной работы. Затрудняясь решить проблему на системном уровне, бизнес взывает к софту, как к волшебной палочке - "автоматизируйте нам это!"
Но софт - это всего лишь алгоритмы. Следует помнить золотую фразу - "автоматизируя хаос, вы получаете автоматизированный хаос".
Для начала, надо представить, что на кассе нет никакого GK, а есть человек с двумя бумажками. И, принимая деньги от гостя, он их должен между бумажками распределить. Вот, формализируйте логику поведения этого человека - а потом уже предъявляйте UCS, что такое-то поведение не реализовано в GK.
Вообще поддержкой работы с юрлицами страдает весь софт UCS. Хотя в последнее время, в связи с реалиями бизнеса, разработчик стал уделять этому внимание. Например в RK7 прекрасно уживаются юрлица на одной кассе. Согласен, что там немного другой принцип работы, но и там порой возникают нюансы, которые UCS решает по мере поступления. Вот и в SH5 заявлена работа с юрлицами. Так, что необходимость введения юрлиц в логику GK считаю небезосновательной.
Видимо есть глубокое непонимание разницы между розницей (с обслуживанием) и предоплаченными услугами на выбор гостя. В принципе все что касалось ответа есть в комментарии sibgaba. Замечу что ни один подобный проект не имеет шансов без глубокой юридической проработки, особенно с учетом тенденций регулирования в сфере микрофинансовых организаций.
Прошу прощения, но у меня ощущение, что эта дискуссия заходит в эмоциональный тупик.
Я всегда считал, что софт, по максимуму заложенной в него логики, должен подстраиваться под законодательство страны, где используется, иначе о получении сертификатов: соответствия, интеллектуальной собственности, использования платежных систем и т.п. разрешительной правовой документации, можно просто забыть.
Бизнес и его "хотелки" на втором плане, если они не пересекаются с законодательством, мониторинг использования и добавление изменений - это уже на совести правообладателей, в угоду коммерческой выгоды использования данного ПО.
Огромная просьба, можете более подробно объяснить, как Вы видите возможность использования отдельных юрлиц в данном ПО, начиная с продажи по кассе, заканчивая отчетностью и распределением выручки или прибыли между юрлицами?
Чуть не забыл, если между юрлицами нет договора по аренде: оборудования или кв. метров, договора по использованию материальных средств одного другим, договора о каких-либо взаиморасчетах в счет использования оборудования, то в рамках нашего законодательства вести фискализированную отчетность должны оба юрлица, т.е. терминал GK - 2 фискальных устройства. Т.к. в системе GK нет возможности разделения суммы по 2 фискальным регистраторам, то имеет место использования одного ФР подключенного к GK, а другого (ручного) стоящего отдельно.
---------- Добавлено в 02:13 ---------- Предыдущее сообщение было размещено в 00:32 ----------
При такой схеме, мы имеем кучу недостатков:
1. ООО Может захотеть прикупить себе в дальнейшем аппараты и тогда мы уже не сможем продавать билеты.
2. Нельзя работать по тарификации в ООО (т. е. только стандартная цена за определенное время-клиент не может заплатить за фактическое время нахождения в зоне).
3. Нарушается сам механизм бонусов. Непонятно какие бонусы должны попадать в кассу, а какие нет. То же и со статистикой.
1. Только одно, фискализировать все полученные средства должно ООО (заключив договор с собственником обрудования), взаиморасчеты между юрлицами по отчетам GK.
2. Это как приучить посетителей, фиксированная цена им понятней, чем гонять их на кассу для доплаты, чтоб забрать СВОЕГО ребенка. (Если только у Вас в РЦ есть правило, что пребывание лиц младше X лет на аттракционах повышенной опасности, только в сопровождении ответственных лиц (родственников или лиц старше ХХ лет).
А если посетитель хочет отдать ребенка ответственному лицу и пойти по магазинам, и ребенок рад - полон энергии и родители спокойны, занимаясь своими делами?
3. Механизм начисления бонусов виден в отчетах, раскладывается от А до Я, каким образом был начислен: Ручной бонус, бонус при пополнении, начисление бонуса при продажи пакета, все начисления бонусов имеют свой ID.
Огромная просьба, можете более подробно объяснить, как Вы видите возможность использования отдельных юрлиц в данном ПО, начиная с продажи по кассе, заканчивая отчетностью и распределением выручки или прибыли между юрлицами?Нет времени думать об этом, т. к. у нас всего 1 клиент попросил об этом и тратить свое время на составление бизнес процессов работы данного предприятия, не вижу смысла. Если нет такой возможности в GK - значит нет.
2. Это как приучить посетителей, фиксированная цена им понятней, чем гонять их на кассу для доплаты, чтоб забрать СВОЕГО ребенка. (Если только у Вас в РЦ есть правило, что пребывание лиц младше X лет на аттракционах повышенной опасности, только в сопровождении ответственных лиц (родственников или лиц старше ХХ лет).
А если посетитель хочет отдать ребенка ответственному лицу и пойти по магазинам, и ребенок рад - полон энергии и родители спокойны, занимаясь своими делами?Тут я останусь при своей точке зрения-не надо учить клиента вести ЕГО бизнес. Да и аттракционы бывают разные, а не только лабиринт...
3. Механизм начисления бонусов виден в отчетах, раскладывается от А до Я, каким образом был начислен: Ручной бонус, бонус при пополнении, начисление бонуса при продажи пакета, все начисления бонусов имеют свой IDНу так каким образом (в каком отчете) при ручном пополнении на кассе, мы увидим, что в одном случае это бонусы-деньги, а в другом бонусы-бонусы? :))
Не вижу проблем. Если клиент платит то можно все. Функционал Game Keeper можно доработать. Отчеты тоже можно сделать любые.
Каждый клиент считает, что именно его видение и ведение бизнеса отражено в любом софте "из коробки".
Каждый клиент считает, что именно его видение и ведение бизнеса отражено в любом софте "из коробки".
Золотые слова.
Видимо есть глубокое непонимание разницы между розницей (с обслуживанием) и предоплаченными услугами на выбор гостя.
Замечу что ни один подобный проект не имеет шансов без глубокой юридической проработки, особенно с учетом тенденций регулирования в сфере микрофинансовых организаций.Замечу, что в ПО Абонемент (те же предоплаченные услуги на выбор гостя) добавлен фукционал работы с несколькими ФР (Юрлицами). Так что, по всей видимости, дело все-таки не в "тенденциях регулирования в сфере микрофинансовых организаций", а в чем-то более другом...
Замечу, что в ПО Абонемент (те же предоплаченные услуги на выбор гостя) добавлен фукционал работы с несколькими ФР (Юрлицами).
ИМНО в Абонементе ситуация немного другая.
Вариант 1 (очень похоже на Кипер). В фолио гостя уже сформирован набор услуг (накидали руками абонементов и/или просто услуг, которые поделены между Юриками) и делаем оплату. На этот момент деление сумм по Юр лицам полностью определено, остается только пробить итоговую сумму, которая поделится по ФР.
Вариант 2. Внесение целевого аванса. На момент внесения средств так же известно на какую услугу (а значит и на какое Юр лицо) они будут потрачены.
Вы же ставите задачу так:
...Причем заранее неизвестно какая сумма, по какой карте будет потрачена в Лабиринте или в ИА. Т. е. клиент купил карту-пополнил счет, но сумма проигранная в Лабиринте должна пройти по ФР, а сумма по автоматом через принтер.
В GK нет машины времени что бы узнать сколько именно от внесенной суммы гость потратит в лабиринте а сколько на ИА.
PS А если еще вспомнить про бонусы за внесение...
Разве что в лабиринте поставить софт и фискальник - тоесть все деньги идут через принтер, а потраченные в лабиринте еще и через фискальник.
П.С. Софт для лабиринта я делал, только вместо фискальника - принтер(ES-88IV), теоретически можно фискальник сделать - переписав процедуру печати на работу с библиотекой фискальника(небыло фискальника для экспериментов).
Powered by vBulletin® Version 4.2.6 LTS Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot