Ստանդարտ փոխանակման կանոններ. Զտել ըստ կազմակերպության

Եթե ​​դուք տվյալների փոխանակում եք առևտրի կառավարում 10.3 և ձեռնարկությունների հաշվապահական հաշվառում 2.0 կոնֆիգուրացիաների միջև, ապա կոնֆիգուրացիաներից մեկը թարմացնելուց հետո դուք պետք է թարմացնեք փոխանակման կանոնները:

Դիտարկենք այն դեպքը, երբ փոխանակումը կազմաձևվել է Առևտրի կառավարման կոնֆիգուրացիայից և կազմաձևվել է ստացողի բազայի հետ ուղղակի միացման միջոցով, այսինքն. հաշվապահական հաշվառման բաժին. Դուք պետք է բեռնեք նոր կանոններ Առևտրի ադմինիստրացիայի տվյալների փոխանակման կարգավորումների միջոցով: Դա անելուց առաջ խիստ խորհուրդ է տրվում հիմքեր պատրաստել:

Գործարկում է 1C Trade Management 10.3. Ընտրեք «Տվյալների փոխանակման բոլոր կարգավորումները» կետը Ծառայություն => Այլ տվյալների փոխանակումներ ցանկից:

Մենք ընտրում ենք «Բոլոր փոխանակումները» բաժինը: Գտեք ձեր տվյալների փոխանակումը ցանկում, սեղմեք աջը և սեղմեք «Փոխել»: Եթե ​​փորձեք փոխել փոխանակման կարգավորումները «Տվյալների փոխանակում 1C. Հաշվապահություն 8» բաժնից, ապա երբ փորձեք փոխել տվյալների փոխանակման կարգավորումների օգնականը կգործարկվի, որը մեզ պետք չէ:

Բացվող պատուհանում մենք տեսնում ենք, որ փոխանակումը տեղի է ունենում փոխանակման կանոնների համաձայն, որոնք կարող են պահպանվել և բեռնվել: Բորսայի բազա վերբեռնելու կանոններն այն կանոններն են, որոնց համաձայն տեղեկատվությունը ներբեռնվում է Առևտրի վարչությունից հաշվապահական հաշվառման բաժին, իսկ փոխանակման բազայից ընթացիկ բազա վերբեռնելու կանոններն այն կանոններն են, որոնց համաձայն տեղեկատվությունը բեռնվում է Հաշվապահական հաշվառման բաժին Առևտրի վարչությանը:

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

Ոչ մի դեպքում մի փոխարինեք դրանք ստանդարտ կանոններով: Եթե ​​վստահ չեք, որ ունեք բնորոշ կոնֆիգուրացիաներ, ամեն դեպքում պահպանեք գոյություն ունեցող կանոնները՝ սեղմելով «Պահպանել կանոնները ֆայլում» կոճակը:

Քանի որ վերջինս դուրս եկավ Առևտրի կառավարման թարմացումից շատ ավելի ուշ, մենք փնտրում ենք փոխանակման կանոններ Հաշվապահական հաշվառման համար 1C թարմացման ձևանմուշների կատալոգում: Դուք կարող եք գտնել թարմացման ձևանմուշների գրացուցակը հետևյալ կերպ. Գործարկեք 1C-ը և սեղմեք «Կարգավորումներ»: Բացվող պատուհանում մենք տեսնում ենք կազմաձևման ձևանմուշների և թարմացումների գրացուցակի ուղին:

Մենք անցնում ենք այս ճանապարհով. Հաջորդը. 1C => Հաշվապահություն և ընտրեք թղթապանակը վերջին տեղադրված Հաշվապահական թողարկման անունով: Եթե ​​կանոնները պետք է վերցվեն 1C: Առևտրի կառավարման կոնֆիգուրացիայի թարմացումից, թղթապանակը կկոչվի Առևտուր: 1C-ի համար. Մանրածախ կոնֆիգուրացիա - Մանրածախ: Այն պարունակում է «Տվյալների փոխանակում» թղթապանակը:

Հետագա «Փոխանակում կոնֆիգուրացիայի հետ Առևտրի կառավարում, rev. 10.3": Դրանում մենք տեսնում ենք BP-UT-ի փոխակերպման կանոնները և UT-BP-ի փոխակերպման կանոնները: Քանի որ մեզ անհրաժեշտ են կանոններ UT-ից բեռնաթափման համար, ընտրեք «UT-BP CONVERSION RULES» և սեղմեք բաց: Մենք նույնն ենք անում փոխանակման բազայից ընթացիկ բազա բեռնաթափելու կանոնների դեպքում, միայն ընտրում ենք ֆայլը RULES FOR CONVERSION BP-UT և սեղմում բաց:

Պանակում «Փոխանակում կոնֆիգուրացիայի հետ Առևտրի կառավարում, խմբ. 10.3 ”-ը Sharing.htm ֆայլն է: Եթե ​​երբեք չեք կարդացել, անպայման կարդացեք։ Այն պարունակում է հետևյալ օգտակար տեղեկատվությունը.

• Նպատակների փոխանակում
• ընդհանուր նկարագրությունը
• Տեղափոխում Legacy երկկողմանի տվյալների փոխանակումից
• Նախնական գործողություններ
• Կազմաձևերի միջև տվյալների փոխանակումը կարգավորելու կարգը
• Տվյալների համաժամեցում
• «Առևտրի կառավարում» և «Ձեռնարկությունների հաշվառում» կոնֆիգուրացիաների համատեղ աշխատանք
• Օգտագործողի սցենարների օրինակ
• Վերբեռնված փաստաթղթերի համապատասխանության աղյուսակ UT - BP (revision 1.6, revision 2.0) Վերբեռնված փաստաթղթերի համապատասխանության աղյուսակ BP (revision 1.6, revision 2.0) - UT
• Փաստաթղթերի և գրացուցակների բեռնաթափման առանձնահատկությունները
• Վերբեռնված փաստաթղթերի համապատասխանության աղյուսակ BP (փոփոխություն 1.6, վերանայում 2.0) - UT
• «Գնորդին վճարման հաշիվ ապրանքագիր» և «Գնորդի պատվերը» փաստաթղթերի փոխանցում.
• Ապրանքների դուրսգրման արժեքի փոխանցում
• Տվյալների փոխանակման արդյունքների մոնիտորինգ

Մենք ստուգում ենք կանոնները ստուգման կոճակներով: Եվ սեղմեք OK: Նոր կանոնները պահպանվել են։ Մենք սկսում ենք տվյալների փոխանակումը և ստուգում նրանց աշխատանքը։

Ինչպես ստեղծել երկկողմանի տվյալների փոխանակում Առևտրի կառավարում 10.3 և Ձեռնարկությունների հաշվառում 2.0 կոնֆիգուրացիաների միջև, նկարագրված է իմ մյուս հոդվածում:

Հարց. Փոխանակման պատրաստի կանոններ բնորոշ կոնֆիգուրացիաների համար

Բոլորին բոլորին բոլորին: Փնտրում եմ պատրաստի փոխանակման կանոններ բնորոշ կոնֆիգուրացիաների համար երկու ուղղություններով փոխանցելու համար ոչ միայն տեղեկատուներ, այլ նաև փաստաթղթեր, փաստաթղթերի մնացորդներ և այլն: Գուցե ինչ-որ մեկը կիսվի։ Փնտրում եմ շատ բեռնաթափում ըստ փաստաթղթերի և PUB 7.7 UPP 8 rev 1.2-ում, առևտրից 7.7-ից մինչև UPP-ն աշխատավարձից 7.7 UPP, առևտրի մենեջմենթից 8-ից մինչև UPP 8. Կանխավ շնորհակալություն բոլորին։

Պատասխան.

փնտրում եմ փոխանակման կանոններ 1C 8.1 UPP 1.2-ի հետ 1C 8.2 UPP 1.3-ի միջև

Հարց. Ծառայություն սովորական 1C կոնֆիգուրացիաների ստանդարտ ֆունկցիոնալությամբ

UT 11.4.1.254 (կամ կարող եք փոխարկել ERP, եթե դա ինչ-որ բանի օգնում է)

Որպես տիպիկ 1C կոնֆիգուրացիաների ստանդարտ ֆունկցիոնալություն, հաշվի առեք տպիչների վերանորոգումը, ավելի ճիշտ, նրանց հաճախորդների սպասարկումը (քանի որ 1C մեթոդաբանների առումով վերանորոգումն այն է, երբ նրանք սպասարկում են իրենց սեփական սարքավորումներ, ոչ հաճախորդներ)

Մեկ վարպետ՝ թե՛ գրասենյակում, թե՛ ճանապարհին։
Հաճախորդները զանգահարում են գրասենյակ իրենց վերանորոգման մասին, բայց ոչ մի տեղեկություն չի մուտքագրվում, տեսնելու բան չկա

Որպես վերջին միջոց, օգտագործեք այլ կոնֆիգուրացիայի այլ հիմք, բայց բնորոշ

Հիմնական թերությունը. ես իսկապես չեմ ուզում փոփոխություններ կատարել տիպիկ կազմաձևում և / օգտագործել անտիպ կոնֆիգուրացիաներ (մոդուլներ)

Պատասխան.

Ավելի շուտ թարմացնել, սովորաբար ERP-ում
Անցումը ՄԱԿ-ին տրիվիալ չէ... թե՛ փոքր, թե՛ խոշոր ձեռնարկությունների համար:
UT 11 - փոփոխված Bitrix մոդուլով, կայքում (առցանց խանութում) Bitrix - նույնպես սղոցված

Եվ պարզ չէ՝ ինչի՞ համար։
Վերևում գրել եմ
UT 11-ում ստեղծվում է վաճառքի պատվեր, որի հիման վրա = ավարտված աշխատանքի ակտ:
«Կատարված աշխատանքի մասին տեղեկատվությունը հաճախորդի պատվերի մեջ կարող է ներառվել վաճառվող ապրանքների կամ վաճառքի ժամանակ մատուցվող ծառայությունների մասին տեղեկատվության հետ միասին»։

Կարող է բարդանալ երկարաժամկետ նախագծերի ֆունկցիոնալությամբ (հաճախորդի հետ փոխգործակցության իրադարձություններ և փուլեր)

Հաճախորդի հետ քննարկումներից պարզվեց, որ անհրաժեշտ է հաշվառում ըստ սերիական համարների, ինչը հասանելի է նաև UT 11-ում։
Պարզապես պետք է միացնել և կարգավորել UT 11-ում

Նայեցի UNF-ն ու բացի հավելյալ խնդիրներից ոչ մի հրաշք չգտա

Այս հարցում ինձ միայն հիասթափեցրեց այն փաստը, որ ես սկսեցի «գրական ակնարկ» անել, թե ինչպես է դա արվում UT - ERP-ում և ինչպես է այն լուծվում.
- այլ բնորոշ կոնֆիգուրացիաներով
- մասնագիտացված անհատական ​​արդյունաբերության կոնֆիգուրացիաներ
- մոդուլներ UT 11-ի համար
, այսինքն. Ես չափազանց ծույլ էի փորձել և շարժել ուղեղս

Վերցրեք այն, օգտագործեք այն, երբ իմանաք, թե ինչպես կամ ինչ-որ մեկն արդեն ստեղծել է, ցույց է տվել
(օրինակ, ստանդարտ ցուցադրական հիմքերում - նայելու բան չկա, ինչ-որ բան պատրաստ է նմուշի համար)
.
Միայն մի քիչ պետք էր հղկել UT - ERP-ում եկամուտների և ծախսերի հաշվառման և բաշխման հմտությունները, իսկ ՄԱԿ-ում, ընդհանուր առմամբ, անհրաժեշտ է ամբողջ հաշվապահական հաշվառումը նորովի ուսումնասիրել և գլուխը մի կողմից շրջել ցանկացած հարցում:

Հարց. Օբյեկտի հեռացում գոյություն ունեցող փոխանակման կանոնից

Խնդրում եմ, կարո՞ղ եք ինձ ասել, թե ինչպես հեռացնել օբյեկտը գոյություն ունեցող փոխանակման կանոնից: Փաստն այն է, որ միայն ապրանքների և ծառայությունների վաճառքն ու ստացումը պետք է որոշակի ամսաթվով բեռնաթափվեն մի բազայից մյուսը: Ինձ մոտ աշխատում է միայն ստեղծված կանոնն ինքնաբերաբար, ստեղծված կանոնը ձեռքով բեռնաթափում է դատարկ փաստաթղթերը։ Հետևաբար, ես կցանկանայի հեռացնել ավելորդ փաստաթղթերը ավտոմատ ստեղծված կանոնից, որպեսզի օգտվողները չկարողանան պատահաբար բեռնաթափել ինչ-որ սխալ:

Պատասխան.

Հաղորդագրություն Ալեքսեյ

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

Շնորհակալություն, ես կփորձեմ:

Կարելի է հեռացնել սովորական եղանակով

Հարց. Փոխանակման կանոններ. որտեղ խմբագրել:

Հաճախորդը փոփոխություններ է կատարել ընդունիչի կազմաձևում: Թե կոնկրետ ինչ է փոխվել, հնարավոր չի լինի պարզել։
Այժմ մենք պետք է շտկենք փոխանակման կանոնները:
Ինչպե՞ս կարող եմ տեսնել այն վայրերը, որոնք պետք է ճշգրտվեն:
Պետք է ինչ-որ կերպ հասկանալ գործող կանոններով, որ գույքն այլևս գոյություն չունի կամ փոխվել է դրա տեսակը։

Պատասխան.() Ինձ թվում է, որ հաճախորդին գոհացնելու համար բավական է ինչ-որ կերպ փոխանակում սկսել։ Իսկ վարձատրվելու համար պետք է ամեն ինչ անել մինչև վերջ :)

Հարց՝ «Առևտրի կառավարում», հրատարակություն 10.3 (10.3.46.2) Մանրածախ առևտրի փոխանակման կանոնների փոփոխություն 2.1.

Բարեւ Ձեզ. Ինչպե՞ս փոխել կանոնները UT-ում:
Փոխում եմ փոխանակման կանոնների դասավորությունը Exchange Plans-ում ExchangeRetaznitsaTrade Management103 Ես թարմացնում և վերագործարկում եմ՝ սխալ կանոններ: Ես նույնիսկ ձեռքով փոխել եմ տարբերակը։ Դա դեռ չի օգնում:
Հիմարաբար ջնջեց կանոնների մուտքը Տվյալների փոխանակման կանոնների ռեգիստրից:
Կանոնների ֆայլը բեռնելու կամ կազմաձևման դասավորությունից թարմացնելու նորմալ կոճակ չկա:
Շատ լրացումներ և փորձարկումներ կան անելու, բայց ես չգիտեմ, թե ինչպես արագ փոխել գրանցման / փոխանակման կանոնները (

Պատասխան.թարմացվել է իր, ամեն ինչ կարգին. Ամբողջ ուղեղն արդեն կերել է այս փոխանակումը

Հարց. Փոխանակման կանոնների փոխարինում վերբեռնման ֆայլում

Ամենայն բարիք։
Կա ֆայլ բեռնաթափում xmlփոխանակման կանոնների համաձայն. Համապատասխանաբար, այն պարունակում է բլոկ

<ПравилаОбмена> ...

Եվ կա երկրորդ ֆայլ, ինչպես այս բլոկի ձևանմուշը:
Անհրաժեշտ է վերբեռնման ֆայլում կանոնների բլոկը փոխարինել կաղապարի ֆայլի բլոկով։
Պետք է տարրական իմաստով կարդալ Reading XML և գրել երրորդ ժամանակավոր ֆայլի վրա Writing XML-ի միջոցով: Կամ կա՞ ավելի հարմար տարբերակ։

P.S. Ես ակնկալում եմ ողջամիտ հարց «Ինչո՞ւ»: Անհրաժեշտ է պաշտպանվել Աղբյուրի կանոնների փոփոխություններից, այսինքն. միշտ բեռնել ըստ հղումի ստացողի կողմից:

Պատասխան.

Գրել է. Օպտիմալության վերաբերյալ որոշ կասկածներ կան։ Գրել ժամանակավոր xml-ին XML Writing-ի միջոցով, այնուհետև ReadingText-ը՝ այս ամենը ի սկզբանե փոխանցված ֆայլի մեջ տեղադրելու համար:
Մեթոդաբանական տեսանկյունից կոպիտ սխալներ չկա՞ն։

// Ընթացակարգը փոխարինում է բլոկին<ПравилаОбмена>...փոխանցված file.xml // կաղապարի բլոկում, որը պահպանում է բեռնաթափվող ֆայլի մի հատվածը հղումային կանոնների համաձայն։ // // Պարամետրեր // XMLFileName - Տեսակ՝ String - Ֆայլի լրիվ անվանումը բեռնաթափվող տվյալների հետ, // որում մենք կփոխենք բլոկը<ПравилаОбмена>// // Վերադարձված արժեք՝ // XMLResultFileName - Տեսակ՝ String - Path // Procedure ReplaceExchangeRulesInDownloadFileWS (XMLFileName) XMLDownloadFile = Նոր XMLReader; XMLDownloadFile.OpenFile (XMLFileName); Կանոնների ձևանմուշ = Նոր XML Read; PathToRulesTemplate = GetExchangeRulesTemplate (); Rule Template.OpenFile (Ուղ դեպի կանոնների ձևանմուշ); XMLResultFileName = GetTemporaryFileName (". Xml"); XML Արդյունք = Նոր XML գրառում; XMLResult.OpenFile (XMLResultFileName); whileXMLDownloadFile.Read () Loop NodeType = XMLDownloadFile.NodeType; Եթե ​​NodeType = XMLNodeType.ElementStart և XMLUpFile.Name = "ExchangeRules" Ապա XMLUploadFile.Skip (); Մինչդեռ RuleRule.Read () Loop If RuleRule.NodeType = XMLNodeType.ElementStart և RuleRule.Name = «ExchangeRules» Հետո XMLResult.WriteCurrent (RuleRule); Մինչ RuleRule.Read () Loop XML Result.WriteCurrent (RuleRemaine); Եթե ​​RuleRule.NodeType = XMLNodeType.ElementEnd և RuleRule.Name = "ExchangeRules" Ապա Աբորտ; Վերջ Եթե; Ցիկլի ավարտ; ընդհատում; Վերջ Եթե; Ցիկլի ավարտ; Հակառակ դեպքում XMLResult.WriteCurrent (XMLDownloadFile); Վերջ Եթե; Ցիկլի ավարտ; XMLDownloadFile.Close (); TemplateRule.Close (); XML Result.Close (); Տեքստ = NewTextReader (XMLResultFileName); ExchangeMessage = Text.Read (); TextRecord = NewTextRecord (XMLFileName, TextCode.UTF8); WriteText.Write (ExchangeMessage); WriteText.Close (); EndProcedure // ReplaceExchangeRules ()

Հարց. Օգնեք փոխանակման կանոններին

1C 8.3.9.1850, UT 11.3.2.157, Մանրածախ 2.2.5.22: UT կանոնները բեռնելիս սխալ է հայտնվում: Հնարավո՞ր է ինչ-որ կերպ շտկել կանոնները:

Հղում գոյություն չունեցող մետատվյալների օբյեկտին փոխանակման կանոններով
Օբյեկտ =
Նկարագրություն Սխալներ = Տեսակը սահմանված չէ (EnumerationRef.TypesOrderOnAssembly)
Մոդուլի դիրքը = Processing.ConversionObjectsInformationBaseObjectModule (4885)
KE սխալ հաղորդագրություններ = 11

Պատասխան.

Եթե ​​հիշողությունս չի ծառայում ինձ, ապա վերջին կանոնները միշտ պահվում են հենց կոնֆիգուրայում՝ դասավորության մեջ։ Այսպիսով, կարիք չկա վերցնել վերջին կանոններըթղթապանակից։ Պարզապես թարմացրեք երկու կոնֆերանսները վերջին թողարկումներին:

Հարց. Ինչպե՞ս բեռնաթափել փոխանակման կանոնները վերբեռնման փոխակերպման համար

Ինչպե՞ս բեռնաթափել փոխակերպման կանոնները սովորական կոնֆիգուրացիայից:

Առաջադրանք. կա «Rarus. Առևտրի և հաճախորդների հետ հարաբերությունների կառավարում (CRM)» կոնֆիգուրացիա, կա կայքի փոխանակման փոխանակման պլան: Կայքի հետ փոխանակումն ընթացքի մեջ է, անհրաժեշտ է ավելացնել պատվերի կարգավիճակի բեռնաթափումը 1C-ից, որպեսզի այն թարմացվի կայքում։

Ես այսպես եմ տեսնում լուծումը. բեռնաթափել պատվերների բեռնաթափման կանոնները, բեռնել դրանք փոխակերպման մեջ, ավելացնել PKS-ն այնտեղ կարգավիճակի համար և նորից բեռնել կոնֆիգուրացիա: Բայց ինչպե՞ս բեռնաթափել այս կանոնները:Փոխանակման պլանում կա դասավորություն SchemeOrdersUnloading, վերջին ներդիրում Կարգավորումներ կա «Պահպանել կարգավորումները ֆայլում» կոճակը, բայց, ինչպես ես հասկացա, դա փոխակերպման դեպք չէ, այս xml ֆայլը բեռնված չէ:

Ասա ինձ խնդրում եմ.

TIS 7.7-ի և BP2-ի փոխանակման կանոնները շտկվել են երկու նավահանգիստների փոխանցում
Cor. հաշիվ ապրանքագիր և ուղղիչ հաշիվ: Այստեղ ամեն ինչ նորմալ է։ Այս երկու փաստաթղթերն էլ ստեղծում են կատարման ճշգրտում BP2-ում:
Բայց խնդիր առաջացավ, դուք պետք է տեղադրեք իրացման շտկման հիմքը (BP2) ոչ թե որպես ստանդարտ ապրանքագիր, այլ այս ապրանքագրի հիմքը, այսինքն. իրականացում։
PKO ծածկագրի մի կտոր (ներբեռնումից հետո).
Object.FillAccountsVTabParts (Object.Goods, «Goods», True); Object.OperationType = Enumerations.ChangeOperationTypesAccessRealization.ConsistentChange; Object.CorrectVAT = True; Object.SumIncludesVAT = True; Եթե ​​Object.Responsible.Empty () Ապա Object.Responsible = hlVariableValue («hlCurrentUser»); Վերջ Եթե; Object.DocumentRealizations = Object.Ref.DocumentRealizations.DocumentFoundation;<--- проблема Объект.Записать(РежимЗаписиДокумента.Проведение);
Մինչև ձայնագրումը, օբյեկտը դեռ գոյություն չունի, և, հետևաբար, անհնար է մուտք գործել օբյեկտի հատկանիշ, իսկ ձայնագրվելուց հետո արդեն ուշ է: Կանոնները կմշակվեն ըստ ստանդարտի: Ասա ինձ, թե ինչպես լուծել CD-ով, հենց նոր սկսեցի պարզել այն:

Պատասխան.Գրելուց հետո = Write մեթոդը կանչելուց հետո

1C տվյալների փոխակերպման ձեռնարկ (հրատարակություն 2) Մանրամասն ծանոթություն փոխանակման կանոններին

Մենք գիտենք, թե ինչ են փոխանակման կանոնները և ինչու են դրանք անհրաժեշտ: Եկեք ավելի մանրամասն ծանոթանանք փոխանակման կանոններով աշխատելու լրացուցիչ ֆունկցիոնալությանը։ Եկեք բացենք տվյալների փոխանակման (փոխակերպման) կանոնների կարգավորումները.

Փոխանակման կանոնները նշում են տվյալների աղբյուրի և նպատակակետի կոնֆիգուրացիաները, բացի այդ.

«Լրացուցիչ» ներդիր.

Փոխանակման կանոնները պահելու համար կարող եք նշել ֆայլի լռելյայն անունը, 7.7-ի տվյալների վերբեռնման և ներբեռնման մոդուլները, փոխանակման կանոնների անվանումը:

«Պարամետրեր» ներդիր.

Ենթադրենք, գրասենյակն ընդունում է բացառապես ապրանքների պատվերներ, ուստի խորհուրդ է տրվում արգելել ծառայությունների բեռնաթափումը։ Եթե ​​Nomenclature կատալոգի տարրի համար Service հատկանիշը սահմանված է True, ապա այն երաշխավորված է, որ այն չի բեռնաթափվի: Ավելի լավ է ծառայությունների բեռնաթափման հսկողությունը անհապաղ դարձնել ընտրովի, որպեսզի չփոխվեն կանոնները, եթե հեռավար գրասենյակը սկսի նաև ծառայությունների պատվերներ ընդունել:

Այս դեպքում մենք ստիպված կլինենք տիրապետել «Տվյալների փոխակերպման» կոնֆիգուրացիայի հետ աշխատելու երկու նոր տեխնիկայի՝ օգտագործելով մշակիչներ և պարամետրերի կարգավորում:

Պարամետրերը բեռնաթափման ալգորիթմների մասնագիտացված տվյալների կառուցվածք են, որոնք կարող են օգտագործվել մշակման փոփոխականներ մուտք գործելու համար: Փոխակերպման կանոնների պարամետրերի կառուցվածքի կարգավորումն իրականացվում է «Տվյալների փոխակերպում» կազմաձևում, իսկ պարամետրերի արժեքների կարգավորումը հնարավոր է տվյալների վերբեռնման և ներբեռնման մշակման տեսքով:

Պարամետրերը խմբագրելու համար բացեք Փոխակերպումների տեղեկատու գրքի տարրի ձևը խմբագրվող փոխանակման կանոնների համար և անցեք պարամետրերի ներդիր: Եկեք ստեղծենք նոր կետ Պարամետրերի կատալոգում: Անվանենք պարամետրը՝ UnloadServices: Պարամետրի անվանումն օգտագործվում է այն Պարամետրերի կառուցվածքում նշելու համար, երբ մշակում են ծրագրի կոդը: Անունը կցուցադրվի Պարամետրերի աղյուսակային բաժնում՝ տվյալների համընդհանուր փոխանակման մշակման տեսքով: Որպեսզի պարամետրը տեսանելի լինի երկխոսության մեջ բեռնումը կարգավորելիս, դուք պետք է սահմանեք «Սահմանել երկխոսության մեջ» վանդակը և ընտրեք պարամետրի արժեքի տեսակը: Երկխոսության պատուհանում պարամետրերի հետ աշխատելու համար դուք պետք է նաև սահմանեք «Վերբեռնել պարամետրերը 2.01 տարբերակի ձևաչափով» վանդակը՝ «Կոնվերսիաներ» տեղեկատու գրքում կետի տեսքով:

Միայն պարամետրերը նշելը բավարար չէ, անհրաժեշտ է, որ բեռնաթափման ալգորիթմը «հասկանա», թե որ դեպքում պետք է բեռնաթափել տարրը, որում՝ ոչ։ Նման (և շատ այլ) դեպքերի համար օգտագործվում է կարգավորիչ մեխանիզմ: Դրա էությունը կայանում է նրանում, որ տվյալների բեռնաթափման և բեռնման բոլոր հիմնական ալգորիթմների կատարման առանցքային կետերում մշակվում է փոխանակման կանոնները ստեղծելիս մշակողի կողմից գրված կոդը: Բնականաբար, նման նուրբ գործիքի օգտագործումը պահանջում է զգուշություն և մտածվածություն: Նախքան ձեր սեփական մշակողները գրելը, խորհուրդ ենք տալիս ուշադիր կարդալ «Տվյալների փոխակերպում 2.0» կոնֆիգուրացիայի օգնությունը, որը նկարագրում է մշակիչներում առկա բոլոր փոփոխականները և դրանց օգտագործման եղանակները, ինչպես նաև թվարկում է մշակողների տեսակներն ու առանձնահատկությունները: դրանք զանգահարելով տվյալների փոխանակման ալգորիթմներում:

Մեր նպատակների համար մենք պետք է օգտագործենք Նախքան բեռնաթափման կանոնների մշակիչը: Բացենք Անվանակարգի տվյալների բեռնաթափման կանոնը և «Իրադարձություններ» ներդիրի «Բեռնաթափումից առաջ» դաշտում տեղադրենք հետևյալ ծրագրի կոդը.

Ի՞նչ է անում մեր կառավարիչը: Ծրագրի կոդը գրելիս մենք օգտագործել ենք տվյալների բեռնաթափման ալգորիթմների փոփոխականները։ Պարամետրերի կառուցվածքն օգտագործվում է UnloadServices պարամետրին մուտք գործելու համար, որը նշված է տվյալների փոխանակման մշակման ձևում: Օբյեկտի փոփոխականը ապահովում է մուտք դեպի բեռնաթափված օբյեկտ: Իսկ Failure փոփոխականը թույլ է տալիս վերահսկել ընթացիկ օբյեկտի բեռնաթափման ձախողումը: Բեռնաթափիչը կատարվում է օբյեկտի բեռնաթափման մեկնարկից անմիջապես առաջ, ինչը հնարավորություն է տալիս չեղարկել օբյեկտի բեռնաթափումը:

ՄԻԱՅՆ V8 - V8 ՓՈԽԱՆԱԿԵԼՈՒ ԵՎ 2.0.18.1-ից ՈՉ ՊԱՍՔ ԲԵՐՄԱՆ ԵՎ ՆԵՐԲԵՐՆԵԼՈՒ ՀԱՄԱՐ

Հնարավոր է պարամետրեր փոխանցել մեկ կոնֆիգուրացիայից մյուսը: Դրա համար «Պարամետրեր» ներդիրում բավական է սահմանել «Անցումային պարամետր բեռնաթափման ժամանակ» վանդակը, և այս պարամետրը կտեղադրվի փոխանակման ֆայլում, և դրա արժեքը հնարավոր կլինի մուտք գործել տվյալների բեռնման ժամանակ: Դուք կարող եք նշել այն պարամետրի փոխակերպման կանոնը, ըստ որի արժեքները պետք է փոխարկվեն: Օգտագործելով «Փոխանցել պարամետրը բեռնաթափման ժամանակ» վանդակը, կարող եք փոխանցել միայն այն պարամետրերը, որոնք խմբագրվում են երկխոսության պատուհանում տվյալների բեռնաթափման ժամանակ: Եթե ​​Ձեզ անհրաժեշտ է փոխանցել պարամետր, որը չկա այս երկխոսության մեջ, ապա դուք պետք է զանգահարեք ընթացակարգը.

Բեռնաթափման պարամետրերի ներդիրում հայտնվել է պարամետր, որը փոխում է այն արժեքները, որոնց ծառայությունները կամ բեռնաթափվում են, կամ չեն բեռնաթափվում:

Փոխանակման կանոններ 1C 8 մշակելիս լայնորեն կիրառվում է փոխանակման կանոնների վարքագծի ծրագրային վերասահմանման հնարավորությունը՝ մշակողների մեխանիզմը: Իրադարձությունների մշակողները զգալիորեն ընդլայնում են ֆունկցիոնալությունը և անփոխարինելի գործիք են փոխանակման կանոններ սահմանելու համար այն դեպքերում, երբ ինտերակտիվ կազմաձևման հնարավորությունները բավարար չեն:

Գործող սարքերը և ալգորիթմները գրված են այն հարթակի լեզվով, որով դրանք կկատարվեն փոխանակման ընթացքում:

Եթե ​​դա 1C: Enterprise 7.7 հարթակ է, ապա մշակման կոդը ինտեգրված է վերբեռնման կամ ներբեռնման մշակման կոդի մեջ: Համապատասխանաբար, յուրաքանչյուր կարգավորիչ կամ ալգորիթմ հատկացվում է առանձին ֆունկցիայի և հասանելի է փոխանակման ժամանակ վրիպազերծման համար:

Եթե ​​վերբեռնումը կամ ներբեռնումը տեղի է ունենում 1C: Enterprise 8 հարթակում, ապա մշակողի կոդը ինտեգրված չէ տվյալների փոխանակման մշակման կոդի մեջ, այլ վերբեռնվում է փոխանակման կանոնների ֆայլում: Տվյալների փոխանակման գործընթացում մշակողների կամ ալգորիթմների ծածկագիրը վերցվում է կանոնների ֆայլից և կատարվում է անմիջապես «Execute» հայտարարության համատեքստում: Դուք կարող եք օգտագործել Universal XML Data Interchange մշակումը կարգավորիչի և ալգորիթմի ծածկագրի վրիպազերծման համար:

Առևտրային գործունեությամբ զբաղվող շատ ձեռներեցներ, կառավարման արդյունավետությունը բարելավելու նպատակով, միաժամանակ ձեռք են բերում երկու ծրագիր «1C: Հաշվապահություն 8» (այսուհետ՝ BP)և «1C: Առևտրի կառավարում 8» (այսուհետ՝ ՀԹ).

BP-ն օգտագործվում է կանոնակարգված հաշվապահական հաշվառման և հաշվետվությունների պահպանման համար, իսկ UT-ն օգտագործվում է ընկերությունում գործառնական և կառավարչական հաշվառման համար:
Այս ծրագրային արտադրանքների համատեղ օգտագործման հաջողությունը մեծապես կախված է էլեկտրամատակարարման և UT կոնֆիգուրացիաների միջև տվյալների փոխանակման կազմակերպումից:

Տվյալների տիպիկ փոխանակման հետևյալ հատկանիշները հասկանալը կօգնի խուսափել կոնֆիգուրացիաների միջև փոխանակման սխալներից և յուրաքանչյուր կազմաձևում հաշվառման խախտումներից:

Այս հոդվածը գրելիս օգտագործվել են ծրագրային արտադրանքների համար 1C փաստաթղթերից նյութեր: Փոխանակման ստեղծման մանրամասն մեթոդաբանությունը նկարագրված է htm ֆայլում «Կազմաձևերի փոխանակում Առևտրի կառավարում (11) և ձեռնարկությունների հաշվառում», որը գտնվում է ձևանմուշների գրացուցակում: երբ տեղադրվում է որպես 1C. Accounting 2.0 (այսուհետ՝ BP) և 1C: Առևտրի կառավարում 11 (այսուհետ՝ UT); 1C գործընկեր կոնֆերանսում ստացված առաջարկությունները և հեղինակի անձնական փորձը RG-Soft Project Consulting ՍՊԸ-ի հաճախորդների համար փոխանակման կարգավորումները ստեղծելու և փոխելու հարցում:

1. Միակողմանի կամ երկկողմանի փոխանակման ստեղծում:

Նախ և առաջ պետք է հաշվի առնել, որ BP կոնֆիգուրացիայից UT կոնֆիգուրացիա կարող են վերբեռնվել միայն կանխիկ և անկանխիկ գործարքների հետ կապված փաստաթղթեր: Դրանց թվում են՝ մուտքային կանխիկի պատվեր, ելքային կանխիկ պատվեր, անդորրագիր ընթացիկ հաշվին և դուրսգրում ընթացիկ հաշվից: BP-ում ստեղծված ապրանքների տեղափոխման փաստաթղթերը չեն վերբեռնվի UT:

1C-ն առաջարկում է փոխանակում կատարել UT-ի բանկի հետ: «Սա կապահովի ելքային վճարային փաստաթղթերի հետ լիարժեք աշխատանք և մուտքային փաստաթղթերի հետ ավելի հեշտ աշխատանք։ Այնուամենայնիվ, կար մի իրավիճակ, երբ հաճախորդ-բանկ ֆայլից գրեթե մեկ վճարում հնարավոր չէր բեռնել UT, մինչդեռ այս ֆայլը ամբողջությամբ բեռնված էր BP-ում:

Դա պայմանավորված է նրանով, որ UT-ին ավելացվել են հաճախորդ-բանկ ֆայլի բովանդակության ավելի խիստ ստուգումներ, օրինակ՝ TIN-ի լրացման ստուգում, փաստաթղթի համարի ստուգում, համարը պետք է պարունակի միայն թվեր՝ համապատասխան. Ռուսաստանի Դաշնության Կենտրոնական բանկի 2002 թվականի հոկտեմբերի 3-ի N2-P կանոնակարգը «Ռուսաստանի Դաշնությունում անկանխիկ վճարումների մասին» (փոփոխվել է 2003 թվականի մարտի 3, 2004 թվականի հունիսի 11, 2007 թվականի մայիսի 2, 2008 թվականի հունվարի 22):

Իմաստ ունի ստեղծել միակողմանի փոխանակում (UT-ից BP) միայն այն դեպքում, եթե UT-ում լրացված են բոլոր փաստաթղթերը և կարգավորող և տեղեկատու տեղեկությունները: Այսպիսով, այս տվյալների բազայում տարրերի կրկնօրինակումը հնարավոր է խուսափել:

Դա անելու համար անհրաժեշտ է կարգավորել փոխանակման հետևյալ սցենարը՝ UT կոնֆիգուրացիայով ստեղծել փոխանակման սցենար, որում կպահվի միայն բեռնաթափումը (նկ. 1), BP կոնֆիգուրացիայի մեջ ստեղծեք փոխանակման սցենար և պահպանեք միայն բեռնվածությունը:

Պետք է հաշվի առնել, որ այս փոխանակման սցենարում BP-ում ստեղծված բոլոր լրացուցիչ փաստաթղթերը և գրացուցակները կգրանցվեն փոխանակման համար, բայց չեն բեռնվի UT-ում, հետևաբար խորհուրդ է տրվում պարբերաբար վերականգնել գրանցումը, հակառակ դեպքում փոխանակման հաղորդագրությունը: BP-ից ֆայլը անընդհատ կավելանա՝ դանդաղեցնելով փոխանակման գործընթացը…

Դրա համար խորհուրդ է տրվում օգտագործել վերամշակումը RegistrationChangesForExchange82.epf, որը կարելի է գտնել «Տվյալների փոխակերպում, rev. 2.1» կոնֆիգուրացիայի առաքման մեջ: Կազմաձևը տեղադրելուց հետո մշակումը գտնվում է թարմացման տեղադրման գրացուցակում՝ ... \ 1c \ Conversion \ ... version_number ...

Եթե ​​նորմատիվային և տեղեկատու տեղեկատվությունը լրացվում է ինչպես UT-ում, այնպես էլ BP-ում, ապա պետք է կազմաձևվի երկկողմանի փոխանակում, բայց միևնույն ժամանակ կարող է անհրաժեշտ լինել հետևել կրկնօրինակներին՝ փոխանակումը սկսելով ինտերակտիվ ռեժիմում, ոչ թե ավտոմատ: (նկ. 2):

Տվյալների փոխանակումը միայն փաստաթղթի մակարդակով սահմանափակելու համար անհրաժեշտ չէ ստեղծել միակողմանի փոխանակում, բավական է BP-ի կողմից փոխանակման ֆիլտրում դնել ամսաթիվ, որն ավելի մեծ է, քան վերջին փաստաթղթի ամսաթիվը: (տես նկ. 5): Բայց նախքան ամսաթվի ֆիլտրը դնելը, դուք պետք է համոզվեք, որ BP-ում փաստաթղթերը նախկինում գրանցված չեն փոխանակման համար, հակառակ դեպքում գրանցված փաստաթղթերը փոխանակման ընթացքում կտեղափոխվեն մեկ այլ տվյալների բազա:

Տվյալների փոփոխության առաջնահերթություն

Եթե ​​սկզբում փոխանակումը կատարվում է UT-ում, իսկ հետո՝ PSU-ում, ապա առաջնահերթություն կունենան UT-ից բեռնաթափված տվյալները։ Օրինակ, UT-ում նրանք բերեցին «Անդորագիր ընթացիկ հաշվին» փաստաթուղթը, գործարկեցին փոխանակումը նախ UT-ում, այնուհետև BP-ում - փաստաթուղթը հայտնվեց BP-ի կազմաձևում: Այնուհետև BP-ի կոնֆիգուրացիայի հաշվապահը փոփոխություններ է կատարել այս փաստաթղթում: Հետագա փոխանակման ժամանակ, եթե փոխանակման մեկնարկի կարգը չի փոխվել, ապա փաստաթղթում կատարված փոփոխությունները կվերագրվեն UT-ի տվյալների հետ:

Երկու տվյալների բազաներում փոխված օբյեկտների հետ ճիշտ փոխանակման համար 1C-ն խորհուրդ է տալիս կազմակերպել աշխատանքը այնպես, որ օբյեկտը խմբագրվի միայն տվյալների բազաներից մեկում: Մեկ այլ տվյալների բազայում նման օբյեկտը պետք է բացվի միայն դիտելու համար։ Դա անելու համար դուք պետք է օգտագործեք օգտվողի մուտքի իրավունքի կարգավորումը, բայց այս մոտեցումը երաշխավորում է փոխանակման ընթացքում բախումների բացակայությունը, այսինքն. անհամապատասխանություններ, որոնք առաջանում են օբյեկտի և մեկ և մյուս բազայի փոփոխություններից, փոխանակումների միջև ընկած ժամանակահատվածում (նկ. 3):

2. BP-ի և UT-ի միջև եղած տարբերությունները, որոնք ազդում են փոխանակման վրա

Կապալառուի պայմանագրեր

UT-ի կոնֆիգուրացիայում վերլուծությունը չի իրականացվում կոնտրագենտների պայմանագրերի վերաբերյալ: Բոլոր գործողությունները, որոնք իրականացվում են UT կոնֆիգուրացիայով, երբ բեռնվում են BP կոնֆիգուրացիա, միշտ կազմվում են առանձին պայմանագրերով, որոնք ստեղծված և վերահսկվում են հենց UT համակարգի կողմից:

Եթե ​​պահանջվող պարամետրերով պայմանագիրը BP-ի կոնֆիգուրացիայի մեջ չէ, ապա այդպիսի պայմանագիր է ստեղծվում: Նշենք, որ պայմանագրի որոնումն իրականացվում է միայն UT-ից նախկինում բեռնված պայմանագրերի քանակից։

Կառավարման կազմակերպություն UT-ում

11.0.6.9 թողարկումից սկսած՝ UT-ում հայտնվել է «Կառավարման կազմակերպություն» նախապես սահմանված տարրը կազմակերպության գրացուցակում: Այս տարրը չպետք է կապված լինի (կամ փոխվի) ընթացիկ (մեկ կամ մեկ) կազմակերպության հետ: Այս օբյեկտի օգտագործման մասին ավելին կարող եք կարդալ փաստաթղթերի ֆայլում «Փոփոխություններ և լրացումներ documentation.htm».ներառված է UT-ի առաքման մեջ:

Ընկերության կառուցվածքը

UT-ում կառավարման հաշվառման համար օգտագործվում է «Ձեռնարկությունների կառուցվածք» գրացուցակը, որը պարունակում է ընկերության ստորաբաժանումների ցանկը: Փաստաթղթեր կազմելիս ձեռնարկության բաժանման նշումը պարտադիր է:

«Ձեռնարկությունների կառուցվածք» գրացուցակի տարրերը կապված չեն BP-ի «Կազմակերպական բաժիններ» գրացուցակի տարրերի հետ: Որպեսզի UT-ն չբեռնի փաստաթղթերը չլրացված ստորաբաժանման ռեկվիզիտով, դուք պետք է լրացնեք նախնական արժեքը փոխանակման կարգավորումներում (նկ. 4):

Պահեստ աղյուսակային բաժնում

Եթե ​​UT-ը նախատեսում է օգտագործել փաստաթղթերի աղյուսակային բաժիններում պահեստներ նշելու նոր հնարավորությունը, ապա փոխանակման պլանի հանգույցի կարգավորումներում դուք պետք է սահմանեք ընդհանրացնող պահեստ, որը կփոխարինվի UT-ից փաստաթղթերը BP-ում բեռնաթափելիս: փաստաթղթերի աղյուսակային բաժիններում ընտրության համար թույլատրված պահեստների փոխարեն կոնֆիգուրացիա (նկ. 4):

Անվանակարգի տեսակը

Տվյալները BP-ից UT բեռնաթափելիս ապրանքի մեջ չի լրացվում «տարրի տեսակը», դա պայմանավորված է նրանով, որ փոխանակումը սպասարկում է սցենարը, երբ նյութը ստեղծվում է UT կոնֆիգուրացիայով, և ոչ թե BP-ում: ՀՏ-ում ապրանքների տեղաշարժի փաստաթղթերում հաշվապահական ծառայությունների առանձին աղյուսակային բաժին չկա (ծառայությունները լրացվում են ապրանքների աղյուսակում), հետևաբար, որպեսզի UT փաստաթղթերում նշված ծառայությունները ճիշտ տեղափոխվեն աղյուսակ. բաժինը BP-ում, ձեզ հարկավոր է.

1. Հղման տեղեկատվության բաժնում բացեք «Նոմենկլատուրայի տեսակները» տեղեկագիրքը, անցեք «ծառայությունների» կետի տեսքը - սեղմեք «Բոլոր գործողությունները» - թույլատրեք խմբագրումը և ընտրեք նյութի տեսակը - Ծառայություն:

2. Փոխեք տարրը (ծառայությունը) - սեղմեք «Բոլոր գործողությունները» - թույլատրեք խմբագրումը և ընտրեք այս Նյութի տեսակը Ծառայության տեսակի հետ:

3. Փոխանակման ֆիլտրերի տեղադրում (նկ. 5)

Փաստաթղթերի բեռնման (բեռնման) ամսաթվի փոփոխություն

1) Նախքան ամսաթիվը տեղափոխելը, անհրաժեշտ է համաժամեցնել տվյալների բազաները՝ կատարելով փոխանակման նիստ, որպեսզի հանգույցը չունենա փոխանակման համար գրանցված փաստաթղթեր այն պահին, երբ կարգավորումները փոխվում են: Հակառակ դեպքում, կարգավորումները փոխելուց հետո, վերբեռնման արդյունքում, նման փաստաթղթերը կարող են ջնջվել ընդունող բազայում, եթե դրանք նախկինում վերբեռնված են եղել այնտեղ։

2) Դուք կարող եք հետ տեղափոխել ամսաթիվը, քանի որ այն միայն ընդլայնում է վերբեռնված տվյալների տարածքը: Հարկ է նշել, որ այս դեպքում նախկինում փակ ժամանակահատվածի փաստաթղթերը ավտոմատ կերպով չեն գրանցվի փոխանակման համար: Դա անելու համար դուք կամ պետք է փոխեք փաստաթղթերը կամ օգտագործեք վերամշակումը RegistrationChangesForExchange82.epf.

Զտել ըստ կազմակերպության

Այս ֆիլտրի ակտիվացումը թույլ է տալիս սահմանափակել այն կազմակերպությունների ցանկը, որոնց համար թույլատրվում է տվյալների փոխանակում: Միացված ֆիլտրի առկայությունը ազդում է ինչպես կազմակերպությունների գրացուցակի բեռնաթափման, այնպես էլ կազմակերպությունների հետ կապված այլ տվյալների (տեղեկատուների և փաստաթղթերի) բեռնաթափման վրա:

Վերբեռնման ֆիլտրերի շահագործման սկզբունքը հետևյալն է. նոր կարգավորումները կիրառվում են բոլոր տվյալների վրա՝ փոխանակման ստեղծման պահին, կամ միայն այն տվյալների համար, որոնք փոխվել են նոր կարգավորումների կիրառման պահից հետո՝ փոխանակում ստեղծելուց հետո, հետևաբար, փոխանակում ստեղծելիս խորհուրդ է տրվում հնարավորինս պատասխանատու կերպով մոտենալ ֆիլտրի կարգավորումներին:…

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

4. Հիմքերից մեկից օբյեկտների ջնջում

Նշել ջնջման համար

Հնարավոր է իրավիճակ, երբ նախկինում օգտագործված կատալոգի տարրը չի նախատեսվում օգտագործել հետագա հաշվառման համար, և օգտվողները ճիշտ են համարում նշել այս կատալոգը ջնջման համար: Ջնջման համար նշված օբյեկտները փոխանակմանը չեն մասնակցում: Այս հատկանիշը պետք է հաշվի առնել:

Կրկնօրինակների հեռացում

Կրկնօրինակների փոխանակման ընթացքում առաջացած օբյեկտները հեռացնելու համար խորհուրդ ենք տալիս օգտագործել մշակումը Search & Replace.epf, որը գտնվում է \ 1CITS \ EXE \ ExtReps \ Unireps82 \ SearchAndChange \ գրացուցակում ITS սկավառակի վրա։ Իսկ երկու ինֆոբազների օբյեկտների համեմատության ճիշտությունը ստուգելու համար կարող եք բացել «Ինֆաբազային օբյեկտների համապատասխանություն» Տեղեկատվական ռեգիստրը և այս ռեգիստրի գրառումները կարող են շտկվել ձեռքով։ Կարևոր է իմանալ, որ բազաներից մեկում օբյեկտը ջնջելուց հետո ջնջված օբյեկտի համընկնում (կոտրված հղում) կմնա տեղեկատվական ռեգիստրի մուտքագրում, կամ պետք է համապատասխանեցնել մեկ այլ օբյեկտ, կամ ջնջել մուտքը:

5. Լրացուցիչ կարգավորումներ

Դրամական հոսքերի տարրեր

UT-ը կարգավորելու համար կարող է անհրաժեշտ լինել սահմանել «corr. հաշիվ «դրամական հոսքերի այն հոդվածների համար, որոնք օգտագործվելու և բեռնաթափվելու են BP-ում:

BP-ն կարգավորելու համար կարող է պահանջվել նշել դրամական միջոցների հոսքի տեսակը գրացուցակի տարրերում:

Օգտատերեր

Գրացուցակի օգտատերերը կարող են տեղափոխվել մեկ այլ տվյալների բազա, եթե նրանք նշված են որպես պատասխանատու փոխանակմանը մասնակցող օբյեկտներից մեկում: Նման օբյեկտների համար դուք պետք է կարգավորեք իրավունքները:

Հիմնական նախածանցը և կազմակերպության նախածանցը

UT-ում նախածանցը միշտ ունի ֆիքսված երկարություն, իսկ բաժանարարը (գծիկ) «-»: Հետևաբար, եթե տեղեկատվական բազայի նախածանցը նշված չէ կամ կազմակերպության նախածանցը նշված չէ, ապա այն փոխարինվում է զրոներով: Այնուամենայնիվ, փոխանակում ստեղծելիս ինֆոբազայի նախածանցը միշտ լրացվում է կենտրոնական բանկում (UT-ի համար) և էներգամատակարարման միավորի վրա (համապատասխանաբար, էլեկտրամատակարարման միավորի կազմաձևման համար):

Այս լուծումը ստանդարտ է փաստաթղթերի համարների և օբյեկտների կոդերի ստեղծման ժամանակ: Նախածանցն ունի ֆիքսված երկարություն և գծիկով բաժանվում է փաստաթղթի համարից: Եթե ​​ապագայում տվյալների բազայում կլինեն մի քանի կազմակերպություններ, ապա նրանց համար բավական կլինի նախածանցներ դնել, և բոլոր օբյեկտները վերահամարակալելու կարիք չկա։

Սխալի ուղղում

Մեր հոդվածում դիտարկվել են «1C: Առևտրի կառավարում 8» rev. 11 և «1C: Accounting 8» rev. 2.0 միջև տվյալների փոխանակման կազմակերպման ամենակարևոր ասպեկտները:

«ՌՋ-Սոֆթ Փրոջեքթ Քոնսալթինգ» ընկերության մասնագետները պատրաստ են առաջարկել ոչ միայն բորսայի ստեղծում որոշակի կազմակերպության հաշվառման առանձնահատկությունների համար, այլև առկա բորսաներում սխալները շտկելու ուղիներ: