Пример ТЗ и ТП на небольшую доработку

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

Техническое задание:

УТВЕРЖДАЮ                                                         ПРЕДСТАВЛЯЮ НА УТВЕРЖДЕНИЕ

"     "______________ 2010 г.                                             "     "_______________ 2010 г.

Автоматизированная

система «СБЫТ».

Техническое задание

На  листах

Действует с «__» ____________ 2010 г.

" _" ______________ 2010 г.

1. Общие сведения

Наименование автоматизированной системы

«АС СБЫТ»

Заказчик

Исполнитель

Основание для выполнения работ

Плановые сроки начала и окончания работ по созданию системы

Начало работ: 01.09.2010

Окончание работ: 31.12.2010

Назначение и цели создания системы

Назначение системы

Разрабатываемая автоматизированная система  предназначена для автоматизации процессов сбыта предприятия..

Цели создания системы

Цели создания автоматизированной системы

Целями разработки «АС СБЫТ»являются:

1. 3.     Характеристика объекта автоматизации

3.1 Бизнес процессы предприятия

3.1. 1 Бизнес процесс «Заключение договора»

3.1.2. Бизнес процесс «Начисление оплаты»

1. 4.     Требования к системе.

4.1.Требования к системе в целом.

4.1.1.      Разрабатываемые в АС методы и программные модули должны содержать возможности дальнейшего развития системы.

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

5.1.2.      Разрабатываемая АС должна обеспечивать простоту настройки автоматизированного рабочего места (АРМ) каждого конкретного исполнителя в соответствии со сложившейся системой учета.

5.1.3.      Разрабатываемая АС должна обеспечивать разграничение прав доступа пользователей и предоставлять возможность доступа к информации в объеме, необходимом и достаточном для осуществления должностных обязанностей каждого исполнителя.

5.1.4.      Защита информации от несанкционированного доступа должна быть реализована с использованием следующих механизмов:

1. Ограничениями прав доступа на уровне платформы 1С:Предприятие 8.1.

2. Дополнительными ограничениями прав доступа на уровне среды исполнения.

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

5.1.4.2.Защита информации на уровне платформы

·         Защита информации на уровне платформы обеспечивается системными средствами. При этом регулируются права на чтение и редактирование объектов системы, использование интерфейсов, системных функций и выполнение регламентных операций с данными информационной системы.

·         Все права доступа должны быть систематизированы в соответствующие наборы – Роли информационной системы.

·         Список пользователей информационной системы должен определяться администратором системы.

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

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

·         При начале работы в системе пользователь должен пройти процедуру авторизации, указав свое имя в системе и пароль.

5.1.4.3. Защита информации на уровне среды исполнения

Для ряда справочников в системе должны быть обеспечены дополнительные ограничения прав редактирования.

Справочники, для которых необходимо установить запрет на редактирование в системе:

• Адресные сокращения
• Валюты
• Виды взаиморасчетов
• Виды деятельности контрагентов
• Группы пользователей
• Документы удостоверяющие личность
• Должности организаций
• Подразделения
• Пользователи
• Статьи движения денежных средств
• Статьи затрат
• Тарифы

5.1.5.      Для обеспечения сохранности информации при авариях, должно быть предусмотрено ежедневное автоматическое архивирование данных.

5.1.6.      Требования к эргономике и технической эстетике

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

5.1.6.2.Терминология, используемая для обозначения объектов и действий пользователей в системе должна соответствовать стандартной терминологии предметной области.

5.2.Требования к структуре и функционированию АС "СБЫТ".

5.2.1.      АС "СБЫТ" должна состоять из следующих автоматизированных подсистем:

-        Подсистема ввода первичной информации об абоненте (заключения договора);

-        Подсистема формирования документов на оплату;

-        Подсистема связи с системой АСКУЭ;

-        Подсистема связи с платежными терминалами.

5.2.2.      Состав Подсистемы ввода первичной информации об абоненте (заключения договора) должен быть следующим:

-        Документ «Договор с абонентом»;

5.2.3.      Состав Подсистемы формирования документов на оплату должен быть следующим:

-        Документ « Квитанция»»

-        Документ «Начисление штрафных санкций»

-        Документ  «Потребленная энергия»

-        Модуль проверки состояния взаиморасчетов

5.2.4.      Состав Подсистемы связи с системой АСКУЭ должен быть следующим:

-        модуль Связь с системой АСКУЭ.

5.2.5.      Состав Подсистемы связи с платежными терминалами должен быть следующим:

-        модуль Связь с с платежными терминалами.

5.3.   Требования к функциям модуля Подсистемы ввода первичной информации об абоненте (заключения договора)

5.3.1.      Подсистемы ввода первичной информации об абоненте (заключения договора) должна выполнять следующие функции:

-        Ввод и хранение информации об установленной мощности контрагента (в дальнейшем абонента);

-        Ввод и хранение информации об установленных счетчиках абонента;

-        Ввод и хранение информации о тарифах абонента;

-        Ввод и хранение информации о условиях начисления штрафных санкций абонента;

-        Ввод и хранение информации о сроках действия договора;

5.4.   Требования к функциям Подсистемы формирования документов на оплату

5.4.1.      Подсистема формирования платежных документов должна выполнять следующие функции:

-          Определение состояния взаиморасчетов с абонентом и определение условий возникновения штрафных санкций.

-          Формирование документов на оплату (квитанций или счетов на оплату).

5.5.   Требования к функциям Подсистемы связи с системой АСКУЭ

5.5.1.      Подсистемы связи с системой АСКУЭ должна выполнять следующие функции:

-  Передачу данных о вновь заключенных договорах с абонентами. Ключом связи должно быть уникальность пары «ID абонента» - «Код договора абонента».

-  Получение данных о потребленной электроэнергии абонентом. Ключом связи должно быть уникальность пары «ID счетчика» - «Код счетчика».

5.6.   Требования к функциям Подсистемы связи с платежными терминалами

5.6.1.      Подсистемы связи с системой АСКУЭ должна выполнять следующие функции:

-          Получение данных о произведенных платежах абонентами за электроэнергию через платежные терминалы.

1. 6.     Порядок контроля и приемки АИС "СБЫТ".

6.1.Устанавливается следующий порядок предъявления и сдачи Заказчику результатов работ:

6.1.1.      Исполнитель демонстрирует работоспособность ПО на контрольном примере.

6.1.2.      Данные для контрольного примера готовят представители Заказчика.

6.1.3.      Исполнитель передает программное обеспечение в информационный отдел Заказчика и выполняет обучение администратора Заказчика.

6.1.4.      По результатам решения контрольного примера должен быть подготовлен Акт о передаче ПО в опытную эксплуатацию.

6.1.5.      В случае несоответствия функциональных возможностей ПО требованиям ТЗ Исполнитель выполняет устранение замечаний в рамках общей стоимости разработки АС.

6.1.6.       При возникновении дополнительных к ТЗ требований Заказчика, составляется дополнительное ТЗ на доработку.

6.1.7.      Наличие дополнительных требований Заказчика не должно являться основанием отказа от подписания Акта о передаче ПО в опытную эксплуатацию.

6.1.8.      После передачи ПО в опытную эксплуатацию, по согласованному с Заказчиком Графику внедрения, Исполнитель производит краткое обучение персонала Заказчика работе с ПО и передает Инструкцию по работе с ПО на каждую подситему.

6.1.9.      При внедрении ПО (опытной эксплуатации) Заказчик осуществляет:

-        ввод необходимой НСИ;

-        ввод фактических данных;

-        формирование отчетности и проверку результатов работы.

6.1.10.  В процессе внедрения Исполнитель должен оказывать помощь Заказчику в рамках Графика внедрения.

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

6.2.Порядок дальнейшего сопровождения задач АС "СБЫТ".

6.2.1.      После сдачи ПО в эксплуатацию, дополнительные доработки и пожелания Заказчика могут быть реализованы по согласованному с Заказчиком ТЗ.

В ТЗ должна быть указана трудоемкость и стоимость работ по реализации дополнительных требований.

6.2.2.      Исполнитель обязуется поддерживать телефонную "горячую линию" по сопровождению программного обеспечения.

6.2.3.      По желанию Заказчика, Исполнитель может осуществлять сопровождение программного обеспечения непосредственно у Заказчика, которое должно производиться на основании дополнительного договора по сопровождению ПО.

6.2.4.       Ошибки, выявленные Заказчиком в течение полугода с момента передачи ПО в эксплуатацию, должны устраняться Исполнителем оперативно и бесплатно.

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

6.2.5.      Заказчик, в течении года после покупки 1С: Предприятие, имеет право на бесплатное получение всех обновлений от фирмы 1С, связанное с развитием программ 1С и изменением законодательства.  Установка изменений должна производиться силами АСУ Заказчика.

6.2.6.      Исполнитель гарантирует сохранение конфиденциальности содержания баз данных Заказчика и любой другой информации, полученной от Заказчика в процессе разработки, внедрения или сопровождения АС.

Технический проект:

УТВЕРЖДАЮ                                                                   ПРЕДСТАВЛЯЮ НА УТВЕРЖДЕНИЕ

"     "______________ 2010 г.                                             "     "_______________ 2010 г.

Приложение к техническому заданию  от «____»  ________ 2010

Автоматизированная

система «СБЫТ».

Технический проект

На  листах

Действует с «__» ____________ 2010 г.

Оглавление

Справочники. 3

Счетчики. 3

Тарифы.. 3

Подстанции. 3

Варианты штрафных санкций. 3

Перечисления. 4

Виды начислений. 4

Регистры сведений. 4

Значение Тарифов. 4

Тарифы абонентов. 4

ПоказанияСчетчиков. 5

Регистры накопления. 5

Потребление энергии. 5

Документы.. 6

Договор с абонентом.. 6

Потребленная Энергия. 6

Квитанция. 7

Начисление штрафных санкций. 9

Обработки. 10

Получение данных из системы АСКУЭ. 10

Получение данных из платежной системы.. 11

Справочники

Счетчики

Реквизиты:

Тарифы

Реквизиты: нет

Подстанции

Реквизиты: нет

Варианты штрафных санкций

Реквизиты: нет

Перечисления

Виды начислений

Значения:

Регистры сведений

Сроки действия договоров

Периодичность : Непериодический

Назначение: Предназначен для хранения сроков действия договоров с абонентами

Измерения

Ресурсы

Значение Тарифов

Периодичность : День

Назначение: Предназначен для хранения тарифов и дат, с которых тарифы начинают действовать их действия

Измерения

Ресурсы

Тарифы абонентов

Периодичность : День

Назначение:  Предназначен для хранения тарифов назначенных абоненту согласно договорам

Измерения

Ресурсы

ПоказанияСчетчиков

Периодичность : День

Назначение: Предназначен для хранения показаний счетчиков для последующего начисления оплаты

Измерения

Ресурсы

Регистры накопления

Потребление энергии

Назначение: Предназначен для хранения информации о потреблении энергии для последующего начисления оплаты

Тип регистра: оборотный

Измерения

Ресурсы

Документы

Договор с абонентом

Назначение: Предназначен для отражения факта заключения договора с абонентом

Табличная часть: Счетчики и Тарифы

Проведение документа

Документ проводится:

-  по регистру сведений «Показания счетчиков» куда прописывает счетчики абонента и начальные показания счетчиков;

- по регистру сведений «Тарифы абонентов» куда прописывает тариф установленный абоненту с даты начала действия договора

- по регистру сведений «Сроки действия договоров» куда прописывает договор , дата начала действия и дату окончания действия договора

Потребленная Энергия

Назначение: Предназначен для отражения показаний счетчиков на определенную дату

Заполнение документа

Документ может заполнятся двумя способами: ручным вводом и путем вызова обработки «Получение данных из системы АСКУЭ» 

Табличная часть: Показания счетчиков

Проведение документа

Документ проводится:

-  по регистру сведений «Показания счетчиков» куда прописывает показания счетчиков на дату документа;

- по регистру накоплений «Потребленная энергия по следующему алгоритму:

1. Берутся показания счетчиков из регистра сведений «Показания счетчиков» на дату документа и предыдущее значения показания счетчиков.

2. Разницы значений показаний заносятся в соответствующие  ресурсы регистра накопления.

Печатные формы

Реестр показаний счетчиков

Квитанция

Назначение: Предназначен для отражения начислений абонентам

Заполнение документа

Документ может заполнятся двумя способами: ручным вводом и путем вызова обработки «начисление оплаты» 

Табличная часть: Показания счетчиков

Проведение документа

Документ проводится:

-  по плану счетов хозрасчетный :

 - по плану счетов налоговый :

Печатные формы

Реестр начислений

Квитанция на оплату со штрих кодом

Штрих-код формируется при помощи шрифта «Infograftbarcode»

Алгоритм формирования  Строка «0000»+Код договора абонента+Начислено

Макет квитанции прилагается в файле КВ_1.mxl

Алгоритм заполнения

Документ заполняется на основании справочника «Договора контрагентов» .  

1. Из справочника выбираются договоры, у которых, согласно регистра сведений «Сроки действия договоров»  ДатаНачала меньше даты документа и ДатаОкончания больше даты документа;
2. Выбираются счетчики соответствующие этим договорам;
3. Для счетчиков определяется потребление энергии как оборот по регистру накопления «Потребление энергии» за период между датой документа и датой предыдущего документа, если дата предыдущего документа неизвестна, то берется весь оборот по регистру. Полученное значение записывается в поле «ПотребленнаяЭнергия»
4. Устанавливается тариф согласно договора и значение тарифа на дату документа ;
5. Устанавливается вид начисления «По показаниям счетчика»;
6. Рассчитывается Поле Начислено как произведение  ПотребленнаяЭнергия на ЗначениеТарифа.

Алгоритм проведения

Для каждой строки табличной части  «Показания счетчиков» должны быть сделаны следующие проводки:

1.

Дт. 62.01 с аналитикой СубконтоДт1 – Контрагент, СубконтоДт2 -  Договор контрагента

Кт. 90.01 с аналитикой СубконтоКт1 – Номенклатура.НоменклатурнаяГруппа, СубконтоКт2 – Номенклатура.СтавкаНДС.

Сумма проводки – значение реквизита «Начислено»;

2.

Если есть Кредитовое сальдо По счету 62.02, то проводится зачет аванса с проводкой 

Дт. 62.02 с аналитикой СубконтоДт1 – Контрагент, СубконтоДт2 -  Договор контрагента

Кт. 62.01 с аналитикой СубконтоКт1 – Контрагент, СубконтоКт2 -  Договор контрагента

Сумма проводки – минимальное значение из кредитового сальдо по счету 62.02 и значения реквизита  «начислено»)

3.

Дт. 90.03 с аналитикой СубконтоДт1 – Номенклатура.НоменклатурнаяГруппа, СубконтоДт2 – Номенклатура.СтавкаНДС

Кт. 62.01 с аналитикой СубконтоКт1 – Контрагент, СубконтоКт2 -  Договор контрагента

Сумма проводки =  «Начисленно»* СтавкаНДС/(100+ставкаНДС), где СтавкаНДС  - «Номенклатура.СтавкаНДС»

Начисление штрафных санкций

Назначение: Предназначен для отражения начислений штрафов абонентам

Заполнение документа

Документ может заполнятся двумя способами: ручным вводом и путем вызова обработки «начисление штрафов                » 

Табличная часть: Показания счетчиков

Проведение документа

Документ проводится:

-  по плану счетов хозрасчетный :

 - по плану счетов налоговый :

Печатные формы

Реестр начислений

Квитанция на оплату со штрих кодом

Штрих-код формируется при помощи шрифта «Infograftbarcode»

Алгоритм формирования  Строка «0000»+Код договора абонента+Начислено

Макет квитанции прилагается в файле КВ_1.mxl

Алгоритм проведения

Для каждой строки табличной части  «Показания счетчиков» должны быть сделаны следующие проводки:

1.

Дт. 62.01 с аналитикой СубконтоДт1 – Контрагент, СубконтоДт2 -  Договор контрагента

Кт. 91.01 с аналитикой СубконтоКт1 – Прочие доходы.

Сумма проводки – значение реквизита «Начислено»;

Обработки

Получение данных из системы АСКУЭ

Формат файла передачи данных – DBF;

Структура файла передачи данных:

Реквизиты обработки

Алгоритм обработки:

1. Создать таблицу значений со структурой:

1. Выбрать строки файла передачи данных
2. Начать цикл по строкам файла передачи данных
3. Прочитать строку файла передачи данных
4. Получить из строки файла передачи данных код счетчика
5. Найти по коду соответствующий элемент в справочнике «счетчики», если элемент не найден, то выдать сообщение « Не найден счетчик с кодом …» 
6. Если элемент найден, то добавить строку в таблицу значений, где : «счетчик» -  найденный элемент, «ПоказанияДень» - «Day», «ПоказанияНочь» - «Night»
7. После получения последний строки файла передачи данных окончить  цикл
8. Если обработка вызвана из документа «Потребленная Энергия» и число строк

 в таблице значений больше 0 то записать содержимое таблицы значений в табличную часть документа и провести документ.

1. Если в таблице значений есть строки и обработка не вызвана из документа «Потребленная Энергия», то создать документ «Потребленная Энергия» с датой равной текущей дате и затем провести документ.

Получение данных из платежной системы

Формат файла передачи данных – DBF;

Структура файла передачи данных:

Реквизиты обработки

Алгоритм обработки:

1. Создать таблицу значений со структурой:

1. Выбрать строки файла передачи данных
2. Начать цикл по строкам файла передачи данных
3. Прочитать строку файла передачи данных
4. Получить из строки файла передачи данных код договора
5. Найти по коду соответствующий элемент в справочнике «Договоры контрагентов», если элемент не найден, то выдать сообщение « Не найден договор с кодом …» 
6. Если элемент найден, то добавить строку в таблицу значений, где : «Договор» -  найденный элемент, «Дата» - «Data_plat», «НомерПлатежа» - «Nomer_plat», «Сумма» - «Summa_plat»
7. После получения последний строки файла передачи данных окончить  цикл
8. Для каждой строки таблицы значения создать документ «Платежное ордер поступление денежных средств». При создании документа сделать проверку наличия в системе документа с такой датой и таким номером входящего документа. Если документ присутствует в системе, то документ не создается.
9. Правила заполнения реквизитов документа:

1. Добавить строку в табличную часть «Расшифровка Платежа»

1. Записать и провести документ