Хотелось бы по рассуждать на тему On-Line и Off-Line списания. Поделиться собственными мыслями. Услышать альтернативные мнения.
Итак, сперва теория:
Off-Line модель списания (типичный представитель RKeeper + StoreHouse). Фронт (Касса Rkeeper) никогда ничего не знает о складских остатках. На кассе нам абсолютно все равно, что у нас числится на складах в учете на момент продажи. Продажи сделанные на кассе никак не влияют на остатки в складском учете (до определенного момента: пока мы не закроем день, не загрузим продажи в склад и не произведем списание).
On-Line модель списания (Трактир, IIKO). Фронт и Бэк завязаны м/у собой (а в некоторых случаях представляют собой единое целое). Продажи сделанные на кассе тут же (On-Line) попадают в складской учет, и тут же происходит списание продуктов по нормам закладки.
Точка актуальности – момент времени, в который остатки в программе полностью отражают фактические остатки.
На первый взгляд преимущества On-Line модели очевидны и в доказательствах не нуждаются. Все разработчики, ПО которых поддерживает On-Line, говорят примерно одни и те же фразы:
On-Line остатки - в любой момент можно заглянуть в программу и увидеть актуальные остатки на всех складах. И вплоть до автоматического составления заявки поставщику.
On-Line себестоимость - как только блюдо продалось на кассе, мы тут же видим не только выручку от его продажи, но и себестоимость и доход. В случае, если себестоимость (или фуд-кост или наценка), выходят за определенные рамки, мы тут же можем отреагировать на это изменение.
Теперь давайте заглянем поглубже, и попробуем разобраться, какие условия должны выполниться, что бы On-Line дал все то чего от него ждут.
Для корректной работы On-Line списания необходимо, что бы к тому моменту, как мы продаем блюдо через кассу, все его составляющие были оприходованны в складском учете. В некоторых случаях это требование доводило до абсурда: Несколько лет назад (5-7) я имел шапошное знакомство с программой Трактир, установленной в одном кафе. Версию не помню, возможно что за прошедшее время, в программе что то изменилось, но на тот момент это выглядело именно так: До тех пор, пока бухгалтер-калькулятор не внесет приход по штучному товару (бутылочное пиво) касса не дает его продавать, ссылаясь на то что на остатках 0. Данное свойство программы преподносилось как четкость и строгость учета, контроль персонала, снижение пересорта.
По факту, это постоянно приводило к ситуации когда в пятницу вечером расторговались бутылочным пивом в ноль, с утра сделали заявку поставщику, к обеду он привез. Пиво стоит в холодильнике, но продавать мы его не можем до тех пор, пока не приедет управляющий или бухгалтер и не внесет приход в программу. Но продавать то надо, гости хотят пива, после вчерашнего. И что делали в итоге? Правильно - продавали пиво мимо кассы, т.е. товар отпускали, деньги брали, записывали на бумажку, а потом, когда в складе делали приход (а иногда это случалось только в понедельник) - пробивали по кассе все одним чеком. Вот тебе и строгость учета и контроль персонала...
Данный случай, это типичный пример того, когда поставили телегу (бух учет) впереди лошади (касса).
В программах On-Line эту проблему решают путем списания в минус. Т.е. на утро у нас в учете было 10 бутылок по цене (себестоимость) 100 рублей, на сумму 1000. Пусть продажная цена будет 200 руб.
Касса продает, Склад списывает, остатки ведутся. И вот продали мы по кассе 10 бутылок и продаем 11-ю. Откуда она взялась – это отдельный вопрос, и далеко не всегда это криминал. Возможно не верно сняли остатки на инвентаризации, возможно поставщик уже привез новую партию, а приход по ней еще не вбили, нам сейчас не это важно. Важно то, что есть товар, есть Гость, который готов отдать за него деньги, но нет остатков по складу. Запретить продажу такого товара – это не вариант (потеряем гостя, потеряем деньги). Значит продаем. Если продали – значит списываем. Что имеем в учете:
Что делать дальше? Если программа позволяет внести приход задним числом и если после этого она корректно пересчитает расход, то в общем то все хорошо (за исключением того что уже нельзя говорить о том что в отчетах мы видим реальную картину). А что делать если прихода не было?
- Количественный остаток. Тут все относительно просто, он равен -1 (или 0?).
- Суммовой остаток. Тут возникает первая трудность. -100? Т.е. списали суммовой остаток в минус. С точки зрения бухгалтерии это бред какой то. Наверное надо списать эту бутылку по 0 себестоимости. Тогда получится остаток -1 на сумму 0? То же так себе картинка.
- Прибыль/наценка. Вообще не понятно что делать. Если 11-ю бутылку списали по 0 себестоимости то наценка 200 руб.
Само по себе списание в минус это еще пол беды. На мой взгляд основной вопрос это приходование при наличии отрицательных остатков (приход на минус).
Имеем остаток -1 на сумму 0 (или на сумму -100). И есть приход на 10 по цене 100. После приходной накладной получим остаток 9 на сумму 1000 (завысили себестоимость???) или остаток 9 на сумму 900. Но по факту то привезли 10! И реально на остатках сейчас 10. Что делать?
По хорошему, перед приходом на минус от него (от минуса) надо избавиться, т.е. сделать корректировочный документ (например с/в) в которой либо указать фактически остаток товара (если на складе он есть) либо хотя бы указать 0.
Списание 1 дня реализации в StoreHouse занимает 3-5 минут максимум (рассматриваем стабильно работающее заведение, в котором все к/к уже заведены и при списании не вылезает ошибок, которые требует время на правку калькуляций). Ввод первички занимает на порядок больше времени. В итоге получается, что точка актуальности, в первую очередь, зависит от своевременного ведения первичных документов (приходов, перемещений м/у складами), а уж потом от On-Line списания. В небольшом заведении, очень часто, нет отдельной должности бухгалтера – калькулятора, или оператора, который бы занимался ведением первичной документации. Как правило, весь учет (и складской в том числе) ведет бухгалтер в одном лице. У него есть выходные, у него есть отчетные периоды, есть выдача зарплаты, есть налоги, расчеты с поставщиками. И все эти дела порой гораздо важнее чем ввод первички. Соответственно, в таком заведении, в понедельник утром Точка актуальности ну никак не наступит вне зависимости от того что мы используем On-Line или Off-Line. И хорошо если это произойдет к вечеру, а то и только во вторник-среду.
---------- Добавлено в 12:19 ---------- Предыдущее сообщение было размещено в 12:15 ----------
Не многие из пользователей SH знают, что у него есть модуль On-Line остатков (он не лицензируется отдельно, если есть SH значит его можно использовать.
Как он работает: всю первичку он получает из SH. Данные о продажах он берет с касс. Списание он не производит (списание в SH делается как обычно). Он только справочно рассчитывает текущие расчетные остатки. Проблемы со списанием в минус не возникает (т.к. фактически ничего и не списывается), а вот On-Line остатки он показывает (и они могут быть отрицательными).
2-3 года назад, один из наших Клиентов, насмотревшись на презентациях и начитавшись в журналах о прелестях программ, которые списывают On-Line, поставил вопрос ребром: StoreHouse устарел, хочу складской учет с On-Line списанием. Программу ему менять не стали, а просто развернули модуль On-Line остатков. Недели 2 он радовался, глядя на цифры которые сами по себе меняются на мониторе. Потом, задумавшись о том, почему они не всегда соответствуют реальности, еще какое то время требовал от бухгалтера, что бы первичка вводилась «сей момент» и «тут же». А потом успокоился, не сдался, а именно успокоился. Своего он добился – живые остатки он увидел и даже делались попытки автоматического формирования заказов. Но чуда не произошло. Выручка заведения не выросла, себестоимость не упала, а наценка продолжала колебаться как обычно. В итоге модуль этот стоит и по сей день, но им никто не пользуется.
Еще один плюс On-Line модели списания это постоянный контроль себестоимости (или, если угодно, Фуд-Коста). Давайте опять же заглянем по глубже. Уже разобрались, что пока не наступит точка актуальности (т.е. пока не будет введена первичка), то и нельзя говорить о корректной себестоимости. А что дальше?
Мы работаем в бизнесе в котором наценка, слава богу, составляет минимум 150-200% (по хорошему, для ресторана, 250-300%). Уровень наценки каждое заведение устанавливает для себя самостоятельно. Что можно сделать если наценка упала? Есть 3 пути:На сколько может измениться себестоимость? Как при этом измениться наценка? При каком изменении наценки нужно что то предпринять?
- Изменить (повысить) продажную цену. Но после этого придется перепечатать все папки меню, а это опять расходы. Не думаю, что есть заведения, которые могут себе позволить менять папки чаще одного раза в месяц.
- Изменить (понизить) себестоимость. Для этого надо или уменьшить закладку/выход, или заменить продукты на более дешевые (а значит менее качественные). Но это получится уже совсем другое блюдо.
- Убрать блюдо из меню совсем. Не многие заведения зимой предлагают салаты из свежих помидор. А летом они есть в любом меню.
Давайте попробуем посчитать. Возьмем кухонное блюдо: себестоимость 100, продажная цена 300, прибыль 200, наценка 200% (прямо скажем, скромная наценка для кухни). Допустим себестоимость изменилась на 3 рубля (стала 103). Учитывая, что это составное блюдо (состоит из нескольких продуктов, которые не могут подорожать одновременно), можно принять, что если общая себестоимость изменилась на 3 процента, это значит что какой-то компонент блюда, подорожал на 5-10 процентов. Как мне кажется, это максимальное изменение цены, которое может произойти.
Что имеем теперь: себестоимость 103, продажная цена 300, прибыль 197, наценка 191%. Наценка изменилась на 9 процентов (в абсолютном выражении) и на 4,5 в процентном. Если изначальная наценка на блюдо у нас будет 300% (что больше похоже на ресторанную кухню), то общее изменение наценки составит 3,8 процента.
Предположим у нас идеальное предприятие, все цифры абсолютно точны, и своевременны. Должно ли изменение закупочной цены на 5-10% по одному компоненту подвигнуть управляющего на сиюминутную переоценку меню? На мой взгляд – нет. В итоге опять приходим к тому, что анализировать наценку нужно не только (и не столько) на основании текущих продаж, сколько на анализе некоего продолжительного периода. Как минимум 7-10 дней (а памятуя о том что мы не можем себе позволить печатать новое меню чаще раза в месяц), то это цифра легко увеличивается до 30 дней. А когда мы говорим об анализе периода длинной в месяц – нам уже абсолютно не важно, какое у нас списание On-Line или Off-Line.
И на последок еще 1 гвоздь в модель On-Line списания. В StoreHouse есть замечательный отчет: Предполагаемая стоимость товаров. Этот отчет никак не зависит от того по какой модели (On-Line или Off-Line) у нас работает Бэк, возможно что подобный отчет есть и в IIKO (и просто я о нем не знаю).
Суть отчета: в любой момент времени (не важно списана у нас реализация прошедшего периода или нет) мы можем посмотреть в этом отчете предполагаемую стоимость (наценку и фуд-кост) на текущий момент. Расчет будет производиться по цене последнего прихода.
Т.е. имеем на остатках кусок прихода по цене 100 руб. Ввели следующий приход по цене 110 руб. В Марочном отчете StoreHouse (по прошедшим и обработанным продажам) будем видеть себестоимость 100. В On-Line списании IIKO будем видеть те же 100. А в Предполагаемой стоимости товаров (в StoreHouse) уже увидим 110. Т.е. используя этот отчет, можно заранее (не после того как продадим и спишем, ни после того как просто продадим, а загодя) увидеть изменение наценки и, если нужно, предпринять необходимые действия.
Еще один большой (для меня) вопрос это изменение калькуляционных карт в программах работающих по On-Line модели. В StorHouse нельзя изменить калькуляцию, если по ней произведено списание. Нам нужно либо отменить списание до нужной даты, изменить к/к этой датой и списать заново. Либо мы можем изменить к/к тем числом, на которое еще нет списания. Если в On-Line программах, так же нельзя менять к/к если по ней есть расход – то получается что изменить задним числом мы ничего не можем. Хорошо это или плохо – отдельный вопрос, но если сегодня к нам придет повар и скажет что вчера (или в пятницу), у него не кончился определенный продукт, и у поставщиков его больше нет, и он заменил в блюдах этот товар на другой, то для того что бы иметь реальную картину, надо что то делать! Причем делать именно с к/к, а не городить акты переработки. Если у нас On-Line списание, то с пятницы все уже списано, надо отменять списание (если программа это позволяет) править к/к и списывать заново.
Итого: модели On-Line и Off-Line списания имеют каждая свои плюсы и минусы. Актуальность отчетов в первую очередь зависит от того, насколько оперативно в программу вводится первичная документация.
Ответить с цитированием
Сообщение от sibgaba
