| |
 25 Кб. |
|
| | В общем, в двух словах... Дипломная работа "Сервисный центр по обслуживанию компьютерной техники". А раз диплом , то соответственно, что-то где-то какие-то детали при разработке можно опустить (в силу недостаточных знаний), да и вообще
не стоит задача описать все бизнес-процессы (склад+бухгалтерию+заказы-торговля), ибо задача эта неподъемная для меня. хм , ну, все это отступление....
Теперь к задаче.
Перед отсылкой своему руководителю решил сначала представить вам на суд, чтоб стыдно не было перед преподом
Меня немного ввела в ступор вот такая вещь. Рассмотрим функционирование сервис-центра с точки зрения сервисного инженера (кто непосредственно ремонтирует\диагностирует)
Возможны такие ситуации, когда требуется ремонт изделия , а нужных деталей нет на складе. Сервисный инженер должен заказать недостающие детали. Ежу понятно, что всё это должно быть описано мною в БД. Но хоть убейте, не знаю, как это сделать наверняка правильно. Подтолкните к верному решению.
Я всё сумбурно, объяснил, но я старался :)
Моя среда - Access 2003. Вложение (моя БД) прикрепил к своему сообщению.
100%, я что-то еще упустил из вида при построении БД. Ваши мысли?
спасибо всем за внимание. | |
| |
| |
| |
|
|
| | если принять во внимание что конечная цель всех ваших телодвижений это получение некоего счета - который в последствии будет преподнесен клиенту, то получается следующее -
в счет входят как оказанные услуги так и израсходованные материалы (тут я предполагаю что все накрутки и расценки включены в две эти категории) материалы в свою очередь должны быть оприходованы через склад, т.е. физически через него пройти - соответственно по моему МЫШЬлению на складе должно быть учтено откуда поступили материалы, по какой цене и когда - сответственно если материалы еще не поступили то эти 3 пунктика будут пустыми (ну можно добавить кому заказали и предположительную дату поступления, количество заказанного) теперь получается что составляя калькуляцию инженер пытается включить в нее материалы (необходимое количество) и делает заказ на склад - если на складе материалы есть то инженер запрашивает необходимое количество если нет то все равно заказывает на складе необходимое количество и заодно заказывает у поставщика ( в данный момент времени он может заказать больше чем ему необходимо) соответственно следующий инженер если пытается заказать материалы на складе видит сколько на складе, сколько заказано и сколько из заказанного уже занято и у второго инженера есть возможность либо подождать поступления или же дозаказать у поставщика
таким образом к Вашей табличке Оказанные услуги помимо уже подключенного блока Работы надо подключить блок заказы материалов на складе с соответствующими связями на складе
Ну пока вот такие мысли | |
| |
| |
| |
|
|
| | еще нужно чуток дорабротать схему
нужно добавить отдельные склады т.е.
в сервисном центре сидит приемщица которая принимает товар у нее свой склад
когда она передает товар мастеру( а в сервисном центре мастеров может быть достаточно много) то она должна сделать перемещение принятого товара на склад того мастера который занимается ремонтом данной техники, приемущества этого разбия по складам в том что на каждом мастере числиться только его техника  | |
| |
| |
| |
|
|
| | Ребят, спасибо вам обоим за ответы.
сейчас займусь правкой... | |
| |
| |
| |
|
|
| | небольшое дополнение: БД я спроектировал с условием, что один заказ может включать только одну позицию (объясняется просто - все несут всегда в сервис центр только одну вещь, и здравый смысл подсказывает, что заявку в сервис-центре оформляют на одну сломанную вещь)
Как выдумаете, такой подход имеет право на жизнь? или есть какие-то узкие места, которые в дальнейшем дадут знать ? | |
| |
| |
| |
|
|
| | Нормально.
+ Каскадное удаление связанных записей для связей:
1. Заказы - ОказанныеУслуги
2. Заказы - СвязьЗаказСостоянияЗаказа
, не помешало бы иметь. | |
| |
| |
| |
|
|
| | artem87-у - а что будет если один человек принесет 2 вещи или вещи от одного клиента попадут разным инженерам
Вы правы - на каждую вещь свой бланк-заказ и пусть этот бланк сопровождает веСЧь на всем пути ее следования
(а с клиентом от того сколько он носит бумажек - одну или три ни чего не случится) | |
| |
| |
| |
|
|
| | так-с, это без иронии написано ? :)
а то, бывает, не поймешь с какой интонацией написано | |
| |
| |
| |
25 Кб. |
|
| | Я совсем упустил из вида проверку серийного номера и возможность гарантийного ремонта.
Как вы думаете, как будет лучше организовать это?
мой вариант:я создал таблицу СЕРИЙНЫЕ НОМЕРА
И добавил в таблицу ЗАКАЗЫ поле СерийныйНомер. Я думаю, потом надо будет добавить процедуру Sub на VBA, которая будет проверять, не кончился ли гарантийный срок у изделия. Или будет достаточно выражения ?
алгоритм такой:
взять поле СерийныйНомер из таблицы ЗАКАЗЫ, запомнить его (пусть будет строка "У")
найти в таблице СЕРИЙНЫЕ НОМЕРА серийный номер равный "У"
В найденном поле СерийныйНомер из таблицы СЕРИЙНЫЕ НОМЕРА приплюсовываем к ДатаВыпускаИзделия срок гарантии и запоминаем его (пусть будет число ДАТА Х).
Сравниваем ДАТА Х с датой создания заказа.
______________________
вложенная обновленная БД прикреплена.
на всякий случай скриншот схемы БД (картинки отобразить не могу, вот прямая ссылка):
URL=http://s16.radikal.ru/i191/1001/20/be44bb98ee09.png
p.s. спасибо, что тратите свое время на помощь | |
| |
| |
| |
|
|
| | гляньте ширше или ширее
У вас ведь наверняка будут формы ввода информации где соответственно будет забиваться серийный номер
у поля - есть такое событие "после обновления" - возникает оно когда инфа в поле была внесена или изменена и юзер пытается покинуть это поле (нажав энтер таб или кликнув мышкой на другом поле) так вот если обработать это событие и заставить сравнить имеющиеся данные (в данном случае серийный номер) с данными имеющимися в некой не связанной с базой данных таблицей (ну или с инфой в другой базе данных) то при возникновении совпадений ......т.е. я все это к чему Ваша справочная таблица с серийными номерами может быть не привязана к Вашей базе данных
а на счет иронии - да бросьте вы - тут в полушутливом тоне иногда говорят об очень серьёзных вещах | |
| |
| |
| |
|
|
| | да да, все правильно.
и насчет того, что моя таблица с серийными номерами вообще может быть не привязана кмоей БД - я тоже об этом думал (ну я как думал - производитель ACER/ASUS/TEAC/HP и т.д. дает данные о серийных номерах в каком-то виде, и необязательно в формате базе данных, может быть вообще текстовый файл с табуляцией... )
ок, это я просто для примера такую таблицу ввел.
да, о событии "до обновления" знаю, конечно. Уверен, код на VBA будет простой, я справлюсь (щас Борей еще поизучаю). Ничего , если я обращусь сюда же, в это топик, если не получится с VBA или надо создать отдельную тему ?
спасибо за предложения! | |
| |
| |
| |
|
|
| | Ну - проще все-таки если это будет таблица -таблица в вашей базе данных но не связанная ни с чем
(вы не думали что в одном mdb может храниться и использоваться две - три независимых базы данных - все дело в доступе к этим базам)
таким образом есть ваша база и рядом таблица и в случае чего вы к ней обращаетесь
а насчет как обратиться - тут Вам принимать решение - если в топике появляется новое сообщение то он автоматически выносится вперед | |
| |
| |
| |
|
|
| | занятная тема - сервисный центр, что принимает ? изделие целиком ... далее идет исследование изделия на предмет неработоспособности деталей ... далее идет анализ наличия запасных частей на собственных складах .... if на своем складе then ....... else делаем заказ ... при этом заказ могет быть выбран из группы поставщиков (и необходимо в этом случаЕ учесть стоимость транспортных расходов !!!!!) .... ну а да далее все эт склеиваем ... | |
| |
| |
