Разрешите посоветоваться по развитию и изменению технологий системы УС Лэнд : КИС Lack & УС Land

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

Всё началось с анализом не очень важных (ситуации встречались крайне редко и пользователи о них более не "вспоминали") замечаний и пожеланий реальных пользователей. Так же захотелось реализовать некогда подсмотренные идеи из других систем, конечно адаптировав их под интерфейсные и технологические приёмы УС Land.

Увы, дабы не оставить себе "путей отступления" уже систему на 90% безвозвратно перепахал в свете ряда, захватывающих большинство модуле изменений:

1. Увеличение поля номер_документа с 12 до 19 знаков. Замечания были из-за чудотворцев при 1С, забавляющихся префиксами у номеров, а так же чудотворцев при государстве, требующих абсолютно точного соответствия номеров документов поставщиков/покупателей в алкогольных декларация и декларации по НДС.

2. Увеличение поля адреса с 100 до 200 знаков во всех рабочих таблицах, в частности юридического адреса контрагента и его торговых точек (удаленных подразделений), как следствие переделка "всего и вся".

3. Куча изменений и добавлений полей под будущие, уже более локальные изменения... то есть пути назад у меня уже нет

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

I. Уже 30% сделано. Подсистема "любимые отчеты". Как руководители (в силу их загруженности), так и новички поголовно жалуются и ругаются на громоздкость, сложность и запутанность отчетного контура системы... типа им нужно в реале 5-10 отчетов, а они "разбросаны везде", да и постоянно забывается "для чего они им нужны".

Что`ж в настройке появился режим - определения необходимых для конкретного пользователя отчетов. Это примерно выглядит так:



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

Подскажите!!! Пока ещё только в начале создания этой подсистемы.

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

Ну, могу сказать, как я к этому вопросу подхожу.

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

Для каждой роли можно сделать динамическую настройку меню путем скрытия неиспользуемых строк и разделов. Это может сделать сам пользователь.

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

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

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

Это конечно условно сказал про сжигание мостов... Предыдущая система с полными исходниками осталась, да и вообще:

1. Сохраняется отлаженная версия
2. Начинаю создавать новую

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

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

Про "историю переходов" - интересно и совсем не сложно, хотя и четкое структурирование режимов "оперативного персонала" и их "простота" в рамках идеологии УС Лэнд... вроде бы никогда это не "напрягало"

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

Это мной чой-то вспомнилась дискуссия Является ли УС Лэнд самопиской и какие критерии самописок?

Немножко "расколюсь" по процессу разработки:

1. В течении длительного времени задачка крутится в голове в поисках оптимального или легкого решения;
2. После его обнаружения набрасывается краткое схематичное описание решения и откладывается до готовности его реализовать;
3. Реализация. Смотрю схему решения и реализую её фрагменты последовательно делая заметки на листочках типа, показанного ниже и подробно в тексте описываю алгоритмы. Если происходит изменение, то сохраняется в "мусорке" старый модуль, изменение просто описывается на листочках, а в исходниках делаются краткие примечания. Пример описания разрабатываемого модуля:



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

Мне кажется, что тут просто надо попробовать :) Искать по бумажкам трудно, а составлять список различий (diff) еще труднее... Но не буду настаивать, я просто от листочков уже давно ушел, т.е. обдумывание идет в голове, все остальное - в электронном виде.

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

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

P.S. На бумажке я тоже любил порисовать, пока система функционально не насытилась. Причем с помощью карандаша и стерки. Олд-скул

Ух! - Закончил...

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

Как описано в первом сообщении для пользователя или через "размножение" - (F9) для пользователей определяется список постоянно, используемых отчетов с описанием понятным себе языком их предназначения. Добавилось только контроль на их максимальное число - 19 штук, иначе это не "любовь", а "блуд".

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



После нажатия клавиши Tab, если для пользователя определен список "любимых отчетов", то программа его отобразит и с ним Вы работаете, как с полной и замкнутой системой меню. Например:



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

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

Продолжим`с... Возможно и будут замечания и советы?

В системе УС Лэнд имеется довольно развитый контур "производства", частично описанный и обсуждаемый в теме: Автоматизация производства при помощи универсальных учетных систем. Конечно сейчас он более развился и как следствие усложнился...

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

Технология комплектования/комплекта/сборки.

Объект-комплект (О-К) описывается в блоке "производства" простенькой таблицей - список ассортиментов с количествами, входящим в единицу ассортимента О-К. Будут три универсальных операции:

1. Молнееносное определение максимально возможных количеств О-И;
2. Молнееносное (доли секунды) производства требуемого количества О-К.
3. Отгрузка О-К или товаров его определяющих.

Поведение О-К зависит от наличия товара-шаблона для данного О-К:

I. НЕТ шаблона для О-К. При попытке создать операцию "производства" программа сие действо запретит. При выборе О-К при создании отгрузочной накладной вместо одного О-К программа "выпишет" составляющие его товары в требуемом количестве.

II. Есть товар-шаблон для О-К. Операция производства произведет необходимое изделие в требуемом количестве с расчетом его себестоимости. При выборе О-К при создании отгрузочной накладной программа произведёт необходимое количество изделий по шаблону и внесет в накладную изделие соответствующее О-К в требуемых количествах.

Цена реализации. Программа просчитает сумму цен продажи по составляющим О-К и предложит её, а в случае её изменения пересчитает цены для товаров составляющих О-К.

Дополнительно предполагаются режимы:

1. Автоматическое преобразование существующей технологической карты с единственным "приходящим" изделием (полуфабрикатом) в объект-комплект.

2. Автоматическое, так же в систему добавлен набор таблиц использование товаров-заменителей при продаже и производстве.

К созданию этих технологий "руки дойдут" наверное только в июле, а посему будет время внимательно выслушать замечания к данным технологиям?