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

19.06.15

Учетные задачи - Розничная торговля

Те, кто пишет программное обеспечение для автоматизации учета розничной выручки, зачастую сталкиваются с проблемой учета авансов и кредитов - таких как предоплаты, подарочные карты, бонусные счета и прочее.
В настоящей статье предлагается вариант решения этой проблемы.

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

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

Проблема

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

Авансы

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

  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 р.

Резюме

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

ККМ авансы кредиты касса автоматизация

См. также

SALE! 20%

Автоматический заказ поставщику в 1С: загрузка прайсов и анализ цен поставщиков для УТ 10.3, УТ 11, КА2, УНФ, УПП, ERP, Розница 2

Бюджетирование и планирование Оптовая торговля Розничная торговля Логистика, склад и ТМЦ Анализ продаж Платформа 1С v7.7 Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Управление торговлей 10 1С:Розница 2 1С:Управление производственным предприятием 1С:Управление нашей фирмой 1.6 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Беларусь Украина Россия Казахстан Управленческий учет Платные (руб)

Система управления запасами для 1С помогает работать с запасами правильно: автоматически рассчитывает потребность и делает заказ поставщику, загружает прайсы, перемещает товары по филиалам, анализирует продажи и позволяет управлять ассортиментом.

28500 22800 руб.

21.04.2017    90188    105    39    

191

ККТ-ОНЛАЙН 54-ФЗ: Обработка для работы онлайн касс АТОЛ, ШТРИХ, VIKI PRINT и т.д. МАРКИРОВКА + ЭКВАЙРИНГ + БЕСПЛАТНЫЙ ДЕМО

ККМ Кассовые операции Розничная торговля Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Бухгалтерия 2.0 1С:Управление торговлей 10 1С:Розница 2 1С:Управление производственным предприятием 1С:Бухгалтерия государственного учреждения 1С:Бухгалтерия 1.6 1С:Бухгалтерия автономного учреждения 1С:CRM ПРОФ, КОРП Россия Платные (руб)

Универсальная обработка для обслуживания любых фискальных регистраторов (ККТ), в том числе Веб сервер АТОЛ. Работает в соответствии с 54-ФЗ. (ФФД 1.0, ФФД 1.05, ФФД 1.1). Подключайте любую онлайн кассу к практически любой конфигурации. Нет необходимости обновлять 1С. Можно бесплатно скачать и протестировать. Может работать одновременно с несколькими онлайн-кассами, либо одной с разных рабочих мест. (через RDP, TCP\IP или веб-сервер) Позволяет разделить один чек сразу на несколько ККТ или на несколько систем налогообложения. Можно настроить собственный шаблонов чека. Можно использовать эквайринг там, где он не поддерживается. Работает на LINUX и Windows ЭМУЛЯТОР + ЭКВАЙРИНГ + МАРКИРОВКА + ПОДДЕРЖКА ФФД 1.2

4800 руб.

27.02.2017    763258    4673    9495    

2781

ЕГАИС++. Опт, производство, импорт

Оптовая торговля Розничная торговля Обмен с ГосИС Платформа 1С v8.3 1С:Управление торговлей 10 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Рестораны, кафе и фаст-фуд Россия Бухгалтерский учет Управленческий учет Акцизы Платные (руб)

Полнофункциональное расширение (ранее известное как Модуль 1С-ЕГАИС) для взаимодействия типовых конфигураций 1С и ЕГАИС, предоставляющее максимум возможностей по работе с УТМ. Получение и отправка ТТН, отправка акта о постановке на баланс и акта о списании. Получение остатков. Загрузка и сопоставление номенклатуры и контрагентов. Оправка в ЕГАИС отчетов о производстве и импорте.

8970 руб.

15.12.2015    165980    677    362    

386

SALE! 10%

Загрузка номенклатуры из Excel в УТ11, КА 2, ERP 2, Розница 2. Дополнительные реквизиты и сведения, характеристики, картинки, цены, остатки

Загрузка и выгрузка в Excel Розничная торговля Логистика, склад и ТМЦ Ценообразование, анализ цен Прайсы Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Розница 2 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Управленческий учет Платные (руб)

Загрузка из файлов xls, xlsx, ods, csv, mxl в УТ11, КА 2, ERP 2, Розница 2. Задействованы все возможности конфигурации - заполнение реквизитов номенклатуры, дополнительных реквизитов и сведений, характеристики, доп.реквизиты и сведения характеристик. Дополнительные обработки для расширения возможностей.

10560 9504 руб.

29.10.2014    210190    620    524    

439

Обмен с системой ЦРПТ (Универсальная конфигурация ХамелеонЦРПТ + маркировка табака, обуви, одежды, лекарств, фото, молока, духов(парфюма), питьевой воды, велосипедов и шин)

Оптовая торговля Розничная торговля Обмен с ГосИС Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Россия Бухгалтерский учет Управленческий учет Платные (руб)

Данная публикация создана для помощи разработчикам, интеграторам и другим заинтересованным лицам по настройке системы маркировки обуви, одежды, лекарств, табака, фото, молока, духов(парфюма), питьевой воды, велосипедов и шин. Смело задавайте нам вопросы по работе с ЦРПТ, GS1, ЭДО, Национальным каталогом, мы накопили достаточно большую базу знаний по данным темам и готовы ответить на все Ваши вопросы.

104000 руб.

18.03.2019    110334    34    114    

178

Печать кассовых чеков на одну ККМ с нескольких рабочих мест для 1С:УТ11.х, КА2.х, Розница 2.х, УНФ, ERP 2.х, БП 3, БГУ2

ККМ Кассовые операции Розничная торговля Обмен с ГосИС Бухгалтерский учет Оперативный учет Управляемые формы 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Платные (руб)

Расширение конфигурации для УТ 11.4, 11.5, КА 2.4, 2.5, Розница 3.0, 2.3 и 2.2, УНФ 1.6, УНФ 3x, ERP 2.4, 2.5, БП 3, БГУ2 (Управляемые формы) позволяет выполнять печать кассовых чеков на одну ККМ 54-ФЗ с нескольких рабочих мест. НИКАКИХ НАСТРОЕК В РАЗРАБОТКЕ - ПОДКЛЮЧИЛ И ПЕЧАТАЙ. Если у вас несколько отделов и одна ККМ - печатайте на одной ККМ! Если у вас две ККМ и одна поломалась - печатайте на одной ККМ, пока ремонтируете другую!

4000 руб.

27.08.2018    116010    980    564    

827

54-ФЗ. Очередь печати для ККМ. Обработки для подключения онлайн-касс к 1С 8 (поддержка Маркировки) + Эмулятор + ФФД 1.2

ККМ Кассовые операции Розничная торговля Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Бухгалтерия 2.0 1С:Управление торговлей 10 1С:Розница 2 1С:Управление производственным предприятием 1С:Бухгалтерия государственного учреждения 1С:Бухгалтерия автономного учреждения Россия Платные (руб)

Обработка осуществляет обслуживание ККТ АТОЛ, Штрих и Меркурий для конфигураций "УТ 10.3", "КА 1.1", "УПП 1.3", "Розница 1.0", "БП 2.0" и других отраслевых решений, построенных на основе указанных выше конфигурациях. Поддерживает возможность параллельно пробития чеков на одной ККМ несколькими пользователями. Поддерживает Веб-сервер Атол. Соответствует требованиям 54-ФЗ. Поддерживает ФФД 1.0, 1.05, 1.1 и 1.2. Разделяет чеки по нескольким СНО. Поддерживает механизмы подключения ККТ по TCP/IP, для работы через RDP или интернет. Поддержка маркировки.

5400 руб.

25.05.2015    316654    1844    3008    

994
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. dimabarkov 26.06.15 14:20 Сейчас в теме
Все конечно хорошо, только одна проблема: 62 счет ведется в разрезе как минимум покупателя, а данный алгоритм не подразумевает эту аналитику. Еще одна проблема частичная предоплата по безналу + налом по факту. Еще одна проблема - кассовый аппарат фиксирует прием оплаты и при данном алгоритме получится задвоение оплата авансом и оплата предоплатой (именно для ккт в ЭКЛЗ) и неизвестно как будет реагировать налоговый инспектор увидев в Z отчете оплату предоплатой
2. ksely 112 26.06.15 18:31 Сейчас в теме
(1) dimabarkov, спасибо за комментарии.

1. Если в кассовом ПО есть понятие "предоплата", то там же должно быть понятие "клиент", который может быть выбран при пробивании чека. Потом эта информация может быть передана в бухгалтерскую программу. Если же там нет такого понятия, то бухгалтеру придется разнести сумму всех авансов по контрагентам руками, ничего не поделаешь. В ресторанах обычно за один день предоплат не так много, чтобы в них не разобраться. По крайней мере эту сумму не надо высчитывать из выручки.

2. В чем состоит "проблема частичная предоплата по безналу + налом по факту", я не очень понял. Предоплату я предлагаю пробивать на отдельную секцию, а тип оплаты (нал/безнал) все также отражается через регистр ККТ.

3. "Задвоение" получается тогда, когда не понятно, для чего используется ККТ. А она используется для регистрации "денежных операций". А не только выручки. Например, возврат (если ККТ позволяет) не уменьшает общую сумму в ЭКЛЗ, а увеличивает. Потому что это общая сумма всех операций, а не сумма выручки. Для бухгалтера Z-отчет является первичным документом, но не отчетным. На основании его бухгалтер отражает хозяйственные операции в бух.учете. И если была пробита предоплата, она должна быть отражена как увеличение кредиторки, а не выручка.

3. ikekoval 119 03.03.16 16:54 Сейчас в теме
Отличная статья! Прочитал много материала по теме, а тут всё упорядоченно и с понятным примером. Спасибо!
4. kvaleksandr 22 18.05.17 11:04 Сейчас в теме
Спасибо за интересный материал.
Оставьте свое сообщение