Преимущества отдельной конфиугарции

Преимущества работы с данными в рамках отдельной системы, по сравнению с тем как, если это вести в рабочей учетной системе.

В начало

Номенклатура

Свой справочник номенклатуры, почему свой, чем плох тот, что используется в Управлении торговлей.

Описанные ниже проблемы (кроме "характеристик" это просто неудобно и не понятно по какой логике было сделано) приводят к тому, что если эту же самую систему, тот же анализ, те же алгоритмы использовать для работы с Номенклатурой в Управлении торговлей, это работает в НЕСКОЛЬКО раз дольше, чем тоже самое в конфигурации Управление номенклатурой.

Первая проблема

Сущность, которая в Управлении торговлей называется Характеристики номенклатуры.

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

Введен дополнительный справочник Характеристики номенклатуры, что потянуло усложнение структуры и более сложное заполнение данных где используются товары:

• Добавить колонку "Характеристика" в каждом документе, где есть товары. Во всех приходных, расходных документах, во всех где так или иначе связано со ссылкой на товары, а таких видов документов в системе не один десяток и в каждом это поле;
• Добавить колонку "Характеристика" в каждом регистре накоплений, где ведется учет товара, и опять же этих регистров несколько десятков, и в каждом это поле;
• Добавить колонку "Характеристика" в каждом из дополнительных сведений товаров: цены, штрихкод, описания, фото и т.п., так как по штрихкоду уже не достаточно найти только товар надо знать еще и "характеристику" во всех дополнительных сведениях, необходимо указать дополнительно Характеристику и дополнительно ее выбирать, в отдельное поле.

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

Сложность, если не сказать невозможность, поиска товаров по техническим характеристикам (дополнительным реквизитам, дополнительным свойствам). Так как "Характеристики" отдельный справочник, в него пришлось так же отдельно добавить свою таблицу технических характеристик (дополнительные реквизиты, дополнительные свойства).

Что получилось необходимо отобрать все товары признаком "Цвет" = "Красный", и не можем! Потому, что у нас два отдельных справочника, в одном товары, в другом "характеристики" можем выбрать либо то ли то, но не все сразу, уже и потому что в Управлении торговлей, они не отображаются нигде одним списком (что можно было бы сделать, через более сложный запрос выбора данных, что в свою очередь тоже не очень хорошо, выбрать станет возможным, но больше времени и ресурсов на выбор данных, а это тормоза при просмотре списка).

Преобразование товаров, мы изначально завели товары как отдельные, вот может не было изначально других вариантов, не создавали для него товар + одна характеристика, и этот товар уже участвует в документообороте, в ценообразовании, на него есть куча ссылок в системе.

Решили сгруппировать несколько товаров в один с характеристиками. Как это сделать? Придется создать новый товар с свойством "С характеристиками" добавить "Характеристики" и заменить в системе все ссылки на эти товары, на товары + характеристики, только после этого удалить старые товары. А если решим наоборот сделать, товары с характеристиками сделать отдельными товарами, та же сложная процедура, с заменой кучи ссылок и созданием новых товаров.

Этого показалось мало, и добавили "характеристики" привязанные не к конкретному товару, а "характеристики" для вида номенклатуры! Что запутало все еще больше. Больше невозможно зная характеристику, точно сказать от какого она товара.

Выгрузка в Битрикс, из за того, что "характеристики" могут быть не привязаны к товару, идентификатор приходится делать составной, содержащий идентификатор товара + идентификатор "характеристики" и на стороне сайта уже нельзя просто взять идентификатор и найти товар который обновить, надо разделить текст идентификатора характеристики на два отдельных.

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

Как устроено это в Управлении номенклатурой.

Вместо отдельного справочника "Характеристики" добавлено три поля в справочник Номенклатура:

• Тип товара (По сути вместо типа товара, хватило бы простого признака Да или Нет, для товара владельца, а дальше если владелец заполнено, значит этого "Характеристика" если не заполнено значит это товар владелец либо самостоятельный товар, какой именно видно по признаку) но так более удобно, а на быстродействие не повлияет:
  • Самостоятельный - то что в УТ товары без характеристик;
  • Товар владелец - то что в УТ товар с характеристиками;
  • Подчиненный - то что в УТ "характеристика"
• Товар владелец - ссылка на группировочный товар;
• Наименование предложения - краткое наименование для товара в группировке как предложение (то что в УТ Характеристика).

Данные подход решает все вышеперечисленные проблемы:

• Не нужно дополнительное поле Характеристика во всех документах с товарам, нужно только условие в списке подбора товаров, что товары с типом "Товар владелец" выбирать в документ нельзя;
• Не нужно дополнительное поле Характеристика в регистрах накопления (остатки и прочее), есть одно поле Номенклатура, а для формирования отчетов, если необходимо, всегда возможно сгруппировать остатки по полю Товар владелец;
• Не нужно создавать отдельно Артикулы характеристик, или поле Характеристика в таблице штрихкоды, потому что это товары и так уже отдельные;
• Не нужно создавать отдельно настройку контента для характеристик, у нас есть контент для Номенклатуры и этого достаточно, мы можем настроить контент хоть на товар владелец, хоть на подчиненный;
• Простой выбор товаров, один справочник не надо прыгать с Номенклатуры на "Характеристики", при этом появляется выбор варианта просмотра:
  • Выбираемые - подчиненные и самостоятельные одним общим списком;
  • Главные - только товары владельцы и самостоятельные, а в подчиненные мы попадаем щелкая на товар владелец, что не перекидывает в другой список, это тот же список, но уже с фильтром по товару владельцу (отдельный список характеристик, с ценами, остатков и прочим делать не надо);
  • Все товары - товары владельцы, самостоятельные и подчиненные одним списком, с указанием свойства, что это за товар, такой список больше подойдет при настройке контента;
• Поиск товаров по техническим характеристикам (дополнительным реквизитам, дополнительным свойствам) теперь возможен, у нас один справочник;
• Преобразование товаров, мы изначально завели товары как отдельные, решили объединить их в товар владелец и подчиненные. Просто создаем Новый товар с типом Товар владелец, привязываем к нему наши объединяемые товары как подчиненные, меняем в них тип товара на Подчиненный и генерируем краткое название. Все! При этом наши товары как были товарами так и остались, то есть все ссылки в старых документах ценах, остатках все как было так и останется, контент как был так и останется. Если захотим наоборот, сделать из отдельными, меняем тип товара на Самостоятельный, очищаем поле товар владелец, а сам товар владелец без проблем удаляем, так как в учете он не используется и ссылок на него нет;
• Выгрузка в интернет-магазин без предложений, если скрипт интернет-магазина не поддерживает предложения, значит выгружаем в него товары с типом "Самостоятельный" и "Подчиненный" (у которого уже есть полное наименование);
• Выгрузка в интернет-магазин с предложениями, если скрипт интернет-магазина поддерживает торговые предложения, не проблема, выгружаем в товары Номенклатуру с типом "Самостоятельная" и "Товар владелец", а в предложения товары с типом "Подчиненный", при этом если надо у нас есть контент как на товары владельцы так и на подчиненные.

Вторая проблема

В справочнике Номенклатура в Управлении торговлей, очень много полей, их больше 100 (Больше сотни!!!) понимаю, что система универсальная, для разных отраслей. Но при этом основная часть полей никогда не используется. Не используется, но каждый раз открывая Номенклатуру или перезаписывая читаются все эти поля, и записываются, а это время и затраты ресурсов сервера, и если много операций складывается в приличное время.

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

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

Эти дополнительные данные, это все ухудшение производительности, лишние тормоза, которых и так хватает в 1С.

Третья проблема

В Управлении номенклатурой (во всей системе и в номенклатуре в частности) вызывается очень много обработчиков по событию, (даже так ОЧЕНЬ МНОГО), при записи, при создании нового. Причем функции, что выполняют эти обработчики большинству пользователей или совсем не нужны, или нужны отчасти, но они всегда все выполняются Все это занимает ресурсы сервера и время, что приводит к достаточно медленной обработке данных.

В начало

Контент-менеджер

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

Не захламляем рабочую базу кучей информации по контенту.

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

В начало

Обработка прайс-листов

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

Не захламляем рабочую базу информацией по товарам прайс-листов необходимыми для сведения аналогов;

Не загружаем сервер и рабочую базу тяжелыми обработками по загрузке данных и поиску аналогов. Освобождаем базу (и сервер) где работают основные сотрудники от этой нагрузки.

В начало

Ценообразование

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

В начало

Интернет-магазин

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

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

В начало