Gedemin Roadmap

Настоящий roadmap является предворительным документом и представляет собой набор изменений и дополнений, которые планируется реализовать в версии Гедымин 2.0. Выход второй версии планируется на 4 кв. 2008 г., хотя многие изменения будут появляться раньше в промежуточных версиях Гедымин 1.х. Обратите внимание, что данный список не является окончательным и будет постоянно изменяться и дополняться.

TgdcBase

1. Переработать механизм сохранения в поток.
2. Пересмотреть внутренние механизмы (например, кэш РУИДов) и заменить сортированные списки строк на хэш таблицы.
3. Сделать из проводки нормальный бизнес-объект.
4. Использовать визуальные настройки связанных гридов для выбора присоединямых таблиц по полям аттрибутам типа ссылка.

Интерфейсные компоненты

1. Добавить MDI интерфейс с докируемыми окнами.
2. Дискуссия по новому интерфейсу

Грид

1. Объединить TgsDBGrid и TgsIBGrid в один компонент. Соответственно, объединить компоненты TgsColumn и TgsIBColumn.
2. Убрать дублирование компонентов, используемых для редактирования данных в гриде.
3. Реализовать каскадные стили (на подобии CSS) для представления визуальных настроек, вместо того, чтобы хранить настройки каждого грида индивидуально.
4. Объединить визуальные настройки колонок и настройки компонентов для редактирования непосредственно в гриде.
5. Показывать прикрепленные объекты во всплывающем окошке, как показываются примечания в Экселе.
6. Реализовать редактирование в гриде при настроенном расширенном отображении.
7. Адаптировать грид для отображения данных в режиме группировки.
8. Реализовать темы оформления
9. Централизованно хранить настройки гридов, привязанно к теме оформления. Для конкретного грида хранить только отличия в визуальных настройках от настроек темы
10. Размеры колонок выставлять по размеру данных
11. Реализовать редактирование полей в случае использования расширенного отображения

Форма просмотра

1. Объединить Панель поиска и Фильтры в один механизм. Привязать к фильтру визуальные настройки таблицы.
2. Реализовать хранение и выбор нескольких визуальных настроек для каждого грида.

Прочие компоненты

1. Разработать визуальный компонент выбора диапазона дат.

База данных

Компоненты доступа IBX

1. На уровне TIBCustomDataSet реализовать группировку записей и подсчет агрегатных значений.
2. Обрабатывать отключение от базы данных (обрыв связи, переподключение) без закрытия датасетов.
   1. Реализовать скрытое переподключение при создании метаданных. (Проверить, возможно с переходом на ФБ 2.5 переподключение вообще не потребуется).
3. Изменить формат предствления записей в оперативной памяти с целью экономии места.

Firebird 2.5

1. Перевести БД на использование сервера Firebird 2.5.
   1. Перевести эталон.
   2. Перевести стандартные настройки.
   3. Встроить в инстолятор апгрейд базы данных.
2. Переделать основные бухгалтерские складские отчеты с использования одного громоздкого запроса на алгоритмическое построение на стороне сервера (используя возможности ФБ 2.5).
3. Адаптировать использование алиасов, вместо непосредственных путей к базам данных.
4. Складскую и бухгалтерскую логику реализовать на стороне сервера с помощью динамического формирования кода в тригерах
5. Скорректировать код обработки интервальных деревьев для того, чтобы исключить непроизвольное изменение полей LB, RB

Закрытие и блокировка периода

1. Реализовать закрытие периода с возможностью выноса архивных данных в отдельную базу.
2. Усовершенствовать механизм блокировки периода.

Склад

1. Бизнес объект работы с движением необходимо убрать и формировать движение либо через прямое добавление в таблицы, либо, еще лучше, напрямую через триггеры соответствующих таблиц (если придумать, что делать с признаками). Надо изучить оператор EXECUTE STATEMENT из Firebird 2.0. Возможно, он поможет решить проблему с признаками. Т.е. в самом триггере можно будет формировать код на основе текущей конфигурации БД и выполнять его.
2. Таблица INV_CARD – разделить на две таблицы (признаки изменяемые и признаки фиксированные). Дать возможность удаления ненужных признаков (т.е. программа должна нормально понимать их отсутствие и должна быть возможность легко их добавить обратно, не вспоминая, как они назывались, и какого они были типа).
3. Обязательно предусмотреть мягкое закрытие периода (т.е. архивирование данных с выводом сальдо).
4. Для INV_BALANCE предусмотреть изменение данных журнального типа, для того, чтобы исключить блокировки при одновременной работе нескольких пользователей с одним и тем же товаром. Механизм должен работать подобно тому, как работает версионность записей в Интербейзе. Более подробно описано в задании №133.
5. Продумать возможность ведения суммового и количественного учета.

Бухгалтерия

1. Отказаться от таблицы AC_RECORD (из нее нам нужно только DOCUMENTKEY, RECORDKEY, COMPANYKEY), поле описание, может быть, хранить в отдельной таблице(оно заполняется достаточно редко).
2. Аналитические признаки разделить на две группы: часто используемые и редко. Первые добавлять непосредственно в таблицу с проводками, а для вторых создавать отдельные таблицы для каждого признака.
3. Сделать журналы документов для этого стандартизировать наименования полей применяемых в документах, например во всех документах, есть ссылка на GD_CONTACT или даже две, сделать их стандартными полями.
4. Насколько оптимальна структура таблицы GD_DOCUMENT: id-parent? Ведь у нас для документа допускаются не более двух уровней вложенности: шапка-позиция? Может разделить на две таблицы: одну для шапок документов, другую для позиций?

Прочее

1. Взять хотя бы десяток характерных баз и проанализировать использование полей в них.
   1. Поле RESERVED убрать.
   2. Поле DESCRIPTION почти нигде не используется.
2. В таблице GD_DOCUMENT поля с суммами и ссылка на валюту не используются. Убрать их из базы. Или заставить всех их использовать.
3. Интервальные деревья. Поскольку в Firebird 2.0 будет возможность объявлять глобальные переменные, то можно будет реализовать блокировку изменения полей LB, RB, так, чтобы менять их можно было только из триггера, но не вручную.
4. Если накопление версий записей представляет такую угрозу производительности, то проанализировать использование и структуру таблиц и те из них, которые часто изменяются, но при этом, в которых меняется всего несколько полей, разбить на две таблицы: одна будет содержать постоянно изменяемые поля, а вторая — редко изменяемые.

Бухгалтерия

1. Бухгалтерские отчеты должны иметь возможность работать с несколькими планами счетов.
2. Журнал хозяйственных операций должен выводится в разрезе необходимого плана счетов (по умолчанию – активного).
3. По любому списку документов необходимо выводить грид со списком проводок (как сейчас реализовано в настройках склада) – это должно быть по умолчанию.

Отчеты

1. Добавить ФастРепорт 4 и, по возможности, ФастКуб.
2. Убрать промежуточное перекачивание данных в TClientDataSet перед передачей их в ФастРепорт. Напрямую связывать данные запроса (TIBQuery, TIBDataSet) с отчетом.
3. Сделать динамическое формирование отчетов для печати данных из грида.
4. Сделать отчеты динамическими. Автоматически, там где это возможно, устанавливать связи между клетками отчета и бизнес-объектами. Там, где автоматическое связывание невозможно, предусмотреть возможность простого программного связывания. Существующий механизм через написание отдельной скрипт функции не удобен.
   1. Система построения отчетов, с показателями должна быть в самой платформе и сам процесс создания отчетов, необходимо как-то сделать прозрачней. Сейчас для этого (не учитывая показателей) необходимо:
      1. Написать функцию, которая рассчитывает налог (это делается в конструкторе)
      2. Написать функцию, которая рассчитанный налог подготавливает к печати
      3. Нарисовать печатную форму.
      4. При этом печатную форму можно проверить только из режима расчета налога, а в режиме его настройки это сделать нельзя.
5. Пересмотреть интерфейсы BaseQueryList. Объединить добавление нового запроса, присваивание его текста и открытие в один метод.
6. Автоматически формировать шаблон отчета на основании данных, поставляемых главной функцией.
7. Создать дизайнер типовых отчетов

Среда разработки

1. Реализовать хранение версий скрипт функции, а также возможность визуального сравнения двух версий одной скрипт функции.
2. Скрипт функции методов одного класса хранить ввиде одного текста.
3. Обновить SynEdit. Реализовать сворачивание кода.
4. Реализовать возможность сравнения конфигураций двух баз данных. Перенос изменений между базами данных.
5. Реализовать механизм контроля версий настроек.
6. Необходимо все свести вместе. Т.е. создание документа, справочника, написание методов, редактирование формы, написание отчетов (печатных форм) с точки зрения разработчика должно быть единым процессом.
7. Очень бы хотелось иметь полноценную подсказку по методам объектов (через CTRL_SPACE) сейчас это возможно только для глобальных объектов.
8. При разработке, указывать какую подсистему мы разрабатываем и автоматом присваивать нужный префикс всем объектам БД.
9. При создании таблицы справочника сразу добавлять поля Наименование и Код.
10. Отказаться от создания оболочек на каждый класс Делфи. Создать класс прокси, который будет привязываться к объекту и поддерживать для него интерфейс IDispatch.
11. Отказаться от путаницы макрос/скрипт функция. Упразднить макросы и ввести для скрипт-функции свойство "Отображается в меню"
12. Отказаться от нашего отладчика. Использовать встроенный в Windows Script Host
13. Переделать обработку исключений. Сделать ее похожей на VB On Error GoTo Label
14. Перейти на редактор кода, который поддерживает сворачивание/разворачивание текста
15. Переделать связку Делфи код/Код скрипта. Использовать хэширование вместо поиска по сортированным спискам

Безопасность

1. Убрать непосредственное хранение паролей пользователя в таблице GD_USER. Хранить хэш MD5.
2. Список баз данных должен храниться где-то централизованно, а не на каждом локальном компьютере.
3. Архивным копированием надо управлять централизованно, а не так, что параметры автоматического архивирования хранятся в самой базе данных.
4. Информация зависящая от пользователя должна в реестре храниться в CURRENT_USER а не в LOCAL_MACHINE

Хранилище

1. Внутренне перейти на использование хэшированных списков при обращении к значениям и папкам.
2. Реализовать посегментное хранение данных в базе вместо записи одного большого блоба.
3. Реализовать архивирование старой версии Хранилища.

Парсер SQL, фильтрация

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

Установка

1. Перейти на использование Inno Setup вместо Install Shield. Собрать единую инстоляцию вместо разрозненных локальных установок.