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

Как огранизовать обмен информацией между отделом администрации и отделом диагностики.

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

Как организовать это взаимодействие? Через базу данных. Или я даже не знаю. через спциальный тип объектов. и список этих объектов.

Нужно учитывать что клиентов может быть много. 

А, и еще такой прикол. Нужно получить отчет от отдела диагностики со списком поломанных деталей, и потом перенаправить его в отдел склада, как запрос на детали. 
Может через базу данных всетаки это организовать? 

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

а так запросы  и отчеты это бд не сомневайся.

Killerman, 
приветствую.
В администаративном отделе на компьютере устанавливаете MS SQL Express 2005 (бесплатный сервер) и пишешь клиентское приложение в VS(С# или VB.NET ).
Спроектируй базу данных, которую потом создашь на своем сервере. Приложения установишь в администрации, на складе и в мастерской. Естественно должна быть сеть(проводная или безпроводная), и все три компьютера должны входить в эту сеть. Иначе они не получат достут к БД на сервере.
Для проектирования БД почитай про нормализацию. Это в принципе самый важный момент. От того как ты спроектируешь БД, будет зависеть работа всей системы. Правильно создашь таблицы для хранения информации и связи между ними, глюков не будет. Есвли нет, то рано или поздно все накроется "медным тазом".
Посмотри внимательно какие документы вы там используете, выпиши всю необходимую информации, разбей ее на группы и по правилам нормальных форм создай таблицы.
К примеру должны быть следующие таблицы: клиенты(информация о клиенте), заявка(информация о шапке документа: номер, когда, кому, чего, для чего), детали этой заявки(собственно строки заявки: что, сколько, по какой цене и т.д.), детали (информация о деталях: код, наименование, цена, кол-во на складе и т.д.), Выполненные работы (две таблицы: шапка документа и строки документа:кто, чего, когда и сколько сделал), монтеры(информация о монтерах). Ну и так далее что там у вас нужно.
Обговорите как происходит весь процесс, кто что делает, какие документы и как заполняет, кому передает. В общем составь описание бизнес процесса. Потом разбей его на подпроцессы: от куда и какая информация берется, как обрабатывается, куда и как передается, как сохраняется (это называется use-case) потом разработай интерфейс программы. И когда это будет готово, приступай к кодированию.
Будут сложности пиши.
Удачи.   

Спасибо.
А как организовывать списки в таблицах?
К примеру есть заказ номер 1234 на диагностику. В диагностическом центре проверяют данный автомобиль и возвращают в администрацию ремонта список поврежденных деталей и список работ, которые нужно провести по ремонту данного заказа.

Как заносить эти данные в таблицу чтобы отправить их в центр ремонта? Это должна быть таблица с отношениями многие - ко многим - ко многим, как номер заказа - поврежденная деталь - работа? или 2-ве таблицы:
номер заказа - деталь  (многие ко многим)
номер заказа - работа. (многие ко многим)

Или как то еще?

ИМХО, так.

Killerman, 
Приветствую.

Значиться так, у вас есть заказы, соответственно данные о них надо хранить в отдельной таблице.
tblЗаказ
номер РК - уникальный
дата заказа
id клиента - связь с таблицей данных о клиентах
id машины - связь с таблицей данных о машинах (если надо хранить много данных о машинах)
или марка авто
кому заказ - если разные цехи или исполнители (можно Id для связи с соответствующей таблицей)

Далее надо создать таблицы орисывающие документ возвращаемый из диагностического центра:
tblЗаявкаНаДетали - или как там у вас этот документ называется
номер документа РК
дата
номерЗаказа - связь с предыдущей таблицей, указывает на какой заказ дается ответ
номер исполнителя - связь с таблицей содержащей данные на монтеров т.е. РК из той таблицы.
плюс еще данные которые вам нужны

tblДеталиЗаявкиНа Детали - содержит данные о строках заявки на детали
idстроки РК
номер документа FK - связь с родительской таблицей, о какой завке на детали идет речь
номер детали - связь с таблицей содержащей данные на детали, там это РК
кол-во
и что там вам еще нужно

tblРаботы - описывает необходтимые работы для проведения ремонта по данной заявке
idстроки РК
номер документа FK - связь с родительской таблицей, о какой завке на детали идет речь
наименование работы (или id, если есть перечень стандартных работ с расценками)
кто выполнял (или будет выполнять) -  связь с таблицей монтёры
дата

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

Идею улавливаешь?
  


Это сообщение отредактировал(а) thomas - 30.12.2007, 20:07

Привет thomas.
В принципе понимаю. 
Я хотел вот как:
Из центра ремонта поступает заказ (в виде записи в таблицу) в центр диагностики. Запись вида:
(номер заказа - id атво)

Когда авто приехало на диагностику, они исходя из этого заказа после проверки автомобиля формируют (как ты говорил - минимум) две таблицы. Я думаю типа:
1) (номер заказа - деталь - колличество) - здесь будет скажем к примеру 10 записей с тем же номером заказа, но с разными названиями деталей.
2) (номер заказа - работа) - также к примеру 6-ть записей с тем же номером заказа, но разными работами.

Таблицы 1) и 2) - общие для множества клиентов. Поэтому в них много записей с разными номерами заказов.

Отдел ремонта потом считует из этих таблиц те записи, номер заказа на который их интересует.

Только как то нада оповестить отдел ремонта об окончании проверки автомобиля.    

Если так подойдет. ?

Это сообщение отредактировал(а) Killerman - 31.12.2007, 02:04

Killerman, 
Приветствую.
Как я уже писал, нужна одна база данных и приложение которое будет работать с этой базой. Приложение устанавливается на разных компьютерах в разных местах, но устанавливает соединение с одной базой. Так вот каждое подразделение работает со своим окном(окнами) программы. На рабочем окне отдела ремонта висит список выполненных заказов, отсортированных по дате и времени. Последний выполненный в верху списка. Т.е. Отдел ремонта создал заявку на ремонт, программа сохранила данные в БД, на эране обновился список невыполнненых заказов. На диагностике программа переодически обновляет список заказов, приэтом пооследний поступивший отображается вверху. Приехало авто, выполнили диагностику. Составили заявку на ремонт, программа сохранила данные в БД и пометила заказ выполненным. А в это время в центре ремонта программа тоже переодически проверяет список заказов и отображает помеченные как выполненные в списке выполненных. Соответственно из списка невыполненных заказ перемещается в список выполненных заказов. Плюс отображается новая заявка в другом списке. 
Для этого в таблицах содержащих данные о заказах, заявках и тому подобное делается поле типа boolean(bit), которое отображает статус - выполнен/не выполнен, обработана/не обработана. И программа соответственно с заданной переодичностью выполняет запрос к БД на выборку заказов с отметкой выполнено и отображает их в списке.
Понятно?
Это о том 

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

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

С наилучшими пожеланиями и с Наступающим Новым Годом!!
Успехов и удачи во всем!   

Спасибо!    Буду думать.
И тебя поздравляю с Новым Годом! Веселых праздников.   

Killerman, 
С Новым Годом!
      

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