ობიექტის კონვერტაციის წესის მაგალითი. ობიექტის კონვერტაციის წესის მაგალითი დიდი ინფობაზების მიგრაცია

მონაცემთა მიგრაცია სხვადასხვა კონფიგურაციას შორის არ არის ტრივიალური ამოცანა. როგორც ყოველთვის, არსებობს რამდენიმე გამოსავალი, მაგრამ ყველა მათგანი არ არის ოპტიმალური. შევეცადოთ გავიგოთ მონაცემთა გადაცემის ნიუანსები და ავირჩიოთ უნივერსალური სტრატეგია ასეთი საკითხების გადასაჭრელად.

მონაცემების მიგრაციის პრობლემა (ეს არის მხოლოდ 1C კომპანიის პროდუქტებზე) ერთი გადაწყვეტიდან მეორეზე გუშინ არ წარმოიშვა. 1C კომპანიამ კარგად იცის, თუ რა სირთულეებს აწყდებიან დეველოპერები მიგრაციის შექმნისას, ამიტომ ის მაქსიმალურად ცდილობს დაეხმაროს ხელსაწყოებს.

პლატფორმის განვითარებისას კომპანიამ შემოიტანა არაერთი უნივერსალური ინსტრუმენტი, ასევე ტექნოლოგიები, რომლებიც ამარტივებს მონაცემთა გადაცემას. ისინი ჩაშენებულია ყველა სტანდარტულ გადაწყვეტაში და იდენტურ კონფიგურაციებს შორის მიგრაციის პრობლემა ზოგადად მოგვარებულია. გამარჯვება კიდევ ერთხელ დასტურდება სტანდარტული გადაწყვეტილებების მჭიდრო ინტეგრაციით.

არასტანდარტულ გადაწყვეტილებებს შორის მიგრაციით, სიტუაცია გარკვეულწილად უფრო რთულია. ტექნოლოგიების ფართო სპექტრი საშუალებას აძლევს დეველოპერებს დამოუკიდებლად აირჩიონ პრობლემის გადაჭრის საუკეთესო გზა მათი თვალსაზრისით.

განვიხილოთ ზოგიერთი მათგანი:

• ტექსტური ფაილების საშუალებით გაცვლა;
• გაცვლითი გეგმების გამოყენება;
• და ა.შ.

თითოეულ მათგანს აქვს თავისი დადებითი და უარყოფითი მხარეები. რომ შევაჯამოთ, მთავარი მინუსი იქნება სიტყვიერება. მიგრაციის ალგორითმების დამოუკიდებელი განხორციელება სავსეა მნიშვნელოვანი დროის ხარჯებით, ასევე ხანგრძლივი გამართვის პროცესით. არც მინდა ვისაუბრო მსგავსი გადაწყვეტილებების შემდგომ მხარდაჭერაზე.

შენარჩუნების სირთულემ და მაღალმა ღირებულებამ აიძულა 1C კომპანია შეექმნა უნივერსალური გადაწყვეტა. ტექნოლოგია, რომელიც საშუალებას გაძლევთ მაქსიმალურად გაამარტივოთ მიგრაციის განვითარება და მხარდაჭერა. შედეგად, იდეა განხორციელდა ცალკე კონფიგურაციის - „მონაცემთა კონვერტაციის“ სახით.

მონაცემთა კონვერტაცია - სტანდარტული გადაწყვეტა, თვითკონფიგურაცია. ნებისმიერ მომხმარებელს, რომელსაც აქვს ITS:Prof გამოწერა, შეუძლია ჩამოტვირთოთ ეს პაკეტი სრულიად უფასოდ მომხმარებლის მხარდაჭერის საიტიდან ან ITS დისკიდან. ინსტალაცია ხორციელდება სტანდარტული გზით - როგორც ყველა სხვა სტანდარტული ხსნარი 1C-დან.

ახლა ცოტათი გადაწყვეტის დადებითი მხარეების შესახებ. დავიწყოთ ყველაზე მნიშვნელოვანით - მრავალფეროვნებით. გამოსავალი არ არის მორგებული პლატფორმის გარკვეულ კონფიგურაციებზე/ვერსიებზე. ის თანაბრად კარგად მუშაობს როგორც სტანდარტულ კონფიგურაციებთან, ასევე თვითნაწერებთან. დეველოპერებს აქვთ უნივერსალური ტექნოლოგია და სტანდარტიზებული მიდგომა ახალი მიგრაციის შესაქმნელად. გადაწყვეტის მრავალფეროვნება საშუალებას გაძლევთ მოამზადოთ მიგრაცია 1C:Enterprise-ის გარდა სხვა პლატფორმებისთვისაც კი.

მეორე თამამი პლუსია ვიზუალური საშუალებები. მარტივი მიგრაცია იქმნება პროგრამირების გარეშე. დიახ, დიახ, კოდის ერთი ხაზის გარეშე! მხოლოდ ამისთვის ღირს დროის დახარჯვა ტექნოლოგიის ერთხელ შესწავლაზე და შემდეგ ფასდაუდებელი უნარების განმეორებით გამოყენებაზე.

მესამე უპირატესობა, რომელსაც მე აღვნიშნავ, არის მონაცემთა განაწილების შეზღუდვების არარსებობა. დეველოპერი თავად ირჩევს მიმღების კონფიგურაციაში მონაცემების მიწოდების მეთოდს. ორი ვარიანტია ხელმისაწვდომი: ატვირთვა xml ფაილში და პირდაპირი კავშირი ინფობაზასთან (COM/OLE).

არქიტექტურის სწავლა

ჩვენ უკვე ვიცით, რომ მონაცემთა კონვერტაციას შეუძლია სასწაულების მოხდენა, მაგრამ ჯერჯერობით უცნობია, რა ტექნიკური უპირატესობა აქვს. პირველი, რაც უნდა ვისწავლოთ, არის ის, რომ ნებისმიერი მონაცემთა მიგრაცია (კონვერტაცია) ეფუძნება გაცვლის წესებს. გაცვლის წესები - ჩვეულებრივი xml ფაილი სტრუქტურის აღწერით, რომელშიც მონაცემები აიტვირთება IB-დან. სერვისის დამუშავება, რომელიც ახორციელებს მონაცემთა ატვირთვა/ჩამოტვირთვას, აანალიზებს გაცვლის წესებს და მათზე დაყრდნობით ახორციელებს ატვირთვას. ჩამოტვირთვის დროს ხდება საპირისპირო პროცესი.

"KD" კონფიგურაცია არის ერთგვარი ვიზუალური კონსტრუქტორი, რომლითაც დეველოპერი ქმნის გაცვლის წესებს. მან არ იცის როგორ ატვირთოს მონაცემები. ამაზე პასუხისმგებელია დამატებითი გარე სერვისის დამუშავება, რომელიც შედის CD განაწილების კომპლექტში. რამდენიმე მათგანია (ფაილის სახელში XX არის პლატფორმის ვერსიის ნომერი):

• MDXXExp.epf- დამუშავება საშუალებას გაძლევთ ატვირთოთ ინფორმაციის ბაზის სტრუქტურის აღწერა xml ფაილში. სტრუქტურის აღწერა ჩაიტვირთება CD-ში შემდგომი ანალიზისა და გაცვლის წესების შესაქმნელად.
• V8ExchanXX.epf- ატვირთავს/ჩამოტვირთავს მონაცემებს ინფობაზიდან გაცვლის წესების შესაბამისად. უმეტეს ტიპურ კონფიგურაციებში, დამუშავება ხელმისაწვდომია ყუთიდან (იხ. მენიუს პუნქტი „სერვისი“). დამუშავება უნივერსალურია და არ არის დაკავშირებული რაიმე კონკრეტულ კონფიგურაციასთან/წესთან.

კარგი, ახლა ყოველივე ზემოთქმულიდან გამომდინარე, მოდით განვსაზღვროთ ახალი კონვერტაციის შემუშავების ეტაპები:

1. დავალების განსაზღვრა. აუცილებელია ნათლად გვესმოდეს, რა მონაცემების გადაცემაა საჭირო (რომელი კონფიგურაციის ობიექტები) და, რაც მთავარია, სად გადაიტანოს.
2. კონფიგურაციის სტრუქტურების (წყარო/მიმღები) აღწერილობის მომზადება CD-ში შემდგომი ჩატვირთვისთვის. ამოცანა მოგვარებულია სერვისის დამუშავებით MDXXExp.epf.
3. IS-ში სტრუქტურების მომზადებული აღწერილობების ჩატვირთვა.
4. გაცვლის წესების შექმნა CD-ის ვიზუალური საშუალებების გამოყენებით.
5. ატვირთვა/ჩამოტვირთვა შექმნილი მონაცემთა კონვერტაციის წესების მიხედვით V8ExchanXX.epf დამუშავების გამოყენებით.
6. გამართვის გაცვლის წესები (საჭიროების შემთხვევაში).

უმარტივესი კონვერტაცია

დემონსტრაციისთვის ჩვენ გვჭირდება ორი განლაგებული კონფიგურაცია. გადავწყვიტე შევჩერდე ვარიანტზე: „ვაჭრობის მენეჯმენტი“ მე-10 გამოცემა და პატარა თვითნაწერი გადაწყვეტა. ამოცანა იქნება მონაცემთა გადაცემა ტიპიური UT კონფიგურაციიდან. მოკლედ, ჩვენ დავარქვათ თვითნაწერი გადაწყვეტა "მიმღები", და სავაჭრო მენეჯმენტი "წყარო". დავიწყოთ პრობლემის გადაჭრა „ნომენკლატურის“ დირექტორიაში ელემენტების გადატანით.

უპირველეს ყოვლისა, მოდით გადავხედოთ მონაცემთა კონვერტაციის სქემას და ხელახლა წავიკითხოთ მოქმედებების სია, რომლებიც უნდა გაკეთდეს. შემდეგ ჩვენ ვიწყებთ "Source" კონფიგურაციას და ვხსნით მასში სერვისის დამუშავებას MD82Exp.epf.

დამუშავების ინტერფეისი არ ანათებს პარამეტრების სიმრავლით. მომხმარებელმა მხოლოდ უნდა მიუთითოს მეტამონაცემების ობიექტების ტიპები, რომლებიც არ მოხვდება სტრუქტურის აღწერაში. უმეტეს შემთხვევაში, ამ პარამეტრების შეცვლა არ არის საჭირო, რადგან დაგროვების რეგისტრებში მოძრაობის გადმოტვირთვას განსაკუთრებული აზრი არ აქვს (მაგალითად).

უფრო სწორია მოძრაობის ფორმირება მიმღებში დოკუმენტების შენახვისას. გადარიცხვის შემდეგ ყველა მოძრაობა განხორციელდება თავად დოკუმენტის მიერ. ნაგულისხმევი პარამეტრების დასაცავად მეორე არგუმენტი არის ატვირთული ფაილის ზომის შემცირება.

ზოგიერთი დოკუმენტი (განსაკუთრებით ტიპიურ კონფიგურაციებში) წარმოქმნის მოძრაობას მრავალ რეესტრში. მთელი ამ ეკონომიის გადმოტვირთვა მიღებულ XML ფაილს ძალიან დიდს გახდის. ამან შეიძლება გაართულოს შემდგომი ტრანსპორტირება და ჩატვირთვა მიმღების ბაზაში. რაც უფრო დიდია მონაცემთა ფაილი, მით მეტი შემთხვევითი წვდომის მეხსიერებამისი დამუშავებისთვის. ჩემი პრაქტიკის დროს, შემხვდა უხამსი ატვირთული ფაილები. ასეთი ფაილები სრულიად უარს ამბობდნენ სტანდარტული საშუალებების გაანალიზებაზე.

ასე რომ, ჩვენ ვტოვებთ ყველა ნაგულისხმევ პარამეტრს და ატვირთავთ კონფიგურაციის აღწერას ფაილში. იგივე პროცედურას ვიმეორებთ მეორე ფუძისთვის.

გახსენით CD და აირჩიეთ მთავარი მენიუდან "დირექტორიები" -> "კონფიგურაციები". დირექტორიაში ინახება ყველა კონფიგურაციის სტრუქტურის აღწერილობები, რომლებიც შეიძლება გამოყენებულ იქნას კონვერტაციის შესაქმნელად. ჩვენ ვტვირთავთ კონფიგურაციის აღწერილობას ერთხელ და შემდეგ შეგვიძლია მისი განმეორებით გამოყენება სხვადასხვა კონვერტაციის შესაქმნელად.

დირექტორიაში ფანჯარაში დააჭირეთ ღილაკს " დამატება”და ფანჯარაში, რომელიც გამოჩნდება, აირჩიეთ ფაილი კონფიგურაციის აღწერით. შეამოწმეთ ყუთი "ატვირთვა ახალ კონფიგურაციაში" და დააჭირეთ ღილაკს "ატვირთვის შესრულება". ჩვენ ვასრულებთ მსგავს მოქმედებებს მეორე კონფიგურაციის სტრუქტურის აღწერით.

ახლა ყველაფერი მზად არის გაცვლის წესების შესაქმნელად. CD-ის მთავარ მენიუში აირჩიეთ "References" -> "Conversions". ახალი ელემენტის დამატება. ახალი კონვერტაციის შექმნის ფანჯარაში უნდა მიუთითოთ: წყაროს კონფიგურაცია (აირჩიეთ UT) და მიმღების კონფიგურაცია (აირჩიეთ "მიმღები"). შემდეგ გახსენით "Advanced" ჩანართი და შეავსეთ შემდეგი ველები:

• გაცვლის წესები ფაილის სახელი - შექმნილი გაცვლის წესები შეინახება ამ სახელით. ფაილის სახელი შეიძლება შეიცვალოს ნებისმიერ დროს, მაგრამ უმჯობესია დააყენოთ ის ახლავე. ეს დაზოგავს დროს მომავალში. მე დავასახელე დემოს წესები: "rules-ut-to-priemnik.xml".
• სახელი - კონვერტაციის სახელი. სახელი შეიძლება იყოს აბსოლუტურად ნებისმიერი, მე შემოვიფარგლე „დემოთი. UT მიმღებამდე“.

ეს არის ის, დააჭირეთ "Ok". მაშინვე ჩვენს თვალწინ ჩნდება ფანჯარა, რომელიც გვთხოვს ავტომატურად შევქმნათ ყველა წესი. ასეთ მაცდურ შეთავაზებაზე დათანხმება მასტერს მისცემს ბრძანებას ავტომატურად გააანალიზოს არჩეული კონფიგურაციების აღწერა და დამოუკიდებლად შექმნას გაცვლის წესები.

მოდი, მაშინვე დავასრულოთ წერტილი "და". ოსტატი ვერაფერს სერიოზულს ვერ გამოიმუშავებს. თუმცა, ეს შესაძლებლობა არ უნდა იყოს შემცირებული. თუ თქვენ გჭირდებათ გაცვლის დამყარება იდენტურ კონფიგურაციებს შორის, მაშინ ოსტატის სერვისები ძალიან სასარგებლო იქნება. ჩვენი მაგალითისთვის სასურველია მექანიკური რეჟიმი.

მოდით უფრო ახლოს მივხედოთ "გაცვლის წესების პარამეტრების" ფანჯარას. ინტერფეისი შეიძლება ოდნავ დამაბნეველი ჩანდეს - დიდი რიცხვიჩანართები სავსეა კონტროლით. სინამდვილეში ყველაფერი არც ისე რთულია, ამ სიგიჟეს აპლიკაციით რამდენიმესაათიანი მუშაობის შემდეგ იწყებ შეგუებას.

Ზე ამ ეტაპზეჩვენ გვაინტერესებს ორი ჩანართი: „ობიექტის კონვერტაციის წესები“ და „მონაცემების ატვირთვის წესები“. პირველზე უნდა დავაწესოთ შესატყვისი წესები, ე.ი. შეადარეთ ორი კონფიგურაციის ობიექტები. მეორეზე, განსაზღვრეთ შესაძლო ობიექტები, რომლებიც ხელმისაწვდომი იქნება მომხმარებლისთვის განტვირთვისთვის.

"ობიექტების კონვერტაციის წესების" ჩანართის მეორე ნახევარში არის დამატებითი პანელი ორი ჩანართით: "საკუთრების კონვერტაცია" და " ღირებულების კონვერტაცია". პირველი შეარჩევს არჩეული ობიექტის თვისებებს (რეკვიზიტებს), ხოლო მეორე აუცილებელია წინასწარ განსაზღვრულ მნიშვნელობებთან მუშაობისთვის (მაგალითად, წინასწარ განსაზღვრული ლექსიკონის ელემენტები ან ჩამოთვლის ელემენტები).

კარგია, ახლა მოდით შევქმნათ დირექტორიების კონვერტაციის წესები. თქვენ შეგიძლიათ შეასრულოთ ეს მოქმედება ორი გზით: გამოიყენეთ ობიექტების სინქრონიზაციის ოსტატი (დააწკაპუნეთ "") ან დაამატეთ შესატყვისები თითოეული ობიექტისთვის ხელით.

სივრცის დაზოგვის მიზნით, ჩვენ გამოვიყენებთ პირველ ვარიანტს. ოსტატის ფანჯარაში მოხსენით ველი " Დოკუმენტები” (ჩვენ გვაინტერესებს მხოლოდ დირექტორიები) და გავაფართოვოთ ჯგუფი ” Ცნობარები". ჩვენ ყურადღებით გადავხედავთ სიას და ვათვალიერებთ დირექტორიების სახელებს, რომელთა შედარებაც შესაძლებელია.

ჩემს შემთხვევაში სამი ასეთი დირექტორია: ნომენკლატურა, ორგანიზაციები და საწყობები. ასევე არის კლიენტების დირექტორია, რომელიც ასრულებს იგივე სემანტიკურ დატვირთვას, როგორც " კონტრაგენტები”კონფიგურაციიდან” UT". მართალია, ოსტატმა ვერ შეძლო მათი შედარება მათი შესანიშნავი სახელების გამო.

ჩვენ თვითონ შეგვიძლია გამოვასწოროთ ეს ხარვეზი. იპოვნეთ ფანჯარაში ობიექტების რუქები»სახელმძღვანელო» კლიენტები", ხოლო სვეტში "წყარო" აირჩიეთ საცნობარო წიგნი "კონტრაგენტები". შემდეგ მონიშნეთ ყუთი "ტიპი" სვეტში და დააჭირეთ ღილაკს "Ok".

Object Synchronization Wizard მოგთხოვთ ავტომატურად შექმნათ წესები ყველა არჩეული ობიექტის თვისებების კონვერტაციისთვის. თვისებები დაემთხვევა სახელს და ჩვენი დემონსტრირებისთვის ეს სავსებით საკმარისი იქნება, ვეთანხმებით. შემდეგი შეკითხვა იქნება წინადადება ატვირთვის წესების შესაქმნელად. მოდით შევთანხმდეთ.

გაცვლის წესების საფუძველი მზად არის. ჩვენ შევარჩიეთ ობიექტები სინქრონიზაციისთვის და ავტომატურად შეიქმნა თვისებების კონვერტაციისა და ატვირთვის წესები. მოდით შევინახოთ გაცვლის წესები ფაილში, შემდეგ გავხსნათ IB “Source” (ჩემს შემთხვევაში ეს არის UT) და დავიწყოთ მასში სერვისის დამუშავება. V8Exchan82.epf.

პირველ რიგში, დამუშავების ფანჯარაში აირჩიეთ ჩვენ მიერ შექმნილი გაცვლის წესები. წესების ჩატვირთვის კითხვას დადებითად ვპასუხობთ. დამუშავება გააანალიზებს გაცვლის წესებს და ააშენებს ამავე სახელწოდების ხეს განტვირთვისთვის ხელმისაწვდომი ობიექტებისთვის. ამ ხისთვის ჩვენ შეგვიძლია დავაყენოთ ყველა სახის ფილტრი ან გავცვალოთ კვანძები, რომელთა შეცვლით უნდა შევარჩიოთ მონაცემები. ჩვენ გვინდა ავტვირთოთ აბსოლუტურად ყველა მონაცემი, ამიტომ არ არის საჭირო ფილტრების დაყენება.

ფაილში მონაცემების ატვირთვის პროცესის დასრულების შემდეგ გადადით IB " მიმღები". ჩვენ ასევე ვხსნით მასში დამუშავებას V8Exchan82.epf, მხოლოდ ამჯერად გადავდივართ ჩანართზე „მონაცემების ჩატვირთვა“. აირჩიეთ მონაცემთა ფაილი და დააჭირეთ ღილაკს "ატვირთვა". ყველაფერი, მონაცემები წარმატებით გადაიტანეს.

ამოცანები რეალური სამყაროდან

პირველი დემო შეიძლება იყოს შეცდომაში შემყვანი. ყველაფერი საკმაოდ მარტივი და ლოგიკური ჩანს. სინამდვილეში ეს სიმართლეს არ შეესაბამება. რეალურ სამუშაოში წარმოიქმნება ამოცანები, რომელთა გადაჭრაც მხოლოდ ვიზუალური საშუალებების გამოყენებით (პროგრამირების გარეშე) რთული ან სრულიად შეუძლებელია.

იმისთვის, რომ ტექნოლოგიაში იმედგაცრუებული არ ვიყო, მოვამზადე რამდენიმე რეალური დავალება. მათ სამსახურში აუცილებლად შეხვდებით. ისინი არც ისე ტრივიალურად გამოიყურებიან და აიძულებენ შეხედოთ მონაცემთა კონვერტაციას ახალი კუთხით. ყურადღებით გაითვალისწინეთ წარმოდგენილი მაგალითები და თავისუფლად გამოიყენეთ ისინი როგორც ფრაგმენტები რეალური პრობლემების გადაჭრისას.

დავალება ნომერი 1. შეავსეთ გამოტოვებული დეტალები

დავუშვათ, რომ ჩვენ გვჭირდება დირექტორია " კონტრაგენტები". მიმღებს აქვს მსგავსი საცნობარო წიგნი "კლიენტები" ამისათვის. ის სრულიად შესაფერისია მონაცემთა შესანახად, მაგრამ აქვს საყრდენი " ორგანიზაცია”, რაც საშუალებას გაძლევთ გამოყოთ კონტრაგენტები ორგანიზაციაში კუთვნილებით. ნაგულისხმევად, ყველა კონტრაგენტი უნდა ეკუთვნოდეს მიმდინარე ორგანიზაციას (მისი მიღება შესაძლებელია ამავე სახელწოდების მუდმივიდან).

პრობლემის რამდენიმე გამოსავალი არსებობს. ჩვენ განვიხილავთ რეკვიზიტების შევსების ვარიანტს ” ორგანიზაცია”სწორედ ბაზაზე” მიმღები“, ე.ი. მონაცემთა ჩატვირთვის დროს. მიმდინარე ორგანიზაცია ინახება მუდმივში, ამიტომ არ არსებობს ბარიერი ამ მნიშვნელობის მისაღებად. მოდით გავხსნათ ობიექტის კონვერტაციის წესი (შემდგომში FRP) ” კლიენტები” (ორმაგად დააწკაპუნეთ ობიექტზე) და წესების დაყენების ოსტატში გადადით განყოფილებაში “მოვლენის დამმუშავებლები”. დამმუშავებელთა სიაში ვხვდებით " ჩატვირთვის შემდეგ”.

მოდით აღვწეროთ კოდი მიმდინარე ორგანიზაციის მისაღებად ატრიბუტზე შემდგომი მინიჭებით. „ჩატვირთვის შემდეგ“ დამმუშავებლის გაშვების მომენტში, ობიექტი სრულად ჩამოყალიბდება, მაგრამ ჯერ არ ჩაიწერება მონაცემთა ბაზაში. არავინ გვიკრძალავს მის შეცვლას ჩვენი შეხედულებისამებრ:

თუ NOT Object.ThisGroup, მაშინ Object.Organization = Constants.CurrentOrganization.Get(); Დაასრულე თუ;

რეკვიზიტების შევსებამდე " ორგანიზაცია» აუცილებელია ატრიბუტის მნიშვნელობის შემოწმება « ეს ჯგუფი". მეგზურისთვის" კლიენტები» იერარქიული დროშა დაყენებულია, ამიტომ ჯგუფის შემოწმება აუცილებელია. ანალოგიურად, ნებისმიერი დეტალის შევსება ხორციელდება. დარწმუნდით, რომ წაიკითხეთ დახმარება სხვა დამმუშავებლის ვარიანტებისთვის " ჩატვირთვის შემდეგ". მაგალითად, მათ შორის არის პარამეტრი " უარი". თუ მას ენიჭება მნიშვნელობა "True", მაშინ ობიექტი არ ჩაიწერება მონაცემთა ბაზაში. ამრიგად, შესაძლებელი ხდება ჩატვირთვის დროს ობიექტების შეზღუდვა ჩასაწერად.

დავალება ნომერი 2. დეტალები საინფორმაციო რეესტრში

სახელმძღვანელოში " კონტრაგენტები"UT კონფიგურაცია, არის დეტალები" მყიდველი"და" პროვაიდერი". ორივე საყრდენი არის ტიპის " ლოგიკური” და გამოიყენება კონტრაგენტის ტიპის დასადგენად. IB-ში" მიმღები”, საცნობარო წიგნში ” კლიენტები„მსგავსი დეტალები არ არსებობს, მაგრამ არის ინფორმაციის რეესტრი“ კლიენტების ტიპები". ის ასრულებს მსგავს ფუნქციას და შეუძლია შეინახოს მრავალი ტეგი ერთი კლიენტისთვის. ჩვენი ამოცანაა დეტალების მნიშვნელობების გადატანა საინფორმაციო რეესტრის ცალკეულ ჩანაწერებში.

სამწუხაროდ, მარტო ვიზუალური საშუალებები აქაც ვერ უმკლავდება. დავიწყოთ მცირედით, შევქმნათ ახალი PCO საინფორმაციო რეესტრისთვის. კლიენტების ტიპები". არ ჩამოთვალოთ არაფერი წყაროდ. უარი თქვით ატვირთვის წესების ავტომატურ შექმნაზე.

შემდეგი ნაბიჯი არის ატვირთვის წესების შექმნა. გადადით შესაბამის ჩანართზე და დააჭირეთ ღილაკს " დამატება". ატვირთვის წესების დამატების ფანჯარაში შეავსეთ:

• შერჩევის მეთოდი. „თვითნებური ალგორითმის“ შეცვლა;
• კონვერტაციის წესი. აირჩიეთ საინფორმაციო რეესტრი „მომხმარებელთა ტიპები“;
• წესის კოდი (სახელი). ჩვენ მას ვწერთ, როგორც „კლიენტის სახეობების ატვირთვა“;

ახლა თქვენ უნდა დაწეროთ კოდი ასატვირთად მონაცემების შესარჩევად. აქ არის პარამეტრი " მონაცემთა შერჩევა". მასში ჩვენ შეგვიძლია მოვათავსოთ კოლექცია მომზადებული მონაცემთა ნაკრებით. Პარამეტრი " მონაცემთა შერჩევა” შეუძლია მიიღოს სხვადასხვა მნიშვნელობები - შეკითხვის შედეგი, შერჩევა, მნიშვნელობების კრებული და ა.შ. ჩვენ ვაკეთებთ მას მნიშვნელობების ცხრილის სახით ორი სვეტით: კლიენტი და კლიენტის ტიპი.

ქვემოთ მოცემულია მოვლენის დამმუშავებლის კოდი " დამუშავებამდე". ის ახდენს პარამეტრის ინიციალიზაციას " მონაცემთა შერჩევა” რასაც მოჰყვება მონაცემების შევსება დირექტორიადან” კონტრაგენტები". აქ ღირს ყურადღება მიაქციოთ სვეტის შევსებას ” კლიენტის ტიპი". "UT"-ში გვაქვს "Boolean" ტიპის მახასიათებლები, ხოლო მიმღებში - ჩამოთვლა.

ამ ეტაპზე მათ სასურველ ტიპამდე ვერ მივიყვანთ (UT-ში არ არის), ამიტომ ამ დროისთვის დავტოვებთ სტრიქონების სახით. თქვენ არ გჭირდებათ ამის გაკეთება, მაგრამ მე დაუყოვნებლივ მინდა გაჩვენოთ, თუ როგორ უნდა გადავიტანოთ წყაროში დაკარგული ტიპი.

DataFetch = NewValueTable(); მონაცემთა შერჩევა.Columns.Add("კლიენტი"); Data Selection.Columns.Add("ClientType"); შერჩევა DataFrom the Directory = Directories.Contractors.Select(); DataFromCatalog.Next()-ის ამოღებისას ციკლი If FetchingDataFromCatalog.ThisGroup შემდეგ გააგრძელეთ; Დაასრულე თუ; If DataFetchFromCatalog.Buyer მაშინ NewString = DataFetch.Add(); NewString.Client = SamplingDataFromCatalog.Reference; NewString.ClientType = "მყიდველი"; Დაასრულე თუ; If DataFetchFromCatalog.Provider მაშინ NewString = DataFetch.Add(); NewString.Client = SamplingDataFromCatalog.Reference; NewString.ClientType = "მიმწოდებელი"; Დაასრულე თუ; საბოლოო ციკლი;

შეინახეთ მონაცემთა ატვირთვის წესი და დაბრუნდით " ობიექტების კონვერტაციის წესები". დავამატოთ საინფორმაციო რეესტრი“ კლიენტების ტიპები” ქონების კონვერტაციის წესები: კლიენტი და კლიენტის ტიპი. წყაროს ცარიელი ვტოვებთ და ღონისძიების „განტვირთვამდე“ ვწერთ:

//„კლიენტი“ თვისებისთვის Value = Source.Client; //„CustomerType“ თვისებისთვის If Source.Customer = "Buyer" Then Expression = "Enumerations.CustomerTypes.Buyer" ElseIf Source.Customer = "Supplier" then Expression = "Enumerations.CustomerTypes.Supplier"; Დაასრულე თუ;

ჩამონათვალში დეტალები ივსება გაკეთებული მონაცემების შერჩევის საფუძველზე. ჩვენ კლიენტს გადავცემთ უბრალოდ ბმულის სახით და ვწერთ კლიენტის ტიპს პარამეტრში " გამოხატულება". ამ პარამეტრის მონაცემები ინტერპრეტირებული იქნება მიმღებში და შესრულებისას ატრიბუტი შეივსება სწორი მნიშვნელობით ჩამოთვლიდან.

ესე იგი, გაცვლის წესები მზადაა, განხილული მაგალითი საკმაოდ უნივერსალური აღმოჩნდა. მსგავსი მიდგომა ხშირად გამოიყენება 7.7 პლატფორმაზე შექმნილი კონფიგურაციებიდან მონაცემების გადაცემისას. ამის ნათელი მაგალითია პერიოდული დეტალების გადაცემა.

დავალება ნომერი 3. ცხრილის ხრიკები

ხშირად არის დავალებები, რომლებიც მოითხოვს ერთი ცხრილის ნაწილის სტრიქონების რამდენიმე ნაწილად განთავსებას. მაგალითად, საწყის კონფიგურაციაში სერვისები და საქონელი რეგისტრირებულია ერთ ცხრილის განყოფილებაში, ხოლო ამ ერთეულების შენახვა გამოყოფილია მიმღებში. ისევ და ისევ, პრობლემა ვერ მოგვარდება ვიზუალური საშუალებებით. აქ მოსახერხებელია მეორე პრობლემის გადაწყვეტის საფუძველი.

ჩვენ ვქმნით მონაცემთა ატვირთვის წესს, ვაზუსტებთ თვითნებურ ალგორითმს და ვწერთ შეკითხვას „ატვირთვამდე“ დამმუშავებელში, რათა მივიღოთ მონაცემები ცხრილის განყოფილებიდან.

სივრცის დაზოგვის მიზნით, მე არ მივცემ მოთხოვნის კოდს (ყოველთვის შეგიძლიათ მიმართოთ წყაროს კოდს) - მასში უჩვეულო არაფერია. ჩვენ ვახარისხებთ მიღებულ ნიმუშს და ვათავსებთ დახარისხებულ შედეგებს უკვე ნაცნობ პარამეტრში. მონაცემთა შერჩევა". კიდევ ერთხელ, მოსახერხებელია ღირებულებების ცხრილის გამოყენება, როგორც კოლექცია:

DataFetch = NewValueTable(); //აქ იქნება კიდევ ერთი ცხრილის განყოფილება Data Selection.Columns.Add("პროდუქტები"); //აქ ასევე იქნება ცხრილის განყოფილება Data Selection.Columns.Add("სერვისები"); მონაცემების შერჩევა.Columns.Add(„ბმული“);

დავალება ნომერი 4. მონაცემთა გადაცემა ოპერაციაზე

თუ ორგანიზაცია იყენებს რამდენიმე სააღრიცხვო სისტემას, მაშინ ადრე თუ გვიან საჭირო იქნება მონაცემთა მიგრაცია შემდგომი განცხადებების ფორმირებით.

კონფიგურაციაში " BP"არსებობს უნივერსალური დოკუმენტი" Ოპერაცია”და იდეალურია მეტი მავთულის ჩამოსაყალიბებლად. აქ მხოლოდ ერთი პრობლემაა - დოკუმენტი ეშმაკურად არის შედგენილი და მასში მონაცემების გადატანა არც ისე ადვილია.

ასეთი კონვერტაციის მაგალითი შეგიძლიათ იხილოთ სტატიის საწყის კოდში. კოდის რაოდენობა საკმაოდ დიდი აღმოჩნდა, ამიტომ სტატიისთვის მის გამოქვეყნებას აზრი არ აქვს. მხოლოდ იმას ვიტყვი, რომ ატვირთვა ისევ იყენებს თვითნებურ ალგორითმს მონაცემთა ატვირთვის წესებში.

დავალება ნომერი 5. მონაცემთა სინქრონიზაცია მრავალი ატრიბუტით

ჩვენ უკვე განვიხილეთ რამდენიმე მაგალითი, მაგრამ აქამდე არ გვისაუბრია ობიექტის სინქრონიზაციაზე მიგრაციის დროს. წარმოვიდგინოთ, რომ ჩვენ გვჭირდება კონტრაგენტების გადაცემა და ზოგიერთი მათგანი ალბათ მიმღების მონაცემთა ბაზაშია. როგორ გადავიტანოთ მონაცემები და თავიდან აიცილოთ დუბლიკატები? ამასთან დაკავშირებით, CD გთავაზობთ რამდენიმე გზას გადაცემული ობიექტების სინქრონიზაციისთვის.

პირველი არის უნიკალური იდენტიფიკატორით. ბევრ ობიექტს აქვს უნიკალური იდენტიფიკატორი, რომელიც უზრუნველყოფს ცხრილის უნიკალურობას. მაგალითად, სახელმძღვანელოში " კონტრაგენტები” არ შეიძლება ჰქონდეს ორი ელემენტი იგივე ID-ით. CD აკეთებს გამოთვლას ამისათვის და ყველა შექმნილი PSP-ისთვის, იდენტიფიკატორის მიხედვით ძიება დაუყოვნებლივ ჩართულია ნაგულისხმევად. PSP-ის შექმნისას თქვენ უნდა შეემჩნიათ გამადიდებელი შუშის ხატულა ობიექტის სახელთან.

უნიკალური იდენტიფიკატორით სინქრონიზაცია საიმედო მეთოდია, მაგრამ ის ყოველთვის არ არის მიზანშეწონილი. დირექტორიების გაერთიანებისას " კონტრაგენტები” (რამდენიმე სხვადასხვა სისტემიდან) მას მცირე დახმარება აქვს.

ასეთ შემთხვევებში უფრო სწორია ობიექტების სინქრონიზაცია რამდენიმე კრიტერიუმის მიხედვით. უფრო სწორია კონტრაგენტების მოძიება TIN-ის, KPP-ის, დასახელების მიხედვით ან ძიების რამდენიმე ეტაპად დაყოფა.

მონაცემთა კონვერტაცია არ ზღუდავს დეველოპერს საძიებო კრიტერიუმების განსაზღვრაში. განვიხილოთ აბსტრაქტული მაგალითი. დავუშვათ, რომ ჩვენ გვჭირდება დირექტორიების სინქრონიზაცია " კონტრაგენტები“ სხვადასხვა საინფორმაციო ბაზებიდან. მოდით მოვამზადოთ PCP და ობიექტის კონვერტაციის წესების პარამეტრებში, მონიშნეთ ყუთი ” განაგრძეთ საძიებო ველების ძებნა, თუ მიმღების ობიექტი ID-ით ვერ მოიძებნა". ამ მოქმედებით ჩვენ დაუყოვნებლივ განვსაზღვრეთ ძიების ორი კრიტერიუმი - უნიკალური იდენტიფიკატორით და თვითნებური ველებით.

ჩვენ გვაქვს უფლება თავად ავირჩიოთ სფეროები. TIN, KPP, სახელის აღნიშვნის შემდეგ, ჩვენ დაუყოვნებლივ მივუთითებთ ძიების რამდენიმე კრიტერიუმს. კომფორტული? საკმაოდ, მაგრამ კიდევ ერთხელ, ეს საკმარისი არ არის. და რა მოხდება, თუ გვინდა ძიების კრიტერიუმების შეცვლა? მაგალითად, ჯერ ვეძებთ TIN + KPP-ის თაიგულს და თუ ვერაფერს ვიპოვით, მაშინ ვიწყებთ ბედის ცდას სახელით.

სავსებით შესაძლებელია ასეთი ალგორითმის განხორციელება. ღონისძიების დამმუშავებელში საძიებო ველებიჩვენ შეგვიძლია განვსაზღვროთ ძიების 10-მდე კრიტერიუმი და თითოეული მათგანისთვის განვსაზღვროთ საძიებო ველების საკუთარი შემადგენლობა:

თუ SearchOptionNumber = 1, მაშინ SearchPropertyNameString = “TIN, KPP”; ElseIfSearchVariantNumber = 2 ThenSearchPropertyNameString = „Name“; Დაასრულე თუ;

ყოველთვის არის მრავალი გამოსავალი.

ნებისმიერ ამოცანას აქვს რამდენიმე გამოსავალი და მონაცემთა გადაცემა სხვადასხვა კონფიგურაციას შორის არ არის გამონაკლისი. თითოეულ დეველოპერს აქვს უფლება აირჩიოს საკუთარი გადაწყვეტის გზა, მაგრამ თუ თქვენ მუდმივად გიწევთ მონაცემთა რთული მიგრაციის შემუშავება, მაშინ გირჩევთ, ყურადღება მიაქციოთ "" კონფიგურაციას. დაე, თავიდან მოგიწიოთ რესურსების (დრო) ინვესტირება ტრენინგში, მაგრამ ისინი უფრო მეტს გადაიხდიან პირველ მეტ-ნაკლებად სერიოზულ პროექტზე.

ჩემი აზრით, 1C კომპანია დაუმსახურებლად გვერდს უვლის მონაცემთა კონვერტაციის გამოყენების თემას. ტექნოლოგიის არსებობის მთელი პერიოდის განმავლობაში მასზე მხოლოდ ერთი წიგნი გამოიცა: „1C: Enterprise 8. მონაცემთა კონვერტაცია: გაცვლა აპლიკაციის გადაწყვეტილებებს შორის“. წიგნი საკმაოდ ძველია (2008), მაგრამ მაინც სასურველია მისი გაცნობა.

პლატფორმის ცოდნა ჯერ კიდევ საჭიროა

» არის უნივერსალური ინსტრუმენტი, მაგრამ თუ თქვენ აპირებთ მის გამოყენებას მონაცემთა მიგრაციის შესაქმნელად 1C:Enterprise 7.7 პლატფორმისთვის შემუშავებული კონფიგურაციებიდან, მაშინ მოგიწევთ დროის დახარჯვა ჩაშენებული ენის გასაცნობად. ენის სინტაქსი და იდეოლოგია ძალიან განსხვავებულია, ამიტომ დრო უნდა დახარჯო სწავლაზე. დანარჩენი პრინციპი იგივე რჩება.

წლების განმავლობაში შრომისმოყვარეობისა და მნიშვნელოვანი დოკუმენტების შეგროვებული მონაცემები არ უნდა დაიკარგოს მხოლოდ იმიტომ, რომ მეტი ახალი პლატფორმაან კონფიგურაცია 1C. ამის თავიდან ასაცილებლად, არსებობს მონაცემთა გადაცემის შესაძლებლობა.

მონაცემთა გადაცემა ერთი კონფიგურაციიდან მეორეზე გადასვლის ერთ-ერთი ყველაზე მნიშვნელოვანი ნაწილია.

იმისთვის, რომ მონაცემები უსაფრთხოდ და ჯანსაღად გადაიცეს, ეს სამუშაო პროფესიონალებს უნდა მიანდოთ. ჩვენი გუნდი ყველა სამუშაოს შეასრულებს ხარისხიანად და დროულად.

მიგრაციის ნაბიჯები

მონაცემთა გადაცემა 5 ეტაპისგან შედგება. ჩვენ შევეცადეთ აღვწეროთ ისინი რაც შეიძლება დეტალურად და ნათლად.

რატომ არის ჩვენი მონაცემთა გადაცემა უკეთესი?

ტიპიური მონაცემთა გადაცემის ღირებულება

ახალი პროგრამის შენარჩუნება

ყველა მონაცემის გადაცემის შემდეგ შეიძლება დაგჭირდეთ თქვენი პროგრამის შენარჩუნება. ჩვენ მზად ვართ მოგაწოდოთ იგი!

გადასვლა 1C-ზე 8.2

დეტალები ერთი პლატფორმიდან მეორეზე გადასვლის სხვა ეტაპების შესახებ. ლიცენზიის განახლება, კონფიგურაცია, ტრენინგი, მხარდაჭერა. ჩვენი ექსპერტები მზად არიან გაგიწიოთ ყველა საჭირო დახმარება!

რატომ ვართ უკეთესები?

შეკვეთის გადაცემა

ჩვენი გუნდი

რატომ არის ჩვენი 1C გადაცემა უკეთესი?

გამჭვირვალობა

დირექტორიების 1C 8.2 და თქვენი სხვა მონაცემების გადაცემამდე, ჩვენი სპეციალისტები დეტალურად გეტყვიან სამუშაოს ყველა ეტაპის შესახებ. ანდობთ თქვენს ბაზას, თქვენ ყოველთვის იცით, რა კეთდება, რა თანმიმდევრობით და რამდენს იხდით მუშაობის თითოეულ ეტაპზე.

ინდივიდუალური მიდგომა

სანამ უშუალოდ 1C 7.7-ზე 1C 8.2-ზე გადატანას დაიწყებთ, ჩვენი სპეციალისტები ჩაატარებენ თქვენი მონაცემთა ბაზის სიღრმისეულ ანალიზს. დიდი ალბათობით, 1C-ის ახალ ვერსიას უკვე აქვს ყველა ის გაუმჯობესება, რაც გჭირდებათ. ნებისმიერ შემთხვევაში, ჩვენ გირჩევთ კიდევ რა დაგჭირდეთ კომფორტული მუშაობისთვის.

ხარისხი

გადაცემის ყველაზე გადამწყვეტ ეტაპამდე, ჩვენი სპეციალისტები ყოველთვის ახორციელებენ 1C მონაცემთა ბაზების საცდელ გადაცემას, რათა გამოავლინონ შესაძლო შეცდომები, გამეორებები და მონაცემთა დაკარგვა. მაგრამ თავად ტრანსფერის შემდეგაც, ჩვენ აუცილებლად შევამოწმებთ ყველაფერს, რომ კიდევ უფრო დავრწმუნდეთ მის ხარისხში.

იმუშავეთ შედეგისთვის

სამუშაო ჩაითვლება დასრულებულად მხოლოდ მას შემდეგ, რაც დარწმუნდებით, რომ 1C 8 დირექტორიების და სხვა მონაცემების გადაცემა სწორად არის შესრულებული და შედეგით კმაყოფილი დარჩებით. ჩვენ არ ვტოვებთ ჩვენს კლიენტებს!

ეტაპი 1. წყაროს მონაცემთა ბაზის ზოგადი ანალიზი

რა სამუშაოა შესრულებული:

წყაროს მონაცემთა ბაზის მსგავსი ვერსიის ტიპიური კონფიგურაციის მიღება;

მონაცემთა სტრუქტურაში ცვლილებების ზოგადი ანალიზი (ტიპიურ კონფიგურაციასთან შედარება);

კონფიგურაციის ფორმებსა და მოდულებში ცვლილებების ზოგადი ანალიზი (ტიპიურ კონფიგურაციასთან შედარება);

სააღრიცხვო კონფიგურაციისთვის არასტანდარტული აღრიცხვის ანგარიშების არსებობის კონტროლი;

ზოგადი კონტროლი წყაროს მონაცემთა ბაზაში აღრიცხვის სისწორეზე („წითელი“ ნაშთების არსებობა, დაუხურავი პერიოდები, ამოუხსნელი მიმდევრობები და ა.შ.);

წყაროს მონაცემთა ბაზის განახლება სტანდარტული მიგრაციის წესებით საჭირო ვერსიით;

მონაცემთა საცდელი გადაცემა;

შესაძლო რეკომენდაციების მომზადება 1C 8 დირექტორიების და სხვა მონაცემების გადაცემის წყაროს ბაზის მოსამზადებლად.

რატომ:

ტიპიური ტრანსფერის გამოყენების შესაძლებლობის განსაზღვრა;

გაუმჯობესების სირთულის შეფასება და ტექნიკური დოკუმენტაციის მომზადება გადასატანად (თუ ტიპიური ტრანსფერის გამოყენება შეუძლებელია).

წყაროს ბაზის ზოგადი ანალიზის განხორციელების შემდეგ, შესაძლებელია დადასტურება, რომ მონაცემთა გადაცემა შესაძლებელია სტანდარტული საშუალებებით, ამ შემთხვევაში, გადარიცხვის სერვისის შემდგომი ღირებულება განისაზღვრება ტიპიური გადარიცხვის ფასების სიის მიხედვით, დამოკიდებულია კონფიგურაცია.

თუ სწორი ტიპიური გადარიცხვა შეუძლებელია, მაშინ მზადდება შეთავაზება სამუშაოს ღირებულებით კონფიგურაციის, გაცვლის წესების და არასტანდარტული გადარიცხვის დასასრულებლად.

ფასი: 2000 რუბლი

ეტაპი 2. ტექნიკური დოკუმენტაციის მომზადება არასტანდარტული გადაცემისთვის

რა სამუშაოა შესრულებული:

ტარდება წყაროს ბაზის სტანდარტული კონფიგურაციის არსებული ცვლილებების სიღრმისეული ანალიზი, ამ ცვლილებების შედარება სტანდარტული კონფიგურაციის ანალოგიურ ვერსიასთან და მიმღების ბაზის სტანდარტული კონფიგურაციის ახალ ვერსიასთან;

კლიენტის პასუხისმგებელ პირებთან კომუნიკაცია გამოვლენილი გაუმჯობესების აუცილებლობის დასადგენად, გაუმჯობესების გამოყენების მეთოდების გარკვევა, გაუმჯობესების გაუმჯობესების წინადადებების შეგროვება (საჭიროების შემთხვევაში);

შედგენილია წყაროს ბაზის სტანდარტული კონფიგურაციის არსებული გაუმჯობესებების სია;

მიმღების ბაზის სტანდარტული კონფიგურაციის რეკომენდირებული გაუმჯობესების სია შედგენილია და შეთანხმებულია, ტიპიური კონფიგურაციის სტანდარტული ფუნქციონირების გათვალისწინებით (შესაძლებელია, რომ გადასინჯვა არ იყოს საჭირო, თუ მიმღების კონფიგურაციას უკვე აქვს მსგავსი სტანდარტული ფუნქციონირება);

მიმდინარეობს ტექნიკური სპეციფიკაციის პროექტი და დამტკიცება მიმღების ბაზის კონფიგურაციის დასასრულებლად, გაცვლის წესების დასასრულებლად, აღწერა
გადაცემის არასტანდარტული პროცედურები (საჭიროების შემთხვევაში).

რატომ:

1C მონაცემთა ბაზების არასტანდარტულ გადაცემაზე მუშაობის ხარისხისა და გამჭვირვალობის გარანტია;

ზუსტი ხარჯთაღრიცხვა და სამუშაოს ხანგრძლივობა;

მიგრაციული სამუშაოების შესრულების შესაძლებლობა 1C პროგრამისტის სრულ განაკვეთზე საჭირო დონის ხარისხის ჩართულობით.

თუ ტექნიკური დოკუმენტაციის მითითებული ნაკრები არ არის ხელმისაწვდომი, არასტანდარტული გადარიცხვები 1C კონფიგურაციებს შორის ხორციელდება მხოლოდ საათობრივად. ამ შემთხვევაში შეუძლებელია სამუშაოს ღირებულებისა და ხანგრძლივობის ზუსტი გარანტია წინასწარ. თუმცა, ამ შემთხვევაში, შესაძლებელია გარკვეული დაზოგვა დროში და ხარჯებში დოკუმენტაციის ნაკრების მომზადებისთვის.

ფასი: დაზუსტდება წყაროს ბაზის ზოგადი ანალიზის შედეგების საფუძველზე.

ეტაპი 3. მიმღების კონფიგურაციის დასრულება

რა სამუშაოა შესრულებული:

მიმღების ბაზის სტანდარტული კონფიგურაცია სრულდება ტექნიკური მახასიათებლების საფუძველზე, ან დამკვეთის მითითებების შესაბამისად (საათობრივი სამუშაოსთვის);

ტარდება გაუმჯობესების წინასწარი ტესტირება;

გაუმჯობესებები დოკუმენტირებულია ტიპიური კონფიგურაციის ცვლილებების შესახებ მოხსენების სახით (მომსახურების ინჟინრის შემდგომი განახლების შესაძლებლობისთვის);

ხორციელდება მომხმარებლისთვის გაუმჯობესების დემონსტრირება (სამუშაოების მიწოდება და მიღება);

შემუშავებულია მომხმარებლის სახელმძღვანელო ცვლილებებისთვის (საჭიროების შემთხვევაში).

რატომ:

თქვენ იღებთ უახლესი ვერსიაკონფიგურაციები თქვენთვის საჭირო ცვლილებებით;

თქვენ იღებთ დოკუმენტაციას შემდგომი გაუმჯობესების შესახებ
განახლებები სერვისის ინჟინრის მიერ.

ეტაპი 4. გადაცემის წესების დასრულება

რა სამუშაოა შესრულებული:

1C-დან გადაცემის სტანდარტული წესები სრულდება, რათა გათვალისწინებულ იქნეს წყაროს ბაზის სტანდარტული კონფიგურაციის მონაცემთა სტრუქტურაში ცვლილებები, ისევე როგორც წყაროს ბაზაში გამოყენებული არასტანდარტული სააღრიცხვო ანგარიშები;

ცვლილებების გათვალისწინებით ტარდება გადარიცხვის წინასწარი ტესტირება.

რატომ:

უზრუნველყოფს მონაცემთა სწორ გადაცემას, რომელიც არ არის გადაცემული სტანდარტული გაცვლის წესებით;

ასევე შეიძლება საჭირო გახდეს გადაცემის წესების დახვეწა, თუ წყაროს მონაცემთა ბაზაში აღრიცხვა არასწორად ჩატარდა გადაწყვეტის სტანდარტული მეთოდოლოგიის თვალსაზრისით, თუმცა წყაროს კონფიგურაცია შეიძლება არ შეიცავდეს გაუმჯობესებას.

ფასი: ჩამოყალიბებულია ტექნიკური დოკუმენტაციის ნაკრების საფუძველზე.

ეტაპი 5. მონაცემთა გადაცემა

რა სამუშაოა შესრულებული:

საცნობარო ინფორმაციის გადაცემა (ყველა ან ბმულით), ნაშთების გადაცემა მოცემულ თარიღზე;

გადაცემის სისწორის კონტროლი - წყაროს და დანიშნულების ბაზის მონაცემების შედარება;

მიმღებ მონაცემთა ბაზაში ნაშთების კორექტირების შესაძლო რეკომენდაციების მომზადება სხვადასხვა კონფიგურაციებში აღრიცხვის თავისებურებების გათვალისწინებით (საჭიროების შემთხვევაში).

რატომ:

თქვენ იღებთ ახალ მონაცემთა ბაზას, რომელიც მზად არის იმუშაოს თქვენს მიმდინარე ნაშთებთან.

გადარიცხვა ხორციელდება 1C-ის მიერ შემუშავებული გადაცემის წესების გამოყენებით, სპეციალურად მომხმარებლისთვის განხორციელებული გაუმჯობესებების გამოყენებით. გადაცემული მონაცემების შემადგენლობა შეიძლება განსხვავდებოდეს სხვადასხვა კონფიგურაციის ვერსიისთვის, ჩვენი სპეციალისტები გაგიწევენ რეკომენდაციას შესაძლო
გადაცემის მახასიათებლები.

ამჟამად, 1C-დან: Enterprise 7.7-ზე 8.3-ზე გადასვლა (ისევე როგორც 8.2) გახდა თავის ტკივილი ბუღალტერებისთვის. სასურველია რაც შეიძლება მალე და შეცდომების გარეშე. თუ თქვენ ხართ 1C: ბუღალტერის პროგრამისტი და გჭირდებათ ამ დოკუმენტების მეშვიდე ვერსიიდან მერვეზე გადაყვანა, მაშინ ეს სტატია თქვენთვისაა.

გადადგით რამდენიმე ნაბიჯი და თქვენი მონაცემთა გადაცემის პრობლემები მოგვარდება. წაიკითხეთ ეს სახელმძღვანელო ბოლომდე და გაიგებთ, როგორ გააკეთოთ ეს. დასაწყისისთვის, თქვენ უნდა მოამზადოთ სამუშაო ადგილი თქვენს კომპიუტერში საჭირო მანიპულაციებისთვის. პირველი, შენი HDDუნდა იყოს მინიმუმ 100 GB ზომა. ეს აუცილებელია, რადგან ნაშთების გადაცემა მრავალდონიანია. და მოგიწევთ მუშაობა რამდენიმე 7.7 კონფიგურაციით.

თუ გჭირდებათ სწრაფი და ხარისხიანი გადასვლა 1C Accounting 7.7-დან 1C 8.3-ზე, გთხოვთ დაგვიკავშირდეთ! ანაზრაურების გადასვლის საშუალო ღირებულება 6600 რუბლს შეადგენს.

მონაცემთა გადაცემა 1C 7.7-დან 1C 8.3-მდე ბუღალტერია 3.0

ასე რომ, სანამ იმუშავებთ მონაცემთა გადაცემაზე 1C 8.3 ვერსიაზე, თქვენ უნდა მოამზადოთ ეს მონაცემები 7.7 ვერსიაში. ამისათვის თქვენ უნდა გააკეთოთ შემდეგი. დავუშვათ, რომ თქვენს კომპიუტერში გაქვთ სამუშაო მონაცემთა ბაზა „საწარმოს აღრიცხვა“, რომლითაც მუშაობენ თქვენი ბუღალტერები. Export77 დამუშავების გამოყენებით, ატვირთეთ ყველა საჭირო დოკუმენტი ტექსტურ ფაილში და ამ მომენტიდან აღარ დაბრუნდებით ძირითად სამუშაო ბაზაზე. თქვენი შემდგომი მანიპულაციები მოხდება სხვა კონფიგურაციებთან ერთად.

დააინსტალირეთ ახალი Release 1C:Enterprise 7.7 ახალ დირექტორიაში. (პაკეტში შედის სტანდარტული ცარიელი (მონაცემების გარეშე) და დემო ვერსია). ჩვენ ვიმუშავებთ სტანდარტული ვერსიით. ახლა გაუშვით ეს მონაცემთა ბაზა და იმპორტი 77 დამუშავების გამოყენებით, ჩატვირთეთ მონაცემები თქვენი ძირითადი მონაცემთა ბაზიდან ტექსტური ფაილიდან.

მონაცემების კონვერტაციისას, ზოგიერთი დოკუმენტი შეიძლება არ იყოს განთავსებული. ეს არ არის საშინელი. ხრიკი ის არის, რომ თქვენ შეგიძლიათ მარტივად გამოასწოროთ ეს გადარიცხვის შემდეგ, რადგან სტანდარტულ მონაცემთა ბაზაში მუშაობთ ძირითადი სტანდარტული ანგარიშების სქემასთან. ამიტომ, რაც არ უნდა დახვეწილი იყოს ქვე-ანგარიშები, თქვენს სამუშაო მონაცემთა ბაზაში ადვილია ამის გამოსწორება დაახლოებით 3 საათში, თითოეულ გამოუქვეყნებელ დოკუმენტში შესვლით და თქვენს კონფიგურაციაში არსებული ანგარიშების შეცვლით ანგარიშის ველებში.

ბუნებრივია, წინასწარ, გადარიცხვამდე, თქვენ სტანდარტული კონფიგურაციის ანგარიშთა გეგმას ახდენთ თქვენი ძირითადი სამუშაო ბაზის ანგარიშთა გეგმასთან. პარამეტრები არის მხოლოდ ინდივიდუალური, თქვენი ორგანიზაციის სპეციფიკიდან გამომდინარე. ამ სამუშაოს შესრულების შემდეგ, თქვენ მიიღებთ სტანდარტულ კონფიგურაციას, რომელიც ივსება თქვენი სამუშაო მონაცემთა ბაზიდან.

ახლა ჩვენ უნდა გავაკეთოთ სხვა მონაცემთა გადაცემა. ამისათვის დააინსტალირეთ სტანდარტული ნულოვანი კონფიგურაცია ახალ დირექტორიაში. და უკვე იქ გადაიტანეთ მონაცემები სტანდარტული კონფიგურაციიდან თქვენი მონაცემებით, შედეგად თქვენ მიიღებთ 8.2 ვერსიაზე გადასატანად მზა 7 ვერსიის მონაცემთა ბაზას.

ფაქტია, რომ მონაცემები გადადის უშუალოდ მერვე ვერსიაში ექსკლუზიურად "ხელშეუხებელი" სტანდარტული ვერსიიდან 7.7. თქვენ ასევე გაქვთ ასეთი კონფიგურაცია ახლა. მაგრამ ახლა ის არ არის ცარიელი, არამედ თქვენი სამუშაო მონაცემებით.

ყველაფერი!ჩვენ ვიწყებთ 1C: Enterprise 8.2. აირჩიეთ "მონაცემთა გადაცემა 7.7 ვერსიიდან". და ისიამოვნეთ, თუ როგორ გადასცემს თავად პროგრამა მონაცემებს თქვენი დამუშავებული 7.7.-დან, გადასცემს დოკუმენტებს და აჩვენებს 7.7 და 8.3 ვერსიების ბალანსის შედარებით ცხრილს.

რა თქმა უნდა, 100% შედეგი არ იქნება. მაგრამ 70-80 პროცენტით თქვენ მიიღებთ შესაბამისობას. და შემდეგ თქვენი სამუშაო შესრულდება მხოლოდ 8.3 ვერსიაში.

შესაძლო უზუსტობები ადვილად გამოსწორდება. ჯერ კიდევ 3-4 საათია. მიდიხარ დოკუმენტის ჟურნალში და ან ასწორებ ანგარიშებს ან ველებს (მაგალითად, „ხელშეკრულება“ ან „მთავარი სალარო“). ეს დამოკიდებულია თქვენი ბაზის განსხვავების ხარისხზე 7.7. სტანდარტიდან. ყველა ამ მოქმედების შედეგად, თქვენი ვერსიის 8.3 სამუშაო კონფიგურაცია შეძლებს სააღრიცხვო მონაცემების გაცემას ბალანსის მეშვეობით იდეალური ფორმით.

გადასვლის შემდეგ, თქვენთვის სასარგებლო იქნება ახალ პროგრამაში მუშაობის სწავლა. ამისათვის ჩვენ მოვამზადეთ განყოფილება ტრენინგი 1C ბუღალტერია 8.3.

Ჰო მართლა! თუ გჭირდებათ 1C პროგრამების დასრულება, შეგიძლიათ დაგვიკავშირდეთ!

1C 7.7 მონაცემთა ბაზის გადატანა 8.3-ზე, როგორ გავაკეთოთ?

ბევრ ზოგად (და ზოგიერთ ინდუსტრიას სპეციფიკურ) ოქტალურ გადაწყვეტას უკვე აქვს ჩაშენებული მიგრაციის ხელსაწყოები 7.7-დან ან დამატებითი ფაილების სახით შაბლონის ინსტალაციის დირექტორიაში.

თუ თქვენ თვითონ გადაიტანეთ, მაშინ ITS დისკზე (ისევე, როგორც ინტერნეტის ბევრ ადგილას - Google-ის დასახმარებლად) არის დამუშავებული "ჩატვირთვა ცხრილების დოკუმენტიდან", რომელიც საშუალებას გაძლევთ ჩატვირთოთ თვითნებური ცხრილის მონაცემები დირექტორიაში / დოკუმენტებში. / რეგისტრირებს. საკმარისად მაღალი ცოდნის დონით, შეგიძლიათ გამოიყენოთ საბრძოლო არტილერია - სპეციალური კონფიგურაცია "მონაცემთა კონვერტაცია 2" (არ უნდა აგვერიოს 3-ში).

შეგიძლიათ მითხრათ რატომ ჩნდება ასეთი შეცდომა? 1C-ის დოკუმენტაციაში ყველა ძალიან დამაბნეველად წერს - ბოლოს და ბოლოს, ხელფასი უნდა მიიღოთ, ასე რომ, საერთოდ ვერ გაიგებთ მათ ხელნაწერებს, ომი და მშვიდობა უფრო ადვილია, ვიდრე მათი გაკვეთილები რთული სისტემის მუშაობის შესახებ.

მაქსიმ კრავჩენკო, ისე, ყველაფერი რუსულად წერია 🙂

ჩემი გამოცდილებით, ყველაზე გავრცელებული მიზეზებია:

1) გაცვლის პარამეტრებში მითითებულია არასწორი ბილიკი 7.7-დან. ან უბრალოდ არის შეცდომა, ან მითითებულია გზა არასწორი დირექტორიაში. ან ლოკალური ბილიკი მითითებულია თქვენს კომპიუტერში და გაცვლა ხდება 1C საწარმოს სერვერის მხარეს და ეს სერვერი, ბუნებრივია, ვერაფერს ხედავს თქვენს გზაზე (ჩვეულებრივი პრობლემა).
2) კომპიუტერის მხარეს, რომელიც ცდილობს 7.7-ით გაცვლას (ლოკალური ან სერვერი), არ არის სრულად დაინსტალირებული 7.7 პლატფორმა. იმათ. არ არსებობს რეგისტრირებული COM ობიექტი და ბაზა 7.7 ტრადიციულად იყო დაკავშირებული დირექტორიას გამოყენებით კომპრომეტირებული პლატფორმით, რომელსაც არ სჭირდება გასაღები ან რაიმე სისტემის მონაცემები.
3) არ არსებობს წვდომის უფლებები 7.7 ბაზის დირექტორიაზე (განსაკუთრებით მნიშვნელოვანია სერვერზე მუშაობისას, სადაც rphost სამუშაო ნაკადი მუშაობს სერვისის მომხმარებლის ქვეშ და 7.7 ბაზის დირექტორია ღიაა კონკრეტული ადამიანებისთვის).

მაქსიმ კრავჩენკო, რატომ არა IRC-ით ან ხალხის "ეშმაკის ეზოებში" ჩეთებით? 🙂
არა, ისევ იმავე ჭურჭელზე არ დავაბიჯებ. უკვე ერთმა უმადურმა მისცა სკაიპი და კისერზე დაჯდა.

თუ თქვენ გაქვთ ზოგადი კითხვები, რომლებზეც პასუხები სხვებს დაეხმარება - ჰკითხეთ. ერთად გავაკეთოთ კარგი საქმე. არანაირი ფარული მოლაპარაკება.

P.S. იმისათვის, რომ ადამიანებმა არ დაკარგონ ამ რესურსზე პასუხის გაცემის სურვილი, კარგი იქნება, მონიშნოთ გადაწყვეტილებები ან დააწკაპუნოთ ღილაკზე „მოწონება“ ყველაზე რელევანტურ პასუხებზე, თუნდაც მათ პირდაპირ არ დაეხმარონ.

მაქსიმ კრავჩენკო, FAQ შეუძლებელია, რადგან სუფთა 7.7 ბუნებაში არ არსებობს. არსებობს ტიპიური/ინდუსტრიული გადაწყვეტილებების მთელი პალიტრა, არსებობს ერთი და იგივე კონკრეტული კონფიგურაციის სხვადასხვა ვერსიები, მაგრამ ამ კომპლექტიდან არცერთი არ მოიცავს კომპანიების საჭიროებებს და ინსტალაციის შემდეგ გაყიდული 7.7 უკვე წლების განმავლობაში დასრულებულია. იმის გათვალისწინებით, რომ 7.7-ის მასობრივი გაყიდვები ათ წელზე მეტი ხნის წინ შეჩერდა, თქვენს კონკრეტულ მონაცემთა ბაზაში ტიპიური ფუნქციონალური არაფერი დარჩება.

ერთია, თუ აიღე სტანდარტული გადაცემის მექანიზმები, რაზეც ჩემს პასუხში დავწერე და გადარიცხავ, მიხვდები, რომ შენ ხარ პასუხისმგებელი ჯამებზე და ყველა შეუსაბამობას დებ "გოგონების" გამოსასწორებლად. და სულ სხვაა ფულის გამო სპეციალისტის მოზიდვა სამუშაოდ. თქვენ უნდა აღწეროთ გადასატანი ყველა საცნობარო წიგნი, გადასაცემი ინფორმაციის რაოდენობა (სტატიები, შტრიხკოდები, TIN და ა.შ.), საიდან მიიღოთ დაკარგული ინფორმაცია და ა.შ. მე არ ვარ მზად თქვენი პროექტის განსახორციელებლად ახლა. მე ვთავაზობ ამ ამოცანის რეგისტრაციას ფრილანსერ საიტებზე და მათ შორის ტენდერის ჩატარებას.

გადაცემის წესები 1s 8

მონაცემთა გადაცემა პროგრამებიდან "1C: Accounting 8 rev. 2.0" to "1C: Accounting 8 rev. 3.0"

შექმნილია ძირითადად მოწინავე კონფიგურაციისთვის 1C: Accounting 8 ed.2.0(შესაძლო სახელები ინტერნეტში BP 2.0 ან BP 8.2), როგორც კონფიგურაციაში გადატანის ორიგინალური წესების შემუშავების საფუძველი. 1C: Accounting 8 ed.3.0(შესაძლებელია სახელები ინტერნეტში BP 3.0 ან BP 8.3), რა თქმა უნდა, ის ასევე შესაფერისია სტანდარტულ კონფიგურაციებს შორის მონაცემების გადასატანად.

მიგრაციის შესაძლო სტრატეგიები 2.0-დან 3.0-მდე შეგიძლიათ იხილოთ აქ.

გადასვლა დან 1C: Accounting 8 ed.2.0ზე 1C: Accounting 8 ed.3.0რეკომენდირებულია შეასრულოს ახალი პერიოდის დასაწყისში (წელი, კვარტალი, თვე) წინა პერიოდის დაგეგმილი ოპერაციების დასრულების შემდეგ.

მონაცემთა გადაცემა ხორციელდება უნივერსალური დამუშავების გამოყენებით, რომელიც ატვირთავს მონაცემებს ინფობაზიდან 1C: Accounting 8 ed.2.0 XML ფაილზე. შედეგად მიღებული ფაილი აიტვირთება ინფობაზაში 1C: Accounting 8 ed.3.0მონაცემთა დატვირთვის უნივერსალური დამუშავების გამოყენებით.

მონაცემთა გადაცემისთვის საჭიროა შემდეგი ფაილები:

ACC20_30.xml - მონაცემთა კონვერტაციის წესები.

საინფორმაციო ბაზიდან BP 2.0 in BP 3.0გადაცემული:

ინფორმაცია საინფორმაციო ბაზის "1C: Accounting 8 rev. 2.0" საბუღალტრო ანგარიშებზე მიმდინარე ნაშთების შესახებ საინფორმაციო ბაზის კონვერტაციის თარიღისთვის.

საინფორმაციო ბაზის დოკუმენტები BP 2.0შერჩეული პერიოდისთვის

საჭირო საცნობარო ინფორმაცია საინფორმაციო ბაზიდან "1C: Accounting 8 ed.2.0"

- მონაცემები 1C საინფორმაციო ბაზიდან BP 8.2გადმოტვირთულია ცალკე ფაილი(მონაცემთა ფაილი);

- მიღებული ფაილი იტვირთება 1C ინფობაზაში BP 8.3.

ინსტალაცია არ არის საჭირო, რადგან გამოიყენება ტიპიურ კონფიგურაციებში ჩაშენებული დამუშავება 1C: Accounting 8 ed.2.0და 1C: Accounting 8 ed.3.0.

(სპეციალიზებული დამუშავების გამოყენების შესაძლებლობის შესახებ წაიკითხეთ ქვემოთ)

პროგრამაში 1C: Accounting 8 ed.2.0თქვენ უნდა გახსნათ დამუშავება (მენიუ: სერვისი — სხვა მონაცემთა გაცვლა), აირჩიეთ გადაცემის წესების შემცველი საქაღალდე (იხ. სურ. 1) და ჩატვირთეთ გაცვლის წესები. მე გირჩევთ ყოველ ჯერზე იძულებით ჩატვირთოთ გაცვლის წესები, მაშინაც კი, თუ ისინი ავტომატურად იტვირთება დამუშავების დაწყებისას. ამისათვის ან ხელახლა აირჩიეთ წესების ფაილი ან დააჭირეთ ღილაკს ხელახლა წაიკითხეთ გაცვლის წესები. თქვენ არ გჭირდებათ ტრანსპორტირების ყველა წესის ჩართვა. თქვენ უნდა გამოიყენოთ მხოლოდ ის, რაც აუცილებელია ნაშთების და (ან) დოკუმენტების გადაცემისთვის. ყველა დირექტორია გადადის ბმულებით, საჭიროებისამებრ, ე.ი. მხოლოდ ის, ვინც ჩართულია ნაშთებსა და დოკუმენტებში. ეს უზრუნველყოფს, რომ ახალ ინფობაზაში არ იყოს „ნაგავი“.

თუ დაგჭირდებათ ნაშთების განტვირთვა წლის ბოლოს, მაგალითად, 2014 წლის 31 დეკემბრის დღის ბოლოს, ე.ი. უფრო სწორია 2015 წლის დასაწყისში ვთქვათ, მაშინ განტვირთვის პერიოდი უნდა იყოს 01/01/2015 - XX.XX.XXXX. საბუთები ნაშთების შესატანად BP 3.0დათარიღებული იქნება 2014 წლის 31 დეკემბერი. 01.01.2015 წლიდან BP 3.0თქვენ უნდა შექმნათ დოკუმენტები, რომლებიც ასახავს მიმდინარე ოპერაციებს. თუ მხოლოდ ნარჩენები გჭირდებათ, მაშინ უნდა ჩართოთ განყოფილებიდან მონაცემების ატვირთვის წესები შემომავალი ნაშთები(იხ. სურ. 1). განყოფილებიდან მონაცემების ატვირთვის წესები Დოკუმენტებიამ შემთხვევაში ის უნდა იყოს გამორთული (იხ. ნახ. 3). განტვირთვის პერიოდი, მაგალითად, 01/01/2015 - 01/31/2015 ნიშნავს, რომ გადაიცემა 2015 წლის იანვრის საბუთები. განყოფილებიდან მონაცემების ატვირთვის წესები Დოკუმენტებიამ შემთხვევაში უნდა იყოს ჩართული.

ბრინჯი. ერთი . მონაცემთა ატვირთვის დამუშავება

უპირველეს ყოვლისა, ჩვენ გირჩევთ გადაიტანოთ ორგანიზაციის სააღრიცხვო პოლიტიკა (მინიშნება ორგანიზაციებიგადატანილი მითითებით). მონაცემთა გადაცემისას შეგიძლიათ დამატებით დააყენოთ პარამეტრები (იხ. ნახ. 2). ნაგულისხმევ მნიშვნელობებზე დასაბრუნებლად, თქვენ უნდა გადატვირთოთ გაცვლის წესები.

ნახ.2 პარამეტრების დაყენება

Პარამეტრი უგულებელყოთ დღგ-ის პარტიების რეესტრიადგენს პირველ რიგში შეივსება თუ არა BP 3.0ნაშთების შეყვანისას TMCმაგიდა მიღებული ინვოისების მონაცემები. ეს ასევე გავლენას ახდენს იმაზე, თუ როგორ შეივსება ქვეკონტო. პარტიები: მიხედვით BOOან რეესტრის დარჩენილი ნაწილით შეძენილ აქტივებზე დღგ.

პარამეტრის დაყენება საშუალებას გაძლევთ მართოთ ნაშთების გადმოტვირთვა ორგანიზაციებისთვის, რომლებიც იყენებენ USN. როდესაც ბუღალტერია მიმდინარეობს, როდესაც რეესტრის მონაცემები არ ემთხვევა გამარტივებული საგადასახადო სისტემის ხარჯებიბუღალტრული აღრიცხვის რეესტრისთვის შეიძლება უფრო სასარგებლო იყოს ნაშთების განტვირთვა მხოლოდ სააღრიცხვო მონაცემების მიხედვით, რეგისტრის გარეშე. USN, რომელსაც შეუძლია ბევრი შეცდომის დამატება. ამ შემთხვევაში, გახსნის ნაშთების შესატან დოკუმენტებში BP 3.0რეკვიზიტები ასახვა USN-შიდა მოხმარების სტატუსიივსება ნაგულისხმევი მნიშვნელობებით.

პარამეტრის დაყენებისას დიახდოკუმენტებთან პარალელურად გადაიცემა ამ დოკუმენტებთან დაკავშირებული რეესტრის ნაკრები. წინააღმდეგ შემთხვევაში, დოკუმენტების შინაარსი გადადის, ხოლო გადაადგილების მისაღებად დოკუმენტები უნდა განთავსდეს მონაცემთა ბაზაში. BP 3.0გადაცემის შემდეგ. უნდა გვესმოდეს, რომ არა ყველა დოკუმენტის გადაადგილებისთვის, რომელიც არსებობს BP 8.3, არის მატჩები BP 8.2. ამიტომ, მაშინაც კი, თუ თქვენ აირჩევთ დოკუმენტების გადატანას მოძრაობებით, შეიძლება დაგჭირდეთ ზოგიერთი ტიპის დოკუმენტის განთავსება, რათა შეიქმნას ყველა საჭირო წიგნის ნაკრები.

ნახ.3 დოკუმენტების სია, რომლებიც გადაეცემა BP 3.0-ს

გადასაცემი ინფორმაციის დირექტორიებისა და რეგისტრების სია წარმოდგენილია ნახ.4-ში. თუ ვინმე დაინტერესებულია ამ სიის გაფართოებით, გთხოვთ დაუკავშირდეთ ავტორს. არსებობს მრავალი დირექტორიისთვის ობიექტების გადაცემის წესები. ეს გასაგებია, რადგან მრავალფეროვანი დირექტორია წარმოდგენილია ბევრ დოკუმენტში და, შესაბამისად, გადმოწერილია ბმულების საშუალებით. მათგან განტვირთვის წესების დადგენა არ არის რთული, ამის გაკეთება თავადაც შეგიძლიათ. დირექტორიას გადმოტვირთვის წესი საჭიროა, თუ არსებობს მთელი კატალოგის გადაცემის სურვილი და არა მხოლოდ ბმულებით.

ბრინჯი. 4 გადასაცემი ინფორმაციის დირექტორიებისა და რეგისტრების სია

76.AB და 76.BA ანგარიშებზე ნაშთების გადარიცხვის თავისებურებები

როცა დაყენებულია დიახპარამეტრი სწორი რეგრადირება კონტრაგენტებთან ანგარიშსწორებისთვისბუღალტრული შეცდომების გამოსწორება შესაძლებელია. რა არის მიმართული, ნათლად ჩანს ნახ.5.1: კონტრაგენტისთვის ნაშთი არის ნული, მაგრამ მეორე ქვეკონტოსთვის თანხები არ არის ნული. ასეთი ნაშთები არ იქნება გადატანილი.

ნახ.5.1 ნარჩენებში რეგრადირება

თუ დაყენებულია დიახპარამეტრი შეტყობინებები დეტალურად, მაშინ განტვირთვისას გამოჩნდება განმარტებითი შეტყობინებები (იხ. სურ.5.2).

ნახ.5.2 შეტყობინებები ნარჩენებში რეგრადაციის დროს

საქონლისა და მასალების სააღრიცხვო ანგარიშებზე ნაშთების გადაცემის მახასიათებლები

შეცდომების გამოსწორების ალგორითმი, როგორიცაა ნაშთების ხელახალი დახარისხება TMC. ეს ალგორითმი მუშაობს პარამეტრის დაყენებისას საქონლისა და მასალების ნარჩენების რეგრადაციის დაფიქსირებამნიშვნელობაში დიახ. მაგალითი ნაჩვენებია სურათზე 5.3. 10.03 ანგარიშის აღრიცხვა ტარდება ნომენკლატურის, საწყობებისა და პარტიების კონტექსტში. დანარჩენი ნომენკლატურა ბენზინი AI-92ზე საწყობი №4არის ნული, მაგრამ თუ ნაშთებს სერიებით გააფართოვებთ, ბევრი იქნება. ნაშთების ალგებრული ჯამი პარტიებზე ნულის ტოლია, ეს არის დახარისხება. ასეთი ნარჩენები არ უნდა გადავიდეს, რადგან ეს აშკარა შეცდომაა. პარამეტრის დაყენებისას ისინი არ გადაიცემა.

ნახ.5.3 ნარჩენებში რეგრადირება TMCწყაროს მონაცემთა ბაზაში BP 2.0

დანარჩენებთან უარესი მდგომარეობაა საწყობი №6. ნაშთი არ არის ნულოვანი, ამიტომ კურორტის კორექტირების ალგორითმი არ იმუშავებს, ნაშთი გადაიცემა. და როგორ გადაიცემა ისინი, განვიხილოთ. ჯამი -155,29 არ მოხვდება გადაცემაში, რადგან ასეთი ნაშთები BP 3.0შეუძლებელია შეყვანა, შეუძლებელია ნულოვანი რაოდენობის და არანულოვანი თანხის შეტანა, ნაშთების შეყვანის დოკუმენტი არ განთავსდება, ამიტომ არ ვტვირთავთ. შედეგად, ში BP 3.0დარჩენილი ორი ჯამი დაეცემა (იხ. სურ. 5.4). დანარჩენი თითქოს შეცდომით გადაიტანა. სინამდვილეში, რა თქმა უნდა, აქ არ არის გადარიცხვის შეცდომა, მაგრამ არის ბუღალტრული შეცდომები.

ნახ.5.4 გადატანის შედეგი BP 3.0

გამოიყენოს თუ არა აღწერილი რეგრადირების კორექტირების ალგორითმი, მომხმარებლის გადასაწყვეტია. თქვენ უბრალოდ უნდა გახსოვდეთ, რომ ნულოვანი რაოდენობის ნაშთები არასოდეს გადადის. ავტორის თქმით, ეს ყველაზე სწორი საქციელია, ყოველ შემთხვევაში საშუალებას გაძლევთ შეიყვანოთ ბალანსის შეყვანის დოკუმენტი და დაიწყოთ შერიგება. შორის ნაშთებს შორის შეუსაბამობის პოზიციების უფრო სწრაფი ძიებისთვის BP 2.0და BP 3.0გადარიცხვის შედეგებიდან გამომდინარე, შეიძლება რეკომენდებული იყოს წყაროში ასეთი პრობლემური პოზიციების შერჩევა ბალანსის შესაბამისად დაყენებით. იხილეთ სურათი 5.5, თუ როგორ უნდა გააკეთოთ ეს.

სურ.5.5 პოზიციების შერჩევა ნულოვანი რაოდენობით

განტვირთვის დასრულების შემდეგთქვენ უნდა გაუშვათ პროგრამა 1C: Accounting 8 ed.3.0. ჩატვირთვა როგორც თავდაპირველად, ასევე მონაცემთა განმეორებითი გადაცემის ან დამატებითი გადაცემის დროს უნდა განხორციელდეს ტიპის დამუშავების გამოყენებით მონაცემთა უნივერსალური გაცვლა XML ფორმატში(იხ. სურ. 8.1). მისი გახსნა შეგიძლიათ მენიუდან: ყველა ფუნქცია - დამუშავება - მონაცემთა უნივერსალური გაცვლა XML ფორმატში.თუ მენიუს ელემენტი არ არის ყველა ფუნქცია, მაშინ თქვენ უნდა წახვიდეთ სერვისი -პარამეტრებიდა შეამოწმეთ ყუთი ბრძანების ჩვენება ყველა ფუნქცია.

მონაცემთა 1C: Accounting 8 edition 3.0 მონაცემთა ბაზაში ჩატვირთვის შემდეგ, აუცილებელია შეასრულოთ დოკუმენტები საწყისი ნაშთების შესაყვანად, რათა მიიღოთ ყველა საჭირო მოძრაობა. შეგიძლიათ გამოიყენოთ დამუშავება დოკუმენტების ჯგუფური ხელახალი გამოქვეყნება(იხ. სურ.8.2) ან განათავსეთ დოკუმენტები ჟურნალში (მენიუ: ყველა ფუნქცია - დოკუმენტები - ნაშთების შეყვანა). თუ დოკუმენტები გადაირიცხა მოძრაობის გარეშე (ვარიანტი დოკუმენტის მოძრაობების ატვირთვადააყენეთ მნიშვნელობა არა), შემდეგ რეესტრებში განცხადებებისა და ჩანაწერების მისაღებად აუცილებელია საბუთების განთავსებაც.

მონაცემთა კონვერტაციის ტექნიკა.

საჭიროების შემთხვევაში, კონვერტაცია შეიძლება განხორციელდეს რამდენიმე ეტაპად, მაგალითად, ჯერ დირექტორიები, შემდეგ დოკუმენტები ნაშთების შესვლისთვის, შემდეგ სხვა დოკუმენტები. შესაძლებელია ინფორმაციის ხელახალი გადაცემა. გადარიცხვებს შორის არ უნდა შეიტანოთ შესწორებები გადაცემულ მონაცემებში 1C: Accounting 8 ed.3.0, წინააღმდეგ შემთხვევაში ეს შესწორებები შეიძლება დაიკარგოს განმეორებითი გადარიცხვის დროს.

ნაშთები გადაირიცხება დოკუმენტებით გახსნის ნაშთების შეყვანა.

დამატებითი დეტალები ნაშთების შეყვანის მეთოდოლოგიის შესახებ შეგიძლიათ იხილოთ სტატიაში ITS ვებსაიტზე 1C.

Მნიშვნელოვანი! გახსნის ნაშთების შეტანამდე უნდა იყოს მითითებული სააღრიცხვო პოლიტიკის პარამეტრები. ორგანიზაციის სააღრიცხვო პოლიტიკის პარამეტრები იკითხება ნაშთების შეტანის შემდეგ თარიღში. მაგალითად, თუ ნაშთის შეტანის თარიღი არის 31/12/2013, მაშინ მხედველობაში მიიღება 01/01/2014 თარიღით დადგენილი სააღრიცხვო პოლიტიკის პარამეტრები. ეს საშუალებას გაძლევთ გაითვალისწინოთ მიმდინარე სააღრიცხვო პოლიტიკის პარამეტრები ( მაგალითად: თუ 2013 წელს ორგანიზაციამ გამოიყენა გამარტივებული საგადასახადო სისტემა და 2014 წლიდან გადავიდა საერთო სისტემაზე - მაშინ 2013 წლის 31 დეკემბრის მდგომარეობით ნაშთების შეყვანისას გათვალისწინებული იქნება 2014 წლის სააღრიცხვო პოლიტიკის პარამეტრები). სწორედ ამიტომ, როგორც ზემოთ აღვნიშნეთ, უპირველეს ყოვლისა გირჩევთ ორგანიზაციის სააღრიცხვო პოლიტიკის გადაცემას.

Მნიშვნელოვანი! თუ გადაწყვეტთ დაიწყოთ მუშაობა 1C: Accounting 8 ed.3.0ნარჩენების იქ გადატანამდე აუცილებელია სამუშაოს დაწყებამდე 1C: Accounting 8 ed.3.0გადაცემის დირექტორიები. წინააღმდეგ შემთხვევაში, ნარჩენების არაცარიელ მონაცემთა ბაზაში გადატანისას, შესაძლებელია შეცდომები.

Მნიშვნელოვანი:არსებობს სინქრონიზაციის პრობლემის გადაჭრის შესაძლებლობა არა ცარიელ მონაცემთა ბაზაში ჩატვირთვისას - შესატყვისი ობიექტები.

როგორ ვიმუშაოთ მონაცემთა გადაცემის სპეციალიზებულ დამუშავებასთან.

დამუშავება გამოიყენება მხოლოდ რეჟიმში ფაილი. დამუშავება მონაცემთა გადაცემა_from_BP20_to_BP30.epfუნდა გაშვებული იყოს ინფო ბაზაში, სადაც ხდება მონაცემების გადაცემა, ე.ი. in 1C საწარმოთა აღრიცხვა rev.3.0.პირველ ფანჯარაში (იხ. სურ. 9) უნდა მიუთითოთ 1C:Enterprise პლატფორმაზე ინფორმაციის ბაზიდან მონაცემების ჩატვირთვის ვარიანტი:

ჩატვირთეთ მონაცემები პირდაპირ საინფორმაციო ბაზიდან

ნახ.9 მონაცემთა გადაცემის დამუშავების დაწყების ფანჯარა

შემდეგ ფანჯარაში (იხ. სურ. 10), თქვენ უნდა დააკონფიგურიროთ ტრანსფერი:

აირჩიეთ ინფობაზა სიიდან (სია იგივეა, რაც აპლიკაციის გაშვებისას 1C საწარმო).

მიუთითეთ მომხმარებლის სახელი და პაროლი

მიუთითეთ რა ინფორმაცია გადაიტანოთ

გარდა ამისა, შეგიძლიათ გადაამოწმოთ წყაროში არსებული მონაცემები გადაცემის სისწორისთვის

ლექსიკონების მიგრაციისას, მონაცემები გადაიცემა შერჩეული ინფობაზის ლექსიკონებიდან, რომლის ატვირთვის წესები არსებობს. დირექტორიები ამ შემთხვევაში მთლიანად გადადის. თუ ჩამრთველი არ არის მონიშნული, მაგრამ არჩეულია გადაცემის სხვა ვარიანტი, მაშინ დირექტორიებიც გადაიცემა, მაგრამ მხოლოდ იმ მოცულობით, რამდენადაც ეს აუცილებელია გადაცემული ტრანზაქციებისა და დოკუმენტების მონაცემების შესავსებად. მონაცემთა გადაცემისას შეგიძლიათ გადაიტანოთ დირექტორიები, დოკუმენტები და ნაშთები წლის დასაწყისში. გადარიცხვის ვარიანტების არჩევა შესაძლებელია ნებისმიერ კომბინაციაში. ნაშთების გადარიცხვისას მონაცემები არჩეული წლის 1 იანვრის მდგომარეობით სააღრიცხვო ანგარიშებზე ნაშთების შესახებ გადაირიცხება 1-ლ ნახაზზე მითითებული წესების მიხედვით. 1C: ბუღალტრული აღრიცხვა 8, დოკუმენტები "საწყისი ნაშთების შეყვანა" შეიქმნება არჩეულის წინა წლის 31 დეკემბერს.



სურ.10 გადაცემის პარამეტრების ფანჯარა

თუ არჩეულია მონაცემთა გადამოწმების ვარიანტი, მაშინ ასეთი გადამოწმება განხორციელდება ჩატვირთვამდე და გადამოწმების შედეგი გამოჩნდება ეკრანზე (იხ. სურ. 11). თუ შემოწმების პროცესში აღმოჩენილია შეცდომები, მიგრაციის პროცესი შეჩერდება შეცდომების გამოსწორების მიზნით. თუ შეცდომების მიუხედავად მონაცემების ატვირთვა და ჩამოტვირთვა გსურთ, მოხსენით მონიშვნა შეამოწმეთ მონაცემები ჩამოტვირთვამდეან დააწკაპუნეთ გაგრძელება. შემოწმების წესების სია მუდმივად განახლდება.



ნახ.11 მონაცემთა ვალიდაციის შედეგი ატვირთვამდე

მონაცემთა წყაროდან მიმღებზე გადატანის პროცესში ეკრანზე განახლდება სურათი, რომელიც მიუთითებს მიმდინარე სტადიაზე: ინფობაზასთან დაკავშირება, მონაცემების ატვირთვა, მონაცემების ჩატვირთვა და ა.შ. გარდა ამისა, უფრო დეტალური ინფორმაცია ნაჩვენებია ქვემოთ, როგორც ხაზი, მაგალითად, "მონაცემების ატვირთვა: დოკუმენტები (3/3)". მონაცემთა ატვირთვის დასრულების შემდეგ იწყება ატვირთული დოკუმენტების განთავსება და შემდეგ ატვირთული მონაცემების შემოწმება. თუ დოკუმენტის გამოქვეყნების ან მონაცემთა გადამოწმების დროს მოხდა შეცდომები, ამის შესახებ შეტყობინებები გამოჩნდება შეტყობინების ფანჯარაში ბოლოს. შეცდომის შეტყობინებები ასევე შეგიძლიათ იხილოთ ცალკეულ ფანჯარაში ჰიპერბმულზე დაწკაპუნებით შეცდომის ინფორმაცია(იხ. სურ.12).



სურ.12 მონაცემთა გადაცემის პროგრესის ჩვენება

ცხრილის ფრაგმენტი, რომელიც შეიცავს შეცდომის ჩანაწერებს, ნაჩვენებია ნახ.13-ზე. პირველ რიგში, ცხრილი აჩვენებს შეცდომის შეტყობინებებს, რომლებიც წარმოიშვა დოკუმენტების გამოქვეყნებისას, შემდეგ შეცდომებს გადამოწმების დროს. ატვირთული მონაცემების შემოწმება შედგება წყაროსა და დანიშნულების ადგილზე ნაშთების შეყვანის თარიღისთვის წარმოქმნილი ბალანსების შედარებაში. რომელიმე ანგარიშზე ბალანსის შეუსაბამობის შემთხვევაში, ამის შესახებ იქმნება ჩანაწერი. შეცდომების ცხრილში ჩანაწერზე ორჯერ დაწკაპუნებით, შეგიძლიათ გახსნათ პრობლემური დოკუმენტი შესწორებისა და ხელით შესასრულებლად. იგივე შეიძლება გაკეთდეს შეტყობინებების ფანჯარაში.



სურ.13 ცხრილის ფრაგმენტი, რომელიც შეიცავს შეცდომის ჩანაწერებს

დანიშნულების მონაცემთა ბაზაში შესწორებების გაკეთების შემდეგ აზრი არ აქვს იგივე ინფორმაციის წყაროს ბაზიდან ხელახლა გადატანას, რადგან მეორე გადაცემის დროს ეს მონაცემები ისევ შეცდომებით ჩაიწერება. ამიტომ შეეცადეთ შეასწოროთ შესწორებები წყაროში და არა დანიშნულების ადგილზე, ან მოერიდეთ იგივე ინფორმაციის გადაცემას. მაგალითად, საწყისი ნაშთების გადარიცხვისა და მიმღებში საწყისი ნაშთების შეყვანის ყველა დოკუმენტის შესწორების შემდეგ, არ დააყენოთ დროშა შემდგომი გადარიცხვებისთვის. ბალანსი წლის დასაწყისში.

განახლებები უფასოა შეძენიდან 6 თვის განმავლობაში. უფასო განახლების პერიოდის ბოლოს, შეგიძლიათ მიიღოთ განახლებები ფასიან საფუძველზე (იხ. ღირებულება ქვემოთ). ამავდროულად, თუ თქვენ იყიდეთ რამდენიმე პროგრამული პროდუქტი, კომპლექტების შემადგენლობაში ან ცალკე, მაშინ გაქვთ უფლება, გაითვალისწინოთ ფასდაკლება. შეგიძლიათ მეტი გაიგოთ ფასდაკლების სისტემის შესახებ.

ტექნოლოგიით შექმნილი წესები მონაცემთა კონვერტაციები: მარტივი რედაქტირება.
სრულად გახსნილია, არ არსებობს ლიცენზირების შეზღუდვები, გარდა რეპლიკაციის აკრძალვისა.

ფაილი TransferDemo20_30.xml არის გადმოტვირთვა მონაცემთა ბაზიდან, რომელიც მიღებულია BP 2.0 დემო მონაცემთა ბაზის 1C-ის მიერ განაწილებული BP 3.0 მონაცემთა ბაზაში გადატანით. შექმენით ცარიელი BP 3.0.44.94 მონაცემთა ბაზა, შეგიძლიათ გამოიყენოთ 1C შაბლონი ან გამოიყენოთ 1Cv8.cf კონფიგურაციის ფაილი. დააყენეთ ბუღალტრული აღრიცხვის პარამეტრებში ანგარიშების გეგმის დაყენებამარაგების აღრიცხვა საწყობებისა და პარტიების მიხედვით. ჩამოტვირთეთ დემო ფაილი TransferDemo20_30.xml დამუშავებით მონაცემთა უნივერსალური გაცვლა XML ფორმატში. დემო მონაცემთა ბაზაში ნაჩვენებია ნაშთების გადარიცხვა 01/01/2009 მდგომარეობით და საბუთები 01/01/2009-დან 31/12/2009 წლამდე პერიოდისთვის.

წესები რეგულარულად ახლდება ახალი გამოშვებებისთვის, შესაფერისია BP 2.0.64.23 და შემდეგ გამოშვებებისთვის. არ არის საჭირო პორტირების წესების სასურველი ვერსიის ძიება და არჩევა, ისინი შესაფერისია ნებისმიერი SOURCE გამოშვებისთვის მითითებულ დიაპაზონში. თუ თქვენ გჭირდებათ წესები ადრინდელი გამოშვებისთვის, გთხოვთ, დაუკავშირდეთ ავტორს. RECEIVER გამოშვება უნდა იყოს უბრალოდ ასეროგორც წესებში.

29.08.2018 ნაშთების გადმოტვირთვა განყოფილების ქვეშ გამოყოფილია ცალკე წესით კრედიტები და სესხები(ანგარიშები 66, 67), ადრე იყო ნაწილი სხვა საბუღალტრო ანგარიშები

08/20/2018 განახლება 2.0.66.59 და 3.0.64.48

06/03/2018 დამატებულია საბუთების გადაცემა ხელფასის ასახვა რეგულირებად აღრიცხვაში

18.05.2018 განახლება 2.0.66.54 და 3.0.61.37

23.02.2018 განახლება 2.0.66.48 და 3.0.58.41

01/18/2018 განახლება 2.0.66.46 და 3.0.57.17

12/22/2017 განახლება 2.0.66.42 და 3.0.56.22

11/03/2017 განახლება 2.0.66.37 და 3.0.53.38

26.09.2017 განახლება 2.0.66.37 და 3.0.52.35

06/14/2017 განახლება 2.0.66.29 და 3.0.50.18

05/05/2017 განახლება 2.0.66.25 და 3.0.49.27

04/04/2017 - დაემატა მიღებული ინვოისების შექმნა, როდესაც BP 2.0 აქვს მხოლოდ ნომერი და თარიღი. საჭიროა პარამეტრის დაყენება შეასრულეთ ინვოისის კონვერტაცია(შექმენით ახალი, თუ წყარო შეიცავს მხოლოდ ნომერს და თარიღს)

02/06/2017 განახლება BP 3.0.47.23-ზე

26.01.2017 დამატებულია საბუთების გადაცემა დღგ-ის დარიცხვის ასახვადა დღგ-ის გამოქვითვის ასახვა

01/11/2017 განახლებულია BP 2.0.66.8 და BP 3.0.46.16. რეგისტრაცია გადარიცხვა გამორიცხულია დღგ OSiNMA-ს მიხედვით.ადრინდელ ვერსიებში, სადაც ის არის კონფიგურაციაში, არ გადაიცემა.

14.12.2016 განახლება BP 3.0.44.203-ზე

12/07/2016 დამატებულია საბუთების გადაცემა ვალის კორექტირება

12/01/2016 პარამეტრი დამატებულია არ გაითვალისწინოთ რეესტრის ხარჯები გამარტივებული საგადასახადო სისტემისთვის, რომელიც საშუალებას გაძლევთ მართოთ ნაშთების განტვირთვა ორგანიზაციებისთვის გამარტივებული საგადასახადო სისტემის გამოყენებით

21/11/2016 დირექტორიას ჩამოტვირთვა დამატებულია მომხმარებლებიცალკე წესი მიმღებში IS მომხმარებლების შექმნით (დეტალები აქ). დამატებულია ნაშთების გადარიცხვა RS-ის მიერ ორგანიზაციის თანამშრომლები(პერსონალის მონაცემები). 76.AB და 76.BA ანგარიშებზე ნაშთების გადარიცხვისას შესაძლებელია მეორე ქვეკონტოს მიხედვით დახარისხების შემოწმება და კორექტირება.

11/08/2016 საბუთების სია გაფართოვდა.

28.10.2016 დამატებულია საბუთების გადაცემა. დამატებულია გადაცემის დემონსტრირება, ეს არის BP 2.0 დემო მონაცემთა ბაზის გადაცემის შედეგი.

26.10.2016 დაფიქსირდა ცარიელი საბუთების შექმნა ნაშთების შესატანად, როდესაც არის ანგარიშების ნაშთები 10.07.

09/09/2016 განახლება BP 3.0.44.102-ზე

23/03/2016 მიღებული ინვოისების მონაცემების გაუმჯობესებული გადაცემა (ინვენტარის ნაშთების გადაცემისას)

01/11/2016 დამატებულია პირთა საკონტაქტო ინფორმაციის გადაცემა, მოქალაქეობა, პასპორტის მონაცემები, ინვალიდობის ინფორმაცია, პირთა სტატუსები. დამატებულია საბანკო ანგარიშებისა და ნივთების აღრიცხვის ანგარიშების გადარიცხვის წესები.

12/23/2015 განახლება BP 3.0.43.29-ზე. დამატებულია კონტრაგენტებისა და მათი საკონტაქტო პირების საკონტაქტო ინფორმაციის გადაცემა.

14.12.2015 შეიქმნა წესები BP 3.0.42-ისთვის

პაკეტში შედის: გადარიცხვის წესები "ACC20_30"და დამუშავება მონაცემთა გადაცემა_BP20_-დან_BP30-მდე. თუ თქვენს ორგანიზაციას არ ჰყავს სრულ განაკვეთზე პროგრამისტი სამუშაოდ, ჩვენ მზად ვართ შემოგთავაზოთ ჩვენი სპეციალისტის მომსახურება (პროგრამისტი თქვენს კომპიუტერს დაუკავშირდება ინტერნეტის საშუალებით, სპეციალური პროგრამადისტანციური მუშაობისთვის და შეასრულეთ საჭირო სამუშაოები). თუ შესაძლებელია სამუშაო ბაზის უზრუნველყოფა "1C: Accounting 8 rev.2.0"ჩვენ შეგვიძლია თავად გადავიტანოთ მონაცემები და გადავიტანოთ ფაილი“ 1C: Accounting 8 ed.3.0» გადატანილი ნაშთებით. ამ სერვისის ღირებულება არ შედის პაკეტის მთლიან ღირებულებაში.

Მნიშვნელოვანი. ყველა დოკუმენტი არ არის მიგრირებული (ძველ BP 2.0 გამოშვებებთან თავსებადობისთვის). ყიდვამდე ყურადღებით წაიკითხეთ ნახ.3-ის სია.

მონაცემთა გადაცემა პროგრამებიდან "1C: Accounting 7.7" და "1C: USN 7.7" to "1C: Accounting 8"

რამდენიმე სიტყვა იმის შესახებ, თუ როგორ ხდება მონაცემების გადაცემა ტიპიური კონფიგურაციიდან " Აღრიცხვა", გამოცემა 4.5 1C-სთვის: Enterprise 7.7 ან კონფიგურაცია "" (შემდგომში მოხსენიებული, როგორც წყაროს კონფიგურაციები) სტანდარტულ კონფიგურაციაში " საწარმოს აღრიცხვა”, გამოცემა 3.0 1C-სთვის: Enterprise 8 (ვერსია 3.0.52), შემდგომში მოხსენიებული, როგორც „დანიშნულების კონფიგურაცია“.

ᲛᲜᲘᲨᲕᲜᲔᲚᲝᲕᲐᲜᲘ! მონაცემთა გადაცემა შესაძლებელია კონფიგურაციიდან Აღრიცხვაგამოცემა 4.5 1C: Enterprise 7.7 ვერსია 7.70.569 და უფრო გვიან ან კონფიგურაციიდან " გამარტივებული საგადასახადო სისტემა, რედ. 1.3» ვერსიები 7.70.219 და უფრო მაღალი.

რეკომენდებულია წყაროს კონფიგურაციიდან დანიშნულების კონფიგურაციაზე გადასვლა ახალი პერიოდის დასაწყისში (წელი, კვარტალი, თვე) წინა პერიოდის დაგეგმილი ოპერაციების დასრულების შემდეგ.

მონაცემთა გადაცემა ხორციელდება სპეციალიზებული დამუშავების გამოყენებით, რომელიც ატვირთავს მონაცემებს წყაროს კონფიგურაციის საინფორმაციო ბაზიდან ფაილში XML ფორმატში. შედეგად მიღებული ფაილი აიტვირთება მიმღების კონფიგურაციის ინფობაზაში მონაცემთა ატვირთვის უნივერსალური დამუშავების გამოყენებით.

ACC_ACC8 .ert - კონფიგურაციიდან გარე ფაილზე მონაცემების ატვირთვის გარე დამუშავება " ბუღალტერია, რევ.4.5»;

USN_ACC8 .ert - კონფიგურაციიდან გარე ფაილში მონაცემების ატვირთვის გარე დამუშავება. გამარტივებული საგადასახადო სისტემა, რედ. 1.3»;

ACC_ACC8 .xml - მონაცემთა კონვერტაციის წესები.

USN_ACC8 .xml - მონაცემთა კონვერტაციის წესები.

შემდეგი გადატანილია წყაროს კონფიგურაციის საინფორმაციო ბაზიდან დანიშნულების კონფიგურაციაში:

— ინფორმაცია წყაროს კონფიგურაციის საინფორმაციო ბაზის სააღრიცხვო ანგარიშებზე მიმდინარე ნაშთების შესახებ ინფორმაციის ბაზის კონვერტაციის თარიღისთვის;

— მიმდინარე დოკუმენტები, რომელთა თარიღი აღემატება საინფორმაციო ბაზის კონვერტაციის თარიღს.

კონვერტაცია ხორციელდება ორ ეტაპად:

— წყაროს კონფიგურაციის საინფორმაციო ბაზის მონაცემები აიტვირთება ცალკე ფაილში (მონაცემთა ფაილი);

— მიღებული ფაილი იტვირთება მიმღების კონფიგურაციის ინფო ბაზაში.

გამოიყენეთ setup.exe ინსტალერი მონაცემთა მიგრაციის დამუშავების დასაყენებლად. პროგრამის დაწყების შემდეგ (თუ 1C: Enterprise ინფობაზების რაოდენობა დიდია, გარკვეული პერიოდის შემდეგ) გამოჩნდება დიალოგური ფანჯარა, რომელშიც უნდა მონიშნოთ ის ინფობაზები, სადაც დაინსტალირებული იქნება მონაცემთა გადაცემის დამუშავება. ფანჯარა გამოიყურება როგორც ნახ.1. თუ ინფობაზების რაოდენობა შვიდზე მეტია, გამოიყენეთ ზემოთ და ქვემოთ ღილაკები ნავიგაციისთვის. თუ არჩეულია რამდენიმე ინფობაზა, მაშინ "ბილიკის" ხაზში ნაჩვენებია მხოლოდ ბოლო არჩეული ინფობაზის მდებარეობა. ეს ინფორმაცია დამხმარე ხასიათს ატარებს და გამოიყენება სურვილისამებრ მომხმარებლის მიერ ინსტალაციის პროგრამის შედეგზე დამატებითი კონტროლისთვის, დიდ ყურადღებას ნუ მიაქცევთ, პროგრამა თავად განსაზღვრავს სად არის დაინსტალირებული თქვენ მიერ არჩეული ინფობაზები.



სურ.1 საინფორმაციო ბაზის შერჩევის ფანჯარა ინსტალაციის დროს

გარდა ამისა, შეგიძლიათ მიუთითოთ საქაღალდე, სადაც ასევე დაინსტალირდება მონაცემთა გადაცემის დამუშავება, ამისთვის უნდა გამოიყენოთ საქაღალდის შერჩევის ფანჯარა (ღილაკზე სამი წერტილის დაჭერით). არჩეული საქაღალდის სრული გზა აისახება შერჩევის ზოლში. ღილაკზე „ინსტალაციის“ დაჭერის შემდეგ, საჭირო ფაილები დაინსტალირდება შერჩეულ ინფობაზებში და (ან) არჩეულ საქაღალდეში. დასრულების შემდეგ შეგიძლიათ დააჭიროთ ღილაკს "დეტალები" და ნახოთ დეტალური ინსტალაციის ჟურნალი, რომელი ფაილები და რომელი საქაღალდეები დაიწერა. შედეგად, შერჩეულ საქაღალდეში უნდა გამოჩნდეს დაახლოებით შემდეგი სურათი, იხილეთ ნახ.2.



ნახ.2 არჩეულ საქაღალდეში დაინსტალირებული ფაილები

ქვედირექტორიამდე ExtFormsდადგენილია დამუშავებისა და გადაცემის წესები. გთხოვთ გაითვალისწინოთ ატვირთვის დამუშავება ACC_ACC8.ertდა მონაცემთა ატვირთვის წესები ცვლის ზოგად დამუშავებას და წესებს. თუ გსურთ შეინარჩუნოთ გადასვლის ტიპიური მექანიზმი, დააინსტალირეთ ახალი დამუშავება ცალკე დირექტორიაში და არა ინფო ბაზაში.

ინსტალაციის პროცესი უფრო დეტალურად არის აღწერილი ანგარიშის დაყენების მაგალითის გამოყენებით " აღრიცხვის ექსპრეს შემოწმება კონფიგურაციისთვის "1C: ბუღალტერია 7.7«.

პროგრამაში" 1C: ბუღალტერია 7.7» თქვენ უნდა გახსნათ დამუშავება დამატებითი ვარიანტებიდან « გადასვლა 1C-ზე: ბუღალტერია 8, რედ. 3.0«, აირჩიეთ გადაცემის წესების შემცველი საქაღალდე (იხ. სურ. 3) და გადმოწერეთ გაცვლის წესები. თქვენ არ გჭირდებათ ტრანსპორტირების ყველა წესის ჩართვა. თქვენ უნდა გამოიყენოთ მხოლოდ ის, რაც აუცილებელია, მაგალითად, ნაშთების, ან ნაშთების და დოკუმენტების გადასაცემად. მაგალითად, ლექსიკონების ჯგუფში არ შეიძლება შეიტანოთ ერთი წესი, რადგან ყველა ლექსიკონი გადადის ბმულებით, საჭიროებისამებრ, ე.ი. მხოლოდ ის, ვინც ჩართულია ან ნაშთებში ან დოკუმენტებში. ეს უზრუნველყოფს, რომ ახალ ინფობაზაში არ იყოს „ნაგავი“. თქვენ ასევე არ გჭირდებათ ყველა დოკუმენტის შეტანა. მაგალითად, თუ თქვენს მონაცემთა ბაზაში არ არის დოკუმენტები, ან არ გსურთ მათი გადაცემა, არ გჭირდებათ ამ წესის ჩართვა.



ნახ.3. მონაცემთა ატვირთვის დამუშავება

მე გირჩევთ დააყენოთ მონაცემთა ფაილის სახელი "C:\v77_v8\Exp77_80.xml", ეს საქაღალდე ხშირად გამოიყენება ნაგულისხმევად პროგრამაში " 1C: ბუღალტერია 8» პლატფორმაზე პროგრამებიდან მონაცემების ჩამოტვირთვისას « 1C: საწარმო 7.7". საჭიროების შემთხვევაში დააყენეთ პარამეტრები გვერდზე. Პარამეტრები«.

კონფიგურაციის მონაცემების გადმოტვირთვის პროცესში " ბუღალტერია 7.7» შეიძლება მოხდეს სხვადასხვა შეცდომები. აქ წარმოდგენილი მიგრაციის წესები განსხვავდება ტიპიურისგან იმით, რომ მონაცემთა გადმოტვირთვის ეტაპზე ხდება ტიპიური შეცდომების ძიება. განვიხილოთ ისინი, რომელთა შესახებაც ნაჩვენებია შეტყობინებები.

საქონლისა და მასალის ნულოვანი რაოდენობა და არანულოვანი რაოდენობა. დანიშნულების კონფიგურაციაში ბალანსის შეყვანა ისე, რომ მასალის რაოდენობა იყოს ნულის ტოლი, ხოლო მასალის ხარჯთაღრიცხვა არ იყოს ნულის ტოლი, შეუძლებელია და აზრი არ აქვს, რადგან ეს შეცდომაა. ამიტომ, ნაშთების გადარიცხვისას, ასეთი ერთეულები (ნულოვანი რაოდენობით) არ იქნება ხელმისაწვდომი ბალანსის შესატან დოკუმენტებში. მაშასადამე, თუ მონაცემების გადაცემამდე შეცდომები არ გამოსწორდება, მაშინ ნაშთების გადარიცხვისას მონაცემთა წყაროსა და დანიშნულების თანხები არ ემთხვევა, რაც გამოიწვევს დამატებით შერიგების სირთულეებს. ამიტომ, კონფიგურაციიდან მონაცემების გადმოტვირთვის პროცესში " ბუღალტერია 7.7» ნაჩვენებია შეტყობინებები დაფიქსირებული შეცდომების შესახებ (იხ. სურ. 4). გარდა ამისა, შეცდომების მოსაძებნად, ჩვენ შეგვიძლია გირჩიოთ დამუშავების "აღრიცხვის ექსპრეს შემოწმება", კერძოდ, წესი "არა ნულოვანი თანხა ნულოვანი რაოდენობით მასალებისთვის".



ნახ.4.1 შეცდომის შეტყობინებები

მეორე (მესამე) დონის სუბანგარიშზე არანულოვანი ნაშთი, ხოლო პირველ (მეორე) დონეზე ნაშთი ნულის ტოლია. ეს არის არასწორი აღრიცხვის საკმაოდ გავრცელებული სიტუაცია. ტიპიური მაგალითი ნაჩვენებია სურათზე 4.2. ანალიტიკურ აღრიცხვაში „კურორტის“ შედეგად არის ასეთი მდგომარეობა. მაგალითად, ხელშეკრულება მითითებულია ფულადი სახსრების ნაკადების დოკუმენტებში, მაგრამ დოკუმენტებში არ არის ხელშეკრულება საქონლისა და მასალების მიღებაზე, ან პირიქით, ან არის ხელშეკრულებები, მაგრამ ისინი განსხვავებულია. ყველა ამ შემთხვევაში, კონტრაქტებზე არის არანულოვანი ნაშთი, მიუხედავად იმისა, რომ კონტრაქტორის ნაშთი ნულის ტოლია. მსგავსი სურათი შეიძლება განვითარდეს მასალების აღრიცხვაში, ნომენკლატურაში (როდესაც ჩართულია მთლიანი აღრიცხვა შენახვის ადგილების მიხედვით): დახარისხება საწყობებს შორის, განსაკუთრებით იმ შემთხვევაში, თუ საწყობები მატერიალურად პასუხისმგებელი პირები არიან.



ნახ.4.2 ბუღალტრული აღრიცხვის შეცდომების მაგალითი

გასაგებია, რომ ეს შეცდომაა და გასაგებია, რომ ასეთი ნარჩენების გადატანას აზრი არ აქვს. ასეთი ნაშთების გადაცემის გამორიცხვის მიზნით არის პარამეტრი „ნუ განტვირთავ ნაშთებს, თუ ნულოვანი ბალანსი ზედა დონეზეა“. თუ ეს პარამეტრი დაყენებულია ერთზე, მაშინ შეტყობინებები ნაჩვენებია ნახ. 4.3 (შეადარეთ ნახ. 4.2) და ასეთი პოზიციების ნაშთები არ განიტვირთება. თქვენ შეგიძლიათ გამოიყენოთ ამ პარამეტრის სხვადასხვა კომბინაციები სხვადასხვა ნარჩენების გადაცემის წესებით. თუ თქვენ გადარიცხავთ არა ყველა ნაშთს ერთდროულად, არამედ ბუღალტრული სექციებით, მაშინ შეგიძლიათ გადაიტანოთ ნაშთები სხვადასხვა სააღრიცხვო განყოფილებისთვის სხვადასხვა პარამეტრის მნიშვნელობით.



სურ.4.3. შეცდომის შეტყობინებები

ცარიელი კონტრაქტის ღირებულებები ან სხვა ადამიანების კონტრაქტები.პრობლემა ზემოთ აღწერილის მსგავსია, მიზეზი იგივეა - ხელშეკრულებების ანალიტიკურ აღრიცხვაში რეგრადირება (იხ. სურ. 4.4). მაგრამ კონტრაგენტის ნაშთი არ არის ნულის ტოლი, ამიტომ ზემოთ აღწერილი გადამოწმების წესი არ იმუშავებს. მონაცემების გადაცემისას მოხდება შეცდომა ბალანსის შეტანის დოკუმენტის განთავსებისას, რადგან ცარიელი კონტრაქტის ღირებულება დაუშვებელია.



ნახ.4.4 შეცდომის ჩვენების ანგარიში

გადარიცხვამდე ასეთი შეცდომების აღმოსაფხვრელად, შეცდომის შეტყობინებები ნაჩვენებია მონაცემთა ატვირთვის ეტაპზე (იხ. სურ. 4.5). იგივე ფიგურა აჩვენებს, რომ დაფიქსირდა კიდევ ერთი შეცდომა: ხელშეკრულება არ შეესაბამება კონტრაგენტს, ე.ი. ხელშეკრულების მფლობელი სხვა კონტრაგენტია. ასეთი შეცდომები ხშირად გვხვდება შეცვლილში, ე.ი. არასტანდარტული კონფიგურაციები ან დიდი ხნის განმავლობაში დამკვიდრებულ მონაცემთა ბაზებში, როდესაც სტანდარტულ კონფიგურაციებს ჯერ არ ჰქონდათ საკმარისად მკაცრი შემოწმება კონტრაქტებთან შესაბამისობისთვის დოკუმენტების შევსებისას.



ნახ.4.5 ბუღალტრული შეცდომის შეტყობინებები

კონტრაქტებისა და სხვა ადამიანების კონტრაქტების ცარიელი მნიშვნელობების შემოწმება ხორციელდება, თუ პარამეტრი " შეამოწმეთ კონტრაქტები ცარიელი ღირებულებისთვის და შესაბამისობა კონტრაგენტთან". გარდა ამისა, შეცდომების მოსაძებნად, ჩვენ შეგვიძლია გირჩიოთ დამუშავების "აღრიცხვის ექსპრეს შემოწმება", კერძოდ, წესები "კონტრაქტებისთვის ცარიელი ანალიტიკა არ არის" და "კონტრაქტორებისა და კონტრაქტების მიმოწერა".

არსებობს სხვა შემოწმებები შეცდომებზე, დაზუსტებისთვის, დაგვიკავშირდით (კონტაქტები გვერდის ბოლოში).

ჩვენ გაჩვენებთ, თუ როგორ შეგიძლიათ გადაიტანოთ მონაცემები ნაწილებად და არა მთლიანად, ცალკეული ტიპის დოკუმენტების გადმოტვირთვის ან თუნდაც შერჩეული ტიპის დოკუმენტების ცალკეული შემთხვევების მაგალითის გამოყენებით. მოდი აღვნიშნოთ მხოლოდ ერთი წესი მონაცემთა გადმოტვირთვისთვის" გადახდის დავალება» (იხ. სურ. 5). ეს საშუალებას მოგცემთ ატვირთოთ დოკუმენტები მხოლოდ ფორმის " გადახდის დავალება". თუ დააკლიკეთ " განტვირთვა", შემდეგ ფორმის ყველა დოკუმენტი" გადახდის დავალება", რომელიც მდებარეობს დროის ინტერვალში " დაწყების თარიღი"ზე" ვადის გასვლის თარიღი". Დააჭირეთ ღილაკს " დააინსტალირეთ PVD"ამის შემდეგ წარწერა" მონაცემთა შერჩევა გადახდის ორდერისთვის«.



ნახ.5 როგორ დავაყენოთ გარკვეული ტიპის მონაცემების ატვირთვის წესი

შემდეგ დააწკაპუნეთ ღილაკზე „პირობის დამატება“, თქვენ შეძლებთ აირჩიოთ შერჩევის ატრიბუტი (იხ. სურ. 6.1), ყველაზე ხშირად ეს არის „ მიმდინარე დოკუმენტი«, რომელიც საშუალებას გაძლევთ აირჩიოთ ერთი დოკუმენტი ამ ტიპის დოკუმენტების სიიდან. შერჩევის სხვა დეტალების გამოყენებით შეგიძლიათ მიიღოთ შერჩევა დოკუმენტების ჯგუფის მიხედვით, მაგალითად, შეარჩიოთ დოკუმენტები თარიღის მიხედვით. ყველა შემთხვევაში, დოკუმენტების შერჩევა ხდება პარამეტრებით განსაზღვრულ დროში ". დაწყების თარიღი"და" ვადის გასვლის თარიღი«.



სურ.6.1 როგორ ავირჩიოთ ერთი დოკუმენტი

Მნიშვნელოვანი! "1C"), რომელიც ზოგიერთ კონფიგურაციაში არ იძლევა დოკუმენტების შერჩევის საშუალებას შერჩევის დეტალებით გადმოტვირთვისას. ეს გამოწვეულია იმით, რომ სამოდელო წესებში დოკუმენტები შეირჩევა მოთხოვნით, ვადის მითითების გარეშე. ასეთი მოთხოვნები ყოველთვის არ მუშაობს.

ანალოგიურად, დირექტორიების ატვირთვა შესაძლებელია არა მთელი დირექტორია, არამედ გარკვეული ატრიბუტის არჩევით. ჯერ აირჩიეთ სასურველი მონაცემების ატვირთვის წესი, შემდეგ თანმიმდევრულად დააჭირეთ ღილაკებს « დააინსტალირეთ PVD"და" პირობის დამატება". მაგალითად, სურათი 6.2 გვიჩვენებს, თუ როგორ შეგიძლიათ განტვირთოთ მხოლოდ ის თანამშრომლები, რომლებთანაც პროგრამიდან გადასვლის დროს " 1C: გამარტივებული საგადასახადო სისტემა, რედ. 1.3" ზე " 1C: Enterprise Accounting, გამოცემა 3.0” (ან, როგორც მომხმარებლები ხშირად ამბობენ, ბუღალტრული აღრიცხვის 7.7-დან 3.0-ზე გადასვლა) დამყარდა შრომითი ურთიერთობა.



სურ.6.2 როგორ ავირჩიოთ დირექტორია ელემენტების ჯგუფი

Მნიშვნელოვანი!მონაცემთა მიგრაციის შემოთავაზებულ წესებში, სტანდარტულ წესებში შეცდომა გამოსწორებულია (კომპანიის მხრიდან "1C"), რაც იწვევს დირექტორიას ელემენტების არასწორ შერჩევას დირექტორიის პერიოდული დეტალებით გადმოტვირთვისას, ე.ი. მათ, რომლებსაც აქვთ განსხვავებული მნიშვნელობა სხვადასხვა თარიღისთვის. ეს გამოწვეულია იმით, რომ მოდელის წესებში დირექტორიაში ელემენტების შერჩევა ხდება შეკითხვით, წერტილის მითითების გარეშე.

დირექტორიას პერიოდული დეტალების მიხედვით შერჩევა ხდება პარამეტრის თარიღზე. ვადის გასვლის თარიღი«.

შეგიძლიათ გამოიყენოთ მონაცემთა ატვირთვის წესებისა და ფილტრების კომბინაცია. წესები, რომლებისთვისაც დაყენებულია არჩევანი, მონიშნული იქნება ” [ FILTER ] “-ით. იმისათვის, რომ ნახოთ ან შეცვალოთ კონკრეტული მონაცემების ატვირთვის წესის არჩევანი, საჭიროა ორჯერ დააწკაპუნოთ ამ წესზე წესების სიაში, ან მისი არჩევის შემდეგ დააწკაპუნოთ " დააინსტალირეთ PVD«.

Მნიშვნელოვანი!თუ ობიექტების გადმოტვირთვა აღმოჩნდა ცარიელი ან არასრული, თქვენ უნდა შეამოწმოთ არის თუ არა სინქრონიზაციის რეჟიმი 1C: Accounting 8-თან დაყენებული. თუ ეს ასეა, მაშინ იქნება მხოლოდ ობიექტები, რომლებიც შეიცვალა გადაცემის დასრულების შემდეგ. გადმოტვირთული (Reference. Synchronous Accounting Parameters ინახავს ბოლო გადმოტვირთული დოკუმენტის პარამეტრის პოზიციას, რომელიც მოწმდება გადმოტვირთვისას ფუნქციით CheckOn the Posibility of Deloading) . სრული მუშაობა სინქრონიზაციის რეჟიმში შეუძლებელი ხდება. სინქრონიზაციის რეჟიმი მოწმდება გაცვლის წესების ჩატვირთვის შემდეგ. თუ რეჟიმი დაყენებულია, გამაფრთხილებელი ფანჯარა წარმოიქმნება (იხ. სურ.6.5) და იქნება შემოთავაზებული სინქრონიზაციის რეჟიმის გამორთვა.



ბრინჯი. 6.5 სინქრონიზაციის რეჟიმის გამაფრთხილებელი ფანჯარა

დამატებითი განსხვავებები მოდელის წესებისგან

P&L-ის ფიქსირებული გადაცემა ძველი ქვითრის ტიპებით: თუ საქონლისა და მომსახურების ქვითრის დოკუმენტებში ქვითრის ტიპი არის 2 (მოძველებული ღირებულება) და არ არის მიმწოდებლის ინვოისი, ხდება ამ დოკუმენტის BP 3.0-ში მცდარი გადაქცევა მყიდველის დაბრუნების დოკუმენტად. .

დაფიქსირდა შეცდომა მექანიკური ოპერაციების გადაცემისას, რომლებსაც აქვთ ქვედანაყოფის ქვეანგარიში BP PROF ვერსიაში. ასეთი ოპერაცია არ არის ჩაწერილი BP-ში, ჩნდება შეცდომა: "განყოფილების ველი ცარიელი უნდა იყოს". ეს გამოწვეულია იმით, რომ წესები შექმნილია CORP ვერსიებთან მუშაობისთვის, თუმცა PROF-ში სააღრიცხვო რეესტრის DivisionDt და DivisionKt ზომები ცარიელი უნდა იყოს.

დაფიქსირდა ხარვეზი, რამაც გამოიწვია კატალოგის დუბლიკატი ჯგუფები ხელშეკრულებებიდა, შედეგად, ამ დირექტორიაში ელემენტების დუბლირებას (რადგან ჩატვირთვისას ძიება ხორციელდება მშობლის გათვალისწინებით). ეს ილუსტრირებულია სურათზე 6.6.



სურ.6.6 დირექტორიაში გადაცემის შედეგი ხელშეკრულებებიმოდელის წესები

აქ, სვეტში მშობელი(საცნობარო ჯგუფი) სახელწოდებით 2015 არსებობს დირექტორიაში ორი განსხვავებული ჯგუფი ერთი და იგივე სახელით (წყაროში არის ერთი ჯგუფი), შესაბამისად, კონტრაქტები დუბლირებულია.

დაფიქსირდა საბანკო დოკუმენტების გადარიცხვის შეცდომა ერთი მიმდინარე ანგარიშიდან მეორეზე თანხის გადარიცხვისას. AT BP 3.0ამ შემთხვევაში დოკუმენტი იქმნება ჩამოწერა მიმდინარე ანგარიშიდანოპერაციის ტიპთან ერთად გადარიცხვა ორგანიზაციის სხვა ანგარიშზე,რომელიც არ ტარდება რეკვიზიტების შეუვსების გამო ბენეფიციარის ანგარიში. გარდა ამისა, დეტალები არასწორად არის შევსებული საბუღალტრო ანგარიშიდა სადებეტო ანგარიში. ეს გამოიხატება, თუ ისინი განსხვავდებიან, მაგალითად 55 და 51, მაშინ ისინი უნდა შეიცვალოს. გამოსწორდა ხარვეზი დაკარგული დეტალებით ვალდებულების სახეობასაგადასახადო დოკუმენტებში. ყოველივე ზემოთქმული ეხება 3.0.43.215 გამოშვებას.

მიმდინარეობს რეკვიზიტების გადატანა მთავარი კონტრაქტიდირექტორია კონტრაგენტები.

შეიცვალა ხელით გადმოტვირთვის წესი ნომენკლატურაახლა მონაცემთა შერჩევის მეთოდი არის სტანდარტული შერჩევა, რომელიც საშუალებას გაძლევთ აირჩიოთ საცნობარო წიგნის ელემენტები დეტალების მიხედვით (USN 7.7 - BP 3.0 სტანდარტული წესებით ეს შეუძლებელია). დირექტორიას გადაცემისას ნომენკლატურა, გადაყვანილნი არიან და ნივთების ფასებილინკებით, ე.ი. საქონლის მხოლოდ გადაცემული ნივთების ფასები. ამ ფუნქციის გასააქტიურებლად, თქვენ უნდა დააყენოთ პარამეტრის მნიშვნელობა ერთზე. ატვირთეთ ფასები ნივთის გადმოტვირთვისას.

დაფიქსირდა ხარვეზი სტანდარტულ წესებში "USN 7.7 - BP 3.0" კონტრაგენტებთან ანგარიშსწორებისთვის ნაშთების გადაცემისას: კონტრაქტის ტიპი ყოველთვის იყო დაყენებული. სხვა. ახლა - ბალანსის ტიპის მიხედვით, სააღრიცხვო განყოფილების მიხედვით " ანგარიშსწორება მომწოდებლებთან და კონტრაქტორებთან» კონტრაქტის ტიპი = « Მიმწოდებელი", ბუღალტრული აღრიცხვის განყოფილების მიხედვით" ანგარიშსწორებები მყიდველებთან და მომხმარებლებთან» კონტრაქტის ტიპი = « მყიდველთან ერთად", სხვა შემთხვევებში, ხელშეკრულების ტიპი = " სხვა«.

დაფიქსირდა ხარვეზი სტანდარტულ წესებში "USN 7.7 - BP 3.0" კონტრაგენტებთან ანგარიშსწორებისთვის ნაშთების გადაცემისას: ორმხრივი ანგარიშსწორების ოდენობა დაფიქსირდა დოკუმენტის ორ დეტალში საწყისი ნაშთების შესაყვანად. ჯამიდა თანხაKt. შედეგად, გახსნის ბალანსის შესვლის დოკუმენტი არ იყო განთავსებული.

Ჩეკიმყიდველთან ერთად"(მოდელის წესებში" სხვა"). ატრიბუტის მნიშვნელობა " გადახდის სახელმწიფო“, ეს მნიშვნელოვანია მყიდველისთვის გადახდისათვის ანგარიშის სწორად შერჩევისთვის საბანკო გადახდის დოკუმენტებში მიმღების კონფიგურაციაში.

ფორმის დოკუმენტების გადაცემისას " გადახდის დავალება» ხელშეკრულების ტიპი დაყენებულია « Მიმწოდებელი"(მოდელის წესებში" სხვა«).

დაფიქსირდა ხარვეზი სტანდარტულ წესებში "USN 7.7 - BP 3.0" შენახვის ადგილების გადაცემისას: ატრიბუტი " საწყობის ტიპი«.

დამატებულია პარამეტრი " შედის მარეგულირებელ ორგანოებთან გაცვლა": თუ მისი მნიშვნელობა არის 1, მაშინ props სამეთვალყურეო ორგანოებთან გაცვლის ტიპიდირექტორია ელემენტი " ორგანიზაციები"დაყენებულია" ExchangeInUniversalFormat", წინააღმდეგ შემთხვევაში" Exchange გამორთულია» როგორც სტანდარტულ წესებში. ეს მნიშვნელოვანია განმეორებითი (რეგულარული) გადარიცხვებისთვის, რათა არ გააფუჭოს EDI დაყენება.

შეცვალა ძიების წესი ჩამოტვირთული ელემენტების დირექტორიაში " კონტრაგენტები": ჯერ ჩხრეკა მიმდინარეობს ᲥᲘᲚᲐდა საგუშაგო(თუ ეს მნიშვნელობები ივსება), მაშინ მხოლოდ ᲥᲘᲚᲐდა ბოლოს სახელი. სამივე შემთხვევაში ძიება მოიცავს ჯგუფის (ThisGroup) და თავად ჯგუფის (მშობელი) ატრიბუტს. ეს მნიშვნელოვანია განმეორებითი (რეგულარული) გადარიცხვებისთვის, რათა არ შეიქმნას დუბლიკატები კონტრაგენტებისთვის, რომელთა სახელები შეიცვალა ატვირთვის შემდეგ.

კონტრაგენტების გადაცემისას ივსება დეტალები ქვეყნის რეგისტრაციანიშნავს "რუსეთს". ეს აუცილებელია იმისათვის, რომ კონტრაგენტების დირექტორია პროგრამაში ჩატვირთვის შემდეგ "1C ბუღალტერია 8"საჭირო დეტალების ხელით შევსება არ მოუხდა ქვეყნის რეგისტრაცია. თუ ის არ არის შევსებული, მაშინ საცნობარო ელემენტის სახით " კონტრაგენტები» დეტალები ხელმისაწვდომი იქნება » საგადასახადო ნომერი"და" რეგ. ოთახი"და დეტალები" ᲥᲘᲚᲐ"და" საგუშაგო» დაიმალება.

გადაცემის წესებში "USN 7.7 - BP 3.0" დამატებულია მონაცემთა ატვირთვის წესი "თანამშრომლების" დირექტორიაში გადასატანად (სტანდარტულ წესებში გადადის მხოლოდ ფიზიკური პირების დირექტორია).

"USN 7.7 - BP 3.0" გადაცემის წესში შესწორებულია საინფორმაციო რეესტრის გადაცემის წესი თანამშრომელთა მიმდინარე ანაზღაურებადი განაკვეთი.

გადასახადების გადახდის მიზნით გადახდის დავალების გადაცემის მახასიათებლები

ოპერაციული ტიპის საგადახდო დავალებებისთვის გადასახადის გადარიცხვადამატებითი დეტალები უნდა შეივსოს: BCC - ბიუჯეტის კლასიფიკაციის კოდი, შემდგენელის სტატუსი და ა.შ. ამ დეტალების სტრუქტურები ში ბუმი 7.7 (USN 7.7) და ში BP 3.0არ ემთხვევა. განსაკუთრებით -ში BP 3.0ზოგიერთი დეტალი მოთავსებულია ცალკე დირექტორიაში, რომლის ბმული მოცემულია გადახდის დავალებაში. დირექტორია გადასახადების სახეები და ბიუჯეტში გადახდებიშეიცავს უამრავ მოწოდებულ ელემენტს, რომლებიც გამოჩნდება ინფო ბაზაში, მაგალითად, სააღრიცხვო პოლიტიკის რედაქტირებისას. მონაცემთა მიგრაციისას, ეს ელემენტები ასევე გამოჩნდება სააღრიცხვო პოლიტიკის ჩატვირთვისას. გადახდის დავალებების ატვირთვის/ჩამოტვირთვისას დირექტორიას ელემენტი გადასახადების სახეები და ბიუჯეტში გადახდებიმოიძია CCC-მ გადახდის დავალების დეტალებში ჩანაცვლებისთვის გადასახადი. ამიტომ რეკომენდირებულია, რომ სააღრიცხვო პოლიტიკის გადაცემის შემდეგ შეამოწმოთ, გამოჩნდა თუ არა ყველა საჭირო გადასახადი დირექტორიაში, საჭიროების შემთხვევაში, დამატება. წყაროსა და მიმღებში საგადახდო დავალებებში CCC-ის შედარების (სინქრონიზაციისას) არ არის გათვალისწინებული CCC-ის ოთხი ციფრი, ციფრები 14-17, შემოსავლის ქვეტიპის კოდი: გადასახადი, ჯარიმები, ჯარიმები და ა.შ. დირექტორიაში გადასახადების სახეები და ბიუჯეტში გადახდებიეს ბიტები ივსება ნულებით. დირექტორიაში ახალი ელემენტების დამატებისას, ციფრები 14-17 ასევე უნდა იყოს შევსებული ნულებით.

დიდი ზომის საინფორმაციო ბაზების გადაცემა.

უპირველეს ყოვლისა, დიდი ინფობაზების მიგრაციისას, მონაცემთა გადმოტვირთვის პროცესს შეიძლება ძალიან დიდი დრო დასჭირდეს. ეს ხდება იმ შემთხვევაში, თუ ერთ სააღრიცხვო განყოფილებაში არის ნაშთების დიდი რაოდენობა, მაგალითად, საქონლის ნაშთები. გადმოტვირთვის დროის შესამცირებლად, შეგიძლიათ გამოიყენოთ ერთი დოკუმენტის გაყოფის მეთოდი " გახსნის ნაშთების შეყვანა"რამდენიმე. თუ დააყენეთ პარამეტრის მნიშვნელობა " ბალანსის შესატან დოკუმენტში ხაზების რაოდენობა» არ არის ნულოვანი (იხ. სურ.6.3), მაშინ მონაცემების ატვირთვა ერთ დოკუმენტში შემოიფარგლება მითითებული მნიშვნელობით. ამან შეიძლება მნიშვნელოვნად (რამდენჯერმე) შეამციროს გადმოტვირთვის დრო.



სურ.6.3 პარამეტრების დაყენება დოკუმენტის ზომის ლიმიტით მონაცემთა გადაცემისას « გახსნის ნაშთების შეყვანა»

შენიშვნა: პარამეტრის მნიშვნელობა ზღუდავს გამოქვეყნების ცხრილის ხაზების რაოდენობას, რომლებიც ატვირთულია ერთ დოკუმენტში " გახსნის ნაშთების შეყვანა”, და არ ადგენს თავად დოკუმენტის სტრიქონების რაოდენობას. ამრიგად, დოკუმენტის ხაზების რაოდენობა განსხვავდება პარამეტრის მნიშვნელობიდან, ეს არ არის შეცდომა. დოკუმენტის გაყოფისას გახსნის ნაშთების შეყვანარამდენიმე დოკუმენტს, სტრიქონის ბოლოს თითოეული დოკუმენტის კომენტარებს დაემატება პოსტფიქსი: „-1“, „-2“ და ა.შ.

ᲛᲜᲘᲨᲕᲜᲔᲚᲝᲕᲐᲜᲘ!აღწერილი ალგორითმი ერთი დოკუმენტის გაყოფისთვის " გახსნის ნაშთების შეყვანა» რამდენიმესთვის გამოიყენება მხოლოდ მონაცემების ატვირთვის დროის შესამცირებლად, ყველა დოკუმენტი იტვირთება ერთ ფაილში, ე.ი. მონაცემთა გადაცემა ხდება ერთ ეტაპად, კომენტარები (პოსტფიქსები) გენერირდება ავტომატურად, დაყენებულია მხოლოდ ერთი პარამეტრი. მაგრამ ეს ტექნიკა არ წყვეტს მეხსიერების ნაკლებობის პრობლემას, რომელიც ქვემოთ იქნება განხილული.

დიდი ინფობაზების მიგრაციისას შეიძლება წარმოიშვას RAM-ის ნაკლებობის პრობლემა: პროგრამის განტვირთვის მცდელობისას, პროგრამა შეწყდება შესაბამისი შეცდომის გაგზავნით ან შეტყობინების გარეშე. კომპიუტერის უფრო ძლიერით გამოცვლის მცდელობა უსარგებლოა. ამ შემთხვევაში, თქვენ უნდა გადმოტვირთოთ მონაცემები ნაწილებად, დაყავით ისინი ნაწილებად. ეს მოითხოვს მიგრაციის წესებს, რომლებიც მხარს უჭერენ მითითებულ რეჟიმს. ვნახოთ როგორ განიტვირთოთ. პირველ რიგში, მონაცემთა გადაცემა უნდა განხორციელდეს მხოლოდ ერთი ატვირთვის წესის გამოყენებით (იხ. სურათი 6.4). თუ ერთი წესის მიხედვით გადატანა შეუძლებელია, მაშინ მას ნაწილებად ვყოფთ, ნაწილებად, თავდაპირველ და საბოლოო რაოდენობაზე მითითებით. თითოეული ნაწილი შეიცავს ინფორმაციას პირველი დონის ანალიტიკური მნიშვნელობების მოცემულ რაოდენობაზე, მაგალითად, პროდუქტის ნაშთებზე, ე.ი. ნაშთების მნიშვნელობების მითითებული რაოდენობა "41" ანგარიშზე. ანგარიშზე არსებული ანალიტიკის მთლიანი რაოდენობის გაცნობით, ადვილია სერვისების რაოდენობის გამოთვლა. რამდენი მონაცემი გადაიცემა უპრობლემოდ ერთდროულად (ერთ ინფორმაციას) ემპირიულად უნდა განისაზღვროს, როგორც წესი, ანგარიშის ნაშთების გადმოტვირთვისას, გადარიცხვის პრობლემები ჩნდება, როდესაც ნაშთების რაოდენობა რამდენიმე ათასი ან მეტია. თუმცა, მონაცემების ატვირთვის დროის დაზოგვის მიზნით, შესაძლებელია რეკომენდაცია გავყოთ ნაწილებად, მაშინაც კი, თუ შესაძლებელია ბუღალტრული განყოფილების ყველა ნაშთის ატვირთვა ერთდროულად. გადმოტვირთვის დრო არ არის დამოკიდებული მონაცემთა ნაწილის ზომაზე პროპორციულად და არა წრფივად. ამიტომ, მაგალითად, ათი ათასი საქონლის ნაშთების ათეულ ნაწილად გაყოფით, შეგიძლიათ რამდენჯერმე შეამციროთ გადმოტვირთვის დრო. თუ პირველ პორციას გადავიტანთ, შეიძლება გამოვტოვოთ საწყისი ნაწილის ნომერი, თუ ბოლო ნაწილი, მაშინ ბოლო ნაწილის რაოდენობა შეიძლება გამოტოვოთ.

ᲛᲜᲘᲨᲕᲜᲔᲚᲝᲕᲐᲜᲘ!მონაცემების ნაწილებად გადაცემისას აუცილებელია პარამეტრებში მიუთითოთ პოსტფიქსი, რომელიც მონაწილეობს დოკუმენტის კომენტარის ფორმირებაში. გახსნის ნაშთების შეყვანა". ნაწილების დიაპაზონის ნომრების შეცვლისას, არ უნდა დაგვავიწყდეს პოსტფიქსის შეცვლა, წინააღმდეგ შემთხვევაში, მიმღების კონფიგურაციაში ჩატვირთვისას, დოკუმენტები იგივე კომენტარებით (პოსტფიქსები) გადაიწერება. მონაცემთა ფაილის სახელს დიდი მნიშვნელობა არ აქვს. შეგიძლიათ გამოიყენოთ თანმიმდევრული გადაცემის ტაქტიკა: ატვირთვა - ჩამოტვირთვა, ატვირთვა - ჩამოტვირთვა და ა.შ. მონაცემთა ფაილის სახელი ამ შემთხვევაში შეიძლება დარჩეს უცვლელი. თქვენ შეგიძლიათ აირჩიოთ ტაქტიკა: ჯერ გადმოტვირთეთ ყველაფერი, შემდეგ გადმოწერეთ ყველაფერი. ამ უკანასკნელ შემთხვევაში, მონაცემთა ფაილის სახელი უნდა შეიცვალოს ყოველ ატვირთვაზე. კიდევ ერთხელ მაგალითი. თუ სააღრიცხვო განყოფილებაში ნაშთების რაოდენობა (მაგალითად, საქონელი) არის, ვთქვათ, 10000, მას ვყოფთ ნაწილებად ათასზე, მაშინ მივიღებთ 10 პორციას. თითოეულ ნაწილს უნდა ჰქონდეს უნიკალური პოსტფიქსი: "-1", "-2", "-3", "-4". თუ ჩვენ განვტვირთავთ ყველა დანარჩენ საქონელს და შემდეგ ვტვირთავთ ყველაფერს, მაშინ მონაცემთა ფაილებიც უნიკალური უნდა იყოს, მაგალითად: "41_1", "41_2", "41_3", "41_4". პარამეტრებმა "Portion number start" და "Portion number end" უნდა მიიღონ შემდეგი მნიშვნელობები: 0, 1000; 1001, 2000; 2001, 3000; 3001, 4000.

• როდესაც სამსახურიდან გათავისუფლების შემდეგ ხანდაზმულობა წყდება 2007 წლის 1 იანვრიდან მოქალაქის ხანდაზმულობის უწყვეტობის დადგენის ოდნავ განსხვავებული პროცედურა მოქმედებს. მანამდე, თუ სამუშაო ადგილიდან მეორეზე გადასვლისას 3 კვირა არ გასულა, მაშინ გამოცდილება არ შეწყვეტილა. 2007 წლიდან […]
• ANKO ტამბოვის სასამართლო ექსპერტიზისა და გამოძიების ცენტრი, ANO ANKO ტამბოვის სასამართლო ექსპერტიზისა და კვლევების ცენტრი, ANO რეგისტრირებულია ტამბოვში, რაბოჩაიას ქ., 37, ოფისი 40, 392008.
• სამუშაო დროის განრიგის შეკვეთა სამუშაო დროის განრიგის ნიმუშის შეკვეთა სამუშაო დროის განრიგის შესახებ რუსეთის ფედერაციის შრომის კოდექსის 100, 103, 104, 73 მუხლებისა და PJSC "ორგანიზაციის" შრომის შინაგანაწესის შესაბამისად. საწარმოს მუშაობის ოპტიმიზაცია და გაზრდის […]
• ეკატერინბურგის No20 ცენტრალურ საქალაქო კლინიკურ საავადმყოფოში, სადაც მთავარი ექიმი გაათავისუფლეს, მოქმედი კომპანია დაინიშნა | სვერდლოვსკის რეგიონი| ურალის ფედერალური ოლქი ალენა ტუნისი დაინიშნა ეკატერინბურგის No20 ცენტრალური საქალაქო საავადმყოფოს მთავარი ექიმის მოვალეობის შემსრულებლად. ჟურნალისტის თქმით, […]
• ომის კანონი პარალელისთვის მულტიმედია 8 უჯრედი. მულტიმედია 9 კლასი მულტიმედია 10-11 უჯრედი. ასტრონომიის ტესტები 7 კლასი ამოწმებს 8 უჯრედს. ამოწმებს 9 უჯრედს. გამოცდის საჩვენებელი ცხრილები […]
• რსფსრ კანონი „საქონლის ბაზრებზე კონკურენციისა და მონოპოლისტური საქმიანობის შეზღუდვის შესახებ“ 1991 წლის 22 მარტის N 948-1 (შესწორებულია რუსეთის ფედერაციის 06/24/1992 N 3119-1 კანონებით, 07/15). /1992 N 3310-1; ფედერალური კანონები 05.25. 1995 N 83-FZ, 06.05.1998 N 70-FZ, 02.01.2000 N 3-FZ, დათარიღებული […]

1. შესავალი.

2. რაც გჭირდებათ: 1C კონფიგურაცია: მონაცემთა კონვერტაცია 2. * და დამუშავება პაკეტიდან. ამოცანების მაგალითზე ვიღებთ კონფიგურაციებს 1C: Trade Management 11 და 1C: BP 3.*.

ასე რომ, 1C-ზე მონაცემების ატვირთვის წესების შესამუშავებლად, დაგჭირდებათ 1C კონფიგურაცია: Object Conversion 2, ისევე როგორც დამუშავება, რომელიც შედის პაკეტში.

მაგალითად, ჩვენ უკვე განვათავსეთ კონვერტაციის ბაზა და გავუშვით.

ჩვენ დავწერთ გაცვლის წესების შემუშავებას კონფიგურაციას შორის 1C: Trade Management 11 და 1C: Enterprise Accounting 3 (UT / BUH გაცვლის წესები).

3. ჩვენ დაგვჭირდება დამუშავება მეტამონაცემების სტრუქტურის განტვირთვისა და გაცვლისთვის.

პირველი, რაც თქვენ უნდა მიიღოთ განვითარებისთვის არის ფაილები მეტამონაცემების სტრუქტურით. ეს კეთდება მეტამონაცემების სტრუქტურის გადმოტვირთვის დამუშავების გამოყენებით, რომელიც შედის ობიექტის კონვერტაციის პაკეტში.

რეალურად, კონფიგურაციის გაუხსნელ დირექტორიაში კონფიგურაციისთვის მართული ფორმებიჩვენ დაინტერესებული ვართ MD83Exp.epf-ის დამუშავებით. თუ გადმოტვირთვა უნდა განხორციელდეს კონფიგურაციებიდან ჩვეულებრივ ფორმებზე, მაშინ გამოიყენება MD82Exp.epf დამუშავება. ეს ხდება იმ შემთხვევაში, თუ, მაგალითად, თქვენ გჭირდებათ სტრუქტურის მიღება ისეთი კონფიგურაციებიდან, როგორიცაა 1C: UT 10, 1C: წარმოების საწარმოების მენეჯმენტი 1.3, 1C: ინტეგრირებული ავტომატიზაცია 1.1, 1C: Zup 2.5 და ა.შ.

გარდა ამისა, 1C-ში მონაცემების ატვირთვისა და ჩამოტვირთვისთვის, ჩვენი წესების გამოყენებით, დაგჭირდებათ "უნივერსალური მონაცემთა გაცვლა XML ფორმატში" V8Exchan83.epf კონფიგურაციისთვის მართულ ფორმებზე, როგორიცაა 1C: Trade Management 11. *, 1C BP 3, 1C. : ERP 2. * და მსგავსი. და შესაბამისად V8Exchan83.epf - რეგულარულ ფორმებზე კონფიგურაციისთვის.

4. კონფიგურაციის მეტამონაცემების სტრუქტურის ატვირთვა 1C: Trade Management 11.3 და 1C: Enterprise Accounting 3.0. *

დავიწყოთ მეტამონაცემების სტრუქტურის გადმოტვირთვით 1C კონფიგურაციიდან: Enterprise Accounting 3.
გახსენით დამუშავება MD83Exp.epf

დამუშავების ფორმაში არის დამატებითი პარამეტრები, სადაც შეგვიძლია ჩართოთ ან გამორთოთ რეგისტრების და მოძრაობების განტვირთვის ვარიანტი 1C-ში. ასევე არსებობს არჩევანი, სადაც განხორციელდება გადმოტვირთვა: 1C სერვერზე ან „კლიენტზე“. მიუთითეთ ფაილის სახელი, სადაც მონაცემთა სტრუქტურა განიტვირთება. ანალოგიურად, ჩვენ ვტვირთავთ კონფიგურაციის მეტამონაცემების სტრუქტურას Trade Management 11.

ახლა თქვენ უნდა ჩატვირთოთ კონფიგურაცია კონვერტაციის მონაცემთა ბაზაში. ამ პუნქტის მიღწევა შესაძლებელია როგორც კონფიგურაციების სიიდან, ასევე კონვერტაციების სიიდან. მოდით, უბრალოდ ჩატვირთოთ დესკტოპიდან:

დიალოგურ ფანჯარაში ჩატვირთეთ BP სტრუქტურა:

და ანალოგიურად - ვაჭრობის დეპარტამენტის სტრუქტურა.

ჩამოტვირთვის დასრულების შემდეგ გამოჩნდება დიალოგური ფანჯარა, სადაც შეგიძლიათ მიუთითოთ თქვენთვის მოსახერხებელი სახელი.

6. 1C-ში კონვერტაციის წესების შექმნა დავალების კონკრეტულ მაგალითზე.

შემდეგ გადადით "ობიექტის წესების დაყენება", სადაც ვქმნით ახალ პარამეტრს.
კონვერტაციის შესაქმნელად დიალოგურ ფანჯარაში აირჩიეთ "წყაროს" კონფიგურაცია და "დანიშნულების ადგილის" კონფიგურაცია (რომელიც ადრე ჩატვირთეთ) და დააწკაპუნეთ OK.

ვინაიდან ამ სტატიაში მე ვგეგმავდი ქმნილების ჩვენება "ნულიდან" და "ნაგვის გარეშე", შეგახსენებთ, რომ ჩვენ ავტომატურად არ ვქმნით არაფერს. არანაირი პროტოტიპები.

ჩვენ არაფერს გავაკეთებთ ამ დიალოგურ ფანჯარაში, უბრალოდ დააჭირეთ - "დახურვა".

მოდით შევქმნათ წესები არა ერთი დოკუმენტის ერთში, არამედ ერთი ტიპის მეორეში გადმოტვირთვისთვის, მაგალითად, დოკუმენტი საქონლისა და მომსახურების გაყიდვები UT 11-დან საჭირო დირექტორიებით BP 3-ში საქონლისა და მომსახურების მიღების დოკუმენტისთვის.

ასე რომ, ჩვენ ვქმნით ახალ PKO-ს (ობიექტების 1C-ად გადაქცევის წესი)

აირჩიეთ წყარო მომსახურების საქონლის რეალიზაცია და მომსახურების საქონლის მიღების მიმღები და დააწკაპუნეთ OK.
ამ შემთხვევაში გამოჩნდება დიალოგური ფანჯარა, სადაც კვლავ უარს ვიტყვით PKC-ის (საკუთრების კონვერტაციის წესები) ავტომატურ შექმნაზე. შემდეგი, ჩვენ ვირჩევთ მხოლოდ საჭიროებს.

მაგრამ PVD-ის შექმნის წინადადებაზე (მონაცემთა ატვირთვის წესები), ჩვენ ვპასუხობთ "დიახ".

იქმნება VDP-ები, რაც აისახება შერჩევის უნივერსალური XML გაცვლის დამუშავებაში:

ასევე შეიქმნება მონაცემთა კონვერტაციის წესები ცარიელი ქონების კონვერტაციის წესებით.

უფრო მეტიც, ცხადია, რომ ნაგულისხმევად შემოთავაზებულია FSP-ის მოძიება ობიექტის შიდა იდენტიფიკატორით. ამაზე მიუთითებს გამადიდებელი შუშა PKO-სთან ახლოს. ჩვენ თვითონ გავაკეთებთ ძიებას და გავაკეთებთ დოკუმენტის ნომრით და დღის დასაწყისში.

UIO-ს ძიების წაშლა:

ახლა დავიწყოთ ობიექტის საჭირო თვისებების (რეკვიზიტების) შესაბამისობა. ამისათვის დააწკაპუნეთ "საკუთრების სინქრონიზაციაზე" (ეკრანის ეტიკეტი "1"). ჩვენ ვხსნით წესების რეკურსიულ შექმნას ("2"). ჩვენ ვხსნით ყველა მონიშნულ დეტალს ("3"). და ჩვენ თვითონ ავირჩევთ იმას, რაც გვჭირდება.

მაგალითად, აირჩიეთ ის, რაც გჭირდებათ:

თქვენს ყურადღებას ვაქცევ იმ ფაქტს, რომ ჩვენ ვაქცევთ კონტრაგენტის PKS-ს ორგანიზაციაში, ხოლო ორგანიზაციას კონტრაგენტად, ასევე შევადარებთ ზოგიერთ დეტალს, რომელიც არ ემთხვევა სახელს, მაგალითად, "ვალუტა" და "დოკუმენტი". ვალუტა”.

სადაც ვხედავთ, რომ ჯერ არ არსებობს კონვერტაციის წესები.

დავიწყოთ დეტალებით, რომ გავიაროთ და აღვწეროთ. ჯერ დავაყენებთ დოკუმენტის ძიებას, როგორც ადრე დავწერე, ვატვირთავთ და ვეძებთ დოკუმენტს თარიღის დასაწყისში და შევცვლით ნუმერაციას. ჩვენ შევცვლით პირველ სამ სიმბოლოს ჩვენი პრეფიქსით "UTB". და რადგან BP-სა და UT-ში ნუმერაცია თითო 11 სიმბოლოა, ჩვენ ვქმნით კომპოზიტურ რიცხვს: ჩვენი პრეფიქსი და 8 სიმბოლო წყაროდან. სკრინშოტის მაგალითი ქვემოთ.

ჩვენ ყოველთვის ვტვირთავთ შეუსრულებელ და გადაადგილების გარეშე დოკუმენტებს. ჩვენ ვვარაუდობთ, რომ დოკუმენტები მომხმარებლის მიერ შემოწმების შემდეგ დარჩება მიმღებში.

ამისათვის, PCS-ი, რომელსაც აქვს მითითებული, თუ როგორ არ არის გამართული, 0 ან 1, გამოიყენება როგორც ლოგიკური მნიშვნელობა.

ვალუტის მაგალითის გამოყენებით, ჩვენ ვქმნით წესს PCS-სთვის ობიექტის კონვერტაციისთვის. ამავდროულად, მიგვაჩნია, რომ ორივე ბაზაში არის ვალუტა და ისინი უნდა იყოს სინქრონიზებული კოდით. ამიტომ, ჩვენ არ შევქმნით ყველა PCS-ს ვალუტების CSP-ში, არამედ დავამატებთ მხოლოდ კოდს საძიებლად. იმათ. ობიექტისთვის PCS-ის შექმნის წინადადებიდან - ჩვენ უარს ვამბობთ.

შექმნილი კონვერტაციის წესი ჩანაცვლდა დოკუმენტის PQS-ში SCS-ისთვის. და ნაგულისხმევი წესი თავად არის შემოთავაზებული უნიკალური იდენტიფიკატორით. ვასწორებთ, ვაკეთებთ ძიებას კოდში და ვაყენებთ თვისებას ისე, რომ არ შეიქმნას ახალი ობიექტი.

შედეგად, ჩვენ ვიღებთ ვარიანტს:

გარდა ამისა, ანალოგიით, ჩვენ ვქმნით PKO-სა და PKS-ის დანარჩენ დეტალებს. უფრო მეტიც, ჩვენ დავაყენეთ ორგანიზაციის ძებნა კონტრაგენტის მიხედვით და პირიქით TIN-ით. ასე გამოიყურება მინიმალური დეტალებით (შეგიძლიათ დაამატოთ საჭიროების შემთხვევაში).

კონტრაგენტთა PKO ხელშეკრულებებისთვის ჩვენ ვეძებთ PKS კონტრაგენტს, სახელს და მფლობელს.

ვნახოთ, როგორ მივუთითოთ სასურველი მნიშვნელობა აღრიცხვის ტიპში PCS-ში. მაგალითად, ატრიბუტი "ოპერაციის ტიპი". აქ შეგიძლიათ გამოიყენოთ სხვადასხვა პირობები და შემცვლელი მნიშვნელობები. მაგალითად, ჩვენ გვჭირდება "ოპერაციის ტიპი", რომ ყოველთვის განიტვირთოს "საქონელი", ამ შემთხვევაში საკმარისია "შუბლზე" სასურველი მნიშვნელობა სტრიქონის სახით ჩავწეროთ.

ქვემოთ მოცემულია, თუ როგორ უნდა დააყენოთ უპრობლემოდ და უმეტეს შემთხვევაში PKS ანგარიშსწორების სიმრავლისთვის, ანგარიშსწორების განაკვეთისთვის, ანგარიშებისთვის.

PKO ნომენკლატურისთვის, ჩვენ ვტოვებთ ძიებას შიდა უნიკალური იდენტიფიკატორით. მაგრამ მე ყურადღებას გავამახვილებ იმაზე, თუ როგორ შეგიძლიათ ხელახლა განსაზღვროთ თქვენი ჯგუფი. მაგალითად, ჩვენ ვეთანხმებით, რომ ახალი ნომენკლატურა განიტვირთება კონფიგურაციიდან 1C: Trade Management 11, მაგრამ აუცილებელია, რომ ნომენკლატურა შეგროვდეს კონკრეტულ ჯგუფში "OurGroup".

ამ ამოცანის განსახორციელებლად, ჩვენ ვქმნით სხვა PKO-ს. დავარქვათ მას „ნომენკლატური მშობელი“, რომელსაც კონვერტაციის წესში მშობლის PDN-ში მივუთითებთ.

ჩვენ დავაყენეთ ორი ძიება: სახელით, სადაც ჩვენი ჯგუფის სახელი არის მყარი კოდირებული და ატრიბუტის "ThisGroup" სავალდებულო თვისება true.

ვინაიდან ჩვენ გადავწყვიტეთ, რომ მთელი ნომენკლატურა მოხვდება ჩვენს ჯგუფში, განტვირთვისას არ არის საჭირო ჯგუფების განტვირთვა UT 11-დან. ამისათვის ნომენკლატურაში PKO „განტვირთვამდე“ მოვლენის დამმუშავებელში დავდებთ ფილტრს, რომელიც არ არის აუცილებელი ჯგუფების "Failure = Source. This group;" განტვირთვა.

DRP (მონაცემთა ატვირთვის წესები) საქონლისა და სერვისის იმპლემენტაციაში ჩვენ დავამატებთ ფილტრს ისე, რომ წაშლისთვის მონიშნული დოკუმენტები არ აიტვირთოს. ამისათვის PDP-ში ღონისძიების დამმუშავებლებში „BeforeUnloading“ დავწერთ ფილტრს „Rejection = Object.DeletionMark;“.

შეინახეთ შემუშავებული წესები ფაილში.

7. შეჯამება: მონაცემთა ატვირთვა და ჩამოტვირთვა მონაცემთა გაცვლის შემუშავებული წესების გამოყენებით.

ჩვენ ვხსნით 1C: Trade Management 11-ში დამუშავებას "მონაცემთა უნივერსალური გაცვლა XML ფორმატში" V8Exchan83.epf.

გადმოტვირთვა დასრულდა, ახლა იგივე დამუშავებით ვტვირთავთ 1C: Enterprise Accounting 3-ში.

ჩამოტვირთვა დასრულდა. მოდით შევამოწმოთ, რომ ის დატვირთულია. ასე რომ, დოკუმენტი იტვირთება, როგორც გვინდოდა - ჩვენ გვაქვს ორგანიზაცია ჩატვირთული კონტრაგენტში, ხოლო კონტრაგენტი ორგანიზაციაში. ყველა ანგარიშები გადმოწერილი და დაინსტალირებულია. ჩვენ მივიღეთ დოკუმენტის ნომერი ჩვენი პრეფიქსით და დღის დასაწყისში. ყველა დეტალი, რომელიც დარეგისტრირდა, შევსებულია.

ვამოწმებთ ნომენკლატურის დატვირთვას. ვხედავთ, რომ ყველაფერი ისე გამოვიდა, როგორც ვგეგმავდით.

ჩვენ შევქმენით და შევავსეთ დეტალები, როგორც გვინდოდა. კონვერტაციაში ბევრი დახვეწილობაა და რამდენიმე მარტივი, მაგრამ აუცილებელი რამ, რაც ხელს უწყობს კონვერტაციის ზუსტად დაწერას. და ეს საშუალებას გაძლევთ მინიმუმამდე დაიყვანოთ შეცდომები, არ გააფუჭოთ არსებული მონაცემები და მოიცილოთ ზედმეტი ნაგავი. ეს არის ერთ-ერთი უმარტივესი მაგალითი. თქვენ ასევე შეგიძლიათ გააკეთოთ ერთი ობიექტის გადაქცევა ბევრში, ან პირიქით, ბევრი - ერთში.

ახლა არის მონაცემთა კონვერტაცია 3, ის წყვეტს სხვა პრობლემებს. ამიტომ, კონვერტაცია 2 ასევე საჭიროა. წარმატებებს გისურვებთ ყველას სწავლაში და დაუფლებაში.

რა თქმა უნდა, თუ პროგრამისტი ხართ და ეს თქვენი მთავარი სამუშაოა, შეგიძლიათ თავად სცადოთ კონვერტაციის დაწერა. მაგრამ თუ არა, მაშინ უნდა დააფასოთ თქვენი დრო თქვენი საქმიანობის სფეროში და სთხოვოთ პროფესიონალებს შეასრულონ ეს დავალება.