Tehničke specifikacije za modifikaciju sistema. Kako kompetentno napisati tehničke specifikacije za programera

Naši stručnjaci pomogli su kupcu u sastavljanju Tehničke specifikacije za modernizaciju ventilacionog sistema.

Više detalja ispod reza..

Tehnički zadatak

za modernizaciju tehnološke opreme ventilacionih sistema laboratorijske zgrade br. 451.452, zgrada 17 na adresi: Moskva

1. Opšte odredbe

1.1. Ovim tehničkim zadatkom predviđeno je izvođenje radova na modernizaciji tehnološke opreme, sistema upravljanja i automatizacije ventilacionih jedinica zgrade, laboratorije broj 451.452 zgrade 17.

1.2. Za izvođenje radova izraditi radnu dokumentaciju za sekcije marki AOB, EM, XS, AHS, AK, koja se mora usaglasiti u skladu sa utvrđenom procedurom.

1.3. Radove izvoditi u skladu sa zahtjevima regulatorne i tehničke dokumentacije.

1.4. Po završetku radova, predočite gotovu dokumentaciju izrađenu u skladu sa zahtjevima GOST-a i SNiP-a.

1.5. Izvršeni posao predati Naručiocu.

1.6. Pojedine odredbe ove Tehničke specifikacije mogu biti razjašnjene u toku procesa rada u dogovoru sa Kupcem.

2. Tehnički zahtjevi

2.1. Modernizacija upravljačkih jedinica za grijanje i hlađenje ventilacijskih jedinica.

2.1.1. Kontrolne jedinice za opskrbu toplinom.

Modernizaciji su podvrgnuti:

· regulacione jedinice toplotne energije za prvo grejanje ventilacionih jedinica K1, K2, K2a, K4 zgrade MIK-V, P2, P6 laboratorije br. 452, P1 laboratorije.

· regulacione jedinice za dovod toplote za drugo grejanje ventilacionih jedinica K1, K2, K2a zgrade MIK-V.

Postojeće regulacijske jedinice za opskrbu toplinom podliježu demontaži, dok dio opreme upravljačkih jedinica (cirkulacijske pumpe, zaporni ventili) odgovara stanju i tehničke specifikacije, za upotrebu u montiranim upravljačkim jedinicama.

Sastav opreme instaliranih upravljačkih jedinica, kao i oprema koja se koristi, navedena je u Dodatku br. 1.

Izvršiti hidraulička ispitivanja krugova grijanja i grijača ventilacijskih jedinica uz izradu izvještaja o hidrauličkom ispitivanju.

Izvođenje farbanja cevovoda i termoizolacionih radova.

2.1.2 Jedinice za regulaciju dovoda hladnoće ventilacionih jedinica.

Modernizuju se rashladni uređaji ventilacionih jedinica K1, K2, K2a, K4 objekta MIK-V, P2, P6 laboratorije „452“, P1 laboratorije br. 451.

Obim posla:

· zamjena termostatskih ventila rashladnih jedinica;

· demontaža/montaža ventilatora kompresorsko-kondenzacijske jedinice K1;

· demontaža/montaža filter-sušača kompresorsko-kondenzacionih jedinica K1, K2;

· demontaža/montaža isparivača ventilacione jedinice K4;

· ispitivanje pritiska u okruženju inertnog gasa, usisavanje, dopunjavanje rashladnih krugova freonom;

· obnova toplotne izolacije cjevovoda.

2.1.3. Jedinice za napajanje za krugove ovlaživanja.

Ugradite filtere za prečišćavanje hladne vode na jedinicama za dopunu komora za navodnjavanje klima uređaja K1, K2, K2a.

2.2. Ormari za upravljanje i automatizaciju ventilacionih jedinica.

Upravljački ormani za ventilacione jedinice K1, K2, K2a, K4, RU3, V1, V2, V3, V6, V7, V8, zgrade MIK-V, P2, P6, V1, V2, V3 laboratorije br. 451, P1, V1 laboratorije br. 451 podliježu demontaži 452.

Izgled novoinstaliranih kontrolnih panela:

SHUA K1 – ormar za upravljanje i automatizaciju ventilacione jedinice i kompresorsko-kondenzacijske jedinice (KKB) klima uređaja K1 (MIK-V);

SHUA K2 – ormar za upravljanje i automatizaciju ventilacione jedinice i upravljačke jedinice za klima uređaj K2 (MIK-V);

SHUA K2 – ormar za upravljanje i automatizaciju ventilacione jedinice i upravljačke jedinice za klima uređaj K2a (MIK-V);

SHUA K4 – ormar za upravljanje i automatizaciju ventilacione jedinice i upravljačke jedinice za klima uređaj K4 (MIK-V);

SHUV – upravljački ormar za izduvne jedinice RU3, V1, V2, V3, V6, V7, V8 (MIK-V);

SHUA P2, P6 – ormar za upravljanje i automatizaciju ventilacionih jedinica i kompresorsko-kondenzacionih jedinica P2, P6 (laboratorij br. 452);

SHUV – upravljački ormar za izduvne jedinice V1, V2, V3 (laboratorij br. 452);

SHUA P1,V1 – ormar za upravljanje i automatizaciju ventilacionih jedinica P1, V1 (laboratorij br. 451).

Modernizovani upravljački ormani moraju da obezbede:

· izbor, sa prednje ploče ormana, načina upravljanja ventilacionim jedinicama (ručno/automatsko);

· svjetlosna signalizacija normalnog i vanrednog režima rada procesne opreme ventilacijskih jedinica (rad/hitna);

· gašenje ventilacionih jedinica u slučaju požara;

· automatsko aktiviranje zaštita i blokiranje rada opreme u slučaju vanrednih situacija.

Frekvencijski pretvarači za upravljanje elektromotorima ventilatora i pumpi su podložni daljoj upotrebi.

2.3. Sistem automatizacije i dispečerstva

Sistem automatizacije i dispečerstva je dizajniran za upravljanje i praćenje rada ventilacionih jedinica, kao i za prikupljanje, obradu, prezentaciju i skladištenje ulaznih informacija.

2.3.1. Sistem automatizacije.

Sistem automatizacije treba da obezbedi, u osnovi, autonoman rad ventilacionih jedinica, koji ne zahteva intervenciju osoblja za održavanje i prelazak, ako je potrebno, na ručni način rada menadžment. Za sve opcije upravljanja i bez obzira na stanje lokalnog regulatora, mora se održavati uvjet za automatsko gašenje općeg ventilacijskog sustava u slučaju požara. Isključivanje treba izvršiti pojedinačno za svaki sistem uz održavanje napajanja strujnih krugova zaštite od smrzavanja.

Lokalna automatizacija ventilacionih sistema treba da uključuje:

· regulisanje temperature dovodnog vazduha na izlazu iz ventilacione jedinice ili, po potrebi, temperature izlaznog vazduha iz servisirane prostorije;

· regulisanje vlažnosti dovodnog vazduha;

· zaustavljanje ventilatora i zatvaranje ventila za vazduh kada se aktivira požarni alarm;

· isključivanje ovlaživanja klima uređaja kada se ventilator zaustavi;

· otvaranje i zatvaranje ventila za vazduh, odnosno prilikom pokretanja i zaustavljanja ventilatora;

· automatsko zagrevanje grejača pre pokretanja sistema u zimskom režimu;

· zaštita od smrzavanja bojlera vazduha i vode (gašenje ventilatora, zatvaranje vazdušne zaklopke, otvaranje ventila za grejanje 100%);

· gašenje ventilatora u odsustvu pada pritiska;

· kontrola kontaminacije instalacionih filtera.

Daljinski uticaj na lokalnu automatizaciju sa automatizovanim radnim mestom određen je u sledećem obimu:

· promjena postavki regulatora temperature i vlažnosti;

· Omogućite/onemogućite postavke.

Postojeća periferna oprema sistema automatizacije podliježe verifikaciji, čišćenju i daljnjoj upotrebi sljedećim redoslijedom:

· senzori temperature i vlažnosti ventilacionih jedinica podležu verifikaciji;

· senzori diferencijalnog pritiska moraju se provjeriti i očistiti;

· Termostati za zaštitu grejača ventilacionih jedinica od smrzavanja moraju biti zamenjeni.

· pogoni kontrolnih ventila upravljačkih jedinica moraju se zamijeniti u skladu sa tačkom 2.1.1.

· Pogoni vazdušnih ventila podležu kontroli i daljoj upotrebi;

Za kontrolu recirkulacije klima uređaja K1, zamijenite on-off pogone vazdušnih ventila ventilima sa kontrolnim signalom od 0..10V.

2.3.2. Dispečerski sistem.

Dispečerski sistem treba da sadrži sledeće komponente:

· kompleks mjernih uređaja, aktuatora i opreme za automatizaciju na bazi Honeywell softvera i hardvera;

· multifunkcionalni kablovski sistem;

· kompleks softvera i hardvera za dispečerski centar.

Za otpremu ventilacionih sistema, obezbedite prikaz, arhiviranje i evidentiranje sledećih informacija:

· grafička slika instalacije sa senzorima temperature i vlage, termostatima protiv smrzavanja, diferencijalnim presostatima, kontrolnim ventilima, ovlaživačima zraka, zračnim ventilima;

· instalacioni brojevi;

· očitavanja senzora temperature i vlažnosti;

· očitavanja senzora releja diferencijalnog pritiska;

· očitavanja položaja kontrolnih ventila 0..100%;

· rad ventilatora/stop mod;

· režim rada/zaustavljanja pumpi;

· položaj vazdušnih ventila „otvoreno/zatvoreno“;

· zaustavljanje sistema kada se aktivira požarni alarm;

· zaustavljanje sistema kada postoji opasnost od smrzavanja grijača;

· zaustavljanje instalacije ako nema pada pritiska na ventilatoru;

· isključivanje ovlaživača zraka kada se ventilator klima uređaja zaustavi;

· rad sistema prema zadatom vremenskom rasporedu ili bez njega;

· signalizacija udesa i vanrednih situacija u slučaju kvara opreme, kao i kada vrijednosti tehnoloških parametara izlaze izvan propisanih raspona;

· upis nezgoda i vanrednih situacija u dnevnik poruka;

· evidencija registracije parametara za trenutno vrijeme, sa naznakom naziva kontroliranih parametara, mjernih jedinica, broja kontrolera i ulazno/izlaznog kanala.

2.3.3. Napajanje automatizacije i dispečerskog sistema mora se vršiti iz mreže naizmjenične struje napona 380/220 V, frekvencije 50 Hz koristeći izvore neprekidno napajanje na baterije i kao napajanje za električne prijemnike prve kategorije

U životu se često dešava da čovek ni u svakodnevnim stvarima ne može da objasni šta želi. Kada je u pitanju objašnjenje svojih „želi“ programeru, osoba jednostavno padne u stupor.

U idealnom slučaju, tehničke specifikacije bi trebao izraditi kupac - samo on zna šta mu treba. Ali u praksi, zbog niske kompetentnosti kupca u oblasti 1C, to često mora da uradi izvođač. Kupac usmeno izražava svoje potrebe, a programer (konsultant) to izražava pismeno.

Zašto su vam potrebne tehničke specifikacije?

Bilo koji, u idealnom slučaju, trebao bi biti popraćen tehničkim specifikacijama. Ovo je, prije svega, jasna definicija zadatka, rokova i načina realizacije. Drugo, ovo je dokument uz pomoć kojeg se rješavaju sva kontroverzna pitanja u budućnosti. Da li ću pisati tehničke specifikacije ili ne, to je, naravno, za mene lično, tehničke specifikacije mi olakšavaju rad i komunikaciju sa klijentom.

Nabavite 267 video lekcija na 1C besplatno:

Šta bi projektni zadatak trebao sadržavati?

One. zadatak mora sadržavati:

  • cilj— problem koji ćemo riješiti implementacijom ove specifikacije;
  • opis — sažetak nadolazeća poboljšanja;
  • metod implementacije — Detaljan opis metode za rješavanje cilja. U ovom trenutku potrebno je programerskim jezikom opisati sve nijanse zadatka: kakve zadatke kreiramo/uređujemo, kako treba da izgleda sučelje itd. Ako ne govorite „programski jezik“, ali „čuli ste nešto“, bolje je ne pokušavati pisati na tehničkom jeziku - ispada prilično zabavno. Opis treba da bude nedvosmislen i da ne izaziva pitanja. Može sadržavati i primjer implementacije sličnog rješenja u nekoj drugoj oblasti;
  • evaluacija učinka- veoma važna tačka, opis troškova rada.

Postoje i državni standardi za pisanje tehničkih specifikacija - GOST. U praksi se rijetko koriste, ali ponekad kupac insistira na tome.

Iz iskustva, prilikom predaje posla, vrlo često se javljaju situacije tipa „rekli smo ti onda...“, što nije baš prijatno, a često morate da prepravljate ceo posao. Stoga, dobro napisana tehnička specifikacija znatno olakšava život objema stranama.

Primjeri i uzorci tehničkih specifikacija za 1C

Mali izbor koji sam našao slobodno dostupan na internetu. Počevši od najjednostavnijih i najpristupačnijih do prilično složenih dokumenata.

Zbog činjenice da ljudi često traže primjere tehničkih specifikacija, dio svog rada dijelim sa zajednicom. Ovi dokumenti nemaju komercijalnu vrijednost (zbog starosti i konfiguracije), ali se nadam da mogu biti korisni kao uzorci.

Tehnički zadatak:

Automatizovano

PRODAJNI sistem.

Tehnički zadatak

Na listovima

"_" ______________ 2010


1. Opće informacije

Naziv automatizovanog sistema

"AS Sbyt"

Kupac

Izvršitelj

Osnova za rad

Planirani datumi početka i završetka radova na izradi sistema

Početak rada: 01.09.2010

Završetak radova: 31.12.2010

Svrha i ciljevi stvaranja sistema

Svrha sistema

Automatizovani sistem koji se razvija je dizajniran da automatizuje prodajne procese preduzeća.

Ciljevi stvaranja sistema

Ciljevi stvaranja automatizovanog sistema

Ciljevi razvoja "AS Sbyt" su:

  1. 3. Karakteristike objekta automatizacije

3.1 Poslovni procesi preduzeća

3.1. 1 Poslovni proces “Zaključivanje ugovora”

3.1.2. Poslovni proces “Obračun plaćanja”

  1. 4. Zahtjevi sustava.

4.1. Zahtjevi za sistem u cjelini.

4.1.1. Metode razvijene u AS i softverski moduli treba da sadrži mogućnosti za dalji razvoj sistema.

5.1.1. Sistem koji se razvija treba da se sastoji od automatizovanih sistema, podsistema i računovodstvenih modula, raspoređenih prema funkcionalnoj namjeni u skladu sa utvrđenom metodologijom za izgradnju automatizovanih sistema finansijske i ekonomske klase.

5.1.2. AS koji se razvija treba da obezbedi lakoću postavljanja automatizovane radne stanice (AWS) za svakog konkretnog izvođača u skladu sa postojećim računovodstvenim sistemom.

5.1.3. AS koji se razvija mora osigurati razlikovanje prava pristupa korisnika i pružiti mogućnost pristupa informacijama u mjeri potrebnoj i dovoljnoj za implementaciju poslovne obaveze svaki izvođač.

5.1.4. Zaštita informacija od neovlaštenog pristupa mora se provoditi korištenjem sljedećih mehanizama:

1. Ograničenja prava pristupa na nivou platforme 1C:Enterprise 8.1.

2. Dodatna ograničenja prava pristupa na razini okruženja izvršavanja.

5.1.4.1. Prioritet treba dati ograničenjima prava pristupa na nivou platforme. Uklanjanje dodatnih ograničenja na razini vremena izvođenja ne daje prava pristupa objektima ili funkcijama sistema ako im je nametnuto sistemsko ograničenje.

5.1.4.2 Zaštita informacija na nivou platforme

· Zaštita informacija na nivou platforme je obezbeđena sistemskim sredstvima. Ovim se regulišu prava čitanja i uređivanja sistemskih objekata, korišćenja interfejsa, sistemske funkcije i obavljanje rutinskih operacija sa podacima informacioni sistem.
· Sva prava pristupa moraju biti sistematizovana u odgovarajuće skupove - uloge informacionog sistema.
· Spisak korisnika informacionog sistema mora odrediti administrator sistema.
· Prava pristupa svakog korisnika moraju biti određena skupom uloga informacionog sistema koji su mu dostupni.
· Sistemski administrator mora odrediti skupove uloga informacionog sistema koji su dostupni svakom korisniku.
· Prilikom početka rada u sistemu korisnik mora proći proceduru autorizacije navođenjem svog imena u sistemu i lozinke.

5.1.4.3. Zaštita informacija na nivou vremena izvršavanja

Za određeni broj direktorija u sistemu, moraju se osigurati dodatna ograničenja prava na uređivanje.
Direktoriji za koje je potrebno zabraniti uređivanje u sistemu:
  • Skraćenice adresa
  • Valute
  • Vrste međusobnih obračuna
  • Vrste aktivnosti ugovornih strana
  • Grupa korisnika
  • Lični dokumenti
  • Organizacijske pozicije
  • Divizije
  • Korisnici
  • Stavke novčanih tokova
  • Rashodi
  • Cijene

5.1.5. Da bi se osigurala sigurnost informacija u slučaju nesreća, mora se osigurati svakodnevno automatsko arhiviranje podataka.

5.1.6. Zahtjevi za ergonomiju i tehničku estetiku

5.1.6.1.Osigurati ujednačavanje dizajna korisničkih interfejsa, alatnih traka i kontekstni meniji, automatski generisan od strane 1C platforme.

5.1.6.2 Terminologija koja se koristi za označavanje objekata i radnji korisnika u sistemu mora odgovarati standardnoj terminologiji predmetne oblasti.

5.2. Zahtjevi za strukturu i funkcioniranje AS "SABYT".

5.2.1. AS "Sbyt" treba da se sastoji od sledećih automatizovanih podsistema:

Podsistem za unos primarnih podataka o pretplatniku (zaključivanje ugovora);

Podsistem za generiranje platnih dokumenata;

Komunikacioni podsistem sa ASKUE sistemom;

Komunikacijski podsistem sa platnim terminalima.

5.2.2. Sastav podsistema za unos primarnih podataka o pretplatniku (zaključivanje ugovora) treba da bude sljedeći:

Dokument “Ugovor sa pretplatnikom”;

5.2.3. Sastav podsistema za generiranje platnih dokumenata trebao bi biti sljedeći:

Dokument "Priznanica"

Dokument “Obračun penala”

Dokument "Potrošena energija"

Modul za provjeru stanja međusobnih obračuna

5.2.4. Sastav komunikacijskog podsistema sa ASKUE sistemom bi trebao biti sljedeći:

Komunikacija modula sa ASKUE sistemom.

5.2.5. Sastav komunikacijskog podsistema sa terminalima za plaćanje trebao bi biti sljedeći:

Modul Komunikacija sa platnim terminalima.

5.3. Zahtjevi za funkcije modula podsistema za unos primarnih informacija o pretplatniku (zaključivanje ugovora)

5.3.1. Podsistem za unos primarnih informacija o pretplatniku (zaključivanje ugovora) mora obavljati sljedeće funkcije:

Unošenje i čuvanje informacija o instaliranom kapacitetu druge ugovorne strane (u daljem tekstu: pretplatnik);

Unošenje i pohranjivanje informacija o instaliranim brojilima korisnika;

Unos i pohranjivanje informacija o pretplatničkim tarifama;

Unošenje i čuvanje informacija o uslovima za obračun penala za pretplatnika;

Unošenje i pohranjivanje informacija o trajanju ugovora;

5.4. Zahtjevi za funkcije podsistema za generiranje platnih dokumenata

5.4.1. Podsistem za generiranje platnih dokumenata mora obavljati sljedeće funkcije:

Utvrđivanje stanja međusobnih obračuna sa pretplatnikom i utvrđivanje uslova za nastanak penala.

Generisanje platnih dokumenata (priznanica ili faktura).

5.5. Zahtjevi za funkcije komunikacijskog podsistema sa ASKUE sistemom

5.5.1. Komunikacijski podsistem sa ASKUE sistemom mora obavljati sljedeće funkcije:

Prijenos podataka o novozaključenim ugovorima sa pretplatnicima. Komunikacijski ključ mora biti jedinstvenost para “Subscriber ID” - “Subscriber Agreement Code”.

Pribavljanje podataka o potrošnji električne energije od pretplatnika. Komunikacijski ključ mora biti jedinstvenost para "ID brojača" - "Šifra brojača".

5.6. Zahtjevi za funkcije komunikacijskog podsistema sa platnim terminalima

5.6.1. Komunikacijski podsistem sa ASKUE sistemom mora obavljati sljedeće funkcije:

Prijem podataka o izvršenim uplatama od strane pretplatnika za električnu energiju preko terminala za plaćanje.

  1. 6. Postupak kontrole i prihvatanja AIS "PRODAJA".

6.1 Utvrđuje se sljedeća procedura za predstavljanje i dostavljanje rezultata rada Kupcu:

6.1.1. Izvođač demonstrira funkcionalnost softvera koristeći probni primjer.

6.1.2. Podatke za testni slučaj pripremaju predstavnici Kupca.

6.1.3. Izvođač prenosi softver odeljenju za informacije o korisniku i obučava administratora korisnika.

6.1.4. Na osnovu rezultata rješenja test slučaja treba pripremiti Potvrdu o prijenosu softvera za probni rad.

6.1.5. U slučaju neusklađenosti funkcionalnost U skladu sa zahtjevima tehničkih specifikacija, Izvođač eliminiše komentare u okviru ukupnih troškova razvoja AS.

6.1.6. Ako se pojave dodatni zahtjevi Kupca prema tehničkim specifikacijama, sastavlja se dodatna tehnička specifikacija za reviziju.

6.1.7. Prisustvo dodatnih zahteva Kupca ne bi trebalo da bude osnov za odbijanje potpisivanja Potvrde o prenosu softvera za probni rad.

6.1.8. Nakon puštanja softvera u probni rad, prema Planu implementacije dogovorenom sa Naručicom, Izvođač nakratko obučava osoblje Naručioca za rad sa softverom i svakom podsistemu prenosi Uputstvo za rad sa softverom.

6.1.9. Prilikom implementacije softvera (probni rad), Kupac vrši:

Unošenje potrebnih referentnih podataka;

Unošenje stvarnih podataka;

Izrada izvještaja i provjera rezultata rada.

6.1.10. Tokom procesa implementacije, Izvođač mora pružiti pomoć Kupcu u okviru Plana implementacije.

6.1.11. U slučaju loše pripremljenosti osoblja Naručioca za implementaciju i potrebe za dodatnom pomoći Izvođača za uspješnu implementaciju softvera, potrebno je sastaviti dodatni protokol za ugovaranje ugovorenih cijena za pružanje informativno-konsultantskih poslova.

6.2.Procedura za dalju podršku poslova AS “PRODAJA”.

6.2.1. Nakon puštanja softvera u rad mogu se implementirati dodatna poboljšanja i želje Kupca prema tehničkim specifikacijama dogovorenim sa Kupcem.

TOR mora naznačiti složenost i cijenu rada za implementaciju dodatnih zahtjeva.

6.2.2. Izvođač se obavezuje da će održavati telefon " hotline"za softversku podršku.

6.2.3. Na zahtev Naručioca, Izvođač može obezbediti softversku podršku direktno od Naručioca, koja se mora izvršiti na osnovu dodatnog ugovora za softversku podršku.

6.2.4. Greške koje je Kupac utvrdio u roku od šest meseci od datuma prenosa softvera u rad Izvođač mora ispraviti odmah i bez naknade.

Ako Izvođač otkrije da je greška nastala kao rezultat pogrešnih radnji Kupca, vrijeme koje je Izvođač potrošio da je pronađe i otkloni mora se dodatno platiti.

6.2.5. Kupac, u roku od godinu dana nakon kupovine 1C: Enterprise, ima pravo da dobije besplatna sva ažuriranja od 1C kompanije u vezi sa razvojem 1C programa i promjenama u zakonodavstvu. Instalaciju izmjena mora izvršiti automatizirani kontrolni sistem Kupca.

6.2.6. Dobavljač garantuje povjerljivost sadržaja baza podataka Kupca i svih drugih informacija koje je primio od Kupca tokom razvoja, implementacije ili održavanja AS-a.

Tehnički projekat:

ODOBRIO SAM I PODNOM NA ODOBRENJE

" "______________ 2010. " "_______________ 2010

Dodatak tehničkim specifikacijama od „____“ ________ 2010

Automatizovano

PRODAJNI sistem.

Tehnički projekat

Na listovima

Važi od "__" ____________ 2010


Imenici. 3

Counters. 3

Tarife.. 3

Trafostanice. 3

Opcije penala. 3

Transferi. 4

Vrste naknada. 4

Informacioni registri. 4

Značenje tarifa. 4

Pretplatničke tarife. 4

Podaci o brojilima. 5

Registri akumulacije. 5

Potrošnja energije. 5

Dokumenti.. 6

Ugovor sa pretplatnikom.. 6

Potrošena energija. 6

Potvrda. 7

Obračun kazni. 9

Obrada. 10

Prijem podataka iz ASKUE sistema. 10

Preuzimanje podataka iz sistem plaćanja.. 11


Imenici

Counters

Rekviziti:

Cijene

Detalji: br

Opcije penala

Detalji: br

Transferi

Vrste naknada

vrijednosti:

Informacioni registri

Trajanje ugovora

Učestalost: Neperiodična

Svrha: Dizajniran za čuvanje perioda važenja ugovora sa pretplatnicima

Mjerenja

Značenje tarifa

Učestalost: Dan

Svrha: Dizajniran za čuvanje tarifa i datuma od kojih tarife počinju da se primenjuju

Mjerenja

Rekviziti

Svrha

Dnevna cijena cijene

Cijena noćenja (možda nije navedena)

Pretplatničke tarife

Učestalost: Dan

Namjena: Dizajniran za pohranjivanje tarifa koje su dodijeljene pretplatniku prema ugovorima

Mjerenja

Rekviziti

Svrha

Imenik Tarife

Pretplatnička tarifa

Podaci o brojilima

Učestalost: Dan

Namjena: Dizajniran za pohranjivanje očitanja brojila za naknadno punjenje

Mjerenja

Rekviziti

Svrha

IndicationsDay

Očitavanje brojila

IndikacijeNoć

Očitavanje brojila

Registri akumulacije

Potrošnja energije

Namjena: Dizajniran za pohranjivanje informacija o potrošnji energije za naknadni obračun

Vrsta registra: po dogovoru

Mjerenja

Dokumentacija

Ugovor sa pretplatnikom

Svrha: Dizajniran da odražava činjenicu sklapanja ugovora sa pretplatnikom

Rekviziti

Svrha

Counterparty

Directory Contractors

Ugovor sa drugom stranom

Imenik Tarife

InstalledPower

Pohranjivanje instalisane snage pretplatnika u KW

Start DateAction

Datum od kojeg važi ugovor

End DateAction

Datum isteka ugovora

Organizacija

Organisation Directory

Mogućnost obračunavanja kazni

Nomenklatura

Nomenklatura imenika

Ručno podešavanje

Znak ručnog podešavanja unosa dokumenata

Deo tabele: Brojevi i tarife

Objavljivanje dokumenta

Dokument se sprovodi:

Prema informacionom registru „Očitavanja brojila“, gde se registruju brojila pretplatnika i početna očitanja brojila;

Prema informacionom registru „Pretplatničke tarife“, gde je upisana tarifa utvrđena za pretplatnika od datuma početka ugovora

Prema registru informacija „Rokovi važenja ugovora“, gde je upisan ugovor, datum početka i datum isteka ugovora

Potrošena energija

Svrha: Dizajnirano da odražava očitanja brojila na određeni datum

Popunjavanje dokumenta

Dokument se može popuniti na dva načina: ručno i pozivom na obradu „Prijem podataka iz ASKUE-a“.

Objavljivanje dokumenta

Dokument se sprovodi:

Prema informacionom registru “Očitavanja brojila”, gde se očitavanja brojila evidentiraju na dan dokumenta;

Prema registru akumulacije „Potrošena energija prema sljedećem algoritmu:

1. Očitavanja brojila se uzimaju iz informacionog registra „Očitavanja brojača“ na datum dokumenta i prethodna očitavanja brojila.

2. Razlike u vrijednostima očitavanja unose se u odgovarajuće resurse registra akumulacije.

Obrasci za štampanje

Registar očitavanja brojila

Potvrda

Svrha: Dizajniran da odražava troškove pretplatnicima

Popunjavanje dokumenta

Dokument se može popuniti na dva načina: ručnim unosom i pozivom na obradu „obračun plaćanja“

Tabelarni dio: Očitavanja brojila

Rekviziti

Svrha

Counterparty

Directory Contractors

Ugovor sa drugom stranom

Imenik Ugovori ugovornih strana

Nomenklatura

Nomenklatura imenika

Imenik Tarife

Pretplatnička tarifa prema ugovoru

Brojači imenika

TypeAccruals

Vrste prijenosa razgraničenja

Potrošena energija

Potrošena energija

Tarifna vrijednost

Vrijednost tarife na datum dokumenta

Accrued

Iznos koji se naplaćuje pretplatniku

Objavljivanje dokumenta

Dokument se sprovodi:

Prema poreskom kontnom planu:

Obrasci za štampanje

Registar naknada

Algoritam punjenja

Dokument se popunjava na osnovu priručnika „Sporazumi sa drugom stranom“.

  1. Iz imenika se biraju ugovori za koje je, prema registru informacija „Period važenja ugovora“, datum početka manji od datuma dokumenta, a datum završetka veći od datuma dokumenta;
  2. Odabiru se brojila koja odgovaraju ovim ugovorima;
  3. Za brojila, potrošnja energije se utvrđuje kao promet u registru akumulacije „Potrošnja energije“ za period između datuma dokumenta i datuma prethodnog dokumenta, onda ceo promet u registru; registar je preuzet. Rezultirajuća vrijednost se bilježi u polju “ConsumedEnergy”.
  4. Tarifa se utvrđuje u skladu sa ugovorom i vrednošću tarife na dan dokumenta;
  5. Tip obračuna je postavljen na “Prema očitanjima brojila”;
  6. Obračunato polje se izračunava kao proizvod potrošene energije i tarifne vrijednosti.

Algoritam

Kt. 90.01 sa analitikom SubcontoKt1 - Nomenklatura.NomenklaturaGrupa, SubcontoKt2 - Nomenklatura.Stopa PDV-a.

Ako postoji stanje na računu 62.02, onda se avans prebija sa knjiženjem

Dt. 62.02 sa analitikom SubcontoDt1 - Counterparty, SubcontoDt2 - Counterparty Agreement

Iznos transakcije je minimalna vrijednost iz stanja kredita računa 62.02 i vrijednosti „nabrojenog“ detalja)

Dt. 90.03 sa analitikom SubcontoDt1 - Nomenklatura.NomenklaturaGrupa, SubcontoDt2 - Nomenklatura.Stopa PDV-a

Kt. 62.01 sa analitikom SubcontoKt1 - Counterparty, SubcontoKt2 - Counterparty Agreement

Iznos transakcije = “Obračunati”*Stopa PDV-a/(100+Stopa PDV-a), gdje je stopa PDV-a “Nomenklatura.Stopa PDV-a”

Obračun kazni

Svrha: Dizajniran da odražava obračun kazni pretplatnicima

Popunjavanje dokumenta

Dokument se može popuniti na dva načina: ručnim unosom i pozivanjem obrade „obračun kazni“

Tabelarni dio: Očitavanja brojila

Rekviziti

Svrha

Counterparty

Directory Contractors

Ugovor sa drugom stranom

Imenik Ugovori ugovornih strana

Mogućnost obračunavanja kazni

Opcije imenika za obračunavanje kazni

Accrued

Iznos koji se naplaćuje pretplatniku

Objavljivanje dokumenta

Dokument se sprovodi:

Prema samonosivom kontnom planu:

Prema poreskom kontnom planu:

Obrasci za štampanje

Registar naknada

Potvrda o uplati sa bar kodom

Barkod se generira pomoću fonta “Infograftbarcode”.

Algoritam formiranja Red “0000”+Šifra pretplatničkog ugovora+Accrued

Izgled računa je priložen u datoteci KV_1.mxl

Algoritam

Za svaki red tabelarnog odeljka „Očitavanja brojila“ potrebno je izvršiti sledeće unose:

Dt. 62.01 sa analitikom SubcontoDt1 - Counterparty, SubcontoDt2 - Counterparty Agreement

Kt. 91.01 sa analitikom SubcontoKt1 - Ostali prihodi.

Iznos transakcije - vrijednost atributa “Accrued”;

Tretmani

Prijem podataka iz ASKUE sistema

Preciznost

Svrha

Šifra brojila u sistemu prodaje poklapa se sa meter_ID u sistemu ASKUE

Dnevna očitavanja brojila

Očitavanje brojila po noćnoj tarifi

Detalji obrade

Algoritam obrade:

  1. Dobijte kod brojača iz linije datoteke za prijenos podataka
  2. Pronađite odgovarajući element u imeniku “counters” po kodu, ako element nije pronađen, a zatim prikažite poruku “Brojač sa kodom nije pronađen...”
  3. Ako je element pronađen, dodajte red u tablicu vrijednosti, gdje je: "counter" - pronađeni element, "ReadingsDay" - "Dan", "ReadingsNight" - "Noć"
  4. Ako se obrada poziva iz dokumenta “Potrošena energija” i broja linija

u tablici vrijednosti je veći od 0, a zatim upišite sadržaj tablice vrijednosti tabelarni dio dokument i knjižite dokument.

  1. Ako postoje redovi u tablici vrijednosti i obrada nije pozvana iz dokumenta „Potrošena energija“, kreirajte dokument „Potrošena energija“ s datumom jednakim trenutnom datumu, a zatim objavite dokument.

Prijem podataka iz platnog sistema

Format datoteke za prijenos podataka je DBF;

Struktura datoteke za prijenos podataka:

Detalji obrade

Algoritam obrade:

  1. Napravite tablicu vrijednosti sa strukturom:
  1. Odaberite linije datoteke za prijenos podataka
  2. Počnite petljati kroz redove datoteke za prijenos podataka
  3. Čitanje linije datoteke za prijenos podataka
  4. Uzmite šifru ugovora iz linije datoteke za prijenos podataka
  5. Pronađite odgovarajući element po kodu u direktorijumu „Ugovori sa drugom stranom“ ako element nije pronađen, a zatim prikažite poruku „Sporazum sa kodom nije pronađen...“;
  6. Ako je element pronađen, dodajte red u tablicu vrijednosti, gdje: “Sporazum” - pronađeni element, “Datum” - “Data_plat”, “Broj plaćanja” - “Nomer_plat”, “Iznos” - “Summa_plat”
  7. Nakon što primite zadnji red datoteke za prijenos podataka, završite ciklus
  8. Za svaki red tablice vrijednosti kreirajte dokument „Nalog za plaćanje za prijem sredstava“. Prilikom kreiranja dokumenta provjerite da li u sistemu postoji dokument sa istim datumom i istim brojem pristiglog dokumenta. Ako je dokument prisutan u sistemu, onda dokument nije kreiran.
  9. Pravila za popunjavanje detalja dokumenta:

Rekviziti

Vrijednost punjenja

Vrsta operacije

TableLineValuable.Date

Broj dolaznog dokumenta

Tabela LineVal.NumberPayment

Datum dolaznog dokumenta

TableLineValuable.Date

Ugovor o drugoj strani

TableLineValue.Contract

Mnogi ljudi se suočavaju sa činjenicom da je prilično teško kratko i jasno objasniti šta želimo u svakodnevnom životu. A kada trebate dati stručnjaku zadatak da napiše program za organizaciju ili individualnog poduzetnika, uzimajući u obzir karakteristike i vlastite želje za funkcionalnošću, možete potpuno zaglaviti.


Ko treba da piše tehničke specifikacije?


Naravno, tehničke specifikacije mora dati kupac, jer on sigurno poznaje svoje potrebe i mogućnosti. Ali, kao što pokazuje praksa, velika većina klijenata nije kompetentna za 1C. Zbog toga je i sam izvođač često primoran da se udubi u potrebe kupca, shvati koji mu je finalni proizvod potreban i u skladu s tim sve to napiše programeru.


Zašto je potrebna tehnička specifikacija?


U idealnoj situaciji, s jednom ili drugom modifikacijom u softverskom proizvodu 1C, potrebna je tehnička specifikacija. Prije svega, moraju biti precizirani zadaci, rokovi i način izvršenja.

Ovo je važan dokument, jer ako se pojave bilo kakva kontroverzna pitanja, kompetentna izrada projektnog zadatka će postati Polazna tačka u pregovorima.

Da li izraditi tehničku specifikaciju ili ne, svako odlučuje za sebe, ali sigurno neće biti suvišno: pojednostavit će komunikaciju s klijentom i dati poslu poslovni i konkretan karakter.



Istaknimo listu najvažnijih tačaka koje bi trebale biti u tehničkim specifikacijama:

1. Cilj/Cilj. Formulirajte šta na kraju treba implementirati.

2. Opis. Ukratko opišite sadržaj planiranih poboljšanja.

3. Način implementacije. Detaljno opišite metode kojima treba postići cilj. Sve karakteristike zadatka treba da budu zapisane na jeziku programera: registri, direktorijumi (kreirajte ih ili uređujte); dizajn interfejsa itd. Za one koji nisu upoznati, a čuli su samo nešto o određenom programskom jeziku, savjetujemo da ne pokušavaju nepotrebno „pričati“ tehničkim jezikom. Jer opis je idealno suva izjava koja eliminiše dvosmislenost i mogućnost pojave nepotrebnih pitanja. Osim toga, ovaj paragraf može uključivati ​​primjer kako je slično programiranje već bilo izvedeno negdje.

4. Procjena učinka. Ova tačka je veoma važna – treba da opiše troškove rada.

Još dvije važne točke: postoje odobreni standardi za pisanje tehničkih specifikacija - GOST. Danas se rijetko koriste, ali neki klijenti mogu tražiti da ih koriste na starinski način.

I drugo, kada se posao preda, može nastati ovako nešto – „ali smo te nekako tražili da uradiš to i to pa onda...“. Postoji mogućnost da ćete morati da počnete sve od samog početka.

Stoga ponavljamo da će dobro napisana tehnička specifikacija biti korisna i za kupca i za izvođača radova.


Primjer tehničkih specifikacija za programera



Tehničke specifikacije 1C za finalizaciju eksterne obrade


Target
Potrebno je konfigurisati učitavanje podataka iz 1C na automatizovano radno mesto banke.


Opis

U vezi sa prelaskom organizacije na konfiguraciju 1C „Plate i osoblje državne institucije“, potrebno je razviti drugu obradu koja bi pružala sličnu funkcionalnost na novoj konfiguraciji.

Učitavanje podataka treba da bude zasnovano na dokumentima „Zahtjev za otvaranje ličnih računa zaposlenih” i „Izvod za isplatu zarada banci”.


Početni podaci

Postojeća obrada za 1C konfiguraciju “Plata budžetske institucije” koja učitava podatke iz dokumenta “Zahtjev za otvaranje ličnih računa zaposlenih” i drugih imenika i registruje u DBF datoteku za razmjenu podataka sa automatiziranim radnim mjestom banke utvrđenog standarda .

Obrada učitava podatke u polja TAB_N, IME, SERNUM, PASSCODE, PDAT, PWHR, ROĐENDAN, POSTINDEX, DRŽAVA, GRAD, ULICA, REGION, ZGRADA, KOMPANIJA, STAN, BPLACE, GRAĐANIN odgovarajuće informacije iz 1C konfiguracije, prethodno unesene u navedeni dokument i druge računovodstvene tabele. Učitava se broj osoblja, puno ime i prezime zaposlenog, njegov pasoš i podaci o adresi, datum rođenja i državljanstvo.


Metoda implementacije

Ovo će biti eksterni izvještaji i obradu pomoću mehanizma proširenja, ako to dozvoljavaju trenutni parametri kompatibilnosti baze i mogućnosti platforme. Prilikom promjene konfiguracije baze podataka potrebno je kreirati: direktorije, dokumente, registre.


Evaluacija učinka

P Potrebno je 5 radnih dana rada programera.

Koliko su precizno sastavljene tehničke specifikacije za modifikaciju 1C direktno određuje da li će zadaci koji su dodijeljeni programerima biti riješeni. Međutim, postoje određene poteškoće pri radu s takvim dokumentom. U širem smislu, TOR specificira standarde za kreiranje i modernizaciju automatizovanog sistema (AS), kao i proceduru rada. Ovo takođe uključuje skup standarda za pokretanje projekta. Ovo razumijevanje uloge tehničkih specifikacija diktirano je zahtjevima GOST 19.201-78 i 34.602-89, prema kojima se vrši razvoj tehničkih specifikacija za 1C. Postoji još jedno tumačenje značenja ovog dokumenta, bliže praksi.

Prema drugoj definiciji, projektni zadatak za reviziju 1C je dokument koji reguliše svrhu i parametre budućeg sistema, kao i proces izrade dokumentacije i njene liste. Ovo tumačenje omogućava uzimanje u obzir interesa programera i korisnika.

Kakva bi trebala biti tehnička specifikacija?

Svaki tehnički zadatak za razvoj 1C programa kreira izvođač. Ali to ne radi programer, već analitičar. Ovo je važna tačka, jer dokument mora biti sastavljen na jeziku razumljivom klijentu, bez visoko specijalizovanih tehničkih termina. Kada se uzmu u obzir sve nijanse projekta i pravilno formuliraju informacije, tehničke specifikacije se dogovaraju sa svim kupcima. Ako se prihvati, u rad se uključuju programeri. U tom slučaju, dokument mora jasno naznačiti željeni rezultat. Ovo pomaže programerima da postave pravi cilj i provjere ga u različitim fazama. Također, prilikom sastavljanja tehničkih specifikacija za modifikaciju 1C, mnogo pažnje treba posvetiti formulaciji. Treba voditi računa da budu dovoljno konkretni i da ne sugerišu druga tumačenja. Ovo je prva stvar koju treba zapamtiti kada radite s tehničkim specifikacijama. Također morate odgovorno pristupiti dizajnu. Ovo se odnosi i na naslovnu stranu dokumenta.

Glavne greške u tehničkim specifikacijama za razvoj 1C

Struktura tehničkih specifikacija regulirana je GOST 34.602-89. Ovaj dokument sadrži jasne zahtjeve za broj i redoslijed informacijskih blokova u tehničkim specifikacijama. Istovremeno, ne postoje strogi standardi za metode prezentacije. Ova situacija sadrži veliki potencijal za rješavanje složenih problema, a istovremeno može dovesti do mnogih grešaka pri izradi dokumenta. Najčešće nepreciznosti su:

  1. Ponavljanje pojedinih dijelova u različitim interpretacijama.
  2. Informacije se daju nasumično. U idealnom slučaju, trebalo bi da se odnosi na određenu strukturu, kao što su poslovni procesi ili sistemski moduli.
  3. Informacije u različitim odeljcima su predstavljene sa različitim stepenom detalja.

Sve ovo sprečava kupca da razume informacije sadržane u tehničkim specifikacijama. Ovo komplikuje proces saradnje, čineći ga radno intenzivnijim.

Nakon što kupac pogleda uzorak tehničke specifikacije za modifikaciju 1C, može se promijeniti i to ne uvijek na bolje. Ovo, zauzvrat, obično sprečava programere da ispravno percipiraju informacije. Ovo se posebno odnosi na specijaliste sa malo iskustva. U ovoj fazi često se javljaju sljedeće greške:

  1. Zahtjevi različitih odjeljaka su u suprotnosti jedni s drugima.
  2. Ispada da je formulacija netačna.
  3. Na nekim mjestima su informacije previše detaljne.

Lako se riješiti svih navedenih grešaka. Morate se fokusirati, prije svega, na rezultat, a ne na pažljivo propisivanje teksta. Vrijedno je zapamtiti da tehnička specifikacija opisuje funkcionalnost projekta, njegove glavne parametre i svrhu.

Kako izbjeći greške pri izradi tehničkih specifikacija?

Osnovno pravilo koje važi za sve naredne preporuke je da tekst mora biti konkretan. Da biste to učinili, morate koristiti reference na GOST-ove i druge regulatorne dokumente. Ovo omogućava izvođaču i kupcu da percipiraju informacije na isti način.

Primjer tehničke specifikacije za modifikaciju 1C pretpostavlja upotrebu jezika poslovnog sektora za koji se projekat izvodi. To je prije svega neophodno za kupca. Međutim, u tekstu ne treba koristiti nikakva poređenja, jer se mogu tumačiti na različite načine.

Osnovna pravila pri izradi tehničkih specifikacija za izradu izvještaja i drugih 1C elemenata:

  1. Tehničku specifikaciju zajednički kreiraju izvođač i kupac.
  2. Na rad programera treba postavljati samo objektivne zahtjeve. Za uspješan razvoj projekta, subjektivna vizija kupca mora biti minimizirana.
  3. Potrebno je detaljno opisati rezultat koji je potreban kupcu. U ovom slučaju, u primjeru tehničke specifikacije za razvoj 1C konfiguracije, potrebno je navesti sve parametre po kojima bi element trebao raditi. U suprotnom, rezultat se može znatno razlikovati od željenog.
  4. Rizici izvođača i kupca trebaju biti približno jednaki i minimizirani.
  5. Ne možete koristiti termine koji se koriste u poslovnoj komunikaciji i koji se ne koriste u određenoj industriji.

Da bi kreirao tehničku specifikaciju za razvoj izvještaja u 1C ili nekom drugom elementu, analitičar mora poznavati sve karakteristike područja djelatnosti kupca. Zahtjevi bi trebali pružiti samo korisne informacije koje će biti korisne izvođaču. S obzirom na to Posebna pažnja ovdje je fokus na konačnim zadacima koje softver mora riješiti; ne postoji jedinstven primjer tehničke specifikacije.

Opasnost od pogrešnog sastavljanja tehničkih specifikacija

Gore navedene greške mogu dovesti do povećanja vremena utrošenog na kreiranje sistema. To povlači nepotrebne troškove i nezadovoljstvo. Projektni zadatak za razvoj baze podataka ili druge 1C konfiguracije trebaju izraditi iskusni stručnjaci. Korist za sve učesnike zavisi od toga koliko je ovaj dokument lak za razumevanje. Kupac prima efektivno automatizovani sistem za rješavanje poslovnih problema. Istovremeno, izvođač ima još jednog zadovoljnog klijenta. Vlasnici preduzeća moraju biti što pažljiviji pri odabiru 1C partnerskih kompanija, jer učinkovitost organizacije uvelike ovisi o tome koliko su dobro sastavljene tehničke specifikacije za reviziju.

mob_info