Jak otevřít 

Upřesnění standardních konfigurací 1c. Přidání předdefinovaných prvků

Potřebujete rozšířit funkčnost 1C? Potřebujete program pro řešení nejen standardních, ale i specifických problémů vašeho podniku? Služba úprav 1C od Active-IT vám pomůže tyto problémy rychle vyřešit.

Provádíme úpravy standardních konfigurací 1C jakékoli úrovně složitosti: od vytváření individuálních tištěné formuláře před zavedením algoritmu pro výpočet bonusů za hodiny práce atd.

Doba obratu- až 5 dní. V případě prodlení do 10 dnů Vám provedeme revize zdarma.

Další výhodou spolupráce s námi je, že svou práci děláme vždy v dobré víře. Nepracujeme podle schématu „mám to“. technický úkol==> udělal práci ==> odevzdal to a zapomněl.“ Přijmeme technický úkol, odvedeme práci efektivně, necháme vás vyhodnotit výsledek a případně upravit revizi bez doplatku.

Cena 1C programátoru

Cena úpravy konfigurace: 1500 rublů. za hodinu práce programátora.

V důsledku toho získáte:

  • Spolupráce se zkušenými programátory.
  • Vytváření a implementace vylepšení absolutně jakékoli úrovně složitosti.
  • Dokončení práce v co nejkratším čase - do 5 dnů.
  • Garance vrácení peněz v případě zpoždění.
  • Zajištění kvality.

Objednejte si úpravy 1C Accounting od Active-IT!
Přizpůsobte práci 1C specifikám vašeho podniku s námi.

Téměř všechny projekty v téměř každé velké integrátorské společnosti 1C se skládají z vylepšování standardních konfigurací a jsou zaměřeny hlavně na optimalizaci účetnictví ekonomická aktivita organizování a předkládání příslušných regulovaných zpráv. A to zase znamená, že v budoucnu bude nutné implementovaná řešení upravit v souladu s často se měnící legislativou. V praxi to téměř vždy znamená aktualizaci verzí standardních konfigurací, na kterých bylo řešení založeno, a přizpůsobení již provedených úprav v souladu se změnami v příštím vydání.

Projekt často nelze označit za zcela úspěšný, pokud klient nezůstane u integrátorské organizace pro podporu. A pokud budete dodržovat přísná pravidla pro změnu standardních konfigurací, pak po utrácení velmi málo času ve fázi vývoje můžete ušetřit mnoho a mnoho hodin a nervů v budoucnu na neustálé aktualizaci změněné konfigurace. Naopak hrubý postoj k návrhu kódu „nezajímá mě“ a výběr rychlejších a jednodušších způsobů implementace úkolů, nikoli správných, může proměnit aktualizaci výsledné konfigurace ve skutečné peklo. V budoucnu to bude mít za následek obrovské hodiny aktualizací, ostré pracovní zatížení vývojářů během sledovaného období, velký počet chyby po aktualizaci, nespokojenost zákazníků atd.

Níže je uvedena sada pravidel vývoje v typických konfiguracích, která výrazně usnadní další aktualizace konfigurace. Tento kód se zrodil postupně z mnohaletých zkušeností velkého počtu vývojářů jedné skvělé společnosti a podle mého názoru nejhlubší přesvědčení, by měl být povinný pro všechny vývojáře bez ohledu na to, v jakém oddělení/projektu/směru pracují.

1. Koncept minimalizace „zničení“ standardní konfigurace

Pokud má být upravená standardní konfigurace aktualizována s vydáním nových verzí, měli by to vývojáři vždy si to zapamatujte a podniknout kroky k usnadnění aktualizace. Vždy byste měli zvolit ty metody řešení problémů, které vám poskytnou snadnější aktualizace konfigurace v budoucnu, i když budou poněkud obtížněji realizovatelné. Samozřejmě pouze za podmínky, že metoda pohodlnější pro aktualizaci nemá vážné nevýhody v oblasti výkonu, srozumitelnosti kódu atd.

2. Komentování změn kódu:

Absolutně všechny změny v programovém kódu modulů musí být komentovány. Blok řádků, který prošel změnou, musí být obklopen řádky komentáře zvláštního formátu. Princip vytváření těchto čar je znázorněn na následujícím příkladu:

//++ VION 20.07.2016 0001234 Finalizace na startu //-- VION 20.07.2016
  • //++ - začátek bloku
  • //— — konec bloku
  • VION - jméno (nebo přezdívka) vývojáře
  • 0001234 - číslo úkolu podle trackeru, umístěné pouze v úvodním komentáři, takže každá změna kódu se ve výsledcích globálního vyhledávání podle čísla úkolu objeví pouze jednou
  • Zlepšení na začátku— libovolný komentář, použitý v případě potřeby, ale pokud není uvedeno číslo úkolu, je vyžadován krátký vysvětlující text

Komentáře jsou určeny ke zvýraznění úprav oproti standardním funkcím. Pokud vývojář po nějaké době v rámci stejného úkolu změní text své vlastní úpravy, pak se tyto změny nekomentují samostatně (a nezmění se ani existující externí komentář). Pokud vývojář provede změny ve svém textu, ale pro jiný úkol, nebo se změní kód napsaný jiným vývojářem, pak by se mělo použít komentování.

Prázdné komentáře jsou zarovnány k levému okraji upraveného bloku kódu. Níže uvedené příklady ukazují, jak používat komentování změn:

2.1 Vložení kódu

Příklad:

Procedure On Opening() If This Is New() Then Fill Fields Default(); endIf; SetFormElements(); //++ VION 07/20/2016 0001234 ConfigureAdditionalElements(); //-- VION 20.07.2016 SetFieldVisibility (); Konec procedury

2.2 Odstranění kódu

Příklad:

Postup OnOpen() //++ VION 20.07.2016 0001234 //If This is New() Then // Fill in the Default Fields(); //EndIf; ConfigureAdditionalItems(); //-- VION 20.07.2016 SetFieldVisibility (); Konec procedury

2.3 Úprava stávajícího kódu

Při změně stávajícího kódu musí být starý blok nejprve zakomentován a poté je zapsána nová verze.

Příklad:

Procedura OnOpen() If This Is New() Then //++ VION 20.07.2016 000123 //Vyplnit pole ve výchozím nastavení(); FieldFillSetting = GetFieldFillSetting(); FillFieldsDefaultExtended(SettingFillFields); //-- VION 20.07.2016 EndIf; SetFormElements(); SetFieldVisibility (); Konec procedury

2.4 Přidání procedur a funkcí do modulu

Pro přidané procedury a funkce, stejně jako pro deklaraci modulových proměnných standardních objektů, platí následující: dodatečná pravidla formátování komentářů:

  • Nekomentuje se blok přidaných procedur jako celek, ale každý přidána procedura nebo funkce odděleně.
  • Úvodní komentář jde na řádek předcházející záhlaví procedury nebo funkce a závěrečný komentář na stejné lince, kde je uvedeno „Konec postupu“ nebo „Konec postupu“, oddělené mezerou.
  • Připomínkování změn v rámci stávajících postupů se provádí pomocí hlavní pravidla.

Příklad:

//++ VION 20.07.2016 000123 Variabilní plnění mSettingField; Postup ModifyFormProgrammatically () ... ... KonecPostupu//-- VION 20.07.2016 //++ VION 20.7.2016 000123 Postup DatumShipmentZpracováníSelection () ... ... KonecPostupu//-- VION 20.07.2016

Toto pravidlo vám umožňuje snadno přenášet změny v modulu při „procedurálním porovnání“ konfigurací.

Pokud vložíte závěrečný komentář na další řádek:

Poté bude při „procesním srovnání“ tato poznámka uznána jako popis dalšího postupu v textu, který bude považován za změněný.

3. Přidání objektů nejvyšší úrovně

Jména objekty nejvyšší úrovně, vytvořené v konfiguraci, Nezbytně musí začínat prefixem vaší společnosti nebo konkrétním prefixem projektu. Zpravidla se skládá ze dvou nebo tří velká písmena a podtržítka, například AB_. Podle toho se budou nazývat vytvořené objekty AB_Nový adresář, AB_NewInformationRegister, AB_NewDocument atd.

Synonyma (uživatelsky viditelná jména) přidaných objektů nejvyšší úrovně musí začínat předponou uzavřenou v závorkách: (AB). V důsledku toho budou tyto objekty v seznamech vizuálně zvýrazněny a seskupeny na jejich začátku (což usnadňuje testování i používání).

V komentáři k vytvořenému objektu byste měli uvést jméno vývojáře, datum a číslo úkolu, podobně jako přidávaný kód, ale bez znaků „++“. To zajistí, že konfigurační objekt bude přidružen k úloze nalezené globálním vyhledáváním.

Příklad: Vytvořte adresář „Projekty“.

Vývojářské akce: v konfiguraci je vytvořen následující adresář:

  • Název: AB_Projects
  • Synonymum: (AB) Projekty

4. Přidání podřízených objektů

Způsob přidání podrobností konfiguračního objektu závisí na tom, ke kterému konfiguračnímu objektu je vlastnost přidána: do konfiguračního objektu vytvořeného dodavatelem standartní řešení(tj. objekt pod podporou) nebo objekt přidaný jako součást aktuálního projektu (tj. již má předponu).

4.1 Přidání podřízených objektů ke standardním konfiguračním objektům

Podřízené objekty přidané do existujících (standardních) konfiguračních objektů musí být předpona: AB_Další rekvizity, AB_NewTabularPart, AB_FormUserSettings, AB_LayoutSpecialInvoice. Ale zároveň se vytvářejí synonyma takových podřízených objektů bez předpony.

V komentáři k vytvořenému objektu byste měli uvést jméno vývojáře, datum a číslo úkolu, podobně jako . To zajistí, že konfigurační objekt bude přidružen k úloze nalezené globálním vyhledáváním.

Příklad: Vytvořte atribut „Projekt“ dokumentu „Platba předem“.

Vývojářské akce: v konfiguraci je vytvořen následující atribut:

  • Název: AB_Project
  • Synonyma: Projekt
  • Komentář: // VION 20.07.2016 000123

4.2 Přidání podřízených objektů k objektům přidaným v rámci projektu

Podřízené objekty přidané k objektům nejvyšší úrovně přidaným do konfigurace v rámci projektu, tj. které již obsahují předponu v názvu, jsou přidány bez předpony. Vznikají také synonyma pro takové podřízené objekty bez předpony.

V komentáři k vytvořenému objektu byste měli uvést jméno vývojáře, datum a číslo úkolu, podobně jako . To zajistí, že konfigurační objekt bude přidružen k úloze nalezené globálním vyhledáváním. Komentář lze vynechat, pokud jsou podrobnosti vytvořeny jako součást stejné úlohy jako samotný objekt nejvyšší úrovně.

Příklad: Vytvořte atribut „Responsible“ v adresáři „(AB) Projects“.

Vývojářské akce: Pokud se úkol liší od úkolu, ve kterém byl vytvořen adresář „(AB) Projects“, pak se v konfiguraci vytvoří následující podrobnosti:

  • Jméno: Zodpovědný
  • Synonymum: Zodpovědný
  • Komentář: // VION 20.07.2016 000456

5. Přidání předdefinovaných prvků

Při přidávání předdefinovaných prvků adresáře, tabulek charakteristických typů a účtových osnov byste měli používat stejná pravidla jako při přidávání podřízených objektů ( tabulkové části, detaily) do objektů nejvyšší úrovně.

5.1 Přidání předdefinovaných prvků do standardních konfiguračních objektů

Nezbytně jsou přidány předdefinované prvky pro typické konfigurační objekty s předponou. Jméno je dáno bez předpony.

Příklad: Přidejte předdefinovaný účet 10.15 do účtového rozvrhu „Nákladové účetnictví“ – Přísné výkazy.

Vývojářské akce: Přidejte následující předdefinovaný účet:

  • Název: AB_FormsStrictReporting
  • Kód: 10.15
  • Název: Přísné formuláře hlášení

Pokud potřebujete přejmenovat předdefinovaný prvek typického konfiguračního objektu (například fakturu), měli byste ponechat samotný objekt beze změny a provést přejmenování programově ve speciálním .

5.2 Přidání předdefinovaných prvků k objektům přidaným v rámci projektu

Předdefinované prvky se přidávají ke konfiguračním objektům přidaným v rámci projektu, tj. již obsahují předponu ve svém názvu bez předpony ve jménu a titulu.

6. Použití společných modulů a jejich striktní struktura

Procedury a funkce opakovaně používané v konfiguraci, procesorech pro odběry a rutinní úlohy jsou umístěny ve společných modulech. Pro tyto účely byste měli přidat vlastní moduly, přidané objekty nejvyšší úrovně a ponechávají standardní moduly beze změny. Při vývoji budou užitečné následující společné moduly (předpona „AB_“):

  • AB_General Purpose (klient, server, externí připojení) - pro běžné postupy a funkce.
  • AB_Server (pouze server) - pro procedury a funkce, které musí být spuštěny v prostředí serveru.
  • AB_Global - pro procedury a funkce, které je nepohodlné volat standardním způsobem (přes název modulu a období).
  • AB_Privileged - pro procedury a funkce, které je vždy nutné provádět s plnými právy.
  • AB_Reuse - uložit do mezipaměti návratové hodnoty některých funkcí.

Kód funkčních bloků můžete vložit do samostatných společných modulů velký objem, v tomto případě je ladění takového kódu zjednodušeno při použití konfiguračního úložiště. V ostatních případech by se měl vývojář před přidáním nového modulu do konfigurace ujistit, že je k dispozici vhodný společný modul.

7. Využití předplatných a jejich striktní struktura

Chcete-li zpracovat různé události spojené se standardními konfiguračními objekty, měli byste použít mechanismus předplatného namísto provádění úprav modulů samotných objektů, pokud je to možné.

Pro každou událost může být ne více než jedno předplatné(jako objekt metadat), do kterého musí být umístěn handler a související kód samostatný společný modul(pro zvýšení paralelismu práce vývojářů s úložištěm). Název předplatného a společný název modulu musí být jsou stejní A korespondovat zpracovávaná událost. Je uveden zdroj předplatného Všechno objekty potenciálně možné ke zpracování (všechny adresáře, všechny dokumenty atd.).

Procedura zpracování předplatného musí obsahovat volání dílčích procedur, které provádějí požadované akce. Jsou přístupné v závislosti na typu zdroje a také v požadovaném pořadí. Při přidávání kódu pro nové úkoly se provádí komentáře v modulu předplatného.

Příklad: Při zaúčtování dokladu „Zálohová platba“ proveďte záznamy do akumulačního registru „(AB) Projektové náklady“.

Vývojářské akce:

1. Vytvořte předplatné „AB_DocumentsProcessingProcessing“ (pokud takové předplatné nebylo vytvořeno dříve), zadejte všechny dokumenty jako zdroj, událost je „ProcessingProcessing“.

2. Vytvořte společný modul serveru „AB_DocumentsProcessing“.

3. V modulu vytvořte exportní proceduru „ProcessingProcessing“. Vyberte tento postup jako obslužnou rutinu pro dříve vytvořené předplatné. V proceduře jsou v závislosti na typu dokumentu volány potřebné handlery.

4. Modul dokladu „Platba předem“ by měl zůstat nezměněn.

8. Editace formulářů

8.1 Úprava tvarů standardních objektů

Pokud je změna na standardní formulář (běžný i spravovaný) malá (například přidání několika nových detailů do formuláře), měla by být taková změna provedena zcela programově. To znamená, že změny se provádějí pouze v formulářový modul, a samotný formulář zůstane v konfigurátoru beze změny. Některým vývojářům může tento způsob úpravy formulářů zpočátku připadat značně těžkopádný. Pokud však máte dostatečné zkušenosti s programovou změnou formulářů, přidání jednoho prvku nezabere více než 3–5 minut. Čas strávený s následnými aktualizacemi standardní konfigurace se mnohonásobně vyplatí.

Příklad: Na hlavním formuláři dokumentu „Zálohová platba“ přidejte detail „Projekt (AB)“.

Vývojářské akce: Do obslužného programu formuláře „When CreatedOnServer“ přidejte proceduru „EditFormProgrammatically()“. V tomto postupu přidejte požadovaný prvek k prvkům formuláře.

Je možné vytvořit samostatný modul, který bude obsahovat všechny potřebné postupy a funkce pro změnu standardních formulářů.

V typických konfiguracích založených na BSP 2 již existuje speciální funkce pro tyto účely:

V proceduře „When CreateOnServer“ obecného modulu „Modification of Configuration Overridden“ můžete zavolat svůj vlastní handler.

Kde podle názvu formuláře můžete zavolat potřebný postup s programovou úpravou formuláře.

Pokud plánujete přidat do formuláře velké množství prvků nebo tabulkové díly, je možné i ruční přetváření. V tomto případě se doporučuje vytvořit na formuláři samostatnou záložku a umístit na ni všechny potřebné prvky. To výrazně usnadní budoucí aktualizace formulářů.

8.2 Úprava tvarů objektů přidaných v rámci projektu

Formy objektů přidaných v rámci projektu (tedy ty s předponou v názvu) se upravují obvyklým způsobem.

9. Zásady práce s rolemi

Obecné role by měly být vždy ponechány beze změny (pokud je to možné). To je nezbytné pro usnadnění aktualizace změněné konfigurace z nových verzí, protože porovnávání a obnova rolí je složitý a pečlivý proces.

Měla by být přiřazena práva k objektům přidaným do konfigurace v novém role vytvořené pro tento účel.

Měla by být implementována omezení přístupu k datům povolená typickými rolemi programově, dokud je to možné. A pouze v případě, že by byl takový zákaz programově velmi obtížně realizovatelný (nebo by takové řešení bylo nespolehlivé), je přípustné upravovat standardní role. Změny typických rolí by měly být nezbytné a zdokumentované minimálně. Pokud například potřebujete změnit text omezení přístupu v roli (RLS), měli byste podle toho okomentovat veškerý ukázkový kód a poté přidat kód s nezbytnými změnami.

10. Externí hlášení a zpracování

Většinu vylepšení v systému lze provést pomocí mechanismu Další zprávy a zpracování.

V konfiguracích založených na BSP 2 (ERP, UT 11, BP 3.0, ZUP 3.0 atd.) je tento mechanismus výrazně rozšířen. S jeho pomocí, beze změny konfigurace, je možné vytvářet externí reporty a zpracování (s umístěním spouštěcího příkazu do příkazového rozhraní a možností konfigurovat přístup pro různé uživatele), zpracování vyplnění dokumentu, zpracování vytvoření dokumentu na základě dodatečných tištěných formulářů atd.

Pomohl vám tento článek?

1C 8.2 a 8.3 má velmi významný konkurenční výhodu— schopnost upravovat standardní konfigurace 1C a vyvíjet vlastní řešení založená na platformě. Toho je dosaženo díky vestavěnému vývojovému prostředí, systém má dokonce vlastní .

Společnost 1C, která se obává o své zákazníky, se snaží vyrábět řešení, která budou nejlépe vyhovovat všem organizacím na trhu. Každá společnost, stejně jako člověk, je jedinečná. Jedná se o jakési „vyladění“ konfigurace 1C tak, aby vyhovovala vašim potřebám.

Jaké nové věci se obvykle dělají v 1C?

Úpravy se zpravidla týkají rozhraní části programu. Existují však také vážné úpravy konfigurací - zavedení nových subsystémů, nových algoritmů.

Příklady změn v 1C 8.3:

  • Nastavení uživatelských práv a výchozí hodnoty. Flexibilní konfigurace práv - velmi důležitý bod. Uživatelé a jejich práva jsou něčím, bez čeho nelze pracovat v žádném víceuživatelském systému.
  • Změna a tvorba nového tištěné formuláře. Tištěná forma je papírový ekvivalent dokumentu v 1C. Je možné jak zpřesňovat stávající, tak přidávat nové. Úpravu tištěných formulářů lze provést bez změny konfigurace.
  • Vytváření nových a úprava stávajících zprávy. Zpráva je konečným produktem jakékoli analýzy informační systém, včetně 1C Enterprise. Sestavy v programu lze upravovat bez změny konfigurace.
  • . Technicky nezkušený klient zpravidla nemůže vždy napsat kompetentní technické specifikace pro programátory. Přitom samotný úkol může být dokončen buď interně, nebo společnostmi třetích stran.
  • Přidání do konfigurace novou funkcionalitu. 1C je univerzální systém a nemůže zohledňovat přání každého klienta. Kompetentní specialisté jsou schopni výrazně rozšířit funkčnost programu a integrovat jej „bez problémů“.
  • Optimalizace výkonu 1C. Systém 1C Enterprise je z hlediska výkonu jedním z lídrů ve svém segmentu. Nicméně získat maximální rychlost Aby systém fungoval, jsou nutné některé změny, které jsou přizpůsobeny IT infrastruktuře klienta.

Cena za hodinu práce specialisty 1C

Náklady na práci na úpravě standardních konfigurací 1C se obvykle odhadují v člověkohodinách.

Všichni ostatní, vítejte u kočky.

Pravidla a techniky pro finalizaci standardních konfigurací 1C pro usnadnění jejich další podpory a aktualizace

Takže, když uděláme projekt (slovem „My“ myslím všechny lidi, kteří se podílejí na automatizaci podnikových procesů), doufáme, že pak plynule přejde do podpory. Zpravidla, pokud se vše udělá dobře a zákazník je spokojený, tak se to stane.

Podpora se vyznačuje velmi specifickým souborem úkolů – mohou to být konzultační úkoly typu „odkud se tato čísla vzala“ nebo opravit nějaké nepochopitelné chyby atd. Ale protože téměř všechny projekty zahrnují přizpůsobení nějakého standardního řešení potřebám zákazníka, konfigurace s podporou musí být pravidelně aktualizována na nová vydání:

  • Pokud se budete řídit některými pravidly vývoje, poté, co jste ve fázi projektu vynaložili velmi málo práce, můžete v budoucnu ušetřit na údržbě a aktualizaci konfigurací.
  • A naopak, pokud ve fázi projektu došlo k nějakým chybám, spěchu nebo nesprávnému formátování kódu, později to může mít za následek skutečné peklo podpory a aktualizací.

Musel někdy někdo aktualizovat konfiguraci, která byla přepsána bez jakýchkoliv identifikačních značek? Chápete, jaká je bolest porovnávat starou konfiguraci dodavatele s novou konfigurací, ručně analyzovat každý případ „dvakrát změněno“ při porovnávání se současnou konfigurací atd. To vše je dost problematické.

9 jednoduchých pravidel pro navrhování úprav ve standardních konfiguracích

1. Koncept minimalizace „zničení“ standardní konfigurace

První není ani pravidlem, jde o jakýsi koncept pro minimalizaci „zničení“ standardní konfigurace.

Jeho podstatou je, že byste měli vždy volit takové metody řešení problémů, které v budoucnu poskytnou snazší aktualizaci konfigurace, i když je takové řešení poněkud obtížnější na implementaci. Je jasné, že by to mělo být provedeno bez fanatismu, v rozumných mezích, ale vývojář si musí vždy pamatovat, že konfigurace zůstává pod podporou, a analyzovat, jak moc jeho kód zkomplikuje aktualizaci konfigurace v budoucnu, a vybrat nejvhodnější řešení.

2. Komentování změn kódu

Druhé pravidlo je, že l jakákoli změna kódu musí být okomentována.

V naší společnosti používáme následující schéma:

  • Na začátku změny je úvodní komentář(začíná znaky //++ )
  • Na konci - závěrečný komentář(začíná znaky //-- )
  • A ty změny, které vývojář provedl, jsou uprostřed.

Toto je povinné pravidlo pro jakékoli změny.

Úvodní a závěrečné komentáře mají značku změny. Obsahuje následující komponenty:

  • Předpona projektu- standardně používáme FTO
  • Název domény vývojáře. Tvoří se velmi pohodlně: společnost je velká, distribuovaná, a pokud vývojáře neznáte, ale potřebujete se ho o něm na něco zeptat, můžete si vzít jeho přezdívku z tohoto tagu, dát @fto.com.ru a pošlete mu dopis, abyste ho mohli kontaktovat.
  • Následuje další datum úpravy. Dojde-li ke změnám v rámci více úkolů, mohou být tyto svazky komentářů vnořeny do sebe a není vždy jasné, do kterého úvodního bloku tento závěrečný komentář patří, proto se zaměřujeme na datum. Datum navíc okamžitě ukazuje, kdy byla úprava provedena: před třemi lety, před šesti měsíci nebo včera.
  • Pak přijde číslo úkolu, který umístěn pouze v úvodním komentáři. Proč jen tam? Aby se při globálním hledání podle čísla úkolu do výběru zahrnul pouze začátek změn kódu, ze kterého se pak můžete dívat dolů, jinak budou dvojky. Například při odesílání úkolu ke kontrole kódu je velmi pohodlné vyhledávat konkrétně podle tagu.

Příklady

Takhle to vypadá vložte kód:

Takhle to vypadá odstranění kódu- kód neodstraňujeme úplně, kód komentujeme. Díky tomu můžete vždy vidět, co bylo okomentováno, a pokud se něco stane, můžete se rychle vrátit.

Takhle to vypadá změna kódu: Nejprve je zakomentován veškerý kód dodavatele a poté je přidán váš vlastní kód.

Funguje samostatné pravidlo přidat procedury, funkce a globální proměnné modulu. V tomto případě závěrečný komentář je umístěn na stejném řádku jako klíčové slovo Konec procedury. Proč se to udělalo? Aby bylo snadné přenášet modifikace pomocí „procedurálního srovnání“.

Tady na obrázku to vidíte pomocí "procedurálního srovnání" můžete tento postup při slučování jednoduše zvýraznit a bude kompletně přenesen (spolu se značkami). Nebo naopak můžete zrušit zaškrtnutí políčka vedle něj, abyste jej nepřenesli.

A pokud je závěrečný komentář na dalším řádku, pak bude přiřazen do dalšího řízení a nebude možné jej jednoduše převést bez dalších nákladů.

3. Přidání objektů nejvyšší úrovně

Dalším pravidlem je přidání objektů nejvyšší úrovně (adresáře, dokumenty, registry atd.) do konfigurace.

Toto pravidlo je ono názvy objektů musí začínat prefixem. Proč?

  • Za prvé vizuálně zvýrazní přidaný prvek v konfiguraci a v kódu hned je jasné, že se jedná o náš přidaný objekt.
  • Za druhé, je dosaženo jedinečnosti jména, protože poskytovatel může přidat svůj vlastní objekt se stejným názvem. A pokud použijeme vlastní předponu, zaručí to, že naše jméno bude jedinečné.

Synonyma objektů musí začínat prefixem v závorkách. To nám umožňuje zvýraznit náš přidaný objekt v rozhraní.

Samozřejmě je to velmi kontroverzní pravidlo a jeho použití je nutné dohodnout se zákazníkem. Naši klienti byli s tímto programem spokojeni, a tak se u nás ujal a stal se součástí pravidel. Zde je ale na vás a na klientovi, abyste se rozhodli, zda to udělat nebo ne.

No a poslední pravidlo: komentáře ke všem přidaným objektům musí obsahovat speciální štítek se jménem vývojáře a číslem úkolu. Tento štítek je podobný úvodnímu komentáři z modulu, pouze bez speciálních znaků - s jeho pomocí vždy pochopím, kdo, kdy a pro jaký úkol tento objekt přidal.

Takže abych to shrnul:

  • Jména jsou uvedena s předponou,
  • Synonyma - s předponou v závorce
  • A komentář musí obsahovat speciální značku.

4. Přidání podřízených objektů

Přidáním dílčích objektů mám na mysli přidávání rekvizit, rozvržení, formulářů atd. do konfiguračních objektů.

Zde musíme okamžitě zvýraznit dvě situace, kdy přidáme podřízený objekt:

  • V typickém konfiguračním objektu
  • Nebo k nějakému objektu, který byl přidán dříve v rámci projektu.

Zvažme každou z těchto situací zvlášť.

Chcete-li přidat podřízené objekty ke standardním konfiguračním objektům Platí následující pravidla.

  • Jména musí začínat stejnou předponou. Díky tomu dosahujeme jedinečnosti názvu a vizuálně je také vždy jasné, že se jedná o náš objekt.

  • Synonymum se vyplňuje bez předpony, protože zde již není potřeba zvýrazňovat naše předměty, naše detaily.

  • A nakonec, komentář obsahuje také speciální značku, aby bylo jasné kdo, kdy a proč.

Pojďme si tedy shrnout, jak funguje přidávání podřízených objektů k typickým konfiguračním objektům:

  • Jména jsou uvedena s předponou,
  • Synonyma podle obecných pravidel
  • A komentáře obsahují speciální označení.

A pokud přidáme podřízené objekty k těm objektům, které byly dříve přidány v rámci projektu a již obsahují předponu ve svém názvu, pak:

  • Jejich jména nesmí obsahovat předponu, protože už je jasné, že objekt je již unikátní, a není potřeba jej nijak zvlášť zvýrazňovat.

  • Synonyma pro takové podřízené objekty jsou také uvedeny bez předpony, protože není potřeba žádný speciální výběr.

  • A komentář obsahuje speciální popisek pouze v případě, že byl tento podřízený objekt přidán jako součást jiného úkolu. Protože pokud můj úkol říká, že musím přidat dokument, který má takové a takové podrobnosti, nemusím dávat takový štítek pro každý detail. Ale pokud je úkol úplně jiný, dávám si záležet, aby bylo jasné, proč jsem to udělal.

Nyní si shrňme, jak se podřízené objekty přidávají k objektům přidaným v rámci projektu:

  • Jména bez předpony.
  • Synonyma bez předpony.
  • A komentáře by měly obsahovat speciální štítek pouze tehdy, když jsou přidány jako součást jiného úkolu.

Pokud toto pravidlo pro oba případy zkombinujeme a „rozdělíme na kousky“, dostaneme následující tabulku:

  • Nové objekty:
    • Název začíná předponou.
    • Synonyma – s předponou v závorce.
    • Komentář obsahuje štítek.
  • Podřízené objekty, které přidáváme do obecných objektů:
    • Jména začínají předponou,
    • Synonymum podle obecných pravidel
    • Vložte štítek do komentáře.
  • A pokud přidáme podřízené objekty k objektům přidaným v rámci projektu, pak
    • Neexistují pro ně žádná zvláštní pravidla,
    • Pokud je ale úkol jiný, pak stejným způsobem vložíme tag do komentáře.

5. Přidání předdefinovaných prvků

Dalším pravidlem je přidávání předdefinovaných prvků.

Zde lze přesně stejným způsobem rozlišit dvě situace:

  • Když přidáme předdefinovaný prvek do typického konfiguračního objektu (do referenční knihy, do plánu typů charakteristik)
  • A když přidáme předdefinovaný prvek k objektu přidanému v rámci projektu.

Pokud do obecného konfiguračního objektu přidáme předdefinovaný prvek,

  • Jeho název podobný musí začínat předponou. Garantujeme tak jedinečnost jeho názvu a budeme schopni okamžitě vizuálně identifikovat náš přidaný prvek.
  • Kód a jméno se vytvoří podle obecných pravidel,
  • Ale označení tady, bohužel, kam to dát. Proto nebude možné tento přidaný předdefinovaný prvek najít pomocí globálního hledání úloh.

A pokud k objektům přidaným v rámci projektu přidáme předdefinované prvky, Že

  • Jeho jméno nebude obsahovat předponu, protože to není potřeba nějak zvýrazňovat.

Pokud tedy nakreslíme analogii s předchozí tabulkou, pak:

  • Předdefinované prvky pro obecné objekty jsou přidány s předponou,
  • A vše ostatní - podle obecných pravidel není třeba přidávat žádné speciální předpony.

6. Použití společných modulů a jejich striktní struktura

Další pravidlo se týká použití společných modulů a organizace jejich přísné struktury.

Za prvé, pro různé opakovaně používané procedury, funkce, obslužné programy předplatného a rutinní úlohy byste měli přidat své vlastní moduly a standardní moduly ponechat beze změny. A pokud chce vývojář umístit nějaký druh exportní procedury do standardního modulu, pak to není třeba dělat, musíte si vytvořit svůj vlastní modul.

Za druhé, mějte na paměti, že společné moduly se přidávají podle pravidel pro přidávání objektů nejvyšší úrovně(jméno a synonymum s prefixem, tag v komentáři atd.)

Třetí, názvy modulů musí být podobné odpovídajícím standardním modulům.

Není třeba znovu vymýšlet kolo: nazýváme jej stejným způsobem, jak je obvyklé ve standardních konfiguracích - pro každou funkcionalitu vlastní modul, odpovídající obecně přijímaným označením v 1C. Například:

  • FTO_General Purpose Client,
  • FTO_General Purpose Server,
  • FTO_General Purpose Global,
  • FTO_RoutineTasksServer
  • Atd.

A nějaký velké individuální úkoly můžete (a pravděpodobně byste měli) vkládat do samostatných společných modulů.


7. Využití předplatných a jejich striktní struktura

Dalším pravidlem je používání předplatných a jejich přísná struktura. Jaká je její podstata?

Předplatné by se mělo používat ke zpracování různých událostí spojených s obecnými objekty, jako:

  • Před nahráváním
  • Při nahrávání
  • Atd.

  • Samozřejmě můžete vzít upravit standardní objektový modul, vložením vašeho kódu do příslušné procedury. Ale toto - špatná cesta.
  • Lepší Místo toho přidat odběr pro zpracování této události.

Předplatné se přidává podle následujících dohodnutých pravidel:

  1. Pro všechny události stejného typu v systému je přidáno pouze jedno předplatné. Pokud například potřebuji použít svůj vlastní algoritmus pro různé adresáře v události „Před zápisem adresáře“, pak pro všechny tyto adresáře použiji pouze jedno přidané předplatné „Před zápisem adresáře“.
  2. Zdroj vybere všechny objekty v této třídě(například všechny adresáře)
  3. Pro přidané předplatné je vytvořen samostatný modul, který se nazývá úplně stejně(jen pro pohodlí).
  4. V obslužné rutině hlavní události je definována podmínka, která analyzuje typ objektu(typ adresáře).
  5. A už V závislosti na typu objektu se provádějí určité akce.

Mohu vám to ukázat na příkladu. Předpokládejme, že existuje takový úkol: při zaúčtování dokumentu „Předběžná zpráva“ proveďte záznamy do dříve přidaného registru akumulace.

Nejprve přidáme obecný modul FTO_DocumentsProcessingProcessing podle všech pravidel.

  • Jako zdroj specifikujeme DocumentObject (všechny dokumenty);
  • Náš modul přidaný výše se používá jako handler.

A již v modulu, v samotném handleru, určujeme, jaký dokument nám přišel a podle jeho typu voláme tu či onu proceduru.

Existuje jedno předplatné, ale akce se mohou lišit. T Můžete také ovládat pořadí, ve kterém jsou procedury volány.

V důsledku toho je postup vytvoření předplatného následující:

  • Jedno předplatné,
  • Jeden společný modul
  • A nic dalšího není potřeba: modul dokumentu zůstává nezměněn - již se nebude zobrazovat v těch „dvakrát změněných“.


8. Editace formulářů

Dalším pravidlem je úprava formulářů.

Zde zdůrazníme dva body, dvě situace:

  • Když upravujeme standardní formuláře;
  • A když upravíme formuláře přidané v rámci projektu.

První situací je editace standardní formuláře, tvary typických předmětů. Toto je nejkontroverznější bod pravidel. Kdysi, v dobách konvenčních formulářů, kdy se projekty dělaly hlavně na SCP, jsme hodně diskutovali o tom, co dělat s formuláři. Jaké byly možnosti?

  • Přímá editace běžných formulářů je, že jen ručně změním tvar. S touto možností musím pokaždé, když dodavatel provede změny tohoto formuláře, přenést všechny své změny znovu. Špatná cesta.
  • Další způsob je vytvoření kopie formuláře. To je, když vytvořím kopii standardního formuláře, označím jej jako hlavní a provedu v něm své změny. Ale opět, pokud dodavatel změní tento formulář, musím jejich změny přenést do své verze ručně. Není to nejlepší způsob.
  • Další možností je vytvoření samostatné karty. Na formuláři vytvoříme samostatnou záložku a umístíme na ni naše prvky. Je jasné, že tato metoda není flexibilní, protože někdy je potřeba váš prvek vložit někam na konkrétní místo ve formuláři. Nebo potřebujete změnit vlastnosti standardních prvků, přiřadit jim nový handler atd. Proto toto ne flexibilním způsobem- taky to moc nejde.
  • Jako výsledek zvolili jsme metodu zcela programové úpravy formulářů. Pro nové vývojáře, kteří se s touto metodou zpočátku nesetkali, je velmi obtížné programově upravit formulář. Ale ve skutečnosti - ne. Z vlastní zkušenosti řeknu, že se v tom prostě musíte zlepšit. Navíc máme dlouho napsané moduly s exportními procedurami pro programově měnící se formuláře a to vše jde celkem jednoduše. Když se objevily spravované formuláře, zcela jsme přenesli tuto praxi programové změny formulářů do spravovaných formulářů. Navíc úpravy řízená forma Programování se stalo obecně snadným - nelze jej srovnávat s konvenčními formami.

Ukážu vám to na příkladu. V handleru OnCreateOnServer přidám volání své procedury EditFormProgrammatically, kde programově přidám prvky do formuláře.

V konfiguracích založených na BSP 2(např. ERP, Účetnictví atd.). Event handlerForm.WhenCreatedOnServer(), která mimo jiné přichází v taky do přepsaného modulu.

A tak v přepsaném modulu můžete přidat svůj vlastní kód- například do procedury WhenCreatingOnServer(). Zde si nadefinuji název formuláře a podle něj zavolám tu či onu proceduru, kde programově přidávám prvky.

Zdá se, že je to obtížné, že toto schéma je těžkopádné, ale ve skutečnosti, pokud jsou všechny projekty provedeny podle těchto pravidel, pak vývojář, když obdrží úkol, okamžitě ví, kde hledat, kam co přidat. Takže si myslím, že je to velmi pohodlné.

Kromě toho jsou v konfiguracích založených na BSP 2 předefinovány další obslužné rutiny formulářů – například When ReadingOnServer(), BeforeWritingOnServer() atd. A v těchto handlerech můžete také aktivně využívat redefinici volaných procedur. Modul předefinovaný dodavatelem se navíc teoreticky nemění a můžete si tam bez obav z konfliktů napsat vlastní kód.

Pokud upravujeme formulář přidaný jako součást projektu, pak nemusíme dělat nic zvláštního, upravujeme ho obvyklým způsobem, ručně.

9. Zásady práce s rolemi

A posledním pravidlem jsou zásady práce s rolemi.

Principy práce s rolemi jsou následující:

  1. Pokud je to možné, pak typické role by měly být vždy ponechány bez jména. Je třeba si dobře rozmyslet, zda je skutečně nutné typickou roli měnit, nebo zda můžete něco udělat jinak.
  2. Přidělujeme práva k přidaným konfiguračním objektům v nových, speciálně vytvořených rolích. Když tedy do konfigurace přidám sestavu a neexistuje pro ni žádná vhodná role, kterou jsme dříve přidali, vytvořím samostatnou roli. A pak se tato role přidá k požadovaným profilům. Typické role se ale nemění.
  3. A pokud dojde ke změnámRLS, pak jsou formátovány podle pravidel pro úpravu modulů.

Pokud například potřebuji změnit RLS, vložím úvodní komentář, okomentuji starý kód, poté přidám svůj vlastní a vložím závěrečný komentář. Vždy je jasné: kdo, proč (v rámci jakého úkolu) a kdy jsem se změnil.

Takže jsem vyjmenoval všech devět jednoduchá pravidla registrace úprav.

Další předměty a techniky pro usnadnění života

Nakonec se budu věnovat některým objektům a technikám, které mohou vývojářům usnadnit život.

1. Vlastní identifikace testovacích databází

První technikou je vlastní identifikace testovacích databází.

Pointa je:

  • existuje nějaká konstanta, která ukládá adresu pracovní produktivní databáze.
  • Po spuštění systému je tato adresa zkontrolována: odpovídá pracovní základní adrese nebo neodpovídá.
  • A pokud se to neshoduje(základna nefunguje), pak Probíhá výměna systémové hlavičky.

Snímek obrazovky ukazuje, jak to vypadá. To je zvláště užitečné, když vývojáři (nebo konzultanti) mají otevřeno mnoho databází (pracovní, testovací, vývojové atd.) a mohou se omylem zmýlit a změnit data ve fungující databázi. A pokud se název změní, tak „automaticky“ – podívejte se do levého horního rohu, o jakou databázi se jedná – ano, test, můžete to změnit.

Tímto způsobem činíme změny dat v infobázích bezpečnější.

Kromě, Kontrolu hodnoty této konstanty je také užitečné využít při provádění některých rutinních úloh. A to:

  • výměny dat,
  • uživatelská upozornění,
  • nějaké maily
  • těžké regulační úkoly.
  • Atd.

Když vývojář vytvoří takový rutinní úkol, musí zkontrolovat, zda se jedná o funkční základnu nebo ne. Je jasné, že teoreticky na všech testovacích databázích by měly být rutinní úlohy zakázány v konzole clusteru. Ale vždy je tam lidský faktor, když někdo tvořil nová základna, načetl do něj čerstvá data, něco změnil a v důsledku toho došlo ke kritické výměně s fungujícími databázemi. A pak zúčtování – proč se to stalo? Proto my před kritickým rutinní úkoly Vždy kontrolujeme, zda se jedná o funkční databázi či nikoliv.

V konfiguracích založených na BSP 2 existuje podobný mechanismus: pokud umístění informační základna změny, pak je položena otázka - je to kopie databáze nebo byla databáze přesunuta. V zásadě může být tento mechanismus dostačující, ale opět může zasahovat lidský faktor, někdo nepochopí, co se děje a stiskne špatné tlačítko. Proto, podle mě je spolehlivější konstanta.

2. Zpracování inicializace

Dalším trikem je inicializační zpracování.

  • Jedná se o zpracování přidané do konfigurace, která ve svém kódu obsahuje aktuální verzi.
  • Zároveň je do konfigurace přidána i nějaká konstanta, která ukládá aktuální verzi inicializačního zpracování.
  • Po spuštění systému se provede kontrola,
  • A pokud se verze změnila, provedou se potřebné handlery a nastaví se nová hodnota konstanty.

Proč je to nutné? Při přidávání nové funkce do konfigurace je často nutné provést některé akce v samotné databázi: například jste přidali předdefinovaný prvek adresáře a nyní musíte vyplnit jeho podrobnosti. Na projektu může být mnoho databází a ruční vyplňování těchto dat je samozřejmě špatné. Správnější:

  • Zvětšit verzi zpracování inicializace;
  • Popište v kódu pořadí programového plnění dat;
  • A po tom nová verze zpracování automaticky přes úložiště přejde do všech potřebných databází, spustí se tam a provede všechny potřebné úkony.

V diagramu toto provozní postup zobrazeno takto:

  • Start systému
  • Porovnání konstantní verze s verzí zpracování.
  • Pokud se to neshoduje, se provádějí postupně vše potřebné manipulátory,
  • Nastaví novou hodnotu pro konstantu.

Výsledkem je, že všude, ve všech databázích jsou data aktualizována.

3. Adresář předdefinovaných hodnot

Dalším trikem je odkaz na předem definované hodnoty.

Často je potřeba přistupovat k existujícím prvkům adresáře z kódu, který není předdefinován. Je jasné, že je lepší vytvořit předdefinovaný prvek, ale stává se, že prvek nelze předdefinovat, ale přesto k němu bude přistupovat.

Jaké možnosti implementace existují?

  • Odkazujte na prvek podle názvu. Je jasné, že se změnil název - kód přestal fungovat. Špatně.
  • Kontakt přes kód. Trochu lepší, ale kód se může také změnit. Není moc dobrá.
  • Kontakt pomocí interního identifikátoru. Pak při přenosu tento kód také nebude fungovat. Obecně platí, že všechny tyto tři případy nebudou fungovat, pokud přeneseme úpravu z jedné databáze do jiné databáze. Není moc dobrá.
  • Nabízeno vytvořit adresář s předdefinovanými hodnotami.

Tento adresář obsahuje pouze jeden atribut typu DirectoryLink(odkaz na všechny příručky).

Pokud potřebuji odkazovat na nějaký prvek jako součást úkolu, přidám do této referenční knihy předdefinovaný prvek (například Counterparty_Agroimpulse)

A pak buď v kódu inicializačního zpracování nebo ručně, doplním hodnotu tohoto adresáře protistranou, kterou potřebuji.

V souladu s tím po tomto Tuto protistranu mohu kontaktovat prostřednictvím adresáře předdefinovaných hodnot. Díky tomu je dosaženo následujícího:

  • Při přenosu úprav mezi různé základny všechny moje kód funguje bez dalších úprav.
  • Navíc je možné, že dnes je touto protistranou Agroimpulse a zítra nějaká jiná organizace, ale nemusím v konfiguraci nic upravovat, jen jdu a změním její hodnotu v adresáři předdefinovaných hodnot.

4. Zobrazte dočasné tabulky v ladicím programu

Posledním trikem je zobrazení dočasných tabulek v debuggeru.

  • Při ladění složitých dotazů pomocí dočasných tabulek musí mít možnost prohlížet obsah tyto dočasné stoly.
  • Pro tyto účely Umět použijte speciální funkci pro zobrazení dočasných tabulek.
  • Tato funkce komfortní místo v globálním modulu.

  • A název Nějak krátké, například VT()

V tomto případě:

  • já Nastavil jsem bod zlomu v místě, kde mám žádost.
  • V okně „Vypočítat výraz“ napíšu VT (Dotaz);
  • Kliknu na „Vypočítat“ a Získávám strukturu dočasných tabulek dotazů abyste viděli, jaká data tam jsou.

To je velmi pohodlná funkce, používáme ji neustále. Zejména při kalkulaci nákladů, nebo v konfiguracích jako je ZUP. Abych byl upřímný, nechápu, jak ostatní bez ní žijí.

V nejnovější verzi platformy se objevila vestavěný nástroj což vám umožňuje prohlížet dočasné tabulky, ale myslím si to ne příliš pohodlné. Použití vlastní funkce je mnohem lepší.

Závěr

Děkuji všem. Mám malý web, na tomto webu jsou všechna tato pravidla a další podrobně rozvržena - vstupte, přečtěte si, napište mi na e-mail nebo na Skype.

Toto téma je pro mě zajímavé, jsem připraven o něm diskutovat. Je pro mě opravdu důležité, aby vám také vše vyšlo.

Jakékoli, dokonce malá organizace má vlastní sadu obchodních procesů. Pracovat efektivně a přijímat nejvyšší zisk velké obchodní procesy je třeba automatizovat. Programy 1C odvádějí s touto funkcí vynikající práci. Ale bohužel žádné ideální programy neexistují, stejně jako každý člověk má své vlastní představy o dokonalosti. Programátor 1C vám může pomoci vylepšit váš program. Po úpravě standardního 1C získáte program, který plně vyhovuje vašim představám a potřebám.

Revize 1C- sada akcí pro konfiguraci a modernizaci programů 1C tak, aby vyhovovaly potřebám vašeho podniku.

Jak vylepšujeme programy 1C

Pro dosažení ideálního výsledku, kdy klient obdrží přesně to, co zamýšlel při finalizaci programů 1C, nabízíme následující pracovní schéma:

  1. klient hlásí informace o nainstalovaném ;
  2. klient seznámí našeho specialistu se základními principy práce jeho organizace, sdělí podstatu problému, popíše, co přesně by chtěl zlepšit;
  3. klientovi je přidělen programátor 1C, který bude s klientem spolupracovat po celou dobu spolupráce s naší společností a bude si vědom všech vlastností účetnictví klienta. Osobní programátor 1C bude plně odpovědný za výkon vylepšení, která implementoval;
  4. jsou vypracovány technické specifikace. Na základě obdržených informací naši programátoři 1C vyvodí potřebné závěry a nabídnou možnosti řešení problému buď úpravami, nebo provedením úprav v 1C;
  5. časové a finanční náklady na dokončení 1C jsou dohodnuty;
  6. je realizována práce dohodnutá s klientem;
  7. Výsledky práce jsou testovány a předány klientovi.

Nejběžnější úpravy 1C

Níže uvádíme zvláště oblíbená vylepšení v programech 1C:

  • Tvorba adresářů a detailů. Stvoření další místa ukládání informací, jako jsou čísla automobilů
  • Zdokonalování nebo vývoj nových tiskových forem. Změna vzhledúčtenky, faktury a další tištěné formy dokumentů dle požadavků vaší organizace.
  • Vytvářejte nové nebo upravujte stávající přehledy. Vytváření dalších nebo úprava stávajících sestav pro účetní, manažery nebo ředitele společností.
  • Nastavení přístupových práv. Omezení nebo rozšíření přístupu uživatelů k informacím v databázi.
  • Vývoj léčebných postupů. Vytvoření zpracování pro zjednodušení systémů pro vkládání informací, analýza podnikových aktivit, automaticky prováděné funkce, například tisk balíku dokumentů nebo stahování informací ze souboru Excel (*.xls).
  • Nastavení výměny 1C. Import/export dat z jednoho programu 1C do druhého.
  • Konzultace s uživateli 1C. Vysvětlení nebo školení uživatelů pro práci s implementovanými vylepšeními.
  • Aktualizace změněných konfigurací. Aktualizujeme konfigurace změněné našimi i externími programátory 1C.

Výhody svěření vylepšení v 1C nám

Existuje několik důvodů, proč je objednávání úprav u naší společnosti výhodné:

  • Vysoká kvalita. Naši programátoři 1C jsou vysoce kvalifikovaní specialisté, což potvrzují příslušné certifikáty 1C.
  • Nízké náklady. Naše společnost je malá, ale rychle rostoucí, eliminujeme prostředníky mezi zákazníkem a programátorem, díky tomu se nám daří udržovat náklady na služby 1C na nízké úrovni, od 1000 rublů. za hodinu odborné práce.
  • Rychlé dokončení práce. Pro naši společnost není výhodné zdržovat dokončení vašeho úkolu. Výsledek své práce tedy zaručeně obdržíte nejpozději do tří pracovních dnů. Pokud je úkol malý, je pravděpodobné, že budete moci získat potřebnou úpravu v 1C v den, kdy jej kontaktujete.
  • 100% záruka na provedení úpravy. Naše společnost garantuje funkčnost vylepšení provedených našimi zaměstnanci ve vašem programu. Do roka po jeho realizaci nám můžete sdělit, zda najdete skryté vady a my je co nejdříve zcela zdarma opravíme.
  • Navzdory tomu, že se geograficky nacházíme v Petrohrad, Můžeme pro vás na dálku provést jakoukoli práci, ať jste kdekoli na světě.