Как правильно реализовать схему работы при нахождении в ИЦ нескольких юрлиц? Например: есть ООО (с ФР) - Лабиринт и ИП (с принтером) - игровые автоматы. Стоит 1 касса. С неё должны активироваться и пополняться карты на оба юрлица. Причем заранее неизвестно какая сумма, по какой карте будет потрачена в Лабиринте или в ИА. Т. е. клиент купил карту-пополнил счет, но сумма проигранная в Лабиринте должна пройти по ФР, а сумма по автоматом через принтер. Как быть в такой ситуации?
Никак.Т. е. клиент купил карту-пополнил счет, но сумма проигранная в Лабиринте должна пройти по ФР, а сумма по автоматом через принтер. Как быть в такой ситуации?
Мы же на момент приема денег не знаем как гость их потратит, соответственно и не можем заранее разделить чеки по принтерам.
Варианты:
1. Городить некое подобие комиссионной схемы. Все деньги принимаем на 1 Юр лицо и пробиваем по ФР, по итогам смены в отчетах смотрим какая часть очков прошла по аппаратам второго Юр лица и бухи делают взаиморасчет.
2. Делать по 2 карты (для игры на одних аппаратах и на других). Но это естественно бред.
3. Менять налогообложение Юр лиц и что то придумывать в бухгалтерии.
В любом случае, адекватное решение этого вопроса лежит вне области ПО GK
Ну почему же вне области. Если немного дополнить функционал GK, то что-то и можно придумать. Если бы касса одновременно поддерживала работу с несколькими ПУ (чего как я понял нет), то можно было бы в программе вести учет потрат и внесений отдельно по юрлицам. Т. е. клиент вносит столько-то на одно юрлицо и столько то на другое. Соответственно контроллеры списывают очки, с соответствующего юрлица. Останется вопрос корректного возвращения денег по юрлицам при закрытии счета. Ну или хотя бы можно было продавать, например на Лабиринт билет, который бы проходил через ФР. Наверное еще что-то можно придумать. Так, что как раз-таки все упирается в UCS.Сообщение от sibgaba
И снова здравствуйте.
Я так понял из Вашего сообщения, что ООО - это арендатор, а ИП - субарендатор (или друг, сват, брат арендатора).
Выручка Арендатора (лабиринт) - фискализируется.
Выручка ИП (игровые аппараты) - не фискализируется.
Банально простой путь:
1. ДЛЯ ООО - Лабиринт, как ТОВАР или УСЛУГА - продается на кассе за фиксированную цену, т.е. за НАЛ (К примеру: Лабиринт 30 мин -100 руб, Лабиринт 1 час -180 руб, Лабиринт БЕЗЛИМИТ -250 руб)
Тем самым предопределяем выбор посетителя. При продаже печатается фискальный чек за ЛАБИРИНТ, сумма попадает в фискальную память (Z-отчет).
2. ДЛЯ ИП - Для игры на аппаратах - карта продается по схеме: ЗАЛОГОВАЯ ЦЕНА КАРТЫ (ОЧКИ-ДЕНЬГИ), т.е. продажа Пакета Стандартный ХХ руб. + Сумма пополнения (ОЧКИ-БОНУСЫ), т.е. Ручное пополнение Бонусов (На кассе все просто - Выбор пакета - Ручной бонус).
Нефискальный принтер ИП - не нужен, при вышеизложенном варианте пополнения (продажи) карты, в фискальную память будет попадать только ее ЗАЛОГОВАЯ стоимость, если она имеется, при пополнении карты Бонусами - на фискальном принтере печатается чек, но сумма не заносится в фискальную память, тем самым налогом не облагается. Но хранить полученные средства за пополнение надо отдельно, от средств полученных за лабиринт!!!!!!!!!!!!
Если есть иные нюансы во взаимоотношениях ООО и ИП или вопросы по моему изложению, то напишите.
Чуть не забыл о ГЛАВНОМ.
При такой схеме взаиморасчетов с посетителями, КАССИРЫ - должны быть "в доску" проверенными (своими до мозга) людьми. Конечно же как возможность контроля на предмет "НЕ УКРАДИ" - есть ОтчетыGK, но почему назвал их "в доску" своими - на случай внеплановой налоговой проверки. Налоговиками делается вот что. Проверка кассовой дисциплины: Контрольная закупка, Уведомление о ВП, Снятие Х-отчета, походу - Проверка даты и времени на фискальном терминале, Сверка наличности в кассе с показаниями X-отчета. Ваши кассиры имеют достаточную выдержку и самообладание?
---------- Добавлено в 02:45 ---------- Предыдущее сообщение было размещено в 02:14 ----------
olegash Так в чем проблема, в последних версиях GK - все заложено, но немного в другой плоскости, в плоскости - налогообложения прибыли.
Есть понятие - Арендованное оборудование, в недрах логики GK - рассчитывается и заносится цена за 1 игру, каждого арендованного игрового аппарата, т.е. это себестоимость для ООО, из расчета суммы договора\ на кол-во аппаратов\ время использования (для бухгалтерии желательно произвести расчеты и учесть нюансы для каждого арендованного оборудования: расчет энергопотребления (пиковое - стандартное), затраты на обслуживание и регламентные работы, если это оборудование является - аттракционом (по договору работы производит арендатор), метраж используемого аппаратом полезного пространства по отношению к арендной плате за кв м арендуемой площади.
А в целом логика обычная:
Заключаем договор между ООО и ИП, что ООО использует оборудование ИП, делясь после уплаты налога чистой прибылью с ИП. Или платит ФИКСУ за ежесуточное (недельное, месячное) использование оборудования ИП, тогда налоги платит ИП.
И прошу всех админовGK прислушаться к моей просьбе: Старайтесь не увлекаться обходными схемами, старайтесь объяснить собственникам Ваших РЦ - держаться в границах логики заложенной в самой программе учета GAME-KEEPER, решая ХОТЕЛКИ Ваших работодателей - Вы сами открываете ДЫРЫ для возможности злоупотребления персоналом.
Если Ваш центр или специфика бизнеса работодателя, нуждается в дополнениях к существующему функционалу GK, напишите здесь в форуме, обсудим, сформулируем ТЗ и получим РЕЗУЛЬТАТ нас удовлетворяющий.
Последний раз редактировалось Solo; 08.01.2015 в 05:18.
Это костыль, жутко неудобный для гостя.Если бы касса одновременно поддерживала работу с несколькими ПУ (чего как я понял нет), то можно было бы в программе вести учет потрат и внесений отдельно по юрлицам. Т. е. клиент вносит столько-то на одно юрлицо и столько то на другое. Соответственно контроллеры списывают очки, с соответствующего юрлица.
Я еще раз настаиваю на том что эта проблема должна решаться не на кассе м/у гостем и кассиром, а в бухгалтерии. Способы для этого есть. То что бухи не хотят этим заниматься, а хотят получить просто готовый результат, не вникая в технологию, и плевать им на то как это будет работать - так это, к сожалению, общая беда...
Да, пимерно так.
При такой схеме, мы имеем кучу недостатков:
1. ООО Может захотеть прикупить себе в дальнейшем аппараты и тогда мы уже не сможем продавать билеты.
2. Нельзя работать по тарификации в ООО (т. е. только стандартная цена за определенное время-клиент не может заплатить за фактическое время нахождения в зоне).
3. Нарушается сам механизм бонусов. Непонятно какие бонусы должны попадать в кассу, а какие нет. То же и со статистикой.
Если бы этот механизм был развит, может он бы и имел место быть. Но логика программы не рассчитывает тех параметров, которые вы описали-все это надо делать вручную. А это может зависеть от многих параметров и меняться от времени использования. Т. е. опять ручные расчеты...
Я всегда считал, что софт должен подстраиваться под бизнес, а не наоборот. И чем гибче настройка программы под меняющийся и растущий бизнес, тем она более конкурентна на рынке.
Ну не такой уж и неудобный. По крайней мере введение понятия юрлиц (и поддержки нескольких ПУ) в логику GK мы решаем многие проблемы и увеличиваем гибкость программы.
Вообще поддержкой работы с юрлицами страдает весь софт UCS. Хотя в последнее время, в связи с реалиями бизнеса, разработчик стал уделять этому внимание. Например в RK7 прекрасно уживаются юрлица на одной кассе. Согласен, что там немного другой принцип работы, но и там порой возникают нюансы, которые UCS решает по мере поступления. Вот и в SH5 заявлена работа с юрлицами. Так, что необходимость введения юрлиц в логику GK считаю небезосновательной. Другое дело, что RK7 - это флагманский продукт компании....
Я немного в сторону уведу. Формально, Вы правы. А фактически, не вижу возражения на следующее замечание:Я всегда считал, что софт должен подстраиваться под бизнес, а не наоборот.
Очень часто бизнес (что характерно, чем крупнее бизнес, тем больше этим страдает) не имеет четко выраженного понимания порядка собственной работы. Затрудняясь решить проблему на системном уровне, бизнес взывает к софту, как к волшебной палочке - "автоматизируйте нам это!"на момент приема денег не знаем как гость их потратит
Но софт - это всего лишь алгоритмы. Следует помнить золотую фразу - "автоматизируя хаос, вы получаете автоматизированный хаос".
Для начала, надо представить, что на кассе нет никакого GK, а есть человек с двумя бумажками. И, принимая деньги от гостя, он их должен между бумажками распределить. Вот, формализируйте логику поведения этого человека - а потом уже предъявляйте UCS, что такое-то поведение не реализовано в GK.
Последний раз редактировалось SH; 11.01.2015 в 15:37.
Алексей Аркадьев
Когда заказчик ищет волшебника, то чаще всего он находит сказочника.
Если у Вас есть вопрос по поддержке - напишите его на форуме, я обязательно отвечу, если знаю ответ.
Если Вам нужны какие-то файлы, пишите на почту: support@carbis.ru, но вначале посмотрите в разделе для скачивания.
Для коммерческих вопросов:
+7 (495) 740-49-91, или на почту: sales@carbis.ru
Видимо есть глубокое непонимание разницы между розницей (с обслуживанием) и предоплаченными услугами на выбор гостя. В принципе все что касалось ответа есть в комментарии sibgaba. Замечу что ни один подобный проект не имеет шансов без глубокой юридической проработки, особенно с учетом тенденций регулирования в сфере микрофинансовых организаций.Вообще поддержкой работы с юрлицами страдает весь софт UCS. Хотя в последнее время, в связи с реалиями бизнеса, разработчик стал уделять этому внимание. Например в RK7 прекрасно уживаются юрлица на одной кассе. Согласен, что там немного другой принцип работы, но и там порой возникают нюансы, которые UCS решает по мере поступления. Вот и в SH5 заявлена работа с юрлицами. Так, что необходимость введения юрлиц в логику GK считаю небезосновательной.
no room basic
system halted...
Прошу прощения, но у меня ощущение, что эта дискуссия заходит в эмоциональный тупик.
Я всегда считал, что софт, по максимуму заложенной в него логики, должен подстраиваться под законодательство страны, где используется, иначе о получении сертификатов: соответствия, интеллектуальной собственности, использования платежных систем и т.п. разрешительной правовой документации, можно просто забыть.
Бизнес и его "хотелки" на втором плане, если они не пересекаются с законодательством, мониторинг использования и добавление изменений - это уже на совести правообладателей, в угоду коммерческой выгоды использования данного ПО.
Огромная просьба, можете более подробно объяснить, как Вы видите возможность использования отдельных юрлиц в данном ПО, начиная с продажи по кассе, заканчивая отчетностью и распределением выручки или прибыли между юрлицами?
Чуть не забыл, если между юрлицами нет договора по аренде: оборудования или кв. метров, договора по использованию материальных средств одного другим, договора о каких-либо взаиморасчетах в счет использования оборудования, то в рамках нашего законодательства вести фискализированную отчетность должны оба юрлица, т.е. терминал GK - 2 фискальных устройства. Т.к. в системе GK нет возможности разделения суммы по 2 фискальным регистраторам, то имеет место использования одного ФР подключенного к GK, а другого (ручного) стоящего отдельно.
---------- Добавлено в 02:13 ---------- Предыдущее сообщение было размещено в 00:32 ----------
1. Только одно, фискализировать все полученные средства должно ООО (заключив договор с собственником обрудования), взаиморасчеты между юрлицами по отчетам GK.При такой схеме, мы имеем кучу недостатков:
1. ООО Может захотеть прикупить себе в дальнейшем аппараты и тогда мы уже не сможем продавать билеты.
2. Нельзя работать по тарификации в ООО (т. е. только стандартная цена за определенное время-клиент не может заплатить за фактическое время нахождения в зоне).
3. Нарушается сам механизм бонусов. Непонятно какие бонусы должны попадать в кассу, а какие нет. То же и со статистикой.
2. Это как приучить посетителей, фиксированная цена им понятней, чем гонять их на кассу для доплаты, чтоб забрать СВОЕГО ребенка. (Если только у Вас в РЦ есть правило, что пребывание лиц младше X лет на аттракционах повышенной опасности, только в сопровождении ответственных лиц (родственников или лиц старше ХХ лет).
А если посетитель хочет отдать ребенка ответственному лицу и пойти по магазинам, и ребенок рад - полон энергии и родители спокойны, занимаясь своими делами?
3. Механизм начисления бонусов виден в отчетах, раскладывается от А до Я, каким образом был начислен: Ручной бонус, бонус при пополнении, начисление бонуса при продажи пакета, все начисления бонусов имеют свой ID.
Последний раз редактировалось Solo; 21.01.2015 в 03:37.
Нет времени думать об этом, т. к. у нас всего 1 клиент попросил об этом и тратить свое время на составление бизнес процессов работы данного предприятия, не вижу смысла. Если нет такой возможности в GK - значит нет.
Тут я останусь при своей точке зрения-не надо учить клиента вести ЕГО бизнес. Да и аттракционы бывают разные, а не только лабиринт...
Ну так каким образом (в каком отчете) при ручном пополнении на кассе, мы увидим, что в одном случае это бонусы-деньги, а в другом бонусы-бонусы?)
Ваши права
Ответить с цитированием