Наша компания занимается разработкой конфигурации для комплексного учета на предприятиях без необходимости модификации данной конфигурации под нужды конкретного предприятия. Другими словами, все наши клиенты работают на одной единой системе. В статье я расскажу том, с какими сложностями при разработке мы сталкиваемся, и какие пути решения для себя определили.
Проблемы из-за универсальности программы
Разработкой учетной системы я занимаюсь уже более 15 лет. Сначала это была семерка, потом восьмерка. Механизмы меняются, меняется платформа, но не меняется общий принцип разработки – функциональность конфигурации всегда должна расти, хотите вы этого или нет, но она будет расти.
Причем, неважно, насколько у вас универсальная и суперфункциональная конфигурация – новые возможности будут нужны всегда. Либо это будут новые сферы бизнеса, либо это будут требования законодательства в виде различных ЕГАИСов, Меркуриев, онлайн-касс и так далее.
Рост функциональности ведет за собой рост сложности как разработки, так и самой программы. При этом у пользователей не очень большой выбор: они могут либо отдельно ставить конфигурации типа УТ, БП, ЗУП и обмениваться между ними данными, либо сразу выбирать большую конфигурацию типа УПП или ERP и начинать работать на ней. В процессе выбора им приходится заранее продумывать, какие возможности могут понадобиться – нужен ли ЕГАИС, Меркурий, штрихкодирование и т.д. Поэтому, если есть деньги, пользователи, как правило, сразу берут ERP.
Но покупка сразу большой конфигурации несет большие расходы как на саму конфигурацию, так и на ее внедрение и поддержку. В таких конфигурациях добавлять новую функциональность без нарушения работы старой становится практически невозможно – поскольку система сложная, то всегда где-нибудь что-нибудь обязательно будет задето. Поэтому пользователи начинают бояться обновлений. Я не знаю, сталкивались ли вы с ситуацией, когда пользователи сразу после обновления звонят разработчику и высказывают ему много интересного, заканчивая словами: «Верните все так, как было!». Разработчик, конечно, постарается вернуть старые возможности, но при этом обязательно где-то ошибется и поломает новую функциональность. И так постоянно: невозможно добавить при обновлении новые возможности так, чтобы пользователь был счастлив. Такого не будет практически никогда.
Есть ли выход?
Какой выход из данной ситуации мы определили для себя?
Мы решили разбить всю разработку на модули. Небольшие модули проще поддерживать. Поэтому мы выделили из одной большой конфигурации ядро конфигурации и дополнительные модули в виде расширений. Благо, платформа 1С позволяет нам сейчас это сделать.
Преимущества такого подхода:
-
Появляется возможность разграничить разработчиков, чтобы они могли заниматься как ядром, так и отдельными модулями, отдельными расширениями – кто-то может заниматься ЕГАИС, кто-то Меркурием, кто-то штрихкодированием, кто-то вести ядро.
-
Сами модули достаточно лаконичны, и обладают ограниченной функциональностью, которая не будет постоянно расти. Да, она может меняться или видоизменяться, но ее границы всегда видны.
-
Пользователь покупает именно ядро конфигурации, и далее уже сам решает, какие дополнительные модули ему нужны. Если он не работает с Меркурием – он не поставит этот модуль, не работает с ЕГАИС – не поставит ЕГАИС. Мы все пользуемся телефонами и всегда сами решаем, какую программу поставить. Мы не получаем изначально систему, в которой есть все программы. Нет, мы поставили изначально Android или iOS и постепенно добавляем программы с нужной нам функциональностью, выбирая из тех, что есть. Если что-то не понравилось, мы это удаляем. Здесь точно такой же подход: изначально пользователь получает ядро конфигурации, а далее он решает, что ему нужно. Либо что ему уже не нужно.
Как мы разделили ядро и основную функциональность
Ядро, по нашему мнению, это базовая функциональность учетной системы – то, без чего учетная система, по большому счету, не имеет смысла. Ядро должно быть небольшое, легкое, быстрое, простое. Оно должно предоставлять возможности для разработчиков расширений. Само ядро должно быть достаточно универсальным, как автомат Калашникова, – отлаженным и просто работать.
В ядро мы выделили такие вещи, как:
-
учет ТМЦ – поступление товаров, списание, перемещение, инвентаризация, работа с товарами предприятия;
-
учет денежных средств – это такие документы, как приходно-кассовый и расходно-кассовый ордер, платежки (входящие и исходящие), все, что связано с деньгами предприятия;
-
управление проведением – я чуть позже к нему вернусь, объясню, что это за контур;
-
управление отчетами – это общие механизмы настройки, сохранения и восстановления, общий вид формы, чтобы он был идентичным, и пользователям не приходилось привыкать к новым видам отчетов;
-
и конечно, магазин расширений – к нему я тоже вернусь чуть позже.
Все остальное можно смело выносить в расширения. Это:
-
библиотека подключаемого оборудования;
-
ВетИС (Меркурий);
-
ЕГАИС;
-
другие дополнения (все, что перечислено на картинке).
И оно спокойно подключается и работает, не мешая основной программе.
Пользователь, видя, какие есть расширения, сам решает, что ему подключить.
При таком подходе количество выпускаемых обновлений уже меньше, чем когда обновляется одна большая система. При большой системе пользователям постоянно приходится обновляться, у них просто нет выбора. А здесь у каждого модуля свое обновление: поменялось что-то для ЕГАИС, значит выпустили обновление для ЕГАИС, поменялось что-то в Меркурии, выпустили обновления для него. Обновляются только те, у кого есть эти контуры.
Причем обновление расширений зачастую позволяет обновлять конфигурацию без необходимости монопольного режима. Особенно когда в новых редакциях расширений не были изменены метаданные, либо когда изменения метаданных коснулись только отчетов или обработок, которые не требуют монопольного режима.
При подобном подходе к разработке нужно помнить, что у нас появляется два вида разработчиков – это разработчики ядра и разработчики расширений.
Разработчики ядра должны в первую очередь заботиться о разработчиках расширений, потому что ядро они изначально пишут не для себя, а для разработчиков расширений. Следовательно, разработчики ядра должны предоставить разработчикам расширений все те же самые возможности, которыми обладают сами. По крайней мере, постараться это сделать.
-
У разработчиков расширений должна быть возможность расширить табличные части. Для этой цели в ядре у табличных частей основных документов должен быть реквизит «идентификатор строки». Имея такой реквизит, достаточно просто расширять табличные части.
-
Далее расширение объектов метаданных. На текущий момент расширение не позволяет создавать все объекты метаданных. Например, сейчас пока нельзя создавать бизнес-процессы, соответственно, в ядре должен быть базовый бизнес-процесс, который можно будет захватить в расширение, и его уже расширить.
-
Также необходимо предоставить разработчикам расширение всех событий, форм, объектов, контекста и окружения. Чтобы разработчикам расширений не приходилось захватывать формы и менять их визуально. Вообще изменение форм, на мой взгляд, должно быть только программным. А для этого у разработчиков расширений должны быть все возможности, чтобы перехватить создание и обновление формы, где их можно без проблем видоизменять.
Унификация форм.
Чтобы разработчикам расширений было легко и просто добавлять свои элементы на формы, они должны знать, как эти формы устроены.
Большинство форм – 90% – достаточно простые, и они все строятся по одному шаблону. Это:
-
шапка документа, которая обычно делится на левую и правую часть (поставщик – покупатель)
-
и центральная часть формы со вкладками, где расположены табличные части.
У себя мы еще разбили это на страницы: на первой странице все данные документа, а следующие страницы нужны для того, чтобы разработчики расширений добавляли свои элементы на форму (программно, разумеется).
На слайде показан результат подключения в базу расширение «Вложения».
В данном случае у документа появляется закладка «Вложения», где находится динамический список с вложениями и предпросмотром выделенного вложения. Разработчик расширения, зная, как устроена форма, легко и непринужденно добавляет свои элементы на форму.
Я обещал вернуться к управлению проведением и рассказать, что это означает.
Ядро конфигурации должно содержать работу с бухгалтерским учетом, потому что довольно сложно представить себе предприятие без бухгалтерского учета. Разработчик расширения не должен задумываться о том, как ему провести документы по бухгалтерскому учету – все это должно быть реализовано в ядре.
Для себя мы создали механизм «Типовых операций», который позволяет настроить проводки пользователю. В случае выбора определенной типовой операции в документ, система сформирует по регистрам бухгалтерии соответствующие проводки.
Для этого существует справочник настроек, который подчинен объектам метаданных (в данном случае, документам). У любого документа может быть любое количество проводок, настроенных пользователями.
В справочнике выбирается, каким образом будет заполняться аналитика (на языке 1С – субконто). Субконто может быть как общее, так и отдельно заполняться по дебету или по кредиту в зависимости от ситуации.
Далее пользователь указывает, откуда берутся значения для заполнения этих субконто. Значения могут браться как из реквизитов табличной части, так и из реквизитов шапки. В крайнем случае, можно написать алгоритм заполнения на языке 1С, но такое бывает очень редко.
Далее пользователь выбирает для формируемых проводок счет дебета и счет кредита, а также показывает, что является источником данных для ресурсов.
Как и для аналитики, пользователь может выбрать значение ресурсов:
-
из реквизитов табличной части;
-
либо из реквизитов шапки;
-
либо из определенных значений, таких как учетная стоимость дебета, учетная стоимость кредита;
-
либо есть тонкая настройка, если понадобилось написать какой-то алгоритм на языке 1С. В частности, можно выбрать данные из уже проведенных регистров. Например, документ «Реализация» при проведении сделал движение по регистру «Учет партии». Соответственно, в этот момент была рассчитана и заполнена учетная стоимость. Нет никакого смысла рассчитывать ее второй раз, если мы, конечно, не хотим разделить бухгалтерскую и управленческую учетную стоимость. Мы можем просто обратиться к данному регистру и взять оттуда рассчитанные данные, чтобы провести их в регистр бухгалтерии.
Таким образом выглядит результат после проведения документа.
Другими словами, чтобы разработчику расширений включить возможность проведения своего документа по бухгалтерскому учету, ему в своих документах достаточно:
-
добавить на форму реквизит со ссылкой на типовую операцию – либо в табличную часть, либо в шапку (в зависимости от ситуации);
-
затем вынести подписку на событие в обработку проведения.
Все. При заполнении реквизита и проведения документа система сделает движения по бухгалтерскому учету. Никакого программирования внутри делать не требуется.
Магазин расширений
Чтобы пользователь мог видеть, какие есть расширения, выбирать среди них что-то для себя, и в дальнейшем обновлять эту функциональность, в ядро встроен магазин расширений – он работает как любой другой магазин типа App Store, Google Play, к которым уже все, я думаю, привыкли.
Здесь указаны: расширения, их авторы, стоимость, если это расширение платное, есть описание, что система делает, есть оценки и комментарии от пользователей, благодаря которым организуется некая обратная связь с авторами.
Пользователь может оплатить нужное расширение путем разовой оплаты или через подписку, установить его и работать спокойно, обновляться прямо отсюда – не надо заходить в конфигуратор, можно обновляться прямо из режима «1С:Предприятие». Это может сделать любой пользователь, любой бухгалтер. Если вдруг какое-то расширение стало больше не нужно, его можно либо просто отключить – тогда данные расширения продолжат храниться в программе, либо расширение можно полностью удалить.
Недостатки подхода
У любого подхода всегда есть недостатки.
-
Весьма неприятно в расширениях, если вы с ними работали, то замечали, отсутствие единого контекста на уровне конфигуратора. Когда мы создаем какой-нибудь отчет, обработку, запрос динамическому списку и пытаемся обратиться к объектам, которых нет в этом расширении, система нам просто не позволит ничего сделать. Если с объектами из основной конфигурации более-менее все понятно, их можно просто заимствовать в расширении, и проблема исчезнет, то с объектами других расширений так не прокатит. Тут придется программно создавать запросы, что не очень удобно.
-
Следующий момент – отсутствует возможность расширения типов объектов. Это тоже самое, что и отсутствие возможности указания типа «ЛюбаяСсылка». Если мы захотим каким-то образом расширить объекты в нашем расширении, то на текущий момент нам этого сделать не удастся. Приведу пример с расширением «Вложения» – казалось бы, очень просто создать в расширении регистр сведений, указать ссылку на документ или на тип «любая ссылка» и подключить его как, чтобы система записывала туда все вложения. Но если объекты основной конфигурации мы можем заимствовать, с этим проблем нет, то что делать с объектами других расширений? У вас в системе могут быть подключены расширения с новыми видами документов – к ним тоже хотелось бы хранить вложения. Но поскольку у нас отсутствует возможность указания типа «ЛюбаяСсылка», мы не можем это сделать. Тут приходится просто указывать отдельно ID, отдельно тип. Это немного неудобно, но тем не менее это все рабочее. Это не то, к чему мы привыкли, есть небольшие неудобства, но к этому можно привыкнуть, когда вы с этим работаете. Надеюсь, что со временем 1С что-то сделает с этим, как-то поправит, даст нам какой-то механизм, чтобы нам не приходилось преодолевать такие трудности.
-
Есть еще сложности при отключении. Как бы смешно ни звучало, но не все расширения можно просто взять и отключить. Точнее, отключить, конечно, их можно, но если расширение делало движение по регистрам, по которым делают движение основные документы, и вы его отключите, то после этого в Предприятии вы не сможете не только сделать по нему движение, вы не сможете прочитать данные по нему, система выдаст ошибку о несовместимости регистров с основной базой. Я не помню, как она точно звучит, но смысл в том, что ошибка будет. То есть просто отключить расширение нельзя. Можно его либо удалить, либо включить обратно. Удалить мы его не можем, так как оно нам нужно. Поэтому приходится включать обратно.
-
Что еще нам нужно помнить? Если мы заимствуем какие-то модули, нужно помнить, что разработчик ядра может их всегда изменить, удалить, сделать все, что угодно. Поэтому с заимствованием модулей надо быть аккуратнее.
-
Еще есть неприятные моменты при подключении расширений к хранилищу конфигураций. Когда разработкой расширений у вас занимается несколько разработчиков, и вы работаете через хранилище, нельзя подключиться ко всем расширениям сразу, приходится подключаться к каждому расширению по отдельности.
Когда у вас одно-два расширения – это не так страшно. Но когда у вас десяток расширений, и при входе в конфигуратор система у вас для каждого хранилища расширения спрашивает: «Подключиться? Да, нет», «Подключиться? Да, нет». Со временем это, мягко говоря, надоедает, поскольку на каждый из вопросов нужно нажать «Да», «Нет» или «Esc», и не забыть, что ты нажал, потому что потом оказывается, что к нужному хранилищу расширения ты не подключился.
Я все-таки надеюсь, что эту проблему 1С тоже поправит.
Есть довольно смешная, казалось бы, проблема, которая сильно действует на нервы.
При отключенных расширениях (а когда расширений у вас много, то вы часть из них, разумеется, отключаете, чтобы спокойно проверять другие) при входе система 1С нас об этом информирует. Правда, не знаю, зачем, но информирует очень навязчиво.
Табличка в виде трех расширений, как на слайде, выскакивает и висит три секунды минимум. Если у вас десяток отключенных расширений, вы 10 секунд тупо смотрите в экран – либо вы пытаетесь их по очереди закрыть, либо ждете, когда они все исчезнут. Что самое обидное, эти уведомления невозможно выключить.
Особенно это достает, когда вы пытаетесь что-то отладить через отладчик, запускаете систему и она из-за этих окон на какое-то время «зависает».
Плюсов больше
Несмотря на все эти минусы, когда мы перешли на модульный подход к разработке, проблем у нас стало гораздо меньше.
Если раньше мы выпускали обновление по каждому поводу, по каждому чиху (изменилось что-то в ЕГАИС или в регламентированной отчетности – получи обновление), и всем пользователям приходилось обновляться, потому что, кроме изменений, исправлялись ошибки, добавлялись какие-то нужные для всех, казалось бы, возможности. И были проблемы с тем, что пользователи постоянно звонили, говорили, что после обновления «все пропало».
Сейчас все стало гораздо проще.
-
Пользователи разделились по функциональности – например, у нас всего один «алкоголик», которому нужна функциональность ЕГАИС – мы для него эту функциональность поддерживаем, и никаких проблем нет. И есть несколько человек, которым нужна функциональность Меркурия – ее мы тоже отдельно поддерживаем.
-
И разработчик спокойно разрабатывает, не думает, что сейчас что-то нарушит в общей системе – он спокойно дорабатывает свой отдельный модуль, и никоим образом не влияет на всю систему. Его обновления выходят настолько часто, насколько это надо, а вся система остается нетронутой.
-
Та же самая картина с регламентированным учетом. Раньше при выходе обновлений регламентированной отчетности, мы постоянно мучились, потому что на каждое такое обновление всегда нужно было выпускать отдельный релиз. Даже при том, что не все пользуются регламентированным учетом, обновляться все равно приходилось всем. Сейчас эта проблема решена.
-
И дополнительные контуры нам стало гораздо проще разрабатывать. Мы отдельно вынесли «Розницу», отдельно «Библиотеку подключаемого оборудования». И система сейчас при выпуске не такая огромная, как раньше, в 200 мегабайт. Люди подключили у себя «Библиотеку подключаемого оборудования», и потом они получают небольшое обновление основной программы.
Я считаю, что самая большая проблема 1С – это единая конфигурация и ее частые обновления, потому что при этом постоянно вылезает много ошибок. После того, как мы перешли на такой путь, разработка стала гораздо проще.
Вопросы
-
Я правильно понял, что вы разработали некое ядро, выложили его в облако и начали сдавать в аренду?
-
Не совсем так. Мы создали ядро, мы создаем расширения и продаем их нашим клиентам. Часть расширений бесплатные, есть и платные. Это та же самая программа, которую мы продавали раньше, просто мы ее разбили, поняли, что вести одну большую конфигурацию типа ERP – очень сложно. Это, видимо, нужен отдел, как в фирме «1С», куча тестировщиков и Бог знает, что еще. И при этом клиенты всегда недовольны, им не нужна вся эта функциональность.
-
Я знаю, что в Европе одна компания создала конфигурацию, некое ядро, выложила в облако и начала сдавать в аренду. Своим клиентам она в дальнейшем предоставляет дополнительные модели – по производству, торговле и так далее – за определенную стоимость. Грубо говоря, основная конфигурация стоит, например, 10 евро в месяц. Если добавили производственный блок, стало стоить, например, 15 евро. И самое интересное, что многие клиенты сейчас выбирают их решение, а не флагманское решение от 1Ci – конфигурацию 1С:Drive. Клиентам больше нравится вариант решения, когда можно закупать блоками, поэтому я думаю, что в таком подходе есть смысл.
-
У нас точно такой же подход. У нас пользователи каждый месяц платят за конфигурации и за модули отдельно. И если они захотят сменить деятельность, они могут просто отключить модуль, и все. У нас был клиент, который решил, что ему больше не выгодно заниматься молоком. Они отказались от нашего модуля Меркурий и продолжают дальше вести учет в той же конфигурации – там все и без этого модуля работает.
*************
Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Kazan.
