Составление претензий к поставщикам
Постановка задачи
Цель:
Определить объем неустоек, предъявляемых строительной организацией поставщикам.
Организационно-экономическая сущность:
Формирование «Претензий к поставщикам» является одной из важнейших задач подсистемы МТС, позволяющая определить компенсацию за несвоевременную доставку, за количество дефектных материалов, за недопоставку материалов. «Претензия к поставщику» составляется на основании документов: «Ведомость контроля графиков поставок МТР по договорам», которая хранится в отделе МТС, «Договора на поставку МТР», которые также хранятся в отделе МТС. Также используются Справочник МТР и Справочник поставщиков МТР, которые хранятся в отделе МТС. Из «Ведомости контроля графиков поставок МТР по договорам» определяются фактические и плановые сроки и объемы поставок, количество дефектных МТР. Из «Договоров на поставку МТР» компенсации за различные отклонения. Для формирования ведомости необходимо определить по году ведомость контроля графиков поставок по договорам, из которой определим фактические и плановые сроки и объемы поставок МТР, Для определения отклонений необходимо от планового объема поставки отнять фактический объем МТР поступивших на склад. Для определения отклонений в сроках поставки необходимо от планового срока поставки отнять фактический срок поступивших МТР на склад. Компенсация за количество дефектных материалов есть произведение компенсации за единицу дефектного МТР на количество дефектных МТР по данному договору. Компенсация за отклонение по сроку есть произведение компенсации за день просрочки на количество дней. Компенсация за отклонение по объему есть произведение компенсации за объем материала на количество недовезенного материала. Количество дефектных МТР определяется визуально.
|
|
|
Периодичность и область применения:
«Претензии поставщикам» составляются в конце каждого года и передаются соответствующим поставщикам для компенсации отклонений.
Технико-экономическая эффективность:
Автоматизированное формирование «Претензий поставщикам» позволяет определить компенсацию по отклонению по срокам, объемам или за дефектные детали и составить претензии к поставщикам МТР. Автоматизация данной задачи - значительно упрощает обработку большого количества информации о поставках МТР на склад и выявление недопоставок, срывов сроков поставок и некачественных поставок, а также экономит людские и временные ресурсы организации и выполняется одним человеком с наличием соответствующего пакета программ. При этом предполагается выявление недопоставок, срывов сроков поставок и контроль качества поставок.
|
|
|
Информационное обеспечение
Входная информация:
Оперативная информация:
В качестве входной оперативной информации используется:
- Договора на поставку МТР;
- Ведомость контроля графиков поставок МТР по договорам.
Нормативно-справочная информация:
- Справочник поставщиков;
- Справочник МТР;
Входные формы документов:
Справочник МТР:
Договора на поставку МТР:
Справочник поставщиков:
Ведомость контроля выполнения графиков поставок по договорам:
Выходная информация:
Выходная форма документа:
Претензия поставщику МР:
Описание выходной формы:
В результате решения данной задачи формируется документ «Претензии к поставщику». Документ представляется на листах формата А4 и является систематизированным, вторичным, текстово - цифровым. В претензии указывается поставщики, и поставляемые ими МТР.
Для каждого поставщика из этой ведомости указываются нарушения договорных обязательств и определяются отклонения в сроках и объемах поставок. Указывается количество дефектных МТР. На основе этих данных определяются компенсации по указанным параметрам.
Перечень получателей:
|
|
|
Сформированная «Претензия к поставщику» передается на утверждение ген.директору организации. После чего претензия передается поставщикам для возмещения денежных компенсаций.
Укрупненная блок-схема:
Нормализация
При проектировании структуры БД определяются сущности (явления, объекты) предметной области, которые должны найти свое отражение в базе данных. Анализ предметной области обычно осуществляется на основании известных сведений о ней с учетом целей проектирования программной системы. В результате анализа создается проект БД.
Процесс проектирования БД в немалой степени зависит от опыта и интуиции разработчика, то есть является творческим, однако некоторые его моменты можно формализовать. Одной из таких формализации является требование, согласно которому реляционная база данных должна быть нормализована. Процесс нормализации имеет своей целью устранение избыточности данных и заключается к приведению к третьей нормальной форме.
Определения.
1.Отношение – по сути сама таблица.
2.Сущность – любой различимый объект или класс однотипных различимых объектов (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных.
|
|
|
3.Атрибут – поименованная характеристика сущности. Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности ЖБИ являются ТИП, МАРКА, ДЛИНА, ШИРИНА, ВЫСОТА и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ТИП имеет много экземпляров или значений: Свая, Колонна, Плита перекрытия и т.д.
4.Ключ - минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. То есть ключ - уникален.
5.Неключевым атрибутом называется любой атрибут отношения, не входящий в состав ключа (в частности, первичного).
6.Неключевой атрибут функционально полно зависит от составного ключа, если он функционально зависит от всего ключа в целом, но не находится в функциональной зависимости от какого-либо из входящих в него атрибутов.
7.Функциональная зависимость R.X -> R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости R.X -> R.Z и R.Z -> R.Y и отсутствует функциональная зависимость R.Z -> R.X. (При отсутствии последнего требования мы имели бы "неинтересные" транзитивные зависимости в любом отношении, обладающем несколькими ключами.)
8.Два или более атрибута взаимно независимы, если ни один из этих атрибутов не является функционально зависимым от других.
Нормальные формы.
Первая нормальная форма(1NF) - значения всех атрибутов отношения атомарны.
Отношение находится во второй нормальной форме (2NF) в том и только в том случае, когда находится в 1NF, и каждый неключевой атрибут полностью зависит от первичного ключа.
Отношение находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 2NF и каждый не ключевой атрибут не транзитивно зависит от первичного ключа.
Как было описано выше третья нормальная форма требует, чтобы в отношении не имелось транзитивных зависимостей между неключевыми атрибутами, то есть любой атрибут, не входящий в первичный ключ, не должен зависеть от другого атрибута, также не входящего в первичный ключ.
Вычисляемые поля хранить в БД нецелесообразно, за исключением тех из них, для вычисления которых требуется производить очень сложные выборки, требующие больших ресурсных и временных затрат.
СПРАВОЧНИК МТР.
- 
* Код МТР
- 
Наименование МТР
- 
Тип, Марка,
- 
Единица измерения
- 
Место_доставкти
В справочнике материалов первичным ключом является атрибут «Код МТР» этот ключ является ключом искусственного происхождения, СУБД гарантирует его уникальность и автоматически выдает его значение (тип счетчик), предотвращая этим возможные ошибки пользователя.
СПРАВОЧНИК ПОСТАВЩИКОВ:
-* Код поставщика
- Наименование поставщика
- Код МТР
- Наименование МТР
- Тип, Марка
- 
- Ед. измер.
- Адрес поставщика
- Телефон
- Расчетный счет
- Наименование банка
- Мощность
В справочнике поставщиков первичным ключом является атрибут «Код поставщика» этот ключ является ключом искусственного происхождения, СУБД гарантирует его уникальность и автоматически выдает его значение, предотвращая этим возможные ошибки пользователя.
После проведенных с данным отношением операций оно примет вид
-* Код поставщика
- Наименование поставщика
- Код МТР (ВК)
- Адрес поставщика
- Телефон
- Расчетный счет
- Наименование банка
-Мощность
СПРАВОЧНИК УЧАСТКОВ:
- * Код объекта
- Наименование объекта
- Город
- Улица
-Дом
-Корпус
-Телефон
В справочнике объектов первичным ключом является атрибут «Код объекта» этот ключ является ключом искусственного происхождения, СУБД гарантирует его уникальность и автоматически выдает его значение, предотвращая этим возможные ошибки пользователя.
Входные документы:
Ведомость потребности в МТР по объектам:
- *Код ведом
- *Код МТР
- Наименование МТР
- Тим,Марка
- Ед. измер.
- Место_доставки
- *Код объекта
- Наименование объекта
- Кол-во МТР 1 мес
- Кол-во МТР 2 мес
- Кол-во МТР 3 мес
- Кол-во МТР 4 мес
- Кол-во МТР 5 мес
- Кол-во МТР 6 мес
- Кол-во МТР 7 мес
- Кол-во МТР 8 мес
- Кол-во МТР 9 мес
- Кол-во МТР 10 мес
- Кол-во МТР 11 мес
- Кол-во МТР 12 мес
- * Код ведом
- *Код МТР
-*Код объекта
- Кол-во МТР 1 мес
- Кол-во МТР 2 мес
- Кол-во МТР 3 мес
- Кол-во МТР 4 мес
- Кол-во МТР 5 мес
- Кол-во МТР 6 мес
- Кол-во МТР 7 мес
- Кол-во МТР 8 мес
- Кол-во МТР 9 мес
- Кол-во МТР 10 мес
- Кол-во МТР 11 мес
- Кол-во МТР 12 мес
Ведомость потребности в МТР на год:
- *Год
- *Код МТР
- Наименование МТР
- Тип
- Марка
- ГОСТ
- Ед. измер.
- Кол-во МТР 1 мес
- Кол-во МТР 2 мес
- Кол-во МТР 3 мес
- Кол-во МТР 4 мес
- Кол-во МТР 5 мес
- Кол-во МТР 6 мес
- Кол-во МТР 7 мес
- Кол-во МТР 8 мес
- Кол-во МТР 9 мес
- Кол-во МТР 10 мес
- Кол-во МТР 11 мес
- Кол-во МТР 12 мес
- *Год
- *Код МТР
- Кол-во МТР 1 мес
- Кол-во МТР 2 мес
- Кол-во МТР 3 мес
- Кол-во МТР 4 мес
- Кол-во МТР 5 мес
- Кол-во МТР 6 мес
- Кол-во МТР 7 мес
- Кол-во МТР 8 мес
- Кол-во МТР 9 мес
- Кол-во МТР 10 мес
- Кол-во МТР 11 мес
- Кол-во МТР 12 мес
Ведомость остатков МТР на складе:
- Код МТР
- Наименование МТР
- Тип, Марка
- Ед.измер
- Место Доставки
- Год
- Остаток
- *Код МТР
- Год
- Остаток
Перечень критериев по оценке поставщиков:
- *Наименование критерия
- *Наименование поставщика
- Балл
Перечень Выбранных поставщиков:
- *Код Поставщика
- Наименование поставщика
- Балл
- *Код поставщика
- Балл
Заявки на поставку МТР на объект:
*Код МТР
Тип. Марка 
Ед.Измер.
Код объекта
*Наименование об.
Город
Улица
Дом
Корпус
Количество
Месяц
Число
Код МТР
Код объекта
Количество
Месяц
Число
Договора МТР:
*Код договора
№ дог
*Код МТР
Тип, Марка
Наим МТР
Тип доставки
Ед.Измер.
Объем поставки
Штраф за отклонение по объему
Штраф за отклонение по сроку
Штраф за дефектные МТР
*Код договора
№ Договора
*Код МТР
Объем поставки
Штраф за отклонение по объему
Штраф за отклонение по сроку
Штраф за дефектные детали
Товарные накладные:
*Код накладной
№ накладной
*Код МТР
Наименование МТР
Тип,Марка
Ед.Измер
*Код поставщика
Наим. поставщика
Количество
Год
*Код накладной
*Код МТР
*Код поставщика
Количество
Год
 |
Накладные на отгрузку:
*Код накладной
№ накладной
Код МТР
Тип,Марка
Ед.Измер
*Код объекта
Наим. объекта
Количество
Год
*Код накладной
*Код МТР
*Код объекта
Количество
Год
График на поставку на участок:
- *Код
- *Код МТР
- Наименование МТР
- Тип, Марка
- Ед. измер.
-*Код объекта
-Наимен.объекта
-Адрес объекта
- Кол-во МТР 1 мес
- Кол-во МТР 2 мес
- Кол-во МТР 3 мес
- Кол-во МТР 4 мес
- Кол-во МТР 5 мес
- Кол-во МТР 6 мес
- Кол-во МТР 7 мес
- Кол-во МТР 8 мес
- Кол-во МТР 9 мес
- Кол-во МТР 10 мес
- Кол-во МТР 11 мес
- Кол-во МТР 12 мес
- *Код
- *Код МТР
-*Код объекта
- Кол-во МТР 1 мес
- Кол-во МТР 2 мес
- Кол-во МТР 3 мес
- Кол-во МТР 4 мес
- Кол-во МТР 5 мес
- Кол-во МТР 6 мес
- Кол-во МТР 7 мес
- Кол-во МТР 8 мес
- Кол-во МТР 9 мес
- Кол-во МТР 10 мес
- Кол-во МТР 11 мес
- Кол-во МТР 12 мес
График на поставку на склад:
- *Код
- *Код МТР
- Наименование МТР
- Тип, Марка
- Ед. измер.
- Кол-во МТР 1 мес
- Кол-во МТР 2 мес
- Кол-во МТР 3 мес
- Кол-во МТР 4 мес
- Кол-во МТР 5 мес
- Кол-во МТР 6 мес
- Кол-во МТР 7 мес
- Кол-во МТР 8 мес
- Кол-во МТР 9 мес
- Кол-во МТР 10 мес
- Кол-во МТР 11 мес
- Кол-во МТР 12 мес
-Год
- *Код
- *Код МТР
- Кол-во МТР 1 мес
- Кол-во МТР 2 мес
- Кол-во МТР 3 мес
- Кол-во МТР 4 мес
- Кол-во МТР 5 мес
- Кол-во МТР 6 мес
- Кол-во МТР 7 мес
- Кол-во МТР 8 мес
- Кол-во МТР 9 мес
- Кол-во МТР 10 мес
- Кол-во МТР 11 мес
- Кол-во МТР 12 мес
-Год
Ведомость заявок на поставку МТР на склад:
- *Код
- *Код МТР
- Наименование МТР
- Тип, Марка
- Ед. измер.
- Кол-во МТР 1 мес
- Кол-во МТР 2 мес
- Кол-во МТР 3 мес
- Кол-во МТР 4 мес
- Кол-во МТР 5 мес
- Кол-во МТР 6 мес
- Кол-во МТР 7 мес
- Кол-во МТР 8 мес
- Кол-во МТР 9 мес
- Кол-во МТР 10 мес
- Кол-во МТР 11 мес
- Кол-во МТР 12 мес
-Год
- *Код
- *Код МТР
- Кол-во МТР 1 мес
- Кол-во МТР 2 мес
- Кол-во МТР 3 мес
- Кол-во МТР 4 мес
- Кол-во МТР 5 мес
- Кол-во МТР 6 мес
- Кол-во МТР 7 мес
- Кол-во МТР 8 мес
- Кол-во МТР 9 мес
- Кол-во МТР 10 мес
- Кол-во МТР 11 мес
- Кол-во МТР 12 мес
-Год
Ведомость контроля поставок МТР:
*Код ведомости
* Код дог
-№ договора
*Код МТР
Тип, Марка
Тип доставки
Ед.Измер.
Объем поставки
Отклонение по объему
Отклонение по сроку
Кол-во дефектных МТР
*Код ведомости
*№ Договора
*Код МТР
Объем поставки
Отклонение по объему
Отклонение по сроку
Кол-во дефектных МТР
Концептуальная модель БД
Концептуальная модель представляет объекты и их взаимосвязи без указания способов их физического хранения.
Таким образом, концептуальная модель является, по существу, моделью предметной области. При проектировании концептуальной модели все усилия разработчика должны быть направлены в основном на структуризацию данных и выявление взаимосвязей между ними без рассмотрения особенностей реализации и вопросов эффективности обработки. Проектирование концептуальной модели основано на анализе решаемых на этом предприятии задач по обработке данных.
Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных. Здесь имеются в виду данные, используемые как в уже разработанных прикладных программах, так и в тех, которые только будут реализованы.
Концептуальная модель транслируется затем в модель данных, совместимую с выбранной СУБД. Возможно, что отраженные в концептуальной модели взаимосвязи между объектами окажутся впоследствии нереализуемыми средствами выбранной СУБД. Это потребует изменения концептуальной модели.
Версия концептуальной модели, которая может быть обеспечена конкретной СУБД, называется логической моделью.
Структура концептуальной модели базы данных подсистемы материально-технического снабжения АСУ ООО “ДСК АФТ” приведена на листе 2.
Дата добавления: 2018-04-05; просмотров: 178; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!