Ֆունկցիոնալ ընտրանքներ (1Cv82): Բաշխված տեղեկատվական համակարգերի կառուցում, որոնում, սովորական առաջադրանքներ, ֆունկցիոնալ ընտրանքներ Ֆունկցիոնալ տարբերակների պարամետրեր 1s 8.3

Օբյեկտ 1c «Ֆունկցիոնալ ընտրանքներ» - նախագծված է ընդգծելու կիրառական լուծումների ֆունկցիոնալությունը, որը հնարավոր է միացնել (անջատել) իրականացման ընթացքում առանց ինքն իրեն փոխելու (Ենթահամակարգերի հետ միասին նրանք կազմում են 1C բարակ հաճախորդի միջերես): Մեխանիզմի մի մասն են ֆունկցիոնալ ընտրանքներ.

Գործառույթների ընտրանքների մեխանիզմ ներառում է երկու մետատվյալների օբյեկտ.

1. Ֆունկցիոնալ տարբերակ;
2. Ֆունկցիոնալ ընտրանքների պարամետրեր:

Ավելին

Ֆունկցիոնալ տարբերակմետատվյալների օբյեկտ է, որը կարող է ուղղակիորեն ազդել հավելվածի միջերեսի կազմի վրա (եթե ֆունկցիոնալ տարբերակը պահում է իր արժեքը բուլյան հատկանիշում): Այս տեսակի օբյեկտների օգնությամբ դուք կարող եք թաքցնել տարրեր, որոնք վերաբերում են անհասանելի ֆունկցիոնալությանը: Օրինակ, Currency accounting տարբերակը կարող է թաքցնել Արժույթները, դաշտը Արժույթը ից, սյունակը Արտարժույթի գումարըհաշվետվություններից։

Ֆունկցիոնալ տարբերակի արժեքի աղբյուրը մետատվյալների օբյեկտն է, որն ընտրված է որպես Storage հատկություն, օրինակ, այն կարող է լինել:

Գործառական տարբերակի արժեքը գրացուցակում կամ ռեսուրսում պահելու դեպքում անհրաժեշտ է լրացուցիչ տեղեկատվություն, որը հստակ ցույց է տալիս, թե ինչպես ընտրել տարբերակի արժեքը: Այդ նպատակով տրամադրվում է առանձին մետատվյալների օբյեկտ Ֆունկցիայի ընտրանքների պարամետրեր.

Կարելի է ասել, որ ֆունկցիոնալ տարբերակների պարամետրերը ֆունկցիոնալ ընտրանքների արժեքների տարածության կոորդինատային առանցքներն են: Ավելին, ֆունկցիոնալ տարբերակների մեկ պարամետրը կարող է որոշել «իր» կոորդինատային առանցքի արժեքը միաժամանակ բազմաթիվ ֆունկցիոնալ տարբերակների համար:

[թաքցնել]

Ֆունկցիոնալ ընտրանքները կարող են ազդել.

1. օգտատիրոջ միջերեսին՝
   • համաշխարհային ;
   • ռեկվիզիտներ (ներառյալ այնպիսի ձևի ռեկվիզիտների սյունակներ, ինչպիսիք են Արժեքների աղյուսակկամ արժեքի ծառ);
   • ձևավորել հրամաններ;
2. տվյալների կազմման համակարգի միջոցով իրականացված հաշվետվությունների վերաբերյալ.
3. ներկառուցված լեզվով գրված ալգորիթմներին - հնարավոր է ներկառուցված լեզվից ստանալ ֆունկցիոնալ ընտրանքների արժեքները և օգտագործել դրանք տարբեր պայմաններում, օրինակ՝ նվազեցնելու հաշվարկների քանակը (տես, օրինակ. )

ՈՒՇԱԴՐՈՒԹՅՈՒՆ.Եթե ​​հաճախորդի հավելվածն աշխատում է ինֆոբազայի ֆայլային տարբերակի հետ վեբ սերվերի միջոցով, ապա ֆունկցիոնալ տարբերակը փոխելը կփոխի օգտատիրոջ միջերեսը միայն վեբ սերվերը վերագործարկելուց հետո (հաճախորդի հավելվածի վերագործարկումը չի փոխի օգտատիրոջ միջերեսը):

1C ֆունկցիոնալ ընտրանքների հատկությունները

• Պահպանում - դաշտ, որտեղ դուք պետք է ընտրեք բուլյան տիպի օբյեկտ: Որպես կանոն, օգտագործվում են հաստատուններ:
• ստանալիս - դրոշը պատասխանատու է արտոնյալ ռեժիմում ֆունկցիոնալ տարբերակի արժեքը ստանալու հնարավորության համար:
• Կազմը - օբյեկտների և օբյեկտների ատրիբուտների ցանկ, որոնց տեսանելիությունը միացված/անջատվում է, երբ ֆունկցիոնալ տարբերակը անջատված/անջատված է (վերահսկվում է կառավարվող ձևի միջոցով):

Օրինակ, կախված որոշակի իրականացման պայմաններից, կարող եք նախատեսել անջատել ապրանքների հաշվառումը պահեստներով, որպեսզի ապրանքների ստացման փաստաթղթերը գրանցելիս Պահեստ դաշտը չցուցադրվի փաստաթղթի ձևում:

1C ֆունկցիոնալ ընտրանքների օգտագործման առանձնահատկությունները.

1. Ֆունկցիոնալ տարբերակները կարող են ունենալ կամայական տիպի արժեքներ (պարտադիր չէ, որ բուլյան):
2. Ֆունկցիոնալ տարբերակ օգտագործելու համար նոր հաստատուն ավելացնելիս համոզվեք, որ այն ներառեք համապատասխան ենթահամակարգում և դրան թույլտվություններ տրամադրեք:
3. Ֆունկցիոնալ ընտրանքների հետ աշխատելը հասանելի է ներկառուցված լեզվից, որի շնորհիվ մշակողը կարող է ստեղծել իր սեփական ալգորիթմները ֆունկցիոնալ ընտրանքների արժեքների համար:
4. Հրամանի ինտերֆեյսի հրամանը կբացառվի հրամանի միջերեսից, եթե ֆունկցիայի տարբերակը անջատված է.
   • հատկանիշ, որը հրամանի պարամետր է.
   • հրամանի պարամետրի տեսակը (եթե հրամանի պարամետրի տեսակը բարդ է, ապա հրամանը անհասանելի է դառնում, երբ բոլոր պարամետրերի տեսակներն անջատված են):

ՈՒՇԱԴՐՈՒԹՅՈՒՆ.Ֆունկցիոնալ ընտրանքները և դրանց պարամետրերը չեն ազդում տվյալների բազայի կազմի վրա. բոլոր աղյուսակներն ու դաշտերը առկա են տվյալների բազայում՝ անկախ ֆունկցիոնալ տարբերակների վիճակից:

Ֆունկցիոնալ ընտրանքների ազդեցությունը ձևի մանրամասների և հրամանների վրա.

1. կառավարվող ձևի տեսակը<Вид>Օբյեկտ ( DirectoryObject, DocumentObject և այլն) կանջատվի, եթե համապատասխան օբյեկտն անջատված է ֆունկցիոնալ տարբերակով: Վերլուծվում են միայն այն ֆունկցիոնալ տարբերակները, որոնք չունեն պարամետրեր:
2. Տիպի կառավարվող ձևի հիմնական հատկանիշը Դինամիկ ցուցակկանջատվի, եթե ֆունկցիոնալ տարբերակը անջատի կազմաձևման օբյեկտը, որը նշված է որպես դինամիկ ցուցակի հիմնական աղյուսակ: Վերլուծվում են միայն այն ֆունկցիոնալ տարբերակները, որոնք չունեն պարամետրեր:
3. Հղման տեսակի ձևի հատկանիշն անջատված է, եթե այդ տեսակը ձևավորող կազմաձևման օբյեկտն անջատված է ֆունկցիոնալ տարբերակով: Կոմպոզիտային տիպի ձևի հատկանիշն անջատված է, եթե ֆունկցիոնալ ընտրանքները անջատում են բոլոր բաղադրիչների տեսակները:
4. Ձևերի աղյուսակը կանջատվի, եթե այն ցուցադրի ֆունկցիոնալ տարբերակով անջատված ձևի հատկանիշի տվյալները:
5. Տիպի ընտրության երկխոսության երկխոսության մեջ չկան տեսակներ (օրինակ՝ ներածման դաշտերի համար, որոնք կապված են կոմպոզիտային տիպի ատրիբուտների հետ), եթե այս տիպերը կազմող կազմաձևման օբյեկտներն անջատված են ֆունկցիոնալ տարբերակով: Ֆունկցիոնալ ընտրանքների կողմից անջատված տեսակների մասին տեղեկությունները պահվում են հաճախորդի կողմից և ջնջվում 20 րոպե հետո կամ մեթոդական զանգի ընթացքում: UpdateInterface ().

ՈՒՇԱԴՐՈՒԹՅՈՒՆ.Ի տարբերություն հրամանի ինտերֆեյսի, ֆունկցիոնալ ընտրանքների պարամետրերի արժեքները սահմանվում են միայն ձևի որոշակի օրինակի համար:

Ֆունկցիոնալ ընտրանքների պարամետրի ստեղծում

Ֆունկցիոնալ ընտրանքի պարամետրը ստեղծվում է «Ֆունկցիոնալ ընտրանքների պարամետրեր» 1C կոնֆիգուրացիայի օբյեկտի միջոցով:

[թաքցնել]

Դա կարելի է անել կազմաձևման պատուհանում՝ ավելացնելով նոր օբյեկտ:

Ֆունկցիայի ընտրանքների պարամետրի հատկությունները.

• Օգտագործում - սահմանում է օբյեկտների մի շարք, որոնց արժեքները կորոշեն, թե ինչպես պետք է ընտրվի ֆունկցիոնալ տարբերակի արժեքը: Առկա օբյեկտների ցանկը ներառում է բառարաններ և տեղեկատվական ռեգիստրի չափսեր: Այս ցանկի ֆունկցիոնալ ընտրանքների յուրաքանչյուր պարամետրի համար կարող եք ընտրել մեկ գրացուցակ (գրացուցակների ամբողջ ցանկից) և յուրաքանչյուր տեղեկատվական ռեգիստրի մեկ հարթություն:

ՈՒՇԱԴՐՈՒԹՅՈՒՆ.Դուք չեք կարող օգտագործել նույն մետատվյալների օբյեկտը մեկից ավելի գործառույթի ընտրանքի պարամետրում:

Ֆունկցիոնալ ընտրանքներսովորական կոնֆիգուրացիայի օբյեկտներ են: Դրանք ֆունկցիոնալ ընտրանքների մեխանիզմի մի մասն են և թույլ են տալիս կիրառական լուծումում ընտրել այնպիսի գործառույթ, որը կարող է միացվել/անջատվել իրականացման ընթացքում՝ առանց կիրառական լուծումը փոխելու:

Օրինակ, կախված կոնկրետ իրականացման պայմաններից, անհրաժեշտ է նախատեսել ապրանքների հաշվառումն անջատել պահեստներով: Որպեսզի ապրանքների ստացման փաստաթղթերը գրանցելիս դաշտը Բաժնետոմսերչի ցուցադրվում փաստաթղթի տեսքով:

Դա անելու համար կոնֆիգուրացիայի մեջ կարող է սահմանվել ֆունկցիոնալ տարբերակ Պահեստի հաշվառում, պահվում է տիպի հաստատունով բուլյան.

Դուք կարող եք կապել տարբեր կոնֆիգուրացիայի օբյեկտներ կամ դրանց ատրիբուտները այս ֆունկցիոնալ տարբերակի հետ: Օրինակ, դուք կարող եք կապել հենարանները այս ֆունկցիոնալ տարբերակի հետ Բաժնետոմսերփաստաթուղթ Ապրանքների ստացում.

Այնուհետև, իրականացման ընթացքում, դուք կարող եք միացնել կամ անջատել այս ֆունկցիոնալ տարբերակը կոնկրետ տեղեկատվական բազայում 1C:Enterprise ռեժիմում:

Պլատֆորմը ավտոմատ կերպով կմիացնի և կանջատի բոլոր համապատասխան ինտերֆեյսի տարրերի ցուցադրումը (դաշտեր, հրամաններ, ցուցակի սյունակներ, հաշվետվության տարրեր): Մեր դեպքում դաշտը կթաքցվի կամ կցուցադրվի Բաժնետոմսերբոլոր փաստաթղթերի ձևերով Ապրանքների անդորրագիր.

.
«1C: ERP ձեռնարկությունների կառավարում» - նորարարական լուծումհամալիր կառուցել տեղեկատվական համակարգերկառավարել դիվերսիֆիկացված ձեռնարկությունների, այդ թվում՝ տեխնիկապես բարդ բազմամշակման արտադրություն ունեցող ձեռնարկությունների գործունեությունը, հաշվի առնելով խոշոր և միջին բիզնեսի ավտոմատացման լավագույն համաշխարհային և ներքին փորձը:
Որոշ ինֆոգրաֆիկա.

Այսօր (2016թ. մարտ) ավելի քան 900 ձեռնարկություն դարձել է 1C:ERP օգտվող, և նրանց թիվը գնալով աճում է։ Միևնույն ժամանակ, մի քանի տասնյակ նախագծեր, մշակողների տեսանկյունից, ստացել են «պիլոտային» կարգավիճակ, այսինքն. այս ձեռնարկություններն ու կազմակերպությունները հիմնականում ակտիվ մասնակցություն են ունենում նոր ֆունկցիոնալության մշակման գործում՝ օպերատիվ արձագանքելով:
Ահա 1C:ERP որոշ օգտվողների լոգոները.


1C. ERP լուծման հետաքրքիր առանձնահատկությունն այն է, որ մենք զարգացնում ենք մեկ լուծում- 1C: ERP - և դրա աղբյուրներից մենք ավտոմատ կերպով ստանում ենք չորս լուծում(«կտրելով» ֆունկցիոնալությունը և միացնելով ֆունկցիոնալ ընտրանքները).


Բիզնեսը ընդլայնելիս կամ ընկերության ավտոմատացման կարիքները մեծացնելիս համակարգի ֆունկցիոնալությունը կարող է աստիճանաբար մեծացվել՝ «Առևտրի կառավարում» կոնֆիգուրացիայից անցնելով «Ինտեգրված ավտոմատացում» կոնֆիգուրացիայի, այնուհետև «ERP Enterprise Management 2»: Լուծումների միավորման բարձր աստիճանի պատճառով նման անցումը կատարվում է արագ, տեղեկատվական բազայում կուտակված տվյալները պահպանվում են, և օգտվողների վերապատրաստումը չի պահանջվում. նրանք շարունակում են աշխատել ծանոթ ծրագրային և տեղեկատվական միջավայրում:

Ինչպես գրել 1C:ERP

Ինչպես ենք մեկից չորս որոշում կայացնում

Մշակումն իրականացվում է միայն մեկ մասնաճյուղում (ERP): Առաջատար ERP լուծումից ավելի «թեթև», ֆունկցիոնալ սահմանափակ ինտեգրված ավտոմատացում (այսուհետ՝ KA հակիրճ) և Առևտրի կառավարման երկու տեսակների (այսուհետ՝ UT և UT Basic) ձևավորման գործընթացը ավտոմատացված է:
Փոփոխությունները ERP-ից դեպի «ածանցյալ» կոնֆիգուրացիաներ (KA, UT, UT Basic) փոխանցվում են ավտոմատ կերպով՝ օգտագործելով կոնֆիգուրացիայի համեմատության և միաձուլման մեխանիզմը: Այս մեխանիզմն ի սկզբանե նախատեսված էր ավտոմատացնել կիրառական լուծումների նոր տարբերակներին անցնելու գործընթացը այն օգտվողների համար, ովքեր փոխում են/ընդլայնում են հավելվածի լուծման ֆունկցիոնալությունը իրենց կողմից: Կազմաձևման համեմատության և միաձուլման մեխանիզմը կատարում է եռակողմ իմաստային միաձուլում, որը հիմնված է երեք կոնֆիգուրացիաների վերլուծության վրա.

• հին վաճառողի կոնֆիգուրացիա
• նոր կոնֆիգուրացիա մատակարարից
• ընթացիկ օգտատիրոջ կոնֆիգուրացիան (հին կոնֆիգուրացիան վաճառողի կողմից, գումարած օգտվողի կողմից դրանում կատարված փոփոխությունները)

Ելքում մենք ստանում ենք նոր ընթացիկ կոնֆիգուրացիա, որը համատեղում է նոր գործառույթները (ներդրված է մշակողի կողմից) և պահպանում է օգտատիրոջ կողմից կատարված բարելավումները (հարմարեցումները):
Մեր դեպքում ընթացիկ կոնֆիգուրացիայի դերը հերթափոխով KA, UT, UT Basic է, քանի որ մատակարարի հին և նոր կոնֆիգուրացիաները՝ համապատասխանաբար հին և նոր տարբերակների ERP: Նրանք. Մենք կարծում ենք, որ ֆունկցիոնալ սահմանափակ կոնֆիգուրացիաները՝ KA, UT, UT Basic, հարմարեցված են (հիմնականում չօգտագործված օբյեկտները հեռացնելու միջոցով) ERP-ի տարբերակները:


Լուծումներից յուրաքանչյուրի համար ձեռքով գրված մի քանի օբյեկտներից մեկը փոխանակման պլաններն են, որոնք սահմանում են այս լուծումը 1C այլ լուծումների հետ (օրինակ՝ 1C: Փաստաթղթերի կառավարում) կամ, օրինակ, արտաքին սարքավորումների հետ ինտեգրելու կանոնները: Սակայն տվյալների փոխանակման աստիճանական անցման շնորհիվ մեկ EnterpriseData ստանդարտի, մենք նվազեցնում ենք փոխանակման պլանների քանակը, որոնք եզակի են որոշակի լուծման համար և փորձում ենք օգտագործել տվյալների փոխանակման մեկ ծածկագիր:
Այս մոտեցման մեջ կա մեկ հետաքրքիր առանձնահատկություն. Ամբողջ լուծումը գրված է մեկ անգամ՝ ERP մասնաճյուղում; բայց կոդի, ձևերի, սցենարների, հաշվետվությունների և այլնի մեծ մասը: օգտագործվում է չորս լուծումներով և շատ տարբեր՝ ERP-ն ներդրվում է հազարավոր օգտատերեր ունեցող ձեռնարկություններում, իսկ UT Basic-ը նախատեսված է ծառայելու համար։ անհատ ձեռնարկատերեր. Մենք փորձում ենք մեծ ուշադրություն դարձնել մեր արտադրանքի օգտագործելիությանը:
ISO 9241-11 միջազգային ստանդարտը սահմանում է օգտագործելիությունը հետևյալ կերպ.

որքանով արտադրանքը կարող է օգտագործվել որոշակի օգտվողներ օգտագործման որոշակի համատեքստում՝ պատշաճ արդյունավետությամբ, արտադրողականությամբ և բավարարվածությամբ որոշակի նպատակներին հասնելու համար

Մենք փորձում ենք հավելվածը գրել այնպես, որ հեշտ և հարմար լինի դրա հետ աշխատել նույնիսկ անփորձ օգտագործողի համար։

Զարգացման առանձնահատկությունները

ERP մշակելիս մենք միշտ պետք է հիշենք, որ մշակվող ֆունկցիոնալությունը կարող է օգտագործվել մեկ կամ մի քանի ERP-ից ստացված լուծումներում (KA, UT, UT Basic): Ֆունկցիոնալությունը հեշտությամբ միացնելու/անջատելու համար մենք լայնորեն օգտագործում ենք ֆունկցիոնալ ընտրանքների մեխանիզմը, որն ի սկզբանե ստեղծվել է նման առաջադրանքների համար: Ֆունկցիոնալ ընտրանքները թույլ են տալիս կիրառական լուծման մեջ ընտրել գործառույթներ, որոնք կարող են միացվել/անջատվել իրականացման ընթացքում՝ առանց կիրառական լուծումը փոխելու: Ֆունկցիոնալ տարբերակներն են լուծման կարգավորումները, վանդակները, երբ անջատված են, դրանց հետ կապված բոլոր գործառույթներն անհասանելի են դառնում: Նախևառաջ, ֆունկցիոնալ տարբերակներն օգտագործվում են ծրագիրը որոշակի իրականացման կարիքներին համապատասխանեցնելու համար: ERP-ում մենք օգտագործում ենք այս մեխանիզմը (ի լրումն դրա հիմնական նպատակի)՝ «կտրելու» ածանցյալ կոնֆիգուրացիաները ERP-ից: Օրինակ, ERP լուծման մեջ կա «Ձեռնարկությունների կառավարում» ֆունկցիոնալ տարբերակ, դրա հետ կապված է արտադրության կառավարման համար պատասխանատու բոլոր գործառույթները՝ արտադրության պլանավորում, արտադրության ծախսերի հաշվառում, հարակից հաշվետվություններ և շատ ավելին: Այս տարբերակը միացված է միայն 1C: ERP լուծումում և անջատված է «ածանցյալ» լուծումներում KA, UT, UT Basic: Ընդհանուր առմամբ, 1C:ERP-ն օգտագործում է մոտ 600 ֆունկցիոնալ տարբերակ:
Մեկ այլ պլատֆորմի մեխանիզմ, որը հեշտացնում է 1C-ի աշխատանքը՝ ERP մշակողը . Ենթահամակարգերը լուծումների ֆունկցիոնալությունը բլոկների բաժանելու միջոց են. լուծման յուրաքանչյուր օբյեկտ (կատալոգ, փաստաթուղթ, հաշվետվություն և այլն) պետք է ներառված լինի առնվազն մեկ ենթահամակարգում: Մասնավորապես, ERP լուծումն ունի երեք ենթահամակարգ, որոնք հեշտացնում են ERP-ից ստացված լուծումների կառուցումը.

1. «Օբյեկտներ UE, UT, KA» - բոլոր կիրառական լուծումներում ներառված օբյեկտներ՝ Առևտրի կառավարում, Ինտեգրված ավտոմատացում, Ձեռնարկությունների կառավարում (ռուսական անվանումը ERP):
2. «Օբյեկտներ UE, KA» - օբյեկտներ, որոնք վերաբերում են միայն Ինտեգրված ավտոմատացման և ERP-ի կոնֆիգուրացիաներին:
3. «UE օբյեկտներ» - օբյեկտներ, որոնք կապված են միայն ERP լուծման հետ

ERP լուծման ցանկացած կիրառական օբյեկտ պետք է պատկանի այս երեք ենթահամակարգերից ՄԻԱՅՆ ՄԵԿԻՆ: Այս պայմանը ստուգվում է ERP լուծման կոդի ստատիկ վերլուծության ժամանակ (տես ստորև):

Թվերը տասնորդական կետից հետո

ERP արտադրանքի տարբերակը բաղկացած է չորս թվերից, որոնք բաժանված են կետերով: Օրինակ - 2.1.3.117:

• Տարբերակում առաջին համարը (վերանայումը) չափազանց հազվադեպ է փոխվում (օրինակ՝ KA 1.х.х.х և КА 2.х.х.х բաժանվում են գրեթե 8 տարով)։
• Երկրորդ թիվը (ենթահրատարակությունը) փոխվում է մոտավորապես տարին մեկ անգամ։ Նոր ենթահրատարակությամբ տարբերակը թողարկում է նոր գործառույթ: Նման տարբերակների թողարկումը հաճախ համընկնում է օրացուցային տարվա սկզբի հետ, որպեսզի օգտվողները բավական ժամանակ ունենան նոր տարբերակ «տեղափոխվելու» համար:
• Նոր երրորդ համարով (թողարկում) տարբերակները զարգացնում են գոյություն ունեցող ֆունկցիոնալությունը. նոր թողարկում է թողարկվում մոտ երկու-երեք ամիսը մեկ:
• Թարմացված չորրորդ համարով տարբերակները (կարկատող կառուցումներ) պարունակում են միայն վրիպակների շտկումներ և թարմացումներ՝ գործող օրենսդրությանը համապատասխանելու համար: Նրանք դուրս են գալիս երկու շաբաթը մեկ:

Մենք կարող ենք մշակման փուլում գտնվող արտադրանքի մինչև 3 տարբերակ ունենալ, օրինակ.

1. 2.1.3.X - Նախորդ ենթահոդվածի աջակցվող թողարկում: Թողարկվելու է մինչև 2016 թվականի վերջ։ Այս տարբերակում կան միայն վրիպակների շտկումներ և խմբագրումներ՝ գործող օրենսդրությանը համապատասխանելու համար:
2. 2.2.1.X - Ընթացիկ ենթահոդվածի ընթացիկ թողարկումը: Այն ունի նոր ենթախմբագրման գործառույթ: Դրա համար, մինչև 2.2.2.X-ի թողարկումը, կթողարկվեն ֆիքս բիլլեր։
3. 2.2.2.X - Ներկայիս ենթահոդվածի ֆունկցիոնալության զարգացում: Այս թողարկումն ակտիվ մշակման փուլում է:

Հաշվի առնելով, որ ERP-ից բացի, ERP-ի յուրաքանչյուր մասնաճյուղից ձեռք են բերվում ևս 3 լուծումներ՝ KA, UT և UT Basic, մենք ստանում ենք ապրանքների 12 տարբերակ, որոնք տեղակայված են 12 տարբեր պահեստներում:
Զարգացման ընթացքում մենք ունենք մինչև 4 պլանավորման հորիզոններ, օրինակ.

1. 2.1.3 (աջակցվում է), մենք որոշում ենք, թե որ սխալներն են ուղղվում, օրենսդրության փոփոխման հետ կապված որ նախագծերն են իրականացվելու: Կիրականացվեն միայն այն փոփոխությունները, որոնք ուժի մեջ են մտնում 2016թ. Հորիզոն - մինչև 2016թ
2. 2.2.1 (աջակցվում է) - «արտաքին» սխալները ամրագրված են + օրենսդրության փոփոխություններ, որոնք ուժի մեջ են մտնում մինչև 2.2.2-ի թողարկումը: Հորիզոն - ելքից առաջ 2.2.2.
3. 2.2.2 (ակտիվորեն մշակված) - «արտաքին» սխալները շտկված են + մեր հայտնաբերած սխալները + ներդրված է նոր գործառույթ: Հորիզոն - մինչև թողարկումը 2.2.3
4. 2.2.3 (պլանավորված). Եթե ​​նախագիծը մեծ է, ապա այն կարող է անմիջապես մշակվել այս տարբերակի համար (և չի ներառվի նախորդի մեջ): Horizon - մինչև 2.2.4-ի թողարկումը կամ մինչև 2017 թվականի վերջը:

Օգտագործելով «1C: Application Design System» արտադրանքը ERP-ի մշակման մեջ

Ինչպես արդեն նշվեց, մենք 1C-ում փորձում ենք հետևել Eat your own dogfood-ի սկզբունքին՝ օգտագործելով մեր սեփական արտադրանքը մեր ներքին ընթացակարգերում: Մասնավորապես, ERP-ի մշակման ժամանակ մենք լայնորեն օգտագործում ենք «1C: Application Design System» (կրճատ DSS) արտադրանքը: DSS-ը, ինչպես ենթադրում է անունը, օգնում է նախագծել կիրառական լուծումներ 1C:Enterprise հարթակում և թույլ է տալիս սպասարկել ծրագրային ապահովման մշակման ամբողջական ցիկլի առաջադրանքները՝ պահանջների հավաքում, փոփոխության վերահսկում, փաստաթղթեր, սխալների հետևում և այլն:
DSS-ը թույլ է տալիս ստեղծել երկու տեսակի տարրեր՝ սխալներ (որոնք պետք է շտկվեն) և պահանջներ (նոր ֆունկցիոնալության հարցումներ): Ամեն ինչ քիչ թե շատ պարզ է սխալներով, եկեք մտածենք նոր պահանջ ստեղծելու մասին։
Պահանջ ստեղծելու պատճառը կարող է լինել.

1. Հարցում գործընկերոջից կամ հաճախորդից. Մենք հավաքում ենք նման հարցումներ, մասնավորապես, գործընկեր սեմինարների ժամանակ. քվեարկելով գործընկերների միջև՝ մենք ընտրում ենք նրանցից ամենաառաջնայինը:
2. Պիլոտային ծրագրի ընթացքում կարող է առաջանալ նոր տարբերակ ներկայացնելու հարցում, եթե հաճախորդն ունի իր համար կարևոր ցանկություն:
3. Մեր տեխնիկական աջակցության թիմի խնդրանքը (ավելի ճիշտ՝ մեր տեխնիկական աջակցության միջոցով անցած գործընկերոջ կամ հաճախորդի խնդրանք), հարցում մեր գործընկեր ֆորումից կամ մեր հաշվի մենեջերից (ով ուղեկցում է մեզ համար կարևոր հաճախորդին/հաճախորդներին):
4. Հարցում 1C:Enterprise հարթակի մշակման թիմից: Պլատֆորմի թիմը հարցնում է ERP մշակման թիմին (և այլ բնորոշ կոնֆիգուրացիաներ) օգտագործել նոր հարթակի ֆունկցիոնալությունը, օրինակ՝ Taxi ինտերֆեյսը, մոդալ պատուհանների մերժումը, համաժամանակյա զանգերի մերժումը և այլն։
5. Refactoring, ճարտարապետության օպտիմալացում, օգտագործելիության բարելավում:

Վերամշակման (կետ 5) պատճառ կարող են լինել ճարտարապետական ​​լուրջ փոփոխությունները (օրինակ՝ առաքման պատվերների վերանայումը, երբ հաշիվ-ապրանքագրերի փոխարեն սկսեցին օգտագործվել պատվերներ)։

DSS արտադրանքը մատակարարվում է որպես ERP-ի մաս (բայց այն կարելի է նաև առանձին գնել): ERP լուծումը կարող է գործարկվել DSS ինտեգրման ռեժիմում; Այս դեպքում յուրաքանչյուր ձև կունենա «Բացել ֆունկցիոնալ մոդել» կոճակը, երբ այն սեղմվի, կբացվի ձևի ֆունկցիոնալության նկարագրությունը DSS-ում:


Ահա թե ինչ է բացվում. սա աշխատավայրի մոդելն է IDEF0-ում.


Հնարավոր է, և հակառակը, ուսումնասիրել ֆունկցիոնալ մոդելը և դրանից բացել աշխատատեղերի ձևերը։ Այս ռեժիմը կարող է օգտագործվել ծրագրի աշխատանքը ուսումնասիրելիս:
Կարևոր կետ. DSS-ը չէ, որ բացվում է, բացվում է ERP-ի ներսում գտնվող ձևը, որտեղ բեռնվում են տվյալները DSS-ից: Նրանք. ինտեգրումը «անխափան» է (օգտագործողը դա չի տեսնում): Այս տեխնիկան օգտագործվում է այլ ապրանքների հետ ինտեգրվելիս: Օրինակ՝ 1C:Document Management-ով (կարող եք աշխատել առանց ERP-ից դուրս գալու փոստով, առաջադրանքներով, բիզնես գործընթացներով, որոնք աշխատում են մեկ այլ տվյալների բազայում):

Ինչպես ենք մենք մշակում ERP. Ծրագրի 6 հիմնաքար

Այսպիսով, որոշվեց կիրառել նոր պահանջ՝ ֆունկցիոնալությունը փոխելու համար։ Նույն տեսակի պահանջները միավորվում են տեխնիկական նախագծերում: Որպես նոր ERP թողարկման մաս, սովորաբար իրականացվում է 100-ից 150 տեխնիկական նախագիծ, յուրաքանչյուր նախագիծ՝ մեկից մինչև մի քանի տասնյակ պահանջներ: Տեխնիկական նախագիծը մուտքագրված է DSS; Նախագիծն իրագործման ընթացքում անցնում է 6 հսկիչ կետերով, որոնցից յուրաքանչյուրը գրանցվում է DSS-ում:
Մի փոքր ERP բաժնի շրջանակներում թիմերի բաժանման մասին: Թիմի ղեկավարը (թիմի ղեկավարը) ներգրավված է նախագծման մեջ և, որպես կանոն, մասնակցում է մշակմանը։ Թիմը սովորաբար ներառում է նաև փորձարկողներ: Զարգացման թիմերը ստատիկ են, դրանք նշանակված են մի քանի առարկայական ոլորտների: Եթե ​​ծրագիրն ազդում է հարակից տարածքների վրա, համապատասխան թիմի անդամները ներգրավվում են ծրագրի տևողության ընթացքում: Ոչ ամբողջ թիմը կարող է ներգրավված լինել նախագծում:
Ծրագրի պատասխանատուն առաջատար մշակողն է կամ թիմի ղեկավարը: Նրա պարտականությունն է վերահսկել գործընթացները.

• Բարձրորակ դիզայն՝ հաշվի առնելով բոլոր տեսակի սցենարները, հարակից բլոկների հետ ինտերֆեյս
• Ժամկետավորում
• Ճարտարապետության որակ, օգտագործողի միջերես
• Հղում գրելը, նախագծի նախագծումը, ներառյալ. ֆունկցիոնալ մոդելի մշակում

Կետ 1. Ծրագրի բացում

Թիմի առաջատարը սկսում է տեխնիկական նախագծերը DSS-ում՝ որպես թողարկման ցուցակ: Յուրաքանչյուր նախագծում ուրվագծվում են նպատակները, նշվում են իրագործելի պահանջները: Ցանկը քննարկվում է զարգացման մենեջերի հետ մինչև թողարկման աշխատանքները սկսելը: Փաստորեն, նախագիծ բացելիս հանդիպումներ չեն անցկացվում, ուղղակի նախագիծն ուղարկում են DSS բացման։
Ծրագրի թիմը սկսում է հայեցակարգի մշակումը:

Կետ 2. Հայեցակարգի շուրջ համաձայնություն

Հայեցակարգի շուրջ համաձայնեցնելու համար անցկացվում է առցանց կամ օֆլայն հանդիպում, որին մասնակցում են ծրագրի պատասխանատուն, թիմի ղեկավարը, զարգացման մենեջերը և նախագծում ներգրավված մասնագետները։ Սովորաբար, այս փուլում ծրագրի համար պատասխանատու անձի մոտ պատրաստ է «մեծ բլոկի» հայեցակարգը, որը վերջնական տեսքի է բերվում հանդիպման ընթացքում: Սցենարները և օգտագործողի միջերեսի նկարագրությունը նույնպես քննարկվում են (և գրված են DSS-ում): Եթե ​​պահանջը ծագել է գործընկերների կամ հաճախորդների խնդրանքից, ապա ծրագրի նյութերը (հայեցակարգեր, սցենարներ, UI) կարող են ուղարկվել գործընկերոջը/հաճախորդին՝ լուծումը գնահատելու համար:
Հանդիպման ընթացքում համաձայնեցվում է նախատիպի ստեղծման բարդությունը (սովորաբար նախատիպի ստեղծումը տևում է մինչև 5 աշխատանքային օր): Թիմը սկսում է նախատիպի կառուցումը։

Կետ 3. Նախատիպերի համակարգում

Անցկացվում է հանդիպում, որի ընթացքում քննարկվում են պատրաստի նախատիպերը, քննարկվում են իրականացման մանրամասները (մասնավորապես, թե որ օբյեկտներն են ավելացվելու և փոխվելու), վարկածների փորձարկում, նախատիպերի հաստատում և այլն։ Օգտագործելիությունը հնարավորինս լրջորեն փորձարկելու համար նախատիպերը գործարկվում են ամենա«կոշտ» ռեժիմով` վեբ-հաճախորդում, Taxi ինտերֆեյսում, ցածր լուծաչափով մոնիտորների վրա:
Նախագծի ֆունկցիոնալ մոդելը IDEF0 նշումով մշակվում և պահվում է DSS-ում:
Այս փուլում ծրագրի թիմը պետք է հնարավորինս ճշգրիտ գնահատի աշխատանքային ծախսերը ծրագրի իրականացման համար, հետևաբար, ծրագրի բոլոր ասպեկտները քննարկվում են (և փաստաթղթավորվում են DSS-ում).

• Ծրագրի նկարագրության ճշտության համակարգում DSS-ում (մասնավորապես, վերահսկվում է, որ նախորդ ծրագրի հիմնաքարերի բոլոր առաջադրանքները կատարված են):
• Ինչ նոր մետատվյալների օբյեկտներ (տեղեկատուներ, փաստաթղթեր և այլն) կավելացվեն լուծմանը
• Ինչ փոփոխություններ են կատարվելու առկա մետատվյալների օբյեկտներում
• Տվյալների փոխանակման պլանների համակարգում այլ լուծումների հետ (արդյո՞ք նոր/փոփոխված տվյալները կներգրավվեն այլ հավելվածների հետ տվյալների փոխանակման մեջ, և եթե այո, ապա ինչպե՞ս)

Եթե ​​բոլորը գոհ են աշխատուժի ծախսերից, ներկայացվում է (հիմնված DSS ծրագրի նյութերի վրա) այն ամենը, ինչ արվել է նախագծի վրա, որպեսզի հնարավորինս շատ նրբերանգներ բացահայտվեն մինչև մշակումը սկսելը:
Եվ զարգացումը սկսվում է:

Կետ 4. Մշակված լուծման համակարգում

Լուծումը մշակվել է, պատրաստվել է շնորհանդես (PowerPoint ֆորմատով): Հաճախ հանդիպում է անցկացվում դեմ առ դեմ՝ մշակված լուծման «ուղիղ» ցուցադրմամբ:
Եթե ​​նախագիծը հրապարակային է (հրապարակված է 1C կայքում գործընկերներին հասանելի ծրագրերի ցանկում), ապա շնորհանդեսը տեղադրվում է գործընկերների ֆորումում ERP բաժնում, որպեսզի բոլոր շահագրգիռ գործընկերները կարողանան ծանոթանալ և արտահայտել իրենց մեկնաբանությունները:

Կետ 5. Նախագծի փորձարկում և աուդիտ

Հիմնական մշակման վերջում իրականացվում է ձեռքով ֆունկցիոնալ թեստերի շարք: Փորձարկողները, որպես թիմի լիիրավ անդամներ, մասնակցում են նախագծի բոլոր հանգրվաններին և հասկանում են նախագծի ֆունկցիոնալությունը և աշխատանքային սցենարները: Փորձարկողները նաև գնահատում են նոր ֆունկցիոնալությունը մեր օգտագործման ստանդարտներին համապատասխան: Այս ստանդարտները (ներառյալ կոդավորման ստանդարտները և ինտերֆեյսի մշակման ստանդարտները) հրապարակվում են 1C կայքում գործընկերների և գրանցված օգտվողների համար հասանելի ռեսուրսում:
Ծրագրի կոդը անցնում է կոդի վերանայման ընթացակարգով: Կոդի վերանայումը ERP-ում իրականացվում է մեկ այլ ծրագրի խմբի անդամների կողմից. Կոդի վերանայումը պարտականություն է, որն իր հերթին ունեն ERP թիմի բոլոր մշակողները: Եթե ​​կոդի մեջ խնդիրներ են հայտնաբերվում, ապա DSS-ում գրանցվում են սխալներ, որոնք պետք է ուղղվեն մինչև 5-րդ կետի ընդունումը:
Թարմացումը ստուգվում է նախորդից նոր տարբերակի համար (վերջինը՝ թողարկված այս պահինժողով):
Այսպիսով, նախագիծը պատրաստ է, թեստերն անցել են, ժամանակն է վերբեռնել կոդը հիմնական պահեստում (մինչ այդ ամբողջ մշակումն իրականացվում է առանձին տեխնիկական նախագծի պահեստում): Այս փուլում ավարտվում է նաև նոր ֆունկցիոնալության վրա տեղեկատու նյութերի գրելը (տեղեկանքը պահվում է DSS-ում):
Փուլի վերջում (անցած թեստերը և պատրաստ են տեղեկատու նյութերը), նախագիծը վերբեռնվում է հիմնական պահոց. Դրանից հետո իրականացվում է ընտրովի ռեգրեսիայի թեստավորում հարակից ոլորտներում. մենք պետք է համոզվենք, որ մենք ոչինչ չենք կոտրել առկա ֆունկցիոնալությունից:

Կետ 6. Նախագծի ավարտ

Մենք փակում ենք նախագիծը DSS-ում և տալիս «Ավարտված» կարգավիճակը:

Թողարկման տարբերակը

Նոր թողարկման թողարկումից մոտ մեկ ամիս առաջ մորատորիում է սահմանվում նոր նախագծերը հիմնական պահեստ բեռնելու համար (տեխնիկական նախագծերի շտեմարանների մշակումը շարունակվում է); այն նախագծերը, որոնք մինչ այս պահը չեն հասցրել ավարտվել, տեղափոխվում են այլ տարբերակ:
Այս ամսվա ընթացքում իրականացվում է ռեգրեսիոն թեստավորում. Կոդի փոփոխությունները թույլատրվում են միայն այս թողարկումում ներկայացված սխալները շտկելու համար: Չներդրված սխալները (նրանք, որոնք վերարտադրվել են նախորդ թողարկումներում), ռեգրեսիայի փորձարկման սկզբում, սովորաբար գրեթե բոլորը շտկվում են. նույն սխալները, որոնք մնացել են, տեղափոխվում են հաջորդ թողարկում: Ռեգրեսիոն փորձարկման հիմնական խնդիրն է ապահովել, որ արտադրանքի որակը չվատանա:
Ինչպես արդեն նշվեց, նույն DSS-ն օգտագործվում է որպես սխալների հետագծող:

Ուղղիչ շինություններ

Երկու շաբաթը մեկ մենք թողարկում ենք շտկված կառուցումներ տարբերակների համար. այսօր 2.1.3.x է, 2.2.1-ի թողարկումից հետո կթողարկվի 2 ֆիքս բիլլս՝ 2.1.3.x և 2.2.1.x։ Սխալը ներկայացնելուց մինչև շտկված թողարկումում հայտնվելը մեզ տևում է երկու շաբաթից պակաս: Մեր վիճակագրությունը ցույց է տալիս, որ հաճախորդի կողմից սխալմամբ ERP աջակցության հետ կապվելու պահից մինչև այսօր շտկման ծրագրում շտկման թողարկումը միջին ժամանակն է 9 օր:

Ճյուղավորված զարգացում

ERP-ի վրա խմբային աշխատանքի ընթացքում մենք փորձում ենք օգտագործել 1C:Enterprise հարթակի կողմից մեզ տրամադրված գործիքները։ Կազմաձևերը պահվում են կոնֆիգուրացիայի խանութում, և երբ նոր ֆունկցիոնալությունը ստուգվում է մասնաճյուղում, օգտագործվում է ստանդարտ առաքման և աջակցության մեխանիզմը: Բոլոր գործողությունները առավելագույնս ավտոմատացված են. եթե օբյեկտները փոխվել են միայն մշակողի կողմից, ապա կոդը միաձուլվում է առանց ծրագրավորողի մասնակցության: Եթե ​​աղբյուրների միաձուլման համար անհրաժեշտ է մշակողի միջամտություն, մենք սովորաբար օգտագործում ենք հարթակի ներկառուցված հնարավորությունները: Բայց կա նաև երրորդ կողմի տարբերվող/միաձուլման գործիքներ պլատֆորմի գործիքներից (օրինակ, Արաքսիսից) կանչելու հնարավորություն։ Ի դեպ, այս ֆունկցիան՝ կանչելով երրորդ կողմի համեմատման/միաձուլման գործիքները, ավելացվել է հարթակում՝ ERP մշակողների թիմի խնդրանքով:

Տարբեր

Նոր գործառույթներ մշակելիս մենք օգտագործում ենք հարթակի այն տարբերակը, որը հասանելի կլինի ERP-ի նոր տարբերակի թողարկման պահին (այսօր այն 8.3.8 հարթակն է):
Դա հնարավոր է շնորհիվ այն բանի, որ հարթակը ակտիվորեն օգտագործում է աջակցության ռեժիմը համատեղելիության համար նախորդ տարբերակները. Հենց նոր հարթակ է հայտնվում, մենք անցնում ենք դրան, սակայն համատեղելիության ռեժիմն անջատելը անմիջապես չի լինում։ Դա պայմանավորված է երեք պատճառով.

1. Մենք ցանկանում ենք ավելի քիչ «ցնցել» օգտատերերին, ուստի փորձում ենք անջատել համատեղելիության ռեժիմը «հանգիստ» ժամանակաշրջաններում, այլ ոչ թե երբ, օրինակ, բոլոր օգտատերերը հաշվետվություններ են ներկայացնում:
2. Սովորաբար համատեղելիության անջատումը կապված է տարբեր կազմաձևման փոփոխությունների հետ: Դրանք պետք է պլանավորել, դրանք իրականացնելու համար ժամանակ է պահանջվում։
3. ERP-ն կոնֆիգուրացիա է, որը ներկայումս ներառում է 10 գրադարան: Դուք կարող եք անջատել համատեղելիությունը միայն այն դեպքում, երբ դա անում են նաև բոլոր գրադարանները:

Գրադարանները կարող են գրվել առանձին: Գրադարանը հատուկ գրված կոնֆիգուրացիա է, որը ներառում է գործառույթներ, որոնք պետք է նույն կերպ աշխատեն մեր տարբեր վերջնական կիրառական լուծումներում: Գրադարանների ինտեգրումն իրականացվում է «Կոնֆիգուրացիայի առաքում» հարթակի արդեն նշված մեխանիզմի միջոցով։ Գրադարանները բաժանված են հրատարակվածների (դրանց, որոնք մենք հրապարակում ենք, և որոնք երրորդ կողմի մշակողները կարող են օգտագործել իրենց կիրառական լուծումներում) և ներքին (որոնք մենք առանձին չենք հրապարակում, միայն որպես կիրառական լուծումների մաս): Գրադարանների ճնշող մեծամասնությունը հրատարակված է։
ERP-ն ներառում է 10 գրադարաններ, որոնք մշակվել են այլ թիմերի կողմից: Նրանց կոդը չի փոխվում ERP թիմի մշակողների կողմից:

Գրադարանների ցանկ

1. Ստանդարտ ենթահամակարգերի գրադարան:
   Հիմնական ֆունկցիոնալությունը - մուտքի իրավունքներ, տպագրություն, փոստ և այլն: Ներառված է կիրառական լուծումների մեծ մասում:
2. ERP-ում
3. Ինտերնետ օգտագործողների աջակցության գրադարան:
   Տեղեկացնելով թարմացումների թողարկման մասին, կապ հաստատել նրանց հետ։ աջակցել, ներբեռնել և տեղադրել թարմացումներ
4. Էլեկտրոնային փաստաթղթերի կառավարման գրադարան:
   Փոխանակում էլեկտրոնային փաստաթղթերԿոնտրագենտների հետ (ներառյալ օրինական նշանակության EDI), DirectBank (ուղղակի փոխանակում բանկերի հետ), փոխանակում կայքերի հետ (CMS):
5. EGAIS-ի հետ ինտեգրման գրադարան:
   Փոխանակում Միասնական պետական ​​ավտոմատացված տեղեկատվական համակարգի հետ ալկոհոլի մանրածախ շրջանառության հաշվապահական գործառնությունների համար:
6. Կարգավորվող հաշվապահական հաշվառման գրադարան:
   «Piece» 1C: Հաշվապահական հաշվառում ERP-ում: Ընդհանուր առմամբ, կարգավորվող հաշվապահությունը ERP-ում մեթոդաբանական մասում (որոշ աննշան բացառություններով) նման է 1C: Հաշվապահական հաշվառմանը, բայց դրա իրականացումը տարբեր է և կատարվում է ինքնուրույն: 1C-ից. Հաշվապահություն մենք վերցնում ենք հաշվապահական հաշվետվություններև որոշակի հարկերի վերաբերյալ հաշվետվություններ:

Ինչպես ենք մենք փորձարկում 1C:ERP

ERP-ից երեք լուծում ստեղծելուց հետո՝ KA, UT, UT Basic, բոլոր չորս լուծումների ճիշտությունը ստուգելու համար մենք անցկացնում ենք ստացված կոնֆիգուրացիաների ստատիկ և դինամիկ վերլուծություն:
Մասնակի ստատիկ վերլուծություն է կատարվում ամեն անգամ, երբ KA, UT, UT հիմնական կոնֆիգուրացիաները ստեղծվում են ERP պահեստից և վերբեռնվում իրենց սեփական պահեստներում (այս գործընթացը տեղի է ունենում օրական երկու անգամ):
Ավելի մանրամասն ստատիկ վերլուծություն է կատարվում՝ օգտագործելով 1C:Automatic Configuration Checker (1C:APK) կոնֆիգուրացիա: Մասնավորապես, 1C:APK-ն ստուգում է.

• Դերերի կազմը. Օրինակ, այն ստուգում է, որ բոլոր հաստատունները կարդալու իրավունքները ներառված են «Հիմնական իրավունքներ» դերում:
• Օրենսգրքի համապատասխանությունը ընդունված ստանդարտներին: Համար մեծ թվովԳրվել են հավելվածների մշակման ստանդարտները (որոնցից ունենք մի քանի հարյուր), դրանց համապատասխանության կոդի վերլուծության ընթացակարգերը։ Օրինակ, որ ամբողջական միացումները չեն օգտագործվում հարցումներում, կամ որ ինտերֆեյսում ցուցադրվող տողերը ճիշտ տեղայնացված են:
• ERP մշակման առանձնահատկությունների հետ կապված հատուկ ստուգումներ
  Օրինակ՝ ստուգելով, որ յուրաքանչյուր հավելվածի օբյեկտ ներառված է «UT, KA, UE օբյեկտներ», «KA, UE օբյեկտներ» կամ «UE օբյեկտներ» ենթահամակարգերից մեկում։

Դինամիկ կոդի վերլուծությունը ներառում է, մասնավորապես, ռեգրեսիոն փորձարկում, որի ժամանակ կատարվում են հետևյալ գործողությունները (և գործողությունների արդյունքները ստուգվում են նախորդ վերջին հաջող թեստի համեմատ).

• Բոլոր ձևերի բացում
• Տվյալների փոխանակում այլ կիրառական լուծումների հետ (օրինակ, 1C-ով: Ձեռնարկությունների հաշվառում)
• Տեղադրված փաստաթղթերի արտացոլումը հաշվապահության մեջ: Ստուգվում է, որ փաստաթուղթը տեղեկատու տվյալների բազայում տեղադրելուց հետո հաշվապահական հաշվառման մեջ դրա արտացոլման արդյունքը չի փոխվել։
• Եվ այլն:

Հետադարձ փորձարկման համար մենք օգտագործում ենք 10-ից 20 տվյալների բազա՝ տարբեր չափերի (15 ԳԲ-ից մինչև 70 ԳԲ) և տարբեր բովանդակության առանձնահատկությունների:
Նույն հիմքերի վրա մենք փորձարկում ենք թարմացումը նախորդից նոր տարբերակի վրա, որպեսզի համոզվենք, որ թարմացումը կատարվում է ա) ճիշտ և բ) ողջամիտ ժամկետում։
1C տվյալների բազան թարմացնելիս կան երկու էական քայլ.

1. Հիմնական ժամանակը տվյալների թարմացումն է բազմաֆունկցիոնալ ռեժիմում: Հավելվածը պատրաստում է տվյալները ֆոնային ռեժիմում թարմացման համար, օգտատերերը կարող են շարունակել աշխատել համակարգի հետ, սակայն համակարգի աշխատանքը կարող է կրճատվել, իսկ որոշ գործառույթներ կարող են սահմանափակ գործել: Սովորաբար, նոր տարբերակի թարմացումն իրականացվում է հանգստյան օրերին (երբ օգտագործողի ակտիվությունը նվազագույն է):
2. Նվազագույն ժամանակ - թարմացում բացառիկ ռեժիմով: Երբ բոլոր տվյալները պատրաստվում են հետին պլանում, ժամանակն է փոխել տվյալների բազայի կառուցվածքը: Դա անելու համար տվյալների բազան փոխանցվում է բացառիկ ռեժիմի, երբ օգտվողները չեն կարողանում աշխատել համակարգի հետ: Թարմացման արագությունը չափազանց կարևոր է մեր օգտատերերի համար:

Առաջիկայում նախատեսում ենք ընդլայնել ավտոթեստավորման գոտին՝ դրանք ծածկելու համար առավելագույն գումարըսցենարներ.

Եզրակացություն

ERP-ն մեր ամենամեծ արտադրանքներից մեկն է: Մենք փորձում ենք դրա մշակման մեջ կիրառել ժամանակակից և առաջադեմ մեթոդներ, ինչպես նաև ստեղծել նոր մեթոդներ և գործիքներ՝ մի կողմից այն արագ զարգացնելու, մյուս կողմից՝ մշակված լուծման բարձր որակն ապահովելու համար։

Tags:

Ավելացնել պիտակներ

30.03.2017

Ֆունկցիոնալ տարբերակներ 1C 8.3 (մեխանիզմ, օգտագործում)

Սկսել կարևորնշեք, որ գործառույթի ընտրանքների մեխանիզմը ՉԻսահմանափակում է տվյալների հասանելիությունը, բայց միայն վերահսկում է ձևի տվյալների տեսանելիությունը (ցուցադրումը): Պլատֆորմում գտնվող օբյեկտների հասանելիությունը սահմանափակելու համար օգտագործվում է դերերի մեխանիզմը:
Հետևաբար, մենք սկսում ենք ֆունկցիոնալ տարբերակների մեխանիզմի մեր դիտարկումը խնդրի նկարագրությամբ: Մեր մինի-կոնֆիգուրացիայի մեջ կա մեկ գրացուցակ «Պահեստներ»: Ենթադրենք, որ բոլոր օգտվողները մուտք ունեն այս գրացուցակը:
Կրկին! Ֆունկցիոնալ ընտրանքների մեխանիզմը վերահսկում է տվյալների ցուցադրումը ձևի վրա և չի սահմանափակում մուտքը դեպի մետատվյալների օբյեկտ (տեղեկատու, փաստաթուղթ, ռեեստրի գրառումներ….) Անհրաժեշտ է կատարել «Օգտագործել բազմաթիվ պահեստներ» պարամետրը: (Այո, այո ... Դա UT 11.X-ում է, այնտեղ արված է կազմակերպությունների համար). Եթե ​​մենք օգտագործում ենք մի քանի պահեստ, ապա ինտերֆեյսում հասանելի է պահեստի գրացուցակը, եթե ոչ, ապա հրամանը, որը բացում է մեկ պահեստ (ենթադրում ենք, որ այս դեպքում կա միայն մեկը, և չենք բարդացնում առաջադրանքը):

Կազմաձևման մետատվյալների օբյեկտներ

Այս առաջադրանքն իրականացնելու համար մեզ անհրաժեշտ է.

• Երկու ֆունկցիոնալ տարբերակ «UseMultipleWarehouses» և «Do NotUseMultipleWarehouses»: Առաջինը պատասխանատու է գրացուցակի առկայության համար, իսկ երկրորդը՝ պահեստը «բացելու» ալգորիթմը կանչելու ընդհանուր հրամանի առկայության համար։
• Ֆունկցիոնալ ընտրանքների արժեքները պահելու համար «Բուլյան» տիպի համանուն հաստատուններ
• տեղեկատու «Պահեստներ»
• «Բաց հիմնական պահեստ» գլխավոր հրամանատարություն. Մի մոռացեք դրա համար նշել հրամանների խումբ, հակառակ դեպքում մի կիրառեք կոնֆիգուրացիան (սխալ կլինի)

Եվ ավելացրեք մեկ ենթահամակարգ, որտեղ մենք ներառում ենք բոլոր առկա օբյեկտները

Ֆունկցիոնալ ընտրանքների կարգավորում

Առաջին տարբերակը «Օգտագործեք բազմաթիվ պահեստներ»: Արժեքը պահվում է նույնանուն հաստատունում, ներառված է «Պահեստներ» գրացուցակը։ Այսպիսով, երբ հաստատունի արժեքը «True» է, գրացուցակը հասանելի է ինտերֆեյսում, սխալի դեպքում գրացուցակը նույնպես չի ցուցադրվի ինտերֆեյսում (ենթահամակարգերի բովանդակությունը, օբյեկտի ձևերը և այլն):

Երկրորդ «Մի օգտագործիր MultipleWarehouses» գործառույթը սահմանվում է, երբ առաջին «UseMultipleWarehouses»-ը ՉԻ դրված:
Նրանք. եթե մենք չենք օգտագործում մի քանի պահեստներ (UseMultipleWarehouses = FALSE և «Warehouses» որոնումը հասանելի չէ), ապա ցուցադրվում է «Open MainWarehouse» հրամանը, որի հասանելիությունը վերահսկվում է «Do not UseMultipleWarehouses» տարբերակով (Do notUseMultipleWarehouses = ՃԻՇՏ)

Համակարգի վարքագծի ստուգում

Տարբերակ թիվ 1. UseMultipleWarehouses = True, Do NotUseMultipleWarehouses = False: «Պահեստներ» գրացուցակը հասանելի է միջերեսում

Տարբերակ թիվ 2. UseMultipleWarehouses = False, Do NotUseMultipleWarehouses = True: «Պահեստներ» տեղեկագիրքը հասանելի չէ միջերեսում, փոխարենը հասանելի է «Բաց հիմնական պահեստ» ընդհանուր հրամանը:

Function Options-ը մետատվյալների օբյեկտ է, որը գտնվում է «Ընդհանուր» խմբում.

Ֆունկցիոնալ ընտրանքները ֆունկցիոնալ ընտրանքների մեխանիզմի մի մասն են, որոնք թույլ են տալիս միացնել կամ անջատել որոշ գործառույթներ հավելվածի լուծման մեջ՝ կախված օգտագործողի կարիքներից՝ առանց ինքնին կոնֆիգուրացիան փոփոխելու:
Օրինակ, ամեն կազմակերպություն չէ, որ կարող է օգտագործել գույքագրման վերահսկողությունը: Եթե ​​պահեստի հաշվառումը չի օգտագործվում, ապա իմաստ ունի հեռացնել պահեստի դաշտը բոլոր փաստաթղթերում, գրացուցակներում և գրանցամատյաններում, ապա ֆունկցիոնալ տարբերակները գալիս են մեզ օգնության:

Դիտարկենք օրինակ.

Եկեք ստեղծենք ֆունկցիոնալ տարբերակ» Պահեստի հաշվառում".
Պահպանում. նշված է արժեքը պահող դաշտը:
Դուք կարող եք ընտրել հաստատուն, գրացուցակի հատկանիշ կամ տեղեկատվական ռեգիստրի ռեսուրս:
Մենք կօգտագործենք հաստատուն.

Եկեք ստեղծենք հաստատուն» Պահպանեք հաշվապահությունը պահեստներումև ընտրեք այն պահեստավորման դաշտում: Այս հաստատունը պատասխանատու կլինի ֆունկցիոնալ տարբերակը միացնելու և անջատելու համար: Սահմանեք վանդակը «Արտոնյալ ռեժիմ ստանալիս»: Այս վանդակը նշանակում է, որ ֆունկցիոնալ տարբերակի արժեքները կստացվեն արտոնյալ ռեժիմով: :

Մենք թարմացնում ենք, գործարկում ենք 1C Enterprise-ը։ Սահմանեք հաստատունի արժեքը = True:

Արդյունքում մենք ունենք.

Հաստատուն = False սահմանելիս մենք ստանում ենք.

Հարց ունե՞ք, խորհրդատուի օգնության կարիք ունե՞ք։

Այսպիսով, մենք ստեղծել ենք ֆունկցիոնալ տարբերակ, որը կառավարում է DirectoryLink.Warehouse տիպի դաշտերը

Այժմ նայենք ֆունկցիայի ընտրանքների պարամետրերի օգտագործման օրինակին:
Ավելացնենք նոր ֆունկցիոնալ տարբերակ» Արժութային հաշվառում"
Պահպանում: Directory.Organization.Props.Արժութային հաշվառում

Կազմում ավելացնենք «Սահմանել ապրանքների գներ» - «Արժույթ» փաստաթղթի մանրամասները.

Փաստաթղթի տեսքով «CreationAtServer» և «OnChange» ընթացակարգերում
Ավելացնենք հետևյալ կոդը.

Թարմացրեք կոնֆիգուրացիան և գործարկեք այն:
Մենք ստեղծում ենք երկու Կազմակերպություն և դրանցից մեկի համար նշում ենք «Արժութային հաշվառում» վանդակը

Ի՞նչ ենք մենք ստանում արդյունքում։ Ֆունկցիոնալ տարբերակի պարամետրերն օգտագործելու արդյունքում ես և դուք ստացանք «Արժույթ» դաշտի պարամետրային կառավարում «Սահմանել ապրանքների գները» փաստաթղթում։ Նրանք. Ալֆա կազմակերպության համար կցուցադրվի Արժույթի դաշտը, իսկ Բետա կազմակերպության համար՝ Արժույթի դաշտը չի ցուցադրվի:
Եկեք համոզվենք սրանում։ Բացեք փաստաթուղթը և փորձեք փոխել «Կազմակերպություն» դաշտը
org = "ալֆա" սահմանելիս ցուցադրվում է արժույթը. փոխել «Բետա» - արժույթը հանվում է