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

на мой взгляд текущий путь - тупик,

или надо всех переводить на ЕРП где все есть и лицензиями прикрывать часть модулей (при этом подходе разработчику будет проще)

или все-же оставить бухию относительно простой и все расширения функционала переводить в расширения


как Вы думаете?

(0) Ветис в расширение - работает без проблем. Как впрочем и многое другое перенесено в расширение - работает.

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

(2) Какая еще "скорость выполнения"?

(3) Совсем недавно в соседних темах ссылку приводили:
https://its.1c.ru/db/metod8dev#content:5940:hdoc

Ты дал ссылку, опровергающую твои слова. Забавный.

(5) Т.е. повышенная нагрузка на CPU и более долгое выполнение обработок из расширения = хорошая практика?

Какое еще "более долгое выполнение"?

(7) Обработка в конфигурации: 322 сек
Обработка в расширении: 406 сек
Внешняя обработка: 513 сек

(7) кофейку попей, не проснулся ведь.
Там время стоит.

А, ясно. Много букв - Я читал только заголовок и последний абзац.
Про расширения увидел, спс.
Но процент прироста имеет мало смысла при таких длительных операциях. Подумаешь, 6 минут вместо 5.

(10) В Ветис это критично :'(

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

(11) т.е. ничего нового от 1С больше не ждем, ни новых платформ, ни новых релизов конфигураций - ничего! Расплакались и ушли дальше грызть кактус.

зато 1с сможет продавать расширения по отдельному прайсу, нпример бухия - 10тр, ветис - еще 3тр, егаис - еще 3тр, интеграция с докуметнооборотом еще 3тр итак далее....

по  существу это путь котрый все отраслевые конфы сделает не нужными.

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

(14) но для этого еще в БСП далеко. Нужно ее дорабатывать и дорабатывать.

(15) я этот путь предлогал лет 7 назад... жаль, что 1с столько времени потеряла

(0) абсолютно не важно что мы думаем. у 1с свое видение.
Или ты решил выпиливать данные блоки?

(0)[уже сейчас бухия стала слишком прожорливой, и не поворотливой]
ты бредишь

(18) Он просто ЕРП не видел

(19) Так бухия со скоростью паровоза туда летит.
Уже есть справочник ключи аналитики для НДС и УСН
Я так понимаю следующий шаг - виды запасов в ТЧ документов?

(20) ну и правильно. зачем нужны разные подходы. а так один прог может и ут и бп пилить

(0) Рано ты с такими заявлениями. Я к тому что в сентябре 1с обещала перевести бухию на 12 платформу, вот тогда и можно говорить об этом

(16) Наверстает, все к этому идет.

(14) да, когда 1С так сделает - все отраслевые умрут (да и не только отраслевые)..если вовремя не сообразят и не переведут свои отраслевые в расширения.

(24) Ну-ну. До этого могут умереть эти самые расширения

(24) думаешь куча конкурентов сразу появится? или как?

(26) Он в принципе не думает ;-)

(14) Думаю надо делать еще круче - создать базовую конфигурацию с общими модулями и справочниками, которые есть в большинстве конфигураций - номенклатура, контрагенты, ФЛ и т.д.
А дальше все по желанию клиента, нужна БП - вот расширение в котором это реализовано, нужна торговля - вот еще расширение и т.д. Хоть ЕРП собирай по кусочкам если нужно. Вот это действительно будет круто, если так сделают.

(28) в ЗУП нет номенклатуры

(29) Сегодня нет, а завтра зачем-нибудь появится. Например зарплату товарами будут выплачивать :)
Было же такое в лихие 90-е...

(30) Типун тебе.

(25) Сомнительно, за расширениями будущее (имхо).
(26) думаю - да.
(27) Всегда думаю и тебе советую (это не так страшно как кажется)

Поддержу (25).
В 1с некому да и наверно денег нет переводить всё это в расширения и сопровождать/развивать.

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

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


то де бсп для этого сделали

(32) Ну в (34) Тебе все ответили, от себя добавлю, что всеми типовыми с маркой "Совместно" владеет компания 1С ;-)

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

(34) Да, схему разработки нужно менять в корне.

>>Вендору в первую очередь
Почему такое мнение? 1Су это как раз должно быть выгодно (в перспективе).

(35) Ну и назови крупных франчей в сравнении с тем же БИТом, которые не принадлежат 1С?

(34) Как раз вендор заинтересован в первую очередь, так как он сможет через фреш продавать SaaS из этих расширений

(36) >>отомрет часть бизнеса, которая сейчас приносит деньги.

Не совсем так - просто 1С подсадит всех на расширения и в перспективе это будет намного выгоднее чем сейчас отраслевые.

(40) Что ты пристал с отраслевками. По этой схеме можно было бы и конфы от вендора делать. Если бы указанные механизмы это позволяли бы

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

(41) потому что практически все отраслевые сделаны на базе типовых
Автосервис - на базе УНФ
Магазины от раруса - на базе Розницы
СРМ от Раруса - интегрируется с УТ
УАТ - легко можно подружить с БП

Т.е. сам бог велел все это перевести на расширения, и предлагать во фреше

(41) Отраслевки - в данном контексте это просто общее название доработок (не более того). То, что важно перечислено в теме.

(4) Там нет указания даты статьи и релиза платформы.

(42) Завидую оптимизму

(41) Кстати тот же молокозавод (могу конечно ошибся) тоже сделал на базе типовой?!

(46) что есть то есть :) я не исправимый оптимист :)

(47) Все отраслевки по Совместно так делают. И это очень правильно

(45) Думаешь скорость в платформе 8.3.11.248 будет в корне отличаться от скорости в платформе 8.3.11.250?
Расширени появилось относительно недавно, и 1с еще не до оптимизации скорости, чтобы говорить о влияние платформы на скорость

(47) есть на базе ERP
https://solutions.1c.ru/catalog/molzavoderp

есть на базе БП
https://solutions.1c.ru/catalog/buh-molzavod

(50) Между указными тобой релизами вряд ли, а вот если их сравнить с 8.3.12.1595 то думаю возможно.

(49) >> И это очень правильно
Скажем так - это просто твое субъективное мнение. Мое мнение немного отличается (как по мне так все это просто проситься в расширения)

(53) Если расширения позволят реализовать весь необходимый функционал без ущерба производительности- я за

(49) В смысле все? WMS от Акселота, СРМ, и прочее

(55) Есть исключения, погорячился

(56) Сейчас отраслевых на каждый чих, поэтому я и не работаю с отраслевками ;-)

(0) >>как Вы думаете?

Все отключается ФО, и если у тебя нет алкоголя, то оно там внутри и не задействовано. Аналогично по всем N-аисам.

Можно ли все это перетащить в расширение? Зачем - со всех сторон, это не стоящие сбоку по функционалу подсистемы, а часто тесно сопряженные между собой. Поддерживать конфу или конфу + расширения - как думаешь, что проще? Потом, для того, чтобы предположим было одно универсальное расширение для егаис, нужно чтобы все взаимодействие было буквально одинаковое по всем прорадительницам, а это значит что логичнее ее поставлять в рамках БСП, и на месте сопрягать. Вот это, скорее всего, давно бы сделали, - тут скорее вопрос целесообразности. Зачем пилить сук, на котором сидишь? Придет автор самой котиковой конфы в мире Магазька, объединится с ней, и чего? Зачем это делать, в чем для вендора профит?

А тему с кастомизацией продажи для фреша - дык кто мешает, прямо сейчас запилить механизм во фреше, каких-нибудь ФО, включаемых по доп.лицензии самой платформы?

(0) Вот согласен полностью. Только хотел добавить что в ERP столько говнофункционала ,который никому не нужен в том виде в котором он сейчас есть. В этом плане ERP вообще дно

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

(58) Казалось бы при чем тут ФО?!  

>>Все отключается ФО, и если у тебя нет алкоголя, то оно там внутри и не задействовано.

Что то сразу напомнило "Видишь суслика ?! и я не вижу а он там есть" ...

(61) это с точки зрения пользователя. Не видно - значит этого нет.
А то что конфа под гиг весит, ну так кого это волнует. Диски сейчас большие

(58) ты давно заглядывал в конфигуратор? сколько там общих модулей, по твоему удобно чего-то пилить при таком количестве обьектов?

зы
про фильтр по подсистемам я в курсе...

(63) я там сижу на постоянной основе, и именно в бухне. Я не вижу ни одной причины для меня, как для программиста, чтобы эта тема с N-сами как-то напрягало. Для пользователя же всего этого вообще не существует, т.к. для него этого функционала нет. И в чем трабла у тебя - не понятно. Если тебе что-то не нужно, ты просто не трогаешь это и все.

(64) Ты видимо не в теме, это тот еще "экзотоман": чего можно безбоязненно выкинуть из Бух 3.0

Тоже про эту ссылку вспомнил.
ТС везёт, такой ерундой можно на работе заниматься.

(64) просто интересно ты фри,фра или фикси?

(67) Ты про ФО троллишь сейчас или нет?

(68) ФО только усложняет разработку.
Ибо чтобы понять почему не водно поля. нужно знать а в каком же ФО ее могли отключить.
и это не отлаживается

(58) вот только один нюанс.
Если пользователь не видит/ ему это не доступно, это не значит что оно не должно заполнятся при создании документа.
И вот это напрягает. У меня нет алкоголя, но при программном создании документа я должен заполнить 100500 реквизитов. а завтра появиться еще 200 реквизитов, и опять переписывать обработку для заполнения этих реквизитов, которые никто не будет использовать

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

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

(71) У меня складывается впечатление, что ты отвечаешь на какой-то другой вопрос. Поправь меня, но я про себя у тебя не спрашивал?

(72) так ты не ответил ни на один вопрос (ни про причём тут ФО, при про фра,фри,фикси, ни о том,что ты пишешь). Отсюда я делаю вывод, что для тебя ФО вполне достаточно ибо для дописок они вполне подойдут.
А говорит о расширениях (как и о вкусе устриц) лучше с теми кто ими пользовался а главное понимает для чего их необходимо использовать

Не понимаю, в чем проблема знать возможности того блока, с которым ты работаешь?

(62) // А то что конфа под гиг весит, ну так кого это волнует

НО ведь оно не только на дисках, но и в память оперативную садится при запуске сеанса базы. Хорошо, что на текущих БСП это хоть загружается только один раз на выбранный РП, а так-то и много раз загружается, если РП создаются много раз

(73) >>для тебя ФО вполне достаточно ибо для дописок они вполне подойдут.

Получается, судя твоей логике разработчика уровня КА, ФО - это не более костылечный дописон, и все можно сделать без низ? Ты проверь вкус тех устриц, которые ты кушаешь - кажется их пора сливать уже.

(76) без ФО в принице можно все сделать.
Поле.Видимость = Ложь

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

Вот млин...долбанная мобильная связь вместе с телефоном...

(77) Насколько я помню в этом случае дикое падение производительности и 1с не рекомендует играться видимостью, типа правильнее играться с Доступностью

(76) как же раньше то жили без ФО?

(78) Главное чтобы отключение не привело к удалению всех введенных данных :)

(80) вроде как еще в 8.3.7 все исправили

(82) В расширении есть замечательное свойство "активно" - убрал галочку и выключил функционал (данные слава всевышнему при этом не удаляются ;) )

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

да, собрать бы этот зоопарк конфигураций в некую структуру модульную - цены бы 1с не было.

Удалите(87)

Расширения - это кривая попытка сделать что-то типа инкапсуляции и наследования в 1с. Хоть что-то пусть будет. И да, с выделением отраслевой специфики в расширение согласен.

Расширения без возможности добавления реквизитов и новых объектов - такие расширения....ниочем...Когда обещают то перевести типовые в режим совместимости - не использовать?

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

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

(90) Режима совместимости, который ты назвал, не бывает. Режим совместимости _всегда_ содержит конкретную версию или релиз платформы.

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

(94) Разработчик (1с) часто любит переименовывать общие модули и перетасовывать процедуры между ними. Очень опасно завязываться на них. Иногда лучше изобрести свой велосипед, чем обращаться к бесполезной БСП.

(94) А ну как, расскажи мне, как изменить алгоритм типовой процедуры/функции с помощью расширения? Да так, что бы потом модули при обновлении не сравнивать?

(90) В БП 3.0 с сентября

(94) а как тогда править ошибки в типовой? Снимать с поддержки?

(96) Вроде выше написал

(99) а по подробней можно?

Конкретизируй

(101) как правильно изменять процедуры в типовых модулях?

Что значит "правильно"?

(103)  как править ошибки в типовой? Снимать с поддержки?

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

(104) Хз, почему ты меня спрашиваешь об этом

(106) А кто (94) писал?
"По поводу плача о сравнении модулей - чтобы ничего не пришлось сравнивать, не нужно заниматься дублированием кода"

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

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

(108) а кого спрашивать?

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

Cyberhawk - "По поводу плача о сравнении модулей - чтобы ничего не пришлось сравнивать, не нужно заниматься дублированием кода"

Вот в контексте этой беседы я 3-ий раз спрашиваю "как тогда править ошибки в типовой?"

Если для того, чтобы "править ошибки в типовой" надо менять код конфигурации, то известно как: или снимаешь с замка, или делаешь через расширение. Херню какую-то спрашиваешь.

(110) Слив засчитан.

Ну ты можешь идти и дальше "многократно увеличивать трудоемкость поддержки", лол )

(112) А что ты имел ввиду в (94)

просто интересно. может существуют какие-то новые методики, недоступные тупым 1сникам?

(113) Ровно то, что там написано. Потом Алексей начал дое*ываться с какими-то ошибками, но это еще ничего по сравнению с (96)...

(115) повторюсь: а поподробней можно?

Что подробней-то? Написание дублирующегося кода повышает вероятность хапнуть горюшка (на этой почве). Ненаписание - исключает такую вероятность.

(117) ну так типовой же код, уже написан. как избежать дублирвоания то?

Дублирование - это как минимум однократное повторение уже написанного кода. Т.е. уже написанный код появляется в конфе как минимум в двух местах.
К чему ты написал, что "типовой код уже написан" - не ясно. Ты на какой-то своей волне?
Избежать дублирования просто - не дублировать.

(119) имхо, он просто хочет вынудить тебя самого перейти к примерам. Вроде того, что раз при типовых процедурах проведения документа создаются наборы записей регистров, а они неверные, то как правильно сделать свой код или исправить поведение обработки проведения, если применяется Расширение: &Перед &Вместо &После - каким образом? Лично мне напрашивается &Вместо и тогда практически весь код придется скопировать в Расширение и изменить его должным образом.

Считать ли такое использование &Вместо дублированием кода или не считать?

(119) Не понятно как твой совет "не дублировать" можно применить к доработке типовых модулей

(120) Конечно считать
(121) Снятие с замка / "Перед" / "После"

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

Почему "только"? Конечно же можно и в расширении задублировать

(124) ты же сам говоришь, что не нужно дублировать

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

(125) Ты что-то напутал

"без дублирования нужно саму конфу менять" // Ты по-прежнему на какой-то своей волне

(127) перечитай внимательно что ты говорил в (94)

(128) ну покажи тогда пример

"посыл был, что если мы задублируем, то потом сложно будет сопровождать" // И в этом ты тоже заблуждаешься

(129) Ну, там ровно то же, что и в (122). Нет дублирования - нет необходимости сравнивать

(132) Короче ты на какой то своей волне. Никто кроме тебя не понимает что ты говоришь

(130) В (122) "Перед" и "После"

(133) Ну так если непонятно, то задают вопросы. Я вроде на них все ответил. Дальше уже результат только от вопрошающего зависит