График : Пн-Пт: 9.30 - 18.00


Разработка на V8 – реальная система за четыре дня!

Постановка задачи

 

Началом всего внедрения можно считать событие почти годовой давности. Раздался телефонный звонок, и диспетчер слегка растерянным голосом произнесла: «Андрей, тут у меня мужчина. То ли я его не пониманию, то ли он меня. Не поговоришь?» После этого состоялась первая из полудюжины встреч с финансовым директором продюсерского центра, предваряющих начало разработки.

 

С чего все начиналось

 

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

Пока центр только раскручивался, и проектов было немного, для учета всех финансов вполне хватало обычных таблиц Excel . Дело нехитрое: деньги приходят, деньги уходят – табличка доходов в разрезе по статьям, аналогично – табличка расходов. Таблички можно сравнить или диаграмму построить, а можно и вознаграждение сотрудника рассчитать. В общем, ситуация довольно типичная для любого начинающего бизнеса. Сам бизнес развивался, число проектов стало превышать число пальцев на руках, и тут начались трудности. Оценить состояние дел, проследить тенденции развития за последний год в различных разрезах владельцам бизнеса и его управляющим на простых табличках Excel , —увы, сложновато. Достаточно много времени приходилось тратить, чтобы сводить данные воедино, отсекая лишнее или вычисляя недостающее. Ну а самое главное, с развитием центра, с возникновением новых направлений, с расширением штата все больше сил уходило на рутинные операции.

 

Заказчик присматривается к ПО с готовым функционалом

 

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

Конечно, теоретически можно было бы выбрать какого-нибудь управленческого монстра – реинжениринг, маркетинг, управление рисками, бюджетирование, финансовое планирование, надо соответствовать мировому уровню …, но… с какой стороны ни подходи – задача-то изначально ставилась простейшая: приход-расход, надо просто зарегистрировать, а потом просто посмотреть – что из этого получается и принять простые и понятные управленческие решения. Неужели держать ради этого целый финансовый отдел, «кормящий» информацией ненасытного программного монстра, да еще и по определенной схеме? Есть ли в этом смысл, какая-то бизнес-логика? Смысла не находилось, и топ-менеджмент центра опять возвращался к табличкам Excel .

 

Очерчиваем основные принципы автоматизации

 

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

  • Предмет автоматизации – движения финансовых средств;
  • Учет финансов – кассовым методом (по факту прихода или расхода);
  • Разделение наличных и безналичных платежей;
  • Контроль денежных остатков;
  • Поддержание многовалютного учета;
  • Возможность построения аналитических отчетов (Доходы, Расходы, Доходы и Расходы, Profit, …) в учетной валюте компании;
  • Не подразумевается ведение фискальной регламентированной отчетности и товарного учета;
  • Программа должна легко обслуживаться силами одного человека и не требовать перехода на непривычные для Заказчика технологии.

Экспресс-обследование

 

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

И, поскольку «гнать коней» никому не хотелось, более чем за полгода состоялось еще несколько рабочих встреч. На них выкристаллизовался следующий перечень задач

 

  1. Ведение учета постоянных и переменных затрат в разрезах статей затрат;
  2. Ведение учета доходов компании в разрезах статей доходов;
  3. Разнесение затрат и доходов по уровням структуры компании;
  4. Определение прибыльности деятельности компании в разрезе соответствующих уровней структуры, изображенной на рисунке.
  5. Составление планов доходов и затрат с возможностью проведения план-фактного анализа в разрезе соответствующих уровней и статей. Периодичность планов – на год, по месяцам;
  6. Оперативное ведение состояния финансов компании (кассы, банк);
  7. Обеспечение возможностей ввода начальных остатков, поступления и выемки инвестиций, корректировки и инвентаризации денежных остатков;
  8. Обеспечение отражения операций конвертирования денежных сумм.

 

Почему выбрали V 8

 

От встречи к встрече росло обоюдное желание заказчика и исполнителя опробовать на данном проекте новую платформу »1С:Предприятие 8». Причин тому было несколько:

  • На каждой встрече постоянно обновлялся, изменялся, пополнялся перечень пожеланий в отношении аналитических отчетов. Причем и исполнитель, и заказчик это заметили и вместе пришли к выводу, что новые потребности в отчетах будут возникать постоянно – аппетит приходит во время еды. Вот только малая часть рабочих записей одной из встреч по этому вопросу:
    • Сравнение отделов по расходам и доходам;
    • Сравнение доходов и расходов в пределах отдела;
    • Сравнение общефирменных и производственных расходов (Сколько «проели», а сколько вложили в дело );
    • Сравнение доходов и расходов (не включая офисные расходы, но включая зарплату сотрудников);
    • Определение тенденции изменения прибыльности в разрезах отделов и сотрудников по месяцам;
    • Определение доли отдела «ХХХХХХ» в доходах компании;
    • И т. д
  • Интерактивное же изменения вида и содержания отчетных форм – одна из красивейших возможностей новой платформы «1С:Предприятие 8».
    • Для регистрации первичной информации подразумевалось использование двух видов документов: «Кассовый день» и «Банковский день». Причем в них требовалось отражать и доходы и расходы одновременно. Для решения задачи просто напрашивалось использование двух табличных частей в каждом документе. Конечно, можно было бы воспользоваться опытом предыдущей платформы и вывести в форме диалога две таблицы значений, которые потом сохранять в каких-нибудь служебных документах. Но такое решение вряд ли можно было бы признать изящным.
    • Для оперативного анализа первичных данных заказчику требовались разнообразные изменяющиеся сложные отборы и сортировки. Этот вопрос в «1С:Предприятии 8» решается на два порядка проще, чем в предыдущей платформе.
    • Заказчик убедился, что на чем бы выбор ни был остановлен – программа будет соответствовать его требованиям и в первую очередь она будет простой в эксплуатации. Тогда почему бы не «иметь самое последнее, самое современное». Ответное желанием разработчиков было попробовать это «самое современное» решение на практике.
    • Существующую разницу в стоимости «самого, самого последнего ПП» и «старого, проверенного ПП» легко компенсировал этап разработки конфигурации, т.к. возможности программирования в новой платформе не только шире, но и значительно проще реализуются. В длительной же перспективе гибкость «1С:Предприятия 8» сэкономит больше денег на реализации разнообразных дополнительных пожеланий.

Разработка структурных решений

 

Стиль программирования на платформе «1С:Предприятие 8» в целом не отличается от того привычного стиля, который, как известно, называется структурным стилем «сверху вниз», то есть «с конца». Сначала были нарисованы самые подробные варианты отчетов и определили, что их можно отнести к трем группам: «Остатки финансов», «Анализ движения финансов», «План-фактный анализ». Исходя из того, что пользователь системы может не обладать знаниями и опытом бухгалтера, было принято решение о реализации задачи на оперативных, а не бухгалтерских объектах.

Существо же показателей, выводимых в отчетах, позволила спуститься на одну ступеньку вниз и определить структуру оперативных регистров. Показатели остатка, показатели движения (оборотов), показатели состояния были реализованы на регистрах остатков, регистрах оборотов и регистрах сведений – соответственно. Разрезы (группировки) информации в отчетах определили наборы измерений регистров, показатели – наборы ресурсов.

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

Единственное, что заставило задуматься – это реализация структурной схемы компании с использованием справочников. С одной стороны, структура должна быть иерархическая, с другой – хоть и с небольшой вероятностью, но она может изменяться. А «помнить» надо и старую структуру, и новую. Замечательным выходом из положения стало разделение структурной схемы компании на три справочника «Отделы», «Сотрудники», «Проекты» (проекты) с ведением истории иерархического подчинения на двух периодических регистрах сведений «ЗакреплениеСотрудников», «ЗакреплениеПроектов». Кроме обеспечения гибкости во времени, это структурное решение очень сильно облегчило впоследствии реализацию технологии быстрого заполнения документов. Для отнесения некоторого дохода или расхода к определенному проекту, определенному сотруднику и определенному отделу пользователю достаточно начать набирать название проекта в реквизите «Проект» и нажать « Enter ». Система сама завершит дело – или подставив конкретный проект из справочника, или предложив на выбор несколько созвучных элементов.

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

 

Работа с формами.

 

При создании форм для данного проекта средствами «1С:Предприятия 8» душа просто пела потому, что их создавать… не надо. Это, конечно, шутка, … но с большой долей правды. Из своего опыта можем утверждать, что создавать формы в конфигураторе есть смысл в том случае, если пользователь нуждается в дополнительном сервисе. Так, для 26 объектов конфигурации, включая вспомогательные, было создано всего 10 форм. Все остальные строятся системой «на лету», при обращении пользователя к данному объекту. Более того, заметили, что эргономика и эстетика этих форм, построенных системой, зачастую даже выигрывают по сравнению с создаваемыми руками программиста.

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

Интересно сравнить реализацию этого свойства в двух платформах 7.7 и 8. Сначала добавляем на диалог два табличных поля. После чего надо обеспечить их заполнение информацией при «скольжении» курсора в верхней таблице по строкам с документами. Опытные программисты наверняка знают, как решить подобную задачу для v 7.7, а главное, знают, чем за это придется «заплатить».

Для реализации того же свойства в «1С:Предприятии 8» все было сделано без программистских «финтов» и изощрений. Рассмотрим эту операцию пошагово, чтобы не быть голословным.

Шаг 1. Открываем свойства верхнего табличного поля.

Шаг 2. Выбираем среди двух десятков событий интересующее нас и нажимаем кнопочку «с лупой». Попадаем в обработчик этого события. Процедура принимает еще параметр «Элемент», смотрим в «отладчике», - что за контекст падает на этот параметр и понимаем, что - это контекст всего табличного поля. Прокручиваем список свойств данного объекта, смотрим, чем они заполнены:

Шаг 3. Видим, что свойство «ТекущаяСтрока» возвращает контекст документа активной строки. Именно это нам и нужно - заполнить данными этого документа элементы данной формы, т.е. нижние табличные поля.

Шаг 4. Начинаем писать текст процедуры с ЭлементыФормы, ставим точку, и… контекстная подсказка дает на выбор полный перечень свойств и действий, которые могут понадобиться:

То же самое происходит и после выбора очередного объекта в качестве свойства.

Подведем итоги первого опыта программирования на v 8. Текст процедуры заполнения нижних таблиц - это буквально два раза по две строчки, причем, и эти строчки написаны скорее синтаксис-подсказчиком, чем программистом. Вот что получилось в результате:

Мы намеренно подробно остановились на описании типичных действий программиста, при написании кода на v 8, чтобы показать: для более-менее уверенного программирования на новой платформе не требуется полугода или года наработки практического опыта в виде всевозможных приемчиков и финтов. Для первых внедрений будет достаточно активно использовать синтаксис-помощник, синтаксис-подсказку и отладчик. Достаточно просто прохождения какого-нибудь установочного курса, дальше все идет значительно легче.

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

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

 

Проведение документов.

 

Безусловное проведение, т.е. проведение без каких-либо дополнительных расчетов, когда данные из документа непосредственно участвуют в заполнении записей регистров, выполняется конструктором движений. Это один из элементов механизма быстрой разработки приложений. В рассматриваемом проекте это относилось к движениям по регистру «Остатки денежных средств» и в большинстве случаев при проведении по регистру «ДвижениюФинансов». Наиболее «сложным» моментом была реализация распределения общефирменных расходов или расходов отделов на нижестоящие элементы структуры компании. В большинстве случаев точно известно, к какому проекту относиться те или иные затраты, но иногда возникают расходы, например, аренда офиса, которые «обременяют» все активные проекты одновременно.

Однако, если разносить такие затраты на все проекты «равномерно», получится не слишком адекватный управленческий результат — рентабельность только-только начинающего раскручиваться проекта будет, как правило, получаться очень низкой. А ведь начинающих полагается опекать и терпеливо взращивать. Потому было принято решение о введении «коэффициентов распределения» расходов, позволяющих гибко управлять этим процессом, причем, величины коэффициентов распределения могут меняться с течением времени. Для реализации таких временных изменений использовали регистры сведений. Основа дальнейшего решения была реализована в конструкторе запросов:

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

 

Формирование отчетов.

 

Отчет «ОстаткиФинансов» весь, вплоть до последнего «винтика», построен конструктором выходных форм. Это результат реализации средств быстрой разработки приложений в новой платформе.

Программисту пришлось просто отвечать на вопросы конструктора. Все остальное - диалог, модуль, макет, работа с расшифровками в табличном документе, — система сделала сама. Единственное, что дописывали вручную, — это все поля группировки на макете свели в одну колонку для экономии места.

 

Универсальный отчет

 

Отчет «Анализ Движения Финансов» — это самая красивая часть конфигурации. Формат статьи вряд ли позволит привести все возможные режимы его использования. Рассмотрим только два режима из всего разнообразия: "шахматку" с использованием группировки и диаграммы.

В данном отчете можно использовать более 20 видов диаграмм. На рисунке приведен один из них - «круговая объемная» для доходов одного из отделов по проектам. Рассмотрим этапы создания отчета более детально. Начнем с назначения отчета, как было определено в техническом задании:

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

  • По затратам
  • По доходам
  • По доходам и расходам
  • Рентабельность

Отчеты должны позволять использовать фильтры по:

  • периодам формирования;
  • отделам;
  • сотрудникам;
  • проектам;
  • статьям доходов и расходов.

С подключением или отключением разворотов информации по группировкам:

  • Итоговой;
  • Отдел;
  • Сотрудник;
  • Проект;
  • Статьи доходов/расходов;
  • ДокументыДвижения

Возможная периодичность:

  • Год;
  • Месяц;
  • Неделя;
  • День.

Уверен, что специалисты по версии 7.7 оценят, сколько пришлось бы писать кода, чтобы реализовать такую функциональность «с нуля». В конфигурации на базе «1С:Предприятие 8» выполнили четыре шага.

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

Шаг 2. Прописываем действия по нажатию на кнопку «Сформировать»

Шаг 3. Пишем процедуру ФормирЗапрос(), основа которой - текст запроса:

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

 

Опыт использования диаграммы

 

Хотелось бы описать опыт использования диаграммы. Уже на этапе тестирования выяснилось, что один из режимов отчета «Доходы и расходы одновременно» плохо отображается в диаграмме. Диаграмма построителя отчета настроена на один показатель, а в нашем случае требовалось выводить два.

Первое решение было, естественно, лобовым. Решили видоизменить текст запроса так, чтобы два показателя ретранслировались в один, но с дополнительной группировкой по виду движения. Операнд «Выбор» позволял это делать, но после этого «улучшения» стал «съезжать» другой режим работы отчета, за исправлением этого – еще что-то не понравилось…

И только, когда решился остановить этот «марш улучшений» и просто ввести в оборотный регистр еще один ресурс, все вернулось в исходное – лаконичное и красивое — состояние. Отсюда вывод: надо больше доверять структурным решениям, как бы ни хотелось перепробовать все программистские.

 

Организация бюджетов

 

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

Программно это выглядело так:

Ничего сверхъестественного. Отчет «План-Фактный анализ» опять же был получен конструктором выходных форм. На этом собственно, программистская работа была завершена.

 

Возможности системы, не потребовавшие программирования

 

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

  • Заполнение реквизитов документов ссылочного типа по первым символам наименования,
  • Организация сложных отборов в формах списков;
  • Организация сложных сортировок в формах списков и выходных формах отчетов;
  • Ведение списка популярных отборов;
  • Организация сложных фильтров при получении аналитических отчетов (по элементам, по группам, по спискам, исключая, включая, равно, больше, меньше, больше или равно… )
  • Организация отчетов в виде сводной таблицы;
  • Построение диаграмм;
  • Возможность печати содержимого любого табличного поля в виде табличного документа;
  • Возможность сохранения копии любого табличного документа в виде файла Excel

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

 

Выводы

 

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

  1. Практически у всех принимавших участие во внедрении за спиной 3-5 летний опыт программирования в системе «1С:Предприятие 7.7». За это время в ней наработаны, наверное, сотни приемов программирования. Но половина из них – бесполезны в новой версии, т.к. уже обобщены и реализованы разработчиками платформы. У всех, кто переходит на v 8, уже был или будет период неуверенности в своих силах. Он не бесконечен! Программировать в v 8 – это … просто красиво!
  2. Как среда разработки, новая версия платформы очень дружелюбна. Перечислим лишь некоторые из приятных программисту свойств:
    • контекстная подсказка;
    • удобный отладчик;
    • синтаксис-помощник с гиперссылками;
    • больше дюжины конструкторов (чаще всего используются: конструктор запросов, конструктор выходных форм, конструктор движений… );
    • построение форм «налету» по умолчанию, а если надо - конструктор формы;
    • построитель отчета;

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

     

  3. Несмотря на мощный программистский функционал новой платформы, предпочтение следует отдавать структурным решениям. Правильно построенная конфигурация позволяет экономить часы кодирования, получается более устойчивой и, в то же время, более гибкой для развития и модификации. Для оптимизации процесса разработки лучше придерживаться одного из следствий принципа Оккама: «наиболее устойчивы и жизнеспособны - простые решения». В платформе «1С:Предприятие 8» заложено много возможностей, позволяющих добиться простыми приемами реализации сложных, зачастую даже слабо формализованных задач.
  4. Что такое 4 дня для разработки конфигурации под задачу подобного класса? На самом деле, это очень много. Половина времени была потрачена на делание ошибок и их исправление, на переосмысление задачи снова и снова, на выбор между возможностями, от которых разбегаются и глаза, и размышления.
Нашли ошибку на сайте? Напишите о ней нам!
Наверх Обратный звонок