Учебная задачка: сделать систему учета для ресторана.

Да забей не будет ресторанов больше

Если закупки всегда по одной цене ("себестоимости") нет такого что один ингредиент закупается дороже/дешевле то все достаточно просто.
Если же надо среднюю себестоимость считать тут уже хехе.

(4) развернуть блюда по спецификации на продукты-тут основная проблема,что спецификацию чуть ли не под каждый выпуск править надо.

В блюде добавь табличную часть Спецификация. Ингредиент справочник Ингредиенты. Второй реквизит - Количество. При проведении заказа при статусе Выдан, списывай ингредиенты в регистре накопления. Или вместо табличной части сделай подчиненный справочник Спецификации, владелец Блюда

(0) Учебное заведение какое, если не секрет? Такое ощущение, что единый задачник разработан.

(0) А у меня вот другой вопрос, к опытным 1С-кам. Как будете реализовывать движение статуса заказа (Заказы имеют 3 состояния: принят, выдан и отменен)?

(8) Почти во всех общепитных системах учета есть "пречек"

(9)+ В смысле лично я бы делал двумя документами а не сменой статуса всего одного

(4) Технологические карты делают.
Ну они все равно есть в реальности. Просто бывает часто, что если делают дописку на основе типовых, то там привязываются к ресурсным спецификациям.
Но у пищевиков это технологическая карта.

Рабочий процесс обычно разворачивают на несколько документов. В принципе, ничего сложного, но нужно все разрисовать/расписать. Довольно громоздко получится.

зы. Перечитал топик - там же все расписано, только не введены понятия, что Документ, что Справочник, что Регистр и т.п.

Что тут городить? написано же в (0) "учебная задачка". На клюшках это все вообще быстро делается такого уровня задачка без краасивостей но с рабочим функционалом. а на снеговике еще и красиво сразу получится.

(4) Когда блюдо готовишь - минусуешь из регистра то количество продуктов, которое необходимо для приготовления блюда, в чём вопрос? В условии, что списание из остатков происходит только при выдаче заказа, а не при приготовлении?

(13) зависит от того полагаем что у нас бездонная кладовка с запасами при приготовлении блюда или нет

(0) Сабж прочитал. А вопрос в чем?

(15) Невысказанный вопрос: "Не сделает ли кто-нибудь мне курсач забесплатно?"

(8) А в чем проблема? Док Заказ в статусе принят не списывает продукты, в статусе выдан списывает.

(14) "Ингредиенты закупаются по себестоимости и сумма закупки должна учитываться в регистре остатков."

Значит должен быть док закупки.

(17) Заказ = "принят", а потом приходишь и говоришь клиенту "сорри. но на отбивную для вас - мяса не хватило, вон тот толстый дядечка кушает порцию мяса последнюю"..?
если заказ=принят, то все ингредиенты должны стать "в резерв", дабы обеспечить потенциальную возможность перевода заказа в статус "кушать подано". А что в резер вне становится - из заказа исключается. Ибо предполагаем, что клиентне станет ждать закупа продуктов или ждать что кто-то откажется от заказа.  если "по уму" - то отказные позиции в заказе (не хватило продуктов) должны стать в "очередь ожидания", и если вдруг продукт sgjzdzncz по той или иной причине - то потенциально идем к клиенту и говорим, "...вы знаете внезапно подвезли ваше любимое фуагра урожая 1953г, подать?"

(19) Насколько я понял, это учебная задача. Критерия наличия по остаткам не озвучено.

(19) В условии никаких "резервов" нет. Даже контроля остатков не требуется.
Хватает ингредиентов для заказа или нет, решается не по остаткам в учете а прямо на кухне. Если не хватает, заказ отменяется или корректируется.

Мне не очень понятно, почему выручка идет в тот же регистр остатков. А не в регистр оборотов, например. Но для учебной задачи можно и так.

(21) "Клиенты заказывают несколько блюд, блюда собираются в заказы, заказы отправляются на готовку и выдачу, после выдачи продукты списываются из остатков."
.
- "Хватает ингредиентов для заказа или нет, решается не по остаткам в учете а прямо на кухне. Если не хватает, заказ отменяется или корректируется."
.
Заказ не может корректироваться. клиентЫ заказывают БЛЮДА. я и ты заказали стейк, 2шт. эти два блюда собрались в ЗАКАЗЫ для КУХНИ. если мяса для двую стейков не хватает - заказ не может быть отменен, так как это повлечет за собой отмену Блюда. а блюда уже собраны. В принципе такое возможно - но надо тогда откатывать и "минусовать" блюда. "Сорри, но стейка сегодня нет в нашем меню" - бывает и такое, потому как вот такие школьники "пишут учет" ;-)
.
в рамках учебной задачи нигде не оговорено контроль наличия остатков. Т.е. исходим из того, что продуктов ВСЕГДА достаточно (в учебной задаче). А так как задача учебная, и такой контроль сам по себе не возникнет. и если контроля остатков нет - то количество уйдет в минус некотнролируемо, себестоимость не посчитается/кривая, прибыль кривая. ЗАДАЧА НЕ СДАНА. мне бы - точно не сдал. особенно если бы на сдаче явным образом студент не упомянул что закуп должен всегда гарантировать наличие. поэтому в рамках задачи закупаем заведомо много продуктов. А если этого не озвучит - я закажу 1000000 стейков и посмотрю на отчеты (упомянутые в задаче) - на предмет их адекватности...
.
кстати нормальная задача даже на собеседовании для джуниора. не на предмет знания техплатформы, а на здравый смысл и понимание автоматизируемых БП

(22) Здравый смысл говорит, что ты никогда не закажешь 1000000. В рамках задачи цена (себестоимость) продуктов фиксирована и вполне может храниться как реквизит карточки продукта. А посему себестоимость и прибыль не может быть кривая в независимости от кривизны остатков.

А так то можно докопаться почему стоимость работы повара и расход газа не учтены при расчете стоимости Блюдо?

(23) что есть в условии задачи, то и делается. Распределения косвенных затрат точно нет, себес только прямой из материалов.

(23) закажу 100. на банкет. и если себестоимость хранится в карточке - то закупать не надо. написал в карточку себестоимость и зашибись

(22) Я понял условие так, что есть только заказы клиентов. Отдельных заказов для кухни нет.

(26) задачка учебная :-)
Как раз и есть смысл не столько "программировать", сколько "систематизировать", т.е. а что вообще нужно предусмотреть в общих чертах, чтобы это все работало.
Причем, взята довольно расхожая тема.

(17) Я имел ввиду не это в своем вопросе. Я спрашивал - "Как будете реализовывать движение статуса заказа (Заказы имеют 3 состояния: принят, выдан и отменен)?"

т.е. Статус - это будет реквизит Документа (документов) или, допустим, отдельного РС ?

(22) Если делать все правильно и обдуманно (т.е. так, как это действительно должно быть), то задачу можно раздуть на полноценную конфигурацию, а реализация займет далеко не один день. Что явно выходит за рамки "учебной" задачки.

Кстати аналогичная ситуация и с "нормальная задача даже на собеседовании для джуниора". Если делать все грамотно и показывать свой уровень, то тестовая задачка растягивается на несколько дней плодотворной работы. А если чисто "по верхам" сделать, то вроде как ты не справился, т.к. не показал должного уровня проработки деталей. Палка о двух концах. Если мне дают подобные задачки тестовые и я понимаю, что для ее реализации потребуется более 5 часов, то я даже не приступаю.

(25) а ты не путай количественный учет и суммовой. Я про количественный ("Закупаться ничего не надо") ничего не писал.

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

(27) Чтобы "это все работало", заказа клиента достаточно имхо. Кухня видит очередь заказов/блюд и готовит.
Хотя я на кухне не работал, может чего не знаю.

(28) Реквизит документа. Есть аргументы за РС?

(31) "Реквизит документа. Есть аргументы за РС?" - конечно есть:

Чтобы двигать статус заказа, который является реквизитом документа, этот заказ нужно перепроводить. Ты будешь перепроводить его задним числом или текущим моментом? Если задним, то теряется "период" установки этого статуса, а если текущим, то меняется момент движения по остаткам и прочее. А если теряется момент установки каждого из статусов Заказа, то теряется возможность анализа процесса - сколько по времени занимает каждая операция (для выявления задержек и оптимизации процесса)

+ Если статус - реквизит документа - нужно открыть и перепровести документ. Что делать если этот документ "потребовался" нескольким пользователям?

Это так, на вскидку

Насчет отслеживания времени изменения статусов согласен, какой-то механизм нужен.

В нашем случае попроще, есть один начальный статус и два конечных, промежуточных нет. Вопрос решается добавлением реквизита - даты/времени приема заказа. А проводим текущим моментом.

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

(33) "А проводим текущим моментом" - тогда у тебя остатки будут списываться тоже текущим моментом, что тоже не правильно. По идее остатки должны списаться сразу, как только ты "взял" заказ в работу. Т.к. фактически именно в этот момент их физически взяли со склада и пустили в процесс. И назад ты их даже не вернешь.

(33) "Это касается любого документа, в т.ч. отдельного документа, меняющего статус" - каждый документ меняющий статус это отдельный документ, а не один и тот же. Поэтому тут не может быть коллизий.

(34) Читай внимательно условие: "После того как заказ был выдан – продукты списываются из остатков".
В статусе "принят" нет движений, все движения только в статусе "выдан".

В этой задаче требуется только регистрация свершившихся фактов. Никаких функций контроля процессов не требуется, не нужно их изобретать.

(36) Интересно как они будут отражать ситуацию с остатками, когда заказ "Приняли", приготовили (пусть даже частично), а потом по каким-либо причинам его отменили.

(37) Тут как раз то, о чем выше говорили - если это чисто тестовая задача, то ОК. Но если попытаться проявить "опыт", продумать как это ДОЛЖНО работать и натянуть ее на реальную жизнь, то возникает слишком много нюансов.

(38) Да, интересно. Можно добавить возможность в статусе отменен списать то, что успели испортить. ТЧ "Потери" например.

(40) еще могу пару интересных ситуаций накидать, допустим:

Оформили заказ - салатик. Заказ выполнили (приготовили салатик). Клиент от заказа отказался (салатик клиенту НЕ выдали).

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

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

делай что написано. а то там еще усушка утряска пойдет, полуфабрикаты, замены и т.п. и задача из учебной в проект на пару человеко лет перерастет.

(0)По второму отчёту не заданы разрезы. Прибыль нужна по заказам, блюдам или просто прибыль?