Типовые конфигурации, работают очень медленно, бывает приходится ждать по несколько секунд, пока запишется документ, либо откроется список данных. От чего работать с такой системой, как минимум, очень не комфортно.
Может сложится впечатление, что виновата в такой медлительности платформа 1С Предприятие, либо не достаточно мощный сервер. Это не совсем так, по большей части виновата архитектура используемой конфигурации.
Все это влияет на скорость работы системы, и в конечном итоге тратит не только ресурсы сервера, но и оплачиваемое время работы сотрудников организации.
Складывается впечатление, что это делается намерено, что бы система получилось более тормозной. Иногда другого логического объяснение такой реализации в типовых конфигурациях не возможно найти.
Архитектура базы данных, изначально не продумана, из за чего приходится использовать «костыли» и почти при каждом обновлении конфигурации вызываются тяжелые обработчики по преобразованию таблиц в с данным.
Злоупотребление событиями, при записи данных. В типовых конфигурациях их очень много, при чем большая часть того, что выполняют функции обрабатывающие события, пользователю либо не пригодится, либо возможно найти другое решение. Но зачем искать более оптимальное решение, это лишние усилия, а альтернативы у пользователей все равно нет.
В итоге в реальных условиях с этим невозможно работать. Особенно сильно этим грешит Управление торговлей + CRM.
Одна и та же информация записывается в базу несколько раз. Особенно много дублирующей информации в регистрах остатков.
Например в Управлении торговлей, информация о складских остатках и заказанных товарах, записывается одновременно в несколько регистров, в разных комбинациях.
Операции записи довольно тяжелые и потребляют значительные ресурсы сервера, и время пользователей на ожидание.
Чем сложнее структура базы данных, тем больше время необходимо на запись данных, и сложнее пользовательский интерфейс.
Если при проектировании, структура данных получается сложной, это признак не правильного решения. Не всегда, но в большинстве случаев.
Например то, что в Управлении торговлей называется «Характеристики номенклатуры», в кавычках потому, что это не характеристики, а по сути отдельные товары, с ценами, остатками и всеми другими свойствами товаров.
Из за них систему пришлось усложнить на столько, что в каждом документы где используются товары пришлось вместо одного делать два поля, Номенклатура + «Характеристика».
Система предназначена в первую очередь для практического применения, поэтому приоритеты следующий:
По какому принципу сделаны типовые конфигурации:
И все! Пункта Скорость нет вообще! Это не учитывается главное, что бы было красиво!
Важно продать систему, что с этим будет в итоге невозможно работать из за низкой скорости уже не важно, система продана и альтернативы нет, приходится использовать то, что есть.
В итоге получаем:
Платформа 1С Предприятия позволяет генерировать формы динамически, что полезно в некоторых случаях, когда нет другого решения. Но использования ради сомнительной «красоты» не приемлемо, каждый раз при открытии формы какой того объекта на редактирования, вызываются функции генерации интерфейса, которые работают более медленно, чем если бы интерфейс был построен на встроенных функциях платформы.
Местами это доведено до абсурда. Например на форме используются закладки, для чего есть готовые элемент формы, с закладками. Вместо того, что бы использовать готовый, на форме размещают несколько текстовых полей в видел гиперссылок и пишут свой обработчик смены закладок, при чем с обращением к серверу, каждый раз когда пользователь выбирает закладку! Зачем? Суть остается та же, только тратится больше времени на обработку.
Пример в Управлении торговлей зачем то сделали службу чтения RSS новостей. Зачем? Если пользователя понадобится читать новости, он может установить отдельный RSS клиент, а возможно он у него уже есть.
Попытка разработать универсальную систему учета, со всеми возможными функциями, подходящую всем.
Для разработки и поддержки проще создать одну универсальную систему, вместо нескольких более узконаправленных, но плохо для оптимальности работы и для работы пользователей системы. Но проблемы пользователей, это их проблемы, систему уже купили, а альтернативы все равно нет.
При этом в большинстве случаев пользователями используется небольшая часть предусмотренных возможностей системы. И это пол беды, хуже то, что неиспользуемые функции не пригодятся большей части организаций.
В итоге получаем: