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

Видел через плечо, что в крупной сети автосалонов Дженсер единое решение и по продажам и по обслуживанию построено на аксесе.

Тем не менее, ваша постановка ТЗ тянет на полноценную учетную систему. Таблиц должно быть несколько десятков. У вас впереди долгий путь, его можно пройти, но напрягаться придется сильно.

Подпись: Инженер-конструктор.

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

Вам не потребуется будет хранить информацию о составе изделий (автомобилей) по агрегатам и деталям и агрегатов по суб-агрегатам и деталями ? Если да, то вы попадаете на деревья и их обработку.

Берясь за новый проект я бы сразу выбрал чуть другой вариант - аксес adp + Ms SQL сервер. С джетом (mdb) не стал бы связываться из-за дикого неудобства программирования запросов и отсутсвия серверных процедурю

Т.е. мельчайшая единица - агрегат. Из агрегатов состоят изделия. Агрегаты не могут включать другие агрегаты ?

Нормы материалов на ремонт агрегатов есть ?
Какое отношение имеют материалы к агрегатам ?
Материалы могут быть использованы на ремонт всего изделия в целом, без указания агрегата ?

Не сервер как тоаковой, а связка Access ADP + MS SQL. Главное, как мне кажется - это нормальная разработка запросов, скалярных и табличных ф-ий, процедур. В конструкторах аксеса ничего толком не накорячишь.

У вас неизбежно будут сложные многоступенчатые запросы.

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

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

Походите по магазинам, посмотрите. Лучшими книгами по аксесу считается 2-х томный Гетц.
Изучите готовые шаблоны БД, которые входят в комплект офиса.
Найдите и скачайте демо БД Solutions, Northwind.

Подумайте и решайте насчет версии аксесс и связки с sql сервером.

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

авторЖалеть меня не надо (лучше помогите)
автордля начало упорядочить и систематизировать ваши функциональные требования из сообщений и ответов на вопросы. После нескольких итераций из него можно будет получить список сущностей и начать строить структуру БД.

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

Нет, конечно - приложение, да еще одним разработчком, можно вылеплять, выращивать постепенно. Добавление полей - абсолютно не проблема, при переименовании поля там есть механизм, который во многих других объектах, использующи старое поле, меняет его на новый. Я им не пользуюсь, поэтому точнее не расскажу. Обычно бывает некое расслоение приложения:

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

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

Третий слой - формы и отчеты.

Каждый следующий слой опирается на предыдущий.

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

Можно придерживаться такой иделогии - составлять достаточно "широкие", "универсальные" запросы, соединяющие с запасом все поля из справочников для какой-то важной сущности и использовать один и тот же запрос для нескольких форм. Разве только что условие WHERE часто бывает нужно динамически с клиента подклеить или, реже, перечислить конкретные столбцы. На мой взгляд так получается меньше объектов в БД и проще разработка. Еще одно мое вкусовое предпочтение - не использовать в запросах ссылки на поля форм, как делают очень многие. Вместо этого я сам в коде VBA обхожу контролы, собираю из них значения, подставляю в текст запроса и "запускаю" его в джете. Собсно динамическое присвоение ControlSource субформам и RecordSource формам и субформам мне кажутся наиболее эффективные приемы программирования приложений Access.

Будьте готовы при работе не с ADP версией на тяжелых формах наткнутся на сообщение: открытие дополнительных баз даннных не возможно.

Все вышесказанное очень общие соображения, часто субъективные соображения, не касающиеся 1ой итерации вашего ТЗ. Глубоко анализировать его сейчас нет времени.

ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ

1. Система регистрации данных о материальных ресурсах (материалы, ГСМ, запчасти).

1.1. На основании входящих документов (счета-фактуры, договора на поставку и т.д.) регистрация в БД материалов, ГСМ, запчастей их стоимости и количества (опционально). // количество материалов фактически имеющихся на складе для нормирования и защиты не важно, имеет значение только цена. // А так же принадлежности (цена на материальные ресурсы для военных изделий или для гражданских?).

1.2. Система должна отслеживать актуальность обоснований цены на материальные ресурсы. Т.е. сверять сколько времени прошло для того или иного ресурса со времени последнего обновления цены (даты последней счет фактуры), через определенные периоды помечать материалы каким-либо образом. Например цветом в таблице материальных ресурсов, через два месяца – желтым, через четыре – оранжевым, через шесть - красным.

1.3. Цены на материальные ресурсы и их обоснования должны все оставаться в базе данных. При обосновании материальных затрат на ремонт зачастую (но не всегда) используется самая большая цена, а она не обязательно самая последняя. Плюс желательно видеть динамику изменения цен на те или иные ресурсы.

1.1. - 1.3. Входящий документ содержит цену ? У вас будет постоянный оборот материалов, операции [принято на склад]/[отпущено на ремонт] будут идти вперемежку. Расчет цены в этом случае возможен по ФИФО, ЛИФО, среднему. Вы попадаете на полноценный складкой-бухгалтерский учет.

1.4. Отдельно, на основании писем предприятий поставщиков, протоколов и др. документов (а так же старых счет фактур с учетом дефлятора) – не имеющих значимости как обоснование фактических затрат, должна быть предусмотрена возможность формирования плановых цен на будущий период

2. Система регистрации данных о ремонтируемых изделиях.

2.1. При поступлении изделия в ремонт (скорее всего на основании договора) в БД регистрируются данные изделия.
Для машины – заводской номер, дата изготовления, тип машины (из списка, список со временем и с освоением ремонта новой техники может меняться), тип ремонта (1 капитальный, 2 капитальный, … 5-й капитальный, техобслуживание …. прочее). На предприятие поступает в ремонт в (указать какой) раз, принадлежность ( укрупнено - военная, гражданская), дата начала ремонта. дата окончания ремонта, комментарии.
Для агрегата – наименование, заводской номер, обозначение, тип машины на которой установлен, дата изготовления, тип ремонта, на предприятие поступает в ремонт в (указать какой) раз, принадлежность (военная, гражданская), дата начала ремонта, дата окончания ремонта, комментарии.

3. Система составления норм на ремонт изделий.

3.1. Для машин и для изделий в зависимости от типа и принадлежности (военн, гражд) составляются нормы расхода тех или иных материальных ресурсов на ремонт с возможностью разбивки по участкам (6 участков). В идеале, так как машина состоит из агрегатов, суммарная норма расхода материала на ремонт машины должна быть равна сумме норм на ремонт всех ее агрегатов (на предприятии такой учет пока не реализован, да и нормы есть еще не на все агрегаты, а их много, но вообще к этому стремимся так что имеет смысл заложить возможность в БД. Для нормы расхода материала так же должно быть указано основание – откуда взята.

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

4. Система регистрации фактических затрат материальных ресурсов на ремонт.

4.1. На основании «Требования» (номер требования, дата, участок) в базу данных заносятся данные по фактическому расходу материальных ресурсов. (материальный ресурс, количество, цена за ед, стоимость, счет-фактура, лист номер листа счет фактуры в подшивке) на машину/ агрегат. (для нормирования имеют значение требования выписываемые на машину, на двигатель, другие агрегаты выписываются как прочая продукция)

Здесь опять должно быть сквозное соответствие объектов учета. Нормы и требования лучше указывать настолько подробно и точно, как это вводилось при регистрации данных о ремонтируемых изделиях. Общий итог по машие в целом можно посчитать потом.

4.2. При занесении расхода материального ресурса в БД производится сверка фактического расхода ресурса с плановым (можно реализовать высвечивая на экране в каком-либо поле остаток (плановый расход минус сумма внесенных ранее фактических расходов. Оставить возможность превышения планового расхода, однако в этом случае строка материальных затрат на экране должна каким-либо образом выделяться (цветом).

5. Выдача отчетов.

5.0. Отчеты выдаются в виде таблиц эксель. Необходимы следующие отчеты:

Вы попали на создание механизма выгрузки данных в эксель. Если они нужны в визульно пристойном виде.

5.1. Расшифровка материальных затрат на ремонт машины. С разбивкой на три главные таблицы: материалы, ГСМ, запчасти. В каждой таблице идет разбивка следующим образом – материалы разбиваются по группам материалов (текстильные, черные металлы, цветные металлы, химикаты, лакокрасочные … и т.д.) (предусмотреть возможность разбивки при желании так же и по агрегатам), ГСМ – общим списком (так же можно разбить по агрегатам), запчасти по агрегатам (допускается укрупнено по системам – например электросистема, трансмиссия, двигатель, кузов и т.д.). Так же все таблицы при желании можно разбить по участкам ремонта.

5.2. Расшифровка материальных затрат на ремонт агрегата. Та же разбивка на три главные таблицы: материалы, ГСМ, запчасти. Материалы разбиваются по группам, ГСМ и запчасти общим списком.

5.3. Выдача норм на ремонт изделий. Кстати нужно предусмотреть возможность сохранения старых норм, что бы отследить их изменения.

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

В целом, писать ЕРП с нуля - это надо иметь очень много ЛИШНЕГО времени/знаний/здоровья. В принципе, задача решаема, для себя я бы оценил строк 6-12 месяцев.

ViPRos,

На вашем инструментарии было бы в разы быстрее. Я давал комментарии по технологии, выбранноой самим ТС, т.к. это мой основной инструмент. Оптимальным аксес для такой разработки не является.