Не клади яйца в одну корзину. Как удовлетворить всех клиентов и не превратить конфигурацию в помойку

05.02.21

Управление проектом

Изменения законодательства вынуждают разработчиков регулярно обновлять свои программные продукты, но такие обновления могут сломать существующие возможности. О том, как выйти из этого положения и создать универсальную конфигурацию, используя расширения конфигурации как подключаемые модули учета, рассказал разработчик компании Лаборатория-33 из Ижевска Константин Мартынов.

 

 

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

 

Проблемы из-за универсальности программы

 

 

Разработкой учетной системы я занимаюсь уже более 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.

См. также

Компетенции и навыки РП Руководитель проекта

Есть занятный психологический эффект, когда мы игнорируем проблемы, с которыми мы не понимаем что делать. В своей книге “Вальсируя с медведями” авторы назвали этот эффект “А, вы имеете в виду этот приближающийся поезд…”

05.11.2024    1102    0    MariaTemchina    1    

27

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного РП и тимлида. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все особенности работы руководителей проектов.

02.05.2024    3656    0    biimmap    39    

39

Канбан и поставка ценности Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

При разработке 1С:Бухгалтерии 8 используются унифицированные процессы обработки задач, построенные на методике Kanban. О том, как выглядит доска задач, в чем пишут код команды – в конфигураторе или в EDT, и что делается для повышения качества и понятности кода самого многопользовательского проекта фирмы «1С», пойдет речь в статье.

26.04.2024    5019    0    mrXoxot    5    

29

Канбан и поставка ценности Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

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

23.04.2024    3836    0    user1853337    8    

29

Инструменты управления проектом Руководитель проекта Бесплатно (free)

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

01.04.2024    3176    0    MariaTemchina    6    

22

Кейсы проектов Руководитель проекта Бесплатно (free)

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

20.12.2023    4829    0    1СERP    21    

31

Кейсы проектов Программист Бизнес-аналитик Пользователь Руководитель проекта Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    15722    0    ASchekachev    37    

55

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    6552    0    stnslv    5    

25
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. DitriX 2102 06.02.21 15:05 Сейчас в теме
Просто для реализации данной модели - надол отказаться от конфигуратора, и все, и тогда все станет красиво.
2. 33lab 944 07.02.21 07:03 Сейчас в теме
(1) Боюсь, что простой отказ от конфигуратора не сделает "все красиво" :)
3. DitriX 2102 07.02.21 12:03 Сейчас в теме
(2) а git вы же используете, верно?
Просто некоторые вещи которые вы описали как недостатки платформы - по сути, недостатки конфигуратора :)
4. 33lab 944 08.02.21 07:39 Сейчас в теме
(3) Ну тут не поспоришь :)
5. Cyberhawk 135 11.02.21 16:57 Сейчас в теме
При отключенных расширениях (а когда расширений у вас много, то вы часть из них, разумеется, отключаете, чтобы спокойно проверять другие) при входе система 1С нас об этом информирует
Кажется, такое поведение наблюдается только у администраторов (пользователей, у которых есть роль, дарующая право "Администрирование")
6. 33lab 944 12.02.21 07:32 Сейчас в теме
(5) На данный момент времени это уже не так актуально т.к. в "1С: предприятии - оповещение и запуск" появилась возможность "Закрыть все".
7. RustIG 1749 17.02.21 02:27 Сейчас в теме
Пользователь покупает именно ядро конфигурации, и далее уже сам решает, какие дополнительные модули ему нужны. Если он не работает с Меркурием – он не поставит этот модуль, не работает с ЕГАИС – не поставит ЕГАИС.


В типовой конфигурации типовые модули Меркурия и ЕГАИС все же остаются? Я так понимаю, только ваши расширения не ставятся на программу?
8. 33lab 944 17.02.21 07:24 Сейчас в теме
(7) Речь шла не о типовых конфигурациях а о конфигурации которую мы разрабатываем, внедряем и сопровождаем Модульная (open source) конфигурация "INFOSTART ERP community edition" следовательно у нас перечисленные модули (как и многие другие) - это расширения.

P.S. Типовые конфигурации написаны по принципу "все в одном", предполагая, что ненужные конуры учета пользователь просто скроет(отключит) через функциональные опции.
9. Dnki 4 17.07.21 16:41 Сейчас в теме
Замечательная идея! Согласен с автором статьи, что основная проблема 1С - ее громоздкость. Мы разработали небольшую конфигурацию (до 60 справочников, 70 документов), но и она стала своеобразным клубком, в котором страшно дернуть ту или иную ниточку.
Второе неудобство клубка - нет наглядности в разделении на подсистемы при разработке. Как ни пытайся разделять по подсистемам, не видел, что разработчики этим пользуются. А разделение по Расширениям носит жесткий характер.
Оставьте свое сообщение