Учет авансов и кредитов в кассовом ПО

Учет авансов и кредитов в кассовом ПО

Большинство кассовых систем разработано так, как будто гости рассчитываются всегда сразу, т.е. одновременно с предоставленной им услугой или передачей реализованных им товаров. Тот факт, что в жизни оплата услуги иногда расходится по времени с ее оказанием, разработчиками кассового ПО до сих пор напрочь игнорируется. Приём и использование авансов, либо оказание услуги в кредит с последующим погашением задолженности для многих рестораторов и их бухгалтеров является периодической головной болью, т.к. требует всяческих уловок и ручного учета.
Попытаемся разобраться, как же все таки можно было бы автоматизировать учет взаиморасчетов с гостями.

Проблема

Для начала попробуем обозначить проблему. А точнее две похожих проблемы – авансы и кредиты. Общее у них то, что на метод начисления, используемый в управленческом учете, накладывается кассовый метод учета, навязываемый кассовым ПО.

Авансы

Проблема с авансами в том, что контрольно-кассовая техника (ККТ) сама по себе не разделяет авансы и продажи.

1. По закону все наличные взаиморасчеты с гостями, а также расчеты с помощью платежных карт должны быть проведены через ККТ (например, фискальный регистратор).
2. Если гость вносит аванс за проведение банкета наличными, деньги должны быть также пробиты через ККТ.
3. В фискальных регистраторах (ФР) нет понятия «Внесение денежных средств на счет расчетов с покупателями». Есть только понятие «продажа». Т.е. все, что пробивается через ФР – продажа. Кроме внесений и изъятий в денежных ящик, которые не записываются в ЭКЛЗ, а имеют значение только в пределах открытой кассовой смены. Т.е. оформление аванса как «внесение наличных» не допускается. Требуется оформлять их именно как «продажу».
4. Кассовое ПО также ничего не знает о существовании предоплат, либо знает, но в учете их где-то теряет.
5. Есть опасность дублирования выручки, если отражать предоплату «фискально» и в момент ее получения и в момент зачета (в момент полного оплаты заказа).
6. Если же предоплату исключать из полной оплаты (оформлять как скидку), то страдает марочный отчет, который покажет снижение наценки на те блюда, которые были оплачены с использованием предоплаты.

В результате в день получения предоплаты бухгалтерия получает Z-отчет, в котором указана общая сумма продаж за день, включающая и сумму предоплаты. Складское же ПО, которое рассчитывает себестоимость, выдает на выходе Акт реализации, не включающий в себя эту сумму. Расхождение двух сумм сильно расстраивает бухгалтерию, т.к. документа, объясняющего это расхождение, у них нет.
В день проведения банкета может также возникнуть проблема. Учесть предоплату можно несколькими способами:

1. Отменить предоплату, а затем оплатить заказ на полную сумму.
   Этот способ не популярен из-за необходимости проводить возврат, который для налоговых органов является «подозрительным» действием.
2. Оформить скидку на сумму предоплаты и принять в оплату только оставшуюся сумму.
   Этот способ хорош для бухгалтерии, но не очень хорош для управленческого учета, т.к. искажает марочный отчет.
3. Оформить зачет предоплаты через ФР, используя отдельный регистр.
   Этот способ не популярен, т.к. создает ощущение искусственного «задвоения» выручки.

Кредит

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

1. С точки зрения управленческого учета оказанную услугу надо учитывать в день ее оказания. Т.е. стол закрывать, выручку зачитывать, а продукты списывать. С точки зрения ФР нет понятия «начислить выручку». Есть все та же «продажа», которая тут же совмещена с оплатой.
2. С точки зрения ресторатора и его бухгалтера, если деньги не получены, через «фискалку» мы ничего пробивать не должны.
3. С другой стороны, в день оплаты мы получаем деньги и обязаны пробить их через ККТ, однако кассовое ПО не дает нам возможности выбить фискальный чек с полным перечнем заказа, за который вносится оплата.

В результате единственное решение, к которому в таких случаях прибегают, — не закрывать стол (заказ) в кассовом ПО до момента оплаты. Этот стол будет «висеть» до того дня, пока гость не принесет деньги. И только тогда ему будет выбит нормальный чек, соответствующий тому, наличными он оплачивает или кредитной картой, и с полным перечнем заказа, скидок, бонусов и прочего. С одной лишь проблемой – эта продажа будет оформлена днем оплаты.
И все бы ничего, если бы эта оплата не оказалась в другом отчетном периоде, перед началом которого нужно было провести инвентаризацию. А с незакрытыми столами это сделать довольно проблематично.

Решение

Я предлагаю прибегнуть к более правильному, на мой взгляд, решению, касающемуся как авансов, так и кредитов.

Регистры ФР

Во-первых, вспомним, что у ФР-ов зачастую есть несколько регистров для разделения продаж по типу оплаты. Регистры имеют свои названия, но могут быть изменены с помощью программ настройки. Например, в ШТРИХ-ФР-К это регистры «Наличные», «Кредитом», «Тарой» и «Плат.карты». Это их названия по умолчанию. В другом ФР-е (не помню названия) я видел регистры «Наличные», «Кред.карты» и 4 разных «Плат.карты N» (итого 6 регистров).
Регистрами мы и воспользуемся для того, чтобы разделить типы оплат (источники/виды денежных средств, используемые для оплаты заказа).
Не нарушая «киперовских» традиций, мы оставим первый регистр для оплаты наличными, второй – для оплаты банковскими картами (не важно, дебетовыми или кредитными).
Третий регистр мы используем для оплаты со счета взаиморасчетов с покупателями (гостями). Некий аналог 62 счета в бухгалтерии. Желательно, конечно, переименовать его, особенно, если его название «Тарой». В кассовом ПО нужно создать типы оплаты «Предоплаты» и «Кредиты» с настройкой их на этот регистр.
Четвертый регистр оставим для отражения расчетов с помощью не банковских пластиковых карты (бонусные, клубные, депозитные, подарочные и прочие карты, выпуск которых контролирует не кредитная организация).

Секции ФР

Второе свойство ФР-ов, которое мы задействуем, это секции. Обычно в ресторанах секции не используются, все продажи бьются на одну и ту же первую секцию. Однако возможно пробивать продажи на разные секции, и иногда даже кассовое ПО позволяет такие настройки для различных категорий блюд.
Для такого ПО надо настроить отдельную категорию блюд «Предоплаты/Кредиты», и включить в нее все возможные блюда, используемые для пробития предоплат («Предоплаты 100», «Аванс 5000», и т.д.) и возврата кредитов («Оплата в кредит 1000»).
Затем выделить для обычных продаж секцию 01. А для предоплат и кредитов – секцию 02. Если есть возможность настроить ФР, то желательно даже переименовать секцию 01 в «Продажи», а секцию 02 — в «Предоплаты».
Теперь надо настроить кассовое ПО так, чтобы для всех блюд категории «Предоплаты/Кредиты» использовалась секция 02, а для остальных блюд – секция 01.

Прием аванса за банкет

Теперь рассмотрим разные ситуации и способы их отражения в системе.
Первое событие – прием аванса за банкет. Пусть это будет 5000 р.
Пробиваем блюдо «Предоплата 5000 р.» ценой в 5000 р.
В фискально регистраторе эта сумма отразится по секции 02. Соответственно, в Z-отчете будет указано, что по секции 01 итоговая сумма выручки – пусть будет 55 тыс. р., а по секции 02 – 5000 р. При этом сумма предоплаты будет отражена в регистре, соответствующем типу оплаты. Если наличными – то в первом регистре, если банковской картой – то во втором.
Заполняя формы КМ-4 (журнал кассира-операциониста) и КМ-6 (справку кассира-операциониста,  на основании которой бухгалтер вносит записи в свою базу) можно указать выручку в две строчки – по одной на каждую секцию.
Дополнительно, кстати, можно доработать формы для того, чтобы разделять выручку по типам оплаты – по одному столбцу на каждый тип.
На основании данных КМ-6 бухгалтер может создать проводки:
Д(50) – К(90.01) – торговая выручка из секции 01, 55 000 р.
Д(50) – К(62.02) – авансы полученные из секции 02, 5 000 р.
Для того, чтобы складское ПО выдало Акт реализации тоже на сумму продаж (т.е. на 55 000 р.) нужно, чтобы продажа блюда «Предоплаты» не попала в этот Акт.
Тут все зависит от ПО. В iiko есть понятие «предоплата», но в ней нельзя настроить секцию (надеюсь, что доработают когда-нибудь).
В Сторхаусе можно блюдо «Предоплата» объявить типа «услуга», в этом случае, она не попадет в документ расхода, а будет оформлена просто приходным кассовым ордером, про которые мало кто вообще в Сторхаусе знает.

Зачет аванса

Теперь отразим оплату банкета с использованием аванса.
Пусть банкет был на 30 000 р. А прочая выручка за этот день – 40 000 р.
Оплачиваем банкет сначала типом оплаты «Предоплаты» (настроенным на 3-й регистр) на сумму 5000 р. Затем оплачиваем оставшуюся сумму (25 000 р.) наличными.
Вся выручка попадает в секцию 01.
В Z-отчете выручка за день будет разнесена по двум регистрам: «наличные» — 65 000 р., «предоплаты» — 5 000 р.
В бухгалтерском учете создаем проводки:
Д (50) – К (90.01) – торговая выручка, оплаченная наличными, 65 000 р.
Д (62) – К (90.01) – торговая выручка, оплаченная авансами, 5 000 р.
В складском ПО формируется один Акт реализации (документ расхода) на сумму 70 000 р.

Оказание услуги в кредит

Теперь давайте отразим оплату «в кредит». Допустим мы обслужили гостя на 3000 р., но он не оплатил заказ (обещал оплатить послезавтра). Общая выручка за день та же (70 000 р.).
Закрываем его стол на тип оплаты «Кредиты». Ничто не мешает нам даже пробить это через фискалку. Сумма уйдет на третий регистр. Гостю будет выдан чек со списком блюд. На этом чеке гость может расписаться и оставить его в кассе (как залоговую квитанцию).
Проводки получаются те же, что и в предыдущем разделе:
Д (50) – К (90.01) – торговая выручка, оплаченная наличными, 67 000 р.
Д (62.02) – К (90.01) – торговая выручка, оплаченная в кредит, 3 000 р.
В складском ПО формируется один Акт реализации (документ расхода) на сумму 70 000 р. Т.е. все продукты мы списали именно сегодня, т.к. оказание услуги было сегодня.

Оплата кредита

И вот наступило долгожданное послезавтра. Гость принес оплату в 3000 р.
Пробиваем блюдо «Оплата в кредит» на сумму 3000 р. Сумма уйдет на 02 секцию. Фискальный чек прикрепляется к оставленной ранее залоговой квитанции и отдается гостю.
В формах кассира-операциониста отражаем эту сумму опять таки в отдельной секции.
В бухучете заводим:
Д(50) – К(90.01) – сумму торговой выручки из секции 01.
Д(50) – К(62.02) – сумму погашения кредита из секции 02, 3000 р.

Резюме

Как видно из предлагаемого решения, в принципе отражать «авансово-кредитные» отношения с гостями в системе можно. И даже можно попытаться подстроить существующее кассовое ПО (которое допускает настройку). Но лучше, конечно, чтобы производители ПО встроили этот алгоритм в свои продукты, чтобы пользователям не приходилось «сворачивать мозги» для учета таких сложных ситуаций.