Блочная конфигурация (нужна или нет)
Собствено чего есть практически во всех учетных системах и нету в 1с: Это возможность докупать готовые блоки и интегрировать их в систему "автоматом" и после обновлять то-же поблочно.
Собствено начиная с 8.1.09 это стало почти возможно, есть идея реализовать следующее:
1. Нулевая конфигурация (в ней не будут только обьекты необходимын для нормального обновления),
2. Базовые конфигурации для подсистем (в них будут описаны метаданные, но не будет логики работы)
3. На основе базовых будут разработаны подсистемы конечного использования
Заказчик устанавливает себе Нулевую конфигурацию и потом простым обьединением с нужными конечными конфами делает себе систему, (при этом ничего дорабатывать не надо), все связи будут сами выстраиваться.
Дальше ему будут доступны обновления конечных конфигураций которые он устанавливает простым обьединением. Вероятно можно будет заменить установленый блок, на блок конкурентов (если они за основу возьмут не базовую а конечную конфу)
Собствено это немного похоже на ... ну Вы сами поняли :)
но пока полностьтю сделать ООП можно только справочники, документы, обработки и отчеты, может еще план счетов, но регистры не поддаються расширению, по этому они должны быть полностью описаны в базовых конфигурациях.
Например предлогаю подсистемы
1. Розничная торговля
2. Оптовая торговля
3. Коммиссионная торговля
4. Учет НДС
5. Выгрузка в бух
6. Планирование закупок
ну и тд...
Пока я не знаю чего с идеей делать, один я это не потяну точно, по этому жду советов
Собствено начиная с 8.1.09 это стало почти возможно, есть идея реализовать следующее:
1. Нулевая конфигурация (в ней не будут только обьекты необходимын для нормального обновления),
2. Базовые конфигурации для подсистем (в них будут описаны метаданные, но не будет логики работы)
3. На основе базовых будут разработаны подсистемы конечного использования
Заказчик устанавливает себе Нулевую конфигурацию и потом простым обьединением с нужными конечными конфами делает себе систему, (при этом ничего дорабатывать не надо), все связи будут сами выстраиваться.
Дальше ему будут доступны обновления конечных конфигураций которые он устанавливает простым обьединением. Вероятно можно будет заменить установленый блок, на блок конкурентов (если они за основу возьмут не базовую а конечную конфу)
Собствено это немного похоже на ... ну Вы сами поняли :)
но пока полностьтю сделать ООП можно только справочники, документы, обработки и отчеты, может еще план счетов, но регистры не поддаються расширению, по этому они должны быть полностью описаны в базовых конфигурациях.
Например предлогаю подсистемы
1. Розничная торговля
2. Оптовая торговля
3. Коммиссионная торговля
4. Учет НДС
5. Выгрузка в бух
6. Планирование закупок
ну и тд...
Пока я не знаю чего с идеей делать, один я это не потяну точно, по этому жду советов
По теме из базы знаний
Ответы
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
vde69 пишет:
но пока полностьтю сделать ООП можно только справочники, документы, обработки и отчеты, может еще план счетов, но регистры не поддаються расширению, по этому они должны быть полностью описаны в базовых конфигурациях.
но пока полностьтю сделать ООП можно только справочники, документы, обработки и отчеты, может еще план счетов, но регистры не поддаються расширению, по этому они должны быть полностью описаны в базовых конфигурациях.
Не "ООП", а "ОПП" - объектно-предметное программирование. И наборы записей регистров тоже можно наворачивать. Но в общем, идея интересная, но невозможная в хорошем осуществлении.
бяка выйдет... ООП - это конечно хорошо, но имхо вопросы с быстродействием сразу станут гораздо острее...
подсисемы дробим на под-подсистемы.
ОптоваяТорговля:
- количественный учет на складах;
- партионный учет на складах;
- учет взаиморасчетов с клиентами в денежном выражении
и т.д.
...
- если мы не ведем учет взаиморасчетов с клиентами - то ок, "списываем" по колдичественному учету;
- если ведем учет по взаиморасчетам - делаем добавочное "спимсание" по деньгам - понятно, что в случае независимости подподсистем в худшем случае время "списания" будет увеличено вдвое... в то время как в линейном алгоритме - списание денего идет по коду вместе со списанием количества.. потому как на 80% код один и тот же...
подсисемы дробим на под-подсистемы.
ОптоваяТорговля:
- количественный учет на складах;
- партионный учет на складах;
- учет взаиморасчетов с клиентами в денежном выражении
и т.д.
...
- если мы не ведем учет взаиморасчетов с клиентами - то ок, "списываем" по колдичественному учету;
- если ведем учет по взаиморасчетам - делаем добавочное "спимсание" по деньгам - понятно, что в случае независимости подподсистем в худшем случае время "списания" будет увеличено вдвое... в то время как в линейном алгоритме - списание денего идет по коду вместе со списанием количества.. потому как на 80% код один и тот же...
(5) Все правильно. Но, если внимательно посмотреть код, то для формирования большинства регистров используется одна и та же таблица значений. Вначале она максимально наполняется с учетом всех методик, а потом "сливается" в регистры. Разработчики 1С давно используют эту схему. Это позволяет менять учетную политику. Задействовать те или иные методики учета, включать или выключать некоторый функционал.
Если общая схема подключения дополнительных модулей будет аналогичной, то возможно что-то выгорит.
Но по моему, чем универсальней инструмент, тем он более громоздкий и неудобный в использовании. Я давно занимаюсь оптимизацией и знаю только 2 способа добиться ускорения: 1) Заменить оборудование на более мощное; 2) Делать меньше лишних движений.
Если говорить о сборке модулей от разных поставщиков, то модулям такой программы, чтобы работать так же быстро как существующие программы, необходимо безоглядно доверять друг другу. Иначе придется или всю обработку данных брать на себя или перепроверять за другими.
Универсальные процедуры проверяют параметры на входе и выполняют соответствующие действия. Это приводит к повышению универсальности и снижению быстродействия. Кроме этого код таких "универсальных процедур" гораздо сложнее в разработке.
Если удастся разработать жесткие спецификации, то ...
Если общая схема подключения дополнительных модулей будет аналогичной, то возможно что-то выгорит.
Но по моему, чем универсальней инструмент, тем он более громоздкий и неудобный в использовании. Я давно занимаюсь оптимизацией и знаю только 2 способа добиться ускорения: 1) Заменить оборудование на более мощное; 2) Делать меньше лишних движений.
Если говорить о сборке модулей от разных поставщиков, то модулям такой программы, чтобы работать так же быстро как существующие программы, необходимо безоглядно доверять друг другу. Иначе придется или всю обработку данных брать на себя или перепроверять за другими.
Универсальные процедуры проверяют параметры на входе и выполняют соответствующие действия. Это приводит к повышению универсальности и снижению быстродействия. Кроме этого код таких "универсальных процедур" гораздо сложнее в разработке.
Если удастся разработать жесткие спецификации, то ...
(8) > Но по моему, чем универсальней инструмент, тем он более громоздкий и неудобный в использовании.
- совершенно неверное имхо утверждение.
использование универсального инструментария предполагает отличное знание особенностей взаимодействия инструмента и предметной области, т.е. использование универсального инструментария предполагается людьми соответствующей квалификации - а для такого человека "громоздкость" и н"неудобность" - вполне логична, применима и объяснима...
..
именно поэтому на портале такое количество "перенумераторов" и иже с ними - потому что для неквалифицированного пользователя на интерфейе программы не должно быть много "элементов", - 2-3 поля, 2 кнопки...
.. а я и штатными "универсальными" обработками весь этот функционал перекрою в подавляющем большинстве случаев, а там где не будет хватать возможностей универсального решения - допишу просто еще один плугин....
- совершенно неверное имхо утверждение.
использование универсального инструментария предполагает отличное знание особенностей взаимодействия инструмента и предметной области, т.е. использование универсального инструментария предполагается людьми соответствующей квалификации - а для такого человека "громоздкость" и н"неудобность" - вполне логична, применима и объяснима...
..
именно поэтому на портале такое количество "перенумераторов" и иже с ними - потому что для неквалифицированного пользователя на интерфейе программы не должно быть много "элементов", - 2-3 поля, 2 кнопки...
.. а я и штатными "универсальными" обработками весь этот функционал перекрою в подавляющем большинстве случаев, а там где не будет хватать возможностей универсального решения - допишу просто еще один плугин....
Лариса пишет:
а каким образом, идеи есть?
- да, все вроде складываеться нормально
а каким образом, идеи есть?
Fuego пишет:
Как они разрываться будут при смене блока на блок конкурента?..
- ничего не будет разрываться, у тебя-же ничего не рушиться если ты используешь компоненту потомок
Как они разрываться будут при смене блока на блок конкурента?..
CheBurashka Сергей пишет:
бяка выйдет... ООП - это конечно хорошо, но имхо вопросы с быстродействием сразу станут гораздо острее...
подсисемы дробим на под-подсистемы.
- вообщем то быстродейтвие упадет из-за использования структур для передачи данных между модулями (ну и небольшие накладные расходы будут по вызову пустых процедур и местами использования "выполнить" для передачи кода), в остальном скорость должна остатся прежней (а учитываю оптимизацию, за счет выкидывания лишних наворотов, в отдельных случаях может и вырастет).
бяка выйдет... ООП - это конечно хорошо, но имхо вопросы с быстродействием сразу станут гораздо острее...
подсисемы дробим на под-подсистемы.
alexk-is пишет:
Все правильно. Но, если внимательно посмотреть код, то для формирования большинства регистров используется одна и та же таблица значений. Вначале она максимально наполняется с учетом всех методик, а потом "сливается" в регистры. Разработчики 1С давно используют эту схему. Это позволяет менять учетную политику. Задействовать те или иные методики учета, включать или выключать некоторый функционал.
Если общая схема подключения дополнительных модулей будет аналогичной, то возможно что-то выгорит.
- угу, а по поводу спецификаций, так на то и будут Базовые конфигурации для подсистем, в них будет прописан механизм взаимодействия (интерфейсы, на подобие обьектов TCustomMuObject) и поля данных
Все правильно. Но, если внимательно посмотреть код, то для формирования большинства регистров используется одна и та же таблица значений. Вначале она максимально наполняется с учетом всех методик, а потом "сливается" в регистры. Разработчики 1С давно используют эту схему. Это позволяет менять учетную политику. Задействовать те или иные методики учета, включать или выключать некоторый функционал.
Если общая схема подключения дополнительных модулей будет аналогичной, то возможно что-то выгорит.
а как решать вопрос с реквизитами будете? измерения там, ресурсы регистров всякие...
1. сразу, но не заполнять... (дико растет размер, переходим к п.3)
2. сразу, заполнять... (наиболее оптимально, но тогда модульность реализуется только наличием отчетов и доп.фенечек)
3. потом, но половины данных не будет:
3.1. перепровести всю базу (главбух повесится, косяки полезут и проч.)
3.2. пусть сами мучаются... (хехе, "с нового года" все данные уже смогут нормально получать)
Вопрос на самом деле актуален, так что я весь в нетерпении!
1. сразу, но не заполнять... (дико растет размер, переходим к п.3)
2. сразу, заполнять... (наиболее оптимально, но тогда модульность реализуется только наличием отчетов и доп.фенечек)
3. потом, но половины данных не будет:
3.1. перепровести всю базу (главбух повесится, косяки полезут и проч.)
3.2. пусть сами мучаются... (хехе, "с нового года" все данные уже смогут нормально получать)
Вопрос на самом деле актуален, так что я весь в нетерпении!
Сергей aka dotBY пишет:
а как решать вопрос с реквизитами будете? измерения там, ресурсы регистров всякие...
Вопрос на самом деле актуален, так что я весь в нетерпении!
а как решать вопрос с реквизитами будете? измерения там, ресурсы регистров всякие...
Вопрос на самом деле актуален, так что я весь в нетерпении!
работа с реквизитами должна строиться через процедуры и функции, как положено прятать поля за свойствами в ООП. Это необходимо сделать на уровне "Базовые конфигурации для подсистем" при этом конечная конфигурация будет иметь механизм расширения как полей, так и форм, но в рамках заданого интерфейса.
Для примера справочник "Пользователи" имеет кучу таких полей реализованых через план видов характеристик, но есть и более интересные способы. Единственное чего нельзя так расширить - регистры.
Собствено интеграция новой подсистемы должна внутри себя иметь регламентные процедуры для обновления, которые и будут реаилизовывать нужную стратегию (например движения по старым документам формировать или нет)
Душелов пишет:
Я смотрю, многие франчи буду аналогичные системы выпуспать?.. (Утрирую, конечно) Это - фантастика...
Я смотрю, многие франчи буду аналогичные системы выпуспать?.. (Утрирую, конечно) Это - фантастика...
я думаю, что это будет принято хорошо для мелких и средних франей, то-есть они будут выпускать свой платный модуль, который будет стыковаться например с бухгалтерией и кадрами, тоесть они продадут 3 коробки вместо 1, а поддерживать им надо будет только свой небольшей блок.
А вот для фришников реализация не принесет ничего хорошего :)
А вот для фришников реализация не принесет ничего хорошего :)
это вряд ли, я думаю народ побоится покупать, уже было много случаев, когда компания выпускала тиражный продукт, подсаживала на него кучу контор с помощью рекламы, да почти на голом рынке, а потом через несколько лет, бросала поддерживать (это ж надо релизы выпускать, законодательство меняется), т.к. основное бабло срубило. И народ возращался на руганный-переруганный стандарт. А для фри куча работы по переносам и возврату в лоно.
Вакансии
Аналитик 1С / Бизнес-аналитик
Нижний Новгород
зарплата от 100 000 руб. до 250 000 руб.
Временный (на проект)
Нижний Новгород
зарплата от 100 000 руб. до 250 000 руб.
Временный (на проект)