Рубрика: Пожелания к 1С

Сегодня пойдет речь об очень полезном механизме в 1С 8.3 — Регламентных заданиях.

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

• выгрузка-загрузка данных в другие системы (другие учетный системы, сайта, кассы и т.д.)
• пересчеты вспомогательных данных, используемых при заполнении документов
• «отложенное» проведение документов — когда в режиме реального времени делаем проводки по основным регистрам (остатки товаров, взаиморасчеты), а вспомогательные (аналитические) можно сделать и в фоновом режиме минут через 10-15-20
• другие варианты — зависит от конкретных задач и фантазии

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

• Для регламентных заданий (или в расписание), добавить свойство «Не выполнять пропущенные». Например: есть регламентное задание, которое должно выполняться ежедневно в 01:00. По каким-либо причинам оно не было выполнено (проводились технические работы и сервер был физически выключен в это время). При запуске сервера в 02:00, это задание выполняется. Но такое «позднее» выполнение требуется далеко не всегда.
• Сделайте возможность добавлять новые задания без изменения конфигурации. Вариант создания нового задания на основании существующего — не вариант, т.к. невозможно переопределить запускаемую процедуру. Использовать методы обхода через внешние обработки, запускаемые по расписанию — не очень красиво и не всегда удобно.
• В продолжение предыдущего пункта — сделать нормальный, быстро работающий интерфейс управления заданиями из 1С:Предприятия через «Функции для технического специалиста -> Стандартные». Текущая обработка в стандартных конфигурациях работает медленно. Плюс сюда можно добавить и возможность добавления новых регламентных заданий.

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

Эта заметка о наболевшем, как очередной крик «Почему так?» от программиста, работающего с несколькими типовыми конфигурациями (Управление торговлей, Бухгалтерия, ЗУП) и самописной с использованием БСП.

Отличная идея разработчиков в 1С разделять все объекты по подсистемам оказалась, на мой взгляд, проваленной. Причина — нет стройной архитектуры в этих подсистемах, нет четкой иерархии какая подсистема от какой зависит. Как итог — дублируются функции и процедуры в различных подсистемах. При внедрении, обнаруживаешь, что в модулях внедряемой подсистемы стоят вызовы модулей других подсистем, которые не связаны (не должны быть связаны) с внедряемой подсистемой. Разбирая ошибки и добавляя нужные модули, наблюдаешь страшную картину, когда в одной процедуре стоит проверка возможного наличия «параллельной» подсистемы, а через 3 строчки кода наличие другой не проверяется.

Вопрос — куда смотрят архитекторы в 1С? Как допустили такой бардак в типовых решениях?

Неужели такая достаточно крупная компания, как 1С, не может себе позволить содержать отдел здравых архитекторов решений, которые построят одно большой дерево всех подсистем, пропишут зависимости между ними. Сделают описания, чтобы избежать дублирования процедур. Или наоборот, специально сделают дубли ради уменьшения количество зависимостей.

Это сложная работа. Очень сложная. Но она необходима всем, кто работает с решениями 1С — от разработчиков в самой 1С до пользователей, которые получат более быстрое решение за счет оптимизации.

Отдельным блоком в этом хаосе стоят разночтения в наименовании объектов в типовых решениях. Без обмена данными между различными конфигурациями никуда, но на вопрос почему в Управлении торговлей документ называется «ПриобретениеТоваровУслуг», а в Бухгелтерии — «ПоступлениеТоваровУслуг» я не могу дать хоть сколько-нибудь здравого ответа. Почему в Управлении торговлей — «Договор», а в Бухгалтерии — «ДоговорКонтрагента»? В Управлении торговлей — «ВозвратТоваровОтКлиента», а в Бухгалтерии — «ВозвратТоваровОтПокупателя»? Зато «ВозвратТоваровПоставщику» — одинаково. Где логика? Из-за всех таких разночтений ловишь кучу проблем при написании обменов между базами. Здесь мы говорим так, а за углом — так, а завтра — по-другому.

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

Продолжаю подкидывать идеи фирме «1С» по улучшению платформы 1С:Предприятие. Сегодня пройдусь по «Подсистемам». Задумка хорошая, но реализация, как обычно, подкачала. Очень сильно подкачала. На мой взгляд, в том виде, как есть сейчас «Подсистемы» в 1С — пустое место. Пользоваться неудобно и бессмысленно (только ради отображения в интерфейсе).

Для начала надо… создать (вернуть, т.к. это было в ранних версиях 1С8.0 и 1С8.1) отдельный раздел «Интерфейс», который и будет, собственно, основой меню, интерфейса пользователя. Здесь у нас остается такая функция как «Командный интерфейс», в которой можно задать последовательность, видимость, доступность и т.д. тех или иных команд пользователю. По сути, мы возвращаемся к тому, что было в 7.7 и 8.0 (8.1) — был отдельный раздел «Интерфейсы», в котором описывались доступные пользователю пункты меню. Эти интерфейсы можно было включить в ту или иную подсистему. И это верный, логичный подход. Я до сих пор не понимаю, почему отказались от этого раздела. Ведь сейчас получается полная ерунда — в подсистему включается куча справочников, документов, но они не отображаются в интерфейсе. Зачем это надо?

А теперь описание того, чего не хватает в реализации подсистем. Здесь у меня «хотелок» гораздо больше.

1. Убрать из подсистем «Командный интерфейс» — т.к. интерфейс должен описываться отдельно (смотри выше).
2. Добавить в подсистему свойство «Номер версии». Необходимо как воздух.
3. Добавить для подсистем свойство с возможностью выбора множества значений «Зависит от подсистем». В этом свойстве разработчик должен выбирать другие подсистемы, необходимые для работы текущей, а также указывать минимальный номер версии «ведущей» подсистемы, с которой можно работать (т.к. не все зависимости можно выстроить по простой иерархии). Получится, что платформа сможет отслеживать наличие всех требуемых подсистем в конфигурации и соответствуют ли их версии. Как пример — указывать, что для подсистемы «Присоединенный файлы» необходимы подсистема «Базовая функциональность» версии 2.1.4 и «Работа с файлами» версии «1.6.2» и если эти требования не выполняются, то, например, функционал данной подсистемы недоступен для пользователя (или вообще невозможно запустить приложение). Есть сложность — при задании свойства необходимо отслеживать указанную зависимость на наличие «кольца», чтобы не получилось, что для «подсистемы 1» нужна «подсистема 2», для «подсистемы 2» — «подсистема 3», а для «подсистемы 3» — «подсистема 1».
4. Для каждой подсистемы сделать предопределенные модули (как «Модуль менеджера» или «Модуль объекта») по типам модулей. Модуль «Клиент», «Сервер», «КлиентСервер», «ПовторныйВызов» (хотя бы на время сеанса). Плюсы этого подхода — модули сразу привязаны к подсистеме и открываются из окна свойств (что удобно), у нас очень сильно уменьшится список «Общие модули» (сейчас он получается очень большой и неудобно искать нужный модуль). А также добавить модуль «ОбновлениеПодсистемы», в котором должна быть предопределенная процедура «ОбновлениеВерсии», вызываемая автоматически при запуске программы, если — читай следующий пункт. Порядок вызова процедур обновления должен соответствовать зависимостям подсистем (пункт 3).
5. Добавить в подсистему свойство «Номер рабочей версии». Это свойство невозможно установить в конфигураторе, а только вызвав в коде какую-нибудь процедуру «УстановитьНомерВерсииПодсистемы». С помощью этого свойства можно автоматически отслеживать версии и запускать процедуру обновления (смотри пункт 4).

Пока на этом с подсистемами остановимся. Как бонус — еще одна идея (возможно, это уже слишком). Для объекта метаданных «Отчет» или «Обработка» так же, как и для подсистем добавить возможность указания необходимых подсистем и их версий.

Разработчикам платформы 1С накидываю идею №3 для повышения удобства разработки на платформе.

Очередной очевидный момент, который упущен разработчиками платформы, но доделывается ручками программистами 1С. Эта недоделка заставляет усложнять код и, как следствие, уменьшает скорость.

Описание моего предложения:

1. Добавить в платформу предопределенный справочник «Объекты метаданных» (этот справочник в типовых конфигурациях создается и заполняется ручками на уровне кода в 1С). В справочнике автоматически при обновлении конфигурации создаются/изменяются данные по объектам (добавлять/удалять записи «ручками» запрещено) — справочникам, документам, перечислениям, отчетам и т.д. Справочник, естественно, иерархический.
2. В каждом ссылочном объекте метаданных должна быть ссылка на этот предопределенный справочник (чтобы можно было получить ссылку на справочник «Объекты метаданных», как говорится «через точку»). Это нужно, чтобы не вызывать метод Метаданные() для ссылки/объекта, не использовать в запросах конструкцию вида «.Ссылка Документ.ПоступлениеТоваровУслуг».
3. Добавить возможность добавления реквизитов в справочник «Объекты метаданных» разработчиком конфигурации, причем значения надо задавать так же в конфигураторе (пожелание о задании реквизитов для предопределенных элементов я описывал ранее). Данная возможность упростит жизнь разработчикам. Можно разделить объекты по принадлежности к какой-либо операции, задать наименования реквизитов (если в разных объектах они имеют различные наименования типа «Организация» и «ОрганизацияОтправитель»)
4. Соответственно, этот предопределенный справочник можно использовать в запросах, должно быть легко делать соединение прикладных объектов с этим справочником, чтобы в запросе легко можно было получить значения заданных разработчиком реквизитов и т.д.

Пожалуйста, подумайте над этим предложением. В этом что-то есть.

Уважаемые разработчики платформы 1С! Очередное пожелание по доработке платформы 1С.

Перед описанием, хочу отметить, что эта недоработка у меня вызывает искреннее удивление — почему не сделали сразу?

Просьба очень простая — добавить возможность добавления реквизитов, а может быть сразу и табличных частей) к объектам типа «Перечисление». Использование этих реквизитов в запросах, как и реквизитов других прикладных типов (справочников, документов).

Все равно в структуре базы данных перечисление записывается в отдельную таблицу (как и справочник).

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

А подумайте, как удобно стало бы программистам 1С. Например, в перечисление «Ставки НДС» добавить реквизит «Процент ставки» и использовать его в запросах для пересчета сумм, а не писать лишние процедуры типа «ПолучитьСтавкуНДС» и делать построчный обход.

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

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

Начну с самого очевидного, что сразу бросается в глаза и создает лишние трудности при разработке.

В справочниках 1С 8.х появилась замечательная возможность, которой очень сильно не хватало в 1С7.7 — предопределенные элементы. Эта штука сама по себе очень удобна для многих моментов, но ПОЧЕМУ при создании предопределенного элемента можно задать ТОЛЬКО Код и Наименование?

Уважаемые разработчики платформы 1С, очень прошу — добавьте возможность при создании предопределенного элемента справочника, сразу, в конфигураторе, задать значения реквизитов этого элемента. Будет очень удобно и не потребуется больше писать заполнение реквизитов предопределенных элементов после обновления конфигурации.

В качестве бонуса, при реализации этой задачи для каждого реквизита каждого предопределенного элемента справочника можно добавить признак — можно или нет его изменять интерактивно (или програмно) в системе 1С:Предприятие.

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