Наши специалисты помогли заказчику составить ТЗ техническое задание на модернизацию системы вентиляции .

Подробнее под катом..

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

на модернизацию технологического оборудования вентиляционных систем корпуса лабораторий №451,452 корпуса 17 по адресу: г. Москва

1. Общие положения

1.1. Настоящее техническое задание предусматривает выполнение работ по модернизации технологического оборудования, систем управления и автоматики вентиляционных установок корпуса, лабораторий №451,452 корпуса 17.

1.2. Для выполнения работ разработать рабочую документацию разделов марок АОВ, ЭМ, ХС, АХС, АК, которую согласовать установленным порядком.

1.3. Работы выполнять с соблюдением требований нормативно-технической документации.

1.4. По окончании работ предъявить исполнительную документацию, выполненную в соответствии с требованиями ГОСТ и СНиП.

1.5. Сдать выполненную работу Заказчику.

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

2. Технические требования

2.1. Модернизация узлов регулирования тепло, холодоснабжения вентиляционных установок.

2.1.1. Узлы регулирования теплоснабжения.

Модернизации подлежат:

· узлы регулирования теплоснабжения первого подогрева вентиляционных установок К1, К2, К2а, К4 корпуса МИК-В, П2, П6 лаборатории №452, П1 лаборатории.

· узлы регулирования теплоснабжения второго подогрева вентиляционных установок К1, К2, К2а корпуса МИК-В.

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

Состав оборудования монтируемых узлов регулирования, а также.используемое оборудование указано в приложении №1.

Провести гидравлические испытания контуров подогрева и калориферов вентиляционных установок с оформлением акта гидравлических испытаний.

Выполнить покраску трубопроводов и теплоизоляционные работы.

2.1.2.Узлы регулирования холодоснабжения вентиляционных установок.

Модернизации подлежат узлы холодоснабжения вентиляционных установок К1, К2, К2а, К4 корпуса МИК-В, П2, П6 лаборатории «452, П1 лаборатории №451.

Состав работ:

· замена терморегулирующих вентилей узлов регулирования холодоснабжения;

· демонтаж/монтаж вентилятора компрессорно-конденсаторного блока К1;

· демонтаж/монтаж фильтров-осушителей компрессорно-конденсаторных блоков К1, К2;

· демонтаж/монтаж испарителя вентиляционной установки К4;

· опрессовка в среде инертных газов, ваккумирование, заправка фреоном контуров холодоснабжения;

· восстановление теплоизоляции трубопроводов.

2.1.3. Узлы подпитки контуров увлажнения.

На узлах подпитки камер орошения кондиционеров К1, К2, К2а установить фильтры очистки холодной воды.

2.2. Шкафы управления и автоматики вентиляционных установок.

Подлежат демонтажу шкафы управления вентиляционными установками К1, К2, К2а, К4, РУ3, В1, В2, В3, В6, В7, В8 корпуса МИК-В, П2, П6, В1, В2, В3 лаборатории №451, П1, В1 лаборатории № 452.

Компоновка вновь устанавливаемых щитов управления:

ШУА К1 – шкаф управления и автоматики вентиляционной установкой и компрессорно-конденсаторным блоком (ККБ) кондиционера К1 (МИК-В);

ШУА К2 – шкаф управления и автоматики вентиляционной установкой и ККБ кондиционера К2 (МИК-В);

ШУА К2 – шкаф управления и автоматики вентиляционной установкой и ККБ кондиционера К2а (МИК-В);

ШУА К4 – шкаф управления и автоматики вентиляционной установкой и ККБ кондиционера К4 (МИК-В);

ШУВ– шкаф управления вытяжными установками РУ3, В1, В2, В3, В6, В7, В8 (МИК-В);

ШУА П2,П6 – шкаф управления и автоматики вентиляционными установками и компрессорно-конденсаторными блоками П2, П6 (лаборатория №452);

ШУВ– шкаф управления вытяжными установками В1, В2, В3 (лаборатория №452);

ШУА П1,В1 – шкаф управления и автоматики вентиляционными установками П1, В1 (лаборатория №451).

Модернизированные шкафы управления должны обеспечивать:

· выбор, с лицевой панели шкафа, режима управления вентиляционными установками (ручной/автоматический);

· световую сигнализацию штатных и аварийных режимов работы технологического оборудования вентиляционных установок (работа/авария);

· отключения вентиляционных установок при возникновении пожара;

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

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

2.3. Система автоматизации и диспетчеризации

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

2.3.1. Система автоматики.

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

Локальная автоматика вентиляционных систем должна предусматривать:

· регулирование температуры приточного воздуха на выходе вентиляционной установки или, при необходимости, температуры вытяжного воздуха из обслуживаемого помещения;

· регулирование влажности приточного воздуха;

· остановку вентиляторов и закрытие воздушных клапанов при срабатывании пожарной сигнализации;

· отключение увлажнения воздуха кондиционера при остановке его вентилятора;

· открытие и закрытие воздушного клапана соответственно при пуске и остановке вентилятора;

· автоматический прогрев калориферов перед запуском систем в зимнем режиме;

· защита от замораживания калориферов по воздуху и по воде (отключение вентилятора, закрытие воздушной заслонки, открытие на 100% клапана подогрева);

· отключение вентилятора при отсутствии перепада давления;

· контроль загрязненности фильтров установок.

Дистанционное воздействие на локальную автоматику с АРМ определяется в следующем объеме:

· изменение уставок регуляторов температуры и влажности;

· включение/отключение установок.

Существующее периферийное оборудование системы автоматики подлежит поверке, очистке и дальнейшему использованию в следующем порядке:

· датчики температуры и влажности вентиляционных установок подлежат поверке;

· датчики реле перепада давления подлежат проверке, очистке;

· термостаты защиты калориферов вентиляционных установок от замораживания подлежат замене.

· приводы регулирующих клапанов узлов регулирования подлежат замене в соответствие с п.2.1.1.

· приводы воздушных клапанов подлежат проверке и дальнейшему использованию;

Для управления рециркуляцией кондиционера К1 заменить двухпозиционные приводы воздушных клапанов на клапана с управляющим сигналом 0..10В.

2.3.2. Система диспетчеризации.

В состав системы диспетчеризации включить следующие компоненты:

· комплекс измерительных устройств, исполнительных механизмов и средств автоматизации на базе программно-технических средств «Honeywell »;

· многофункциональная кабельная система;

· комплекс программно-технических средств диспетчерского пункта.

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

· графическое изображение установок с датчиками температуры и влажности, термостатами от замораживания, реле дифференциального давления, регулирующими клапанами, увлажнителями воздуха, воздушными клапанами;

· номера установок;

· показания датчиков температуры, влажности;

· показания датчиков реле дифференциального давления;

· показания положения регулирующих клапанов 0..100%;

· режим «работа/останов» вентиляторов;

· режим «работа/ останов» насосов;

· положение воздушных клапанов «открыт/закрыт»;

· остановка систем при срабатывании пожарной сигнализации;

· остановка систем при возникновении угрозы замораживания калорифера;

· остановка установки при отсутствии перепада давления на вентиляторе;

· отключение увлажнителя воздуха при остановке вентилятора кондиционера;

· работа систем по заданному временному графику или без него;

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

· регистрация аварий и нештатных ситуаций в журнале сообщений;

· журнал регистрации параметров на текущее время с указанием наименования контролируемых параметров, единиц измерения, номера контроллера и канала ввода/вывода.

2.3.3. Электропитание системы автоматизации и диспетчеризации должно осуществляться от сети переменного тока напряжением 380/220 В, частотой 50 Гц с использованием источников бесперебойного питания на аккумуляторных батареях и обеспечиваться как питание электроприемников первой категории

В жизни очень часто бывает так, что человек не может объяснить, что хочет, даже в бытовых вещах. Когда дело доходит до объяснения программисту своих «хотелок», человек просто впадает в ступор.

В идеале ТЗ должен составлять заказчик — только он знает, что ему нужно. Но на практике из-за низкой компетенции заказчика в сфере 1С часто это приходится делать исполнителю. Заказчик устно озвучивает свои потребности, а программист(консультант) оформляет это в письменной форме.

Зачем нужно техническое задание?

Любые , в идеале, должны сопровождаться техническим заданием. Это, во-первых, четкое определение задачи, сроков и метода выполнения. Во-вторых, это документ, с помощью которого решаются все спорные моменты в будущем. Писать ТЗ или нет — дело, конечно, Ваше, лично мне ТЗ облегчает работу и общение с клиентом.

Получите 267 видеоуроков по 1С бесплатно:

Что должно содержать в себе техническое задание?

Тех. задание обязательно должно содержать в себе:

• цель — задача, которую мы решим, реализуя данное ТЗ;
• описание — краткое изложение предстоящих доработок;
• способ реализации — подробное описание методов решения цели. В этом пункте необходимо описать все нюансы задачи на языке программиста: какие , создаем/редактируем, как должен выглядеть интерфейс и т.д. Если Вы не владеете «языком программиста», но «что-то слышали», лучше не пытаться писать на техническом языке — получается достаточно весело. Описание должно быть однозначным и не вызывать вопросов. Также может содержать в себе пример реализации подобного решения в другой сфере;
• оценка работы — очень важный пункт, описание трудозатрат.

Также существуют государственные стандарты к написанию ТЗ — ГОСТы. На практике мало где применяются, но бывает, заказчик настаивает на этом.

По опыту, при сдаче работ очень часто возникают ситуации вроде «а мы Вам тогда-то говорили же…», что не очень приятно, и зачастую приходится переделывать работу целиком. Поэтому хорошо написанное ТЗ сильно облегчает жизнь обеих сторон.

Примеры и образцы ТЗ для 1С

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

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

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

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

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

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

На листах

" _" ______________ 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. Разницы значений показаний заносятся в соответствующие ресурсы регистра накопления.

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

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

Квитанция

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

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

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

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

Реквизит		Назначение
Контрагент	Справочник Контрагенты
ДоговорКонтрагента	Справочник Договоры контрагентов
Номенклатура	Справочник Номенклатура
	Справочник Тарифы	Тариф абонента согласно договора
	Справочник Счетчики
ВидНачисления	Перечисление ВидыНачислений
ПотребленнаяЭнергия		Потребленнаяэненргия
Значение тарифа		Значение тарифа на дату документа
Начисленно		Сумма начисленная абоненту

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реквизит		Назначение
Контрагент	Справочник Контрагенты
ДоговорКонтрагента	Справочник Договоры контрагентов
ВариантНачисленияШтрафов	Справочник Варианты Начисления штрафных санкций
Начисленно		Сумма начисленная абоненту

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обработки

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

			Точность	Назначение
				Код счетчика в системе «Сбыт», совадает с ID_счетчика в системе АСКУЭ
				Показания счетчика по дневному тарифу
				Показания счетчика по ночному тарифу

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

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

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

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

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

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

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

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

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

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

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

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

Реквизит	Значение заполненя
Вид операции
	СтрокаТаблицыЗначний.Дата
Номер входящего документа	СтрокаТаблицыЗначний.НомерПлатежа
Дата входящего документа	СтрокаТаблицыЗначний.Дата
Договор контрагента	СтрокаТаблицыЗначний.Договор

Многие сталкиваются с тем, что достаточно сложно объяснить коротко и ясно то, что мы хотим в повседневной жизни. А уж когда надо дать задание специалисту написать программу для организации или ИП с учетом особенностей и собственных пожеланий по функционалу, то можно вообще «зависнуть».

Кто должен писать ТЗ?

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

Для чего необходимо техзадание?

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

Это важный документ, потому как при возникновении каких-либо спорных вопросов грамотная разработка техзадания станет отправной точкой в переговорах.

Составлять ТЗ или нет - решает каждый для себя, но это точно не будет лишним: упростит общение с клиентом и придаст работе деловой и конкретный характер.



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

1. Цель/Задача. Сформулировать то, что должно быть реализовано в конечном итоге.

2. Описание. Вкратце изложить содержание планируемых доработок.

3. Способ реализации. Детально описать методы, с помощью которых должна быть достигнута цель. Следует прописать все особенности задачи на языке программиста: регистры, справочники (создать их или отредактировать); дизайн интерфейса и т.д. Для тех, кто не знаком и лишь что-то такое слышал про специфический язык программиста, советуем не делать ненужных попыток «заговорить» на техническом языке. Т.к. описание в идеале - это сухая констатация, исключающая неоднозначность и возможность возникновения лишних вопросов. Кроме этого этот пункт может включать в себя пример, как подобное программирование было уже исполнено где-то.

4. Оценка работы. Данный пункт очень важен - в нем нужно описать трудозатраты.

Еще два важных момента: есть утвержденные стандарты к написанию ТЗ - ГОСТы. Сейчас они редко используются, но некоторые клиенты могут по старинке просить использовать и их.

И второе, когда сдается работа может возникнуть и такое - «а мы же вроде как просили Вас сделать то-то и тогда-то...». Есть вероятность, что придется все начать делать с самого начала.

Поэтому, повторимся, что грамотно составленное ТЗ будет полезно как для заказчика, так и для исполнителя.

Пример ТЗ для программиста

Техническое задание 1С на доработку внешней обработки


Цель
Необходимо настроить выгрузку данных из 1С в АРМ банка.


Описание

В связи с переходом организации на конфигурацию 1С «Зарплата и кадры государственного учреждения» требуется разработка других обработок, которые осуществляли бы аналогичный функционал на новой конфигурации.

Выгрузка данных должна основываться на документах «ЗаявкаНаОткрытиеЛицевыхСчетовСотрудников» и «ВедомостьНаВыплатуЗарплатыВБанк».


Исходные данные

Имеющаяся обработка к конфигурации 1С «Зарплата бюджетного учреждения», осуществляющая выгрузку данных из документа «ЗаявкаНаОткрытиеЛицевыхСчетовСотрудников» и других справочников и регистров в файл DBF обмена данными с АРМ банка установленного образца.

Обработка выгружает данные в поля TAB_N, NAME, SERNUM, PASSCODE, PDAT, PWHR, BIRTHDAY, POSTINDEX, COUNTRY, CITY, STREET, REGION, BUILDING, CORP, FLAT, BPLACE, CITIZEN соответствующую информацию из конфигурации 1С, предварительно занесённую в указанный документ и другие учётные таблицы. Выгружаются табельный номер, ФИО сотрудника, его паспортные и адресные данные, день рождения и гражданство.


Способ реализации

Это будут внешние отчёты и обработки с использованием механизма расширений, если текущие параметры совместимости базы и возможности платформы позволят это сделать. При изменении конфигурации базы следует создать: справочники, документы, регистры.


Оценка работы

Потребуется 5 рабочих дней работы программиста.

От того, насколько точно составлено техническое задание на доработку 1С, напрямую зависит, будут ли решены поставленные перед разработчиками задачи. Вместе с тем при работе с таким документом существуют некоторые сложности. В широком понимании в ТЗ прописаны нормы при создании и модернизации автоматизированной системы (АС), а также порядок работ. Сюда же входит и свод стандартов запуска проекта. Это понимание роли технического задания продиктовано требованиями ГОСТ 19.201-78 и 34.602-89, согласно которым ведется разработка ТЗ для 1С. Есть и другое толкование значения этого документа, более приближенное к практике.

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

Каким должно быть ТЗ?

Любое техническое задание на разработку программы 1С создается исполнителем. Но этим занимается не программист, а аналитик. Это важный момент, поскольку документ должен быть составлен на языке, понятном клиенту, без узкоспециальных технических терминов. Когда все нюансы проекта учтены и информация сформулирована верно, ТЗ согласовывается со всеми заказчиками. В случае его принятия к работе подключаются программисты. При этом в документе должен быть четко очерчен желаемый результат. Это помогает разработчикам правильно поставить цель и сверяться с ней на разных этапах. Также большое внимание при составлении технического задания на доработку 1С стоит уделить формулировкам. Следует следить, чтобы они были достаточно конкретными и не предполагали иных толкований. Это первое, о чем нужно помнить при работе с ТЗ. Также нужно ответственно подойти к оформлению. Это касается и титульного листа документа.

Основные ошибки в техническом задании на разработку 1С

Структура техзадания регламентируется ГОСТ 34.602-89. В этом документе содержатся четкие требования по количеству и последовательности блоков информации в ТЗ. В то же время там нет строгих стандартов по способам изложения. Такая ситуация заключает в себе большой потенциал для решения сложных задач и одновременно может повлечь множество ошибок при составлении документа. Наиболее часто встречаются следующие неточности:

1. Повторение некоторых разделов в разных интерпретациях.
2. Информация дается беспорядочно. В идеале она должна относиться к определенной структуре, например бизнес-процессам или модулям системы.
3. Информация в разных разделах подается с разной степенью детализации.

Все это препятствует пониманию заказчиком информации, которая изложена в ТЗ. Это осложняет процесс сотрудничества, делая его более трудоемким.

После просмотра заказчиком образец ТЗ на доработку 1С может измениться и не всегда в лучшую сторону. Это в свою очередь обычно мешает программистам правильно воспринимать информацию. Особенно это касается специалистов с небольшим опытом. На этом этапе часто возникают следующие ошибки:

1. Требования разных разделов противоречат друг другу.
2. Формулировки оказываются неточными.
3. Местами информация излишне детализирована.

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

Как избежать ошибок при разработке ТЗ?

Основное правило, которое относится ко всем последующим рекомендациям, - формулировки должны быть конкретными. Для этого нужно использовать ссылки на ГОСТы, другие нормативные документы. Это позволяет исполнителю и заказчику воспринимать информацию в одном ключе.

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

Основные правила при составлении технического задания на разработку отчета и других элементов 1С:

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

Для создания ТЗ на разработку отчета в 1С или другого элемента аналитик должен знать все особенности сферы деятельности заказчика. В требованиях нужно давать только полезную информацию, которая пригодится исполнителю. Учитывая, что особое внимание здесь уделяется конечным задачам, которые должно решать программное обеспечение, единого примера технического задания не существует.

Опасность неверного составления ТЗ

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