Библиотека Интернет Индустрии I2R.ru

Благодарности

Хотелось бы поблагодарить tsd и slw за их убежденность, за то, что смогли зацепить, за то, что заставили вспомнить программирование на 1С.

Очень хотелось бы поблагодарить Александра Зданевича (_-ZAV-_), Алексея Мазуркина (Marshak_IX) и Александра Галимова за активное участие в обсуждении проблемы. Во-первых, без их поддержки я не смог бы выбраться из пучин пессимизма. Во-вторых, их здоровая лень вынудила меня сделать мастера создания тестовых данных.

Предыстория

На форуме Территория 1С было начато обсуждение "Возвращаясь к ERP и 1С" (к сожалению, на форуме не работают ссылки на топики, поэтому, если хотите найти оригинал, поищите в архиве. здесь копия). Где то в середине (46 постинг) один из участников БТР сказал: "Сколько общаюсь, пока не слышал реальных проблем по реализации ERP в конфигурациях 1С". Я, считая, что он написал несерьезно, написал свой ответ (50 постинг): "А как насчет ввода планов будущим числом? Или всю ERP-систему на бухгалтерии делать? :)" После этого было длинное обсуждение. Я постарался выйти из этого обсуждения. В конце (286 постинг) известный участник этого форума Тот высказал мысль, что к 1С предъявляются только "технические" претензии, что все учетные задачи на 1С решаются: "А БТР - он хитрый. Он знает, что никто ничего конкретного не скажет. Потому как давно бы все это известно было. Что вот нельзя решить задачу в 1С, сформулированную в терминах учета - и все тут". Я повелся на утверждение Тота и привел только три таких задачи:

• трехвалютный учет в 1С
• планирование
• функции работы со временем.

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

Немного о функциях работы со временем. В самой 1С v 7.7 просто нет такого типа. Т.е. нет штатных средств, которые работают со временем. Это значит что программисты вынуждены придумывать что то свое. А это сильно удорожает проекты, в которых учет времени обязателен. Удорожает вплоть до неприемлимости решения.

Про планирование хотелось бы поговорить в данной статье.

Что такое "решаются - не решаются"

1С открытая система. В 1С есть внутренний язык программирования. Кроме того, платформа 1С предоставляет механизм "внешних компонент", который позволяет "прикрутить" любую библиотеку на любом языке.

Это значит, что теоретически на 1С можно решить абсолютно ЛЮБУЮ задачу. НО. Совершенно очевидно, что теория и практика - разные вещи. Совершенно очевидно, что любое практическое решение имеет свою цену. Эта цена складывается из: цены создания, цены подключения (внедрения), цены сопровождения и цены утилизации.

Я постоянно говорю, что имею в виду практическую решаемость задачи. Это значит, что при рассмотрении должны учитываться вопросы цены и целесообразности. Если задачу можно решить теоретически, то вполне возможно, что практическое решение не имеет никакого смысла.

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

Планирование

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

Пример планирования.
Процесс: отдых с семьей.
Плановая оценка: отдыхать будем на пляже.
Фактическая оценка: отдыхали дома, потому что был дождь.
Решение: съездить на курорт, где лето не такое фиговое.

Когда речь идет об 1С, как правило, подразумевается управленческое и финансовое планирование. Т.е. все оценки выражены числами.

Пример финансового планирования.
Процесс: продажа товаров.
Плановая оценка: продать в июле товаров на 1000 рублей.
Фактическая оценка: продали на 1500 рублей.
Решение: срочно пополнять склад.

Что является ключевым в нашем случае? Плановая оценка записывается до фактического исполнения процесса. Как правило, чем раньше мы сделаем оценку, тем лучше.

Проблема будущих проводок на регистрах

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

1. мы должны записать движение регистра и каким-то образом у этого движения указать будущую дату или будущий период;
2. регистры в 1С двигаются только документами;
3. поэтому, технически, план будет документом;
4. документ должен иметь дату;
5. чтобы не сбить ТА, документ должен иметь дату, близкую к текущей (ни в коем случае не будущую дату);
6. анализ план/факт будет выполняться далеко в будущем когда событие действительно произойдет.

Практически это значит, что период планирования необходимо записывать в одном из измерений регистра. А это значит, что для составления отчета план/факт 1С будет вынуждена:

• либо хранить только отклонения факта от плана
• либо анализировать проводки с начала деятельности
• либо оставлять регистр незакрытым

Только отклонения плана от факта явно недостаточны для анализа. Например, отклонение в 100 рублей, если запланировали 10 000, является терпимым. Но такое же отклонение в 100 рублей является совершенно недопустимым, если запланировали всего лишь 100 рублей.

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

Рассмотрим вариант с незакрытым регистром. Хранение незакрытых (не обнуленных) планов приводит к сильному распуханию файла с промежуточными итогами и очень медленной обработке итогов. На реальных данных распухание приводит к недопустимо медленной работе 1С.

Незакрытый регистр

Регистр это объект, который позволяет хранить движения по заданным измерениям и получать итоги в разрезе этих измерений. Гарантируется, что регистры очень быстро получают итоги на некоторый момент времени. Этот момент времени называется точкой актуальности (ТА). Разработчики предполагали, что ТА должна совпадать с текущим моментом времени.

Для нас важно физическая структура регистра. Регистр это два файла - сами движения и промежуточные итоги. По-умолчанию, 1С создает ежемесячные итоги плюс итоги ТА. Важно, что для получения итога на произвольный момент времени 1С берет ближайший итог и суммирует все движения регистра от момента промежуточного итога до заданного момента.

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

В методиках, на всех обучениях и в типовых конфигурациях 1С говорит, что надо стремиться, чтобы каждый плюс закрывался минусом, каждый минус - плюсом. Очень нехорошо, когда в регистре длительное время остаются незакрытые остатки. Надо стремиться, чтобы все суммы по всем измерениям закрывались в 0. Как только в регистре по некоторому измерению получился 0, то в следующий период этот промежуточный итог переноситься не будет.

Подробнее см. "Описание встроенного языка" начало главы работа с регистрами оперативного учета. У меня стр. 315.

Предложения tsd и slw

На форуме были два человека (tsd и slw), которые убеждали меня в возможности планирования на регистрах. Если кратко, то их предложение сводилось к тому, что период надо представлять как измерение регистра. На форуме приводился пример кода, в котором объяснялось, как надо упаковывать информацию о периоде в справочник. Ничего о закрытии регистра не было сказано. Но мою просьбу предоставить работающий пример, slw прислал вот такую конфигурацию. Я благодарен slw за затраченное время. Жаль, что в тестовом примере нет мастера, который создавал бы тестовые данные. Но все равно, пример очень показателен.

Тестовый пример от slw

Загрузить

В этом тестовом примере есть две принципиальные идеи:

• Приведен один из вариантов реализации кодирования даты;
• Сделана попытка решить проблему с закрытием итогов.

По-моему, кодирование даты это совершенно избыточная функциональность, так как удобнее просто завести дату в реквизите и искать по реквизиту, вместо того, чтобы затевать подобные извраты (см. модуль проведения документа План).

Для того, чтобы решить проблему с закрытием итогов было введено понятие "Горизонт планирования". Горизонт планирования должен выбирается заранее, до планирования. Горизонт планирования это день, неделя, месяц, квартал, год. Документ закрытия планов просматривает все планы и если план был создан давно и ушел за горизонт планирования, то план ОБНУЛЯЕТСЯ! Мда... Интересное решение. Во-первых, проблема не решается, а "загоняется под коврик". Во-вторых, а что делать, если хочется сделать отчет план/факт за прошлый год после того, как план закрыт? :)

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

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

Мой тестовый пример

Загрузить

Я считаю, что теоретически, реализовать планирование на 1С можно. Планирование на 1С можно использовать для "игрушечных" случаев. Я считаю, что в 1С невозможно реализовать планирование в практически значимых случаях за разумное время и за разумные деньги.

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

Я не решал проблемы. Я попытался их показать. Для этого была создана конфигурация, в которой есть:

• Три справочника - Бюджет, Периоды, Статьи затрат
• Один документ - План
• Один регистр - План
• Один отчет - План/факт
• Один мастер - Создание тестовых данных

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

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

Я предполагал, что планирование ведется по статьям затрат. Кстати, совершенно необязательно планировать именно затраты. Вместо затрат может быть что угодно. Но затраты планируют очень часто, и у меня сработала привычка. А потом переименовывать этот справочник было лень — в 1С это непросто.

Планы вводятся с помощью документа План. Плановые данные записываются в регистр План. Все документы вводятся текущей датой. Как правило, документы планирования будут "размазаны" во времени. Это должно несколько снизить объемы файла с промежуточными итогами. Но если в данной программе учет ведется несколько лет, то не стоит рассчитывать на существенное облегчение.

Отчет выводит только служебную информацию и информацию о времени исполнения. Однако, отчет План/факт честно исполняет запрос по регистру/план факт. Причем запрос выполняется на точку актуальности (мы помним, что 1С гарантирует, что итоги быстрее всего рассчитываются именно на ТА). Время исполнения этого отчета при различных параметрах и было основным тестируемым параметром. Кроме времени исполнения, можно посмотреть и на временные файлы, которые генерируются во временном каталоге (см. документацию 1С). Объем этого файла позволяет получить нижнюю оценку объема данных, необходимых для построения данного отчета.

В реальной жизни этот отчет должен содержать запросы к фактическим данным. Кроме того, отчет должен уметь сопоставить период планирования и фактические даты. В реальной жизни отчет будет выполняться существенно медленнее (в разы).

Отчет сознательно не использует никаких ухищрений типа таблицы значений. Дело в том, что таблица значений (ТЗ) "живет" в своп-файле операционной системы. Я понимаю, что ТЗ в некоторых случаях спасает программиста от рутинной работы. Но использование ТЗ никогда не дает выигрыша по скорости. Замедление - сколько угодно. ТЗ - удобный инструмент, иногда без нее не обойтись, но повсеместное использование ТЗ говорит скорее о низкой квалификации программиста. :)

И наконец, мастер. Это пожалуй, самая трудоемкая вещь во всей конфигурации. Если для создания остальных объектов, я просто использовал автосоздание, то здесь пришлось повозится. Задача мастера в конфигурации — сделать для вас всю подготовительную работу по вводу данных. Мастер предлагает 4 набора параметров для тестирования.

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

2 вариант - еженедельное планирование по 100 статьям затрат
Здесь число планируемых параметров увеличилось более чем в 4 раза. И это уже существенно сказывается на результатах. Но 1С еще работает очень даже ничего. Этот вариант уже вряд ли удобно делать в Экселе, хотя и реальным его назвать сложно.

3 вариант - ежедневное планирование по 100 статьям затрат
Конечно, в реальной жизни число статей затрат бывает существенно больше. Однако, если учесть что каждый день вводятся далеко не все позиции, то это вариант становится очень похожим на правду. По сравнению с первым вариантом число планируемых показателей возросло в 30 раз. Смотрите на файл с итогами! Смотрите на время исполнения!! Учтите, что вся эта фигня гоняется по сети, когда ваш аналитик создает отчет - смотрите на временный файл!!!

4 вариант - еженедельное планирование продаж по артикулам
Это часто используемый вариант планирования. Есть около 3000 артикулов, есть 3 варианта прогноза, прогноз составляется каждую неделю. Это не так уж и много. Однако число планируемых показателей возросло с первым игрушечным вариантом в 130 раз. Именно на таких задачах становится выгодно использовать системы автоматизации. Но посмотрите, что происходит с данными, посмотрите, что происходит со временем исполнения!!! Это неприемлемое решение!!!

Результаты тестирования

Немного о методике тестирования. Перед каждым тестом я удалял старые данные с помощью bat-файла "deldata.bat". Перед каждым тестом я очищал временный каталог Windows. Тест запускался в монопольном режиме. Dbf-база располагается на локальной машине.

Я замерял:

1. время создания отчета План/факт
2. время от нажатия на кнопку "Закончить" в мастере до момента, когда появлялась форма отчета.
3. размер файлов rg20.dbf и rg20.cdx (это промежуточные итоги регистра)
4. размер временных файлов *.dbf и *.cdx, которые создаются в момент работы отчета (по размеру этого файла можно оценить объем передаваемых по сети данных).

Тест проводился на ноутбуке Celeron 900, 256Mb, Windows XP Home Edition. 1С:Предприятие 18 релиз.

Собственно сами результаты:

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

На создание самого примера было затрачено 3 часа. Около 5 часов было затрачено на поиски альтернативных более оптимальных вариантов. Более 40 часов было затрачено на тестирование. Итого на создание работоспособного простейшего примера было затрачено около 48 часов.

И это без механизма согласования бюджетов, это без механизма выявления источников отклонений, это вообще без сопоставления с фактическими данными... мда...

На написание этой статьи было затрачено около 4 часов.

Выводы

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

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

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

Вывод 2: неожиданный
Поколение 1С выросло. Еще лет пять назад мы с пивом и смехом предсказывали появление людей, которые кроме 1С ничего не знают, и знать не хотят. Тогда это казалось анекдотом. Были совершенно очевидны рамки платформы 1С. Была совершенно очевидной мысль, что кроме 1С существует много других систем: и надо стараться находить наиболее целесообразное решение, надо использовать лучшее от разных систем. Лозунг, что на 1С решаются все учетные задачи, воспринимался внедренцами именно как рекламный лозунг, но ни в коем случае не как реальность.

Чтобы уверенно предлагать решение, которое работает настолько медленно нужно обладать достаточным уровнем авантюризма :или просто ничего не знать про 1С :или ничего не знать о реальных задачах :или просто быть молодым и здоровым.

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

Что ж, здравствуй племя молодое — поколение 1С.