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

ვერსია 1.3.8 არის 1.3 გამოცემის განვითარება "1C: ელექტრონული დოკუმენტების ბიბლიოთეკა 8", რომელიც შექმნილია ელექტრონული დოკუმენტების გაცვლის უზრუნველსაყოფად აპლიკაციის გადაწყვეტილებებში, რომლებიც შემუშავებულია 1C:Enterprise პლატფორმის ვერსიაზე 8.3.10.2252 და უფრო მაღალ ვერსიაზე.

ახალი ფუნქციები და ცვლილებები

სავაჭრო შეთავაზებების საძიებო ფორმაში დამატებულია ძებნის შესაძლებლობა 1C: Business Network სერვისთან დაკავშირების გარეშე და დამატებულია მომწოდებლის სახელით ძებნის შესაძლებლობა.
დამატებულია ანგარიში გამოქვეყნებული სავაჭრო შეთავაზებების შესახებ.
დამატებულია სამუშაო ადგილი 1C:Business Network სერვისში სავაჭრო შეთავაზებების გამოქვეყნებისთვის.
ადაპტაცია განხორციელდა ქვესისტემებით „1C: სტანდარტული ქვესისტემების ბიბლიოთეკა“ ვერსია 2.4.2, „1C: ინტერნეტ მომხმარებელთა მხარდაჭერის ბიბლიოთეკა“ ვერსია 2.2.2.

გადასვლა 1.3.8 ვერსიაზე 1.3.7 ვერსიიდან

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

მოდულის ცვლილებები:

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

ცვლილებები მოდულში სავაჭრო შეთავაზებები

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

როლი დაემატა ReportsTradingOffersსაჭიროა მოხსენებაში წვდომისათვის გამოქვეყნებული სავაჭრო შეთავაზებები.

ვერსია 1.3.7

ვერსია 1.3.7 არის 1.3 გამოცემის განვითარება "1C: ელექტრონული დოკუმენტების ბიბლიოთეკა 8", რომელიც შექმნილია ელექტრონული დოკუმენტების გაცვლის უზრუნველსაყოფად აპლიკაციის გადაწყვეტილებებში, რომლებიც შემუშავებულია 1C:Enterprise პლატფორმის 8.3.10 და უფრო მაღალ ვერსიაზე.

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

თავსებადობის რეჟიმი უნდა დაყენდეს „არ გამოიყენო“.
მოდალობის გამოყენების რეჟიმი შეიძლება დაყენდეს „არ გამოიყენო“.
ინტერფეისის თავსებადობის რეჟიმს შეუძლია მიიღოს მნიშვნელობები "Version 8.2", "Version 8.2. Allow Taxi" ან "Taxi. Allow Version 8.2".

ახალი ფუნქციები და ცვლილებები

დამატებულია Sberbank-ისგან გადახდის დოკუმენტის სტატუსის მიღების შესაძლებლობა.
განხორციელდა Sberbank-ისთვის პარამეტრების ავტომატური მიღება 1C:DirectBank სერვისთან დაკავშირებისას.
დამატებულია კონტექსტური რეკლამის ჩვენების შესაძლებლობა 1C:DirectBank.
ადაპტაცია განხორციელდა 1C: Business Network სერვისთან მუშაობისთვის 1CFresh ღრუბლოვან სერვისში.
დამატებულია სავაჭრო შეთავაზებების გამოქვეყნების, ძიების და შეკვეთის შესაძლებლობა 1C: Trade Offers სერვისში 1C: Business Network სერვისის მონაწილეებისთვის.
ადაპტაცია განხორციელდა ქვესისტემებით „1C: სტანდარტული ქვესისტემების ბიბლიოთეკა“ ვერსია 2.4.1, „1C: ინტერნეტ მომხმარებელთა მხარდაჭერის ბიბლიოთეკა“ ვერსია 2.1.9, „1C: სერვისის ტექნოლოგიების ბიბლიოთეკა“ ვერსია 1.0.12.

ქვესისტემა "გაცვლა კონტრაგენტებთან"

მოდულის ცვლილებები:

დოკუმენტის თარიღი, DocBaseDate

ქვესისტემა "გაცვლა ბანკებთან"

ცვლილებები მოდულში FilesOverridable-თან მუშაობა:

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

ElectronicInteraction.WhenDefiningSettings(Settings);

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

Electronic Interaction.FileStorage დირექტორიების განსაზღვრისას (FileOwnerType, DirectoryNames);

დირექტორიები MessageExchangeWithBanksAttachedFiles და EDAttachedFiles დაემატა გაცვლის გეგმას UpdateInformationBase
საქაღალდეები MessageExchangeWithBanksAttachedFiles და EDAttachedFiles დაემატა განსაზღვრულ ტიპს SignedObject.

კლიენტბანკი) ელემენტების ჯგუფის გადატანა ზოგადი ფორმიდან.

მოვლენის დამმუშავებლის ფორმაში როდესაც CreatedOnServer

&სერვერზე

…

პროცედურის დასასრული

მოვლენის დამმუშავებლის ფორმაში ProcessingAlerts

&OnClient

…
// ელექტრონული ურთიერთქმედება.გაცვლა ბანკებთან

Elements.GroupAdvertisingDirectBankHorizontally, Elements.TextDirectBankHorizontally);
// ელექტრონული ურთიერთქმედების დასრულება.გაცვლა ბანკებთან
პროცედურის დასასრული

ელემენტისთვის TextDirectBankHorizontallyმოვლენის დამმუშავებლის დამატება ნავიგაციის ბმულების დამუშავება

&OnClient

პროცედურის დასასრული

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

ქვესისტემა "საიტებთან გაცვლა"

ცვლილებები მოდულში საიტის ExchangeOverridable:

დამატებულია პროცედურა დაამატეთ DetailsFormNode, გამოიყენება გაცვლის გეგმის კვანძში დეტალების დასამატებლად საიტთან გაცვლის სახით. გაცვლის კვანძის ფორმა არ ითვალისწინებს აპლიკაციის გადაწყვეტასთან დაკავშირებული დეტალების არსებობას; დეტალები ემატება პროგრამულად.
დამატებულია პროცედურა შეიტანეთ FieldWhenChangedOnServer, გამოიყენება ჩრდილოეთში მოვლენის დასამუშავებლად, როდესაც იცვლება გაცვლის გეგმის კვანძის ფორმის შეყვანის ველი, დაემატება Add NodeFormDetails პროცედურაში.
დამატებულია პროცედურა CheckboxFieldWhenChangedOnServer, გამოიყენება სერვერზე მოვლენის დასამუშავებლად, როდესაც იცვლება გაცვლის გეგმის კვანძის ფორმის დროშის ველი, რომელიც დამატებულია Add NodeFormDetails პროცედურაში.
დამატებულია პროცედურა WhenCreatingOnServerFormCreateSite, გამოიყენება CreateSite დამუშავების ფორმაში დეტალების დასამატებლად.

ცვლილებები მოდულში ExchangeSiteClientOverridable:

ამოღებულია პროცედურა განსაზღვრეთ GroupTableU კატალოგის ტიპიპროდუქტების კატალოგის ცხრილის Groups სვეტის მნიშვნელობის ტიპი განისაზღვრება გაცვლის პარამეტრებით.
დამატებულია პროცედურა InputFieldOnChange, გამოიძახება მოვლენის დასამუშავებლად, როდესაც იცვლება გაცვლის გეგმის კვანძის ფორმის შეყვანის ველი, რომელიც დაემატება SiteExchangeOverridden.AddNodeFormDetails პროცედურას.
დამატებულია პროცედურა CheckboxFieldOnChange, გამოიძახება მოვლენის დასამუშავებლად, როდესაც SiteExchangeOverridden.AddNodeFormDetails-ის პროცედურაში დამატებული გაცვლის გეგმის კვანძის ფორმის დროშის ველი იცვლება.
დამატებულია პროცედურა TableFormBeforeFinishEditing, მოწოდებულია SiteExchangeOverridden.AddNodeFormDetails-ის პროცედურაში დამატებული გაცვლის გეგმის კვანძის ფორმის ტაბულურ ნაწილში ველის BeforeFinishEdit მოვლენის დასამუშავებლად.

ქვესისტემა "ბიზნეს ქსელი"

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

// ელექტრონული ურთიერთქმედება
ElectronicInteraction.OnReceivingListTemplates(TaskTemplates);

პროცედურაში Aliases Handlers-ის განსაზღვრისას:

// ელექტრონული ურთიერთქმედება
ElectronicInteraction.WhenDefiningHandlerAliases(MatchNamesAliases);
// ელექტრონული ურთიერთქმედების დასრულება

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

ქვესისტემა "სავაჭრო შეთავაზებები"

დამატებულია ახალი ქვესისტემა "სავაჭრო შეთავაზებები", ჩაშენებისთვის საჭიროა:

შეიმუშავეთ გადაჭარბებული მეთოდები საერთო მოდულებში TradeOffersClientOverridable, TradeOffersOverridable.
მიუთითეთ მონაცემთა ტიპები განსაზღვრულ ტიპებში დეტალების ღირებულებების ტიპები 1СBusinessNetwork, სახეები ნომენკლატურა BED, დამატებითი დეტალებიBED, სავაჭრო შეთავაზება.

იხილეთ ჩაშენების დოკუმენტაცია დეტალებისთვის.

ვერსია 1.3.6

ვერსია 1.3.6 არის 1.3 გამოცემის განვითარება "1C: ელექტრონული დოკუმენტების ბიბლიოთეკა 8", რომელიც შექმნილია ელექტრონული დოკუმენტების გაცვლის უზრუნველსაყოფად აპლიკაციის გადაწყვეტილებებში, რომლებიც შემუშავებულია 1C:Enterprise პლატფორმაზე 8.3.8 და უფრო მაღალ ვერსიაზე. ამ შემთხვევაში, კონფიგურაციის თვისება "თავსებადობის რეჟიმი" უნდა დაყენდეს "ვერსია 8.3.8".

ეს კონფიგურაცია განკუთვნილია ერთობლივი გამოყენებისათვის კონფიგურაციასთან "1C: სტანდარტული ქვესისტემების ბიბლიოთეკა" არანაკლებ 2.3.4.112 ვერსიისა, კონფიგურაციით "1C: ბიბლიოთეკა ინტერნეტის მომხმარებელთა მხარდაჭერის 8" არანაკლებ 2.1.9.4 ვერსიაზე.

ახალი ფუნქციები და ცვლილებები

პირველადი ინვოისის დოკუმენტების ფორმატები მხარდაჭერილია (ცალკე პირველადი დოკუმენტის, ინვოისის გადაცემის თვალსაზრისით) ფედერალური საგადასახადო სამსახურის 2016 წლის 24 მარტის № ММВ-7-15/155@ ბრძანების შესაბამისად „დამტკიცების შესახებ ქ. ინვოისის ფორმატი და დოკუმენტის წარმოდგენის ფორმატი საქონლის გადაზიდვაზე (სამუშაოს შესრულებაზე), საკუთრების უფლების გადაცემაზე (მომსახურების გაწევის დოკუმენტი), ინვოისის ჩათვლით, ელექტრონული ფორმით.“.
ღირებულების ცვლილების შესახებ პირველადი დოკუმენტების ფორმატები, მათ შორის კორექტირების ინვოისი, მხარდაჭერილია (ცალკე პირველადი დოკუმენტის, კორექტირების ინვოისის გადაცემის თვალსაზრისით) ფედერალური საგადასახადო სამსახურის 2016 წლის 13 აპრილის N MMV ბრძანების შესაბამისად. -7-15/189@ "კორექტირების ინვოისის ფორმატის დამტკიცების შესახებ და დოკუმენტის წარდგენის ფორმატი გადაგზავნილი საქონლის ღირებულებაში ცვლილებების შესახებ (შესრულებული სამუშაო, გაწეული მომსახურება), გადაცემული საკუთრების უფლებები, კორექტირების ინვოისის ჩათვლით, ქ. ელექტრონული ფორმა."
დაემატა ახალი ელექტრონული დოკუმენტები: საქონლის გადაცემა, სამუშაოს შედეგების გადაცემა, დოკუმენტების ვიზუალური წარმოდგენის ახალი ფორმა.
დამატებულია ცალმხრივი გაცვლის მექანიზმი, რომელიც არ საჭიროებს შეტყობინებას მიმღების მიღების შესახებ.
დამატებულია შემომავალი ელექტრონული დოკუმენტების შეფუთვის (ავტომატურად ან ხელით) კონტროლის შესაძლებლობა, ელექტრონული დოკუმენტების მიღებისას კონკრეტული ტიპის დოკუმენტის შექმნის კონფიგურაციის შესაძლებლობა.
დაემატა ელექტრონული დოკუმენტის რამდენიმე საინფორმაციო ბაზის საბუღალტრო დოკუმენტთან დაკავშირების შესაძლებლობა.
განხორციელდა ელექტრონული დოკუმენტების დაყოფა შემოსულ და გამავალზე.
სერვისთან ინტეგრაცია განხორციელდა 1C-UMIსაშუალებას გაძლევთ შექმნათ ვებსაიტები პროგრამიდან, მოაწყოთ გაცვლა ონლაინ მაღაზიასთან UMI.
ადაპტაცია გაკეთდა 1C-EDO სერვისთან მუშაობისთვის 1CFresh ღრუბლოვან სერვისში.

გადასვლა 1.3.6 ვერსიაზე 1.3.5 ვერსიიდან

ქვესისტემა "გაცვლა კონტრაგენტებთან"

ზოგადი მოდული ExchangewithCounterparties ხელახლა განსაზღვრებადი

დამატებულია მეთოდი UPD SCHFDOP.
დამატებული მეთოდი შეავსეთ UPD მყიდველის ინფორმაციის ფედერალური საგადასახადო სამსახურის მონაცემები. მეთოდი ამზადებს მონაცემებს UPD (მყიდველის ინფორმაცია) ტიპის SCHFDOP ფუნქციის ელექტრონული დოკუმენტისთვის.
დაემატა UPD მეთოდის (გამყიდველის ინფორმაცია) ფუნქცია SCHFDOP ინფორმაციული უსაფრთხოების ობიექტებს.
დამატებული მეთოდი შეავსეთ მონაცემები გამყიდველის ფედერალური საგადასახადო სამსახურის დამატებითი ინფორმაციისთვის. მეთოდი ამზადებს მონაცემებს ელექტრონული დოკუმენტისთვის, როგორიცაა STD (გამყიდველის ინფორმაცია) DOP ფუნქცია.
დამატებული მეთოდი FindCreate UPDT DocumentAboutTransfer. მეთოდი ინახავს მონაცემებს ელექტრონული დოკუმენტის UPD (გამყიდველის ინფორმაცია) ფუნქციიდან DOP IS ობიექტში.
დამატებული მეთოდი შეავსეთ მონაცემები SCHFISeller-ის ინფორმაციის ფედერალური საგადასახადო სამსახურისთვის. მეთოდი ამზადებს მონაცემებს UTD (გამყიდველის ინფორმაცია) ტიპის SSF ფუნქციის ელექტრონული დოკუმენტისთვის.
დამატებული მეთოდი FindCreateUPDSInvoiceInvoice. მეთოდი ინახავს მონაცემებს ელექტრონული დოკუმენტის UPD (გამყიდველის ინფორმაცია) SSF ფუნქციიდან ინფორმაციის უსაფრთხოების ობიექტში.
დამატებული მეთოდი. მეთოდი ამზადებს მონაცემებს UCD ტიპის (გამყიდველის ინფორმაცია) KSCHFDIS ფუნქციის ელექტრონული დოკუმენტისთვის.
დამატებული მეთოდი შეავსეთ მონაცემები UKID მყიდველის ინფორმაციის ფედერალური საგადასახადო სამსახურისთვის. მეთოდი ამზადებს მონაცემებს UKD (მყიდველის ინფორმაცია) ტიპის KSCHFDIS ფუნქციის ელექტრონული დოკუმენტისთვის.
დამატებული მეთოდი. მეთოდი ინახავს მონაცემებს ელექტრონული დოკუმენტიდან UCD (გამყიდველის ინფორმაცია) ფუნქციიდან KSCHFDIS ინფორმაციული უსაფრთხოების ობიექტებში.
დამატებული მეთოდი შეავსეთ მონაცემები გამყიდველის ფედერალური საგადასახადო სამსახურის დეინფორმაციისთვის. მეთოდი ამზადებს მონაცემებს UCD ტიპის (გამყიდველის ინფორმაცია) DIS ფუნქციის ელექტრონული დოკუმენტისთვის.
დამატებული მეთოდი FindCreateUKDDocumentAboutChangeValue. მეთოდი ინახავს მონაცემებს ელექტრონული დოკუმენტიდან UCD (გამყიდველის ინფორმაცია) ფუნქციიდან DIS IS ობიექტში.
დამატებული მეთოდი შეავსეთ მონაცემები KSCHFISeller-ის ინფორმაციის ფედერალური საგადასახადო სამსახურისთვის. მეთოდი ამზადებს მონაცემებს UCD ტიპის (გამყიდველის ინფორმაცია) KSCHF ფუნქციის ელექტრონული დოკუმენტისთვის.
დამატებული მეთოდი FindCreateUKDSAccountInvoice. მეთოდი ინახავს მონაცემებს ელექტრონული დოკუმენტიდან UCD (გამყიდველის ინფორმაცია) ფუნქციიდან KSCHF ინფორმაციული უსაფრთხოების ობიექტში.
დამატებული მეთოდი ED-ის გამავალი ტიპების შესაბამისობა ინფორმაციული უსაფრთხოების დოკუმენტებთან. მეთოდი აყალიბებს შესაბამისობას გამავალ ელექტრონულ დოკუმენტებსა და ინფორმაციული უსაფრთხოების დოკუმენტებს შორის.
დამატებული მეთოდი FindCreateDocumentTransferWorkResults. მეთოდი გამოიყენება „საქონლის გადაცემის“ ფორმატში მიღებული ზედნადების დოკუმენტის შესავსებად.
დამატებული მეთოდი FindCreateDocument საქონლის გადაცემა. მეთოდი გამოიყენება „სამუშაო შედეგების გადაცემის“ ფორმატში მიღებული დოკუმენტის მომსახურების გაწევის სერტიფიკატის შესავსებად.
დამატებული მეთოდი InstalledStateExchange დასრულდა. მეთოდი იწოდება, როდესაც დოკუმენტის ნაკადის მდგომარეობა იცვლება გაცვლა დასრულებულია, გაცვლა დასრულებულია შესწორებით.
ელექტრონული დოკუმენტების გენერირებისას UPD, UKD, საქონლის გადაცემა, სამუშაოს შედეგების გადაცემა, დეტალები დოკუმენტის თარიღი, DocBaseDateსაჭიროა შევსება.

დამუშავება გაცვლა კონტრაგენტებთან

"Torg-12Seller" განლაგებაში:

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

განლაგებაში უფლებათა გადაცემის აქტი:

დამატებულია ცხრილის ნაწილი "ბაზა".
ველები "DocumentBaseName", "DocumentBaseNumber", "DocumentBaseDate", "DocumentBaseAdditionalInformation" ამოღებულია.
დაემატა ველი "CurrencyName".
დამატებულია ველი "პრეტენზიები".
დაემატა ველი "აღსრულების თარიღი".
ტრანზაქციის მონაწილეთა თვისებებში „ფაქსის“ ველი შეიცვალა „ელ.ფოსტის“ ველით.
ტრანზაქციის მონაწილეთა თვისებებში „ქვეყნის კოდის“ ველი შეიცვალა „ქვეყნის კოდის“ ველით.
ტრანზაქციის მონაწილეთა თვისებებში „AddressText“ ველი შეიცვალა „AddressText“ ველით.

განსაზღვრული ტიპის განახლება კონტრაპარტიული:

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

განახლების პროცედურა:

დაარქვით განსაზღვრული ტიპის Account AccountBED.
ამოიღეთ კონფიგურაცია საყრდენი BED 1.3.5.
განახორციელეთ შედარება/შერწყმა BED 1.3.5 კონფიგურაციასთან, დაეთანხმეთ კონფიგურაციის მხარდაჭერას.
მოხსენით ყველა ობიექტი და დატოვეთ მხოლოდ განსაზღვრული ანგარიშის ტიპი, შეასრულეთ შერწყმა.
დაიწყეთ კონფიგურაციის განახლება, აირჩიეთ BED ფაილი 1.3.6.
აირჩიეთ ველები განსაზღვრულ ტიპებზე AccountBED და Account. მიუთითეთ მონაცემთა ბაზის სხვა საჭირო ობიექტები განახლებისთვის.
განახორციელეთ განახლება.

ქვესისტემა "გაცვლა ბანკებთან"

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

ქვესისტემა "საიტებთან გაცვლა"

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

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

დამატებულია საცნობარო წიგნი ვებსაიტები:

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

დამატებულია დამუშავება შექმენით ვებგვერდი:

დამატებულია საიტის შექმნის შესაძლებლობა 1C-UMI დომენში; საიტი იქმნება ავტომატურად (Sites ელემენტი) და ივსება მონაცემებით 1C. ExchangeSite გაცვლის კვანძი ავტომატურად იქმნება და პირველი სრული გაცვლა საიტთან შესრულდება.

ზოგადი მოდული საიტის ExchangeOverridable:

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

ზოგადი მოდული ExchangeSiteEvents:

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

სხვა ცვლილებები

ქვესისტემის დაყენება ტარიფის მართვაბიბლიოთეკის მომსახურების მოდელში მომსახურების ტექნოლოგიები

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

// ელექტრონული ურთიერთქმედება
ელექტრონული ურთიერთქმედება.მომსახურებების სიის ფორმირებისას (მომსახურების პროვაიდერები);
// ელექტრონული ურთიერთქმედების დასრულება

ვერსია 1.3.5

ვერსია 1.3.5 არის "1C: Electronic Document Libraries 8" 1.3 გამოცემის განვითარება, რომელიც შექმნილია ელექტრონული დოკუმენტების გაცვლის უზრუნველსაყოფად აპლიკაციის გადაწყვეტილებებში, რომლებიც შემუშავებულია 1C:Enterprise პლატფორმის 8.3.8 და უფრო მაღალ ვერსიაზე.

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

თავსებადობის რეჟიმი უნდა დაყენდეს „არ გამოიყენო“.
მოდალობის გამოყენების რეჟიმი შეიძლება დაყენდეს „არ გამოიყენო“.
ინტერფეისის თავსებადობის რეჟიმს შეუძლია მიიღოს მნიშვნელობები "Version 8.2", "Version 8.2. Allow Taxi" ან "Taxi. Allow Version 8.2".

ახალი ფუნქციები და ცვლილებები

ბიბლიოთეკის ფუნქციონალობა ადაპტირებული იყო 8.3.8 პლატფორმაზე მუშაობის სპეციფიკურ მახასიათებლებთან თავსებადობის რეჟიმის გამორთვით;
"სტანდარტული ქვესისტემების ბიბლიოთეკის" ქვესისტემები განახლდა 2.3.3.45 ვერსიამდე;
ბიბლიოთეკა მოიცავს ქვესისტემას „ინტერნეტ მომხმარებელთა მხარდაჭერის ბიბლიოთეკები“, ვერსია 2.1.8.3.

გადასვლა 1.3.5 ვერსიაზე 1.3.4 ვერსიიდან

ცვლილებები არ არის საჭირო.

ვერსია 1.3.4

ვერსია 1.3.4 არის "1C: Electronic Document Libraries 8" 1.3 გამოცემის განვითარება, რომელიც შექმნილია ელექტრონული დოკუმენტების გაცვლის უზრუნველსაყოფად აპლიკაციის გადაწყვეტილებებში, რომლებიც შემუშავებულია 1C:Enterprise პლატფორმაზე 8.3.6 და უფრო მაღალ ვერსიაზე. ამ შემთხვევაში, კონფიგურაციის თვისება "თავსებადობის რეჟიმი" უნდა იყოს მითითებული "არ გამოიყენო". მოდალობის გამოყენების რეჟიმი შეიძლება დაყენდეს „არ გამოიყენო“, ხოლო ინტერფეისის თავსებადობის რეჟიმი შეიძლება დაყენდეს „ვერსია 8.2“, „ვერსია 8.2. ტაქსის დაშვება“ ან „ტაქსი. ნებადართული ვერსია 8.2“.

ახალი ფუნქციები და ცვლილებები

დანერგილია EDI ღონისძიებების შესახებ შეტყობინებების სისტემა (ახალი ელექტრონული დოკუმენტები, ახალი მოსაწვევები, სერტიფიკატის ვადის გასვლა და ა.შ.). ახლა უკვე შესაძლებელია ელ.ფოსტის შეტყობინებების კონფიგურაცია EDF პარამეტრების პროფილში, ასევე მოვლენების შესახებ შეტყობინებების ჩვენება პირდაპირ 1C პროგრამაში pop-up შეტყობინებების გამოყენებით;
მხარდაჭერილია პირველადი დოკუმენტის ფორმატი, მათ შორის ინვოისი (UPD ფორმატი) ფედერალური საგადასახადო სამსახურის 2016 წლის 24 მარტის ბრძანების შესაბამისად No ММВ-7-15/155@ „ინვოისის ფორმატის დამტკიცების შესახებ და საქონლის გადაზიდვის (სამუშაოს შესრულების), საკუთრების უფლების გადაცემის (დოკუმენტი მომსახურების გაწევის შესახებ) დოკუმენტის ელექტრონული ფორმით წარდგენის ფორმატი“;
ღირებულების ცვლილების შესახებ დოკუმენტის ფორმატი, რომელიც მოიცავს კორექტირების ანგარიშ-ფაქტურას, მხარდაჭერილია“ (UKD ფორმატი) ფედერალური საგადასახადო სამსახურის 04/13/2016 N ММВ-7-15/189@ ბრძანების შესაბამისად. „გაგზავნილი საქონლის (შესრულებული სამუშაო, გაწეული მომსახურება), გადაცემული ქონებრივი უფლებების, მათ შორის კორექტირების ინვოისის, ელექტრონულად გადაგზავნილი საქონლის ღირებულების ცვლილებების შესახებ კორექტირების ინვოისის ფორმატის და წარდგენის ფორმატის დოკუმენტის დამტკიცების შესახებ“;
მხარი დაუჭირა გარე კომპონენტების გამოყენებას ბანკებთან სანაცვლოდ DirectBank ტექნოლოგიის გამოყენებით.

გადასვლა 1.3.4 ვერსიაზე 1.3.2, 1.3.3 ვერსიებიდან

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

დოკუმენტების სიის ფორმებში, თქვენ უნდა დაამატოთ დანამატის პროცედურა გაცვლა CounterpartiesClient-თან.Waiting ProcessorEDW:

&OnClient

პროცედურის დასასრული

ქვესისტემის განახლებისას, დოკუმენტების სიის ფორმის მოვლენების დამმუშავებლებში აუცილებელია: როდესაც CreatedOnServer, გახსნისას, ProcessingAlerts

&სერვერზე
პროცედურა სერვერზე შექმნისას
…
ParametersWhenCreatedOnServer = ExchangeWithCounterparties.ParametersWhenCreatedOnServer_ListForm();
ParametersWhenCreatedOnServer.Form = ThisObject;
ParametersWhenCreatedOnServer.LocationofCommands = Elements.EDO ბრძანებები;
ExchangewithCounterparties.WhenCreatedOnServer_ListForm(Failure, StandardProcessing, ParametersWhenCreatedOnServer);
პროცედურის დასასრული

&OnClient
გახსნის პროცედურა (მარცხი)
…
// ქვესისტემა „გაცვლა კონტრაგენტებთან“.
// „კონტრაქტორის გაცვლის“ ქვესისტემის დასასრული.
პროცედურის დასასრული

&OnClient
პროცედურის პროცესის შეტყობინებები (მოვლენის სახელი, პარამეტრი, წყარო)
…
// ქვესისტემა „გაცვლა კონტრაგენტებთან“.
Alert ParametersEDO = გაცვლა CounterpartiesClient.AlertParametersEDO_ListForm();
EDO Notification Parameters.Form = ThisObject;
EDO Notification Parameters.DynamicListName = "List";
ExchangewithCounterpartiesClient.ProcessingAlert_ListForm(EventName, Parameter, Source, EDI AlertParameters);
// „კონტრაქტორის გაცვლის“ ქვესისტემის დასასრული.
პროცედურის დასასრული

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

დოკუმენტის ფორმებში თქვენ უნდა დაამატოთ დანამატის პროცედურა Connectable_WaitingHandlerEDO, სადაც უნდა განათავსოთ მეთოდის ზარი

გაცვლა CounterpartiesClient-თან. Waiting ProcessorEDW:

&OnClient
პროცედურა Connectable_EDOWaitingHandler()
ExchangeCounterpartiesClient.EDOWaitingHandler(ThisObject);
პროცედურის დასასრული

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

ქვესისტემის განახლებისას აუცილებელია დოკუმენტის ფორმის ღონისძიების დამმუშავებლები როდესაც CreatedOnServer, გახსნისას, AfterRecordingOnServer, ProcessingAlertsადგილის მეთოდები "კონტრაგედიის გაცვლის" ქვესისტემა.

Მაგალითად:

&სერვერზე

…
// ქვესისტემა „გაცვლა კონტრაგენტებთან“.
EDO პარამეტრები როდესაც შეიქმნა = გაცვლა კონტრაქტებთან პარამეტრები როცა შეიქმნა Server_DocumentForm();
EDO პარამეტრები როდესაც შეიქმნა.Form = ThisObject;
EDO პარამეტრები როდესაც შეიქმნა.DocumentLink = Object.Link;
EDO პარამეტრები როდესაც შეიქმნა.DecorationStateEDO = Elements.DecorationStateEDO;
EDO პარამეტრები როდესაც შეიქმნა.EDO State Group = Elements.EDO State Group;
გაცვლა Counterparties.When CreatedOn the Server_DocumentForm(Refusal, StandardProcessing, EDO ParametersWhen Created);
// „კონტრაქტორის გაცვლის“ ქვესისტემის დასასრული.
პროცედურის დასასრული

&OnClient
გახსნის პროცედურა (მარცხი)
…
// ქვესისტემა "გაცვლა კონტრაგენტებთან"
ExchangeWithCounterpartiesClient.OnOpening(ThisObject);
// ქვესისტემის დასრულება "გაცვლა კონტრაგენტებთან"
პროცედურის დასასრული

&სერვერზე
პროცედურა RecordOnServer-ის შემდეგ (CurrentObject, RecordParameters)
…
// ქვესისტემა „გაცვლა კონტრაგენტებთან“.
ParametersAfterRecord = ExchangeWithCounterparties.ParametersAfterRecordOnServer();
ParametersAfterRecord.Form = ThisObject;
ParametersAfterRecord.DocumentLink = Object.Link;
ParametersAfterRecording.DecorationStateEDO = Elements.DecorationStateEDO;
ParametersAfterRecord.GroupEDOState = Elements.GroupEDOState;
ExchangewithCounterparties.AfterRecordOnServer(CurrentObject, RecordParameters,AfterRecordParameters);
// „კონტრაქტორის გაცვლის“ ქვესისტემის დასასრული.
პროცედურის დასასრული

&OnClient
პროცედურის პროცესის შეტყობინებები (მოვლენის სახელი, პარამეტრი, წყარო)
…
// ქვესისტემა „გაცვლა კონტრაგენტებთან“.
Alert Parameters = ExchangewithCounterpartiesClient.AlertParametersEDO_DocumentForm();
AlertParameters.Form = ThisObject;
AlertParameters.DocumentLink = Object.Link;
AlertParameters.DecorationEDOState = Elements.DecorationEDOState;
Alert Parameters.EDO State Group = Elements.EDO State Group;
ExchangeWithCounterpartiesClient.ProcessingAlert_DocumentForm(EventName, Parameter, Source, AlertParameters);
// „კონტრაქტორის გაცვლის“ ქვესისტემის დასასრული.
პროცედურის დასასრული

ცვლილებები ExchangeCounterparties მოდულში

დამატებულია პროცედურა როდესაც CreatedOnServer_ListForm, გამოძახებული დოკუმენტების სიის ფორმის "When CreatedOnServer" მოვლენის დამმუშავებლისგან. როგორც მეთოდის მესამე პარამეტრი, გადაეცემა სტრუქტურა, რომელიც ინიციალიზებულია მეთოდით ParametersWhenCreatingOnServer_ListForm.
დამატებულია პროცედურა როდესაც CreatedOnServer_FormDocument, გამოძახებული დოკუმენტის ფორმის "When CreatedOnServer" მოვლენის დამმუშავებლისგან. როგორც მეთოდის მესამე პარამეტრი, გადაეცემა სტრუქტურა, რომელიც ინიციალიზებულია მეთოდით ParametersWhenCreatingOnServer_DocumentForm.
დამატებულია პროცედურა AfterRecordingOnServer, გამოძახებული დოკუმენტის ფორმის "AfterRecordOnServer" მოვლენის დამმუშავებლისგან. როგორც მეთოდის მესამე პარამეტრი, გადაეცემა სტრუქტურა, რომელიც ინიციალიზებულია მეთოდით ParametersAfterRecordingOnServer.

ცვლილებები მოდულში გაცვლა CounterpartiesClient-თან.

დამატებულია პროცედურა გახსნისას, გამოძახებული დოკუმენტების სიის ფორმისა და დოკუმენტის ფორმის "On Opening" ღონისძიების დამმუშავებლისგან.
დამატებულია პროცედურა ProcessingAlerts_ListForm, გამოძახებული დოკუმენტების სიის ფორმის „შეტყობინებების დამუშავების“ ღონისძიების დამმუშავებლისგან. როგორც მეთოდის მეოთხე პარამეტრი, გადაეცემა სტრუქტურა, რომელიც ინიციალიზებულია მეთოდით Alert ParametersEDO_ListForm.
დამატებულია პროცედურა ProcessingAlert_FormDocument, გამოძახებული დოკუმენტის ფორმის "შეტყობინებების დამუშავების" მოვლენის დამმუშავებლისგან. როგორც მეთოდის მეოთხე პარამეტრი, გადაეცემა სტრუქტურა, რომელიც ინიციალიზებულია მეთოდით შეტყობინების ParametersEDO_DocumentForm.
ცვლილებები მოდულში ExchangewithCounterparties Overridable:
დამატებული მეთოდი შეავსეთ სამუშაოს შემსრულებლის მონაცემთა გადაცემა.
მაგალითი:

// ამზადებს მონაცემებს ელექტრონული დოკუმენტის ტიპის საქონლის გადაცემა გამყიდველზე.
// Პარამეტრები:
// LinkToObject - ბმული ED-სთან, რომლითაც აუცილებელია ელექტრონული დოკუმენტის გენერირება,

პროცედურის შევსება მონაცემთა გადაცემის სამუშაო შემსრულებელი (ობიექტის ბმული, ED სტრუქტურა, მონაცემთა ხე) ექსპორტი
შეავსეთ ფედერალური საგადასახადო სამსახურის აღმასრულებელი აქტის 501 მონაცემები (ობიექტის ბმული, ED სტრუქტურა, მონაცემთა ხე)
პროცედურის დასასრული

მეთოდი CheckAbility toEditObjectპროცედურად იქცა.
დამატებული მეთოდი შეავსეთ მონაცემები გამყიდველის ფედერალური საგადასახადო სამსახურის UPD ინფორმაციისთვის. მეთოდი ამზადებს მონაცემებს ამ ტიპის ელექტრონული დოკუმენტისთვის UPD(გამყიდველის ინფორმაცია) ფუნქცია SCHFDOP.
დამატებული მეთოდი FindCreateUniversalTransferDocument. მეთოდი ინახავს მონაცემებს ელექტრონული დოკუმენტიდან UPD(გამყიდველის ინფორმაცია) ფუნქცია SCHFDOPv IS ობიექტები.
დამატებული მეთოდი შეავსეთ მონაცემები UKDI გამყიდველის ინფორმაციის ფედერალური საგადასახადო სამსახურისთვის. მეთოდი ამზადებს მონაცემებს ამ ტიპის ელექტრონული დოკუმენტისთვის UKD(გამყიდველის ინფორმაცია) ფუნქცია KSCHFDIS.
დამატებული მეთოდი FindCreateUniversalAdjustmentDocument. მეთოდი ინახავს მონაცემებს ელექტრონული დოკუმენტიდან UKD(გამყიდველის ინფორმაცია) ფუნქცია KSCHFDISინფორმაციის უსაფრთხოების ობიექტებზე.

ცვლილებები „ბანკებთან გაცვლა“ ქვესისტემაში

ცვლილებები მოდულში ExchangeWithBanksRedefinable

Პროცედურა როდესაც ED მდგომარეობა იცვლებადაემატა. გამოიძახება, როდესაც ელექტრონული დოკუმენტის ნაკადის მდგომარეობა იცვლება.

ცვლილებები მომსახურების რეჟიმში მუშაობისთვის

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

პროცედურაში GetProvidedDataHandlers საერთო მოდულის SuppliedDataOverridden, დაამატეთ შემდეგი კოდი:

ElectronicInteraction.RegisterDeliveredDataHandlers(Handlers);

დაამატეთ რუტინული დავალება განახლება გარე მოდულების გაცვლა ბანკებთან ზოგად ატრიბუტზე Data Area Basic Data.

სხვა ცვლილებები

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

ვერსია 1.3.3

ვერსია 1.3.3 არის პროდუქტის 1.3 გამოცემის განვითარება "1C: ელექტრონული დოკუმენტების ბიბლიოთეკა". შექმნილია კონფიგურაციების შემუშავებისთვის, რომლებიც შექმნილია 1C:Enterprise პლატფორმაზე 8.3 ვერსია 8.3.6 და უფრო მაღალი სამუშაოებისთვის.

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

თავსებადობის რეჟიმი უნდა დაყენდეს „არ გამოიყენო“.
მოდალობის გამოყენების რეჟიმი შეიძლება დაყენდეს „არ გამოიყენო“.
ინტერფეისის თავსებადობის რეჟიმს შეუძლია მიიღოს მნიშვნელობები "Version 8.2", "Version 8.2. Allow Taxi" ან "Taxi. Allow Version 8.2".

ახალი ფუნქციები და ცვლილებები

2015 წლის 30 ნოემბრის No ММВ-7-10/551@ ბრძანებით „სავაჭრო ოპერაციების დროს საქონლის ელექტრონული ფორმით გადაცემის შესახებ დოკუმენტის წარდგენის ფორმატის დამტკიცების შესახებ“ და 2015 წლის 30 ნოემბრის No. ММВ-7-10/552@ „სამუშაო შედეგების (მომსახურების მიწოდების დოკუმენტი) ელექტრონული ფორმით გადაცემის შესახებ დოკუმენტის წარდგენის ფორმატის დამტკიცების შესახებ“ მხარდაჭერილია ელექტრონული დოკუმენტების ახალი ფორმატები.

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

მოდულში ExchangewithCounterparties Overridableგააკეთე ცვლილება:

// ამზადებს მონაცემებს ზედნადების ტიპის ელექტრონული დოკუმენტისთვის.
// Პარამეტრები:
// LinkOnED - ბმული ED-სთან, რომლითაც აუცილებელია ელექტრონული დოკუმენტის გენერირება,
// StructureED - სტრუქტურა, მონაცემთა სტრუქტურა ელექტრონული დოკუმენტის გენერირებისთვის.
// მონაცემთა ხე - სიდიდეების ხე, მონაცემთა ხე ელექტრონული დოკუმენტის შევსებისთვის.
საქონლის გამყიდველის მონაცემთა გადაცემის შევსების პროცედურა (ობიექტის ბმული, ED სტრუქტურა, მონაცემთა ხე) ექსპორტი
შეავსეთ მონაცემები ვაჭრობის შესახებ 12 ფედერალური საგადასახადო სამსახურის გამყიდველი (ობიექტის ბმული, ED სტრუქტურა, მონაცემთა ხე)
პროცედურის დასასრული

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

ვერსია 1.3.2

ვერსია 1.3.2 არის პროდუქტის 1.3 გამოცემის განვითარება "1C: ელექტრონული დოკუმენტების ბიბლიოთეკა". შექმნილია კონფიგურაციების შემუშავებისთვის, რომლებიც შექმნილია 1C:Enterprise პლატფორმაზე 8.3 ვერსია 8.3.6 და უფრო მაღალი სამუშაოებისთვის.

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

თავსებადობის რეჟიმი უნდა დაყენდეს „არ გამოიყენო“.
მოდალობის გამოყენების რეჟიმი შეიძლება დაყენდეს „არ გამოიყენო“.
ინტერფეისის თავსებადობის რეჟიმს შეუძლია მიიღოს მნიშვნელობები "Version 8.2", "Version 8.2. Allow Taxi" ან "Taxi. Allow Version 8.2".

ახალი ფუნქციები და ცვლილებები

ელექტრონული დოკუმენტის 2 დასახელების (TORG12, Act, Adjustment document) დანერგილი ჩვენება ერთი ფორმით ელექტრონული დოკუმენტის სანახავად. ყველა ინფორმაცია სათაურებიდან შეგროვდება ერთ ფორმაში. ცალკე მეორე სათაურის ფორმა შეგიძლიათ იხილოთ „ელექტრონული დოკუმენტების“ ფორმიდან;
განხორციელდა სტანდარტული "EDA ხელშეკრულების" ელექტრონული ფორმით დადების შესაძლებლობა 1C პროგრამაში "EDF პარამეტრებიდან"; ბრძანების „გენერირება ხელშეკრულების შაბლონის გამოყენებით“ გამოყენებით ავტომატურად შეიქმნება თვითნებური ელექტრონული დოკუმენტი, რომლის დანართი იქნება ხელშეკრულების ფაილი. ხელმოწერის შემდეგ, დოკუმენტი შეიძლება დაუყოვნებლივ გადაეგზავნოს კონტრაგენტს.
თვითნებური ელექტრონული დოკუმენტების ინტეგრირებული გაცვლა თანდართული ფაილებით. ახლა ნებისმიერი თანდართული ფაილი შეიძლება სწრაფად მოაწეროს ხელი და გაიგზავნოს კონტრაგენტს ნებისმიერი ელექტრონული დოკუმენტის გამოყენებით;
ხელფასების პროექტზე ბანკთან ელექტრონული დოკუმენტების გაცვლის შესაძლებლობა;
დაამატა ასისტენტი ორგანიზაციის DirectBank-თან დასაკავშირებლად;
ინტერნეტის საშუალებით განახლდა იმ ბანკების სია, რომლებიც მხარს უჭერდნენ DirectBank-ს;
მხარდაჭერილი მუშაობა Sberbank-ის სხვადასხვა ტიპის ჟეტონებთან (ელექტრონულ გასაღებებთან): „ჩვეულებრივი“, „შეხება“, „ეკრანით“.
"სტანდარტული ქვესისტემის ბიბლიოთეკის" (BSS) ქვესისტემები განახლდა 2.3.2.27 ვერსიამდე.

გადასვლა 1.3.2.19 ვერსიაზე 1.2.7, 1.3.1 ვერსიებიდან

თქვენ უნდა დაამატოთ პროცედურა მოდულში ჩასმის გარეშე:

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

მოდულში RegularTasksOverridableგააკეთე ცვლილება:

რუტინული ამოცანების პარამეტრების განსაზღვრის პროცედურა (პარამეტრები) ექსპორტი
Electronic Interaction.Routine Tasks (პარამეტრების) პარამეტრების განსაზღვრისას;
პროცედურის დასასრული

მოდულში ElectronicSignatureClientOverridableგააკეთე ცვლილება:

დამატებითი სერტიფიკატის გადამოწმების (პარამეტრების) ექსპორტის პროცედურა
ExchangeWithBanksClient.AtAdditionalCertificateVerification(პარამეტრები);
პროცედურის დასასრული

მოდულისკენ ElectronicSignatureOverridableგააკეთე ცვლილება:

ფორმის შექმნის პროცედურა სერტიფიკატის შემოწმება (სერთიფიკატი, დამატებითი ჩეკები, დამატებითი შემოწმების პარამეტრები, სტანდარტული ჩეკები) ექსპორტი
ExchangeWithBanks.WhenCreatingFormVerificationCertificate(
სერთიფიკატი, დამატებითი შემოწმებები, დამატებითი შემოწმების პარამეტრები, სტანდარტული ჩეკები);
პროცედურის დასასრული

შემდეგი გაუზიარებელი ობიექტები დაემატა:

;

მუდმივი ზოგადი ფაილების გაცვლა ბანკებთან.

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

თუ კონფიგურაცია გამიზნულია იმუშაოს სერვისის მოდელის რეჟიმში, მაშინ თქვენ უნდა შეცვალოთ Subscription Handler მოვლენაზე Control of Unshared Objects while Writing BED to WorkIn Service Model.Control of Unshared Objects while Writing.

ვერსია 1.3.1

ვერსია 1.3.1 არის პროდუქტის 1.2 გამოცემის განვითარება "1C: ელექტრონული დოკუმენტების ბიბლიოთეკა". შექმნილია კონფიგურაციების შემუშავებისთვის, რომლებიც შექმნილია 1C:Enterprise პლატფორმაზე 8.3 ვერსია 8.3.6 და უფრო მაღალი სამუშაოებისთვის.

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

თავსებადობის რეჟიმი უნდა დაყენდეს „არ გამოიყენო“.
მოდალობის გამოყენების რეჟიმი შეიძლება დაყენდეს „არ გამოიყენო“.
ინტერფეისის თავსებადობის რეჟიმს შეუძლია მიიღოს მნიშვნელობები "Version 8.2", "Version 8.2. Allow Taxi" ან "Taxi. Allow Version 8.2".

ახალი ფუნქციები და ცვლილებები

EDI სერვისის მეშვეობით ელექტრონული დოკუმენტების ელექტრონული ხელმოწერის გარეშე გაცვლის შესაძლებლობა განხორციელდა 1C: ბიზნეს ქსელის მონაწილეებისთვის;
დანერგილია ბანკებთან ავტონომიური გაცვლის ქვესისტემა;
"სტანდარტული ქვესისტემის ბიბლიოთეკის" (BSS) ქვესისტემები განახლდა 2.3.1.71 ვერსიამდე.

გადასვლა 1.3.1 ვერსიაზე 1.2.6, 1.2.7 ვერსიებიდან

არქიტექტურა იცვლება

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

ელექტრონული დოკუმენტებივ ელექტრონული ურთიერთქმედება:

გვარი ინიციალები პირები

მოდულიდან გადატანილი მეთოდების სია ელექტრონული დოკუმენტებივ გაცვლა ბანკებთან:

შესაძლებელია ბანკთან პირდაპირი გაცვლა
GetDataBankStatementsTreeValues
GetDataBankStatementsTextFormat
Parsing TreeExtractsBank

მეთოდების სია, რომლებიც გადატანილია მოდულიდან ElectronicInteractionClientOverridable:

შეასრულეთ დოკუმენტის შემოწმება

მოდულიდან გადატანილი მეთოდების სია ElectronicDocumentsClientOverridableვ ExchangeWithBanksClientOverridable:

ParseFileExtracts

მეთოდების სია, რომლებიც გადატანილია მოდულიდან ElectronicInteractionClientServer:

GetMessageText (ეწოდა MessageText)
დიახ მოქმედება

მოდულიდან გადატანილი მეთოდების სია Electronic DocumentsClientServerვ ExchangeWithBanksClientServer:

შევსებული DetailsSettings EDSBanks (ეწოდა შევსებული შევსებული დეტალებიSettingsExchange)
HeaderSettingsEDOSBank-ს ეწოდა HeaderSettingsExchangeWithBank
GetStatusTextED

მეთოდების სია, რომლებიც გადატანილია მოდულიდან ElectronicInteraction Overridable:

ChangeFormElementProperties
CurrentDirectoryTemporaryFiles
მიიღეთ შესაბამისი ფუნქციური პარამეტრები
მიიღეთ შესაბამისი დირექტორიები
მიიღეთ მიმოწერა MD ობიექტების სახელებთან და დეტალებთან
დეტალებისა და წარმომადგენლობების კოდების შესაბამისობა
მიიღეთ ობიექტის ძირითადი დეტალების სტრუქტურა
ტექსტური შეტყობინება NecessarySystem პარამეტრები
შეცდომის შეტყობინების რედაქტირება
მოამზადეთ MessageText წვდომის უფლებების დარღვევის შესახებ
disassembleNameIndividuals
FindReferenceToObject
მიიღეთ დაბეჭდილი დოკუმენტის ნომერი
CheckReadinessSources
GetData იურიდიული პირები
აღწერა ორგანიზაციები
არსებობს ED დამუშავების უფლება
არსებობს უფლება წაიკითხოს ED
არსებობს ჟურნალის რეგისტრაციის უფლება

მოდულიდან გადატანილი მეთოდების სია ElectronicDocumentsOverridableვ ExchangeWithBanksOverridable:

მიიღეთ ED-ის მიმდინარე ტიპები
მიიღეთ საბანკო ანგარიშის ნომრები
შეავსეთ ED Parameters By Source
შეავსეთ გადახდის ორდერის მონაცემები
შეავსეთ გადახდის მოთხოვნის მონაცემები
CheckAbility toEditObject

ღონისძიების გამოწერებიდან მიანიჭეთ ED-ის ახალი ვერსია მფლობელის ჩაწერისასდა შეამოწმეთChangeBeforeRecordingOwnerEDსაბანკო დოკუმენტები წაიშალა.

განლაგება გადატანილია დამუშავებიდან ExchangeCounterpartiesვ გაცვლა ბანკებთან:

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

თქვენ უნდა დაამატოთ განსაზღვრულ ტიპს

documentObject.PackageED

ინტერფეისი იცვლება

საერთო მოდულებში გაცვლა ბანკებთან, ExchangeCounterpartiesდამატებულია პროცედურები როდესაც CreatedOnServer. გამოიძახება ობიექტის ფორმების გახსნისას EDI ბრძანებების გენერირებისთვის. Პარამეტრები: ფორმა- მიმდინარე ფორმა, გუნდის განლაგება ნაგულისხმევი– ქვემენიუ ფორმის ელემენტი, რომელშიც შეიქმნება EDI ბრძანებები.
საერთო მოდულებში ExchangeWithBanksOverridable, ExchangewithCounterparties Overridableდაამატა პროცედურები EDM ბრძანებების სიის შესაქმნელად მოამზადეთ გუნდების ობიექტების სტრუქტურა EDF. Პარამეტრი TeamsEDO-ს შემადგენლობაშეიძლება იყოს მასივი (ქვესისტემისთვის გაცვლა ბანკებთან) ან მასივის სტრუქტურა ( ExchangeCounterparties).
EDI ბრძანებების ჯგუფი ამოღებულია, ბრძანების პანელის ავტომატური შევსება EDI ბრძანებებით აღარ არის შესრულებული.

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

მაგალითი მოდულში ExchangewithCounterparties Overridable:

EDM-ის გუნდების შემადგენლობა.გამავალი.დამატება("დოკუმენტი.საქონლისა და სერვისების გაყიდვები");
EDO Commands.Outgoing.Add("დოკუმენტი.მყიდველის შეკვეთა");
…
EDF-ის გუნდების შემადგენლობა.შემომავალი.Add("დოკუმენტი.საქონლისა და მომსახურების მიღება");
EDO Commands.Incoming.Add("Document.Invoice Received");
…
პროცედურის დასასრული

ExchangeWithBanksOverridable:

პროცედურა EDF გუნდების ობიექტების სტრუქტურის მომზადება (EDF გუნდების შემადგენლობა) ექსპორტი
EDO Commands.Add("დოკუმენტი.გადახდის ორდერი");
EDO Commands-ის შემადგენლობა.Add("Document.PaymentRequest");
…
პროცედურის დასასრული

ფორმის შექმნისას გამოიძახეთ პროგრამის გენერირება ბრძანებები

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

პროცედურა სერვერზე შექმნისას (მარცხი, სტანდარტული დამუშავება)
//EDO ბრძანებები
გაცვლა Counterparties.When CreatedOnServer(ThisObject, Elements.EDO Commands);
// EDO ბრძანების დასასრული
პროცედურის დასასრული

დაამატეთ ჩამრთველი ფორმის დამმუშავებელი Connectable_Execute EDO ბრძანება:

პროცედურა Connectable_Execute EDO ბრძანება (ბრძანება)
ElectronicInteractionServiceClient.ExecuteConnectedCommandEDO(Command, ThisForm, Elements.List);
პროცედურის დასასრული

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

შეავსეთ განსაზღვრული ტიპი "თვითნებური ედ-ის საფუძვლები" იმ დოკუმენტების ტიპებით, რომელთა საფუძველზეც შეიტანება ჩანაწერები. თვითნებური ედ(სავარაუდოდ, ეს იქნება იგივე დოკუმენტები, როგორც განსაზღვრული ტიპის მიმაგრებული ფაილების მფლობელში), ასევე ამ დოკუმენტებში თქვენ უნდა დაამატოთ დოკუმენტი "Custom ED" სიაში "ეს არის საფუძველი:"
დოკუმენტის ფორმებსა და დოკუმენტების სიებში (რომლის საფუძველზეც არის შეყვანილი Custom ED), აუცილებელია გამორთოთ Custom ED ქვემენიუში "Create based on", რადგან Custom ED-ში შესვლის ბრძანება მოთავსებულია EDO ქვემენიუში (ბრძანება „ფაილის დამატება“);
უფლებათა გადაცემის აქტის განლაგებაში, საქონლის შეკვეთა, შეკვეთაზე პასუხი, კომისიის აგენტის ანგარიში გაყიდვების შესახებ, კომისიის აგენტის ანგარიში აღწერილობაზე, გადახდის ინვოისი, პროდუქტის კატალოგი, ფასების სია პარამეტრების ჯგუფში. "ბანკი" "BIC" ველში შეიცვალა სავალდებულო შევსების ატრიბუტი. ეს ველი უნდა იყოს შევსებული;
InvoiceInvoice-ის განლაგებაში შეიცვალა წარმოშობის ქვეყნის კოდის და საბაჟო დეკლარაციის ნომრის ველების ფორმატი. უფრო სწორად შევსებისთვის, ისინი გაერთიანებულია საბაჟო დეკლარაციის ცხრილში. ESF მონაცემების მომზადების პროცედურაში ამ ელემენტების შევსების მაგალითი შეგიძლიათ იხილოთ BED-ის დემო მონაცემთა ბაზაში.

ცვლილებები მოდულში ExchangewithCounterpartiesClient

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

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

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

საქონლისა და მომსახურების გაყიდვები მეტამონაცემებში
საქონლისა და მომსახურების მიღება მეტამონაცემებში

ცვლილებები ExchangeCounterparties მოდულში

დამატებულია Fill DataBy 1SEDOD მეთოდი 1C-Reporting Master-ისთვის, რომელიც ამზადებს მონაცემებს 1C-Reporting Master-ისთვის.

დამატებულია მეთოდი Check AccounterV1EDMSWhen CreatedOnServer, რომელიც უნდა გამოიძახოთ ანგარიშის ფორმის შექმნისას. ეს მეთოდი ამოწმებს კონტრაგენტის მიერ 1C-EDO სერვისთან დაკავშირებას.
მაგალითი გაცვლა კონტრაგენტებთან. შეამოწმეთ კონტრაგენტი 1 SEDO-ში სერვერზე შექმნისას:

პროცედურა სერვერზე შექმნისას (მარცხი, სტანდარტული დამუშავება)
// ელექტრონული ურთიერთქმედება.გაცვლა კონტრაგენტებთან
გაცვლა კონტრაგენტებთან შეამოწმეთ Counterparty 1SEDO-ში When CreatedOnServer(Object.Link);
// ელექტრონული ურთიერთქმედების დასრულება.გაცვლა კონტრაგენტებთან
პროცედურის დასასრული

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

დამატებულია გაყოფილი ინფორმაციის რეესტრი კონტრაგენტების სტატუსიBED, რომელიც აგროვებს სტატისტიკას 1C-EDO სერვისთან დაკავშირებული კონტრაქტორების შესახებ.

დაამატეთ 1C-EDO სერვისთან კავშირის ნიშნის ჩვენება "EDO" სვეტში სიის ფორმაში და კონტრაგენტის შერჩევის ფორმაში. დაამატეთ მინიშნება სვეტს "დაკავშირებულია 1C-EDO სერვისთან".
მაგალითი:

არჩევა
არჩევანი
WHENCCounterparty StatusBED.Status = VALUE(Enumeration.CounterpartyStateBED.Connected)
მერე 0
სხვა 1
ᲓᲐᲡᲐᲡᲠᲣᲚᲘ
END LIKE EDO
DirectoryCounterparties.Name,
DirectoryCounterparties.INN,
DirectoryCounterparties.KPP,
....
DirectoryCounterparties.NameFull
FROM
Directory.Counterparties AS DirectoryCounterparties
LEFT CONNECTION ინფორმაციის რეესტრი კონტრაქტორების სტატუსი BED AS კონტრაქტორების სტატუსი BED
პროგრამული უზრუნველყოფა (კონტრაქტორი StatesBED.Counterparty = DirectoryCounterparties.Link)

საინფორმაციო ბაზის დოკუმენტის ფორმებზე აუცილებელია ბმულის „გამოიყენე ED Exchange“ ფუნქციური ვარიანტის „ED State Text“ ფორმის ატრიბუტიდან ამოღება. ამოიღეთ სათაური "ED Status" ატრიბუტიდან.

ცვლილებები „ბანკებთან გაცვლა“ ქვესისტემაში

დამატებულია ღონისძიების გამოწერები ExchangeWithBanksOwnerEDBeforeRecordingდა ExchangeWithBanksOwnerEDOnRecording.

დამატებულია განსაზღვრული ტიპები OwnersExchangeWithBanks და DirectoryBanks.
დამატებულია ზოგადი ბრძანება SettingsExchangeWithBanks.

განსაზღვრული ტიპისთვის Მიმაგრებული ფაილიდაამატეთ:

directoryLink.MessageExchangeWithBanksAttachedFiles;
directoryObject.MessageExchangeWithBanksAttachedFiles;
directoryLink.PackageExchangeWithBanksAttachedFiles;
directoryObject.PackageExchangeWithBanksAttachedFiles.

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

documentLink.MessageExchangeWithBanks;
documentLink.PackageExchangeWithBanks.

განსაზღვრული ტიპისთვის OwnerAttachedFilesObjectუნდა დაემატოს

documentObject.MessageExchangeWithBanks;
documentObject.PackageExchangeWithBanks;
documentObject.PackageED

დამატებულია ახალი ქვესისტემა "ბიზნეს ქსელი"

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

აუცილებელია მოდულში პროცედურების და ფუნქციების დასრულება BusinessNetwork Overridable:

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

გადასვლა 1.3.7 ვერსიაზე 1.3.6 ვერსიიდან

ფაილში გადახდის დოკუმენტების ატვირთვისა და ფაილიდან საბანკო ამონაწერის ჩამოტვირთვის ფორმაში (დამუშავება კლიენტბანკი) ელემენტების ჯგუფის გადატანა GroupAdvertisingDirectBankHorizontallyზოგადი ფორმიდან OfferConnect1SdirectBank.

მოვლენის დამმუშავებლის ფორმაში როდესაც CreatedOnServerადგილის მეთოდები ExchangeWithBanksClientServer.ShowAdvertisingDirectBank:

&სერვერზე
პროცედურა CreateOnServer-ის დროს (მარცხი, სტანდარტული დამუშავება)
…
// ელექტრონული ურთიერთქმედება.გაცვლა ბანკებთან
ExchangeWithBanksClientServer.ShowAdvertisingDirectBank(
Elements.GroupAdvertisingDirectBankHorizontally, Elements.TextDirectBankHorizontally);
// ელექტრონული ურთიერთქმედების დასრულება.გაცვლა ბანკებთან
პროცედურის დასასრული

მოვლენის დამმუშავებლის ფორმაში ProcessingAlertsგანათავსეთ მეთოდი ExchangeWithBanksClient.UpdateAdvertisingDirectBank:

&OnClient
პროცედურის პროცესის შეტყობინებები (მოვლენის სახელი, პარამეტრი, წყარო)
…
// ელექტრონული ურთიერთქმედება.გაცვლა ბანკებთან
ExchangeWithBanksClient.UpdateAdvertisingDirectBank(EventName,
Elements.GroupAdvertisingDirectBankHorizontally, Elements.TextDirectBankHorizontally);
// ელექტრონული ურთიერთქმედების დასრულება.გაცვლა ბანკებთან
პროცედურის დასასრული

ელემენტისთვის TextDirectBankHorizontallyმოვლენის დამმუშავებლის დამატება ნავიგაციის ბმულების დამუშავებადა განათავსეთ მასში მეთოდი ExchangeWithBanksClient.ProcessingNavigationLinkAdvertisingDirectBank:

&OnClient
პროცედურა TextDirectBankHorizontalNavigationLinkProcessing(ელემენტი, ფორმატირებული სტრიქონიNavigationLink, StandardProcessing)
ExchangeWithBanksClient.ProcessingNavigationLinkAdvertisingDirectBank(
NavigationLinkFormatString, StandardProcessing);
პროცედურის დასასრული

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

09.06.2017

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

BED-ზე გადასვლის შესახებ მსჯელობა საკმაოდ დიდი ხანია, სახელმწიფო დონეზე - აქტიურად 2008 წლიდან მიმდინარეობს. მაგრამ რამდენად დინამიური და წარმატებულია ეს პროცესი? რა არის მიზეზები, რის გამოც დღევანდელი შედეგები განსხვავდება 7-10 წლის წინ ნაწინასწარმეტყველებისაგან? ამ კითხვებზე პასუხებისთვის ჩვენ მივმართეთ ექსპერტებს - EDMS/ECM ინსტრუმენტების შემქმნელებს და მათ, ვინც მონაწილეობს ასეთი სისტემების დანერგვასა და ექსპლუატაციაში.

რა მნიშვნელობა აქვს BED-ზე გადასვლას

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

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

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

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

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

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

ამაზე საუბრისას, Taxkom-ის მარკეტინგის დირექტორის მოადგილე ერნესტ კოლესნიკოვი ანალიტიკოსების პროგნოზებს ეხება: 2017 წლისთვის EDI მექანიზმების გამოყენება კონტრაგენტებთან 22,5%-ს მიაღწევს. უკვე ახლა, დღგ-ს ახალი დეკლარაციის შემოღების შემდეგ (თითქმის ყველა გადასახადის გადამხდელმა ახლა უნდა წარადგინოს იგი ელექტრონულად), განსაკუთრებით აქტუალური გახდა დოკუმენტის ავტომატიზაციის საკითხი, რადგან მონაცემთა ხელით შეყვანით, ბუღალტერია დიდი ალბათობით მიიღებს ავტომატურ მოთხოვნებს კონტრაგენტებთან შეუსაბამობის შესახებ. . ის ასევე შეახსენებს, რომ რუსეთის ფედერაციის შრომის კოდექსის 49.1 თავი საშუალებას აძლევს EDI-ს გამოყენებას დისტანციურად მუშაობისას, ხოლო 2016 წლის 1 ივლისიდან ძალაში შევა ცვლილებები ფედერალურ კანონში „სააქციო საზოგადოებათა შესახებ“, რაც საშუალებას მისცემს აქციონერებს. EDI-ის გამოყენებით შეხვედრებში დისტანციურად მონაწილეობის მისაღებად.

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

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

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

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

Directum-ის ბიზნეს ანალიტიკოსი მაქსიმ კაინერი ამბობს, რომ EDMS/ECM დანერგვისას ქაღალდის ბეჭდვაზე დაზოგვა მიიღწევა მხოლოდ ავტომატიზირებული პროცესების მეშვეობით, მაგრამ ხშირად აღმოჩნდება, რომ ბეჭდვის მთლიანი მოცულობა მთელ ორგანიზაციაში შეიძლება გაიზარდოს. უფრო მეტიც, კონკრეტული ბიზნეს პროცესის ავტომატიზაცია ECM-ის საშუალებით 10%-ზე ნაკლებ შემთხვევაში საშუალებას გაძლევთ თავიდან აიცილოთ დოკუმენტების ბეჭდვა ამ პროცესის ფარგლებშიც კი. ზოგადად, მას მიაჩნია, რომ ჯერჯერობით არ არის საუბარი ორგანიზაციების უქაღალდოდ გადატანაზე.

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

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

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

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

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

დაბრკოლებები BED-ისკენ მიმავალ გზაზე

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

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

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

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

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

Რა უნდა ვქნა?

„ამჟამად, რუსეთში შეუძლებელია ქაღალდის მთლიანად მიტოვება, იქნება ეს საჯარო სექტორში თუ კომერციულ სექტორში“, - ამბობს ელენა ივანოვა. - უპირველეს ყოვლისა, აუცილებელია საკანონმდებლო ბაზის შემუშავება, რომელიც წაახალისებს ორგანიზაციებს გადავიდნენ BED-ზე. ნაწილობრივ, ეს ახლა იწყებს გამოვლინებას სამთავრობო ორგანიზაციებში SMEV, M-ის გაუმჯობესებასთან დაკავშირებით. ბევრი რამ არის დამოკიდებული EDMS გამყიდველზე, მისი აზრით; მათ შეუძლიათ გაამართლონ BED-ზე გადასვლის ეკონომიკური ეფექტი და შესთავაზონ ტექნოლოგიური გადაწყვეტილებები. ასევე მნიშვნელოვანია EDMS/ECM სფეროებში სტანდარტიზაციაში ჩართულ პროფესიულ საზოგადოებებში და ორგანიზაციებში მუშაობა და სახელმწიფო მარეგულირებელთან ურთიერთობა.

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

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

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

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

კოლეგებო!

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

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

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

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

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

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

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

Რა შეიძლება გაკეთდეს?

ჩვენ ვხსნით ინფორმაციის რეესტრს "კონტრაგენტთა სტატუსი" - ჩ. მენიუ - ყველა ფუნქცია - ინფორმაციის რეგისტრები:

„კონტრაქტორის სტატუსის“ საინფორმაციო რეესტრში მოათავსეთ კურსორი ხაზზე სასურველ კონტრაგენტთან:

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

გამოვიდა სტანდარტული კონფიგურაციის ახალი ვერსია 1.3.8 "1C: Electronic Documents 1.3 ბიბლიოთეკა".

ვერსია 1.3.8

ახალი ფუნქციები და ცვლილებები

სავაჭრო შეთავაზებების საძიებო ფორმაში დამატებულია ძებნის შესაძლებლობა 1C: Business Network სერვისთან დაკავშირების გარეშე და დამატებულია მომწოდებლის სახელით ძებნის შესაძლებლობა.
დამატებულია ანგარიში გამოქვეყნებული სავაჭრო შეთავაზებების შესახებ.
დამატებულია სამუშაო ადგილი 1C:Business Network სერვისში სავაჭრო შეთავაზებების გამოქვეყნებისთვის.
ადაპტაცია განხორციელდა ქვესისტემებით „1C: სტანდარტული ქვესისტემების ბიბლიოთეკა“ ვერსია 2.4.2, „1C: ინტერნეტ მომხმარებელთა მხარდაჭერის ბიბლიოთეკა“ ვერსია 2.2.2.

გადასვლა 1.3.8 ვერსიაზე 1.3.7 ვერსიიდან

მოდულის ცვლილებები:

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

ცვლილებები მოდულში სავაჭრო შეთავაზებები

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

ვერსია 1.3.7

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

თავსებადობის რეჟიმი უნდა დაყენდეს „არ გამოიყენო“.
მოდალობის გამოყენების რეჟიმი შეიძლება დაყენდეს „არ გამოიყენო“.
ინტერფეისის თავსებადობის რეჟიმს შეუძლია მიიღოს მნიშვნელობები "Version 8.2", "Version 8.2. Allow Taxi" ან "Taxi. Allow Version 8.2".

ახალი ფუნქციები და ცვლილებები

დამატებულია Sberbank-ისგან გადახდის დოკუმენტის სტატუსის მიღების შესაძლებლობა.
განხორციელდა Sberbank-ისთვის პარამეტრების ავტომატური მიღება 1C:DirectBank სერვისთან დაკავშირებისას.
დამატებულია კონტექსტური რეკლამის ჩვენების შესაძლებლობა 1C:DirectBank.
ადაპტაცია განხორციელდა 1C: Business Network სერვისთან მუშაობისთვის 1CFresh ღრუბლოვან სერვისში.
დამატებულია სავაჭრო შეთავაზებების გამოქვეყნების, ძიების და შეკვეთის შესაძლებლობა 1C: Trade Offers სერვისში 1C: Business Network სერვისის მონაწილეებისთვის.
ადაპტაცია განხორციელდა ქვესისტემებით „1C: სტანდარტული ქვესისტემების ბიბლიოთეკა“ ვერსია 2.4.1, „1C: ინტერნეტ მომხმარებელთა მხარდაჭერის ბიბლიოთეკა“ ვერსია 2.1.9, „1C: სერვისის ტექნოლოგიების ბიბლიოთეკა“ ვერსია 1.0.12.

გადასვლა 1.3.7 ვერსიაზე 1.3.6 ვერსიიდან

ქვესისტემა "გაცვლა კონტრაგენტებთან"

მოდულის ცვლილებები:

დოკუმენტის თარიღი, DocBaseDate

ქვესისტემა "გაცვლა ბანკებთან"

ცვლილებები მოდულში FilesOverridable-თან მუშაობა:

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

ElectronicInteraction.WhenDefiningSettings(Settings);

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

Electronic Interaction.FileStorage დირექტორიების განსაზღვრისას (FileOwnerType, DirectoryNames);

დირექტორიები MessageExchangeWithBanksAttachedFiles და EDAttachedFiles დაემატა გაცვლის გეგმას UpdateInformationBase
საქაღალდეები MessageExchangeWithBanksAttachedFiles და EDAttachedFiles დაემატა განსაზღვრულ ტიპს SignedObject.

&სერვერზე
პროცედურა CreateOnServer-ის დროს (მარცხი, სტანდარტული დამუშავება)
…
ExchangeWithBanksClientServer.ShowAdvertisingDirectBank(

პროცედურის დასასრული

&OnClient

…
// ელექტრონული ურთიერთქმედება.გაცვლა ბანკებთან
ExchangeWithBanksClient.UpdateAdvertisingDirectBank(EventName,
Elements.GroupAdvertisingDirectBankHorizontally, Elements.TextDirectBankHorizontally);
// ელექტრონული ურთიერთქმედების დასრულება.გაცვლა ბანკებთან
პროცედურის დასასრული

ქვესისტემა "საიტებთან გაცვლა"

ცვლილებები მოდულში საიტის ExchangeOverridable:

დამატებულია პროცედურა დაამატეთ DetailsFormNode, გამოიყენება გაცვლის გეგმის კვანძში დეტალების დასამატებლად საიტთან გაცვლის სახით. გაცვლის კვანძის ფორმა არ ითვალისწინებს აპლიკაციის გადაწყვეტასთან დაკავშირებული დეტალების არსებობას; დეტალები ემატება პროგრამულად.
დამატებულია პროცედურა შეიტანეთ FieldWhenChangedOnServer, გამოიყენება ჩრდილოეთში მოვლენის დასამუშავებლად, როდესაც იცვლება გაცვლის გეგმის კვანძის ფორმის შეყვანის ველი, დაემატება Add NodeFormDetails პროცედურაში.
დამატებულია პროცედურა CheckboxFieldWhenChangedOnServer, გამოიყენება სერვერზე მოვლენის დასამუშავებლად, როდესაც იცვლება გაცვლის გეგმის კვანძის ფორმის დროშის ველი, რომელიც დამატებულია Add NodeFormDetails პროცედურაში.
დამატებულია პროცედურა WhenCreatingOnServerFormCreateSite, გამოიყენება CreateSite დამუშავების ფორმაში დეტალების დასამატებლად.

ცვლილებები მოდულში ExchangeSiteClientOverridable:

ამოღებულია პროცედურა განსაზღვრეთ GroupTableU კატალოგის ტიპიპროდუქტების კატალოგის ცხრილის Groups სვეტის მნიშვნელობის ტიპი განისაზღვრება გაცვლის პარამეტრებით.
დამატებულია პროცედურა InputFieldOnChange, გამოიძახება მოვლენის დასამუშავებლად, როდესაც იცვლება გაცვლის გეგმის კვანძის ფორმის შეყვანის ველი, რომელიც დაემატება SiteExchangeOverridden.AddNodeFormDetails პროცედურას.
დამატებულია პროცედურა CheckboxFieldOnChange, გამოიძახება მოვლენის დასამუშავებლად, როდესაც SiteExchangeOverridden.AddNodeFormDetails-ის პროცედურაში დამატებული გაცვლის გეგმის კვანძის ფორმის დროშის ველი იცვლება.
დამატებულია პროცედურა TableFormBeforeFinishEditing, მოწოდებულია SiteExchangeOverridden.AddNodeFormDetails-ის პროცედურაში დამატებული გაცვლის გეგმის კვანძის ფორმის ტაბულურ ნაწილში ველის BeforeFinishEdit მოვლენის დასამუშავებლად.

ქვესისტემა "ბიზნეს ქსელი"

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

// ელექტრონული ურთიერთქმედება
ElectronicInteraction.OnReceivingListTemplates(TaskTemplates);

პროცედურაში Aliases Handlers-ის განსაზღვრისას:

ცვლილებები მოდულში BusinessNetwork Overridable:
- პროცედურა გადაერქვა მიიღეთ IB UserContactsვ მიიღეთ მომხმარებლის საკონტაქტო ინფორმაცია.
- პროცედურა შეიცვალა ფუნქციურად შექმენით კონტრაგენტი დეტალების მიხედვით, ანგარიშის პარამეტრი წაშლილია.

ქვესისტემა "სავაჭრო შეთავაზებები"

შეიმუშავეთ გადაჭარბებული მეთოდები საერთო მოდულებში TradeOffersClientOverridable, TradeOffersOverridable.
მიუთითეთ მონაცემთა ტიპები განსაზღვრულ ტიპებში დეტალების ღირებულებების ტიპები 1СBusinessNetwork, სახეები ნომენკლატურა BED, დამატებითი დეტალებიBED, სავაჭრო შეთავაზება.

იხილეთ ჩაშენების დოკუმენტაცია დეტალებისთვის.

ვერსია 1.3.6

ახალი ფუნქციები და ცვლილებები

პირველადი ინვოისის დოკუმენტების ფორმატები მხარდაჭერილია (ცალკე პირველადი დოკუმენტის, ინვოისის გადაცემის თვალსაზრისით) ფედერალური საგადასახადო სამსახურის 2016 წლის 24 მარტის № ММВ-7-15/155@ ბრძანების შესაბამისად „დამტკიცების შესახებ ქ. ინვოისის ფორმატი და დოკუმენტის წარმოდგენის ფორმატი საქონლის გადაზიდვაზე (სამუშაოს შესრულებაზე), საკუთრების უფლების გადაცემაზე (მომსახურების გაწევის დოკუმენტი), ინვოისის ჩათვლით, ელექტრონული ფორმით.“.
ღირებულების ცვლილების შესახებ პირველადი დოკუმენტების ფორმატები, მათ შორის კორექტირების ინვოისი, მხარდაჭერილია (ცალკე პირველადი დოკუმენტის, კორექტირების ინვოისის გადაცემის თვალსაზრისით) ფედერალური საგადასახადო სამსახურის 2016 წლის 13 აპრილის N MMV ბრძანების შესაბამისად. -7-15/189@ "კორექტირების ინვოისის ფორმატის დამტკიცების შესახებ და დოკუმენტის წარდგენის ფორმატი გადაგზავნილი საქონლის ღირებულებაში ცვლილებების შესახებ (შესრულებული სამუშაო, გაწეული მომსახურება), გადაცემული საკუთრების უფლებები, კორექტირების ინვოისის ჩათვლით, ქ. ელექტრონული ფორმა."
დაემატა ახალი ელექტრონული დოკუმენტები: საქონლის გადაცემა, სამუშაოს შედეგების გადაცემა, დოკუმენტების ვიზუალური წარმოდგენის ახალი ფორმა.
დამატებულია ცალმხრივი გაცვლის მექანიზმი, რომელიც არ საჭიროებს შეტყობინებას მიმღების მიღების შესახებ.
დამატებულია შემომავალი ელექტრონული დოკუმენტების შეფუთვის (ავტომატურად ან ხელით) კონტროლის შესაძლებლობა, ელექტრონული დოკუმენტების მიღებისას კონკრეტული ტიპის დოკუმენტის შექმნის კონფიგურაციის შესაძლებლობა.
დაემატა ელექტრონული დოკუმენტის რამდენიმე საინფორმაციო ბაზის საბუღალტრო დოკუმენტთან დაკავშირების შესაძლებლობა.
განხორციელდა ელექტრონული დოკუმენტების დაყოფა შემოსულ და გამავალზე.
სერვისთან ინტეგრაცია განხორციელდა 1C-UMIსაშუალებას გაძლევთ შექმნათ ვებსაიტები პროგრამიდან, მოაწყოთ გაცვლა ონლაინ მაღაზიასთან UMI.
ადაპტაცია გაკეთდა 1C-EDO სერვისთან მუშაობისთვის 1CFresh ღრუბლოვან სერვისში.

გადასვლა 1.3.6 ვერსიაზე 1.3.5 ვერსიიდან

ქვესისტემა "გაცვლა კონტრაგენტებთან"

ზოგადი მოდული ExchangewithCounterparties ხელახლა განსაზღვრებადი

დამატებულია მეთოდი UPD SCHFDOP.
დამატებული მეთოდი შეავსეთ UPD მყიდველის ინფორმაციის ფედერალური საგადასახადო სამსახურის მონაცემები. მეთოდი ამზადებს მონაცემებს UPD (მყიდველის ინფორმაცია) ტიპის SCHFDOP ფუნქციის ელექტრონული დოკუმენტისთვის.
დაემატა UPD მეთოდის (გამყიდველის ინფორმაცია) ფუნქცია SCHFDOP ინფორმაციული უსაფრთხოების ობიექტებს.
დამატებული მეთოდი შეავსეთ მონაცემები გამყიდველის ფედერალური საგადასახადო სამსახურის დამატებითი ინფორმაციისთვის. მეთოდი ამზადებს მონაცემებს ელექტრონული დოკუმენტისთვის, როგორიცაა STD (გამყიდველის ინფორმაცია) DOP ფუნქცია.
დამატებული მეთოდი FindCreate UPDT DocumentAboutTransfer. მეთოდი ინახავს მონაცემებს ელექტრონული დოკუმენტის UPD (გამყიდველის ინფორმაცია) ფუნქციიდან DOP IS ობიექტში.
დამატებული მეთოდი შეავსეთ მონაცემები SCHFISeller-ის ინფორმაციის ფედერალური საგადასახადო სამსახურისთვის. მეთოდი ამზადებს მონაცემებს UTD (გამყიდველის ინფორმაცია) ტიპის SSF ფუნქციის ელექტრონული დოკუმენტისთვის.
დამატებული მეთოდი FindCreateUPDSInvoiceInvoice. მეთოდი ინახავს მონაცემებს ელექტრონული დოკუმენტის UPD (გამყიდველის ინფორმაცია) SSF ფუნქციიდან ინფორმაციის უსაფრთხოების ობიექტში.
დამატებული მეთოდი. მეთოდი ამზადებს მონაცემებს UCD ტიპის (გამყიდველის ინფორმაცია) KSCHFDIS ფუნქციის ელექტრონული დოკუმენტისთვის.
დამატებული მეთოდი შეავსეთ მონაცემები UKID მყიდველის ინფორმაციის ფედერალური საგადასახადო სამსახურისთვის. მეთოდი ამზადებს მონაცემებს UKD (მყიდველის ინფორმაცია) ტიპის KSCHFDIS ფუნქციის ელექტრონული დოკუმენტისთვის.
დამატებული მეთოდი. მეთოდი ინახავს მონაცემებს ელექტრონული დოკუმენტიდან UCD (გამყიდველის ინფორმაცია) ფუნქციიდან KSCHFDIS ინფორმაციული უსაფრთხოების ობიექტებში.
დამატებული მეთოდი შეავსეთ მონაცემები გამყიდველის ფედერალური საგადასახადო სამსახურის დეინფორმაციისთვის. მეთოდი ამზადებს მონაცემებს UCD ტიპის (გამყიდველის ინფორმაცია) DIS ფუნქციის ელექტრონული დოკუმენტისთვის.
დამატებული მეთოდი FindCreateUKDDocumentAboutChangeValue. მეთოდი ინახავს მონაცემებს ელექტრონული დოკუმენტიდან UCD (გამყიდველის ინფორმაცია) ფუნქციიდან DIS IS ობიექტში.
დამატებული მეთოდი შეავსეთ მონაცემები KSCHFISeller-ის ინფორმაციის ფედერალური საგადასახადო სამსახურისთვის. მეთოდი ამზადებს მონაცემებს UCD ტიპის (გამყიდველის ინფორმაცია) KSCHF ფუნქციის ელექტრონული დოკუმენტისთვის.
დამატებული მეთოდი FindCreateUKDSAccountInvoice. მეთოდი ინახავს მონაცემებს ელექტრონული დოკუმენტიდან UCD (გამყიდველის ინფორმაცია) ფუნქციიდან KSCHF ინფორმაციული უსაფრთხოების ობიექტში.
დამატებული მეთოდი ED-ის გამავალი ტიპების შესაბამისობა ინფორმაციული უსაფრთხოების დოკუმენტებთან. მეთოდი აყალიბებს შესაბამისობას გამავალ ელექტრონულ დოკუმენტებსა და ინფორმაციული უსაფრთხოების დოკუმენტებს შორის.
დამატებული მეთოდი FindCreateDocumentTransferWorkResults. მეთოდი გამოიყენება „საქონლის გადაცემის“ ფორმატში მიღებული ზედნადების დოკუმენტის შესავსებად.
დამატებული მეთოდი FindCreateDocument საქონლის გადაცემა. მეთოდი გამოიყენება „სამუშაო შედეგების გადაცემის“ ფორმატში მიღებული დოკუმენტის მომსახურების გაწევის სერტიფიკატის შესავსებად.
დამატებული მეთოდი InstalledStateExchange დასრულდა. მეთოდი იწოდება, როდესაც დოკუმენტის ნაკადის მდგომარეობა იცვლება გაცვლა დასრულებულია, გაცვლა დასრულებულია შესწორებით.
ელექტრონული დოკუმენტების გენერირებისას UPD, UKD, საქონლის გადაცემა, სამუშაოს შედეგების გადაცემა, დეტალები დოკუმენტის თარიღი, DocBaseDateსაჭიროა შევსება.

დამუშავება გაცვლა კონტრაგენტებთან

"Torg-12Seller" განლაგებაში:

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

განლაგებაში უფლებათა გადაცემის აქტი:

დამატებულია ცხრილის ნაწილი "ბაზა".
ველები "DocumentBaseName", "DocumentBaseNumber", "DocumentBaseDate", "DocumentBaseAdditionalInformation" ამოღებულია.
დაემატა ველი "CurrencyName".
დამატებულია ველი "პრეტენზიები".
დაემატა ველი "აღსრულების თარიღი".
ტრანზაქციის მონაწილეთა თვისებებში „ფაქსის“ ველი შეიცვალა „ელ.ფოსტის“ ველით.
ტრანზაქციის მონაწილეთა თვისებებში „ქვეყნის კოდის“ ველი შეიცვალა „ქვეყნის კოდის“ ველით.
ტრანზაქციის მონაწილეთა თვისებებში „AddressText“ ველი შეიცვალა „AddressText“ ველით.

განსაზღვრული ტიპის განახლება კონტრაპარტიული:

განახლების პროცედურა:

დაარქვით განსაზღვრული ტიპის Account AccountBED.
ამოიღეთ კონფიგურაცია საყრდენი BED 1.3.5.
განახორციელეთ შედარება/შერწყმა BED 1.3.5 კონფიგურაციასთან, დაეთანხმეთ კონფიგურაციის მხარდაჭერას.
მოხსენით ყველა ობიექტი და დატოვეთ მხოლოდ განსაზღვრული ანგარიშის ტიპი, შეასრულეთ შერწყმა.
დაიწყეთ კონფიგურაციის განახლება, აირჩიეთ BED ფაილი 1.3.6.
აირჩიეთ ველები განსაზღვრულ ტიპებზე AccountBED და Account. მიუთითეთ მონაცემთა ბაზის სხვა საჭირო ობიექტები განახლებისთვის.
განახორციელეთ განახლება.

ქვესისტემა "გაცვლა ბანკებთან"

ქვესისტემა "საიტებთან გაცვლა"

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

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

დამატებულია საცნობარო წიგნი ვებსაიტები:

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

დამატებულია დამუშავება შექმენით ვებგვერდი:

დამატებულია საიტის შექმნის შესაძლებლობა 1C-UMI დომენში; საიტი იქმნება ავტომატურად (Sites ელემენტი) და ივსება მონაცემებით 1C. ExchangeSite გაცვლის კვანძი ავტომატურად იქმნება და პირველი სრული გაცვლა საიტთან შესრულდება.

ზოგადი მოდული საიტის ExchangeOverridable:

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

ზოგადი მოდული ExchangeSiteEvents:

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

სხვა ცვლილებები

ვერსია 1.3.5

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

თავსებადობის რეჟიმი უნდა დაყენდეს „არ გამოიყენო“.
მოდალობის გამოყენების რეჟიმი შეიძლება დაყენდეს „არ გამოიყენო“.
ინტერფეისის თავსებადობის რეჟიმს შეუძლია მიიღოს მნიშვნელობები "Version 8.2", "Version 8.2. Allow Taxi" ან "Taxi. Allow Version 8.2".

ახალი ფუნქციები და ცვლილებები

ბიბლიოთეკის ფუნქციონალობა ადაპტირებული იყო 8.3.8 პლატფორმაზე მუშაობის სპეციფიკურ მახასიათებლებთან თავსებადობის რეჟიმის გამორთვით;
"სტანდარტული ქვესისტემების ბიბლიოთეკის" ქვესისტემები განახლდა 2.3.3.45 ვერსიამდე;
ბიბლიოთეკა მოიცავს ქვესისტემას „ინტერნეტ მომხმარებელთა მხარდაჭერის ბიბლიოთეკები“, ვერსია 2.1.8.3.

გადასვლა 1.3.5 ვერსიაზე 1.3.4 ვერსიიდან

ცვლილებები არ არის საჭირო.

ვერსია 1.3.4

ახალი ფუნქციები და ცვლილებები

დანერგილია EDI ღონისძიებების შესახებ შეტყობინებების სისტემა (ახალი ელექტრონული დოკუმენტები, ახალი მოსაწვევები, სერტიფიკატის ვადის გასვლა და ა.შ.). ახლა უკვე შესაძლებელია ელ.ფოსტის შეტყობინებების კონფიგურაცია EDF პარამეტრების პროფილში, ასევე მოვლენების შესახებ შეტყობინებების ჩვენება პირდაპირ 1C პროგრამაში pop-up შეტყობინებების გამოყენებით;
მხარდაჭერილია პირველადი დოკუმენტის ფორმატი, მათ შორის ინვოისი (UPD ფორმატი) ფედერალური საგადასახადო სამსახურის 2016 წლის 24 მარტის ბრძანების შესაბამისად No ММВ-7-15/155@ „ინვოისის ფორმატის დამტკიცების შესახებ და საქონლის გადაზიდვის (სამუშაოს შესრულების), საკუთრების უფლების გადაცემის (დოკუმენტი მომსახურების გაწევის შესახებ) დოკუმენტის ელექტრონული ფორმით წარდგენის ფორმატი“;
ღირებულების ცვლილების შესახებ დოკუმენტის ფორმატი, რომელიც მოიცავს კორექტირების ანგარიშ-ფაქტურას, მხარდაჭერილია“ (UKD ფორმატი) ფედერალური საგადასახადო სამსახურის 04/13/2016 N ММВ-7-15/189@ ბრძანების შესაბამისად. „გაგზავნილი საქონლის (შესრულებული სამუშაო, გაწეული მომსახურება), გადაცემული ქონებრივი უფლებების, მათ შორის კორექტირების ინვოისის, ელექტრონულად გადაგზავნილი საქონლის ღირებულების ცვლილებების შესახებ კორექტირების ინვოისის ფორმატის და წარდგენის ფორმატის დოკუმენტის დამტკიცების შესახებ“;
მხარი დაუჭირა გარე კომპონენტების გამოყენებას ბანკებთან სანაცვლოდ DirectBank ტექნოლოგიის გამოყენებით.

გადასვლა 1.3.4 ვერსიაზე 1.3.2, 1.3.3 ვერსიებიდან

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

&OnClient

პროცედურის დასასრული

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

გაცვლა CounterpartiesClient-თან. Waiting ProcessorEDW:

&OnClient
პროცედურა Connectable_EDOWaitingHandler()
ExchangeCounterpartiesClient.EDOWaitingHandler(ThisObject);
პროცედურის დასასრული

Მაგალითად:

&სერვერზე
პროცედურა სერვერზე შექმნისას (მარცხი, სტანდარტული დამუშავება)
…
// ქვესისტემა „გაცვლა კონტრაგენტებთან“.
EDO პარამეტრები როდესაც შეიქმნა = გაცვლა კონტრაქტებთან პარამეტრები როცა შეიქმნა Server_DocumentForm();
EDO პარამეტრები როდესაც შეიქმნა.Form = ThisObject;
EDO პარამეტრები როდესაც შეიქმნა.DocumentLink = Object.Link;
EDO პარამეტრები როდესაც შეიქმნა.DecorationStateEDO = Elements.DecorationStateEDO;
EDO პარამეტრები როდესაც შეიქმნა.EDO State Group = Elements.EDO State Group;
გაცვლა Counterparties.When CreatedOn the Server_DocumentForm(Refusal, StandardProcessing, EDO ParametersWhen Created);
// „კონტრაქტორის გაცვლის“ ქვესისტემის დასასრული.
პროცედურის დასასრული

ცვლილებები ExchangeCounterparties მოდულში

დამატებულია პროცედურა როდესაც CreatedOnServer_ListForm, გამოძახებული დოკუმენტების სიის ფორმის "When CreatedOnServer" მოვლენის დამმუშავებლისგან. როგორც მეთოდის მესამე პარამეტრი, გადაეცემა სტრუქტურა, რომელიც ინიციალიზებულია მეთოდით ParametersWhenCreatingOnServer_ListForm.
დამატებულია პროცედურა როდესაც CreatedOnServer_FormDocument, გამოძახებული დოკუმენტის ფორმის "When CreatedOnServer" მოვლენის დამმუშავებლისგან. როგორც მეთოდის მესამე პარამეტრი, გადაეცემა სტრუქტურა, რომელიც ინიციალიზებულია მეთოდით ParametersWhenCreatingOnServer_DocumentForm.
დამატებულია პროცედურა AfterRecordingOnServer, გამოძახებული დოკუმენტის ფორმის "AfterRecordOnServer" მოვლენის დამმუშავებლისგან. როგორც მეთოდის მესამე პარამეტრი, გადაეცემა სტრუქტურა, რომელიც ინიციალიზებულია მეთოდით ParametersAfterRecordingOnServer.

ცვლილებები მოდულში გაცვლა CounterpartiesClient-თან.

დამატებულია პროცედურა გახსნისას, გამოძახებული დოკუმენტების სიის ფორმისა და დოკუმენტის ფორმის "On Opening" ღონისძიების დამმუშავებლისგან.
დამატებულია პროცედურა ProcessingAlerts_ListForm, გამოძახებული დოკუმენტების სიის ფორმის „შეტყობინებების დამუშავების“ ღონისძიების დამმუშავებლისგან. როგორც მეთოდის მეოთხე პარამეტრი, გადაეცემა სტრუქტურა, რომელიც ინიციალიზებულია მეთოდით Alert ParametersEDO_ListForm.
დამატებულია პროცედურა ProcessingAlert_FormDocument, გამოძახებული დოკუმენტის ფორმის "შეტყობინებების დამუშავების" მოვლენის დამმუშავებლისგან. როგორც მეთოდის მეოთხე პარამეტრი, გადაეცემა სტრუქტურა, რომელიც ინიციალიზებულია მეთოდით შეტყობინების ParametersEDO_DocumentForm.
ცვლილებები მოდულში ExchangewithCounterparties Overridable:
დამატებული მეთოდი შეავსეთ სამუშაოს შემსრულებლის მონაცემთა გადაცემა.
მაგალითი:

მეთოდი CheckAbility toEditObjectპროცედურად იქცა.
დამატებული მეთოდი შეავსეთ მონაცემები გამყიდველის ფედერალური საგადასახადო სამსახურის UPD ინფორმაციისთვის. მეთოდი ამზადებს მონაცემებს ამ ტიპის ელექტრონული დოკუმენტისთვის UPD(გამყიდველის ინფორმაცია) ფუნქცია SCHFDOP.
დამატებული მეთოდი FindCreateUniversalTransferDocument. მეთოდი ინახავს მონაცემებს ელექტრონული დოკუმენტიდან UPD(გამყიდველის ინფორმაცია) ფუნქცია SCHFDOPv IS ობიექტები.
დამატებული მეთოდი შეავსეთ მონაცემები UKDI გამყიდველის ინფორმაციის ფედერალური საგადასახადო სამსახურისთვის. მეთოდი ამზადებს მონაცემებს ამ ტიპის ელექტრონული დოკუმენტისთვის UKD(გამყიდველის ინფორმაცია) ფუნქცია KSCHFDIS.
დამატებული მეთოდი FindCreateUniversalAdjustmentDocument. მეთოდი ინახავს მონაცემებს ელექტრონული დოკუმენტიდან UKD(გამყიდველის ინფორმაცია) ფუნქცია KSCHFDISინფორმაციის უსაფრთხოების ობიექტებზე.

ცვლილებები „ბანკებთან გაცვლა“ ქვესისტემაში

ცვლილებები მოდულში ExchangeWithBanksRedefinable

ცვლილებები მომსახურების რეჟიმში მუშაობისთვის

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

პროცედურაში GetProvidedDataHandlers საერთო მოდულის SuppliedDataOverridden, დაამატეთ შემდეგი კოდი:

ElectronicInteraction.RegisterDeliveredDataHandlers(Handlers);

დაამატეთ რუტინული დავალება განახლება გარე მოდულების გაცვლა ბანკებთან ზოგად ატრიბუტზე Data Area Basic Data.

სხვა ცვლილებები

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

ვერსია 1.3.3

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

თავსებადობის რეჟიმი უნდა დაყენდეს „არ გამოიყენო“.
მოდალობის გამოყენების რეჟიმი შეიძლება დაყენდეს „არ გამოიყენო“.
ინტერფეისის თავსებადობის რეჟიმს შეუძლია მიიღოს მნიშვნელობები "Version 8.2", "Version 8.2. Allow Taxi" ან "Taxi. Allow Version 8.2".

ახალი ფუნქციები და ცვლილებები

2015 წლის 30 ნოემბრის No ММВ-7-10/551@ ბრძანებით „სავაჭრო ოპერაციების დროს საქონლის ელექტრონული ფორმით გადაცემის შესახებ დოკუმენტის წარდგენის ფორმატის დამტკიცების შესახებ“ და 2015 წლის 30 ნოემბრის No. ММВ-7-10/552@ „სამუშაო შედეგების (მომსახურების მიწოდების დოკუმენტი) ელექტრონული ფორმით გადაცემის შესახებ დოკუმენტის წარდგენის ფორმატის დამტკიცების შესახებ“ მხარდაჭერილია ელექტრონული დოკუმენტების ახალი ფორმატები.

გადასვლა 1.3.2.19 ვერსიაზე 1.2.7, 1.3.1 ვერსიებიდან

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

მოდულში ExchangewithCounterparties Overridableგააკეთე ცვლილება:

ჩვენ ვაგრძელებთ იმას, რაც უკვე ბევრი გავაკეთეთ.

ჩერნომირდინი ვ.ს.

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

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

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

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

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

როგორ დაიწყო 1C? გავიხსენოთ!

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

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

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

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

დღეს 1C კომპანია უზრუნველყოფს მთელ ეკოსისტემას თავისი კლიენტებისთვის:

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

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

1C განახლებები: როგორ მუშაობს

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

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

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

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

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

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

მოდულარობის ნაკლებობა: რატომ არის ეს ასე მნიშვნელოვანი

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

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

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

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

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

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

ლიცენზირების პოლიტიკა და შეცდომები სისტემაში

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

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

მნიშვნელოვანი პრობლემა: პლატფორმის ქცევის არაპროგნოზირებადობა განახლებისას.

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

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

ასე რომ, პროგრამისტისთვის სიტუაცია ასე გამოიყურება:

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

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

რატომ არის ამდენი შეცდომები?

შეცდომების სიმრავლის მთავარი მიზეზი, ჩემი მოკრძალებული აზრით, სისტემის სირთულეა. გახსოვდეთ, ახლა 1C პლატფორმა ხელმისაწვდომია Windows 32 და 64 ბიტისთვის, Linux-ისთვის, სერვერის ვერსიისთვის, მობილურისთვის და ა.შ. შენარჩუნების სირთულე ძალიან მაღალია და როგორც პრაქტიკა გვიჩვენებს, 1C დეველოპერები უბრალოდ ვერ უმკლავდებიან შენარჩუნებას.

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

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

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

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

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

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

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

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

მაგრამ მომხმარებელთა უმრავლესობა იყენებს მხოლოდ 4 კონფიგურაციას:

საწარმოს აღრიცხვა
ვაჭრობის მენეჯმენტი
საწარმოო ქარხნის მართვა
ხელფასი და HR მენეჯმენტი

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

მოდულარობის ნაკლებობა
ნაყარი და ბევრი არასაჭირო ფუნქცია
ახალი შეცდომები ახალ ვერსიებში
განახლების არაპროგნოზირებადი შედეგები

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

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

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

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

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

აგრესიული მარკეტინგი და მისი შედეგები

ძალიან ხშირად ჩემი კლიენტები აყენებენ განახლებებს ჩემი რჩევის საწინააღმდეგოდ. Რატომ ხდება ეს?

პროგრამისტის მოტივაცია

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

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

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

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

აგრესიული მარკეტინგი 1C-დან

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

მომსახურების და ფრენჩაიზინგის ნაკლოვანებები

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

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

სინამდვილეში, 1C კომპანია პრაქტიკულად არ მუშაობს პარტნიორებთან:

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

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

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

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

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

და აქ ჩნდება 1C პროგრამისტებისა და თავად პროგრამული პროდუქტის მიმართ ნეგატივის მიზეზებიც.
როდესაც შევწყვიტე მუშაობა მხოლოდ 1C-თან და დავიწყე ბიზნეს კონსულტაცია, დავიწყე სხვადასხვა პროგრამული პროდუქტის გამოყენება ჩემს საქმიანობაში. ეს იყო საიტები Drupal-ზე და სისტემები, როგორიცაა ZOHO CRM, ATOL RMK, Redmine და მრავალი სხვა სისტემა. და თითქმის ყველა ეს სერვისი და პროგრამა არ საჭიროებს მუდმივ და ხშირ განახლებას. და განახლებისას არც ისე ბევრი პრობლემაა.

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

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

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

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

1C: Bitrix - სირთულეები, მახასიათებლები, მარკეტინგი

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

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

რა შედეგი მოჰყვა?

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

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

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

Bitrix და 1C: სხვადასხვა სისტემები, საერთო ნაკლოვანებები

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

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

რეზიუმეს ნაცვლად

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

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

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

მომხმარებლების მხრიდან ნეგატიურობა გამოწვეულია:

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

ნეგატივი 1C პროგრამისტების მიმართ ასევე ნათელი ხდება:

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

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

ტეგები: ტეგების დამატება

შეიძლება სასარგებლო იყოს წაკითხვა: