Kaitēkļu kontrole
Darījuma partneru statuss slikti 1s ko. Pāreja uz elektronisko dokumentu plūsmu bez papīra: pieredze, problēmas, perspektīvas

Darījuma partneru statuss slikti 1s ko. Pāreja uz elektronisko dokumentu plūsmu bez papīra: pieredze, problēmas, perspektīvas

Versija 1.3.8 ir 1.3 izdevuma "1C: Electronic Document Library 8" izstrāde, kas paredzēta, lai nodrošinātu elektronisko dokumentu apmaiņu lietojumprogrammu risinājumos, kas izstrādāti uz 1C:Enterprise platformas versijas 8.3.10.2252 un jaunākas versijas.

Jaunas funkcijas un izmaiņas

Tirdzniecības piedāvājumu meklēšanas formā ir pievienota iespēja meklēt bez savienojuma ar pakalpojumu 1C: Business Network, kā arī ir pievienota iespēja meklēt piegādātāju pēc nosaukuma.
Pievienots pārskats par publicētajiem tirdzniecības piedāvājumiem.
Ir pievienota darba vieta tirdzniecības piedāvājumu publicēšanai pakalpojumā 1C:Business Network.
Adaptācija veikta ar apakšsistēmām "1C: Standarta apakšsistēmu bibliotēka" versiju 2.4.2, "1C: Library of Internet User Support" versiju 2.2.2.

Pāreja uz versiju 1.3.8 no versijas 1.3.7

Pievienots noteiktais veids Darījuma partnerisBED, noteikts tips Darījuma partneris dzēsts Atjauninot Obligāti iestatiet jaunu datu tipu, pretējā gadījumā dzēšana dati par darījumu partneriem apakšsistēmas objektos Exchange darījuma partneri(dokuments Elektronisko dokumentu pakete, informācijas reģistrs BED darījuma partneru statuss).

Moduļa izmaiņas:

Pievienota funkcija Pieprasīt tekstu publicētajiem produktiem iegūt datu avotu tirdzniecības piedāvājumu publicēšanai un publicēto preču pārskata ģenerēšanai. Saņemot produktu sarakstu, ir nepieciešams ieviest funkcijas izsaukumu uz FillOfferPackage metodi.

Izmaiņas modulī Tirdzniecības piedāvājumi

Pievienota procedūra UpdateDecorationConditionsPublikācijas lai atjauninātu veidlapas elementu Dekorācija ar publicēšanas stāvokli. Veidlapas izsaukumam ir jāpievieno statusa elementa publicēšanas iestatījumi.

Pievienota loma ReportsTradingOffers nepieciešams, lai piekļūtu pārskatam Publicēti tirdzniecības piedāvājumi.

Versija 1.3.7

Versija 1.3.7 ir 1.3 izdevuma "1C: Electronic Document Library 8" izstrāde, kas paredzēta, lai nodrošinātu elektronisko dokumentu apmaiņu lietojumprogrammu risinājumos, kas izstrādāti 1C:Enterprise platformas versijā 8.3.10 un jaunākā versijā.

Konfigurācijas rekvizītu vērtības:

Saderības režīmam jābūt iestatītam uz "Nelietot".
Modalitātes lietošanas režīmu var iestatīt uz "Nelietot".
Interfeisa saderības režīmam var būt vērtības "Version 8.2", "Version 8.2. Allow Taxi" vai "Taxi. Allow Version 8.2".

Jaunas funkcijas un izmaiņas

Pievienota iespēja no Sberbank iegūt maksājuma dokumenta statusu.
Ieviesta automātiska Sberbank iestatījumu saņemšana, pieslēdzoties pakalpojumam 1C:DirectBank.
Pievienota iespēja parādīt kontekstuālo reklāmu 1C:DirectBank.
Ir veikta pielāgošana darbam ar 1C: Business Network pakalpojumu 1CFresh mākoņpakalpojumā.
Pievienota iespēja publicēt, meklēt un pasūtīt tirdzniecības piedāvājumus pakalpojumā 1C: Tirdzniecības piedāvājumi pakalpojuma 1C: Business Network dalībniekiem.
Adaptācija tika veikta ar apakšsistēmām "1C: Standarta apakšsistēmu bibliotēka" versija 2.4.1, "1C: Library of Internet User Support" versija 2.1.9, "1C: Library of Service Technology" versija 1.0.12.

Apakšsistēma "Apmaiņa ar darījumu partneriem"

Moduļa izmaiņas:

DocumentDate, DocBaseDate

Apakšsistēma "Apmaiņa ar bankām"

Izmaiņas modulī Darbs ar FilesOverridable:

Uz procedūru Definējot iestatījumus jums jāpievieno kods:

ElectronicInteraction.WhenDefiningSettings(Settings);

Uz procedūru Definējot failu krātuves direktorijus jums jāpievieno kods:

Elektroniskā mijiedarbība. Definējot FileStorage direktorijus (File OwnerType, DirectoryNames);

Apmaiņas plānam UpdateInformationBase ir pievienoti direktoriji MessageExchangeWithBanksAttachedFiles un EDAttachedFiles
Katalogi MessageExchangeWithBanksAttachedFiles un EDAttachedFiles ir pievienoti definētajam tipam SignedObject.

Klientu Banka) pārvietot elementu grupu no vispārējās formas.

Veidlapas notikumu apstrādātājā Kad CreatedOnServer

&Serverī

…

Procedūras beigas

Veidlapas notikumu apstrādātājā Apstrādes brīdinājumi

&OnClient

…
// Elektroniskā mijiedarbība. Apmaiņa ar bankām

Elements.GroupAdvertisingDirectBankHorizontally, Elements.TextDirectBankHorizontally);
// Beigt elektronisko mijiedarbību. Apmaiņa ar bankām
Procedūras beigas

Elementam TextDirectBankHorizontāli pievienot notikumu apstrādātāju Navigācijas saišu apstrāde

&OnClient

Procedūras beigas

Uz kopīgu moduļa procedūru Elektroniskā mijiedarbība Maksājuma uzdevums lietojumprogrammas risinājumā.

Apakšsistēma "Apmaiņa ar vietnēm"

Izmaiņas modulī Site ExchangeOverridable:

Pievienota procedūra Pievienot DetailsFormNode, ko izmanto, lai pievienotu informāciju apmaiņas plāna mezgla veidlapai Apmaiņa ar vietni. Apmaiņas mezgla veidlapa neuzņemas ar lietojumprogrammas risinājumu saistīto detaļu klātbūtni; informācija tiek pievienota programmatiski.
Pievienota procedūra Ievades lauks, kadChangedOnServer, tiek izmantots, lai ziemeļos apstrādātu notikumu Kad tiek mainīts apmaiņas plāna mezgla formas ievades lauks, pievieno procedūrā Add NodeFormDetails.
Pievienota procedūra Izvēles rūtiņaFieldWhenChangedOnServer, tiek izmantots, lai apstrādātu notikumu serverī Kad tiek mainīts apmaiņas plāna mezgla formas karoga lauks, kas pievienots procedūrā Add NodeFormDetails.
Pievienota procedūra KadCreatingOnServerFormCreateSite, ko izmanto, lai pievienotu detalizētu informāciju apstrādes veidlapai CreateSite.

Izmaiņas modulī ExchangeSiteClientOverridable:

Noņemta procedūra Definējiet GroupTableU kataloga veidu, Produktu kataloga tabulas kolonnas Grupas vērtības veidu nosaka apmaiņas iestatījumi.
Pievienota procedūra InputFieldOnChange, tiek izsaukts, lai apstrādātu notikumu Kad tiek mainīts apmaiņas plāna mezgla formas ievades lauks, pievienots procedūrā SiteExchangeOverridden.AddNodeFormDetails.
Pievienota procedūra Izvēles rūtiņa FieldOnChange, tiek izsaukts, lai apstrādātu notikumu Kad tiek mainīts SiteExchangeOverridden.AddNodeFormDetails procedūrā pievienotās apmaiņas plāna mezgla formas karoga lauks.
Pievienota procedūra Tabulas veidlapaBeforeFinishRediģēt, tiek izsaukts, lai apstrādātu procedūrā SiteExchangeOverridden.AddNodeFormDetails pievienotā apmaiņas plāna mezgla formas tabulas lauka notikumu BeforeFinishEdit.

Apakšsistēma "Biznesa tīkls"

Pievienotas jaunas metodes rutīnas uzdevumu izpildei sadalītajā režīmā, kopējais modulis Elektroniskā mijiedarbība, procedūras Saņemot veidņu sarakstu, . Skatiet tāda paša nosaukuma metodes vispārīgajā modulī JobQueueOverridable.
Iegulstot bibliotēku, lai strādātu sadalītā režīmā, vispārīgajā modulī ir jāpievieno metožu izsaukums JobQueueOverridable:
- procedūrā Saņemot veidņu sarakstu:

// Elektroniskā mijiedarbība
ElectronicInteraction.OnReceivingListTemplates(TaskTemplates);

procedūrā Definējot aizstājvārdu apstrādātājus:

// Elektroniskā mijiedarbība
ElectronicInteraction.WhenDefiningHandlerAliases(MatchNamesAliases);
// Beigt elektronisko mijiedarbību

Izmaiņas modulī BusinessNetworkOverridable:
- procedūra pārdēvēta par Iegūstiet lietotāja kontaktinformāciju.
- procedūra mainīta uz funkciju Izveidojiet darījuma partnerisaskaņā ar detaļām, konta parametrs ir noņemts.

Apakšsistēma "Tirdzniecības piedāvājumi"

Ir pievienota jauna apakšsistēma "Tirdzniecības piedāvājumi", kuras iegulšanai nepieciešams:

Kopējos moduļos izstrādāt ignorētas metodes TradeOffersClientOverridable, TradeOffersOverridable.
Norādiet datu tipus noteiktajos tipos Detaļu vērtību veidi 1СBusinessNetwork, Nomenklatūras veidi BED, Papildus informācija GULTA, Tirdzniecības piedāvājums.

Plašāku informāciju skatiet iegulšanas dokumentācijā.

Versija 1.3.6

Versija 1.3.6 ir 1.3 izdevuma "1C: Electronic Document Library 8" izstrāde, kas paredzēta, lai nodrošinātu elektronisko dokumentu apmaiņu lietojumprogrammu risinājumos, kas izstrādāti 1C:Enterprise platformas versijā 8.3.8 un jaunākā versijā. Šajā gadījumā konfigurācijas rekvizītam "Saderības režīms" jābūt iestatītam uz "Version 8.3.8".

Šī konfigurācija ir paredzēta kopīgai lietošanai ar konfigurāciju "1C: Standarta apakšsistēmu bibliotēka", kas nav zemāka par versiju 2.3.4.112, ar konfigurāciju "1C: Interneta lietotāju atbalsta bibliotēka 8" ne zemāka par versiju 2.1.9.4.

Jaunas funkcijas un izmaiņas

Primāro rēķinu dokumentu formāti tiek atbalstīti (atsevišķa primārā dokumenta, rēķina nodošanas ziņā) saskaņā ar Federālā nodokļu dienesta 2016. gada 24. marta rīkojumu Nr. ММВ-7-15/155@ “Par apstiprināšanu rēķina formātu un dokumenta noformējuma formātu par preču nosūtīšanu (darbu veikšanu), īpašuma tiesību nodošanu (dokumentu par pakalpojumu sniegšanu), tai skaitā rēķinu, elektroniskā veidā."
Tiek atbalstīti primāro dokumentu par vērtības izmaiņām, tostarp korekcijas rēķina, formāti (atsevišķa primārā dokumenta, korekcijas rēķina pārsūtīšanas ziņā) saskaņā ar Federālā nodokļu dienesta 2016. gada 13. aprīļa rīkojumu N ММВ -7-15/189@ " Par korekcijas rēķina formāta un dokumenta par nosūtīto preču (veikto darbu, sniegto pakalpojumu) izmaksu izmaiņām, nodotajām īpašuma tiesībām, tai skaitā korekcijas rēķina, iesniegšanas formāta apstiprināšanu plkst. elektroniskā formā."
Pievienoti jauni elektroniskie dokumenti: Preču nodošana, Darba rezultātu pārskaitīšana, jauna dokumentu vizuālās noformēšanas forma.
Ir pievienots vienvirziena apmaiņas mehānisms, kas neprasa adresāta paziņojumu par saņemšanu.
Pievienota iespēja kontrolēt ienākošo elektronisko dokumentu izsaiņošanu (automātiski vai manuāli), iespēja konfigurēt noteikta veida dokumenta izveidi, saņemot elektroniskos dokumentus.
Pievienota iespēja sasaistīt elektronisku dokumentu ar vairākiem informācijas bāzes grāmatvedības dokumentiem.
Ir ieviests elektronisko dokumentu dalījums ienākošajos un izejošajos.
Ir ieviesta integrācija ar pakalpojumu 1C-UMIļaujot no programmas izveidot vietnes, izveidot apmaiņu ar tiešsaistes veikalu UMI.
Tika veikta pielāgošana darbam ar 1C-EDO pakalpojumu 1CFresh mākoņpakalpojumā.

Pāreja uz versiju 1.3.6 no versijas 1.3.5

Apakšsistēma "Apmaiņa ar darījumu partneriem"

Vispārējais modulis ExchangewithCounterpartiesRedefinable

Pievienota metode UPD SCHFDOP.
Pievienota metode Aizpildiet datus UPD pircēja informācijai Federālais nodokļu dienests. Metode sagatavo datus UPD (pircēja informācija) funkcijas SCHFDOP tipa elektroniskajam dokumentam.
Informācijas drošības objektiem pievienota UPD metodes (pārdevēja informācija) funkcija SCHFDOP.
Pievienota metode Aizpildiet Pārdevēja Federālā nodokļu dienesta PAPILDU INFORMĀCIJAS datus. Metode sagatavo datus elektroniskam dokumentam, piemēram, STD (pārdevēja informācija) DOP funkcijai.
Pievienota metode FindCreate UPDT DocumentAboutTransfer. Metode saglabā datus no elektroniskā dokumenta UPD (pārdevēja informācija) funkcijas DOP IS objektā.
Pievienota metode Aizpildiet datus SCHFISeller informācijai Federālais nodokļu dienests. Metode sagatavo datus elektroniskam dokumentam tipa UTD (pārdevēja informācija) SSF funkcijai.
Pievienota metode FindCreateUPDSinvoiceInvoice. Metode saglabā datus no elektroniskā dokumenta UPD (pārdevēja informācija) SSF funkcijas informācijas drošības objektā.
Pievienota metode. Metode sagatavo datus UCD tipa (pārdevēja informācija) funkcijas KSCHFDIS elektroniskajam dokumentam.
Pievienota metode Aizpildiet datus par UKID pircēja informāciju Federālais nodokļu dienests. Metode sagatavo datus elektroniskam dokumentam tipa UKD (pircēja informācija) funkcijas KSCHFDIS.
Pievienota metode. Metode saglabā datus no elektroniskā dokumenta UCD (pārdevēja informācija) funkcijas KSCHFDIS informācijas drošības objektos.
Pievienota metode Aizpildiet Pārdevēja Federālā nodokļu dienesta DISinformācijas datus. Metode sagatavo datus UCD tipa (pārdevēja informācija) DIS funkcijas elektroniskajam dokumentam.
Pievienota metode FindCreateUKDDocumentAboutChangeValue. Metode saglabā datus no elektroniskā dokumenta UCD (pārdevēja informācija) funkcijas DIS IS objektā.
Pievienota metode Aizpildiet datus KSCHFISeller informācijai Federālais nodokļu dienests. Metode sagatavo datus UCD tipa (pārdevēja informācija) funkcijas KSCHF elektroniskajam dokumentam.
Pievienota metode FindCreateUKDSAccountInvoice. Metode saglabā datus no elektroniskā dokumenta UCD (pārdevēja informācija) funkcijas KSCHF informācijas drošības objektā.
Pievienota metode Izejošo ED veidu atbilstība informācijas drošības dokumentiem. Metode veido korespondenci starp izejošajiem elektroniskajiem dokumentiem un informācijas drošības dokumentiem.
Pievienota metode FindCreateDocumentTransferWorkResults. Metode tiek izmantota, lai aizpildītu Pavadzīmes dokumentu, kas saņemts formātā “Preču nodošana”.
Pievienota metode FindCreateDocument Preču pārsūtīšana. Metode tiek izmantota, lai aizpildītu “Darba rezultātu nodošanas” formātā saņemto dokumentu Sertifikāts par pakalpojumu sniegšanu.
Pievienota metode InstalledStateExchangeCompleted. Metode tiek izsaukta, kad dokumenta plūsmas stāvoklis mainās uz ExchangeCompleted, ApmaiņaPabeigta ar labojumu.
Veidojot elektroniskos dokumentus UPD, UKD, Preču nodošana, Darba rezultātu nodošana, rekvizīti DocumentDate, DocBaseDate ir jāaizpilda.

Apmaiņas apstrāde ar darījumu partneriem

Izkārtojumā "Torg-12Seller":

Pievienots lauks "IdStateContract".
Papildināta tabulas daļa "Transporta rēķins".
Lauki "Transport InvoiceDate", "Transport InvoiceNumber" ir noņemti.
Pievienots lauks "Informācija par personu, kas nodevusi preces".

Izkārtojumā Tiesību nodošanas akts:

Pievienota tabulas daļa "Bāze".
Lauki "DocumentBaseName", "DocumentBaseNumber", "DocumentBaseDate", "DocumentBaseAdditionalInformation" ir noņemti.
Pievienots lauks "CurrencyName".
Pievienots lauks "Pretenzijas".
Pievienots lauks "Izpildes datums".
Darījuma dalībnieku rekvizītos lauks "Fakss" ir aizstāts ar lauku "E-pasts".
Darījuma dalībnieku rekvizītos lauks "Valsts kods" ir aizstāts ar lauku "Valsts kods".
Darījuma dalībnieku rekvizītos lauks "AddressText" ir aizstāts ar lauku "AddressText".

Noteikta veida atjaunināšana Darījuma partneris:

Veicot jaunināšanu no versijas 1.3.5, ir jāatjaunina definētais tips Counterparty; pretējā gadījumā atsauces uz Darījuma partnera direktoriju BED objektos, kad tās tiks atjauninātas, tiks aizstātas ar virknes tipu, zaudējot atsauces uz objektiem bez iespējas atveseļošanās.

Atjaunināšanas procedūra:

Pārdēvējiet definēto kontu veidu uz AccountBED.
Noņemiet konfigurāciju no atbalsta BED 1.3.5.
Veiciet salīdzināšanu/apvienošanu ar BED 1.3.5 konfigurāciju, piekrītiet iestatīt konfigurāciju atbalstam.
Noņemiet atzīmi no visiem objektiem un atstājiet tikai definēto konta veidu, veiciet sapludināšanu.
Sāciet konfigurācijas atjaunināšanu, izvēlieties BED failu 1.3.6.
Atzīmējiet izvēles rūtiņas definētajiem veidiem AccountBED un Account. Norādiet citus nepieciešamos datu bāzes objektus atjaunināšanai.
Veiciet atjaunināšanu.

Apakšsistēma "Maiņa ar bankām"

Uz procedūru Saņemiet bankas izrakstu kopējais modulis ExchangeWithBanksClient pievienots izvēles parametrs OpenFormClarificationPeriod ar tipu Būla. Tam jābūt iestatītam uz True, ja veidlapā, no kuras tiek saņemts izraksts, nav iespējas manuāli mainīt izraksta pieprasījuma periodu.

Apakšsistēma "Apmaiņa ar vietnēm"

Mainīts apmaiņas mezgls Vietņu apmaiņa, forma, objekta modulis:

Pievienota iespēja augšupielādēt preces ar atlasi pēc vienumu veidiem (iepriekš tā bija pieejama tikai pēc vienumu grupām).

Pievienota uzziņu grāmata Vietnes:

Pievienota iespēja konfigurēt pāreju uz vietni no 1C - uz vietnes lietotāja daļu un vietnes administratora apgabalu.
Pamatojoties uz vietni, varat izveidot ExchangeSite apmaiņas mezglu.

Pievienota apstrāde Izveidojiet vietni:

Pievienota iespēja izveidot vietni domēnā 1C-UMI; vietne tiek izveidota automātiski (vietņu elements) un aizpildīta ar datiem no 1C. Automātiski tiek izveidots ExchangeSite apmaiņas mezgls un tiek veikta pirmā pilnā apmaiņa ar vietni.

Vispārējais modulis Site ExchangeOverridable:

Ir pievienota iespēja atlasīt vienumu veidus; iespēja atlasīt pielāgotu uzziņu grāmatu ir noņemta.

Vispārējais modulis ExchangeSiteEvents:

Pievienota iespēja atlasīt vienumu veidus.
Iespēja atlasīt pielāgotu direktoriju ir noņemta.

Citas izmaiņas

Apakšsistēmas iestatīšana Tarifu vadība bibliotēkas apkalpošanas modelī Servisa tehnoloģijas

Uz kopējo moduli Tarifikācija atkārtoti definējama metodē Veidojot pakalpojumu sarakstu (), pēc metodes InternetUser Support izsaukšanas jāpievieno kods. Veidojot pakalpojumu sarakstu (pakalpojumu sniedzēji):

// Elektroniskā mijiedarbība
Elektroniskā mijiedarbība. Veidojot pakalpojumu sarakstu (pakalpojumu sniedzēji);
// Beigt elektronisko mijiedarbību

Versija 1.3.5

Versija 1.3.5 ir "1C: Electronic Document Libraries 8" 1.3 izdevuma izstrāde, kas paredzēta, lai nodrošinātu elektronisko dokumentu apmaiņu lietojumprogrammu risinājumos, kas izstrādāti platformas 1C:Enterprise versijā 8.3.8 un jaunākā versijā.

Konfigurācijas rekvizītu vērtības:

Saderības režīmam jābūt iestatītam uz "Nelietot".
Modalitātes lietošanas režīmu var iestatīt uz "Nelietot".
Interfeisa saderības režīmam var būt vērtības "Version 8.2", "Version 8.2. Allow Taxi" vai "Taxi. Allow Version 8.2".

Jaunas funkcijas un izmaiņas

bibliotēkas funkcionalitāte tika pielāgota 8.3.8 platformas specifiskajām iezīmēm ar atspējotu saderības režīmu;
"Standarta apakšsistēmu bibliotēkas" apakšsistēmas ir atjauninātas uz versiju 2.3.3.45;
Bibliotēkā iekļauta apakšsistēma "Interneta lietotāju atbalsta bibliotēkas", versija 2.1.8.3.

Pāreja uz versiju 1.3.5 no versijas 1.3.4

Izmaiņas nav nepieciešamas.

Versija 1.3.4

Versija 1.3.4 ir "1C: Electronic Document Libraries 8" izdevuma 1.3 izstrāde, kas paredzēta, lai nodrošinātu elektronisko dokumentu apmaiņu lietojumprogrammu risinājumos, kas izstrādāti platformas 1C:Enterprise versijā 8.3.6 un jaunākā versijā. Šajā gadījumā konfigurācijas rekvizītam "Saderības režīms" jābūt iestatītam uz "Nelietot". Modalitātes lietošanas režīmu var iestatīt uz "Nelietot", un saskarnes saderības režīmu var iestatīt uz "Version 8.2", "Version 8.2. Allow Taxi" vai "Taxi. Allow Version 8.2".

Jaunas funkcijas un izmaiņas

ieviesta paziņojumu sistēma par EDI notikumiem (jauni elektroniskie dokumenti, jauni ielūgumi, sertifikāta derīguma termiņš u.c.). Tagad ir iespējams konfigurēt e-pasta paziņojumus EDF iestatījumu profilā, kā arī parādīt paziņojumus par notikumiem tieši programmā 1C, izmantojot uznirstošos ziņojumus;
tiek atbalstīts primārā dokumenta formāts, ieskaitot rēķinu (UPD formātā) saskaņā ar Federālā nodokļu dienesta 2016. gada 24. marta rīkojumu Nr. ММВ-7-15/155@ “Par rēķina formāta apstiprināšanu un dokumenta par preču nosūtīšanu (darba veikšanu), īpašuma tiesību nodošanu (dokumentu par pakalpojumu sniegšanu), tai skaitā rēķina, iesniegšanas formāts elektroniskā veidā”;
ir atbalstīts vērtības izmaiņu dokumenta formāts, kurā iekļauts korekcijas rēķins" (UKD formāts) saskaņā ar Federālā nodokļu dienesta rīkojumu 13.04.2016 N ММВ-7-15/189@ "Par korekcijas rēķina un prezentācijas formāta dokumenta par nosūtīto preču (veikto darbu, sniegto pakalpojumu) pašizmaksas izmaiņām, nodotajām īpašuma tiesībām, tajā skaitā korekcijas rēķina, formāta apstiprināšanu elektroniskā veidā";
atbalstīja ārējo komponentu izmantošanu apmaiņā ar bankām, izmantojot DirectBank tehnoloģiju.

Pāreja uz versiju 1.3.4 no versijām 1.3.2, 1.3.3

Izmaiņas pieteikumu risinājumu dokumentu sarakstu formās

Dokumentu saraksta veidlapās ir jāpievieno spraudņa procedūra Apmaiņa ar CounterpartiesClient.Waiting ProcessorEDW:

&OnClient

Procedūras beigas

Atjauninot apakšsistēmu, dokumentu saraksta formas notikumu apstrādātājos ir nepieciešams: Kad CreatedOnServer, Atverot, Apstrādes brīdinājumi

&Serverī
Procedūra, veidojot serverī
…
ParametersWhenCreatedOnServer = ExchangeWithCounterpartities.ParametersWhenCreatedOnServer_ListForm();
ParametersWhenCreatedOnServer.Form = ThisObject;
ParametersWhenCreatedOnServer.LocationofCommands = Elements.EDO komandas;
ExchangewithCounterparties.WhenCreatedOnServer_ListForm(Failure, StandardProcessing, ParametersWhenCreatedOnServer);
Procedūras beigas

&OnClient
Atvēršanas procedūra (neveiksme)
…
// Apakšsistēma "Apmaiņa ar darījumu partneriem".
// Apakšsistēmas "Darījuma partneru apmaiņa" beigas.
Procedūras beigas

&OnClient
Procedūras procesa paziņojumi (notikuma nosaukums, parametrs, avots)
…
// Apakšsistēma "Apmaiņa ar darījumu partneriem".
Alert ParametersEDO = apmaiņa ar CounterpartiesClient.AlertParametersEDO_ListForm();
EDO Notification Parameters.Form = ThisObject;
EDO Notification Parameters.DynamicListName = "Saraksts";
ExchangewithCounterpartiesClient.ProcessingAlert_ListForm(Notikuma nosaukums, Parametrs, Avots, EDI brīdinājuma parametri);
// Apakšsistēmas "Darījuma partneru apmaiņa" beigas.
Procedūras beigas

Izmaiņas pieteikuma risinājuma dokumentu veidlapās

Dokumentu veidlapās jāpievieno spraudņa procedūra Connectable_WaitingHandlerEDO, kur jāievieto metodes izsaukums

Apmaiņa ar CounterpartiesClient.Waiting ProcessorEDW:

&OnClient
Procedūra Connectable_EDOWaitingHandler()
ExchangeCounterpartiesClient.EDOWaitingHandler(ThisObject);
Procedūras beigas

Dokumentu formās nepieciešams noņemt formas atribūtu “EDO statuss” un tā vietā pievienot formas elementu “dekorācija”. Aplikācijas risinājuma vajadzībām apdare var tikt pakārtota formas elementam "Grupa". Grupas redzamība ir iestatīta metodes ietvaros Apmaiņu ar darījuma partneriem Kad izveidots serverī atkarībā no f.o. stāvokļa. "Izmantot apmaiņu ar darījuma partneriem."

Atjauninot apakšsistēmu, tas ir nepieciešams dokumentu formas notikumu apstrādātājos Kad CreatedOnServer, Atverot, AfterRecordingOnServer, Apstrādes brīdinājumi vietu apakšsistēmas "Darījuma partneru apmaiņa" metodes.

Piemēram:

&Serverī

…
// Apakšsistēma "Apmaiņa ar darījumu partneriem".
EDO parametri, kad izveidots = apmaiņa ar darījuma partneriem Parametri, kad tiek izveidots serverī_DocumentForm();
EDO parametri, kad izveidots.Form = ThisObject;
EDO parametri, kad izveidots.DocumentLink = Object.Link;
EDO ParametersWhenCreated.DecorStateEDO = Elements.DecorationStateEDO;
EDO parametri, kad tie izveidoti.EDO stāvokļa grupa = Elements.EDO State Group;
Apmaiņu ar darījuma partneriem.Kad ir izveidotsServera_dokumenta veidlapā (atteikums, standarta apstrāde, EDO parametri, kad izveidots);
// Apakšsistēmas "Darījuma partneru apmaiņa" beigas.
Procedūras beigas

&OnClient
Atvēršanas procedūra (neveiksme)
…
// Apakšsistēma "Apmaiņa ar darījumu partneriem"
ExchangeWithCounterpartiesClient.OnOpening(ThisObject);
// Beigt apakšsistēmu "Apmaiņa ar darījumu partneriem"
Procedūras beigas

&Serverī
Procedūra AfterRecordOnServer (pašreizējais objekts, ieraksta parametri)
…
// Apakšsistēma "Apmaiņa ar darījumu partneriem".
ParametersAfterRecord = ExchangeWithCounterparties.ParametersAfterRecordOnServer();
ParametersAfterRecord.Form = ThisObject;
ParametersAfterRecord.DocumentLink = Object.Link;
ParametersAfterRecording.DecorationStateEDO = Elements.DecorationStateEDO;
ParametersAfterRecord.GroupEDOStatus = Elements.GroupEDOState;
Exchange ar darījuma partneriem.AfterRecordOnServer(CurrentObject, RecordParameters,AfterRecordParameters);
// Apakšsistēmas "Darījuma partneru apmaiņa" beigas.
Procedūras beigas

&OnClient
Procedūras procesa paziņojumi (notikuma nosaukums, parametrs, avots)
…
// Apakšsistēma "Apmaiņa ar darījumu partneriem".
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(Notikuma nosaukums, Parametrs, Avots, AlertParameters);
// Apakšsistēmas "Darījuma partneru apmaiņa" beigas.
Procedūras beigas

Izmaiņas ExchangeCounterparties modulī

Pievienota procedūra Kad CreatedOnServer_ListForm, izsaukts no dokumentu saraksta veidlapas notikumu apstrādātāja “When CreatedOnServer”. Kā trešais metodes parametrs tiek nodota struktūra, kuru inicializē metode ParametriCreatingOnServer_ListForm.
Pievienota procedūra Kad CreatedOnServer_FormDocument, izsauca no dokumenta veidlapas notikumu apstrādātāja “When CreatedOnServer”. Kā trešais metodes parametrs tiek nodota struktūra, kuru inicializē metode ParametriCenCreatingOnServer_DocumentForm.
Pievienota procedūra AfterRecordingOnServer, izsauca no dokumenta veidlapas notikumu apstrādātāja "AfterRecordOnServer". Kā trešais metodes parametrs tiek nodota struktūra, kuru inicializē metode ParametersAfterRecordingOnServer.

Izmaiņas modulī Apmaiņa ar CounterpartiesClient.

Pievienota procedūra Atverot, izsaukts no dokumentu saraksta veidlapas un dokumentu veidlapas notikumu apstrādātāja "Atvēršanas laikā".
Pievienota procedūra ProcessingAlerts_ListForm, izsaukts no dokumentu saraksta veidlapas notikumu apstrādātāja "Paziņojumu apstrāde". Kā ceturtais metodes parametrs tiek nodota struktūra, kas tiek inicializēta ar metodi Brīdinājuma parametriEDO_ListForm.
Pievienota procedūra ProcessingAlert_FormDocument, izsaukts no dokumenta veidlapas notikumu apstrādātāja "Paziņojumu apstrāde". Kā ceturtais metodes parametrs tiek nodota struktūra, kas tiek inicializēta ar metodi Paziņojuma parametriEDO_DocumentForm.
Izmaiņas modulī Apmaiņa ar darījuma partneriem Ierobežojama:
Pievienota metode Aizpildiet Darba izpildītāja datu pārsūtīšanu.
Piemērs:

// Sagatavo datus elektroniskam dokumentam, kura veids ir Preču nodošana pārdevējam.
// Opcijas:
// LinkToObject — saite uz ED, ar kuru nepieciešams ģenerēt elektronisku dokumentu,

Procedūra Aizpildiet datu pārsūtīšanas darbu izpildītāju (objekta saite, ED struktūra, datu koks) eksportēt
Aizpildiet Federālā nodokļu dienesta likuma 501 izpildītāja datus (saite uz objektu, ED struktūra, datu koks)
Procedūras beigas

Metode Iespēja rediģēt objektu kļuva par procedūru.
Pievienota metode Aizpildiet Pārdevēja Federālā nodokļu dienesta UPDI informāciju. Metode sagatavo datus šāda veida elektroniskam dokumentam UPD(pārdevēja informācija) funkcija SCHFDOP.
Pievienota metode FindCreateUniversalTransferDocument. Metode saglabā datus no elektroniskā dokumenta UPD(pārdevēja informācija) funkcija SCHFDOPv IS objekti.
Pievienota metode Aizpildiet UKDI Pārdevēja informācijas Federālā nodokļu dienesta datus. Metode sagatavo datus šāda veida elektroniskam dokumentam UKD(pārdevēja informācija) funkcija KSCHFDIS.
Pievienota metode FindCreateUniversalAdjustmentDocument. Metode saglabā datus no elektroniskā dokumenta UKD(pārdevēja informācija) funkcija KSCHFDIS uz informācijas drošības objektiem.

Izmaiņas apakšsistēmā "Maiņa ar bankām".

Izmaiņas modulī ExchangeWithBanksRedefinable

Procedūra Kad mainās ED stāvoklis pievienots. Izsauc, kad mainās elektronisko dokumentu plūsmas stāvoklis.

Izmaiņas darbam servisa režīmā

Ja ir nepieciešama mērķa konfigurācija darbībai servisa režīmā:

Kopējā moduļa SuppliedDataOverridden procedūrā GetProvidedDataHandlers pievienojiet šādu kodu:

ElectronicInteraction.RegisterDeliveredDataHandlers(Handlers);

Pievienojiet rutīnas uzdevumu Atjaunināt ārējo moduļu apmaiņu ar bankām vispārīgajam atribūtam Datu apgabals Pamatdati.

Citas izmaiņas

Definējamajam tipam jāpievieno konstante UseExchangeWithBanks;
Noņemta funkcija Maiņa ar bankām. Ieteicama tiešā maiņa ar banku.

Versija 1.3.3

Versija 1.3.3 ir produkta "1C: Elektronisko dokumentu bibliotēka" 1.3 izdevuma izstrāde. Paredzēts tādu konfigurāciju izstrādei, kas paredzētas darbam platformas 1C:Enterprise 8.3 versijā 8.3.6 un jaunākās versijās.

Konfigurācijas rekvizītu vērtības:

Saderības režīmam jābūt iestatītam uz "Nelietot".
Modalitātes lietošanas režīmu var iestatīt uz "Nelietot".
Interfeisa saderības režīmam var būt vērtības "Version 8.2", "Version 8.2. Allow Taxi" vai "Taxi. Allow Version 8.2".

Jaunas funkcijas un izmaiņas

saskaņā ar 2015.gada 30.novembra Rīkojumu Nr.ММВ-7-10/551@ "Par tirdzniecības darījumu laikā dokumenta par preču nodošanu iesniegšanas formāta apstiprināšanu elektroniskā veidā" un 2015.gada 30.novembra Rīkojumu Nr. ММВ-7-10/552@ "Par darba rezultātu nodošanas dokumenta (pakalpojumu sniegšanas dokumenta) iesniegšanas formāta apstiprināšanu elektroniskā formā" tiek atbalstīti jauni elektronisko dokumentu formāti.

Izmaiņas apakšsistēmā "Apmaiņa ar darījumu partneriem"

Modulī Apmaiņa ar darījuma partneriem Ierobežojama veikt izmaiņas:

// Sagatavo datus Pavadzīmes tipa elektroniskajam dokumentam.
// Opcijas:
// LinkOnED — saite uz ED, ar kuru nepieciešams ģenerēt elektronisku dokumentu,
// StructureED - Struktūra, datu struktūra elektroniska dokumenta ģenerēšanai.
// Datu koks - vērtību koks, datu koks elektroniskā dokumenta aizpildīšanai.
Procedūra Preču pārdevēja datu pārsūtīšanas aizpildīšanas (objekta saite, ED struktūra, datu koks) eksports
Aizpildiet datus par sarunām 12 Federālā nodokļu dienesta pārdevējs (saite uz objektu, ED struktūra, datu koks)
Procedūras beigas

Konfigurācijai, kas izmanto BED, ir jāpievieno veidnes, lai ierobežotu piekļuvi ierakstu līmenī pēc organizācijas (RLS), strādājot ar elektroniskajiem dokumentiem (skatiet iegulšanas dokumentāciju).

Versija 1.3.2

Versija 1.3.2 ir produkta "1C: Elektronisko dokumentu bibliotēka" 1.3 izdevuma izstrāde. Paredzēts tādu konfigurāciju izstrādei, kas paredzētas darbam platformas 1C:Enterprise 8.3 versijā 8.3.6 un jaunākās versijās.

Konfigurācijas rekvizītu vērtības:

Saderības režīmam jābūt iestatītam uz "Nelietot".
Modalitātes lietošanas režīmu var iestatīt uz "Nelietot".
Interfeisa saderības režīmam var būt vērtības "Version 8.2", "Version 8.2. Allow Taxi" vai "Taxi. Allow Version 8.2".

Jaunas funkcijas un izmaiņas

ieviesta 2 nosaukumu elektronisko dokumentu (TORG12, Akts, Korekciju dokumenti) attēlošana vienotā formā elektroniskā dokumenta apskatei. Visa informācija no nosaukumiem tiks apkopota vienā veidlapā. Atsevišķi otrā virsraksta formu var apskatīt no formas “Elektroniskie dokumenti”;
ir ieviesta iespēja slēgt standarta “EDA līgumu” elektroniskā formā no “EDF iestatījumiem” programmā 1C; Izmantojot komandu “Izveidot līgumu, izmantojot veidni”, automātiski tiks izveidots patvaļīgs elektronisks dokuments, kura pielikums būs līguma fails. Pēc parakstīšanas dokumentu var nekavējoties nosūtīt darījuma partnerim.
integrēta patvaļīgu elektronisko dokumentu apmaiņa ar pievienotajiem failiem. Tagad jebkuru pievienoto failu var ātri parakstīt un nosūtīt darījuma partnerim, izmantojot jebkuru elektronisku dokumentu;
tiek atbalstīta iespēja apmainīties ar elektroniskajiem dokumentiem ar banku par algu projektu;
pievienots palīgs organizācijas savienošanai ar DirectBank;
ar interneta starpniecību tika atjaunināts to banku saraksts, kuras atbalstīja DirectBank;
Atbalstīts darbs ar dažāda veida Sberbank žetoniem (elektroniskajām atslēgām): “parastais”, “pieskāriens”, “ar ekrānu”.
"Standarta apakšsistēmu bibliotēkas" (BSS) apakšsistēmas ir atjauninātas uz versiju 2.3.2.27.

Pāreja uz versiju 1.3.2.19 no versijām 1.2.7, 1.3.1

Modulim jāpievieno procedūra bez polsterējuma:

procedūra CheckUsingTestMode. Ietver iespēju iespējot papildu funkcijas, lai pārbaudītu apmaiņu ar bankām. Pagaidām nav plānots to izmantot lietišķos risinājumos;

Modulī RegularTasksOverridable veikt izmaiņas:

Kārtējo uzdevumu (iestatījumu) eksportēšanas iestatījumu noteikšanas procedūra
Elektroniskā mijiedarbība. Kad tiek definēti rutīnas uzdevumu iestatījumi (iestatījumi);
Procedūras beigas

Modulī ElectronicSignatureClientOverridable veikt izmaiņas:

Papildu sertifikāta (parametru) pārbaudes procedūra
ExchangeWithBanksClient.AtAdditionalCertificateVerification(Parameters);
Procedūras beigas

Uz moduli Electronic SignatureOverridable veikt izmaiņas:

Veidlapas izveides procedūra Sertifikāta pārbaude (sertifikāta, papildu pārbaudes, papildu pārbaužu parametri, standarta pārbaudes) eksports
ExchangeWithBanks.WhenCreatingFormVerificationCertificate(
Sertifikāts, papildu pārbaudes, papildu pārbaudes parametri, standarta pārbaudes);
Procedūras beigas

Ir pievienoti šādi nekoplietotie objekti:

;

Pastāvīgi Vispārēja failu apmaiņa ar bankām.

Uz noteiktu veidu Uzglabāšanas telpa Funkcionālās opcijas pievienot konstanti UseExchangeWithBanks.

Ja konfigurācija ir paredzēta darbam pakalpojuma modeļa režīmā, tad jums ir jāmaina abonementu apdarinātājs uz notikumu Nekopīgotu objektu kontrole, rakstot BED uz WorkIn the Service Model.Control of Unshared Objects While Writing.

Versija 1.3.1

Versija 1.3.1 ir produkta "1C: Elektronisko dokumentu bibliotēka" 1.2 izdevuma izstrāde. Paredzēts tādu konfigurāciju izstrādei, kas paredzētas darbam platformas 1C:Enterprise 8.3 versijā 8.3.6 un jaunākās versijās.

Konfigurācijas rekvizītu vērtības:

Saderības režīmam jābūt iestatītam uz "Nelietot".
Modalitātes lietošanas režīmu var iestatīt uz "Nelietot".
Interfeisa saderības režīmam var būt vērtības "Version 8.2", "Version 8.2. Allow Taxi" vai "Taxi. Allow Version 8.2".

Jaunas funkcijas un izmaiņas

1C: Business Network dalībniekiem ir ieviesta iespēja apmainīties ar elektroniskajiem dokumentiem bez elektroniskā paraksta, izmantojot EDI pakalpojumu;
ieviesta autonoma apmaiņas apakšsistēma ar bankām;
"Standarta apakšsistēmu bibliotēkas" (BSS) apakšsistēmas ir atjauninātas uz versiju 2.3.1.71.

Pāreja uz versiju 1.3.1 no versijām 1.2.6, 1.2.7

Arhitektūras izmaiņas

Visi moduļi ar prefiksu "Elektroniskie dokumenti" ir pārdēvēti par moduļiem ar prefiksu "Apmaiņa ar darījumu partneriem". Moduļu metodes Vispārējs mērķisED pārvietots uz jaunu moduli Elektroniskā mijiedarbība. Modulis ED informācijas bāzes atjaunināšana pārdēvēta par Datu bāzes atjaunināšana.

Elektroniskie dokumenti V Elektroniskā mijiedarbība:

UzvārdsInicialipersonas

No moduļa pārvietoto metožu saraksts Elektroniskie dokumenti V ExchangeWithBanks:

Iespējama tiešā maiņa ar banku
GetDataBankStatementsTreeValues
GetDataBankStatementsTextFormat
TreeExtractsBank parsēšana

To metožu saraksts, kuras ir pārvietotas no moduļa uz ElectronicInteractionClientOverridable:

Veiciet dokumentu pārbaudi

No moduļa pārvietoto metožu saraksts ElectronicDocumentsClientOverridable V ExchangeWithBanksClientOverridable:

ParseFileExtracts

To metožu saraksts, kuras ir pārvietotas no moduļa uz ElectronicInteractionClientServer:

GetMessageText (pārdēvēts par MessageText)
TurAction

No moduļa pārvietoto metožu saraksts Elektronisko dokumentu klientu serveris V ExchangeWithBanksClientServer:

Aizpildīta informācijaIestatījumi EDSBanks (pārdēvēts Aizpildīto Aizpildītu informācijuIestatījumu apmaiņa)
HeaderSettingsEDOSBank ir pārdēvēta par HeaderSettingsExchangeWithBank
GetStatusTextED

To metožu saraksts, kuras ir pārvietotas no moduļa uz ElectronicInteractionOverridable:

ChangeFormElementProperties
CurrentDirectoryTemporaryFiles
Iegūstiet atbilstošas funkcionālās opcijas
Iegūstiet atbilstošus katalogus
Iegūstiet atbilstību objektu nosaukumiem MD un detaļām
Detaļu un pārstāvju kodeksu atbilstība
Iegūstiet objekta galvenās detaļas struktūru
ĪsziņaNepieciešamiSistēmas iestatījumi
Rediģēt kļūdas ziņojumu
Sagatavojiet ziņojumu par piekļuves tiesību pārkāpumu
DisassembleNameIndividuals
FindReferenceToObject
Iegūstiet drukātā dokumenta numuru
Pārbaudiet gatavības avotus
GetData LegalIndividuals
AprakstsOrganizācijas
Ir tiesības apstrādāt ED
Ir tiesības lasīt ED
Ir tiesības atvērt žurnāla reģistrāciju

No moduļa pārvietoto metožu saraksts ElectronicDocumentsOverridable V ExchangeWithBanksOverridable:

Iegūstiet pašreizējos ED veidus
Iegūstiet bankas konta numurus
Aizpildiet ED ParametersBy Source
Aizpildiet Maksājuma uzdevuma datus
Aizpildiet maksājuma pieprasījuma datus
Iespēja rediģēt objektu

No pasākumu abonementiem Piešķiriet jaunu ED versiju, ierakstot īpašnieku Un CheckChangeBeforeRecordingOwnerED Bankas dokumenti tika izdzēsti.

Izkārtojumi pārvietoti no apstrādes Exchange darījuma partneri V ExchangeWithBanks:

Maksājuma uzdevums
Maksājuma prasība

Jums jāpievieno noteiktajam veidam

documentObject.PackageED

Interfeisa izmaiņas

Kopējos moduļos ExchangeWithBanks, Exchange darījuma partneri pievienotas procedūras Kad CreatedOnServer. Tiek izsaukts, atverot objektu formas, lai ģenerētu EDI komandas. Iespējas: Veidlapa- pašreizējā forma, Komandas izvietojumsNoklusējums– apakšizvēlnes formas elements, kurā tiks izveidotas EDI komandas.
Kopējos moduļos ExchangeWithBanksOverridable, Apmaiņa ar darījuma partneriem Ierobežojama pievienotas procedūras EDM komandu saraksta ģenerēšanai Sagatavot komandu EDF objektu struktūru. Parametrs TeamsEDO sastāvs var būt masīvs (apakšsistēmai ExchangeWithBanks) vai masīva struktūra ( Exchange darījuma partneri).
EDI komandu grupa ir noņemta, komandu paneļa automātiska aizpildīšana ar EDI komandām vairs netiek veikta.

Lai izveidotu EDM komandas informācijas bāzes dokumentu formās, ir jāpievieno kods, lai ģenerētu objektu tipus ignorētā kopējā moduļa procedūrā.

Piemērs modulī Apmaiņa ar darījuma partneriem Ierobežojama:

EDM komandu sastāvs. Outgoing.Add("Dokuments. Preču un pakalpojumu pārdošana");
EDO komandu sastāvs.Outgoing.Add("Dokuments.Pircēja pasūtījums");
…
EDF komandu sastāvs.Incoming.Add("Dokuments.Preču un pakalpojumu saņemšana");
EDO komandu sastāvs.Incoming.Add("Document.InvoiceReceived");
…
Procedūras beigas

ExchangeWithBanksOverridable:

Procedūra EAF komandu objektu struktūras sagatavošana (EDF komandu sastāvs) eksports
EDO Commands.Add sastāvs ("Dokuments. Maksājuma uzdevums");
EDO Commands.Add("Dokuments.PaymentRequest") sastāvs;
…
Procedūras beigas

Veidojot formu, izsauciet programmas komandu ģenerēšanu

Apmaiņu ar darījuma partneriem. Izveidojot serverī:

Procedūra, kad tiek izveidots serverī (kļūme, standarta apstrāde)
//EDO komandas
Apmaiņu ar darījuma partneriem.When CreatedOnServer(ThisObject, Elements.EDO Commands);
// EDO komandas beigas
Procedūras beigas

Pievienojiet pievienojamu veidlapu apstrādātāju Connectable_Execute EDO komanda:

Procedūra Connectable_Execute EDO komanda (komanda)
ElectronicInteractionServiceClient.ExecuteConnectedCommandEDO(Command, ThisForm, Elements.List);
Procedūras beigas

Izmaiņas apakšsistēmā "Apmaiņa ar darījumu partneriem"

aizpildiet definēto veidu "Patvaļīgas ED pamatojums" ar dokumentu veidiem, uz kuru pamata tiks veikti ieraksti Patvaļīgs ED(visticamāk, tie būs tie paši dokumenti, kas definētajā tipa Pievienoto failu īpašnieks), arī šajos dokumentos ir jāpievieno dokuments “Pielāgots ED” sarakstam “Ir pamatā:”
dokumentu veidlapās un dokumentu sarakstos (uz kuru pamata tiek ievadīts Pielāgotais ED) apakšizvēlnē “Izveidot, pamatojoties uz” nepieciešams atspējot Custom ED, jo komanda Custom ED ievadīšanai tiek ievietota EDO apakšizvēlnē (komanda "Pievienot failu");
parametru grupā Tiesību nodošanas akta, Preču pasūtījuma, Atbildes uz pasūtījumu, Komisāra ziņojuma par pārdošanu, Komisāra ziņojuma par aprakstu, Rēķina apmaksai, Preču kataloga, Cenrādis maketos. "Banka" laukā "BIC" ir mainīts obligātās aizpildīšanas atribūts. Šis lauks ir jāaizpilda;
izkārtojumā InvoiceInvoice ir mainīts laukiem Izcelsmes valsts kods un Muitas deklarācijas numurs formāts. Pareizākai aizpildīšanai tie tiek apvienoti Muitas deklarācijas tabulā. Šo elementu aizpildīšanas piemēru ESF datu sagatavošanas procedūrā var atrast BED demo datubāzē.

Izmaiņas modulī ExchangewithCounterpartiesClient

OpenEDList metode ir novecojusi. Tā vietā ieteicams izmantot OpenEDTree, kas paver lietotājam noteikumu koku elektronisko dokumentu apmaiņai informācijas drošības dokumentam.

Izmaiņas elektroniskās mijiedarbības modulī ignorētas

Saņemt atbilstību objektu nosaukumiem un detaļām ir pievienotas divas atslēgas atkārtotai definēšanai:

Preču un pakalpojumu pārdošana metadatos
Preču un pakalpojumu saņemšana metadatos

Izmaiņas ExchangeCounterparties modulī

Pievienota metode Fill DataBy 1SEDOD 1C-Reporting Master, kas sagatavo datus 1C-Reporting Master.

Pievienota metode Check AccounterV1EDMSWhen CreatedOnServer, kas jāizsauc, veidojot konta formu. Izmantojot šo metodi, tiek pārbaudīts darījuma partnera savienojums ar pakalpojumu 1C-EDO.
Piemērs Apmaiņu ar darījumu partneriem Pārbaudiet darījuma partneri 1 SEDO, kad tas ir izveidots serverī:

Procedūra, kad tiek izveidots serverī (kļūme, standarta apstrāde)
// Elektroniskā mijiedarbība. Apmaiņa ar darījumu partneriem
Apmaiņu ar darījuma partneriem Pārbaudiet darījumu partneri 1SEDO When CreatedOnServer(Object.Link);
// Beigt elektronisko mijiedarbību. Apmaiņa ar darījumu partneriem
Procedūras beigas

Pievienots NAV sadalīts rutīnas uzdevums Pārbauda darījuma partnerusBED, kas veic darījumu partneru atlasi un pārbauda to savienojumu ar 1C-EDO.

Pievienots sadalītās informācijas reģistrs Darījuma partneru statussBED, kurā tiek apkopota statistika par darbuzņēmējiem, kas savienoti ar pakalpojumu 1C-EDO.

Pievienojiet 1C-EDO pakalpojuma savienojuma zīmes displeju saraksta veidlapas kolonnā "EDO" un darījuma partnera atlases veidlapu. Pievienojiet mājienu kolonnai "Savienots ar pakalpojumu 1C-EDO".
Piemērs:

IZVĒLIES
IZVĒLE
WHENDarījuma partnera statussBED.Statuss = VĒRTĪBA(Uzskaitījums.Darījuma partnera stāvoklisBED.Savienots)
TAD 0
CITS 1
BEIGAS
BEIGAS KĀ EDO
KatalogsDarbpuses.Nosaukums,
KatalogsCounterparties.INN,
KatalogsDarbpuses.KPP,
....
KatalogsDarbpuses.VārdsPilns
NO
Katalogs.Darījumu partneri AS KatalogsDarījumu puses
KREISAIS SAVIENOJUMS Informācijas reģistrs Būvuzņēmēju statuss BED AS Līgumslēdzēju statuss BED
Programmatūra (Contractor StatesBED.Counterparty = DirectoryCounterparties.Link)

Informācijas bāzes dokumentu veidlapās no formas atribūta “ED State Text” nepieciešams noņemt saiti uz funkcionālo opciju “Izmantot ED Exchange”. Noņemiet galveni no atribūta “ED statuss”.

Izmaiņas apakšsistēmā "Maiņa ar bankām".

Pievienoti pasākumu abonementi ExchangeWithBanksOwnerEDBeforeRecording Un ExchangeWithBanksOwnerEDOnRecording.

Pievienoti noteikti veidi OwnersExchangeWithBanks un DirectoryBanks.
Pievienota vispārīgā komanda SettingsExchangeWithBanks.

Uz noteiktu veidu Pievienotais fails pievienot:

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

Uz noteiktu veidu Pievienoto failu īpašnieks nepieciešams pievienot

documentLink.MessageExchangeWithBanks;
documentLink.PackageExchangeWithBanks.

Uz noteiktu veidu OwnerAttachedFilesObject nepieciešams pievienot

documentObject.MessageExchangeWithBanks;
documentObject.PackageExchangeWithBanks;
documentObject.PackageED

Pievienota jauna apakšsistēma "Biznesa tīkls"

Apakšsistēmā ir kopīgi moduļi (prefikss ExchangeBusinessNetwork), ārstēšana Biznesa tīkls, lomas ( AdministrācijaSubscriberBusinessNetwork, PerformingExchangeBusinessNetwork), informācijas reģistrs IdentifiersBusinessNetwork. Veidlapā "Elektronisko dokumentu apmaiņas iestatīšana" ir pievienota komanda pakalpojuma savienojuma formas izsaukšanai.

Nepieciešams pabeigt procedūras un funkcijas modulī BusinessNetworkOverridable:

metodi Izveidojiet darījuma partnerisaskaņā ar detaļām. Izveido darījumu partneri lietojumprogrammas risinājumā, izmantojot nodotos parametrus;
metodi Iegūstiet IB lietotāju kontaktus. Saņem lietotāja kontaktinformāciju (lomas vārds, e-pasta adrese);
metodi Veiciet dokumenta detaļu kontroli. Pārbauda dokumenta informāciju, lai varētu nosūtīt masīvu (sūtītājam un saņēmējam ir jābūt vienam un tam pašam).

Pāreja uz versiju 1.3.7 no versijas 1.3.6

Veidlapā maksājuma dokumentu augšupielādei failā un bankas izraksta lejupielādei no faila (apstrāde Klientu Banka) pārvietot elementu grupu GroupAdvertisingDirectBankHorizontāli no vispārējās formas OfferConnect1SDirectBank.

Veidlapas notikumu apstrādātājā Kad CreatedOnServer vietas metodes ExchangeWithBanksClientServer.ShowAdvertisingDirectBank:

&Serverī
Procedūra, kad CreateOnServer (kļūme, standarta apstrāde)
…
// Elektroniskā mijiedarbība. Apmaiņa ar bankām
ExchangeWithBanksClientServer.ShowAdvertisingDirectBank(
Elements.GroupAdvertisingDirectBankHorizontally, Elements.TextDirectBankHorizontally);
// Beigt elektronisko mijiedarbību. Apmaiņa ar bankām
Procedūras beigas

Veidlapas notikumu apstrādātājā Apstrādes brīdinājumi ievietojiet metodi ExchangeWithBanksClient.UpdateAdvertisingDirectBank:

&OnClient
Procedūras procesa paziņojumi (notikuma nosaukums, parametrs, avots)
…
// Elektroniskā mijiedarbība. Apmaiņa ar bankām
ExchangeWithBanksClient.UpdateAdvertisingDirectBank(Notikuma nosaukums,
Elements.GroupAdvertisingDirectBankHorizontally, Elements.TextDirectBankHorizontally);
// Beigt elektronisko mijiedarbību. Apmaiņa ar bankām
Procedūras beigas

Elementam TextDirectBankHorizontāli pievienot notikumu apstrādātāju Navigācijas saišu apstrāde un ievietojiet tajā metodi ExchangeWithBanksClient.ProcessingNavigationLinkAdvertisingDirectBank:

&OnClient
Procedūra TextDirectBankHorizontalNavigationLinkProcessing (elements, FormattedStringNavigationLink, StandardProcessing)
ExchangeWithBanksClient.ProcessingNavigationLinkAdvertisingDirectBank(
NavigationLinkFormatString, StandardProcessing);
Procedūras beigas

Uz procedūru Iegūstiet atbilstību MDI objektu nosaukumiem un detaļām kopējais modulis Elektroniskā mijiedarbība pievienot atbilstības elementu ar atslēgu PaymentOrderInMetadata un vērtība: metadatu objekta nosaukums Maksājuma uzdevums lietojumprogrammas risinājumā.

09.06.2017

Izlaista standarta konfigurācijas "1C: Library of Electronic Documents 1.3" jauna versija 1.3.8.

Versija 1.3.8

Jaunas funkcijas un izmaiņas

Tirdzniecības piedāvājumu meklēšanas formā ir pievienota iespēja meklēt bez savienojuma ar pakalpojumu 1C: Business Network, kā arī ir pievienota iespēja meklēt piegādātāju pēc nosaukuma.
Pievienots pārskats par publicētajiem tirdzniecības piedāvājumiem.
Ir pievienota darba vieta tirdzniecības piedāvājumu publicēšanai pakalpojumā 1C:Business Network.
Adaptācija veikta ar apakšsistēmām "1C: Standarta apakšsistēmu bibliotēka" versiju 2.4.2, "1C: Library of Internet User Support" versiju 2.2.2.

Pāreja uz versiju 1.3.8 no versijas 1.3.7

Moduļa izmaiņas:

Pievienota funkcija Pieprasīt tekstu publicētajiem produktiem iegūt datu avotu tirdzniecības piedāvājumu publicēšanai un publicēto preču pārskata ģenerēšanai. Saņemot produktu sarakstu, ir nepieciešams ieviest funkcijas izsaukumu uz FillOfferPackage metodi.

Izmaiņas modulī Tirdzniecības piedāvājumi

Pievienota procedūra UpdateDecorationConditionsPublikācijas lai atjauninātu veidlapas elementu Dekorācija ar publicēšanas stāvokli. Veidlapas izsaukumam ir jāpievieno statusa elementa publicēšanas iestatījumi.

Pievienota loma ReportsTradingOffers nepieciešams, lai piekļūtu pārskatam Publicēti tirdzniecības piedāvājumi.

Versija 1.3.7

Konfigurācijas rekvizītu vērtības:

Saderības režīmam jābūt iestatītam uz "Nelietot".
Modalitātes lietošanas režīmu var iestatīt uz "Nelietot".
Interfeisa saderības režīmam var būt vērtības "Version 8.2", "Version 8.2. Allow Taxi" vai "Taxi. Allow Version 8.2".

Jaunas funkcijas un izmaiņas

Pievienota iespēja no Sberbank iegūt maksājuma dokumenta statusu.
Ieviesta automātiska Sberbank iestatījumu saņemšana, pieslēdzoties pakalpojumam 1C:DirectBank.
Pievienota iespēja parādīt kontekstuālo reklāmu 1C:DirectBank.
Ir veikta pielāgošana darbam ar 1C: Business Network pakalpojumu 1CFresh mākoņpakalpojumā.
Pievienota iespēja publicēt, meklēt un pasūtīt tirdzniecības piedāvājumus pakalpojumā 1C: Tirdzniecības piedāvājumi pakalpojuma 1C: Business Network dalībniekiem.
Adaptācija tika veikta ar apakšsistēmām "1C: Standarta apakšsistēmu bibliotēka" versija 2.4.1, "1C: Library of Internet User Support" versija 2.1.9, "1C: Library of Service Technology" versija 1.0.12.

Pāreja uz versiju 1.3.7 no versijas 1.3.6

Apakšsistēma "Apmaiņa ar darījumu partneriem"

Moduļa izmaiņas:

DocumentDate, DocBaseDate

Apakšsistēma "Apmaiņa ar bankām"

Izmaiņas modulī Darbs ar FilesOverridable:

Uz procedūru Definējot iestatījumus jums jāpievieno kods:

ElectronicInteraction.WhenDefiningSettings(Settings);

Uz procedūru Definējot failu krātuves direktorijus jums jāpievieno kods:

Elektroniskā mijiedarbība. Definējot FileStorage direktorijus (File OwnerType, DirectoryNames);

Apmaiņas plānam UpdateInformationBase ir pievienoti direktoriji MessageExchangeWithBanksAttachedFiles un EDAttachedFiles
Katalogi MessageExchangeWithBanksAttachedFiles un EDAttachedFiles ir pievienoti definētajam tipam SignedObject.

Veidlapas notikumu apstrādātājā Kad CreatedOnServer vietas metodes ExchangeWithBanksClientServer.ShowAdvertisingDirectBank:

&Serverī
Procedūra, kad CreateOnServer (kļūme, standarta apstrāde)
…
ExchangeWithBanksClientServer.ShowAdvertisingDirectBank(

Procedūras beigas

Veidlapas notikumu apstrādātājā Apstrādes brīdinājumi ievietojiet metodi ExchangeWithBanksClient.UpdateAdvertisingDirectBank:

&OnClient

…
// Elektroniskā mijiedarbība. Apmaiņa ar bankām
ExchangeWithBanksClient.UpdateAdvertisingDirectBank(Notikuma nosaukums,
Elements.GroupAdvertisingDirectBankHorizontally, Elements.TextDirectBankHorizontally);
// Beigt elektronisko mijiedarbību. Apmaiņa ar bankām
Procedūras beigas

Apakšsistēma "Apmaiņa ar vietnēm"

Izmaiņas modulī Site ExchangeOverridable:

Pievienota procedūra Pievienot DetailsFormNode, ko izmanto, lai pievienotu informāciju apmaiņas plāna mezgla veidlapai Apmaiņa ar vietni. Apmaiņas mezgla veidlapa neuzņemas ar lietojumprogrammas risinājumu saistīto detaļu klātbūtni; informācija tiek pievienota programmatiski.
Pievienota procedūra Ievades lauks, kadChangedOnServer, tiek izmantots, lai ziemeļos apstrādātu notikumu Kad tiek mainīts apmaiņas plāna mezgla formas ievades lauks, pievieno procedūrā Add NodeFormDetails.
Pievienota procedūra Izvēles rūtiņaFieldWhenChangedOnServer, tiek izmantots, lai apstrādātu notikumu serverī Kad tiek mainīts apmaiņas plāna mezgla formas karoga lauks, kas pievienots procedūrā Add NodeFormDetails.
Pievienota procedūra KadCreatingOnServerFormCreateSite, ko izmanto, lai pievienotu detalizētu informāciju apstrādes veidlapai CreateSite.

Izmaiņas modulī ExchangeSiteClientOverridable:

Noņemta procedūra Definējiet GroupTableU kataloga veidu, Produktu kataloga tabulas kolonnas Grupas vērtības veidu nosaka apmaiņas iestatījumi.
Pievienota procedūra InputFieldOnChange, tiek izsaukts, lai apstrādātu notikumu Kad tiek mainīts apmaiņas plāna mezgla formas ievades lauks, pievienots procedūrā SiteExchangeOverridden.AddNodeFormDetails.
Pievienota procedūra Izvēles rūtiņa FieldOnChange, tiek izsaukts, lai apstrādātu notikumu Kad tiek mainīts SiteExchangeOverridden.AddNodeFormDetails procedūrā pievienotās apmaiņas plāna mezgla formas karoga lauks.
Pievienota procedūra Tabulas veidlapaBeforeFinishRediģēt, tiek izsaukts, lai apstrādātu procedūrā SiteExchangeOverridden.AddNodeFormDetails pievienotā apmaiņas plāna mezgla formas tabulas lauka notikumu BeforeFinishEdit.

Apakšsistēma "Biznesa tīkls"

Pievienotas jaunas metodes rutīnas uzdevumu izpildei sadalītajā režīmā, kopējais modulis Elektroniskā mijiedarbība, procedūras Saņemot veidņu sarakstu, . Skatiet tāda paša nosaukuma metodes vispārīgajā modulī JobQueueOverridable.
Iegulstot bibliotēku, lai strādātu sadalītā režīmā, vispārīgajā modulī ir jāpievieno metožu izsaukums JobQueueOverridable:
- procedūrā Saņemot veidņu sarakstu:

// Elektroniskā mijiedarbība
ElectronicInteraction.OnReceivingListTemplates(TaskTemplates);

procedūrā Definējot aizstājvārdu apstrādātājus:

// Elektroniskā mijiedarbība
ElectronicInteraction.WhenDefiningHandlerAliases(MatchNamesAliases);
// Beigt elektronisko mijiedarbību

Izmaiņas modulī BusinessNetworkOverridable:
- procedūra pārdēvēta Iegūstiet IB lietotāju kontaktus V Iegūstiet lietotāja kontaktinformāciju.
- procedūra mainīta uz funkciju Izveidojiet darījuma partnerisaskaņā ar detaļām, konta parametrs ir noņemts.

Apakšsistēma "Tirdzniecības piedāvājumi"

Ir pievienota jauna apakšsistēma "Tirdzniecības piedāvājumi", kuras iegulšanai nepieciešams:

Kopējos moduļos izstrādāt ignorētas metodes TradeOffersClientOverridable, TradeOffersOverridable.
Norādiet datu tipus noteiktajos tipos Detaļu vērtību veidi 1СBusinessNetwork, Nomenklatūras veidi BED, Papildus informācija GULTA, Tirdzniecības piedāvājums.

Plašāku informāciju skatiet iegulšanas dokumentācijā.

Versija 1.3.6

Jaunas funkcijas un izmaiņas

Primāro rēķinu dokumentu formāti tiek atbalstīti (atsevišķa primārā dokumenta, rēķina nodošanas ziņā) saskaņā ar Federālā nodokļu dienesta 2016. gada 24. marta rīkojumu Nr. ММВ-7-15/155@ “Par apstiprināšanu rēķina formātu un dokumenta noformējuma formātu par preču nosūtīšanu (darbu veikšanu), īpašuma tiesību nodošanu (dokumentu par pakalpojumu sniegšanu), tai skaitā rēķinu, elektroniskā veidā."
Tiek atbalstīti primāro dokumentu par vērtības izmaiņām, tostarp korekcijas rēķina, formāti (atsevišķa primārā dokumenta, korekcijas rēķina pārsūtīšanas ziņā) saskaņā ar Federālā nodokļu dienesta 2016. gada 13. aprīļa rīkojumu N ММВ -7-15/189@ " Par korekcijas rēķina formāta un dokumenta par nosūtīto preču (veikto darbu, sniegto pakalpojumu) izmaksu izmaiņām, nodotajām īpašuma tiesībām, tai skaitā korekcijas rēķina, iesniegšanas formāta apstiprināšanu plkst. elektroniskā formā."
Pievienoti jauni elektroniskie dokumenti: Preču nodošana, Darba rezultātu pārskaitīšana, jauna dokumentu vizuālās noformēšanas forma.
Ir pievienots vienvirziena apmaiņas mehānisms, kas neprasa adresāta paziņojumu par saņemšanu.
Pievienota iespēja kontrolēt ienākošo elektronisko dokumentu izsaiņošanu (automātiski vai manuāli), iespēja konfigurēt noteikta veida dokumenta izveidi, saņemot elektroniskos dokumentus.
Pievienota iespēja sasaistīt elektronisku dokumentu ar vairākiem informācijas bāzes grāmatvedības dokumentiem.
Ir ieviests elektronisko dokumentu dalījums ienākošajos un izejošajos.
Ir ieviesta integrācija ar pakalpojumu 1C-UMIļaujot no programmas izveidot vietnes, izveidot apmaiņu ar tiešsaistes veikalu UMI.
Tika veikta pielāgošana darbam ar 1C-EDO pakalpojumu 1CFresh mākoņpakalpojumā.

Pāreja uz versiju 1.3.6 no versijas 1.3.5

Apakšsistēma "Apmaiņa ar darījumu partneriem"

Vispārējais modulis ExchangewithCounterpartiesRedefinable

Pievienota metode UPD SCHFDOP.
Pievienota metode Aizpildiet datus UPD pircēja informācijai Federālais nodokļu dienests. Metode sagatavo datus UPD (pircēja informācija) funkcijas SCHFDOP tipa elektroniskajam dokumentam.
Informācijas drošības objektiem pievienota UPD metodes (pārdevēja informācija) funkcija SCHFDOP.
Pievienota metode Aizpildiet Pārdevēja Federālā nodokļu dienesta PAPILDU INFORMĀCIJAS datus. Metode sagatavo datus elektroniskam dokumentam, piemēram, STD (pārdevēja informācija) DOP funkcijai.
Pievienota metode FindCreate UPDT DocumentAboutTransfer. Metode saglabā datus no elektroniskā dokumenta UPD (pārdevēja informācija) funkcijas DOP IS objektā.
Pievienota metode Aizpildiet datus SCHFISeller informācijai Federālais nodokļu dienests. Metode sagatavo datus elektroniskam dokumentam tipa UTD (pārdevēja informācija) SSF funkcijai.
Pievienota metode FindCreateUPDSinvoiceInvoice. Metode saglabā datus no elektroniskā dokumenta UPD (pārdevēja informācija) SSF funkcijas informācijas drošības objektā.
Pievienota metode. Metode sagatavo datus UCD tipa (pārdevēja informācija) funkcijas KSCHFDIS elektroniskajam dokumentam.
Pievienota metode Aizpildiet datus par UKID pircēja informāciju Federālais nodokļu dienests. Metode sagatavo datus elektroniskam dokumentam tipa UKD (pircēja informācija) funkcijas KSCHFDIS.
Pievienota metode. Metode saglabā datus no elektroniskā dokumenta UCD (pārdevēja informācija) funkcijas KSCHFDIS informācijas drošības objektos.
Pievienota metode Aizpildiet Pārdevēja Federālā nodokļu dienesta DISinformācijas datus. Metode sagatavo datus UCD tipa (pārdevēja informācija) DIS funkcijas elektroniskajam dokumentam.
Pievienota metode FindCreateUKDDocumentAboutChangeValue. Metode saglabā datus no elektroniskā dokumenta UCD (pārdevēja informācija) funkcijas DIS IS objektā.
Pievienota metode Aizpildiet datus KSCHFISeller informācijai Federālais nodokļu dienests. Metode sagatavo datus UCD tipa (pārdevēja informācija) funkcijas KSCHF elektroniskajam dokumentam.
Pievienota metode FindCreateUKDSAccountInvoice. Metode saglabā datus no elektroniskā dokumenta UCD (pārdevēja informācija) funkcijas KSCHF informācijas drošības objektā.
Pievienota metode Izejošo ED veidu atbilstība informācijas drošības dokumentiem. Metode veido korespondenci starp izejošajiem elektroniskajiem dokumentiem un informācijas drošības dokumentiem.
Pievienota metode FindCreateDocumentTransferWorkResults. Metode tiek izmantota, lai aizpildītu Pavadzīmes dokumentu, kas saņemts formātā “Preču nodošana”.
Pievienota metode FindCreateDocument Preču pārsūtīšana. Metode tiek izmantota, lai aizpildītu “Darba rezultātu nodošanas” formātā saņemto dokumentu Sertifikāts par pakalpojumu sniegšanu.
Pievienota metode InstalledStateExchangeCompleted. Metode tiek izsaukta, kad dokumenta plūsmas stāvoklis mainās uz ExchangeCompleted, ApmaiņaPabeigta ar labojumu.
Veidojot elektroniskos dokumentus UPD, UKD, Preču nodošana, Darba rezultātu nodošana, rekvizīti DocumentDate, DocBaseDate ir jāaizpilda.

Apmaiņas apstrāde ar darījumu partneriem

Izkārtojumā "Torg-12Seller":

Pievienots lauks "IdStateContract".
Papildināta tabulas daļa "Transporta rēķins".
Lauki "Transport InvoiceDate", "Transport InvoiceNumber" ir noņemti.
Pievienots lauks "Informācija par personu, kas nodevusi preces".

Izkārtojumā Tiesību nodošanas akts:

Pievienota tabulas daļa "Bāze".
Lauki "DocumentBaseName", "DocumentBaseNumber", "DocumentBaseDate", "DocumentBaseAdditionalInformation" ir noņemti.
Pievienots lauks "CurrencyName".
Pievienots lauks "Pretenzijas".
Pievienots lauks "Izpildes datums".
Darījuma dalībnieku rekvizītos lauks "Fakss" ir aizstāts ar lauku "E-pasts".
Darījuma dalībnieku rekvizītos lauks "Valsts kods" ir aizstāts ar lauku "Valsts kods".
Darījuma dalībnieku rekvizītos lauks "AddressText" ir aizstāts ar lauku "AddressText".

Noteikta veida atjaunināšana Darījuma partneris:

Atjaunināšanas procedūra:

Pārdēvējiet definēto kontu veidu uz AccountBED.
Noņemiet konfigurāciju no atbalsta BED 1.3.5.
Veiciet salīdzināšanu/apvienošanu ar BED 1.3.5 konfigurāciju, piekrītiet iestatīt konfigurāciju atbalstam.
Noņemiet atzīmi no visiem objektiem un atstājiet tikai definēto konta veidu, veiciet sapludināšanu.
Sāciet konfigurācijas atjaunināšanu, izvēlieties BED failu 1.3.6.
Atzīmējiet izvēles rūtiņas definētajiem veidiem AccountBED un Account. Norādiet citus nepieciešamos datu bāzes objektus atjaunināšanai.
Veiciet atjaunināšanu.

Apakšsistēma "Maiņa ar bankām"

Apakšsistēma "Apmaiņa ar vietnēm"

Mainīts apmaiņas mezgls Vietņu apmaiņa, forma, objekta modulis:

Pievienota iespēja augšupielādēt preces ar atlasi pēc vienumu veidiem (iepriekš tā bija pieejama tikai pēc vienumu grupām).

Pievienota uzziņu grāmata Vietnes:

Pievienota iespēja konfigurēt pāreju uz vietni no 1C - uz vietnes lietotāja daļu un vietnes administratora apgabalu.
Pamatojoties uz vietni, varat izveidot ExchangeSite apmaiņas mezglu.

Pievienota apstrāde Izveidojiet vietni:

Pievienota iespēja izveidot vietni domēnā 1C-UMI; vietne tiek izveidota automātiski (vietņu elements) un aizpildīta ar datiem no 1C. Automātiski tiek izveidots ExchangeSite apmaiņas mezgls un tiek veikta pirmā pilnā apmaiņa ar vietni.

Vispārējais modulis Site ExchangeOverridable:

Ir pievienota iespēja atlasīt vienumu veidus; iespēja atlasīt pielāgotu uzziņu grāmatu ir noņemta.

Vispārējais modulis ExchangeSiteEvents:

Pievienota iespēja atlasīt vienumu veidus.
Iespēja atlasīt pielāgotu direktoriju ir noņemta.

Citas izmaiņas

Apakšsistēmas iestatīšana Tarifu vadība bibliotēkas apkalpošanas modelī Servisa tehnoloģijas

// Elektroniskā mijiedarbība
Elektroniskā mijiedarbība. Veidojot pakalpojumu sarakstu (pakalpojumu sniedzēji);
// Beigt elektronisko mijiedarbību

Versija 1.3.5

Konfigurācijas rekvizītu vērtības:

Saderības režīmam jābūt iestatītam uz "Nelietot".
Modalitātes lietošanas režīmu var iestatīt uz "Nelietot".
Interfeisa saderības režīmam var būt vērtības "Version 8.2", "Version 8.2. Allow Taxi" vai "Taxi. Allow Version 8.2".

Jaunas funkcijas un izmaiņas

bibliotēkas funkcionalitāte tika pielāgota 8.3.8 platformas specifiskajām iezīmēm ar atspējotu saderības režīmu;
"Standarta apakšsistēmu bibliotēkas" apakšsistēmas ir atjauninātas uz versiju 2.3.3.45;
Bibliotēkā iekļauta apakšsistēma "Interneta lietotāju atbalsta bibliotēkas", versija 2.1.8.3.

Pāreja uz versiju 1.3.5 no versijas 1.3.4

Izmaiņas nav nepieciešamas.

Versija 1.3.4

Jaunas funkcijas un izmaiņas

ieviesta paziņojumu sistēma par EDI notikumiem (jauni elektroniskie dokumenti, jauni ielūgumi, sertifikāta derīguma termiņš u.c.). Tagad ir iespējams konfigurēt e-pasta paziņojumus EDF iestatījumu profilā, kā arī parādīt paziņojumus par notikumiem tieši programmā 1C, izmantojot uznirstošos ziņojumus;
tiek atbalstīts primārā dokumenta formāts, ieskaitot rēķinu (UPD formātā) saskaņā ar Federālā nodokļu dienesta 2016. gada 24. marta rīkojumu Nr. ММВ-7-15/155@ “Par rēķina formāta apstiprināšanu un dokumenta par preču nosūtīšanu (darba veikšanu), īpašuma tiesību nodošanu (dokumentu par pakalpojumu sniegšanu), tai skaitā rēķina, iesniegšanas formāts elektroniskā veidā”;
ir atbalstīts vērtības izmaiņu dokumenta formāts, kurā iekļauts korekcijas rēķins" (UKD formāts) saskaņā ar Federālā nodokļu dienesta rīkojumu 13.04.2016 N ММВ-7-15/189@ "Par korekcijas rēķina un prezentācijas formāta dokumenta par nosūtīto preču (veikto darbu, sniegto pakalpojumu) pašizmaksas izmaiņām, nodotajām īpašuma tiesībām, tajā skaitā korekcijas rēķina, formāta apstiprināšanu elektroniskā veidā";
atbalstīja ārējo komponentu izmantošanu apmaiņā ar bankām, izmantojot DirectBank tehnoloģiju.

Pāreja uz versiju 1.3.4 no versijām 1.3.2, 1.3.3

Izmaiņas pieteikumu risinājumu dokumentu sarakstu formās

Dokumentu saraksta veidlapās ir jāpievieno spraudņa procedūra Apmaiņa ar CounterpartiesClient.Waiting ProcessorEDW:

&OnClient

Procedūras beigas

Atjauninot apakšsistēmu, dokumentu saraksta formas notikumu apstrādātājos ir nepieciešams: Kad CreatedOnServer, Atverot, Apstrādes brīdinājumi

&OnClient
Atvēršanas procedūra (neveiksme)
…
// Apakšsistēma "Apmaiņa ar darījumu partneriem".
// Apakšsistēmas "Darījuma partneru apmaiņa" beigas.
Procedūras beigas

Izmaiņas pieteikuma risinājuma dokumentu veidlapās

Dokumentu veidlapās jāpievieno spraudņa procedūra Connectable_WaitingHandlerEDO, kur jāievieto metodes izsaukums

Apmaiņa ar CounterpartiesClient.Waiting ProcessorEDW:

&OnClient
Procedūra Connectable_EDOWaitingHandler()
ExchangeCounterpartiesClient.EDOWaitingHandler(ThisObject);
Procedūras beigas

Piemēram:

&Serverī
Procedūra, kad tiek izveidots serverī (kļūme, standarta apstrāde)
…
// Apakšsistēma "Apmaiņa ar darījumu partneriem".
EDO parametri, kad izveidots = apmaiņa ar darījuma partneriem Parametri, kad tiek izveidots serverī_DocumentForm();
EDO parametri, kad izveidots.Form = ThisObject;
EDO parametri, kad izveidots.DocumentLink = Object.Link;
EDO ParametersWhenCreated.DecorStateEDO = Elements.DecorationStateEDO;
EDO parametri, kad tie izveidoti.EDO stāvokļa grupa = Elements.EDO State Group;
Apmaiņu ar darījuma partneriem.Kad ir izveidotsServera_dokumenta veidlapā (atteikums, standarta apstrāde, EDO parametri, kad izveidots);
// Apakšsistēmas "Darījuma partneru apmaiņa" beigas.
Procedūras beigas

Izmaiņas ExchangeCounterparties modulī

Pievienota procedūra Kad CreatedOnServer_ListForm, izsaukts no dokumentu saraksta veidlapas notikumu apstrādātāja “When CreatedOnServer”. Kā trešais metodes parametrs tiek nodota struktūra, kuru inicializē metode ParametriCreatingOnServer_ListForm.
Pievienota procedūra Kad CreatedOnServer_FormDocument, izsauca no dokumenta veidlapas notikumu apstrādātāja “When CreatedOnServer”. Kā trešais metodes parametrs tiek nodota struktūra, kuru inicializē metode ParametriCenCreatingOnServer_DocumentForm.
Pievienota procedūra AfterRecordingOnServer, izsauca no dokumenta veidlapas notikumu apstrādātāja "AfterRecordOnServer". Kā trešais metodes parametrs tiek nodota struktūra, kuru inicializē metode ParametersAfterRecordingOnServer.

Izmaiņas modulī Apmaiņa ar CounterpartiesClient.

Pievienota procedūra Atverot, izsaukts no dokumentu saraksta veidlapas un dokumentu veidlapas notikumu apstrādātāja "Atvēršanas laikā".
Pievienota procedūra ProcessingAlerts_ListForm, izsaukts no dokumentu saraksta veidlapas notikumu apstrādātāja "Paziņojumu apstrāde". Kā ceturtais metodes parametrs tiek nodota struktūra, kas tiek inicializēta ar metodi Brīdinājuma parametriEDO_ListForm.
Pievienota procedūra ProcessingAlert_FormDocument, izsaukts no dokumenta veidlapas notikumu apstrādātāja "Paziņojumu apstrāde". Kā ceturtais metodes parametrs tiek nodota struktūra, kas tiek inicializēta ar metodi Paziņojuma parametriEDO_DocumentForm.
Izmaiņas modulī Apmaiņa ar darījuma partneriem Ierobežojama:
Pievienota metode Aizpildiet Darba izpildītāja datu pārsūtīšanu.
Piemērs:

Metode Iespēja rediģēt objektu kļuva par procedūru.
Pievienota metode Aizpildiet Pārdevēja Federālā nodokļu dienesta UPDI informāciju. Metode sagatavo datus šāda veida elektroniskam dokumentam UPD(pārdevēja informācija) funkcija SCHFDOP.
Pievienota metode FindCreateUniversalTransferDocument. Metode saglabā datus no elektroniskā dokumenta UPD(pārdevēja informācija) funkcija SCHFDOPv IS objekti.
Pievienota metode Aizpildiet UKDI Pārdevēja informācijas Federālā nodokļu dienesta datus. Metode sagatavo datus šāda veida elektroniskam dokumentam UKD(pārdevēja informācija) funkcija KSCHFDIS.
Pievienota metode FindCreateUniversalAdjustmentDocument. Metode saglabā datus no elektroniskā dokumenta UKD(pārdevēja informācija) funkcija KSCHFDIS uz informācijas drošības objektiem.

Izmaiņas apakšsistēmā "Maiņa ar bankām".

Izmaiņas modulī ExchangeWithBanksRedefinable

Procedūra Kad mainās ED stāvoklis pievienots. Izsauc, kad mainās elektronisko dokumentu plūsmas stāvoklis.

Izmaiņas darbam servisa režīmā

Ja ir nepieciešama mērķa konfigurācija darbībai servisa režīmā:

Kopējā moduļa SuppliedDataOverridden procedūrā GetProvidedDataHandlers pievienojiet šādu kodu:

ElectronicInteraction.RegisterDeliveredDataHandlers(Handlers);

Pievienojiet rutīnas uzdevumu Atjaunināt ārējo moduļu apmaiņu ar bankām vispārīgajam atribūtam Datu apgabals Pamatdati.

Citas izmaiņas

Uz noteiktu veidu Uzglabāšanas telpa Funkcionālās opcijas jāpievieno konstante UseExchangeWithBanks;
Noņemta funkcija Maiņa ar bankām. Ieteicama tiešā maiņa ar banku.

Versija 1.3.3

Konfigurācijas rekvizītu vērtības:

Saderības režīmam jābūt iestatītam uz "Nelietot".
Modalitātes lietošanas režīmu var iestatīt uz "Nelietot".
Interfeisa saderības režīmam var būt vērtības "Version 8.2", "Version 8.2. Allow Taxi" vai "Taxi. Allow Version 8.2".

Jaunas funkcijas un izmaiņas

saskaņā ar 2015.gada 30.novembra Rīkojumu Nr.ММВ-7-10/551@ "Par tirdzniecības darījumu laikā dokumenta par preču nodošanu iesniegšanas formāta apstiprināšanu elektroniskā veidā" un 2015.gada 30.novembra Rīkojumu Nr. ММВ-7-10/552@ "Par darba rezultātu nodošanas dokumenta (pakalpojumu sniegšanas dokumenta) iesniegšanas formāta apstiprināšanu elektroniskā formā" tiek atbalstīti jauni elektronisko dokumentu formāti.

Pāreja uz versiju 1.3.2.19 no versijām 1.2.7, 1.3.1

Izmaiņas apakšsistēmā "Apmaiņa ar darījumu partneriem"

Modulī Apmaiņa ar darījuma partneriem Ierobežojama veikt izmaiņas:

// Sagatavo datus Pavadzīmes tipa elektroniskajam dokumentam.
// Opcijas:
// LinkOnED — saite uz ED, ar kuru nepieciešams ģenerēt elektronisku dokumentu,
// StructureED - Struktūra, datu struktūra elektroniska dokumenta ģenerēšanai.
// Datu koks - vērtību koks, datu koks elektroniskā dokumenta aizpildīšanai.
Procedūra Datu aizpildīšanas par preču pārsūtīšanu pārdevējam (saite uz sējumu

Kolēģi!

Dažās konfigurācijās kļūdas neļauj lejupielādēt datus un līdz ar to iesniegt ziņojumu Federālajam nodokļu dienestam.

Darījumi ar darījuma partneri - kāpēc TIN/KPP pārbaude neiztur - ir ilgs process, un bieži vien jums vienkārši jāpārsūta informācija Federālajam nodokļu dienestam un, ja rodas jautājumi, jāiesniedz sertifikāts par darījumu partneri, lai tas var tikt ar to galā pats, nevis mēģināt pats atrisināt šo problēmu un saņemt naudas sodu par novēlotu ziņošanu.

Tagad mēs pievērsīsimies dažiem paņēmieniem, kā izkļūt no šādām situācijām, izmantojot 1C: Grāmatvedības 8. izdevuma konfigurācijas piemēru. 3.0.

Tātad, triks numurs 1: Iebūvētā darījuma partneru verifikācija grāmatvedībā 8 darbojas tikai ar darījuma partneriem, kuriem ir TIN/KPP. Ja noņemsiet TIN/KPP no darījuma partnera, kurš nav izturējis verifikāciju, kļūdas ziņojums netiks parādīts. Tas vienkārši tiek izslēgts no pārskata pārbaudes moduļa.

Triks Nr.2: Pārbaudot darījumu partnerus, tiek aizpildīts īpašs informācijas reģistrs: “Darījuma partneru statuss”. Tas ir tas, ar ko jums ir jāstrādā.

Izmantojot apmācības bāzes piemēru, mēs apsvērsim šo iespēju. Mums ir nepārbaudītu darījumu partneru saraksts:

Programma ziņo, ka, piemēram, Camellia darījuma partnera statuss “KPP neatbilst datiem Federālā nodokļu dienesta datubāzē”. Šāds darījuma partneris neizturēs pārbaudi, un programma neļaus lejupielādēt PVN atskaiti, kurā ir šāds darījuma partneris.

Ko var darīt?

Atveram informācijas reģistru “Darījuma partneru statuss” - Ch. izvēlne - Visas funkcijas - Informācijas reģistri:

Informācijas reģistrā “Līgumslēdzēja statuss” novietojiet kursoru uz rindas ar vēlamo darījuma partneri:

Un mēs mainām pārbaudes statusu no “Pārbaudes punkts neatbilst Federālā nodokļu dienesta datiem” uz “Darījuma partneris ir Federālā nodokļu dienesta datu bāzē”.

«(EDI) ne pārāk precīzi atspoguļo to, kas praksē tiek īstenots Krievijas uzņēmumos un organizācijās. Izrādījās, ka nereti runa bija (un ir) drīzāk par elektronisku atbalstu tradicionālajai papīra dokumentu plūsmai: vienkāršākajā gadījumā - par papīra dokumentu elektronisko karšu pārvaldību, sarežģītākā gadījumā - par to elektronisko kopiju papildu shēmas izveidi. Tomēr oriģināls šeit vienmēr ir papīra dokuments. Tāpēc šajā apskatā nolēmām lietot terminu “papīra elektroniskā dokumentu pārvaldība” (BED), apzīmējot “īstā” EDF ieviešanas iespēju, kad oriģinālie dokumenti tiek uzrādīti elektroniskā formātā. Vienlaikus vēlos uzsvērt, ka papīra dokumentu likvidēšana nav pašmērķis, bet tikai līdzeklis darba kvalitātes un efektivitātes uzlabošanai.

Diskusijas par pāreju uz BED notiek jau labu laiku, valsts līmenī - aktīvi kopš 2008. gada. Bet cik dinamisks un veiksmīgs ir šis process? Kādi ir iemesli, kāpēc šodienas rezultāti atšķiras no tiem, kas tika prognozēti pirms 7–10 gadiem? Lai saņemtu atbildes uz šiem jautājumiem, vērsāmies pie ekspertiem – EDMS/ECM rīku izstrādātājiem un tiem, kas iesaistīti šādu sistēmu ieviešanā un darbībā.

Kāda nozīme ir pārejai uz BED

Šī tēma kļūst arvien aktuālāka dažāda veida klientiem – gan komerciālām, gan valsts organizācijām, norāda Business Logic (IT Group) Alfresco prakses vadītājs Oļegs Beilezons. Visi jau burtiski slīkst papīra straumēs - tā fiziski kļūst par problēmu, daudzu darbinieku galddatori un kabineti ir nosēti ar izskatītiem, saskaņotiem, parakstītiem, uzglabātiem un “nodokļu atskaites” dokumentiem, un tas kļūst arvien grūtāk lai tās pārvaldītu. Viņaprāt, daudzi valdības regulatori (piemēram, Federālais nodokļu dienests) to ir sapratuši, un tāpēc stingri - pat obligātas prasības - iesaka pāriet uz formālo dokumentu elektronisku apriti.

Savukārt uzņēmuma EOS mārketinga nodaļas vadītāja Jeļena Ivanova atzīmē, ka, lai gan pāreja uz elektronisku dokumentu plūsmu ļauj uzņēmumiem samazināt izmaksas un palielināt biznesa procesu efektivitāti, tomēr jāņem vērā, ka šāda pārveide prasa noteiktas izmaksas, kas saistītas ar tehnoloģisko risinājumu ieviešanu, noteikumu maiņu, risku minimizēšanu, kas izriet no elektronisko dokumentu izmantošanas fakta. Kopumā situācija ir acīmredzama: jo lielāka ir papīra dokumentu plūsma, jo aktuālāks ir bezpapīra apmaiņas jautājums. Kā galvenos šķēršļus, kas bremzē šādu pāreju, viņa saskata nepieciešamību pēc papildu izmaksām “šobrīd” un darbinieku nevēlēšanos atteikties no ierastajiem procesiem un papīra dokumenta atribūtiem. Taču izstrādātājiem ir rīki, kas var pārvarēt ieviešanas problēmas.

Taču šobrīd, ieilgušās ekonomiskās krīzes apstākļos, ne visi uzņēmumi ir gatavi to darīt, norāda ELAR Corporation ECM risinājumu attīstības nodaļas vadītājs Dmitrijs Šmailovs. Turklāt BED nav tāda biznesa prioritāte kā, teiksim, ražošanas automatizācija, risinājumi kritiskiem uzdevumiem un sistēmas, kuru mērķis ir samazināt izmaksas, t.i., projekti, kas var nest naudu.

InterTrust ģenerāldirektora vietnieks biznesa attīstības jautājumos Vadims Ipatovs atgādina, ka līdzās organizatoriskām un tehnoloģiskām problēmām pastāv arī normatīvās prasības, kas mūsdienās lielā mērā joprojām ir vērstas uz papīra oriģinālu izmantošanu. Jo īpaši joprojām neatrisināti paliek jautājumi par dokumentu ilgtermiņa (un īpaši mūžīgu) glabāšanu. Šķiet, ka šādu dokumentu īpatsvars to kopējā apjomā ir neliels, taču tas kā enkurs bremzē atteikšanos no papīra oriģināliem kopumā.

Ja runājam par dokumentiem, kas tiek izmantoti kā saziņas līdzeklis, tad mūsdienās visizplatītākais mehānisms ir e-pasts. Šķiet, ka šeit nav organizatorisku, juridisku vai tehnisku problēmu. Taču patiesībā e-pasts ievieš tradicionālo papīra mijiedarbības versiju, kas, automātiski ieviešot, rada milzīgus informācijas apjomus, kurus ir grūti pārvaldīt pat izmantojot IT. Tas ir, ir vajadzīgas dažas kvalitatīvi atšķirīgas komunikācijas arhitektūras. Un, lai tos izmantotu, uzsver eksperts, mums ir jāpārskata sava izpratne par ECM, pozicionējot tās kā sistēmas, kas apvieno cilvēkus, procesus un saistīto saturu. Šodien pareizāk ir runāt nevis par elektronisku dokumentu apriti, bet gan par bezpapīru, bet dokumentētu cilvēku mijiedarbību darba procesos.

Tradicionāli EDMS jautājums tika saprasts kā uzņēmuma iekšējo biznesa procesu automatizācijas jautājumi un lielā mērā saistībā ar organizatoriskiem un administratīvajiem dokumentiem. Tomēr pēdējos gados strauji pieaugusi starporganizāciju dokumentu apmaiņas jautājuma aktualitāte: starp komercsabiedrībām, valsts struktūrās, kā arī uzņēmumu un privātpersonu mijiedarbībā ar valsts iestādēm. Visas šīs jomas šobrīd strauji attīstās tieši no pārejas uz starporganizāciju elektronisko dokumentu apriti viedokļa.

Par to runājot, Taxkom mārketinga direktora vietnieks Ernests Koļesņikovs atsaucas uz analītiķu prognozēm: līdz 2017. gadam EDI mehānismu izmantošana ar darījumu partneriem sasniegs 22,5%. Jau šobrīd, pēc jaunas PVN deklarācijas ieviešanas (gandrīz visiem nodokļu maksātājiem tā tagad jāiesniedz elektroniski), dokumentu automatizācijas jautājums ir kļuvis īpaši aktuāls, jo ar manuālu datu ievadi grāmatvedībā ir liela iespēja saņemt automātiskus pieprasījumus par nesakritībām ar darījuma partneriem. . Viņš arī atgādina, ka Krievijas Federācijas Darba kodeksa 49.1 nodaļa ļauj izmantot EDI, strādājot attālināti, un no 2016. gada 1. jūlija stāsies spēkā grozījumi Federālajā likumā “Par akciju sabiedrībām”, kas ļaus akcionāriem attālināti piedalīties sanāksmēs, izmantojot EDI.

Artjoms Tanans, 1C elektroniskās dokumentu apmaiņas projektu vadītājs, ir pārliecināts, ka galvenais stimuls pārejai uz BED ir uzņēmumu vēlme palielināt savu konkurētspēju. Tie, kas vēlas būt tirgus līderi, sāka gatavoties šādai pārveidei ilgi pirms likumīgas atļaujas un ir pirmie, kas šīs iespējas apgūst praksē. Vēl 2013.–2014. Elektroniskās metodes mijiedarbībai ar darījuma partneriem sāka izmantot uzņēmumi no ļoti konkurētspējīgām un tehnoloģiskām nozarēm, piemēram, mazumtirdzniecības ķēdes, izplatītāji, telekomunikāciju operatori utt. Tas ļāva iegūt visaptverošu efektu: no PVN atmaksas paātrināšanas un nodokļu risku samazināšanas līdz optimizēšanai. izmaksas un mijiedarbības ar darījuma partneriem efektivitātes palielināšana. Piegādājošo uzņēmumu spiediena ietekmē arī to darījuma partneri sāka pāriet uz BED. 2015. gadā process kļuva vēl plašāks, ko veicināja likumdošanas attīstība un vairāku jaunu normatīvo prasību parādīšanās nodokļu atskaišu iesniegšanai. Pēdējos gados ievērojami pieaudzis pakalpojumiem pieslēgto lietotāju skaits.

Prakse pārejai uz elektronisko dokumentu pārvaldību bez papīra

Pēc Jeļenas Ivanovas teiktā, elektronisko oriģinālu pārsūtīšanas prakse, mijiedarbojoties ar filiālēm un attālinātām vienībām, kļūst arvien izplatītāka. Arvien populārāka kļūst primāro grāmatvedības dokumentu (akts, rēķins uc) apmaiņa ar darījumu partneriem un integrācija ar atbilstošajiem specializētajiem maiņas pakalpojumiem. Viņa gan norāda, ka daudzas organizācijas joprojām ir piesardzīgas pret riskiem, kas rodas, izmantojot elektroniskos oriģinālos dokumentus, un jebkāda veida elektronisko dokumentu izmantošana tām joprojām ir “aizliegta” tēma.

"Runājot par pāreju uz darbu ar elektroniskiem oriģināliem, uzņēmumi sāk ar vārdu "mēs gribam", kam seko "bet..."," atzīmē Oļegs Beilezons. "Tad ir vairāk vai mazāk pārvaramu iemeslu kopums: dažas vienības nav gatavas, nav piešķirts budžets, mēs nevaram lauzt organizācijas tradīcijas utt." Taču kopumā, viņaprāt, tendence uz dokumentu plūsmas elektronizāciju ir redzama diezgan labi, kaut vai tāpēc, ka ir projekti pārejai uz bezpapīra tehnoloģijām, bet par apgrieztās pārejas projektiem nekas nav dzirdēts. BED aptver daudzas jomas - tās ir klasiskās EDMS, organizācijas finanšu dokumentu plūsma un juridiski nozīmīga finanšu dokumentu aprite. Juridiski nozīmīgā organizatorisko un administratīvo dokumentu plūsma ir nedaudz apstājusies - ir pārāk daudz juridisku smalkumu, un nav izveidota pietiekama prakse. Dokumentu ar dažādu piekļuves klasifikāciju elektroniskā uzglabāšana un apstrāde atpaliek vēl vairāk, jo (parasti pamatoti) sistēmām, kas tās ievieš, tiek izvirzītas diezgan stingras prasības.

Directum biznesa analītiķis Maksims Kainers stāsta, ka, ieviešot EDMS/ECM, ietaupījums uz papīra drukāšanu tiek panākts tikai ar automatizētiem procesiem, taču bieži vien izrādās, ka kopējais drukas apjoms visā organizācijā var pieaugt. Turklāt konkrēta biznesa procesa automatizācija, izmantojot ECM, mazāk nekā 10% gadījumu ļauj izvairīties no dokumentu drukāšanas pat šī procesa ietvaros. Kopumā viņš uzskata, ka pagaidām nav runas par organizāciju pāreju uz bezpapīru dokumentu apriti.

Kā likums, uzdevums atbrīvoties no papīra nav pašmērķis, mērķis ir optimizēt noteiktus biznesa procesus, paātrināt un vienkāršot to ieviešanu, uzsver Vadims Ipatovs. Pēc viņa aplēsēm, lielākā daļa klientu organizāciju ir pilnībā ieviesušas iekšējās elektroniskās sistēmas, ieskaitot visu apliecinošo dokumentu klāstu (instrukcijas, rezolūcijas, izpildes atskaites...). Daudzās valsts aģentūrās viņa uzņēmuma klientu vidū sabiedrisko pakalpojumu sniegšana un darbs ar pilsoņu apelācijām lielā mērā ir automatizēts. Ja pieprasījums tiek saņemts pa elektroniskiem kanāliem, tad tas tiek pilnībā apstrādāts elektroniski. Organizatorisko, administratīvo un normatīvo dokumentu jomā “digitalizācija” var sasniegt, nosacīti runājot, 99,9%, bet rīkojums, rīkojums vai nolikums, vismaz vienā papīra eksemplārā, tomēr ir vajadzīgs - to diktē gan tradīcijas, gan likumdošanas normas. Strādājot ar līgumiem, situācija ir līdzīga: viss to sagatavošanas un apstiprināšanas process notiek pilnībā elektroniski, bet divi eksemplāri, kurus puses paraksta, joprojām “dzīvo” uz papīra.

Svarīga loma pārejā uz EDMS ir organizāciju IT departamentiem tieši kā EDMS lietotājiem - viņi izmanto šos rīkus saviem iekšējiem uzdevumiem (lietotāju pieprasījumu apstrādei, projektu vadībai uzdevumu un darbu sadalē, apstiprinājumos utt.) , savukārt ar savu piemēru viņi parāda, kā papīru var pilnībā likvidēt.

“Pāreja uz bezpapīra tehnoloģijām kļūst par ikdienu, un to nosaka ražošanas vajadzības; strādāt bez papīra ir izdevīgi,” piekrīt Dmitrijs Šmailovs. - BED ir ļoti aktuāla uzņēmuma iekšējai dokumentu plūsmai. Mūsdienās, kad elektroniskie dokumenti pamazām iegūst likumdošanas statusu, darbs EDMS kopā ar darījuma partneriem kļūst par ikdienu. Taču vienlaikus viņš atzīmē, ka organizācijās, kas piemēro īpašus režīmus, dokumenti, kas veido valsts vai komercnoslēpumu vai ir īpaši vērtīgi, joprojām tiek glabāti uz papīra. Pāreja uz BED šādai dokumentācijai ir vai nu neiespējama, vai saistīta ar visaugstākā drošības līmeņa nodrošināšanu, kas ir dārga, sarežģīta un bieži vien neattaisno izmaksas.

Pēc Ernesta Koļesņikova teiktā, elektronisko dokumentu apmaiņa ar darījumu partneriem piedzīvo pārejas posmu no embrija stāvokļa uz nobriedušu. EDF operatori sākotnēji izvēlējās lielāko uzņēmumu - dokumentu aprites ģeneratoru - piesaistes taktiku, galvenajās biznesa nozarēs dokumentu apmaiņa elektroniskā formā kļūst par ikdienu, citās notiek pilotprojekti. Šo procesu būtiski stimulē un dažkārt pat ierosina regulatora darbības. Izplatīts gadījums automatizācijai ir vienas holdinga uzņēmumu grupa ar teritoriālo izplatību visā valstī, kur lielākā daļa dokumentu tiek pārvērsti elektroniskā formā un tiek nodrošināts maksimālais finansiālais efekts. Vienlaikus eksperts atzīmē būtisku momentu: “Daudz kas ir atkarīgs no tā, kā uzņēmumā tiek veikta grāmatvedība. Ja viss ir pēc likuma, tad paaugstināta caurskatāmība ir apsveicama, bet, ja situācija ir pretēja, tad tā darbojas kā instruments kārtības atjaunošanai, taču tas nav ātrs process.

Acīmredzamākā BED piemērošanas joma ir pāreja uz elektroniskām pavadzīmēm un rēķiniem. Taču Artjoms Tanans atzīmē, ka, lai gan regulators izrāda skaidru vēlmi ātri virzīties šajā virzienā, rodas diezgan daudz privātu grūtību. Piemēram, pāreju uz elektronisko rēķinu apmaiņu apgrūtināja situācijas, kad, teiksim, pakalpojumi tika sniegti taksācijas perioda pēdējā dienā (sakari, internets, komunālie maksājumi utt.), un rēķins ar apstiprinājumu no elektroniskā dokumenta. vadības operators tika datēts jau ar nākamo mēneša dienu. Šī problēma tika atrisināta diezgan ātri, pieņemot federālo likumu 382-FZ un turpmākos Finanšu ministrijas precizējumus.

Šķēršļi ceļā uz GULTU

Pirms dažiem gadiem galvenā atbilde uz šo jautājumu bija tēze “normatīvā un likumdošanas bāzes nesagatavotība”, taču tagad eksperti, minot šo problēmu, to neliek pirmajā vietā. "Organizācijas nav ieinteresētas atteikties no papīra," saka Maksims Kainers. – Izmaksas par drukāšanu un darbu ar papīra dokumentiem nav tik lielas, lai to samazināšana būtu uzskatāma par ieguvumu. ECM sistēmas tiek ieviestas nevis, lai pārietu uz elektronisku dokumentu apriti, bet gan lai iegūtu citus taustāmākus un acīmredzamākus efektus: procesu caurskatāmību un to paātrināšanu, risku samazināšanu u.c. Turklāt dažkārt procesa pārvēršanai elektroniskā formā vienkārši nav jēgas. tostarp arī elektroniskā paraksta sertifikāta diezgan augstās cenas dēļ.” Vienlaikus viņš atzīmē arī normatīvā regulējuma nepilnības - vairāku formulējumu neskaidrību un vispārēju konsultatīvo raksturu, atstājot izvēli organizācijām, kuras, iespējams, vienkārši nevēlas mainīt pārbaudītus darba modeļus. Tajā pašā laikā viņš ir pārliecināts, ka nevajadzētu krasi uzspiest jaunas pieejas, jo lielākajā daļā uzņēmumu tās prasīs izmaiņas IT infrastruktūras līmenī.

Runājot par likumdošanas regulējuma problēmu, Jeļena Ivanova vērš uzmanību uz to, ka daudzi regulējuma jautājumi ir pašu organizāciju pārziņā. "Daudzos veidos vadības gribai ir nozīme BED attīstībā," viņa ir pārliecināta. – Ja vadītājs liks strādāt bez papīra, tad to darīs visi, gribot vai negribot. Ja no vadības puses šādas motivējošas darbības organizācijā nav, tas nozīmē, ka tā nesaskata BED ekonomisko iespējamību un efektu. Pastāv arī problēma, ka trūkst darbinieku, kas varētu darboties kā BED ieviešanas procesa virzītājspēks un nodot vadītājam visus tā priekus.

Viņai piekrīt arī Dmitrijs Šmailovs: “Protams, varam teikt, ka likumdošana BED attīstībā atpaliek no Rietumvalstīm, taču daudz svarīgāk ir tas, ka ne visi izmanto pat tās iespējas, ko sniedz likumdošanas grozījumi. Drīzāk ir nobīde: daudzas BED tehnoloģijas izmanto tikai dažas organizācijas. Savu klientu gadījumā redzam tendenci uz elektroniskās grāmatvedības tēmu attīstību un padziļināšanu un vienota modeļa konstruēšanu grāmatvedības dokumentu apstrādei un uzglabāšanai elektroniskā formā. Pilnīgu pāreju uz BED lielā mērā ierobežo vienotas uzticamības telpas trūkums elektroniskajiem parakstiem. Tāpat neaizmirstiet par informācijas aizsardzības prasībām, kas atsevišķos gadījumos padara neiespējamu elektronisko dokumentu glabāšanu un izmantošanu. Finansējums joprojām ir svarīgs faktors.

Pārfrāzējot kādu labi zināmu teicienu, Ernests Koļesņikovs nosauc divas galvenās Krievijas elektronisko dokumentu pārvaldības nepatikšanas: likumi un cilvēki. “Tiesību aktos ir nepilnības, piemēram, tikai dažiem dokumentiem ir apstiprināti formāti, savukārt pie citiem veidiem darbs tikai notiek. Tuvākajā laikā būtu jāapstiprina universālā nodošanas dokumenta formāts, tiek runāts par universālo konteineru, kuram var pievienot jebkuru dokumentu. Neformalizētu dokumentu izmantošanas tiesu prakse vēl nav pietiekama, lai visi uzņēmumi bez bailēm pārietu uz EDI, taču laiks iet un situācija mainās uz labo pusi. Otra galvenā problēma ir cilvēki un valdošā dzīves realitāte, bieži no klientiem dzirdam: mēs atteiksim no papīra tikai tad, ja viņi mūs piespiedīs.

Lai ieviestu jaunu tehnoloģiju esošā procesa ietvaros, galvenokārt nepieciešama personāla pārkvalifikācija un uzņēmuma vadības vēlme pielietot inovācijas, taču procesi būtībā paliek nemainīgi, stāsta Artjoms Tanans. Viņš sniedz konkrētus padomus: lai ieviestu BED, jāieceļ atbildīgie un jāveic trīs galvenie uzdevumi - jāizveido jauna procedūra darbam ar dokumentiem, jāapmāca personāls un jānosaka termiņi, kad izvēlētajiem darījumu partneriem jāatsakās no vecās procedūras. Lai jaunās procedūras darbam ar dokumentiem būtu vienkāršas, saprotamas un minimāli atšķirtos no esošajām, ir jāatbalsta BED integrācija ar grāmatvedības, vadības un EDMS programmām un vēl labāk - jāveido BED. to neatņemama sastāvdaļa. Atsevišķs, iespējams, problemātiskākais bloks ir darījuma partneru iesaistīšanas jautājums. Nepieciešams ne tikai savienot BED klienta darījuma partnerus, bet arī palīdzēt pārejā uz jaunu procedūru darbam ar dokumentiem. Pretējā gadījumā, pat izmantojot BED, saglabāsies kļūdas un neatbilstības informācijā pirkšanas un pārdošanas grāmatiņās, un ir citas negatīvas sekas. Eksperts ir pārliecināts, ka jautājumi par BED integrāciju ar citām biznesa sistēmām un darbuzņēmēju iesaistīšanu tuvāko gadu laikā spēlēs lielu lomu BED tehnoloģiju izplatīšanā mūsu valstī.

Ko darīt?

"Pagaidām Krievijā nav iespējams pilnībā atteikties no papīra ne valsts sektorā, ne komerciālajā sektorā," norāda Jeļena Ivanova. - Pirmkārt, ir jāizstrādā likumdošanas bāze, kas veicinātu organizāciju pāreju uz BED. Daļēji tas tagad sāk izpausties valdības organizācijās saistībā ar SMEV uzlabošanu, M. Viņa uzskata, ka daudz kas ir atkarīgs no EDMS pārdevēja; tie var pamatot pārejas uz BED ekonomisko efektu un piedāvāt tehnoloģiskus risinājumus. Svarīgi ir arī strādāt profesionālās kopienās un organizācijās, kas iesaistītas standartizācijā EDMS/ECM jomās, kā arī sadarboties ar valsts regulatoru.

Turklāt pašiem EDMS piegādātājiem ir jārāda piemērs pārejai uz BED, pārliecināts Dmitrijs Šmailovs. Šiem uzņēmumiem ir nepieciešama arī elektroniskā dokumentu pārvaldība, lai uzlabotu darba efektivitāti. Klientu trūkuma apstākļos veiksmes faktors var būt BED tehnoloģiju testēšana savā biznesā. EDMS piegādātāji būtu labs palīgs tehnoloģiskajā attīstībā, piedāvājot jaunākos sasniegumus, kas atbilst un ņem vērā viņu klientu individuālās prasības un specifiku.

Maksims Kainers arī izsakās par ekonomisko pamatojumu pārejai uz BED: “Lai pāreja uz elektronisku dokumentu plūsmu notiktu, IT risinājumu ieviešanai ir jāatmaksājas, ietaupot uz atbalsta darbu ar papīra medijiem (iekārtu iegāde un apkope, palīgmateriāli, nosūtīšanas un piegādes izmaksas, uzglabāšanas un izņemšanas izmaksas). Pasaules eksperti norāda, ka ieguldījumu konkrētos ECM risinājumos atmaksāšanās laiks vairāk nekā pusē gadījumu ir pusotrs gads vai mazāk. Pārdevēju reālā līdzdalība šajā procesā var būt idejas “strādāt bez papīra ir iespējams un izdevīgi” popularizēšanā, piedalīšanās likumdošanas procesā, kā arī savu risinājumu izmaksu samazināšana, tostarp izmantojot mākoņmodeļus un SaaS.

BED nav nepārvaramu šķēršļu, taču ir problēmas, kuras var un vajag atrisināt, saka Ernests Koļesņikovs. Viennozīmīgi pozitīvs aspekts ir tas, ka valsts iestādes iegulda lielus līdzekļus valsts automatizācijā, un var teikt, ka pēdējo desmit gadu laikā dzīvot un strādāt ir kļuvis daudz patīkamāk. Problēmas ir, taču tās tiek apzinātas un atrisinātas, kopīgiem spēkiem regulatoram, izstrādātājiem un klientiem. "Līdz noteiktam brīdim informācijas apjoms sabiedrībā sasniegs pietiekamu apjomu un visi sapratīs, ka dokumentu eksponēšana vecmodīgā veidā uz papīra ir pagātne," viņš ir pārliecināts. "Tagad ir grūti iedomāties, kā mēs agrāk dzīvojām bez interneta, bet ar elektronisko dokumentu apstrādi, manuprāt, situācija būs tāda pati."

“Mēs iesakām uzņēmumiem negaidīt “pēdējo zvanu”, kad tie paši vairs nespēs tikt galā ar papīra plūsmu un neizpildīs regulatora prasības,” iesaka Artjoms Tanans. - Viņiem tagad ir jāizlemj, kāda veida darījumiem/dokumentiem un ar kuriem darījuma partneriem tiks izmantots BED, pēc tam jāieceļ atbildīgie un jānosaka termiņi. Uzdoto uzdevumu kvalitatīvai izpildei nepieciešamības gadījumā piesaistīt ekspertus ar pietiekamām kompetencēm šajā jomā. Ja rodas metodoloģiskas vai tehniskas grūtības, aiciniet tās apspriest specializētās platformās, darba grupās par BED jautājumiem. Tikai konkrētu uzdevumu izvirzīšana, pārejot uz BED vienā uzņēmumā, ļauj gūt veiksmīgu un citiem tirgus dalībniekiem saprotamu pieredzi. Šīs pieredzes atkārtošana, ko veic lielie uzņēmumi kopā ar SF operatoriem, programmatūras pārdevējiem un viņu partneru tīkliem, ir visefektīvākais veids, kā izplatīt BED tehnoloģijas tirgū.

Turpinām to, ko jau esam daudz darījuši.

Černomirdins V.S.

Pirms neilga laika pie manis kārtējo reizi vērsās klients ar labi zināmu problēmu. Viņa uzņēmums instalēja 1C atjauninājumus. Un darbs apstājās, jo programma pārstāja darboties pareizi. Es domāju, ka ikviens, kurš ir saskāries ar programmatūras produktiem no 1C kā programmētājs vai lietotājs, ļoti labi pārzina šo situāciju.

Protams, šajā konkrētajā gadījumā es centos visas problēmas atrisināt pēc iespējas ātrāk, un rezultātā biroja darbs atgriezās normālā ritmā. Taču arī šajā situācijā no klienta saņēmu daudz negatīvisma. Un tad es domāju par to, kāpēc ar 1C programmatūras produktiem pastāvīgi rodas tik daudz problēmu, kāpēc no klientiem ir tik daudz negatīvisma un kāpēc paši 1C programmētāji bieži vien nepatīk, tostarp citiem programmētājiem?

Šajā rakstā es nolēmu piedāvāt savu versiju par iemesliem, kas noved pie šāda negatīvisma. Centīšos lietot pēc iespējas mazāk specifisku terminu, lai teksts būtu saprotams pēc iespējas lielākam skaitam lasītāju.

Tajā pašā laikā es pats kādu laiku nodarbojos tikai ar 1C programmēšanu, un šodien ļoti aktīvi savā darbā izmantoju programmatūras produktus no 1C, un esmu ļoti pateicīgs šim uzņēmumam par iespēju nopelnīt naudu, tostarp es.

Bet, no otras puses, es uzskatu, ka ir jāsaprot arī negatīvisma cēloņi. Vismaz, lai neatstātu to visu intuīcijas un emociju līmenī.

Kā sākās 1C? Atcerēsimies!

Personīgi es sāku strādāt ar 1C programmatūru no 6.0 versijas. Manuprāt, šī programma bija nedaudz sarežģītāka par dažādām uzskaites iespējām, kas tika glabātas Excel izklājlapās.

Tā tika aizstāta ar 7. versiju, ieskaitot tās veiksmīgāko versiju - 1C 7.7. Tas jau bija diezgan spēcīgs programmatūras produkts, kas kļuva ļoti izplatīts visā postpadomju telpā. Līdz tam laikam lielākā daļa lietotāju bija tik ļoti pieraduši strādāt ar 1C, ka iespēja izmantot šīs programmas kļuva par vienu no nosacījumiem, lai pieņemtu darbā grāmatvežus, dažādus biroja darbiniekus, kā arī vadītājus, noliktavas u.c.

Principā 1C 7.7 diezgan veiksmīgi atrisināja problēmas, kas saistītas ar dažāda veida grāmatvedību. Turklāt šis programmatūras produkts dažos gadījumos joprojām tiek izmantots, kas arī norāda uz tā popularitāti.

Tagad šī programmatūra pārsteidz ar savu iespēju plašumu un tajā pašā laikā sistēmas sarežģītību.

Mūsdienās 1C uzņēmums saviem klientiem nodrošina visu ekosistēmu:

Jaudīga platforma izstrādātājiem.
Vide dažāda veida grāmatvedības un analītikas uzturēšanai
Iespēja pieslēgt dažādas tirdzniecības iekārtas
Plašākais partneru tīkls
Daudzfunkcionāla CMS vietņu izveidei

Tajā pašā laikā visas šīs ekosistēmas sastāvdaļas kopā un atsevišķi nedarbojas vislabākajā veidā. Bieži rodas problēmas, neveiksmes darbā, tiek prasīts papildu laiks un nauda, kas, protams, izraisa noraidījumu.

1C atjauninājumi: kā tas darbojas

Es vēlos īsi atgādināt, kā mūsdienās darbojas 1C saimes programmatūras produkti. Vairumā gadījumu lietotājs iegādājas vienu vai vairākus programmatūras produktus, kas sastāv no platformas un uz šīs platformas rakstītas aplikācijas – tā sauktās konfigurācijas.

Tālāk programmētājs pielāgo izvēlēto konfigurāciju darbību konkrētā uzņēmuma vajadzībām, bieži uzstāda papildus spraudņus, precizē noteiktas atskaites, veido jaunus dokumentus, kas piedalās kā iekšējā dokumentu plūsma šajā uzņēmumā utt.

Tajā pašā laikā gan platformā, gan jebkurā konfigurācijā ir diezgan daudz izstrādātāja kļūdu. Un pati sistēma ir tik sarežģīta un apjomīga, ka šo kļūdu labošana ar 1C programmētāja palīdzību ir ļoti sarežģīta un, pats galvenais, neizdevīga gala lietotājam. Turklāt gan platforma, gan pašas konfigurācijas izceļas ar tādu nepatīkamu kvalitāti kā modularitātes trūkums.

Tā rezultātā jums ir jāinstalē atjauninājumi, lai novērstu kļūdas. Šajā gadījumā visa platforma un/vai konfigurācija tiek atjaunināta katru reizi. Protams, šāds risinājums aizņem daudz laika, un, ja mēs runājam par konfigurāciju, tad iestatījumi, papildu spraudņi un citas programmētāja veiktās modifikācijas, visticamāk, būs jāveic vēlreiz.

Bet tas nav skumjākais situācijā ar 1C atjauninājumiem. Skumjākais ir tas, ka izstrādātāja vietnē ir redzams, ka atjauninājumi tiek izdoti ļoti bieži, dažreiz pat 3-4 reizes mēnesī. Dažos gadījumos tiek izlabotas nesvarīgas kļūdas, citos - nopietnas kļūdas, kas saistītas ar visas sistēmas darbību.

Katra jaunā versija ir funkcionalitātes papildinājums un sava veida “ielāps” iepriekšējās kļūdām, kas izlabo vecās kļūdas, bet gandrīz vienmēr ievieš jaunas. Tāpēc atjauninājumu instalēšana lielākoties ir neparedzams process.

Modularitātes trūkums: kāpēc tas ir tik svarīgi?

Pirmkārt, parunāsim tieši par platformu. 1C programmētāji zina, cik tas ir kļuvis apgrūtinoši. Es jau rakstīju par modularitātes trūkumu iepriekš. Produkta kods satur tā sauktās apakšsistēmas, taču tās neatbilst modularitātes prasībām un tāpēc ir vienkārši sava veida mēģinājums strukturēt kodu.

Kāpēc es personīgi uzskatu, ka modularitātes trūkums ir problēma? Sapratīsim to ar piemēru. Teiksim, ir nepieciešams pilnveidot dažas Tirdzniecības vadības sekmīgai darbībai nepieciešamās funkcijas vai veikt izmaiņas atlikumu glabāšanas līdzekļos. Bet 1C platformā viss ir savstarpēji saistīts, un tāpēc jums ir arī jāievelk atjauninājumi, lai strādātu ar algām, grāmatvedību utt. un tā tālāk.

Ja nav modularitātes, lai veiktu pat vismazākās izmaiņas, jums ir jāizpēta viss masīvs, visa platforma.

Tajā pašā laikā 1C platforma ir ļoti liela un apgrūtinoša. Mūsdienās tas satur tik daudz, ka sākumā tas pat izraisa apbrīnu iespēju bagātības dēļ. Taču, lietojot šo platformu, apbrīna ātri vien beidzas. 1C izstrādātāji, cenšoties padarīt programmu universālu, platformai pievienoja daudzas dažādas funkcijas.

Un tagad jūs vienlaikus iegūstat jaudīgu rīku, ērtu vizuālo saskarni un... daudzas problēmas un kļūdas sistēmas sarežģītības dēļ.

Ļaujiet man sniegt jums vēl vienu piemēru. Teiksim, manam darbam man vajag tikai Tirdzniecību. Neko citu uzņēmums neizmanto ne mobilo saskarni, ne grāmatvedību, ne interneta veikalu, ne kādas citas sastāvdaļas. Bet neatkarīgi no tā, kad es saņemu atjauninājumus, es saņemu visu platformu, ieskaitot funkcionalitāti, kas nepieciešama to komponentu darbībai, kurus neizmantoju. Tie. Neskatoties uz to, ka izmantoju Commerce un atjauninājumi ir paredzēti darbam ar grāmatvedību, man ir jālejupielādē un jāinstalē visa platforma.

Licencēšanas politika un kļūdas sistēmā

Atjauninot platformu, lietotāji diezgan bieži saskaras ar faktu, ka licences atslēgas pārstāj darboties. Ja neesat personīgi saskāries ar šādu situāciju, vienkārši ierakstiet meklētājā “1C pārtrauca darbu pēc atjaunināšanas”, un jūs redzēsit, cik plaši šī problēma ir izplatīta.

Tātad, iedomājieties situāciju. Ir uzņēmums, kurā strādā, piemēram, 30 cilvēki. Pēc atjaunināšanas programma pārtrauca pieņemt licences atslēgas. Uzņēmuma darbs ir paralizēts. Uzņēmums cieš zaudējumus.

Svarīga problēma: platformas uzvedības neparedzamība atjaunināšanas laikā.

Papildus tam, ka licence bieži neizdodas, pēc platformas atjaunināšanas tajā var būt iekļauta jauna funkcionalitāte, kas arī var nedarboties pareizi. Bet jūs varat tikai pārbaudīt darba kvalitāti un noteikt jaunas kļūdas jaunā programmas versijā praksē, t.i. procesā.

Atgādināšu, ka platforma ir ļoti liela un apgrūtinoša, un tāpēc ir vienkārši nereāli to īsā laikā pārbaudīt ar programmētāju. Un tas viss ir jāņem vērā katrā atjauninājumā.

Tātad programmētāja situācija izskatās šādi:

Katru reizi, kad atjauninu, man rodas daudz jucekļu, jo platforma ir pilnībā atjaunināta, un nav iespējas noņemt vai neinstalēt rīkus, kas netiks izmantoti nākotnē.
Un tomēr ir nepieciešami atjauninājumi, jo šī ir vienīgā iespēja “izārstēt” pašreizējās kļūdas, kuras programmētājs zina vai vēl nav identificējis.
Turklāt jauns atjauninājums parasti satur jaunas kļūdas, kas tiks novērstas nākamajā versijā.

Tādējādi aplis ir noslēgts. Un programmētājam laiku pa laikam ir jāinstalē jaunas versijas, neskatoties uz jaunajām problēmām, ko tās rada.

Kāpēc ir tik daudz kļūdu?

Galvenais kļūdu pārpilnības iemesls, manuprāt, ir sistēmas sarežģītība. Atcerieties, ka tagad 1C platforma ir pieejama operētājsistēmai Windows 32 un 64 bitu, Linux, servera versijai, mobilajām ierīcēm utt. Apkopes sarežģītība ir ļoti augsta, un, kā liecina prakse, 1C izstrādātāji vienkārši nevar tikt galā ar apkopi.

Modularitātes trūkuma dēļ rodas arī papildu grūtības, jo praktiski nav iespējams identificēt visas kļūdas un atkļūdot tik apgrūtinošu programmatūras produktu. Tā rezultātā pastāvīgi tiek izlaisti jauni atjauninājumi.

Vēl viens ļoti būtisks kļūdu pastāvīgās klātbūtnes iemesls un situācija ar tām ir konkurences trūkums. Faktiski 1C tagad ir monopolists.

Protams, tiek radīti alternatīvi programmatūras produkti, daži no tiem ir diezgan pieklājīgi. Bet līdz šim tie visi ir piemēroti risinājumi, kas spēj atrisināt noteiktas problēmas, savukārt 1C ir vesela ekosistēma.

Turklāt uzņēmums 1C izceļas ar ļoti spēcīgu un agresīvu mārketingu, visi zina par šo programmatūru.

Tāpēc es apgalvoju, ka šodien 1C nav cienīga konkurenta postpadomju telpā. Un konkurences trūkums vienmēr noved pie paša produkta kvalitātes pazemināšanās, ko mēs redzam 1C piemērā: pastāvīgi “neapstrādāti” atjauninājumi, pastāvīgas kļūdas, detalizētas dokumentācijas trūkums atjauninājumiem utt.
Tāpēc es personīgi iesaku visiem saviem klientiem neatjaunināt, ja vien tas nav absolūti nepieciešams. Starp citu, es pats saņēmu tādu pašu padomu no viena no cilvēkiem, kuri bija 1C pirmsākumos.

Protams, pašreizējā versijā noteikti ir dažas kļūdas, taču, ja jūs tajā strādājat bez problēmām, tad šīs kļūdas jums nav kritiskas. Nav iespējams paredzēt, kas notiks jaunajā versijā. Tāpēc atjauninājumi ir jāinstalē tikai tad, kad tas patiešām ir nepieciešams darbam.

Flagmaņi. Tipiskas konfigurācijas

1C programmatūras produktu līnija ir balstīta uz standarta konfigurācijām. Vietnē 1C ir pieejams diezgan daudz gatavu kastes risinājumu.

Bet lielākā daļa lietotāju izmanto tikai 4 konfigurācijas:

Uzņēmuma grāmatvedība
Tirdzniecības vadība
Ražotnes vadība
Algu un personāla vadība

Un katrai no konfigurācijām ir tādi paši trūkumi kā platformai:

Modularitātes trūkums
Lielgabarīta un daudzas nevajadzīgas funkcijas
Jaunas kļūdas jaunajās versijās
Neparedzami atjaunināšanas rezultāti

Turklāt katram atjauninājumam ir jāanalizē, kas tieši tika atjaunināts, jāveic pats atjauninājums un atkārtoti jākonfigurē konfigurācija. Taču arī konfigurācijas atjauninājumi tiek izdoti tik bieži, ka kļūst problemātiski tos saprast.

Turklāt modularitātes trūkuma dēļ jums bieži ir jāatjaunina, pat ja izmaiņas ietekmē funkcijas, kuras jūs neizmantojat. Vienkārši tāpēc, ka kļūda šajā funkcionalitātē var izraisīt citu moduļu nepareizu darbību.

Ja runājam par Trade, mana prakse rāda, ka patiesībā cilvēki izmanto ne vairāk kā 30% no šīs komponentes kopējās funkcionalitātes. Līdzīga situācija ir arī citās tipiskajās konfigurācijās. Cenšoties ieviest maksimālo funkciju skaitu, izstrādātāji ir radījuši ļoti apgrūtinošus un sarežģītus produktus, kuros viss ir savstarpēji saistīts, un tāpēc ne vienmēr ir iespējams pat atspējot nevajadzīgu funkcionalitāti.

Piemēram, atjauninot Trade, izstrādātāji pievienoja jaunu bonusu sistēmu. Klients bonusus neizmanto vispār. Viņam tās nav vajadzīgas. Bet, ja jūs mēģināt atspējot šos bonusus, atlaižu sistēma sāk darboties nepareizi. Es ar šo situāciju saskāros praksē. Protams, šīs problēmas risināšanai bija nepieciešama programmētāja palīdzība.

Pēdējā laikā esmu nonācis pie secinājuma, ka pēc projekta pabeigšanas visiem klientiem iesaku vispār neatjaunināt. Sakonfigurēju visu, kā nepieciešams darbam, kopā ar klientu un viņa darbiniekiem pārbaudījām konfigurāciju un pārliecinājāmies, ka viss darbojas labi. Tāpēc nav nepieciešams atjaunināt konfigurāciju, līdz rodas nepieciešamība veikt būtiskas izmaiņas.

Agresīvs mārketings un tā rezultāti

Ļoti bieži mani klienti instalē atjauninājumus pretēji maniem ieteikumiem. Kāpēc tas notiek?

Programmētāja motivācija

1C programmētāji ir ieinteresēti, lai klients pēc iespējas biežāk atjauninātu programmatūru. Viņiem tas vienkārši ir izdevīgi. Katru reizi, kad veicat atjaunināšanu, jums būs atkārtoti jākonfigurē konfigurācija. Tāpēc ar atjauninājumu palīdzību viņi burtiski saņem ienākumus no zila gaisa.

Iedomājieties situāciju, kad uzņēmums mierīgi un uzticami darbojas kādā konfigurācijā bez atjauninājumiem. Bet bija nepieciešams, piemēram, izveidot citu atskaiti vai instalēt papildu apstrādi. Protams, šajā gadījumā viņi vēršas pie speciālista.

Kas notiek tālāk? Atnāk 1C programmētājs un redz, ka programma sen nav atjaunināta. Viņš stāsta klientam, cik tas ir slikti, paskaidro, ka bez atjauninājumiem nevarēs izveidot klientam nepieciešamo atskaiti vai veikt citus darbus, biedē viņu ar lielo kļūdu skaitu, kas ir vecajā versijā utt. un tā tālāk. Kopumā tas pārliecina klientu iegādāties un instalēt atjauninājumus.

Faktiski vairumā gadījumu nav objektīvas nepieciešamības pēc atjauninājumiem. Bet programmētāja darba apjoms un attiecīgi viņa honorārs ievērojami palielinās. Starp citu, tāpēc daudziem lietotājiem ir negatīva attieksme pret 1C programmētājiem. No viņu viedokļa viņi programmētājam maksā 90% no summas par kaut ko, kas lieliski nostrādāja pirms viņš sāka strādāt, t.i. viņiem par vienu un to pašu funkcionalitāti ir jāmaksā vairākas reizes.

Agresīvs mārketings no 1C

Arī pats 1C uzņēmums ir ieinteresēts nodrošināt, lai lietotāji tiktu atjaunināti pēc iespējas biežāk. Rezultātā lietotāji bieži saņem atgādinājumus par jauniem atjauninājumiem, brīdinājumus par nepieciešamību atjaunināt platformu vai konfigurāciju. Bet tajā pašā laikā vietnē nav pietiekami detalizētas informācijas par to, ko tieši lietotājs saņems atjauninājuma gadījumā, kādas kļūdas ir novērstas, kādi līdzekļi ir parādījušies. Tie. Nav iespējams objektīvi novērtēt nepieciešamību instalēt konkrētu atjauninājumu. Rezultātā daudzi lietotāji atjaunina, lai būtu drošībā.

Pakalpojuma un franšīzes trūkumi

Uzskatu, ka 1C uzņēmumā klientu apkalpošanas praktiski nav. Uzņēmums veic lielisku darbu pārdošanas jomā, tam patiešām ir ļoti agresīva un, jāatzīst, efektīva mārketinga politika. Bet, ja jums ir nepieciešama apkope, jūs saskarsities ar daudzām grūtībām.

1C vietnē ir vesela sadaļa, kurā varat atrast sertificētus partnerus savā reģionā, kas sniedz 1C programmatūras produktu apkopes pakalpojumus. Šie partneri ir sertificēti un maksā filiāļu maksas. Šķiet, ka viss ir kārtībā.

Bet patiesībā uzņēmums 1C praktiski nedarbojas ar partneriem:

Lai uzņēmums saņemtu partnera statusu, pietiek ar sertificētu speciālistu.
Pēc tam neviens neveic atkārtotas pārbaudes vai eksāmenus. Tāpēc sertificēts programmētājs var būt vienīgais speciālists, un tevi apkalpot nāks pavisam citi cilvēki, vai arī viņš var aiziet pavisam, bet uzņēmums nezaudē partnera statusu.
1C praktiski nestrādā ar partneriem, nenodrošina apmācību un nekontrolē darba kvalitāti.

Šādas politikas rezultāts ir zināms daudziem. Konkrēta uzņēmuma klātbūtne 1C partneru sarakstā negarantē kvalitatīvu pakalpojumu.

Es jau minēju, ka 1C ir vesela ekosistēma. Dažos veidos to pat var salīdzināt ar Apple. Tur ir uzbūvēta vesela sistēma, kas sastāv no aparatūras, programmatūras un tālākpārdevējiem. 1C ir arī platforma, ir konfigurācijas, ir sertificēti tālākpārdevēji.

Bet, ja Apple ļoti stingri kontrolē kvalitāti visos posmos - no ražošanas līdz partneru darbam, un augstākā kvalitāte ir viena no svarīgajām šī zīmola konkurences priekšrocībām, tad 1C uzņēmumā viss ir pavisam savādāk. Servisa šeit praktiski nav, neviens nekontrolē partneru darbu, kā rezultātā pēcpārdošanas darba kvalitāte ar programmatūru ir ļoti zema.

Interesanti ir arī tas, ka 1C uzņēmums savus mārketinga pasākumus galvenokārt virza uz produkta patērētājiem, t.i. uz lietotājiem. Un darbs ar konfigurācijām ir pilnībā vērsts uz programmētājiem. Rezultātā tiek reklamēta viena lieta, bet praksē izrādās, ka pircējs saņēma pavisam ko citu.

Un šeit parādās arī negatīvisma iemesli pret 1C programmētājiem un pašu programmatūras produktu.
Kad pārstāju strādāt tikai ar 1C un sāku nodarboties ar biznesa konsultācijām, savā darbā sāku izmantot dažādus programmatūras produktus. Tās bija vietnes Drupal un tādas sistēmas kā ZOHO CRM, ATOL RMK, Redmine un daudzas citas sistēmas. Un gandrīz visiem šiem pakalpojumiem un programmām nav nepieciešama pastāvīga un bieža atjaunināšana. Un, veicot atjaunināšanu, nav tik daudz problēmu.

Kamēr uzņēmums 1C pelna naudu divos virzienos: no pārdošanas un pastāvīgiem atjauninājumiem. Bet kāds ar to sakars klientam? Viņš ir spiests maksāt un uzlabot, jo nav citas izvēles. Turklāt visi uzņēmumā izmantotie produkti ir jāatjaunina vienlaicīgi.

Piemēram, ja izmantojat Trade, tam ir izdots patiešām noderīgs atjauninājums, kas izlabo kādu jums aktuālu kļūdu, noteikti būs jāatjaunina arī Grāmatvedība. Tā kā datu apmaiņa iespējama tikai starp identiskām konfigurācijas versijām. Ja nolemjat pamest Grāmatvedību bez atjaunināšanas, tad dokumentu augšupielāde no Tirdzniecības uz Grāmatvedību jums vairs nederēs.

Rezultātā klients ir spiests izmantot sistēmu, kas pastāvīgi sabojājas, un regulāri maksāt, lai to atjaunotu. Protams, klients kļūst negatīvs. Bet viņš nevar pārslēgties uz kādu citu programmatūras produktu, viņš vienkārši neredz cienīgu alternatīvu.

Jā, mūsu valstī ir arī citas uzskaites sistēmas, dažas pat pamazām pēc iespējām tuvojas 1C. Bet mārketings ir lieliska lieta! Tāpēc klients neredz alternatīvu, un, neskatoties uz pastāvīgo negatīvismu, veic vēl vienu maksājumu.

1C: Bitrix - grūtības, funkcijas, mārketings

Vēl viens produkts, kas tradicionāli tiek klasificēts kā daļa no 1C līnijas, ir vietņu pārvaldības sistēma 1C-Bitrix. Tajā pašā laikā daudzi lietotāji ir pārliecināti, ka pietiek ar Bitrix iegādi, un visi jautājumi par vietnes un datu integrēšanu 1C tiks atrisināti.

Lietotājs, kurš pērk 1C programmatūras produktus un pasūta vietni 1C-Bitrix, redz kopīgu zīmolu un ir pārliecināts, ka tie ir vienas līnijas produkti, kas vienmēr darbosies kopā bez problēmām.
Faktiski CMS Bitrix ir atsevišķs produkts, ko izstrādājuši speciālisti, kuriem nav nekāda sakara ar uzņēmumu 1C. Vēlāk šai CMS tika pievienoti integrācijas rīki ar 1C līnijas produktiem, un parādījās jauns nosaukums “1C-Bitrix”. Tas notika tāpēc, ka uzņēmums 1C nopirka lielu Bitrix daļu un nolēma izmantot šo CMS kopā ar programmatūru.

Kāds bija rezultāts?

Tiešsaistes veikala datu bāzes un 1C programmatūras produktu integrācija patiešām ir nodrošināta. Bet tas ir ļoti sarežģīti, un bez speciālista palīdzības ir gandrīz neiespējami iestatīt datu apmaiņu, un to ir ļoti, ļoti grūti mainīt.

Turklāt programmētāji, kuri jums iestatīja 1C, nevarēs instalēt un konfigurēt Bitrix. Šeit jums būs nepieciešams tīmekļa programmētājs, Bitrix speciālists. Integrāciju daļēji konfigurē 1C programmētāji, daļēji Bitrix speciālisti. Un ir gadījumi, kad lietotājs vispār nezina, ar ko sazināties.

Piemēram, man bija šāda situācija. Pēc jaunākajiem atjauninājumiem mana klienta datu apmaiņa ar vietni pārstāja darboties. Es vērsos pie 1C speciālista, bet viņš nevarēja mums palīdzēt, jo, viņaprāt, problēma bija Bitriksa pusē. Mēs vērsāmies pie Bitrix programmētāja. Viņš arī atmeta rokas un teica, ka problēma, visticamāk, joprojām ir 1C pusē. Datu apmaiņa ar vietni nedarbojās apmēram 2 nedēļas. Klients bija spiests manuāli lejupielādēt cenas un atlikumus un izlādēt pasūtījumus no vietnes. Galu galā mums paveicās. Es sazinājos ar programmētāju, kurš zināja gan Bitrix, gan 1C, un viņš uzstādīja apmaiņas moduli.

Bitrix un 1C: dažādas sistēmas, kopīgi trūkumi

Tīmekļa izstrādātāji, kuri ir pazīstami ar jaunākajām Bitrix versijām, mani tagad sapratīs. Tāpat kā 1C programmatūras produkti, arī Bitrix jaunākās versijas ir kļuvušas ļoti jaudīgas, ar plašām iespējām, bet tajā pašā laikā nevajadzīgi sarežģītas. Mūsdienās bez administratora (tīmekļa programmētāja) palīdzības Bitrix lietotājs visbiežāk nevar pat izveidot jaunas kategorijas preču katalogā, jo, lai organizētu viedo meklēšanu, katram produkta veidam ir jāiestata savi parametri.

Tajā pašā laikā vietnes un 1C programmu uzturēšanai ir nepieciešami dažādi speciālisti. Galu galā tie ir dažādi produkti. Tie tiek izmantoti dažādiem mērķiem, tiem ir dažādas platformas, un, lai strādātu ar tiem, ir nepieciešamas zināšanas par dažādām tehnoloģijām.

CV vietā

Tātad apkoposim. 1C līnijas programmatūras produkti speciālistu vidū izraisa negatīvismu šādu iemeslu dēļ:

Augsta sistēmas sarežģītība
Modularitātes trūkums
Kļūdas katrā atjauninājumā
Trūkst detalizētas dokumentācijas atjauninājumiem
Neprognozējams atjauninājumu instalēšanas rezultāts

Tas viss attiecas gan uz platformu, gan uz jebkuru 1C konfigurāciju.

Lietotāju negatīvismu izraisa:

Neprognozējami atjauninājumu instalēšanas rezultāti. Programma var pārtraukt darbu jebkurā laikā. Tomēr iepriekšējo versiju kļūdu dēļ ir nepieciešami atjauninājumi.
Gan uzņēmumam 1C, gan programmētājam ir jāmaksā par atjauninājumiem. Tajā pašā laikā lietotājam redzamās priekšrocības vairumā gadījumu ir niecīgas, un lielākā daļa izmaksu ir jāmaksā par programmas funkcionalitātes atjaunošanu pēc jaunas versijas instalēšanas.

Kļūst skaidrs arī negatīvisms pret 1C programmētājiem:

Lietotāji daļu no programmas negatīvisma nodod speciālistam. Galu galā tieši 1C programmētājs saņem samaksu par atjauninājumu instalēšanu un konfigurāciju iestatīšanu.
Programmētāji, kas strādā citās jomās, saprot, ka bieži viņu kolēģi, kas specializējas 1C, saņem naudu būtībā par "gaisa pārdošanu". Tas ir īpaši pamanāms, ja atjauninājumus klientam uzliek paši speciālisti.
Tā kā no 1C puses nav kontroles, ar programmatūras produktu apkalpošanu nodarbojas nejauši cilvēki, kas arī neveicina pozitīvu tēlu.

Šos secinājumus izdarīju es personīgi. Varbūt man nav kaut kas līdz galam taisnība, iespējams, esmu kaut ko palaidis garām. Jebkurā gadījumā es nolēmu rakstīt šo rakstu nevis kritikas dēļ, bet gan tāpēc, lai saprastu, kādu iemeslu dēļ klientiem var būt negatīva attieksme pret 1C līnijas programmām un 1C programmētājiem.

Tagi: pievienojiet atzīmes