Просмотр полной версии : On-Line и Off-Line модели складского учета.
Хотелось бы по рассуждать на тему 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 списания имеют каждая свои плюсы и минусы. Актуальность отчетов в первую очередь зависит от того, насколько оперативно в программу вводится первичная документация.
С 2005-го года существует приложение для обеспечения online-списания для SH4: SH4ST
Доступен на FTP компании UCS, дилеры получали по этому поводу рассылку... Есть описание на support.ucs.ru
Только онлайн списание никому не нужно )
В итоге получается, что точка актуальности, в первую очередь, зависит от своевременного ведения первичных документов (приходов, перемещений м/у складами), а уж потом от On-Line списания.
Золотые слова. Кратко и емко закрыл тему :)
Списание он не производит (списание в SH делается как обычно). Он только справочно рассчитывает текущие расчетные остатки. Проблемы со списанием в минус не возникает (т.к. фактически ничего и не списывается), а вот On-Line остатки он показывает (и они могут быть отрицательными).
КМК, в iiko совершенно аналогичный "онлайн".
чуда не произошло. Выручка заведения не выросла, себестоимость не упала, а наценка продолжала колебаться как обычно.
АААА! Еще более золотые!!!
Не думаю, что есть заведения, которые могут себе позволить менять папки чаще одного раза в месяц.
В Москве есть, это рестораны премиум-класса. Сам работал и сам перепечатывал. Бывало, перепечатывали каждый день, на дорогущей бумаге, на струйных принтерах с дорогущими картриджами (СНПЧ позже появились). Часто не по причине смены цен, а по причине строго наказа: в ресторане такого уровня не может быть стоп-листа, что гость увидел в меню - должно быть.
sibgaba, огромное спасибо за пост! От себя еще добавлю одну цитату:
"а контрамоция обязательно должна быть непрерывной?" (с) Стругацкие
если сегодня к нам придет повар и скажет что вчера (или в пятницу), у него не кончился определенный продукт, и у поставщиков его больше нет, и он заменил в блюдах этот товар на другой, то для того что бы иметь реальную картину, надо что то делать! Причем делать именно с к/к, а не городить акты переработки.
Вот тут спорный момент, зависящий от конкретной ситуации.
Если у нас On-Line списание, то с пятницы все уже списано, надо отменять списание (если программа это позволяет) править к/к и списывать заново.
Нет, тут-то нам и поможет акт переработки. Как и в Shouse, если на инвентуре выясняется, что повара месяц клали в блюда не то - не надо пересписывать.
Задам тему для дальнейшего обсуждения и размышления:
В StorHouse нельзя изменить калькуляцию, если по ней произведено списание. Нам нужно либо отменить списание до нужной даты, изменить к/к этой датой и списать заново.
Вот в iiko можно изменить карту, и у нас автоматически пересчитается все списание, которое мы по карте сделали. Внимание, вопрос: хорошо это или плохо? Что лучше? Может быть, дать волю обоим вариантам? Криминала я не вижу: действительное списание за период совпадает с картами за этот период.
Данный пост родился не сам по себе, а после многих разговоров с людьми (нашими текущими и потенциальными клиентами), которым представители iiko промыли мозги и они как заведенные повторяли: On-Line, on-line, on-line...
КМК, в iiko совершенно аналогичный "онлайн".
Т.е. я правильно понял что айко не делает он-лайн списания? Р/н автоматом не формируются, а есть только расчет он-лайн остатков?
Вот в iiko можно изменить карту, и у нас автоматически пересчитается все списание, которое мы по карте сделали. Внимание, вопрос: хорошо это или плохо?
Оно конечно удобно, но как и любой инструмент - палка о двух концах.
Есть и куча технических вопросов: если уменьшаем закладку, то все нормально. А если увеличиваем, то автоматические пересписание по новой закладке может привести к отрицательным остаткам и что тут делать - не совсем ясно.
Есть и принципиальные вопросы:
Криминала я не вижу: действительное списание за период совпадает с картами за этот период.
Вылезла в конце месяца недостача, меняем (немного увеличиваем) закладку в к/к и недостачи как не бывало, после инвентуры правим к/к обратно. А как это отследить? Получается что нужно отслеживать какой то лог по изменению к/к...
Т.е. я правильно понял что айко не делает он-лайн списания? Р/н автоматом не формируются, а есть только расчет он-лайн остатков?
Там по итогу смены формируется акт реализации, а пока смена не закрыта - некий промежуточный документ. Так что по сути - аналогично.
после инвентуры правим к/к обратно.
Ну и недостача выплывает обратно. А подделать отчеты можно и в Shouse.
Там по итогу смены формируется акт реализации, а пока смена не закрыта - некий промежуточный документ. Так что по сути - аналогично.
А со списанием в минус как поступают?
leopold1984
22.07.2013, 22:30
Тема он-лайн раскрыта полностью.
В целом, и правда, нафига он-лайн если калькулятор заводит приходы два-три раза в неделю в 99% ресторанов?
Он-лайн в целом помогает делать точечные инвентуры, которые опять же имеют смысл если все заведено.
Однако преимущества складского учета в айко не в этом.
А в том, что:
1. Очень легки и просты все пересчеты. Поменяли ТТК задним числом - все пересписалось и пересчиталось в мгновения. Завели накладную посеянную - такая же фигня.
2. Метод учета - ССС (средневзвешенное среднее за период). Это позволяет не парясь работать с отрицательными остатками ибо списание происходит по этой средней цене, что для финансового учета вполне достаточно. Более того, это избавляет калькуляторов от ежедневного гемора с переработками свинины в водку чтобы убрать красное.
3. Есть механизм формирования складских документов через фронт. И если раньше процесс был таким: Бумажка- подпись - лоток - программа - печать - подпись, то теперь он такой: Программа - бумажка - подпись. Это экономит кучу времени калькулятору, который вместо заведения списаний и инвентур занимается их анализом.
Эти преимущества дают следущие возможности:
1. Экономия времени калькулятора. Пример: один ресторан на кипере и сеть из трех ресторанов с фабрикой кухней на айко. Калькулятор один и тот же. Трудозатраты 60% на ресторан на кипере и 40% на сеть с фк на айко. Да и вообще все что касается сети с фабрикой в айко оч хорошо сделано - весь документооборот в электронном виде. от заявки на производство до расходной и приходной накладной.
2. Очень быстрая инвентаризация. У нас в Опен баре 4 барных стойки, адская проходка (до 1500 человек за ночь). После кажой вечеринки в 6 утра старшие бармены быстро делают инвентуру сканером и весами через фронт и тут же ее анализируют, ибо у них к ее итогам сильно оплата привязана.
3. Очень быстрый фин учет. Опять же, для заведений с финансовым циклом в месяц это не очень важно, хотя поулчить опиу 2-го числа бесценно. В опен баре у нас финансовый цикл это одна неделя. Мы подводим итоги КАЖДЫЙ понедельник в 18:00. Открывали это заведение 5 лет назад на тиллипаде и на нем с этим ФИФО и пересчетами в сутки длинной и екселем это все было невозможно.
И он-лайн нужен в первую очередь не для того, чтобы смотреть как цифры на экране бегают, а для того, чтобы благодаря этим трем пунктам я мог опиу смотреть каждый понедельник.
Кто-то увлекается техноложками, а я прибылью
И помимо всех этих бонусов благодаря всему этому наша компания сейчас активно занимается аусторсингом складского учета в ресторанах и весьма успешно. На кипере данную услугу я даже представить себе не могу
экономит кучу времени калькулятору, который вместо заведения списаний и инвентур занимается их анализом
Это есть в RK6, пользуемся.
бармены быстро делают инвентуру сканером и весами через фронт
Это есть в RK6, не пользуемся. Ибо нужен очень мощный заряд, извините, пиздюлей со стороны руководства: Вы у себя обеспечили, но всех не построите. Для справки: инвентаризация в крупном подмосковном клубе с шестью контактными барами и сервис-баром утром "по бумажке" делается за полчаса и тут же анализируется. Что там вбивать, в баре-то!? Они сканируют и взвешивают дольше - проверено - а разливаем не Хенесси Ричардс с Блю Лейбл, чтоб каждую бутылку непременно взвешивать.
При сильном желании - нафиг сканер, нафиг бумажки: тупо бьем на фронте, закрываем на спецвалюту и импортируем в хаус. Вуаля, инвентура готова. Но обновление барменов так часто, что не успеваем учить: проще "на бумажке". К тому же, от рукописной они меньше головой крутят, что ошиблись, тоже проверено. На кассе объяснение "это я не туда нажал" - слишком частое. Нафиг, короче.
хотя поулчить опиу 2-го числа бесценно.
Во всех моих ресторанах - онлайн. В том числе на больших проектах ресторан-кафе-клуб-банкетный в одном лице (это его клуб упомянут в предыдущем абзаце. Да, большой клуб там - только часть). Первого числа всегда готов отчет. Понедельно не делаем - никто не спрашивает, но нет проблем. Да, в эксель. Да, прошлый век. Да, пробовал Капитал (фигня), iiko (фигня, если не улучшили).
для того, чтобы благодаря этим трем пунктам я мог опиу смотреть каждый понедельник
На самом деле, не очень трудно составить планирование и онлайн финансовый учет в эксель. Эксель мне не нравится другим - статистики по сути, нет, ибо анализировать даже за год 12 экселевских файлов - можно, но только по предопределенным параметрам. Покрутить нельзя. Это не очень-то сильно кому надо, поэтому напрягает только смотря из идеального мира. Так что... по факту - никто не страдает.
наша компания сейчас активно занимается аусторсингом складского учета в ресторанах и весьма успешно. На кипере данную услугу я даже представить себе не могу
Однако, предоставляем. Предполагаю, что не слишком дешево, ибо Москва - от 15 тысяч рублей в месяц. Однако, спрос ничтожен. Рестораторы просто не хотят понимать, что там делает бухгалтер-калькулятор: им просто спокойнее, когда на месте сидит человек и занимается, извините, херней за зарплату.
2. Метод учета - ССС (средневзвешенное среднее за период). Это позволяет не парясь работать с отрицательными остатками ибо списание происходит по этой средней цене, что для финансового учета вполне достаточно. Более того, это избавляет калькуляторов от ежедневного гемора с переработками свинины в водку чтобы убрать красное.
Ну, свинину в водку никто не перерабатывает, конечно.
Но в целом - да, здорово. Я уже и забыл. Не удивлены? Мне нравится этот подход. Он действительно подходит подавляющему большинству ресторанов куда больше, чем доскональный учет Shouse - потому что проще, доступнее. И, увы - в большинстве ресторанов и этого нет.
Ну а с другой стороны - круто-круто, но и в хаусе достаточно показать куда дуть и куда нажимать, и на 90% операций сажаются просто исполнители. А аналитику достаточно полчаса в день на ресторан уделить, и то включая непредвиденные ситуации с выяснением.
Поэтому, по факту - не страдаем.
Итог? ДДС ежедневный есть, прибыли и убытки ежедневные есть, планирование есть, товар под контролем. Вывод? Я уже писал в другой теме. Пофиг, в чем вести учет. Я абсолютно верю, что его можно вести в iiko и верю, что Вам больше нравится. Но если кто-то и страдает на RK&SH, то только от того, что поленился оплатить обучение/внедрение. Или оплатил, но не понял. Или понял, но не так... Ну и так далее.
5 копеек про инвентаризацию алкоголя на весах: был подобный опыт, огромный (по моим меркам) клуб. 25 рабочих мест в залах, количество баров - много (точнее не помню). Для экономии времени решили инвентаризировать не весах - столкнулись с большой проблемой. Для хаус позиций, например дешевая водка, которая льется во все коктейли, для литровой бутылки, вес тары в зависимости от партии и завода, колебался на +/- 100 грамм. В баре работает несколько барменов, открытых бутылок несколько, баров много, излишки/недостачи прут.
Ушли от этой технологии...
..............если калькулятор заводит приходы два-три раза в неделю в 99% ресторанов?
это где ж такие ушлепки работают? ..... а может гражданин соврамши?
leopold1984
23.07.2013, 12:05
5 копеек про инвентаризацию алкоголя на весах: был подобный опыт, огромный (по моим меркам) клуб. 25 рабочих мест в залах, количество баров - много (точнее не помню). Для экономии времени решили инвентаризировать не весах - столкнулись с большой проблемой. Для хаус позиций, например дешевая водка, которая льется во все коктейли, для литровой бутылки, вес тары в зависимости от партии и завода, колебался на +/- 100 грамм. В баре работает несколько барменов, открытых бутылок несколько, баров много, излишки/недостачи прут.
Ушли от этой технологии...
В этой технологии самое главное не весы, а сканер.
СКанер снимает с барменов необходимость разбираться во внутренних названиях товаров.
Хаус может быть введен так: пикаем, вводим кол-во
---------- Добавлено в 11:05 ---------- Предыдущее сообщение было размещено в 11:00 ----------
Уважаемый SH, если вы все это это смогли реализовать в кипере, то я перед вами преклоняюсь. Я второго такого человека не знаю.
Но, я приводил пример, на все эти процессы в айко просто уходит гораздо меньше человеко часов дорогих людей
Дважды делал, дважды отказывались, в разных ресторанах. Причина - именно потеря времени. Честно говоря, не представляю, каким образом в iiko снятие через этот геморрой проходит быстрее, чем через бланк. Внутренние названия у алкоголя??? А, ну да, в iiko же бланк инвентаризации не делится по товарным группам!
leopold1984
23.07.2013, 17:54
Дважды делал, дважды отказывались, в разных ресторанах. Причина - именно потеря времени. Честно говоря, не представляю, каким образом в iiko снятие через этот геморрой проходит быстрее, чем через бланк. Внутренние названия у алкоголя??? А, ну да, в iiko же бланк инвентаризации не делится по товарным группам!
У бармена может быть гжелка, березка и еще какая нить водка. А в системе это хаус водка.
Поэтому сканер.
Бармен пикает штрих код и вводит количество. Количество можно получить через весы, линейку или на глаз. Где тут гемор?
Гораздо дольше записать, а потом перенести в программу и проверить
У бармена может быть гжелка, березка и еще какая нить водка. А в системе это хаус водка.
Если бармен не знает, что это хаус-позиции - это не бармен.
Гемор - носить к кассе. Подключать сканер и весы для инвентаризации (да, для некоторых это высшая математика). Если взвешиваем - надо еще и вес тары предварительно вести в склад, и плотность. В общем, по моему опыту - не согласен. В теории все хорошо, но помноженное на человеческий фактор и движуху - получается дольше. Если у Вас иначе - хорошо, но факт того, что в тираж это не пошло, подтверждает мой опыт.
leopold1984
23.07.2013, 23:19
Если бармен не знает, что это хаус-позиции - это не бармен.
Гемор - носить к кассе. Подключать сканер и весы для инвентаризации (да, для некоторых это высшая математика). Если взвешиваем - надо еще и вес тары предварительно вести в склад, и плотность. В общем, по моему опыту - не согласен. В теории все хорошо, но помноженное на человеческий фактор и движуху - получается дольше. Если у Вас иначе - хорошо, но факт того, что в тираж это не пошло, подтверждает мой опыт.
Носить к кассе не надо, нужен длинный юэсби сканере на витом телефонном шнуре.
У нас это используют примерно 20%клиентов
Про сканера и штрихкоды - главное изначально не забыть вбить это все в склад (а кто вводит номенклатуру - у того может и не быть времени со всего алкоголя баркоды обработать). На старте большого бара обычно не до этого. Так что даже блютус сканер не спасет.
leopold1984
24.07.2013, 00:00
Про сканера и штрихкоды - главное изначально не забыть вбить это все в склад (а кто вводит номенклатуру - у того может и не быть времени со всего алкоголя баркоды обработать). На старте большого бара обычно не до этого. Так что даже блютус сканер не спасет.
Ага, на старте это все вообще делать не надо. Надо деньги зарабатывать, а не сканеры внедрять. Вот здесь об этом написано http://www.open-s.info/index.php?id=10
Сканеры - это потом уже, через месяцок-другой
Надо деньги зарабатывать, а не сканеры внедрять. Вот здесь об этом написано http://www.open-s.info/index.php?id=10
Леонид, личная просьба, Вы когда следующий ресторан открывать будите - дайте знать. Очень бы хотел устроиться к Вам барменом на первые 2 месяца работы. Пока Вы будите в качестве себестоимости принимать недостачи, и прикидывать сколько еще столов Вам нужно - я буду зарабатывать...
Леонид, личная просьба, Вы когда следующий ресторан открывать будите - дайте знать. Очень бы хотел устроиться к Вам барменом на первые 2 месяца работы. Пока Вы будите в качестве себестоимости принимать недостачи, и прикидывать сколько еще столов Вам нужно - я буду зарабатывать...
:Dну вы и шутник, sibgaba
У нас бармены каждый день остатки снимают, чтобы передать смену, и можно было понять в какой день что пропало
Шутник в данном случае leopold1984, я только поддержал юмор
Для тех кто не оценил юмора - поясню
В статье http://www.open-s.info/index.php?id=10 написано:
Как считать общий фудкост методом инвентаризации мы вам можем рассказать и показать отдельно в разделе Запуск кладского учета (добавить этот раздел). Суть в том, что заводим все приходы (это не сложно), делаем инвентаризацию как можно чаще. Недостача инвентаризации и есть фудкост. Причем, очень правдивый.
Этот способ позволяет знать затраты на продукты не умирая перед компьютером каждый день.
А то что идет перед этими строками, я могу своими словами пересказать так: Складской учет - это скучно. С Айко это вам нафиг не нужно. Есть способ проще: ведем приходы, ничего не списываем (есть более важные вещи), проводим инвентуру. Все что вылезло на недостачу это и есть наша себестоимость.
Так понятнее в чем смех?
А то что идет перед этими строками, я могу своими словами пересказать так: Складской учет - это скучно. С Айко это вам нафиг не нужно. Есть способ проще: ведем приходы, ничего не списываем (есть более важные вещи), проводим инвентуру. Все что вылезло на недостачу это и есть наша себестоимость.
Так понятнее в чем смех?
Так можно разворовать все, а никто и не заметит:O:
Так можно разворовать все, а никто и не заметит
Так вот я и поспешил записаться на этот аттракцион невиданной щедрости...
Так вот я и поспешил записаться на этот аттракцион невиданной щедрости...
вот у нас, к примеру, стоят везде камеры, но все равно ночью пьют, не стесняются...камеры-то тоже нужно смотреть не лениться...
ой...сорри за флуд
С такой схемой учета, которая описана в статье, бармену пить нельзя - можно очень быстро печень посадить! А вот поработать на благо самого себя - милое дело!
leopold1984
24.07.2013, 17:07
Леонид, личная просьба, Вы когда следующий ресторан открывать будите - дайте знать. Очень бы хотел устроиться к Вам барменом на первые 2 месяца работы. Пока Вы будите в качестве себестоимости принимать недостачи, и прикидывать сколько еще столов Вам нужно - я буду зарабатывать...
Обязательно позову.
Я много лет работал барменом. У меня очень сложно украсть. У меня бармены зарабатывают 4-7 тр за смену. Им безопаснее честно работать
класс!!! надо менять профессию срочно:)
2. Метод учета (в айке) - ССС (средневзвешенное среднее за период). Это позволяет не парясь работать с отрицательными остатками ибо списание происходит по этой средней цене, что для финансового учета вполне достаточно. Более того, это избавляет калькуляторов от ежедневного гемора с переработками свинины в водку чтобы убрать красное.
Вот заинтересовал меня метод учета - ССС (средневзвешенное среднее за период). Начал гуглить, что бы понять как ведется расчет цены в данном случае. Нашел вот такое описание http://referent.mubint.ru/security/8/2796/1#h69 (может быть кто то знает другое)
С практической точки зрения удобно фиксировать среднюю цену на начало интервала и считать ее неизменной на всем периоде. Тем не менее, в Налоговом кодексе РФ присутствует метод расчета средней за период себестоимости, в котором средняя цена рассчитывается на конец интервала, с учетом всего прихода товаров в интервале. Такой подход несколько неудобен. В самом деле, если вычисляется себестоимость отгрузки каждой партии товара, то в течение периода мы должны задать некоторую среднюю себестоимость. Это может быть либо сложившаяся на начало интервала средняя цена, либо средняя цена, рассчитываемая методом скользящего среднего, либо вообще некоторое условное значение стоимости. Затем, в конце месяца, после того как весь приход товара будет обработан и учтен, необходимо рассчитать «истинную» среднюю цену, пересчитать себестоимость всей реализации в интервале и сформировать корректирующую проводку.
Таким образом, в данном методе стоимость может формироваться двумя способами: на начало или на конец интервала. Если средняя цена рассчитывается в начале интервала, то она принимается неизменной на всем интервале, и будущие поставки влияют лишь на среднюю цену следующего интервала. Если средняя цена формируется на конец интервала, то будущие поставки влияют на среднюю цену текущего периода, и средняя цена может быть рассчитана только после достижения конца интервала. Ввиду некоторой непрактичности последняя разновидность метода далее не рассматривается.
Переварив вышеизложенное возникает несколько вопросов:
1. Какой период берется в айке для расчета средней цены?
2. Если средняя фиксируется на начало периода - то фигня получается с себестоимостью овощей и фруктов весной и осенью.
3. Если себестоимость автоматически корректируется по окончании периода, то конечно лучше, но тогда получается что в течение месяца мы имеем в отчетах одни цены, а по окончании периода, после пересчета уже другие. Они конечно более правильные, но все равно не те что предлагались весь месяц для принятия управленческих решений.
Или тут что то еще?
тогда получается что в течение месяца мы имеем в отчетах одни цены, а по окончании периода, после пересчета уже другие
Я слышал от пользователей iiko именно эту версию.
sibgaba
ну что ты бред его разбираешь по составным? его надо рассматривать в целости и желательно быстро пробежав глазами .....
ты же не анализируешь рекламные лозунги автопроизводителей и слоганы с экрана телевизора?
относись проще к этим постам - маркетинговые ходы с минимальным знанием автором ведения учета на предприятии сегмента HoReCa
ну нельзя тексты постов рассматривать отдельно от личности автора - там такой набор некомпетентности и практически провальных проектов....
Я слышал от пользователей iiko именно эту версию.
Ну вообще тогда зашибись учет получается!!!
Ну вообще тогда зашибись учет получается!!!
Это одна из основных причин отказа от... сразу на втором месте после "мы тут ничего не понимаем, поставьте нам ...!!!"
Vasiliy Yartsev
27.09.2013, 21:06
Переварив вышеизложенное возникает несколько вопросов:
1. Какой период берется в айке для расчета средней цены?
2. Если средняя фиксируется на начало периода - то фигня получается с себестоимостью овощей и фруктов весной и осенью.
3. Если себестоимость автоматически корректируется по окончании периода, то конечно лучше, но тогда получается что в течение месяца мы имеем в отчетах одни цены, а по окончании периода, после пересчета уже другие. Они конечно более правильные, но все равно не те что предлагались весь месяц для принятия управленческих решений.
Или тут что то еще?
Тут что-то еще.
ССС - это СКОЛЬЗЯЩАЯ СРЕДНЕВЗВЕШЕННАЯ СЕБЕСТОИМОСТЬ. Она от периодов не зависит.
Скользящая средняя себестоимость — это не за период, это в момент списания (то же самое можно сказать про метод FIFO).
Маленький ликбез
Себестоимость чего-либо за период можно посмотреть в отчетах (что в iiko, что в SH, что в 1С) и там она обязана быть средней. Иначе теряется смысл слов "за период".
Себестоимость в момент списания — это себестоимость "котлеты в момент ее продажи". Она нужна для того, чтобы понимать, как меняется foodcost (себестоимость / цену продажи) во времени в условиях меняющихся цен закупки.
Как считается ССС?
Все просто: вводится понятие себестоимость товара на складе (это и будет наша ССС). Она рассчитывается так: все партии товара "объединяются в одну" (грубо — суммируются стоимости и делятся на кол-во), которая имеет одну цену. При списании (продаже, перемещении) берется именно эта цена. При каждом новом приходе товара эта цена пересчитывается (важно, что она пересчитывается на складе, а не в документах: если мы списали товар вчера по 100р, а сегодня был приход по 120 и ССС стала 110, эта 110 возьмется в будущих расходах, вчерашний так и будет по 100р.).
Разница между FIFO и CCC
Тут тоже все просто: в случае FIFO себестоимость меняется в момент расхода (когда заканчивается одна партия и начинается вторая), а при ССС себестоимость меняется в момент прихода. Идеологически это значит, что в случае FIFO мы не учитываем потраченные деньги до того, как у нас израсходуется предыдущая партия, а в ССС мы начинаем их учитывать с момента поставки товара на склад.
Очевидно, что разница между двумя цифрами будет тем меньше, чем меньше неуменьшаемый товарный запас: а это как раз то, к чему стремятся большинство ресторанов - частые небольшие закупки тогда, когда остаток на складе близок к нулю.
Особо пытливые умы могут посмотреть картинку с примером — там видна разница в цифрах и графиках на примере закупки по алгоритму если у нас осталось меньше минимума, закупаем до максимума. В примере минимум = 5, максимум = 10, средние продажи в день = 3. Если вы настолько пытливы, что хотите посмотреть на формулы, которые это считают (в Excel), напишите, выложу файл.
Зачем нужен метод ССС?
Метод ССС имеет ряд преимуществ перед старым добрым FIFO. Вот они:
ССС позволяет дать быстрый ответ на вопрос: "Сколько сейчас стоят помидоры у нас на складе?" и этот ответ в точности совпадет со значением, которое система отразит в расходных документах за сегодняшний день. В случае с FIFO вы либо получите несколько разных значений (у нас есть 5кг по 100р, 3 кг по 110р и 5 кг по 120р.), либо будете вынуждены считать среднее (13 кг по 110р), которое вам ни о чем не скажет: ведь в расходе возьмутся 100р. от первой партии.
ССС позволяет раньше чувствовать изменения закупочных цен в складских остатках (поскольку себестоимость "сглаживается")
CCC с некоторыми оговорками (на самом деле, не оговорками, а небольшим усложнением формулы) позволяет работать с отрицательными остатками, а, значит позволяет автоматически проводить документы там, где раньше требовался оператор
для ССС требуется на порядок меньше вычислений (поэтому его реализации работают быстрее)
Кроме этого, с уверенностью можно сказать, что в реальном ресторане обеспечить списания (не учет, а именно списания) по FIFO практически невозможно, поэтому физический смысл такого учета не совсем ясен. Зачем делать вид, что мы списываем все по очереди, когда на самом деле это не так?
2400
Идеологически это значит, что в случае FIFO мы не учитываем потраченные деньги до того, как у нас израсходуется предыдущая партия, а в ССС мы начинаем их учитывать с момента поставки товара на склад.
Вот только этот момент не смог осознать. При тут деньги?
И, в выводы по преимуществам, должен внести важную оговорку: эти преимущества нивелируются, если разработчики программы с FIFO предусмотрели отдельные инструменты для достижения тех же целей. Реализация конкретно в SHouse учитывает недостатки модели FIFO и решает все, кроме отрицательных остатков. Для решения этой задачи в Shouse Требуется поддержка скриптов, или задания алгоритмов списания - тогда оператор тоже не нужен будет. Так что все упирается в реализацию метода.
По сути: возможность SH4 смотреть определенные отчеты с учетом цен последнего прихода - самый лучший вариант. Мы берем не "старую партию", и не среднюю - мы берем актуальные закупочные цены. Да, средняя лучше, чем стоимость самой старой партии, но для оперативного контроля важнее знать актуальные цены на момент запроса. Было бы круто, если бы iiko умела брать себестоимость из последнего прихода для просмотра текущей себестоимости.
Если вы настолько пытливы, что хотите посмотреть на формулы, которые это считают (в Excel), напишите, выложу файл.
Хотелось бы посмотреть (для собственного понимания).
В целом согласен с аргументом о том что чем меньше остатки на складах - тем меньше разница в цифрах у разных методов учета.
В пределе, если у нас абсолютно пустой склад, и каждый раз когда гость заказывает 50 мл водки мы бежим к поставщику и закупаем ровно 50 мл, то цифры вообще совпадут (должны совпасть, для этого и хочу в формулах разобраться).
И все равно, 2 момента которые есть в StoreHouse, в плане контроля за изменением себестоимости (будущего периода) дают очень четкое понимание того что у нас будет "завтра". Это "Предполагаемая стоимость товаров" и расчет себестоимости (справочный) при просмотре к/к, который можно делать по цене последнего прихода.
ответа не дождался - пошел разбираться сам...
В процессе нарыл тему в ЖЖ http://andreysemenov.livejournal.com/292865.html
Этот журнал уже обсуждали (но по другой теме), тут эмоций поменьше, фактов побольше...
1. Получается что действительно а Айке возможна ситуация когда сегодня в отчетах по себестоимости (и следовательно и в ОПИУ?) мы видим одни цифры, а завтра это могут стать другие цифры. Вот цитата с примером (это пишет человек лояльный к iiko):
Alex Slad (http://www.facebook.com/alex.lepeshkin)
Обращаю Ваше внимание, что себестоимость в указанных выше отчётах может меняться, прыгать.
Основные причины:
1. Изменение ТТК задним числом
2. Если у Вас на складах отрицательные остатки по причине несвоевременного занесения всех первичных документов(приходные накладные, акты списания, перемещения). Что происходит в этом случае. Например я покупал морковь по 10 рублей, мне привезли новую морковь по 100 рублей, но я её ещё не забил в iiko. Программа создаёт на складе отрицательный остаток и считает себестоимость этой моркови по средневзвешенной себестоимости. Если сформируем Отчёт о продажах, то себестоимость будет X, когда мы оприходовали морковь по новой цене на отрицательный остаток, то себестоимость естественно скакнёт вверх. Именно поэтому для принятия серьёзных управленческих решений рекомендуется сначала заносить всю первичку, закрывать период и потом принимать решения на основании ОПИУ и Отчёта о продажах
Собственно опять пришли к тому о чем я говорил: On-Line у нас или Off-Line - не важно. Цифры (в ОПИУ, в себестоимости) не будут верными пока не введем всю первичку...
ИМНО: Такой плюс ОнЛайна как контроль себестоимости можно хоронить...
2. Как там тему не крутили, вроде сходятся к тому что действительно в 3-х отчетах себестоимость разная, и поэтому (я утрирую) ее нужно смотреть в другом месте ;)
ответа не дождался - пошел разбираться сам...
Почему скачет себестоимость? Если не редактировать задним числом, то всё совпадает. Если начать редактировать документы и править тех карты задним числом - то конечно будет меняться себестоимость, иначе учет можно хоронить...
Вот реальный пример - инвентаризация. ОПИУ построили, распечатали. вроде всё четко. Но нашли накладную на 20 литров водочки... След в инвентаризации эта водочка уже с минусом, след недостачи = 20 литрам = примерно 5000р. Перед вами вопрос - ввести накладную задним числом и тогда в ОПИУ данные изменятся, или... Ввести накладную текущей датой, и тогда в следующей инвентаризации будут излишки.
решать вам, но iiko позволяет делать и так и сяк.
Если кто не знает, то в iiko можно отключить online остатки, и поставить запрет на редактирование задним числом всего и вся...
Почему скачет себестоимость?
Дык вот же пример:
Например я покупал морковь по 10 рублей, мне привезли новую морковь по 100 рублей, но я её ещё не забил в iiko. Программа создаёт на складе отрицательный остаток и считает себестоимость этой моркови по средневзвешенной себестоимости. Если сформируем Отчёт о продажах, то себестоимость будет X (порядка 10 рублей), когда мы оприходовали морковь по новой цене на отрицательный остаток, то себестоимость естественно скакнёт вверх.
Соответственно после того как мы сделали приход - себестоимость в отчетах изменилась. Инвентаризаций не было... На излишки (да и какие это к черту излишки то, если реально на кухне морковь была) не спишешь...
Если кто не знает, то в iiko можно отключить online остатки, и поставить запрет на редактирование задним числом всего и вся...
И тем самым потерять один из 3-х основных плюсов (On-Line списание и отчетность) которыми кичится айка?
Vasiliy Yartsev
08.11.2013, 17:10
Сорри, что отвечаю так поздно: почему-то не пришло уведомление об ответах, а сам я в раздел StoreHouse не лазил.
Вот только этот момент не смог осознать. При тут деньги?
Про деньги я имел в виду следующее:
Допустим, у нас на складе есть 30кг картошки по 30р., которой нам хватит на три дня. Понимая это, мы сегодня покупаем еще 50 кг картошки, но уже по новой цене 40р. То есть, деньги мы потратили сегодня, и сегодня же у нас пополнился склад. В случае с методом AVG это сегодня же отразится на себестоимости. При FIFO себестоимость поменяется только через три дня.
Да, средняя лучше, чем стоимость самой старой партии, но для оперативного контроля важнее знать актуальные цены на момент запроса. Было бы круто, если бы iiko умела брать себестоимость из последнего прихода для просмотра текущей себестоимости
Так умеет же. Прямо в технологической карте и показывает, рядом со средневзвешенной.
Vasiliy Yartsev
08.11.2013, 17:23
Файл с расчетом — 2478
Безопасно править можно цифры, выделенные красным, остальные — на свой страх и риск)
Vasiliy Yartsev
08.11.2013, 18:07
Собственно опять пришли к тому о чем я говорил: On-Line у нас или Off-Line - не важно. Цифры (в ОПИУ, в себестоимости) не будут верными пока не введем всю первичку...
ИМНО: Такой плюс ОнЛайна как контроль себестоимости можно хоронить...
У ОнЛайна есть два плюса:
Первый в том, что мы получаем информацию без задержки. Эта информация может быть разная: например, наличие "отрицательных" остатков говорит нам, что у нас присутствуют ошибки в учете (не отражен приход товара или некорректно заполнены рецепты), но нет смысла оспаривать тот факт, что ее наличие помогает принимать решения быстрее. Этот плюс — в первую очередь для владельца / управляющего.
Второй плюс — это то, что при нахождении ошибки мы можем ее сразу же исправить без длительной процедуры "откатывания" (или "перепроведения"). Этот плюс — для оператора (бухгалтера-калькулятора) который следит, чтобы первичка была введена, техкарты были правильными, а информация по складу достоверной, и по роду своих занятий должен исправлять найденные ошибки.
Первый плюс можно нивелировать идеальным администрированием: когда учет ведется день-в-день, операторы заменяют друг друга в случае болезни/отпуска/выходных и т.д. Проблема только в том, что в реальной жизни не бывает ничего идеального, и держать "взаимозаменяемых" сотрудников слишком дорого. В реальности, то, что мы видим у 9/10 клиентов, выглядит так: бух-калк считает своей обязанностью следить за складом, то есть вводить первичку и сравнивать книжные остатки с инвентаризацией. Поэтому у него в принципе нет задачи вести ежедневные списания: инвентура-то делается раз в месяц. Директор или владелец сам не открывает стор-хаус, потому что сторхаус - это программа для бухгалтера-калькулятора, там все сложно. Вместо этого он получает отчет о себестоимости, остатках и т.д. раз в месяц. Как результат — контроль "раз в месяц".
http://www.carbis.ru/forum/images/misc/quote_icon.png Сообщение от sibgaba http://www.carbis.ru/forum/images/buttons/viewpost-right.png (http://www.carbis.ru/forum/showthread.php?p=62849#post62849)
Например я покупал морковь по 10 рублей, мне привезли новую морковь по 100 рублей, но я её ещё не забил в iiko. Программа создаёт на складе отрицательный остаток и считает себестоимость этой моркови по средневзвешенной себестоимости. Если сформируем Отчёт о продажах, то себестоимость будет X (порядка 10 рублей), когда мы оприходовали морковь по новой цене на отрицательный остаток, то себестоимость естественно скакнёт вверх.
Соответственно после того как мы сделали приход - себестоимость в отчетах изменилась. Инвентаризаций не было... На излишки (да и какие это к черту излишки то, если реально на кухне морковь была) не спишешь...
Я не понял, что вам кажется странным или неправильным? То, что себестоимость изменяется при вводе данных "задним числом" или сама возможность "ввода в прошлом"?
Я попробую зайти с другой стороны:
Когда вы нашли ошибку в "прошлом" (пусть, как в нашем примере, не введен приход товара), независимо от того, в какой программе вы работаете, у вас есть выбор: исправить ошибку или отразить ее в учете. Исправить в нашем случае — это ввести приход задним числом. Отразить — это оприходовать красный остаток в инвентаризации и сделать переоценку текущей партии товара с учетом стоимости прихода, который вы забыли ввести ранее. По-моему, второй вариант — это страшный сон, оказаться в котором разумный человек может только при отсутствии первого варианта (возможности исправить ошибку).
Однако, исправление задним числом — это довольно ресурсоемкая операция, поскольку требует большого кол-ва вычислений, особенно при использовании схемы FIFO для расчета себестоимости, и сделать ее быстрой реально непросто. Поэтому большинство программ, при работе по FIFO, просто запрещают проведение документов, приводящих к красным остаткам (iiko здесь не исключение). Как идеальный результат мы должны бы получить учет без ошибок "в прошлом". В реальности, понятно, этого не происходит, поскольку закупки делаются до того, как товар закончится, и до того как остаток станет отрицательным, он уже несколько дней будет неверным (хоть и > 0). В результате, все равно придется пересчитывать задним числом или извращаться с инвентаризацией и переоценкой.
И тем самым потерять один из 3-х основных плюсов (On-Line списание и отчетность) которыми кичится айка?
Ну почему потерять? Если клиент поставил задачу - никаких отриц остатков и никаких исправлений задним числом - то iiko это позволяет сделать.
У нас есть такой клиент, и всё у него работает, его iiko устраивает полностью.
По поводу отчета ОПИУ и прихода на отриц остатки. Вот 2 скрина, показывающие, что при приходе на отриц остатки все отображается корректно.
В них четко видно
что себестоимость первого прихода не изменилась
что после прихода на отриц остатки себестоимость минусовых остатков - корректно рассчиталась по средней ССС.
видно что себестоимость первого прихода не изменилась. (хотя кто-то утверждал что она меняется)
Я тут ничего противоречащего не вижу. Если я не прав, поправьте меня.
P.S. всё делал на пустой БД, с одной товарной позицией.
24802481
Vasiliy Yartsev
08.11.2013, 19:35
что себестоимость первого прихода не изменилась
что после прихода на отриц остатки себестоимость минусовых остатков - корректно рассчиталась по средней ССС.
Это все так, но мы сейчас не совсем об этом.
Официальный дисклеймер: приходование на "отрицательные" остатки — это ОЧЕНЬ ПЛОХАЯ ПРАКТИКА. Мы настоятельно рекомендуем никогда так не делать.
Та коррекция себестоимости, которая видна на картинках еще выплывет у вас в отчетах (потому что кто-то может снять отчет, например, за 1.11.2013—6.11.2013, а из него не видно, почему себестоимость такая) и обычному пользователю осознать, откуда она такая посчиталась, будет очень сложно.
Пытался разобраться в методе расчета себестоимости по скользящей средней, а именно в вопросе за какой период берутся приходы для усреднения цены. И как все это считается на конкретных примерах.
Вводные данные:
Самое начало работы, остатки 0, движение 0
1. Приход 1 кг по цене 150
После этого СС = 150
2. Приход 1 кг по цене 250
После этого себестоимость пересчитается по формуле СС = (150+250)/2=200
3. Расход 1 кг. Себестоимость этого товара составит 200.
Сумма по накладной тоже 200
Остаток 1 кг по цене 200 (мы ее уже усреднили)
4. Приход 1 кг по цене 300. Нужно пересчитать ССС
Дальше начинаются варианты:
Вариант №1 (мой)
В расчете себестоимости принимает участие только не списанный товар
ССС = (200+300)/2=250
5. Расход 2 кг. Себестоимость составит 500.
ИТОГО:
Количественный остаток: 0 (3 кг получили, 3 списали)
Сумма приходов за период: 150 + 250 + 300 = 700
Себестоимость списанного за период= 1*200+2*250=700
Суммовой остаток: 0
Вариант №2 (бухгалтера говорят что так)
Расчет себестоимости ведется по всем приходам за некий отчетный (не закрытый) период. В нашем случае по всем 3-м приходам.
ССС = (150+250+300)/(1+1+1) = 700/3 = 233,33
5. Расход 2 кг. Себестоимость составит 466,66
ИТОГО:
Количественный остаток: 0 (3 кг получили, 3 списали)
Сумма приходов за период: 150 + 250 + 300 = 700
Себестоимость списанного за период= 1*200+2*233,33=666,66
Суммовой остаток: 33,34
Получается что во втором варианте, после того как мы спишем все количество товара, на остатках зависает некая сумма при нулевом количестве.
Для того что бы сошлись концы с концами при таком способе расчета, после 3-го прихода, надо изменить себестоимость первого списанного килограмма с 200 на 233,33.
Вопрос: Какой из вариантов правильный и как считает Айка?
Если никакой - то как нужно считать?
Если я правильно понимаю, то айка считает по варианту 2. И да, происходит пересчет. Отсюда и проблемы у тех, кто работал с хаусом по фифо. Пересчитывается весь расход товара по приходным накладным, которые учитываются в подсчете среднего.
Если я правильно понимаю, то айка считает по варианту 2.
ttttttt
Ну блин не может быть! Не должно так быть...
Пересчитывается весь расход товара по приходным накладным, которые учитываются в подсчете среднего.
Тогда следующий логичный вопрос: Где (кем, как, когда) определяется за какой период брать п/н для расчета ССС? И, как следствие, за какой период у нас будет меняться себестоимость в уже сделанных (и проведенных) р/н?
И еще: себестоимость старых (уже проведенных р/н) в какой момент изменится: в момент нового прихода или в момент "закрытия периода"?
Хотелось бы заслушать представителей противоположной стороны...
Или, у кого есть доступ к этому сакральному источнику, возьмите чистую базу, забейте товародвижение как в примере, и расскажите (только чур честно!) что получится...
Brambrulet
27.04.2014, 02:05
Представители где-то писали, что после получения отчётов периоды принято закрывать ... в результате редактировать в закрытых периодах ничего нельзя - отчёты изменятся. Соответственно все перерасчёты касаются только открытого периода.
Т.е. получается так:
В Складе (в Айке) списалась вчерашняя реализация, для нее рассчиталась определенная себестоимость.
Я формирую отчеты (Марочный, БДР, ОПИУ) - круто я вижу прибыль.
Потом приходит бухгалтер калькулятор, и начинает вбивать приходы сегодняшнего дня и у меня, чудесным образом, изменяются финансовые итоги работы за вчера???
Я готов согласиться с утверждением, что когда у нас на кухне лежат 2 партии товара (Первая - дешевая и Вторая - дорогая), то мы не можем контролировать повара и быть уверенным в том что он при производстве соблюдает партионность. И в этом случае ССС должна показывать более реальную картину. Хотя опять же вопрос: Куда смотри Шеф-повар и Су-шеф?
Но я не могу взять в толк, как более дорогой товар, пришедший на склад сегодня, влияет на себестоимость блюд проданных вчера?
Я так понимаю, что для борьбы с этой печалью, предусмотрена процедура закрытия периода. И если мы сегодня с утра, перед тем как вбивать новые приходы, закроем период, то показатели в отчетах зафиксируются.
В реальности я знаю крайне мало заведений, которые готовы закрывать период хотя бы раз в неделю. В лучшем случае раз в месяц.
И если это так, то в течение всего открытого периода (неделя, месяц) у меня плавают цифры в отчетности.
Хорошо, давайте скажем что они не плавают, а усредняются... Весной (у нас это обычно в Мае) себестоимость овощей (огурцы, помидоры и т.п.) за месяц упадет вдвое. И я этого не увижу...
Еще вопрос: на кухне испортилась партия товара (которая была куплена давно, и мы точно знаем, что эта партия стоила совершенно определенных денег). Почему сегодня ее нужно списывать по усредненной цене?
Потом приходит бухгалтер калькулятор, и начинает вбивать приходы сегодняшнего дня и у меня, чудесным образом, изменяются финансовые итоги работы за вчера???
Да, именно так.
В этом и была претензия в той теме в ЖЖ.
Но я не могу взять в толк, как более дорогой товар, пришедший на склад сегодня, влияет на себестоимость блюд проданных вчера?
С точки зрения учета по среднему - все ок.
Учет по среднему не предназначен для получения правильных отчетов за краткий период. Ему надо хотя бы месяц. Это другой подход, он близок к "котловому" методу.
Vasiliy Yartsev
27.05.2014, 00:33
Привет всем) Очень приятно, что вы интересуетесь и стараетесь разобраться. Хоть и несколько странно возвращаться к этому спору в 2014 году)))
Итак, еще раз по порядку:
Если я правильно понимаю, то айка считает по варианту 2.
Нет, вы понимаете неправильно. Смотрите картинку с примером sibgaba. Очевидно, что на 5-м ходу и количественный, и суммовой остаток — 0.
2804
Но я не могу взять в толк, как более дорогой товар, пришедший на склад сегодня, влияет на себестоимость блюд проданных вчера?
Если вы приходуете на положительный или нулевой остаток, то никак не влияет.
Если на отрицательный — другое дело. Поскольку там есть потенциальная проблема: представьте, что будет, если на третьем шаге в нашем примере мы спишем не 1, а 3 кг?
:rule:
Собственно, мы можем ограничить пользователя уже здесь, запретив ему проводить расход, если он формирует отрицательный остаток. Но такой подход ограничивает предоставление информации пользователю: если мы не проводим расход, мы не считаем себестоимость и заказчик (владелец или директор ресторана) не увидит заветных цифр и будет зависеть от калькулятора, который должен принять решение, что же делать с отрицательным остатком. Впрочем, пользователь сам может решить, какой вариант для него лучше — в Айко есть настройка, которая позволяет запретить проведение документов, приводящих к отрицательным остаткам.
Если же мы позволим провести расход, у нас получится отрицательный остаток с "какой-то" себестоимостью. "Какая-то" она потому, что мы не знаем, какая она должна быть. В случае Айко мы предполагаем, что такая же, как и раньше. Это делается для того, чтобы более достоверно представить "мгновенную" себестоимость (поскольку в большинстве случаев отрицательный остаток вызван забытым приходом). На самом деле, сейчас это совершенно не важно, главное, чтобы вы понимали, что в этом случае себестоимость списания зависит только от выбора разработчика и является некой условностью.
Итак, у нас получился остаток -1 кг по цене 200 рублей. Вроде бы все ОК, переходим к 4-му шагу и приходуем 1 кг по 300р. В результате —долгожданная проблема: у нас есть нулевой по кол-ву остаток на сумму 100р, а средневзвешенная цена ушла в бесконечность.
:rule:
Собственно, мы можем снова ограничить пользователя и запретить приходовать на отрицательный остаток. В Айко это регулируется правами доступа.
Система понимает, что это — проблема, и нулевое кол-во не может стоить 200 рублей. Как можно выкрутиться? Вспоминаем, что у нас с 3-го шага осталась "какая-то" себестоимость, и мы можем ей играть: например, подогнать ее так, чтобы сумма в результате 4 шага получилась нулевой. Смотрите на картинку.
2803
Вот в этом случае система поменяет данные в "прошлом".
Конечно, если перед 4-м шагом мы закроем период, то этого не произойдет, и цифра себестоимости будет совсем "кривой". Поэтому во всех руководствах и на обучении пользователям говорят, что ни в коем случае нельзя закрывать период с отрицательными остатками на складах.
В реальности я знаю крайне мало заведений, которые готовы закрывать период хотя бы раз в неделю. В лучшем случае раз в месяц.
Да, по умолчанию в Айко открытый период — два месяца.
И если это так, то в течение всего открытого периода (неделя, месяц) у меня плавают цифры в отчетности..
Этот вопрос снят?
Но я не могу взять в толк, как более дорогой товар, пришедший на склад сегодня, влияет на себестоимость блюд проданных вчера?
С точки зрения учета по среднему - все ок.
Учет по среднему не предназначен для получения правильных отчетов за краткий период. Ему надо хотя бы месяц. Это другой подход, он близок к "котловому" методу.
Алексей, Алексей. Вот от кого точно не ожидал услышать подобную ерунду.
"Учет по среднему" — это такой же точно учет, как и по Фифо, отличаются только правила расчета себестоимости складского остатка. Он предназначен для того же самого, что и фифо, и не имеет никаких недостатков перед фифо, кроме разве что того, что лично вам непривычен. И от "котлового" метода далек ровно так же, как и фифо.
Надеюсь, мой опус был кому-то полезным.
Спасибо за ответ.
По картинке получается все таки вариант №1. Т.е.в расчете ССС принимает участие только НЕ списанный товар. У нас в деревне, одни "официальный представитель", с уверенность заявляет обратное (что расчет ССС по приходам за весь не закрытый период).
Отсюда, при минимизированных товарных остатках (а за это сейчас борются все), себестоимость, рассчитанная по ССС, будет приближаться к цифрам полученным по FIFO.
В Системе StoreHouse, право на списание в минус (и автоматическое получение данных по себестоимости реализованных блюд) было всегда (еще со времен 3-ки, а то и 2-ки). В системе складского учета SH можно разрешить списание в минус и тем самым, не зависимо от работы оператора (вводящего первичку), получать данные по себестоимости. Тут ничего нового я не вижу.
поскольку в большинстве случаев отрицательный остаток вызван забытым приходом
Вот тут не соглашусь. В большинстве случаев он вызван не верной тех. картой (завышенная закладка, не верный компонент) или не соблюдением тех. карты (недозаклад, пересорт).
На самом деле, сейчас это совершенно не важно, главное, чтобы вы понимали, что в этом случае себестоимость списания зависит только от выбора разработчика и является некой условностью.
Тогда и доходность получаемая в вашей программе тоже некая условность?
...
проблема: у нас есть нулевой по кол-ву остаток на сумму 100р, а средневзвешенная цена ушла в бесконечность.
Собственно, мы можем снова ограничить пользователя и запретить приходовать на отрицательный остаток. В Айко это регулируется правами доступа.
А StoreHouse заранее позаботился о своих пользователях и не допускает такого бреда в принципе.
Как показывает практика, в среднестатистическом заведении, как только разрешаем калькулятору списывать в минус - скорость списания увеличивается, а вот качество падает. Никто из калькуляторов не заинтересован в том что бы сидеть и искать причину красноты. И если минус возник из за отсутствующего прихода - это в итоге всплывет в акте сверки с поставщиком и будет исправлено. Но если минуса возникают из за не верных к/к или их не соблюдения, то эти ошибки спокойно игнорятся, не исправляются, и кочуют из одного периода в другой, извращая отчетность... Стимула для их исправления у юзера никакого. В этом смысле StoreHouse ведет себя жестче. Отсюда картина в учете получается более строгая.
Как ни странно бы это прозвучало, но у StoreHouse есть спец. версия позволяющая вести приходы на отрицательные остатки. Насколько я знаю, разработана она была под конкретного сетевого заказчика, корни которого произрастают из за океана. И его мало волнует точность складского учета (там же не воруют). Опять же знаю, что по настойчивым просьбам некоторых клиентов, им была установлена данная версия Склада. Они ею попользовались и вернулись к стандартной...
Vasiliy Yartsev
27.05.2014, 20:06
По картинке получается все таки вариант №1. Т.е.в расчете ССС принимает участие только НЕ списанный товар. У нас в деревне, одни "официальный представитель", с уверенность заявляет обратное (что расчет ССС по приходам за весь не закрытый период).
Отсюда, при минимизированных товарных остатках (а за это сейчас борются все), себестоимость, рассчитанная по ССС, будет приближаться к цифрам полученным по FIFO..
Ну вы намешали))
На самом деле, верны все три утверждения, которые вы привели.
1) да, вариант 1. 2) да, ССС пересчитывается за весь не закрытый период (а в закрытом ничего не пересчитывается). И это совсем не "обратное" п. 1, они вполне уживаются вместе. Имеется в виду, что если вы вносите документ "задним числом", то он поменяет вам себестоимость уже состоявшихся реализаций.
3) да, при минимизированных остатках, за которые все борются, за период ССС практически = FIFO (и это видно в том экселе, который я приводил где-то в середине этой темы) и это совсем не из-за того, что себестоимость считается как-то по-особенному. Это потому что за период (смотрите http://www.carbis.ru/forum/showthread.php?t=7459&p=61395&viewfull=1#post61395)
В Системе StoreHouse, право на списание в минус (и автоматическое получение данных по себестоимости реализованных блюд) было всегда (еще со времен 3-ки, а то и 2-ки). В системе складского учета SH можно разрешить списание в минус и тем самым, не зависимо от работы оператора (вводящего первичку), получать данные по себестоимости. Тут ничего нового я не вижу.
А что именно "нового" вы хотели увидеть? :O:
Тогда и доходность получаемая в вашей программе тоже некая условность?
:wall:И в нашей, и в вашей, и в любой другой. Если вы допускаете отрицательные остатки, то оказываетесь в некоей сингулярности (не бывает в жизни -5 кг картошки), и да, любая посчитанная доходность в этом случае будет условной. А когда введете точную первичку, правильные техкарты и отразите пересортицу (и все пересчитаете), доходность станет верной. Отличие Айко только в скобках: "все пересчитаете" работает без дополнительных действий и прилично быстро.
По поводу приходования на отрицательные остатки, это не совсем абсолютное зло. Это плохая практика, да, но в реальной жизни случается, и очень удобно, если программа умеет отработать такую ситуацию.
А StoreHouse заранее позаботился о своих пользователях и не допускает такого бреда в принципе.
у StoreHouse есть спец. версия позволяющая вести приходы на отрицательные остатки
Как ни странно бы это прозвучало
:facepalm:
Powered by vBulletin® Version 4.2.6 LTS Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot