Показать сообщение отдельно
Старый 18.09.2003, 16:29   #15  
Михал Семенов is offline
Михал Семенов
Участник
 
15 / 10 (1) +
Регистрация: 16.09.2003
Здравствуйте все,

Спасибо еще раз всем откликнувшимся!!!! Ваши замечания - очень ценнЫ для меня.

Мне кажется, надо объяснить, какого рода "исправления" вносились в систему.
Я их делю на четыре класса.

1. Изменения в бизнес-логике. Таковых на самом деле очень-очень мало, буквально единичные. В основном мы пользуемся стандартной бизнес-логикой международной Аксапты 2.5 со вторым сервис-паком (компания наша - представительство буржуев в России).

2. Изменения в стандартном порядке сортировки-группировки запросов к БД в формах и отчетах. Например, при резервировании товаров нам нужно было сортировать по сроку годности партии, а не по дате поступления на склад. Никакими другими способами, кроме внесения изменений в класс, к сожалению, это не лечилось. Таковых примерно процентов 30 от общего объема изменений.
3. Добавления новых колонок в отчеты и экранные формы, изменения дизайна отчетов. Самое большое количество, больше половины точно. Это, как мне кажется, самое слабое место в Аксапте. Очевидно, что разным предприятиям нужна разная информация на экране. Часто из связанных таблиц, иногда вычисляемая по сложным алгоритмам. Например, нашему финотделу нужно видеть в списке транзакций по клиентам - количество дней с момента выставления инвойса до момента его оплаты. А отделу закупок - т.н. "остаток на складе в днях", т.е. на сколько дней хватит того, что сейчас есть на складе, при среднем потреблении, вычисленном на основе истории за предыдущие n месяцев. И это лишь самые простые из доработок. Мне до сих пор не понятно, почему такая развитая в общем система не имеет механизмов добавления таких полей - без изменения кода. Я уж не говорю про случаи, когда скажем в журнале складских перемещений надо выводить название каждой номенклатуры, а соответствующей таблице такого поля нету. Тут уж вообще дурдом - приходится вешать метод на таблицу, и выдавать его значение в грид, иначе просто никак... А если нужно еще и сортировку организовать по этому новому полю - это вообще труба, либо соответствующий метод перекрывай через ж., либо добавляй целое поле и инициализируй его... Ну скажите, неужели разработчикам было неведомо, что операторы просто не могут работать только с кодами материалов???? Должны были придумать что-нибудь, чтобы можно было выводить U]любое[/U] поле из связанной таблицы простой настройкой формы непосредственно в Аксапте. Такие фичи есть во многих системах...

4. Совершенно новые разработки, не меняющие стандартный код - все остальное, процентов 15 от общего объема кода.

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

Вообще, мне кажется, проблема не в том что "пользователи слишком много изменяют" - а в том, что разработчик не озаботился созданием средств переноса этих доработок.