|
Значицца идея:
1) Изменить схему работы с БД. Основы новых структур БД изложены в Ролевой Модели Данных (wiki.kint.ru), единственное дополнение, которое хотелось бы сделать это то, что в базе будут отсутствовать такие классические объекты метаданных как Константа и Справочник. Новая схема хранения данных опирается на следующее: Имеется Объект, который подлежит учету. Объект принадлежит какому-либо типу и наследует свойства типа. Конкретное значение свойств конкретного Объекта устанавливается Документом. Итого имеем а) Хранилище Объектов; б) Хранилище документов, устанавливающих свойства Объектов.
Преимущества: Становится прозрачным хранение и изменение данных, так как можно отследить любое изменение, каким документом сделано и т.д. Данная схема легко расширяется, например решили добавить новую область учета - описываем соответствующие типы, документы. Старая схема при этом остается полностью рабочей.
Мне, например, пришлось однажды искать, почему база для исчисления налогов в ФОМС отличалась от базы другого налога. Через два часа нашел сотрудника, которому случайно бухи поставили галочку "Сотрудник является инвалидом". Тогда как если бы для регистрации данного факта бухам пришлось бы ввести первичный документ - эту ошибку они бы не допустили. Или, например, в Рарус:Автохозяйство автомобили уже пишутся как "Камаз Р 070 АБ бывший Р 018 КС" - потому что свойство "Гос.номер" не устанавливается первичным документом "Паспорт технического средства" и т.д.
Пример: Поменялась ставка НДС - вводим новый документ, указываем сроки действия, пользуемся. В случае вопросов "а почему так" - поднимаем историю.
Сложность: Потребуется сделать строгий документооборот. Надо будет практически с нуля описать много базовых вещей, например сделать документ "Налоговый Кодекс" (возможно придется разделить его на документы по главам-статьям). С другой стороны, после окончания этой работы в случае внесения Гос. думой изменений в НК, придется переписать только соответствующие части данного документа, с указанием новых сроков действия.
2) Надо будет сделать "Конструктор документов", так как документов будет много и разных, кроме того, я бы поставил как обязательное условие - создание электронных форм документов аналогичными первичным документам, Т.е. форма документа"Паспорт", в части расположения ключевых полей совпадает с тем, как они расположены в самом документе "Паспорт". При этом обеспечивается гарантия того, что ни один из важных реквизитов не будет пропущен. Дополнительным плюсом будет то, что снизятся затраты на обучение персонала, так как будет явно видно куда и какие данные вносить.
3) Так как в любом случае реализуется новая структура БД, то можно написать класс "ПоставщикДанных", который будет отвечать за работу с СУБД, и, который можно переписать под другую СУБД (типа Постгре или МССКЛ, кому как нравится)
4) В самой дальней перспективе... Так как от "стандартного 1С" будет использоваться только интерфейс, то можно будет переписать эту часть с использованием любого другого ПО (например QT)
... вот такая вот идея, покритикуйте пожалуйста
|
Страницы: 
Сумасшедшие идеи для 1С. Кто больше? (число прочтений - 72074 )
