← На главную

При проектировании собственной конфигурации или доработке существующих систем начинающие разработчики часто сталкиваются с вопросом выбора типа объекта для сущности «Заказ». Давайте разберемся, почему этот выбор принципиален для архитектуры вашей системы и почему стандартным решением является использование документа.

Понимаем сущность объекта «Заказ»

Чтобы принять верное решение, необходимо осознать разницу между двумя ключевыми объектами платформы: Справочник и Документ. Разберем их предназначение:

1. Справочники используются для хранения условно-постоянной нормативно-справочной информации (НСИ). Это объекты, описывающие «кто» и «что» участвует в процессах: Контрагенты, Номенклатура, Склады.
2. Документы предназначены для фиксации фактов хозяйственной жизни. Любая операция, имеющая временную привязку, должна отражаться через документ. Заказ — это не просто описание объекта, это событие, которое имеет дату, время, инициатора и набор товаров или услуг.

Почему «Заказ» — это документ?

Рассмотрим, почему выбор документа является единственно верным подходом при проектировании бизнес-процесса:

• Хронология и дата: У любого документа есть предопределенный реквизит Дата. Это позволяет выстраивать цепочки событий, формировать отчеты за конкретные периоды и анализировать историю заказов клиента во времени.
• Движения по регистрам: Только документы могут формировать движения по регистрам (накопления, сведений, бухгалтерии). Если вы создадите Заказ справочником, вы не сможете автоматически учитывать резервирование товаров, планировать отгрузки или рассчитывать взаиморасчеты с клиентами.
• Статусность и изменения: Заказ часто проходит через разные состояния: «Новый», «В работе», «Оплачен», «Отгружен». Механизм Проведения документа позволяет контролировать эти состояния и обеспечивать целостность данных в учетной системе.

Разбираем типичные возражения

Иногда новички пытаются использовать справочник из-за удобства иерархических структур или «простоты». Однако важно понимать, что справочник не предназначен для фиксации факта хозяйственной операции. Если заказ будет справочником, вы столкнетесь с фундаментальными проблемами: отсутствием возможности строить отчеты по продажам, потерей истории изменений и сложностями при автоматическом расчете остатков.

Если вам кажется, что в документе «Заказ» не хватает функционала, или он кажется слишком сложным, проанализируйте бизнес-процесс:

1. Если это «намерение», которое не влияет на учет, все равно создавайте документ, но добавьте ему Статус.
2. Если необходимо создать «шаблон» заказа для часто повторяющихся услуг, используйте справочник как ШаблоныЗаказов, а при выборе шаблона создавайте полноценный документ ЗаказКлиента.

Рекомендация по проектированию

Всегда помните: Сначала думаем, потом создаем. Прежде чем добавлять объект в конфигурацию, задайте себе вопрос: «Является ли это сущностью, которая просто существует, или это событие, которое должно изменить состояние системы?»

Если это событие, то реализация через Документ обеспечит вам:

• Гибкую работу с Периодичностью.
• Возможность использования ЖурналовДокументов для удобного просмотра операций.
• Стандартный механизм Печати и Нумерации.

Использование правильного типа объекта сэкономит вам недели разработки в будущем, так как вся отчетность в 1С строится именно на данных, которые формируют документы. Не пытайтесь изобрести велосипед, используя справочник там, где должен быть документ — придерживайтесь стандартов платформы, и вы получите систему, которую легко поддерживать и развивать.