Разработка системы учета для предприятия общественного питания — это классическая задача для начинающего разработчика 1С. Она объединяет в себе основные механизмы платформы: работу со сложными структурами данных (рецептуры), управление остатками и расчет финансовой эффективности. В этой статье мы подробно разберем, как спроектировать такую систему «с нуля», основываясь на требованиях учебной задачи и лучших практиках разработки.
Прежде всего, нам необходимо определить, как будут храниться данные о продуктах и готовых блюдах. Рассмотрим справочник Номенклатура. Для удобства работы разделим его на две группы или добавим реквизит ТипНоменклатуры (Продукт, Блюдо). Продукты — это сырье (лук, мясо, картофель), которое мы закупаем. Блюда — это то, что мы продаем клиентам.
Ключевым элементом системы является связь между блюдом и его составом. Проанализируем ситуацию: одно блюдо состоит из множества ингредиентов. Для реализации этого механизма используем один из двух подходов:
Спецификация, где будут колонки Продукт (ссылка на ту же Номенклатуру) и Количество.Спецификации, владельцем которого будет Номенклатура.Выясним причину, почему второй вариант предпочтительнее в реальных задачах: он позволяет хранить историю изменений рецептуры, не меняя само блюдо. Однако для учебной задачи достаточно табличной части в карточке блюда.
Для хранения информации о количестве и стоимости продуктов нам понадобится Регистр накопления (вид: Остатки). Назовем его ОстаткиПродуктов. Разберем его структуру:
Измерения:
- Номенклатура (ссылка на продукт).
Ресурсы:
- Количество (число);
- Сумма (число — это и есть наша себестоимость закупок).
При закупке продуктов (документ ПоступлениеТоваров) мы будем делать движение «Приход» в этот регистр. Если в задаче сказано, что цена закупки фиксирована, мы можем просто умножать количество на цену из карточки товара. Если же цена меняется, платформа 1С позволяет реализовать партионный учет или списание по средней стоимости.
Документ Заказ — основной рабочий инструмент. В его табличной части указываются блюда и их розничная цена. Согласно условию, у заказа есть три состояния: Принят, Выдан и Отменен. Реализуем это через Перечисление.СтатусыЗаказов.
Проанализируем ситуацию с проведением документа. Основная логика списания должна срабатывать только при статусе Выдан. Рассмотрим пример кода в модуле объекта документа Заказ в процедуре ОбработкаПроведения:
Процедура ОбработкаПроведения(Отказ, РежимПроведения)
// Проверяем статус заказа
Если Статус = Перечисления.СтатусыЗаказов.Выдан Тогда
Для Каждого СтрокаБлюдо Из Блюда Цикл
// Получаем спецификацию блюда (ингредиенты)
Для Каждого СтрокаИнгредиент Из СтрокаБлюдо.Блюдо.Спецификация Цикл
// Рассчитываем общее количество продукта к списанию
КоличествоСписания = СтрокаИнгредиент.Количество * СтрокаБлюдо.Количество;
// Формируем движение по регистру остатков (Расход)
Движение = Движения.ОстаткиПродуктов.ДобавитьРасход();
Движение.Период = Дата;
Движение.Номенклатура = СтрокаИнгредиент.Продукт;
Движение.Количество = КоличествоСписания;
// Здесь же рассчитываем себестоимость для списания
// В учебной задаче можно брать фиксированную цену из справочника
СебестоимостьЕдиницы = СтрокаИнгредиент.Продукт.СебестоимостьЗакупки;
Движение.Сумма = КоличествоСписания * СебестоимостьЕдиницы;
КонецЦикла;
КонецЦикла;
КонецЕсли;
КонецПроцедуры
Важный момент: Если мы хотим получить отчет по прибыли, нам также нужно фиксировать факт продажи. Для этого создадим второй регистр накопления — Продажи (вид: Обороты). В него мы будем записывать Выручку (количество блюд * розничная цена) и Себестоимость (суммарная стоимость ингредиентов).
Рассмотрим подробнее вопрос изменения статусов. В сообщениях форума развернулась дискуссия: нужно ли перепроводить документ при смене статуса?
Если статус — это просто реквизит документа, то при смене его с Принят на Выдан нам придется перепроводить документ «текущим моментом». Это правильно, так как продукты физически списываются из кухни именно в момент выдачи. Если же статус Отменен, то движения по регистру ОстаткиПродуктов либо не создаются, либо (если они были созданы ранее) должны быть сторнированы.
Для более продвинутых систем рекомендуется использовать Регистр сведений для хранения истории статусов. Это позволит анализировать, сколько времени заказ находился в очереди и как быстро повара справляются со своей работой.
Система должна выдавать два ключевых отчета. Разберем, как их настроить с помощью Системы Компоновки Данных (СКД).
ОстаткиПродуктов. Он показывает текущее количество лука, мяса и картофеля на складе и их общую оценочную стоимость.Продажи.
Выручка — это сумма, которую заплатил клиент.Затраты (Себестоимость) — стоимость списанных продуктов.Прибыль — рассчитывается как разница: Выручка - Затраты.Выясним причину возможных расхождений: если в процессе готовки повар испортил блюдо, необходимо предусмотреть документ СписаниеПродуктов, который уменьшит остатки в регистре ОстаткиПродуктов, но не создаст записи в регистре Продажи. Таким образом, общая прибыль предприятия уменьшится на величину этих издержек.
Рассмотрим ситуацию с многоуровневыми спецификациями. В реальном ресторане часто используются полуфабрикаты (например, заранее сваренный бульон). В этом случае в спецификации блюда «Суп» будет указан не только сырой картофель, но и «Бульон куриный». При списании система должна уметь «разворачивать» цепочку до первичных ингредиентов. Это достигается с помощью рекурсивного обхода спецификаций в коде 1С.
Таким образом, даже простая учебная задача позволяет освоить фундаментальные принципы автоматизации: иерархию данных, событийное проведение документов и многомерный анализ информации через отчеты. Используя предложенную структуру, вы создадите гибкую систему, которую легко масштабировать под реальные нужды ресторанного бизнеса.