Vegyünk egy tipikus helyzetet, amelyben a kezdők gyakran találják magukat. Tegyük fel, hogy létezik az 1C tipikus konfigurációja: Integrated Automation 8. Kezdetben a konfigurációt a disztribúciós készletből telepítették (tegyük fel az 1.1.20.1-es kiadást). Aztán a vállalkozás sajátosságaihoz való alkalmazkodás szükségessége miatt bekerült a változtatás lehetősége is (az újonnan érkezők nagyon gyakran tévesen támogatásból való kivonásnak nevezik ezt az akciót, pedig valójában ez nem így van).

És most, egy idő után, egy erősen módosított, de még mindig szabványos (szabályozott könyvelés céljából rendszeresen frissítettük) konfigurációval rendelkezünk. Nézzünk néhány hipotetikus helyzetet:

1) Valamivel a következő frissítés után üzenetet kapunk a könyvelési osztálytól a rutin hó végi zárási művelet során fellépő hibáról. Korábban nem volt ilyen hiba, ezért a frissítés a hibás. Egészen tipikus helyzet. Elkezdjük diagnosztizálni a hibát, és azt látjuk, hogy a lábak kinőnek az ÁFA elszámolása és a mozgások kialakulása általános modulból. Kezdjük megérteni és megérteni, hogy ezt a modult jelentősen átalakították egy szabványossá, és az összevonás után néhány eljárást/funkciót „elveszítettünk” (vagy ahogy az a szabványosoknál gyakran előfordul, „ugrottak” egy másik közös modulba). A bonyodalmakra való tekintettel közös modulok egymás között tipikus módon, a frissítési szakaszban nem mindig lehet azonosítani egy olyan problémát, amely csak a felhasználók munkája során jelentkezik.

Tehát megértjük, hogy ennek kiderítéséhez szükségünk van az aktuális kiadás tipikus konfigurációjára (tegyük fel, hogy az 1.1.23.1). De hol kaphatom meg? Ha van egy ismerős francia, aki gyorsan el tudja küldeni az elosztókészletet, remek, de tegyük fel, hogy nincs ott, és a problémát sürgősen orvosolni kell. (Ne javasold Varesét!). Sőt, előfordulhat, hogy nincs internet, és mit kell tenni ilyen helyzetben? Többször tanúja voltam olyan folyamatnak, ahol egy személy telepítette új alap a meglévő kezdeti disztribúcióból, majd következetesen frissítette a legújabbra, hogy egy tiszta adatbázisban lássa, „hogyan is kellene valójában lennie”. És a láda, mint mindig, most is kinyílt :)

Most nézzük a különböző megoldásokat:

a) Első lehetőség: Menü -> Konfiguráció -> Konfigurációk összehasonlítása, majd válassza ki a szállítói konfigurációt és hasonlítsa össze a fő konfigurációval.

Meglepő módon vannak, akik nem tudnak erről. Vagy bármilyen körülmények között használja az Összehasonlítás elemet, kombinálja a fájl konfigurációjával (miután korábban megkapta/kapta a szabványos .cf fájlt).

b) A második módszer akkor megfelelő, ha nem csak a változásokat kell látnunk, hanem azonnal végre kell hajtanunk az egyesítést is.

Menü -> Konfiguráció -> Támogatás -> Támogatási beállítások, majd alul kattintson az Összehasonlítás, egyesítés gombra.

2) Egy másik helyzet: tegyük fel, hogy megváltoztattunk vagy töröltünk egy szabványos kódot, és egy idő után kiderült, hogy hibáztunk, és mindent vissza kell raknunk. És ahogy ez gyakran megesik, a módosítások végrehajtása előtt nincs biztonsági másolat a mentett konfigurációról. De biztosan tudjuk, hogy ez a kódrészlet benne van a szabványos kódban, így a gyártói konfiguráció megoldaná a problémát.

Természetesen ugyanazt teheti, mint az első esetben. Várja meg, amíg az összehasonlítási folyamat befejeződik, majd a konfiguráció-összehasonlító ablakból nyissa meg a szabványos modult, és másolja ki onnan a kódot.

Vannak, akik ezt teszik, de ha olyan szörnyeteggel van dolgunk, mint az UPP, amely szintén erősen módosított, akkor nagyon sokáig várhatunk az összehasonlítási folyamat befejezésére. Ha lenne .cf fájlunk, akkor egyszerűen megnyithatnánk a konfigurációs ablakban (egyébként nem minden kezdő ismeri ezt a funkciót), és onnan másolhatnánk ki a szükséges kódot.

És felmerül egy ésszerű kérdés: hogyan lehet mégis fájlba menteni a szállító konfigurációját? Miért nincs a Konfiguráció mentése fájlba a fő konfigurációhoz vagy az Adatbázis-konfiguráció mentése fájlba az adatbázis-konfigurációhoz hasonló menüelem. Hol van ugyanez a szállítói konfigurációnál? Sőt, ott is van, csak egy kicsit mélyebbre van temetve. Ugyanis minden ugyanabban a formában van a támogatási beállításokban.

Csak annyi, hogy sokan csak egyszer nyitják meg. ezt az űrlapot csak hogy lehetővé tegye a változás lehetőségét, és soha ne térjen vissza hozzá.

Esetünkben pedig még egyszerűbben is meg lehetett csinálni, anélkül, hogy a konfigurációt fájlba mentené, kattintson a Megnyitás gombra. A hatás ugyanaz, de sokkal gyorsabb.

Miért kell egyébként a szállítói konfigurációt fájlba menteni?

3) Tekintsük a következő helyzetet! Tegyük fel, hogy a konfiguráció létezésének kezdeti szakaszában a standard konfiguráció nem rendelkezett azzal a funkcionalitással, amire szükségünk volt, és döntés született a javításáról. A módosítás minimális volt, de a jövőben még kellemetlenséget okozott a frissítés során. De aztán egy idő után rájövünk, hogy ez a funkció (mint az objektumverzióval egy időben) megjelent a szabványos verzióban (és ahogy ez gyakran megesik, egy nagyságrenddel jobban implementálták, mint a „makeshift” módosítást ).

Hozok még néhány példát a valós helyzetekre, amikor a visszalépés tipikus konfiguráció:

1. Néhányszor találkoztam olyan konfigurációkkal, amelyekben csak a nyomtatott űrlapok elrendezése volt módosulni. Tapasztalatlanság vagy tudatlanság miatt a konfigurációt kísérő programozó ahelyett, hogy külsőt hozna létre nyomtatott formában eltávolította a konfigurációt a támogatásból, és módosította a beépített elrendezéseket (gyakran triviálisan a vállalati logó hozzáadásához), ami után a felhasználókat megfosztották az automatikus frissítés lehetőségétől.

2. Megint tudatlanságból tipikus funkcionalitás(nagyon gyakran a korábbi „hétéves hallgatók” szenvednek ettől) a tulajdonságok és kategóriák használata helyett a referenciakönyvek/dokumentumok részleteit adták hozzá, ha erre nem volt alapos indok (pl. az adatokat csak a nyomtatott űrlapokra való kiadáshoz használták fel) ).

Természetesen ez nem probléma, ha UT vagy más kezelési terv konfigurációról van szó, ahol a frissítések általában nem kritikusak, de ebben a példában módosított SCP-kről vagy összetett automatizálásról beszéltünk. És kiderül, hogy a kisebb fejlesztések miatt, amelyeket a teljes támogatás eltávolítása nélkül is meg lehetett volna valósítani, a szokásos frissítésekkel felesleges aranyéreink vannak.

Ésszerű a szándék az elvégzett módosítások elhagyására és a konfiguráció teljes támogatásra való visszaállítására. Hogyan kell ezt csinálni?

A konfiguráció teljes támogatásának visszaállításának egyetlen módja a standard.cf betöltése (nem az összehasonlítás és egyesítés módban, hanem a Konfiguráció betöltése fájlból elem). Ezért van szükségünk arra, hogy a szállítói konfigurációt .cf fájlba mentsük. Mentjük, majd betöltjük, és az adatbázis konfiguráció frissítése után megkapjuk a standard konfigurációt eredeti formájában, azaz. zárral :) Természetesen ezen műveletek végrehajtása előtt gondoskodni kell a szükséges adatok mentéséről/átviteléről, amelyek a normál konfigurációba való visszatérés után „elmosódnak” és feltétlenül biztonsági másolat adatbázisok!

Ezek, mint kiderült, egyszerű lehetőségek állnak a fejlesztői arzenál rendelkezésére, ám a gyakorlatban ezeknek a technikáknak a tudatlansága sokórás, fentebb leírt felesleges felhajtást eredményezhet. Tehát akik tudták - jól sikerült, és akik nem tudták -, vegyék üzembe, és takarítsák meg az idejét.

Volt egy kérdés:
Hány konfiguráció van benne információs bázis?
Helyes válasz 3

Az IS felépítése a következőket tartalmazza:
1. Alapkonfiguráció.
2. Adatbázis konfiguráció.
3. Szolgáltató konfigurációja(lehet, hogy hiányzik).

4. Plusz felhasználói adatok (dokumentumok, könyvtárak stb.)

A konfiguráció meghatározza az adatbázis szerkezetét, és algoritmusokat tartalmaz, amelyek biztosítják az adatokkal való munkát.

A fejlesztők a fő konfigurációval dolgoznak. A felhasználók az adatbázis-konfigurációval dolgoznak.

Szállító konfigurációja – a szabványos megoldásszállító kezdeti konfigurációja.

Ha az infobázis sablonból van telepítve és a szállító támogatja, akkor az információbiztonságon belül a szállító konfigurációja meg fog jelenni.

Ha a konfiguráció támogatás alatt áll, és az objektumok módosítása tilos, akkor két konfiguráció kerül tárolásra az infobázisban – az alapkonfiguráció és az adatbázis-konfiguráció.

Ha engedélyezi a konfiguráció módosításának lehetőségét (parancs Szerkesztési lehetőség engedélyezése a párbeszédben" Támogatás beállítása"), platform a fő konfigurációból létrehozza a szolgáltató konfigurációját. Az információbiztonság mérete növekszik.

A szolgáltató konfigurációja csak olvasható.

A szállítói konfiguráció megtekintéséhez válassza a lehetőséget
Konfiguráció – Támogatás – Támogatási beállítások – Megnyitás.

Az információs bázis több szállítói konfigurációt is tartalmazhat, ha a konfiguráció több szállítót is támogat. Ez a séma ipari cirkulációs megoldások használatakor fordul elő.

Az 1C támogatás alapjai

Az 1C frissítés végrehajtható felhasználói módban, konfigurátor módban, valamint a beállítások összehasonlításában és összevonásában.

Támogatásból való eltávolítás

A „Támogatás beállításai” párbeszédpanelen, amikor az Eltávolítás a támogatásból gombra kattint A szállítói konfiguráció törlése folyamatban van. Ezt a funkciót olyan esetekben kell használni, amikor standard oldatot használnak alapul saját fejlesztésés nem tervezik elkísérni.

Ha le kell töltenie a szolgáltató konfigurációját. Ezt a Támogatás – Támogatási beállítások menüpontban teheti meg. A „Támogatás beállításai” párbeszédpanelen kattintson a Mentés fájlba gombra.

Ebben a cikkben szeretném megmutatni szolgáltatási képességek Az 1C:Enterprise 8 platformok a beszállító konfigurációjának használata szempontjából, amelyek nagyon gyakran keresettek, de amint azt a gyakorlat megmutatta, nem ismerik minden kezdő és még tapasztalt szakember sem.

Vegyünk egy tipikus helyzetet, amelyben a kezdők gyakran találják magukat. Tegyük fel, hogy létezik az 1C tipikus konfigurációja: Integrated Automation 8. Kezdetben a konfigurációt a disztribúciós készletből telepítették (tegyük fel az 1.1.20.1-es kiadást). Aztán a vállalkozás sajátosságaihoz való alkalmazkodás szükségessége miatt bekerült a változtatás lehetősége is (az újonnan érkezők nagyon gyakran tévesen támogatásból való kivonásnak nevezik ezt az akciót, pedig valójában ez nem így van).

És most, egy idő után, egy erősen módosított, de még mindig szabványos (szabályozott könyvelés céljából rendszeresen frissítettük) konfigurációval rendelkezünk. Nézzünk néhány hipotetikus helyzetet:

1) Valamivel a következő frissítés után üzenetet kapunk a könyvelési osztálytól a rutin hó végi zárási művelet során fellépő hibáról. Korábban nem volt ilyen hiba, ezért a frissítés a hibás. Egészen tipikus helyzet. Elkezdjük diagnosztizálni a hibát, és azt látjuk, hogy a lábak kinőnek az ÁFA elszámolása és a mozgások kialakulása általános modulból. Kezdjük megérteni és megérteni, hogy ezt a modult jelentősen átalakították egy szabványossá, és az összevonás után néhány eljárást/funkciót „elveszítettünk” (vagy ahogy az a szabványosoknál gyakran előfordul, „ugrottak” egy másik közös modulba). A szabványos modulok egymás közötti bonyolultsága miatt a frissítési szakaszban nem mindig lehet azonosítani egy olyan problémát, amely csak akkor jelentkezik, amikor a felhasználók dolgoznak.

Tehát megértjük, hogy ennek kiderítéséhez szükségünk van az aktuális kiadás tipikus konfigurációjára (tegyük fel, hogy az 1.1.23.1). De hol kaphatom meg? Ha van egy ismerős francia, aki gyorsan el tudja küldeni az elosztókészletet, remek, de tegyük fel, hogy nincs ott, és a problémát sürgősen orvosolni kell. (Ne javasold Varesét!). Sőt, előfordulhat, hogy nincs internet, és mit kell tenni ilyen helyzetben? Többször is szemtanúja voltam olyan folyamatnak, amikor egy személy egy adott probléma megoldása érdekében telepített egy új adatbázist a meglévő kezdeti disztribúcióból, majd egymást követően frissítette a legújabbra, hogy lássa, „hogyan kell valójában” tiszta adatbázis. És a koporsó, mint mindig, egyszerűen kinyílt (IMG:)

Most nézzük a különböző megoldásokat:

a) Első lehetőség: Menü -> Konfiguráció -> Konfigurációk összehasonlítása, majd válassza ki a szállítói konfigurációt és hasonlítsa össze a fő konfigurációval.

Meglepő módon vannak, akik nem tudnak erről. Vagy bármilyen körülmények között használja az Összehasonlítás elemet, kombinálja a fájl konfigurációjával (miután korábban megkapta/kapta a szabványos .cf fájlt).

b) A második módszer akkor megfelelő, ha nem csak a változásokat kell látnunk, hanem azonnal végre kell hajtanunk az egyesítést is.

Menü -> Konfiguráció -> Támogatás -> Támogatási beállítások, majd alul kattintson az Összehasonlítás, egyesítés gombra.

2) Egy másik helyzet: tegyük fel, hogy megváltoztattunk vagy töröltünk egy szabványos kódot, és egy idő után kiderült, hogy hibáztunk, és mindent vissza kell raknunk. És ahogy ez gyakran megesik, a módosítások végrehajtása előtt nincs biztonsági másolat a mentett konfigurációról. De biztosan tudjuk, hogy ez a kódrészlet benne van a szabványos kódban, így a gyártói konfiguráció megoldaná a problémát.

Természetesen ugyanazt teheti, mint az első esetben. Várja meg, amíg az összehasonlítási folyamat befejeződik, majd a konfiguráció-összehasonlító ablakból nyissa meg a szabványos modult, és másolja ki onnan a kódot.

Vannak, akik ezt teszik, de ha olyan szörnyeteggel van dolgunk, mint az UPP, amely szintén erősen módosított, akkor nagyon sokáig várhatunk az összehasonlítási folyamat befejezésére. Ha lenne .cf fájlunk, akkor egyszerűen megnyithatnánk a konfigurációs ablakban (egyébként nem minden kezdő ismeri ezt a funkciót), és onnan másolhatnánk ki a szükséges kódot.

És felmerül egy ésszerű kérdés: hogyan lehet mégis fájlba menteni a szállító konfigurációját? Miért nincs a Konfiguráció mentése fájlba a fő konfigurációhoz vagy az Adatbázis-konfiguráció mentése fájlba az adatbázis-konfigurációhoz hasonló menüelem. Hol van ugyanez a szállítói konfigurációnál? Sőt, ott is van, csak egy kicsit mélyebbre van temetve. Ugyanis minden ugyanabban a formában van a támogatási beállításokban.

Csak arról van szó, hogy sokan csak egyszer nyitják meg ezt az űrlapot, hogy engedélyezzék a változtatásokat, és soha többé nem térnek vissza hozzá.

Esetünkben pedig még egyszerűbben is meg lehetett csinálni, anélkül, hogy a konfigurációt fájlba mentené, kattintson a Megnyitás gombra. A hatás ugyanaz, de sokkal gyorsabb.

Miért kell egyébként a szállítói konfigurációt fájlba menteni?

3) Tekintsük a következő helyzetet! Tegyük fel, hogy a konfiguráció létezésének kezdeti szakaszában a standard konfiguráció nem rendelkezett azzal a funkcionalitással, amire szükségünk volt, és döntés született a javításáról. A módosítás minimális volt, de a jövőben még kellemetlenséget okozott a frissítés során. De aztán egy idő után rájövünk, hogy ez a funkció (mint az objektumverzióval egy időben) megjelent a szabványos verzióban (és ahogy ez gyakran megesik, egy nagyságrenddel jobban implementálták, mint a „makeshift” módosítást ).

Adok még néhány példát azokra a valós helyzetekre, amikor szükség lehet a normál konfigurációra való visszaállításra:

1. Néhányszor találkoztam olyan konfigurációkkal, amelyekben csak a nyomtatott űrlapok elrendezése volt módosulni. Tapasztalatlanság vagy tudatlanság miatt a konfigurációt karbantartó programozó ahelyett, hogy egy külső nyomtatott űrlapot készített volna, eltávolította a konfigurációt a támogatásból, és módosította a beépített elrendezéseket (gyakran triviálisan céglogó hozzáadása céljából), ami után a felhasználók megfosztották őket. az automatikus frissítés képességéről.

2. Ismét a szabványos funkcionalitás ismeretének hiánya miatt (ezt nagyon gyakran a korábbi „hétéves hallgatók” szenvedik) a tulajdonságok és kategóriák használata helyett a címtárak/dokumentumok részletei kerültek hozzáadásra, ha erre nem volt alapos oka (adat például csak nyomtatott űrlapokra való kiadáshoz használták).

Természetesen ez nem probléma, ha UT vagy más kezelési terv konfigurációról van szó, ahol a frissítések általában nem kritikusak, de ebben a példában módosított SCP-kről vagy összetett automatizálásról beszéltünk. És kiderül, hogy a kisebb fejlesztések miatt, amelyeket a teljes támogatás eltávolítása nélkül is meg lehetett volna valósítani, a szokásos frissítésekkel felesleges aranyéreink vannak.

Ésszerű a szándék az elvégzett módosítások elhagyására és a konfiguráció teljes támogatásra való visszaállítására. Hogyan kell ezt csinálni?

A konfiguráció teljes támogatásának visszaállításának egyetlen módja a standard.cf betöltése (nem az összehasonlítás és egyesítés módban, hanem a Konfiguráció betöltése fájlból elem). Ezért van szükségünk arra, hogy a szállítói konfigurációt .cf fájlba mentsük. Mentjük, majd betöltjük, és az adatbázis konfiguráció frissítése után megkapjuk a standard konfigurációt eredeti formájában, azaz. zárral (IMG:) Természetesen ezen műveletek végrehajtása előtt gondoskodni kell a szükséges adatok mentéséről/átviteléről, amelyek a normál konfigurációba való visszatérés után „elmosódnak”, és mindenképpen készítsünk biztonsági másolatot az adatbázisból!

Ezek, mint kiderült, egyszerű lehetőségek állnak a fejlesztői arzenál rendelkezésére, ám a gyakorlatban ezeknek a technikáknak a tudatlansága sokórás, fentebb leírt felesleges felhajtást eredményezhet. Tehát azok, akik tudták - jól sikerült, és akik nem tudták -, vegyék üzembe, és takarítsák meg az idejét.

[a link megtekintéséhez regisztráció szükséges]

És így ismét Hello kedves olvasók a blog www.site. Ma arról fogunk beszélni, hogyan lehet feltölteni és letölteni egy konfigurációt az 1C Enterprise-ban. A kérdést már megbeszéltük Önnel. De mint kiderült, teljesen üres lesz. A munka megkezdéséhez be kell töltenie a konfigurációt egy fájlból. A konfiguráció feltöltésének és betöltésének folyamata meglehetősen egyszerű, de nagyon fontos.

Például az 1C 8.2-t fogom használni, de a 8.3-as verziónál ez az utasítás is működik. Nézzük meg közelebbről, mi az a konfiguráció. Megpróbálom ezt a saját szavaimmal elmagyarázni neked. Az 1C konfigurációja dokumentumok, táblázatok, különféle jelentések stb. halmaza, csak kitöltetlenül, üresen, adatok nélkül. Analógia vonható az Excel dokumentumokkal, üres asztal amelyben különféle képletek és diagramok vannak kitöltve, az a konfiguráció. Nagyon sok konfiguráció létezik: Számvitel, Bérek és HR, dokumentum áramlás, Kiskereskedelem, stb. Ezen kívül nagyon sok különböző saját maga által írt konfiguráció létezik.

Konfiguráció feltöltése 1C-ből fájlba

Hogyan tölthetjük fel az 1C konfigurációt egy fájlba? Tehát először is be kell mennünk magába a konfigurátorba, ehhez indítsuk el az 1C-t, és válasszuk ki a kívánt adatbázist, kattintson a Konfiguráció elemre.

A konfigurátorban lépjen a Konfiguráció elemre, és válassza a Konfiguráció mentése fájlba lehetőséget.

Ez az, a konfiguráció feltöltése befejeződött. Most beszéljünk arról, hogyan kell letölteni.

Konfiguráció betöltése az 1C-be fájlból

A feltöltést elintéztük, most nézzük meg a konfiguráció betöltését egy fájlból. Válassza ki a Konfiguráció elemet, és keresse meg a Konfiguráció betöltése fájlból lehetőséget.

A megnyíló ablakban meg kell adnia a konfigurációs fájlt, és kattintson a Megnyitás gombra. Ezután megvárjuk a konfiguráció betöltését.

Zárja be a konfigurátort, és indítsa el az 1C-t normál módban.

Amint látja, minden nagyon egyszerűnek bizonyult.

WiFi