Технічне завдання на доопрацювання системи. Як грамотно скласти технічне завдання програмісту
Наші фахівці допомогли замовнику скласти ТЗ - технічне завдання на модернізацію системи вентиляції.
Детальніше під катом.
Технічне завдання
на модернізацію технологічного обладнання вентиляційних систем корпусу лабораторій №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
Призначення та цілі створення системи
Призначення системи
Розроблена автоматизована система призначена для автоматизації процесів збуту підприємства.
Цілі створення системи
Цілі створення автоматизованої системи
Цілями розробки «АС ЗБУТ» є:
- 3. Характеристика об'єкта автоматизації
3.1 Бізнес процеси підприємства
3.1. 1 Бізнес процес «Укладання договору»
3.1.2. Бізнес процес «Нарахування оплати»
- 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. Підсистеми зв'язку із системою АСКУЕ має виконувати такі функції:
Отримання даних про здійснені платежі абонентами за електроенергію через платіжні термінали.
- 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
Перерахування. 4
Види нарахувань. 4
Регістри інформації. 4
Значення тарифів. 4
Тарифи абонентів. 4
Показання лічильників. 5
Регістри нагромадження. 5
Споживання енергії. 5
Документи.. 6
Договір з абонентом.
Споживана Енергія. 6
Квитанція. 7
Нарахування штрафних санкцій. 9
Обробки. 10
Отримання даних із системи АСКУЕ. 10
Отримання даних з платіжної системи.. 11
Довідники
Лічильники
Реквізити:
Тарифи
Реквізити: ні
Варіанти штрафних санкцій
Реквізити: ні
Перерахування
Види нарахувань
Значення:
Реєстри відомостей
Строки дії договорів
Періодичність: Неперіодичний
Призначення: Призначений для зберігання термінів дії договорів із абонентами
Вимірювання
Значення тарифів
Періодичність: День
Призначення: Призначений для зберігання тарифів та дат, з яких тарифи починають діяти.
Вимірювання
|
Реквізит |
Призначення |
|
|
Вартість денного тарифу |
||
|
Вартість нічного тарифу (може бути не заданий) |
Тарифи абонентів
Періодичність: День
Призначення: Призначений для зберігання тарифів, призначених абоненту згідно договорів
Вимірювання
|
Реквізит |
Призначення |
|
|
Довідник Тарифи |
Тариф абонента |
Показання лічильників
Періодичність: День
Призначення: Призначений для зберігання показань лічильників для подальшого нарахування оплати
Вимірювання
|
Реквізит |
Призначення |
|
|
ПоказанняДень |
Показ лічильника |
|
|
ПоказанняНіч |
Показ лічильника |
Регістри накопичення
Споживання енергії
Призначення: Призначений для зберігання інформації про споживання енергії для подальшого нарахування оплати
Тип регістру: оборотний
Вимірювання
Документи
Договір з абонентом
Призначення: Призначений для відображення факту укладання договору з абонентом
|
Реквізит |
Призначення |
|
|
Контрагент |
Довідник Контрагенти |
|
|
ДоговірКонтрагенту |
||
|
Довідник Тарифи |
||
|
Встановлена потужність |
Зберігання встановленої потужності абонента у КВТ |
|
|
ДатаПочаткуДії |
Дата з якою діє договір |
|
|
ДатаЗакінчення Дії |
Дата закінчення дії договору |
|
|
Організація |
Довідник Організації |
|
|
ВаріантНарахуванняШтрафів |
||
|
Номенклатура |
Довідник Номенклатура |
|
|
Ручне Коригування |
Ознака ручного коригування проводок документа |
Таблична частина: Лічильники та Тарифи
Проведення документа
Документ проводиться:
За регістром відомостей «Покази лічильників» куди прописує лічильники абонента та початкові показання лічильників;
За регістром відомостей «Тарифи абонентів» кудись прописує тариф встановлений абоненту з дати початку дії договору
За регістром відомостей «Терміни дії договорів» куди прописує договір, дата початку дії та дату закінчення дії договору
Споживана Енергія
Призначення: Призначений для відображення показань лічильників на дату
Заповнення документа
Документ може заповнюватися двома способами: ручним введенням та шляхом виклику обробки «Отримання даних із системи АСКУЕ»
Проведення документа
Документ проводиться:
За регістром відомостей «Покази лічильників» куди прописує показання лічильників на дату документа;
За регістром накопичень «Споживана енергія за наступним алгоритмом:
1. Беруться показання лічильників із регістра відомостей «Покази лічильників» на дату документа та попереднє значення показання лічильників.
2. Різниці значень показань заносяться до відповідних ресурсів регістру накопичення.
Друковані форми
Реєстр показань лічильників
Квитанція
Призначення: Призначений для відображення нарахувань абонентам
Заповнення документа
Документ може заповнюватися двома способами: ручним введенням та шляхом виклику обробки «нарахування оплати»
Таблична частина: Покази лічильників
|
Реквізит |
Призначення |
|
|
Контрагент |
Довідник Контрагенти |
|
|
ДоговірКонтрагенту |
Довідник Договори контрагентів |
|
|
Номенклатура |
Довідник Номенклатура |
|
|
Довідник Тарифи |
Тариф абонента згідно з договором |
|
|
Довідник Лічильники |
||
|
ВидНарахування |
Перелік ВидиНарахувань |
|
|
Потреба Енергія |
Спожитаенергія |
|
|
Значення тарифу |
Значення тарифу на дату документа |
|
|
Нараховано |
Сума нарахована абоненту |
Проведення документа
Документ проводиться:
За планом рахунків податковий:
Друковані форми
Реєстр нарахувань
Алгоритм заповнення
Документ заповнюється на підставі довідника «Договору контрагентів».
- З довідника вибираються договори, у яких, згідно з регістром відомостей «Терміни дії договорів» ДатаПочатку менше дати документа та ДатаЗакінчення більше дати документа;
- Вибираються лічильники, що відповідають цим договорам;
- Для лічильників визначається споживання енергії як оборот за регістром накопичення «Споживання енергії» за період між датою документа та датою попереднього документа, якщо дата попереднього документа невідома, то береться весь оборот по регістру. Отримане значення записується в полі «Потрібна Енергія»
- Встановлюється тариф згідно з договором та значення тарифу на дату документа;
- Встановлюється вид нарахування "За показаннями лічильника";
- Розраховується Поле Нараховано як твір Споживана Енергія на значення тарифу.
Алгоритм проведення
Кт. 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_лічильника в системі АСКУЕ |
||||
|
Покази лічильника за денним тарифом |
||||
|
Покази лічильника за нічним тарифом |
Реквізити обробки
Алгоритм обробки:
- Отримати з рядка файлу передачі даних код лічильника
- Знайти за кодом відповідний елемент у довіднику «лічильники», якщо елемент не знайдено, то видати повідомлення «Не знайдено лічильник з кодом …»
- Якщо елемент знайдено, то додати рядок до таблиці значень, де: «лічильник» - знайдений елемент, «ПоказиДень» - «Day», «Покази Ніч» - «Night»
- Якщо обробка викликана з документа «Споживана Енергія» та кількість рядків
у таблиці значень більше 0, то записати вміст таблиці значень у табличну частину документа і провести документ.
- Якщо в таблиці значень є рядки та обробка не викликана з документа «Споживана Енергія», то створити документ «Споживана Енергія» з датою, що дорівнює поточній даті, а потім провести документ.
Отримання даних із платіжної системи
Формат файлу передачі даних – DBF;
Структура файлу даних:
Реквізити обробки
Алгоритм обробки:
- Створити таблицю значень зі структурою:
- Вибрати рядки файлу передачі даних
- Почати цикл за рядками файлу передачі
- Прочитати рядок файлу передачі даних
- Отримати з рядка файлу передачі даних код договору
- Знайти за кодом відповідний елемент у довіднику «Договори контрагентів», якщо елемент не знайдено, то видати повідомлення «Не знайдено договору з кодом...»
- Якщо елемент знайдено, то додати рядок до таблиці значень, де: «Договір» - знайдений елемент, «Дата» - «Data_plat», «НомерПлатежа» - «Nomer_plat», «Сума» - «Summa_plat»
- Після отримання останнього рядка файлу передачі даних закінчити цикл
- Для кожного рядка таблиці значення створити документ «Платіжне ордер надходження коштів». Під час створення документа зробити перевірку наявності в системі документа з такою датою та таким номером вхідного документа. Якщо документ є у системі, то документ не створюється.
- Правила заповнення реквізитів документа:
|
Реквізит |
Значення заповнення |
|
вид операції |
|
|
РядокТаблиціЗначний.Дата |
|
|
Номер вхідного документа |
РядокТаблиціЗначний.НомерПлатежа |
|
Дата вхідного документа |
РядокТаблиціЗначний.Дата |
|
Договір контрагента |
РядокТаблиціЗначний.Договір |
Багато хто стикається з тим, що досить складно пояснити коротко і ясно те, що ми хочемо у повсякденному житті. А коли треба дати завдання фахівцеві написати програму для організації чи ІП з урахуванням особливостей і власних побажань щодо функціоналу, то можна взагалі «зависнути».
Хто має писати ТЗ?
Безумовно техзавдання має надати замовник, тому що він точно знає свої потреби і можливості. Але, як показує практика, переважна більшість клієнтів не є компетентними в області 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С
Структура техзавдання регламентується ГОСТ 34602-89. У цьому документі містяться чіткі вимоги щодо кількості та послідовності блоків інформації у ТЗ. У той же час, там немає суворих стандартів за способами викладу. Така ситуація містить великий потенціал для вирішення складних завдань і одночасно може спричинити безліч помилок при складанні документа. Найчастіше зустрічаються такі неточності:
- Повторення деяких розділів у різних інтерпретаціях.
- Інформація надається безладно. В ідеалі вона має ставитись до певної структури, наприклад бізнес-процесів або модулів системи.
- Інформація у різних розділах подається з різним ступенем деталізації.
Все це перешкоджає розумінню замовником інформації, що викладена у ТЗ. Це ускладнює процес співробітництва, роблячи його більш трудомістким.
Після перегляду замовником зразок ТЗ на доопрацювання 1С може змінитися і не завжди на краще. Це своє чергу зазвичай заважає програмістам правильно сприймати інформацію. Особливо це стосується фахівців із невеликим досвідом. На цьому етапі часто виникають такі помилки:
- Вимоги різних розділів суперечать одне одному.
- Формулювання виявляються неточними.
- Подекуди інформація надмірно деталізована.
Позбутися всіх перелічених помилок просто. Потрібно орієнтуватися насамперед на результат, а не на ретельне прописування формулювань. Варто пам'ятати, що ТЗ описує функціонал проекту, його основні параметри та призначення.
Як уникнути помилок під час розробки ТЗ?
Основне правило, яке стосується всіх наступних рекомендацій, - формулювання повинні бути конкретними. Для цього слід використовувати посилання на ГОСТи, інші нормативні документи. Це дозволяє виконавцю та замовнику сприймати інформацію в одному ключі.
Приклад технічного завдання на доопрацювання 1С передбачає використання мови галузі бізнесу, на яку виконується проект. Це потрібно насамперед для замовника. При цьому в тексті не варто використовувати будь-які порівняння, оскільки вони можуть бути витлумачені по-різному.
Основні правила при складанні технічного завдання на розробку звіту та інших елементів 1С:
- ТЗ створюється спільно виконавцем та замовником.
- До роботи програмістів мають бути лише об'єктивні вимоги. Для успішної розробки проекту суб'єктивне бачення замовника має бути зведене до мінімуму.
- Потрібно докладно описувати результат, який потрібний замовнику. При цьому в прикладі технічного завдання на розробку конфігурації 1С необхідно прописувати всі параметри, якими повинен працювати елемент. Інакше результат може сильно відрізнятиметься від бажаного.
- Ризики виконавця та замовника повинні бути приблизно рівні та зведені до мінімуму.
- Не можна застосовувати терміни, що використовуються у діловому спілкуванні та не застосовуються у конкретній галузі.
Для створення ТЗ на розробку звіту в 1С чи іншого елемента аналітик має знати всі особливості сфери діяльності замовника. У вимогах потрібно надавати лише корисну інформацію, яка стане в нагоді виконавцю. Враховуючи що особливу увагутут приділяється кінцевим завданням, які має вирішувати програмне забезпечення, єдиного прикладу технічного завдання немає.
Небезпека неправильного складання ТЗ
Перелічені вище помилки можуть призвести до збільшення часу, що витрачається створення системи. Це спричиняє зайві витрати та невдоволення. Технічне завдання на розробку бази даних або іншої 1С конфігурації повинні становити досвідчені фахівці. Від того, наскільки цей документ є доступним для розуміння, залежить вигода всіх учасників. Замовник отримує ефективну автоматизовану систему для вирішення бізнес-завдань. При цьому підрядник має ще один задоволений клієнт. Власникам бізнесу потрібно якнайуважніше підходити до вибору компаній-партнерів 1С, адже від того, наскільки якісно складено технічне завдання на доопрацювання, багато в чому залежить ефективність організації.
