For kort tid siden glædede 1C sig over udgivelsen af ​​en ny version af applikationsløsningen 1C: Enterprise Accounting 3.0 og var ked af det efterfølgende ophør af support til version 2.0 i foråret 2014. Lidt senere, på anmodning fra partnere, blev udviklerne enige om at fortsætte med at understøtte version 2.0 med hensyn til reguleret rapportering indtil udgangen af ​​2014.

Løsningen er den længe ventede fortsættelse af den legendariske serie regnskabsprogrammer. Det har en fundamentalt ny grænseflade (den såkaldte administrerede applikation), som åbner nye muligheder for brugerne: det er muligt at arbejde i tynd- og webklienttilstand, hoste applikationer i skyen, generere rapporter i baggrunden og andre. Ud over grænsefladeændringer er der nogle regnskabsmæssige forbedringer: Regnskabsmodulet er blevet udvidet løn, skatteregnskab er blevet mere bekvemt og logisk.

Påkrævet udgivelse

Lad os starte med det grundlæggende: hvad er nødvendigt for overgangen? Det, der skal til, er en version af version 2.0-konfigurationen, hvorfra du kan skifte til den aktuelle version. For at forstå, hvilken udgivelse der er nødvendig, skal du finde oplysninger om den aktuelle version, der er egnet til opdatering på webstedet http://users.v8.1c.ru. For eksempel er den aktuelle version 3.0.27.7, som kan opdateres fra version 2.0.53.6.

Tilpasning af konfigurationsforbedringer

Hvis konfigurationen er atypisk, er den første og sværeste opgave, som "implementører" står over for, at overføre fra "to-rums" funktionaliteten til "tre".

For at få en liste over ændringer skal du sammenligne databasekonfigurationen med leverandørkonfigurationen (tjek at leverandørkonfigurationen er opdateret).

Følgende funktioner findes her:

• Alle forbedringer foretaget på "almindelige" formularer kan ikke blot overføres til administrerede formularer. Det er nødvendigt at tilpasse programkoden.
• Regnskab 3.0 er i sagens natur nyt program. Hvis f.eks. din ændring tidligere var i funktionen "Beregn procentdel af tillæg" i dokumentmodulet "Varer og tjenesteydelser", eksisterer en sådan procedure muligvis slet ikke. Her opstår spørgsmålet om behovet for seriøs forståelse og analyse af hver modifikation.
• Hvis programmørernes modifikationer brugte standard, vil "linkene" med stor sandsynlighed gå tabt: de fælles moduler er alvorligt ændret: både sammensætningen af ​​deres funktioner og deres navne (arven fra den nye BSP 2.x).
• Samme situation gør sig gældende for metadataobjekter. Et stort antal objekter er blevet "unødvendige", andre objekter bruges i stedet, nogle er blevet omdøbt (for eksempel begyndte biblioteket "Registreringer af VIFNS" at blive kaldt "Registreringer i skattemyndighederne").

Få 267 videolektioner på 1C gratis:

Problemet med industriens "overbygninger"

I øjeblikket, baseret på 1C: Enterprise Accounting-konfigurationen, er der et stort udvalg af brancheløsninger. Disse løsninger installeres ofte som et "tillæg" til konfigurationen.

Hvis vi analyserer markedet, understøttes mange sådanne løsninger ikke længere. Overalt af forskellige årsager: Nogle steder forlod udviklerne virksomheden, andre steder eksisterer udviklingsorganisationen ikke længere. Uanset årsagen er kendsgerningen fortsat - enten overfører vi konfigurationen "for egen regning", eller også mister vi den skattede funktionalitet.

Dette problem kan opfattes meget skarpt af klienten på grund af virksomhedens budgetbegrænsninger for vedligeholdelse og support af softwareprodukter.

Dataomstrukturering og selve processen er meget følsomme emner.

Omstrukturering kan tage lang tid. Borde med stort beløb poster, selv på godt udstyr, kan tage ret lang tid at omstrukturere.

Der var eksempler på, at databasen blev opdateret i flere dage, og til sidst genererede systemet en fejl om, at "informationsregisterindgangen ... er blevet uunik." Denne situation er ganske mulig, det er nødvendigt at være opmærksom på dette og tilføje yderligere tid til risikobanken.

Opdateringsprocessen (start af opdateringshandlere, når programmet startes for første gang) fungerer heller ikke altid korrekt og kan gentagne gange frembringe "overraskelser".

Der er ingen enkelt opskrift på, hvordan man undgår fejl ved opdatering og omstrukturering; ny nuance. Før selve overgangen Nødvendigvis kør opdateringsproceduren og omstrukturering live på serverudstyr flere gange - dette vil hjælpe dig med at undgå unødvendige nerver i timen "H".

Adgangsrettigheder

At dømme efter erfaring opstår problemer med adgangsrettigheder ret ofte. Efter opdateringen skal du sørge for at kontrollere brugerens mulighed for at logge ind i informationsdatabasen. Som regel løses disse problemer ved blot at omskrive brugerens rettigheder (fanen Adgangsgrupper i mappeelementet "Brugere").

Ekstern behandling, rapporter, trykning af formularer

Oversættelse af ekstern behandling, rapporter og trykte formularer leveres på ingen måde af 1C. For at "konvertere" dem skal du tage en bevidst tilgang til sagen:

• for det første skal formularerne skiftes til administreret applikationstilstand;
• for det andet ved ny teknik biblioteker af standardundersystemer, er det nødvendigt at forberede sådanne filer.

(Detaljer om oprettelse af ekstern behandling og rapporter i ITS-artiklen http://its.1c.ru/db/bspdoc#content:22:1:IssOgl2_%D0%A1%D0%BE%D0%B7%D0%B4% D0 %B0%D0%BD%D0%B8%D0%B5%D0%BD%D0%BE%D0%B2%D0%BE%D0%B3%D0%BE%D0%BE%D1%82%D1% 87 %D0%B5%D1%82%D0%B0%D0%B8%D0%BB%D0%B8%D0%BE%D0%B1%D1%80%D0%B0%D0%B1%D0%BE% D1 %82%D0%BA%D0%B8)

Gendannelse af nummerering

Udviklerne sagde selv, at efter at have opdateret programmet til 3.0, er der et problem med nummereringen: det "går på afveje" og begynder at tælle igen. For at returnere nummereringen er det nok at oprette et dokument med den sidste kode, der var i systemet.

For eksempel, hvis det sidste Kvitteringsdokument var nummereret 256, opretter vi et dokument med det samme nummer manuelt (256), og det næste dokument vil automatisk have nummer 257.

Til disse formål kan du skrive en simpel behandling: opret et dokument af hver type med det sidste eksisterende nummer og marker det til sletning.

Udvekslingsregler

Hvis din konfiguration blev udskiftet med en anden ved hjælp af udvekslingsregler, så vil reglerne med meget stor sandsynlighed holde op med at virke. Dette skyldes, at nogle metadataobjekter begyndte at blive navngivet anderledes, nogle detaljer blev slettet, og nogle blev tilføjet.

For korrekt drift skal du indlæse dine regler i "Datakonvertering"-konfigurationen, finde de ændrede detaljer og rette dem. Hvis du er sikker på, at du ved, hvad fejlen er, kan du rette den direkte i xml-regelfilen ved at åbne den i notesblok.

Organisatoriske aspekter

Det sidste punkt blandt vanskelighederne er organisatoriske spørgsmål:

Begrundelse for opdateringsomkostninger til kunden (ledelsen). Dette er et meget vanskeligt problem for klienten. For ganske nylig var der en overgang fra 1.6 til 2.0, og nu 3.0. Hvorfor skal en klient betale penge for en opdatering? Der er kun én trøst: Jeg håber, at der ikke forventes nogen nyskabelser eller større opdateringer i den nærmeste fremtid.

Estimering af lønomkostninger for overgangen. Overgangstiden til en ny version af programmet afhænger i høj grad af graden af ​​ændring af konfigurationen. Det anbefales at forsøge at afstå fra at foretage en for tidlig vurdering og forsøge at gå med til at arbejde "faktisk". Det skyldes, at omstruktureringsprocessen kan tage lang tid, og disse problemer kan på ingen måde forudses på forhånd.

Lad os opsummere og prøve at give nogle generelle anbefalinger for en nemmere og mere behagelig overgang:

• Planlæg din overgang så tidligt som muligt, vent ikke til de sidste dage.
• Det er ønskeligt, at overførslen af ​​funktionalitet udføres af de samme programmører, som afsluttede konfigurationen.
• Prøv at afsætte så meget tid som muligt til omstruktureringen. Hvis du skifter fra mandag, skal du begynde at arbejde fredag ​​aften.
• Før den endelige opdatering af alle forbedringer, skal du sørge for at køre opdateringen i et testmiljø. Uden en "genhør" risikerer du ikke at have tid til at gennemføre opdateringen inden for det teknologiske vindue.
• Tag backup af alt, hvad du kan, så ofte som muligt.
• Overgangen til 3.0 er en glimrende grund til at omstrukturere koden og "inventory"-forbedringer. Hvis du ser, at en eller anden funktionalitet ikke bliver brugt eller er ophørt med at være relevant, så er du velkommen til at sige farvel til det.
• Test den overførte funktionalitet så meget som muligt, opret en testdatabase og start brugere der.
• Skab et miljø for brugerne, hvor de bliver fortrolige med programmet på forhånd - dette vil hjælpe med at undgå simple spørgsmål når du begynder at arbejde med 3.0.
• Hav altid en "Plan B" - hvis noget ikke går som planlagt, så vær forberedt på at rulle tilbage til 2.0 for ikke at lamme virksomhedens arbejde.

Relativt for nylig udgav 1C-selskabet ny version applikationsløsning "1C: 3.0" og stoppede dermed med at understøtte udgave 2.0. Tidligere fortsatte udviklerne efter anmodning fra deres partnere med at støtte tidligere version, men det varede ikke længe.

Denne applikationsløsning er en fortsættelse af den såkaldte legendariske serie af regnskabsprogrammer. Den har en anden grænseflade, den såkaldte administrerede applikation, som giver brugerne helt nye muligheder: Hosting af applikationer i skyen, oprettelse af rapporter i baggrunden og arbejde i webklient-tilstand er også muligt. Udover grænsefladeændringer er der nogle forbedringer, der relaterer sig til regnskabsdelen: Lønregnskabsmodulet er blevet udvidet, og skatteregnskabet er blevet mere logisk og bekvemt.

Hvad er kendetegnene ved overgangen?

Overgangen fra 1C Accounting-løsningen fra udgave 2.0 til 3.0 vil uden tvivl være uundgåelig for alle virksomheder, hvor den bruges. Det er vigtigt at sige, at selve overgangen slet ikke er kompliceret og blot er en "opdatering" af konfigurationen til den næste. Men der er også nogle ulemper. I praksis har vi allerede fået erfaring med overgangen af ​​atypiske konfigurationer, som vi nu vil fortælle om. Nedenfor vil vi se på de funktioner og problemer, der opstår i konfigurationer med et ændringsniveau, der er "større end gennemsnittet."

Påkrævet udgivelse

For at skifte til en anden konfiguration behøver du lidt: frigiv konfigurationen af ​​udgaven "2.0", hvorfra du skal skifte til den nye version. Du kan finde ud af, hvilken udgivelse der er påkrævet på hjemmesiden. Der er information om de aktuelle versioner, der er egnede til opdatering. For eksempel er den nuværende version i dag "3.0.27.7", som kan opdateres fra udgivelsen "2.0.53.6".

Hvordan tilpasser man konfigurationsændringer?

Hvis brugeren har at gøre med en atypisk konfiguration, er den første ting at gøre at overføre forbedringer fra funktionaliteten af ​​den anden version til den tredje.

For at få en liste over ændringer skal du sammenligne (sammenligne) informationsdatabasens konfiguration med leverandørens konfiguration. Samtidig skal du kontrollere, at udbyderens konfiguration forbliver opdateret.

I dette tilfælde er der visse funktioner:

Forbedringer, der er foretaget på "almindelige" formularer, kan ikke blot overføres til administrerede formularer. Her er der behov for at tilpasse programkoden;

- "Accounting 3.0" er i sin kerne en ny softwareløsning. Hvis f.eks. ændringen før dette var i et dokumentmodul kaldet "Modtagelser af varer og tjenesteydelser" (funktionen "Beregn procentdel af tillæg"), eksisterer ovenstående procedure muligvis slet ikke. Så opstår spørgsmålet om behovet for seriøs forståelse, samt analyse af hver af forbedringerne;

Når programmører brugte typiske fælles moduler i modifikationer, vil mest af alt alle "links" gå tabt. Nu har de generelle moduler gennemgået væsentlige ændringer: både deres navne og sammensætningen af ​​deres funktioner (arven fra den nye 2.x);

En lignende skæbne påvirkede metadataobjekter. En lang række af dem er blevet "unødvendige", så at sige. I stedet for sidstnævnte begyndte andre objekter at blive brugt, og nogle af dem blev omdøbt (for eksempel ændrede en mappe med navnet "Registration VIFNS" sit navn til "Registrering i skattemyndighederne");

Problemet med industriens "overbygninger"

I øjeblikket er der baseret på konfigurationen kaldet "1C: Enterprise Accounting". et stort antal af brancheløsninger. Disse løsninger er i de fleste tilfælde installeret som en "add-on" konfiguration.

Som et resultat af markedsanalyser understøttes mange sådanne løsninger ikke længere. Dette skete af helt andre årsager. I nogle tilfælde forlod udviklerne virksomheden, og i andre eksisterer udviklervirksomheden ikke længere. Derfor er valget dette: mister den værdsatte funktionalitet eller overfør konfigurationen "for egen regning."

På grund af virksomhedens begrænsede budget og programstøtte kan dette problem være meget følsomt for kunderne.

Data omstrukturering

Generelt er 1C-opdateringsprocessen, især dataomstrukturering, meget følsomme spørgsmål.

Selve omstruktureringen tager meget tid. Omstrukturering af tabeller, der har et betydeligt antal poster, og selv med god hardware, kan også tage meget tid.

Der er tilfælde, hvor opdateringen af ​​databasen tog flere dage, og i slutningen rapporterede systemet en fejl, der sagde, at "informationsregisteret... er blevet uunik." Naturligvis kan sådanne situationer eksistere, men du skal være opmærksom på dette, og der skal indbygges yderligere tid i din risikobank.

Selve opdateringsprocessen (ved første lancering software lancering af opdateringsbehandlere) fungerer heller ikke korrekt i alle tilfælde (uden fejl) og kan nogle gange forårsage problemer.

I dag er der ingen enkelt handlingsalgoritme, der kan hjælpe med at undgå fejl. Når alt kommer til alt, hver gang kan en ny "behagelig nyhed" dukke op. Det eneste for at undgå unødvendige nerver i timen "H", i begyndelsen af ​​den umiddelbare overgang, råder vi dig til at køre opdaterings- og omstruktureringsproceduren "live" flere gange på serverudstyret.

Et par ord om adgangsrettigheder

Vores erfaring tyder på, at den gennemsnitlige bruger ganske ofte kan have problemer med adgangsrettigheder. Efter opdatering skal du sørge for at tjekke dine login-muligheder og informationsdatabase. Typisk kan disse problemer løses ved at omskrive brugerens tilladelser (fanen kaldet "Adgangsgrupper" i biblioteksposten kaldet "Brugere").

Trykte skemaer, ekstern behandling og rapporter

Oversættelse af trykte formularer, ekstern behandling og rapporter leveres ikke af 1C på nogen måde. For at "konvertere" dem skal du tage en bevidst tilgang til sagen.

Til at begynde med skal du overføre formularerne til den administrerede applikationstilstand. Så skal vi forberede sådanne filer ved hjælp af den nye standard undersystembiblioteksmetode.

Nummergendannelsesproces

Selv udviklerne bemærkede selv, at efter opdatering af softwareproduktet til version "3.0" er der problemer med nummereringen: det "går på afveje" og begynder derefter at tælle igen. For at returnere nummereringen er det nok at generere et dokument med den sidste kode, der var i systemet.

For eksempel, hvis det sidste dokument kaldet "Kvittering" havde nummer 256, så skal du oprette et dokument med det samme nummer, indstillet manuelt (256). Følgende dokument er derfor i automatisk tilstand kommer ind på nummer 257.

Til sådanne formål er det muligt at skrive en simpel behandling. Det betyder, at man danner et dokument af hver type med det sidste eksisterende nummer og udpeger det med henblik på sletning.

Hvad er udvekslingsreglerne?

Hvis for eksempel din konfiguration blev udskiftet med en anden ved hjælp af udvekslingsregler, så vil reglerne i næsten alle tilfælde ikke fungere. Denne situation opstår, fordi nogle metadataobjekter begyndte at have forskellige navne, nogle detaljer blev slettet, andre blev tilføjet.

For at fungere korrekt skal du indlæse dine regler i en konfiguration kaldet "Datakonvertering". Find derefter de detaljer, der er ændret, og ret dem. Hvis du ved hvad fejlen er, så kan den eksisterende fejl rettes i regelfilen " ". Den kan åbnes i notesblok.

Lidt om organisatoriske spørgsmål

Blandt vanskelighederne skal man være opmærksom på organisatoriske spørgsmål:

Begrundelse af omkostningerne ved opdatering til klienten. For sidstnævnte er dette et ret svært spørgsmål. Relativt for nylig var der lige en overgang fra "1.6" til "2.0", så gik der lidt tid, og konfigurationen skal allerede ændres til "3.0". Hvorfor skulle kunden igen give sine midler til en opdatering? Brugeren kan dog trøstes med, at 1C-virksomheden ikke planlægger nogen opdateringer eller større innovationer i den nærmeste fremtid.

Hvilke udgifter skal du forvente under overgangen? Den tid det tager at skifte til en ny version af et softwareprodukt afhænger i høj grad af graden af ​​konfigurationsændring i sig selv. En af anbefalingerne er at afstå fra at foretage for tidlige vurderinger og i stedet gå med til at arbejde "som en kendsgerning." Omstruktureringsprocessen kan trods alt fortsætte meget længere end planlagt. Ulempen er, at ovenstående problem ikke kan forudsiges på nogen måde.

Nu vil vi drage visse konklusioner og forsøge at give råd om en mere komfortabel og enklere overgang:

Spild ikke tid, planlæg din overgang så tidligt som muligt;

Det ville være bedre, hvis overførslen af ​​funktionalitet blev udført af de samme specialiserede programmører, som arbejdede på at færdiggøre konfigurationen;

Det er tilrådeligt at afsætte så meget tid som muligt til omstrukturering. For eksempel, hvis du planlægger at skifte fra mandag, ville det være bedre at begynde at arbejde fredag ​​aften;

Før du foretager endelige ændringer, skal du køre opdateringerne i et tekstmiljø. Uden den såkaldte “repetition” er der risiko for ikke at kunne gennemføre opdateringen i tide i det teknologiske vindue;

Der bør laves sikkerhedskopier af alt, og disse operationer bør udføres så ofte som muligt;

Overgangen til "3.0" er en god grund til at "tage opgørelse" over forbedringer og koderefaktorering. Hvis du ser, at en bestemt funktionalitet ikke bliver brugt eller har mistet sin relevans, så sig farvel til den uden tøven;

Du kan også teste den overførte funktionalitet oftere. Opret en testbase og start brugere ind i den;

Skab et miljø for brugerne, hvor de kan stifte bekendtskab med software produkt. Dette vil gøre det muligt i fremtiden at undgå simple spørgsmål, når man begynder at arbejde med “3.0”;

Der skal altid være en Plan B på lager. Hvis noget ikke fungerede med "3.0", bliver du nødt til at vende tilbage til "2.0" for ikke at stoppe driften af ​​virksomheden.

Før du skifter til den nye udgave, skal du gøre det sikkerhedskopi. For at gøre dette skal du køre infobasen i mode Konfigurator og i menuen Administration vælg element Download infobase. I den dialog, der åbnes, skal du blot angive navnet på den fil, som dataene skal skrives ind i.

Start databasen i tilstanden KONFIGURATØR på vegne af Administrator databaser eller vælg bruger med rettigheder database Administrator. For en korrekt overgang fra BP 2.0 til BP3.0 skal du installere den ekstra rolle ""

Dette kan gøres ved at vælge Konfigurator menupunkt " Administration - Brugere" og åbn den ønskede bruger på listen.

På fanen " Andre"du skal markere feltet ud for varen" Systemadministrator (for overgang til udgave 3.0)"og" Fuld rettigheder".

Efter at have klikket på " Okay" ændringerne vil blive gemt.

Overgangen til udgave 3.0 må kun udføres på vegne af en databasebruger med disse rettigheder.

Trin 2. Opdatering af databasen i Configurator mode

For at vælge den korrekte opdateringsfil skal du kende den aktuelle konfigurationsversion. Du kan se den aktuelle version ved at klikke på ikonet "Om programmet" eller i menupunktet Reference vælg element "Om programmet"

Åbn databasen i tilstanden Konfigurator på vegne af den bruger, som du har givet rettigheder til.

I menupunktet " Konfiguration/Support » klik « Opdater konfiguration " Hvis varen " Support" ikke tilgængelig, klik på " Konfiguration - Åbn konfiguration " og gentag handlingen.

I det vindue, der åbnes, skal du vælge " Valg af en opdateringsfil " ved at trykke på knappen Yderligere

Angiv stien til opdateringsfilen: Eksterne behandlinger N:\1C-opdateringer\Overgangsfiler fra BP 2.0 til BP 3.0

Klik i det næste vindue « Parat » for at starte opdateringsprocessen.

Efter nogen tid vil programmet downloade information om opdateringsfilen, og du vil se et vindue som dette:

Ved et klik på en knap Okay Kobegynder. Det kan tage noget tid.

I løbet af opdateringsperioden vil du modtage to beskeder, først klik JA- Opdaterionen, tryk på den anden ACCEPTERE- omlægning af tabeller.

Trin 3: Fuldførelse af opdateringen

Når opdateringen er fuldført, skal du klikke på knappen "Start fejlretning." Databasen åbnes i tilstand Selskab og du vil se en meddelelse, der bekræfter lovligheden af ​​opdateringen. Afkrydsning "Jeg bekræfter" og tryk "Blive ved".

Efter opdateringen er bekræftet, vil databasen tage noget tid at forberede ændringerne (programmet kan se ud til at være frosset).

Du bør vente på, at opdateringen er færdig.

Dette fuldender overgangen til version 3.0.

Kunne du ikke opdatere? Kontakt en specialist!

Sandkasse

fremmed 8. juli 2013 kl. 12.33

Overgang til udgave 3.0 af virksomhedens regnskabskonfiguration

Dette er navnet på instruktionerne på "ITS PROF"-disken i afsnittet om nye udgivelsesmaterialer. Efter at have prøvet at udføre de tricks, der er beskrevet i denne vejledning, bør du have dit eget virksomhedsregnskab (BP) 2.0, men med administrerede formularer og tilsyneladende, kortspil og luskede kvinder. Alle handlinger vil blive udført med filversionen af ​​databasen.
Jeg ventede specifikt på disken med ITS og opdagede, at instruktionerne, der blev offentliggjort på den, ikke var sande, selvom de var i den opdaterede sektion. Lad os prøve at lave denne overgang på egen hånd.

ITS disk skærm

Billedet ovenfor viser proceduren, og alt ser ud til at være enkelt, men kun på ITS-hjemmesiden i BP 3.0-sektionen finder du ikke versioner, der starter med to.

Skærmbillede af en rigtig ITS hjemmeside

Således fører det allerførste afsnit af instruktionerne brugeren til en blindgyde. Det vil ikke være muligt at opdatere til en anden, dato-matchende eller nyeste version. Den allerede eksisterende opdateringsdistribution fra version 2.0 er ikke angivet. Men der er et komplet distributionssæt, der indeholder de nødvendige opdateringer. Download denne distribution og installer den i skabelonmappen. "Tricket" ved denne distribution er, at den indeholder filen "1Cv8.cf", som er det, vi har brug for. Med dens hjælp vil vi skabe en ren BP 3.0-konfiguration og indlæse vores database med BP 2.0 i den.
Vi installerer platform 8.3, bemærk tyndklientfilversionen og webserverudvidelsesmoduler (for at lege med de "nye" godbidder i regnskabet). Åbn den "gamle" (8.2) konfigurator, og tilføj rettighederne "Systemadministrator (til overgang til revision 3.0)" til den bruger, som vi vil opdatere under. Vi aflæser databasen, lukker konfiguratoren og åbner den "friske" (8.3). Vi skaber i det ny base, fra skabelonen, med version 3.0, dukkede denne skabelon op, da vi installerede den fulde distribution. Åbn den oprettede database og download download af vores database. Denne operation kan tage lang tid. Når uploaden er fuldført, skal du åbne databasen (ikke fra konfiguratoren) og fuldføre opdateringen (denne handling tager også meget tid). Jeg anbefaler at komprimere databasen, da den efter disse trin næsten blev fordoblet.
Hvis din konfiguration ikke indeholdt ændringer (tilføjelser), så vil opdateringen højst sandsynligt foregå uden fejl, men i tilfælde af 1C kan du ikke være helt sikker på noget.
Alle. Du kan åbne databasen med en tynd klient, publicere den på en WEB-server og starte 1C gennem en browser.
P.S:
1. Brug ikke 1C Denwer som webserver.
2. Publicer den database, der fysisk er placeret på webserveren.
Disse tips hjælper dig med at udgive 1C på en webserver i første forsøg.

Tags: systemadministration, 1s virksomhed 8, regnskab

Denne artikel er ikke genstand for kommentarer, fordi dens forfatter ikke er det endnu