Блочная конфигурация (нужна или нет)

1. vde69 925 02.01.09 18:52 Сейчас в теме
Собствено чего есть практически во всех учетных системах и нету в 1с: Это возможность докупать готовые блоки и интегрировать их в систему "автоматом" и после обновлять то-же поблочно.

Собствено начиная с 8.1.09 это стало почти возможно, есть идея реализовать следующее:

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

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

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


Собствено это немного похоже на ... ну Вы сами поняли :)

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

Например предлогаю подсистемы
1. Розничная торговля
2. Оптовая торговля
3. Коммиссионная торговля
4. Учет НДС
5. Выгрузка в бух
6. Планирование закупок
ну и тд...

Пока я не знаю чего с идеей делать, один я это не потяну точно, по этому жду советов


По теме из базы знаний
Ответы
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
2. larisab 160 02.01.09 20:45 Сейчас в теме
все связи будут сами выстраиваться
.

а каким образом, идеи есть?
3. Fuego 462 02.01.09 23:05 Сейчас в теме
Да что там "выстраиваться". Как они разрываться будут при смене блока на блок конкурента?..
4. Fuego 462 02.01.09 23:09 Сейчас в теме
vde69 пишет:
но пока полностьтю сделать ООП можно только справочники, документы, обработки и отчеты, может еще план счетов, но регистры не поддаються расширению, по этому они должны быть полностью описаны в базовых конфигурациях.

Не "ООП", а "ОПП" - объектно-предметное программирование. И наборы записей регистров тоже можно наворачивать. Но в общем, идея интересная, но невозможная в хорошем осуществлении.
5. CheBurator 3119 02.01.09 23:11 Сейчас в теме
бяка выйдет... ООП - это конечно хорошо, но имхо вопросы с быстродействием сразу станут гораздо острее...
подсисемы дробим на под-подсистемы.
ОптоваяТорговля:
- количественный учет на складах;
- партионный учет на складах;
- учет взаиморасчетов с клиентами в денежном выражении
и т.д.
...
- если мы не ведем учет взаиморасчетов с клиентами - то ок, "списываем" по колдичественному учету;
- если ведем учет по взаиморасчетам - делаем добавочное "спимсание" по деньгам - понятно, что в случае независимости подподсистем в худшем случае время "списания" будет увеличено вдвое... в то время как в линейном алгоритме - списание денего идет по коду вместе со списанием количества.. потому как на 80% код один и тот же...
6. Fuego 462 02.01.09 23:21 Сейчас в теме
8. alexk-is 6533 03.01.09 00:27 Сейчас в теме
(5) Все правильно. Но, если внимательно посмотреть код, то для формирования большинства регистров используется одна и та же таблица значений. Вначале она максимально наполняется с учетом всех методик, а потом "сливается" в регистры. Разработчики 1С давно используют эту схему. Это позволяет менять учетную политику. Задействовать те или иные методики учета, включать или выключать некоторый функционал.
Если общая схема подключения дополнительных модулей будет аналогичной, то возможно что-то выгорит.
Но по моему, чем универсальней инструмент, тем он более громоздкий и неудобный в использовании. Я давно занимаюсь оптимизацией и знаю только 2 способа добиться ускорения: 1) Заменить оборудование на более мощное; 2) Делать меньше лишних движений.
Если говорить о сборке модулей от разных поставщиков, то модулям такой программы, чтобы работать так же быстро как существующие программы, необходимо безоглядно доверять друг другу. Иначе придется или всю обработку данных брать на себя или перепроверять за другими.
Универсальные процедуры проверяют параметры на входе и выполняют соответствующие действия. Это приводит к повышению универсальности и снижению быстродействия. Кроме этого код таких "универсальных процедур" гораздо сложнее в разработке.
Если удастся разработать жесткие спецификации, то ...
10. CheBurator 3119 03.01.09 00:42 Сейчас в теме
(8) > Но по моему, чем универсальней инструмент, тем он более громоздкий и неудобный в использовании.
- совершенно неверное имхо утверждение.
использование универсального инструментария предполагает отличное знание особенностей взаимодействия инструмента и предметной области, т.е. использование универсального инструментария предполагается людьми соответствующей квалификации - а для такого человека "громоздкость" и н"неудобность" - вполне логична, применима и объяснима...
..
именно поэтому на портале такое количество "перенумераторов" и иже с ними - потому что для неквалифицированного пользователя на интерфейе программы не должно быть много "элементов", - 2-3 поля, 2 кнопки...
.. а я и штатными "универсальными" обработками весь этот функционал перекрою в подавляющем большинстве случаев, а там где не будет хватать возможностей универсального решения - допишу просто еще один плугин....
11. alexk-is 6533 03.01.09 01:05 Сейчас в теме
(10) Разве я говорю, что универсальный инструмент это плохо? Нет, мне всегда нравились разводные ключи, сменные сверла к дрели и т.п. Но универсальность снижает скорость на начальном этапе. Ключ надо подкрутить, сверлышко установить или поменять...
7. larisab 160 02.01.09 23:49 Сейчас в теме
Собствено это немного похоже на ... ну Вы сами поняли :)

не знаю насколько все поняли, я знаю в галактике подобная система, в соломоне... Но в галактике выгрузки между филиалами весят более 2-3 Гб
9. alexk-is 6533 03.01.09 00:29 Сейчас в теме
(7) Объем выгрузок зависит от формата данных, частоты обмена данными, количества филиалов, активности сотрудников филиалов и т.д. К модульной системе построения программы это не имеет прямого отношения.
12. vde69 925 03.01.09 02:19 Сейчас в теме
Лариса пишет:
а каким образом, идеи есть?
- да, все вроде складываеться нормально

Fuego пишет:
Как они разрываться будут при смене блока на блок конкурента?..
- ничего не будет разрываться, у тебя-же ничего не рушиться если ты используешь компоненту потомок

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

alexk-is пишет:
Все правильно. Но, если внимательно посмотреть код, то для формирования большинства регистров используется одна и та же таблица значений. Вначале она максимально наполняется с учетом всех методик, а потом "сливается" в регистры. Разработчики 1С давно используют эту схему. Это позволяет менять учетную политику. Задействовать те или иные методики учета, включать или выключать некоторый функционал.
Если общая схема подключения дополнительных модулей будет аналогичной, то возможно что-то выгорит.
- угу, а по поводу спецификаций, так на то и будут Базовые конфигурации для подсистем, в них будет прописан механизм взаимодействия (интерфейсы, на подобие обьектов TCustomMuObject) и поля данных

13. CheBurator 3119 03.01.09 04:05 Сейчас в теме
ндя... и основное время будет уходить на связку блоков, а не на решение прикладных задач... а вся проблема как раз-то в разработке прикладных блоков....
14. dotBY 03.01.09 12:46 Сейчас в теме
а как решать вопрос с реквизитами будете? измерения там, ресурсы регистров всякие...
1. сразу, но не заполнять... (дико растет размер, переходим к п.3)
2. сразу, заполнять... (наиболее оптимально, но тогда модульность реализуется только наличием отчетов и доп.фенечек)
3. потом, но половины данных не будет:
3.1. перепровести всю базу (главбух повесится, косяки полезут и проч.)
3.2. пусть сами мучаются... (хехе, "с нового года" все данные уже смогут нормально получать)

Вопрос на самом деле актуален, так что я весь в нетерпении!
15. vde69 925 03.01.09 16:04 Сейчас в теме
Сергей aka dotBY пишет:
а как решать вопрос с реквизитами будете? измерения там, ресурсы регистров всякие...
Вопрос на самом деле актуален, так что я весь в нетерпении!


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

Собствено интеграция новой подсистемы должна внутри себя иметь регламентные процедуры для обновления, которые и будут реаилизовывать нужную стратегию (например движения по старым документам формировать или нет)
16. Душелов 4014 04.01.09 00:02 Сейчас в теме
Я смотрю, многие франчи буду аналогичные системы выпуспать?.. (Утрирую, конечно) Это - фантастика...
17. vde69 925 04.01.09 02:52 Сейчас в теме
Душелов пишет:
Я смотрю, многие франчи буду аналогичные системы выпуспать?.. (Утрирую, конечно) Это - фантастика...


я думаю, что это будет принято хорошо для мелких и средних франей, то-есть они будут выпускать свой платный модуль, который будет стыковаться например с бухгалтерией и кадрами, тоесть они продадут 3 коробки вместо 1, а поддерживать им надо будет только свой небольшей блок.

А вот для фришников реализация не принесет ничего хорошего :)
18. larisab 160 04.01.09 23:04 Сейчас в теме
А вот для фришников реализация не принесет ничего хорошего :)

это вряд ли, я думаю народ побоится покупать, уже было много случаев, когда компания выпускала тиражный продукт, подсаживала на него кучу контор с помощью рекламы, да почти на голом рынке, а потом через несколько лет, бросала поддерживать (это ж надо релизы выпускать, законодательство меняется), т.к. основное бабло срубило. И народ возращался на руганный-переруганный стандарт. А для фри куча работы по переносам и возврату в лоно.
Оставьте свое сообщение
Вакансии
1С аналитик
Москва
зарплата от 210 000 руб.
Полный день

Руководитель направления 1С
Москва
зарплата от 350 000 руб.
Полный день

1С Программист
Москва
зарплата от 180 000 руб.
Полный день

Программист 1С
Москва
зарплата от 180 000 руб. до 220 000 руб.
Полный день

Аналитик 1С / Бизнес-аналитик
Нижний Новгород
зарплата от 100 000 руб. до 250 000 руб.
Временный (на проект)