При проектировании учетной системы с чистого листа часто возникает вопрос: как грамотно разграничить логику работы с физическими товарами и неосязаемыми услугами? Рассмотрим основные архитектурные подходы, которые помогут сделать систему гибкой, масштабируемой и удобной для последующей интеграции с типовыми решениями.
Самый распространенный и простой в реализации подход — использование единого справочника Номенклатура для всех видов активов. В этом случае мы не дробим базу на разные таблицы, а управляем поведением системы через реквизиты.
Рассмотрим, как это работает на практике:
ЭтоУслуга (или более гибкий вариант — ВидНоменклатуры, ссылающийся на справочник типов).ЭтоУслуга, система должна пропустить проверку наличия остатков на складе.ОстаткиТоваров, чтобы исключить продажу несуществующего на складе актива.Этот подход предпочтителен для небольших и средних конфигураций, так как он упрощает выбор позиций пользователем в одном документе и минимизирует количество сложных SQL-запросов при формировании отчетов.
В крупных системах класса ERP нередко используется подход с разделением сущностей. Например, как в SAP, где для услуг и материалов могут существовать разные таблицы (такие как ASMD для услуг). Давайте проанализируем, почему этот метод имеет право на жизнь:
Преимущества раздельной структуры:
Вес, Габариты, Упаковка, которые абсолютно бесполезны для услуг. Разделение сущностей позволяет очистить структуру БД от избыточных полей.Если вы планируете масштабируемую систему, подумайте о создании отдельных регистров для списания услуг. В отличие от товаров, услуга не хранится на складе, поэтому она не должна затрагивать складские регистры, но может влиять на регистры затрат или выручки.
Чтобы ваша система была спроектирована «правильно», предлагаем придерживаться следующих принципов:
1. Отказ от жесткого кодирования
Не используйте жесткую логику в коде вида Если Номенклатура = "Услуга". Используйте типы метаданных или перечисления. Это позволит вам в будущем легко добавить новые типы, например, Работа или ПодарочныйСертификат, не переписывая все документы реализации.
2. Унификация для обмена данными
Помните, что рано или поздно вам может потребоваться обмен данными с типовыми решениями 1С. В типовых конфигурациях стандартом де-факто является наличие справочника ВидыНоменклатуры. Рекомендуем сразу закладывать аналогичную структуру, чтобы в будущем не пришлось проводить трудоемкий рефакторинг для настройки обмена.
3. Понимание учета
Разберем разницу в учете на примере кода. Для товаров при списании вы всегда обращаетесь к остаткам:
// Пример проверки для товара
Если Не ЭтоУслуга Тогда
Остаток = ПолучитьОстатокНаСкладе(Номенклатура, Склад);
Если Остаток < Количество Тогда
ВызватьИсключение "Недостаточно товара на складе!";
КонецЕсли;
КонецЕсли;
Для услуг же процедура проведения должна быть гораздо проще — вы просто фиксируете факт продажи (выручку), не обращаясь к регистрам остатков. Это кардинально упрощает алгоритм проведения документов и повышает скорость работы системы.
В конечном итоге, выбор зависит от сложности вашего проекта. Для простых баз достаточно одного справочника с реквизитом ЭтоУслуга. Для сложных систем, претендующих на звание ERP, лучше рассмотреть вариант разделения сущностей на уровне метаданных или использования справочника ВидыНоменклатуры для управления поведением объектов. Главное — сохраняйте единообразие подходов во всей архитектуре вашей базы данных.