Udoskonalenie przedsiębiorstwa 1c. Koncepcja minimalizacji „zniszczenia” typowej konfiguracji

Cóż, wszyscy inni, witamy w kocie.

Zasady i techniki finalizowania typowych konfiguracji 1C w celu ułatwienia ich dalszej obsługi i aktualizacji

Tak więc, kiedy robimy jakiś projekt (przez słowo „my” mam na myśli wszystkie osoby, które zajmują się automatyzacją procesów biznesowych), mamy nadzieję, że wtedy płynnie przejdzie on do wsparcia. Z reguły, jeśli wszystko jest zrobione dobrze, a klient jest zadowolony, tak się dzieje.

Wsparcie charakteryzuje się bardzo specyficznym zestawem zadań - mogą to być zadania do konsultacji z kategorii „skąd się wzięły takie liczby” lub poprawienia jakichś niezrozumiałych błędów itp. Ponieważ jednak prawie wszystkie projekty polegają na dostosowaniu jakiegoś typowego rozwiązania do potrzeb klienta, konfiguracja wraz z obsługą musi być okresowo aktualizowana o nowe wersje:

• Jeśli zastosujesz się do pewnych zasad programowania, to poświęcając niewielki wysiłek na etapie projektu, w przyszłości możesz zaoszczędzić na wsparciu i aktualizowaniu konfiguracji.
• I odwrotnie, jeśli na etapie projektu były jakieś błędy, pośpiech, niepoprawny projekt kodu, to później może to zaowocować prawdziwym piekłem wsparcia i aktualizacji.

Czy ktoś kiedykolwiek musiał aktualizować konfigurację, która została przepisana bez żadnych oznaczeń? Czy widzisz, jak bolesne jest porównywanie starej konfiguracji dostawcy z nową konfiguracją, ręczne analizowanie każdego przypadku „podwójnej zmiany” w porównaniu z bieżącą konfiguracją i tak dalej. To wszystko jest dość problematyczne.

9 prostych zasad projektowania modyfikacji w typowych konfiguracjach

1. Pojęcie minimalizacji „zniszczenia” typowej konfiguracji

Pierwsza nie jest nawet regułą, to pewna koncepcja zminimalizowania „zniszczenia” typowej konfiguracji.

Jego istotą jest to, że zawsze należy wybierać takie metody rozwiązywania problemów, które w przyszłości zapewnią łatwiejszą aktualizację konfiguracji, nawet jeśli takie rozwiązanie jest nieco trudniejsze do wdrożenia. Oczywiste jest, że należy to zrobić bez fanatyzmu, w rozsądnych ramach, ale programista powinien zawsze pamiętać, że konfiguracja pozostaje na wsparciu i analizować, jak bardzo jego kod skomplikuje aktualizację konfiguracji w przyszłości, wybierając najbardziej odpowiednie rozwiązanie.

2. Komentowanie zmian w kodzie

Druga zasada jest taka, że \u200b\u200bl wszelkie zmiany w kodzie wymagają komentarza.

W naszej firmie stosujemy następujący schemat:

• Na początku zmiany jest komentarz otwierający (zaczyna się od znaków //++ )
• Na końcu - komentarz zamykający (zaczyna się od znaków //-- )
• I te zmiany wprowadzone przez dewelopera są w trakcie.

Jest to obowiązkowa zasada dotycząca każdej zmiany.

Komentarze otwierające i zamykające mają znak zmiany... Zawiera następujące elementy składniki:

• Prefiks projektu - domyślnie używamy FTO
• Nazwa domeny dewelopera... Tworzy się bardzo wygodnie: firma jest duża, rozproszona, a jeśli nie znasz dewelopera, ale musisz go o coś zapytać, możesz wziąć jego pseudonim z tej wytwórni, wstaw @ fto.com.ru na prawo i wyślij mu list, aby się z nim skontaktować.
• Dalej idzie zmień datę... Gdy zmiany zachodzą w ramach kilku zadań, te zestawy komentarzy mogą być zagnieżdżone w sobie nawzajem i nie zawsze jest jasne, do którego bloku otwierającego należy ten komentarz zamykający, dlatego skupiamy się na dacie. Ponadto data od razu pokazuje, kiedy dokonano modyfikacji: trzy lata temu, sześć miesięcy temu lub wczoraj.
• Potem nadchodzi numer zadania, który umieszczony tylko w komentarzu otwierającym... Dlaczego tylko tam? Dzięki temu podczas globalnego wyszukiwania według numeru zadania tylko początek zmian kodu zostanie uwzględniony w wyborze, z którego można spojrzeć dalej, w przeciwnym razie podwoi się. Na przykład, przesyłając zadanie do przeglądu kodu, bardzo wygodnie jest wyszukiwać według znaczników.

Przykłady

Tak to wygląda wklejanie kodu:

Tak to wygląda usuń kod - nie usuwamy całkowicie kodu, komentujemy kod. Dzięki temu zawsze możesz zobaczyć, co zostało zakomentowane, aw takim przypadku możesz szybko wrócić.

Tak to wygląda zmiana kodu: Najpierw komentowany jest cały kod dostawcy, a następnie dodawany jest kod.

Działa osobna zasada aby dodać procedury, funkcje i zmienne globalne do modułów... W tym przypadku komentarz zamykający jest umieszczany w tym samym wierszu, co słowo kluczowe EndProcedure... Dlaczego to się dzieje? Aby ułatwić przenoszenie modyfikacji za pomocą „porównania proceduralnego”.

Tutaj na zdjęciu możesz to zobaczyć używając „porównania procedur” możesz po prostu zaznaczyć tę procedurę podczas łączenia, i zostanie przeniesiony w całości (razem z etykietami). Lub odwrotnie, możesz odznaczyć pole znajdujące się przed nim, aby go nie przenosić.

A jeśli komentarz zamykający znajduje się w następnej linii, to zostanie odesłany do kolejnej procedury i nie będzie można go tak po prostu przenieść bez dodatkowych kosztów.

3. Dodawanie obiektów najwyższego poziomu

Następną zasadą jest dodanie do konfiguracji obiektów najwyższego poziomu (katalogów, dokumentów, rejestrów itp.).

Ta zasada jest taka nazwy obiektów muszą zaczynać się od przedrostka. Po co?

• Najpierw wizualnie podświetla dodany element w konfiguracji i w kodzie. od razu widać, że to nasz dodany obiekt.
• Po drugie, uzyskuje się wyjątkowość nazwyponieważ dostawca może dodać własny obiekt o tej samej nazwie. A jeśli użyjemy własnego przedrostka, zagwarantuje to, że nasza nazwa będzie niepowtarzalna.

Synonimy obiektów muszą zaczynać się od przedrostka w nawiasach... Pozwala to na wyróżnienie naszego dodanego obiektu w interfejsie.

Oczywiście jest to bardzo kontrowersyjna zasada i jego zastosowanie należy uzgodnić z klientem... Nasi klienci byli zadowoleni z takiego schematu, więc utkwił w nas i wpadł w zasady. Ale tutaj decyzja, czy to zrobić, czy nie, zależy od Ciebie i klienta.

No cóż, ostatnia zasada: komentarze do wszystkich dodanych obiektów muszą zawierać specjalny tag z nazwą dewelopera i numerem zadania. Ta etykieta jest podobna do komentarza otwierającego z modułu, tyle że bez znaków specjalnych - z jej pomocą zawsze mogę zrozumieć, kto, kiedy i do jakiego zadania dodał ten obiekt.

Podsumowując:

• Nazwy są poprzedzone,
• Synonimy - poprzedzone nawiasami
• A komentarz musi zawierać specjalną etykietę.

4. Dodawanie obiektów podrzędnych

Dodając podrzędne obiekty mam na myśli dodawanie rekwizytów, układów, formularzy itp. do obiektów konfiguracyjnych.

Tutaj musimy od razu zaznaczyć dwie sytuacje, w których dodajemy podrzędny obiekt:

• Do typowego obiektu konfiguracyjnego
• Lub w jakimś obiekcie, który został dodany wcześniej w projekcie.

Rozważmy każdą z tych sytuacji osobno.

Aby dodać obiekty podrzędne do typowych obiektów konfiguracyjnych obowiązują następujące zasady.

• Nazwy muszą zaczynać się dokładnie tak samo przedrostkiem... Dzięki temu uzyskujemy niepowtarzalność nazwy i zawsze widać też, że to nasz przedmiot.

• Synonim jest wypełniany bez przedrostkaponieważ nie ma już potrzeby wybierania naszych obiektów, naszych potrzeb.

• I w końcu, komentarz zawiera również specjalną etykietęaby było jasne, kto, kiedy i dlaczego.

Podsumujmy więc, w jaki sposób obiekty podrzędne są dodawane do typowych obiektów konfiguracyjnych:

• Nazwy są poprzedzone,
• Ogólne synonimy
• Komentarze zawierają specjalną etykietę.

I jeśli dodamy obiekty podrzędne do obiektów, które zostały wcześniej dodane w projekcie i zawierają już przedrostek w swojej nazwie, to:

• Ich nazwy nie mogą zawierać przedrostka, bo już widać, że przedmiot jest już wyjątkowy i nie ma potrzeby podkreślania go w żaden inny sposób.

• Synonimy dla takich obiektów podrzędnych są również określane bez przedrostka.ponieważ nie jest potrzebny żaden specjalny wybór.

• Komentarz zawiera specjalną etykietę tylko wtedy, gdy ten podrzędny obiekt jest dodawany w ramach innego zadania. Bo jeśli w moim zadaniu jest napisane, że muszę dodać dokument, który ma takie a takie szczegóły, nie muszę umieszczać takiego oznaczenia przy każdym atrybucie. Ale jeśli zadanie jest zupełnie inne, zdecydowanie umieszczam etykietę, aby było jasne, dlaczego to zrobiłem.

Podsumujmy teraz, w jaki sposób obiekty podrzędne są dodawane do obiektów dodanych w projekcie:

• Nazwy bez przedrostka.
• Synonimy bez przedrostka.
• Komentarze powinny zawierać specjalną etykietę tylko wtedy, gdy są dodawane jako część innego zadania.

Jeśli ta zasada zostanie połączona dla obu przypadków i „połóż na półkach”, otrzymasz następującą tabelę:

• Nowe obiekty:
  • Nazwa zaczyna się od przedrostka.
  • Synonimy są poprzedzone nawiasami.
  • Komentarz zawiera etykietę.
• Obiekty podrzędne, które dodajemy do obiektów ogólnych:
  • Nazwy zaczynają się od przedrostka,
  • Synonim ogólnych zasad
  • Umieściliśmy znak w komentarzu.
• A jeśli dodamy obiekty podrzędne do obiektów dodanych w projekcie, to
  • Nie ma dla nich specjalnych zasad,
  • Ale jeśli zadanie jest inne, w ten sam sposób umieszczamy ocenę w komentarzu.

5. Dodanie predefiniowanych elementów

Następną zasadą jest dodawanie predefiniowanych pozycji.

Można tu rozróżnić dwie sytuacje w ten sam sposób:

• Gdy dodamy predefiniowany element do typowego obiektu konfiguracyjnego (do referencji, do wykresu charakterystycznych typów)
• A kiedy dodamy predefiniowany element do obiektu dodanego w projekcie.

Jeśli dodamy predefiniowany element do ogólnego obiektu konfiguracyjnego,

• Jego nazwa podobny musi zaczynać się od przedrostka... W ten sposób gwarantujemy niepowtarzalność jego nazwy i możemy od razu wizualnie zidentyfikować nasz dodany element.
• Kod i imięzostanie utworzony zgodnie z ogólnymi zasadami,
• Ale etykieta tutaj niestety nigdzie położyć... Dlatego nie będzie można znaleźć tego dodanego wstępnie zdefiniowanego elementu za pomocą globalnego wyszukiwania zadań.

I jeśli dodamy predefiniowane elementy do obiektów dodanych w projekcienastępnie

• Jego nazwa nie będzie zawierała przedrostka, bo nie ma potrzeby jakoś go podkreślać.

Jeśli więc narysujemy analogię z poprzednią tabelą, to:

• Predefiniowane elementy dla obiektów ogólnych są dodawane z przedrostkiem,
• I cała reszta - zgodnie z ogólnymi zasadami nie trzeba dodawać żadnych specjalnych przedrostków.

6. Stosowanie wspólnych modułów i ich ścisła struktura

Kolejna zasada dotyczy wykorzystania wspólnych modułów i organizacji dla nich ścisłej struktury.

Najpierw należy dodać własne moduły dla różnych wielokrotnie używanych procedur, funkcji, programów obsługi subskrypcji i zaplanowanych zadań, pozostawiając standardowe moduły bez zmian. A jeśli programista chce umieścić jakąś procedurę eksportu w typowym module, to nie musi tego robić, musi stworzyć własny moduł.

Po drugie, zwróć uwagę na to wspólne moduły są dodawane zgodnie z zasadami dodawania obiektów najwyższego poziomu (nazwa i synonim z prefiksem, tag w komentarzu itp.)

Po trzecie, nazwy modułów powinny być podobne do odpowiadających im standardowych modułów.

Nie ma potrzeby odkrywania na nowo koła: nazywamy to tak samo, jak to jest zwykle przyjęte w typowych konfiguracjach - dla każdej funkcjonalności istnieje moduł odpowiadający ogólnie przyjętej notacji w 1C. Na przykład:

• FTO_GeneralAppointmentClient,
• FTO_GeneralPurposeServer,
• FTO_General PurposeGlobal,
• FTO_RegularJobsServer
• Itp.

A niektóre duże zadania indywidualne jest to możliwe (i prawdopodobnie konieczne) przejdź do oddzielnych wspólnych modułów.

7. Korzystanie z abonamentów i ich ścisła struktura

Kolejną zasadą jest stosowanie abonamentów i ich ścisłej struktury. Jaka jest jego istota?

Subskrypcje powinny być używane do obsługi różnych zdarzeń związanych z obiektami ogólnymi, Jak na przykład:

• Przed nagrywaniem
• Podczas nagrywania
• Itp.

• Możesz oczywiście wziąć i edytować moduł typowego obiektu, wstawiając swój kod do odpowiedniej procedury. Ale to - zła droga.
• To jest lepsze zamiast tego dodaj subskrypcję, aby obsłużyć to wydarzenie.

Subskrypcja jest dodawana zgodnie z następującymi ustalonymi zasadami:

1. Dla wszystkich wydarzeń tego samego typu w systemie dodawany jest tylko jeden abonament... Na przykład, jeśli muszę użyć mojego algorytmu dla różnych odniesień w zdarzeniu „Przed nagraniem odniesienia”, to dla wszystkich tych odniesień używam tylko jednej dodanej subskrypcji „Przed nagraniem odniesienia”.
2. Wszystkie obiekty w tej klasie są wybierane w źródle(na przykład wszystkie katalogi)
3. Dla dodanej subskrypcji tworzony jest osobny moduł o dokładnie takiej samej nazwie (tylko dla wygody).
4. W głównej procedurze obsługi zdarzeń definiowany jest warunek analizujący typ obiektu (rodzaj podręcznika).
5. I już określone akcje są wykonywane w zależności od rodzaju obiektu.

Mogę pokazać na przykładzie. Załóżmy, że istnieje takie zadanie: podczas wysyłania dokumentu „Raport zaliczkowy” dokonaj wpisów w dodanym wcześniej rejestrze akumulacyjnym.

Najpierw dodajemy ogólny moduł FTO_DocumentsProcessingW ze wszystkimi regułami.

• Określ DocumentObject (wszystkie dokumenty) jako źródło;
• Jako handler - nasz moduł dodany powyżej.

I już w module, w samym module obsługi, określamy, jaki dokument do nas trafił iw zależności od jego typu nazywamy tę lub inną procedurę.

Subskrypcja jest jedna, ale działania mogą być inne. Tmożesz także kontrolować kolejność wywoływania procedur.

W rezultacie procedura tworzenia subskrypcji wygląda następująco:

• Jedna subskrypcja,
• Jeden wspólny moduł
• I nic więcej nie jest potrzebne: moduł dokumentu pozostaje niezmieniony - w „dwukrotnie zmienionym” już się nie pojawi.

8. Edycja formularzy

Następną zasadą jest edycja formularza.

Tutaj, w ten sam sposób, podkreślamy dwa punkty, dwie sytuacje:

• Kiedy edytujemy przykładowe formularze;
• A kiedy edytujemy formularze dodane w ramach projektu.

Pierwsza sytuacja to edycjae standardowe formularze, formy typowych obiektów... To najbardziej kontrowersyjny punkt przepisów. Kiedyś, w czasach konwencjonalnych formularzy, kiedy projekty były wykonywane głównie na SCP, toczyliśmy wiele dyskusji na temat tego, co zrobić z formularzami. Jakie były możliwości?

• Bezpośrednia edycja regularnych kształtów polega na tym, że zmieniam kształt ręcznie. Dzięki tej opcji za każdym razem, gdy dostawca wprowadza zmiany w tym formularzu, muszę przesłać wszystkie moje zmiany od nowa. Zła droga.
• Innym sposobem jest wykonanie kopii formularza... Wtedy tworzę kopię przykładowego formularza, przypisuję go do głównego i wprowadzam w nim zmiany. Ale znowu, jeśli dostawca zmieni ten formularz, muszę ręcznie przenieść zmiany do mojego wariantu. Nie jest to najlepszy sposób.
• Inną opcją jest tworząc osobną zakładkę... Utwórz osobną zakładkę na formularzu i umieść na niej nasze elementy. Oczywiste jest, że ta metoda nie jest elastyczna, ponieważ czasami trzeba wstawić swój element gdzieś w określonym miejscu na formularzu. Lub musisz zmienić właściwości standardowych elementów, przypisać im nową procedurę obsługi itp. Dlatego to nie elastyczny sposób - to też nie działa zbyt dobrze.
• W rezultacie wybraliśmy całkowicie programową metodę edycji formularzy... Nowi programiści, którzy nie zetknęli się z tą metodą, początkowo mają duże trudności z programową edycją formularza. Ale w rzeczywistości - nie. Z mojej praktyki powiem, że wystarczy wziąć rękę w rękę. Ponadto mamy długie napisane moduły z procedurami eksportu dla programowo zmieniających się formularzy, a wszystko to jest dość łatwe. Po wprowadzeniu formularzy zarządzanych w pełni dokonaliśmy migracji tej praktyki programistycznego zmieniania formularzy do formularzy zarządzanych. Co więcej, programowe edytowanie zarządzanego formularza stało się ogólnie łatwe - za pomocą zwykłe formy nie porównuj.

Pokażmy ci przykład. W module obsługi OnCreateAtServer dodaję wywołanie do mojej procedury ModifyFormProgrammatically, gdzie mam dodatek oprogramowania elementy na formularz.

W konfiguracjach opartych na BSP 2 (takie jak ERP, księgowość itp.) event handlerForm.OnCreateAtServer ()które między innymi wchodzi również do nadpisanego modułu.

A więc w nadpisanym module możesz dodać swój kod - na przykład do procedury OnCreateAtServer (). Tutaj definiuję nazwę formularza iw zależności od tego nazywam tę lub inną procedurę, w której programowo dodaję elementy.

Wydaje się, że trudno, aby ten schemat był uciążliwy, ale tak naprawdę, jeśli wszystkie projekty są wykonywane według takich zasad, to deweloper otrzymując zadanie od razu wie, gdzie szukać, gdzie co dodać. Dlatego wydaje mi się, że jest to bardzo wygodne.

Ponadto w konfiguracjach opartych na BSP 2 przedefiniowane są również inne programy obsługi formularzy - takie jak ReadOnServer (), BeforeWriteOnServer () itp. W tych programach obsługi możesz również aktywnie używać nadpisywania wywoływanych procedur. Co więcej, nadpisany moduł dostawcy nie zmienia się teoretycznie i możesz tam napisać swój kod bez obawy o konflikty.

Jeśli edytujemy formularz dodany w projekcie, nie musimy robić nic specjalnego, edytujemy go w zwykły sposób, ręcznie.

9. Zasady pracy z rolami

A ostatnia zasada to zasady pracy z rolami.

Zasady pracy z rolami są następujące:

1. Jeśli to możliwe typowe role powinny być zawsze nienazwane... Musisz dokładnie przemyśleć, czy naprawdę konieczna jest zmiana typowej roli, czy też możesz zrobić coś inaczej.
2. Nadajemy uprawnienia dodanym obiektom konfiguracyjnym w nowych, specjalnie stworzonych rolach. Dlatego gdy dodam raport do konfiguracji, a nie ma odpowiedniej roli, którą wcześniej dla niego dodaliśmy, tworzę osobną rolę. A następnie ta rola jest dodawana do wymaganych profili. A typowe role się nie zmieniają.
3. I jeśli są zmiany wRLS, następnie są sporządzane zgodnie z zasadami edycji modułów.

Na przykład, jeśli muszę zmienić RLS, umieszczam komentarz otwierający, komentuję stary kod, a następnie dodaję własny i umieszczam komentarz zamykający. Zawsze jest jasne: kto, dlaczego (w ramach jakiego zadania) i kiedy się zmieniłem.

Dlatego wymieniłem wszystkie dziewięć prostych zasad modowania.

Dodatkowe przedmioty i techniki ułatwiające życie

Podsumowując, opowiem o niektórych obiektach i technikach, które mogą ułatwić życie programistom.

1. Samoidentyfikacja baz testowych

Pierwsza technika to samoidentyfikacja baz testowych.

Najważniejsze jest to, że:

• istnieje pewna stała, która przechowuje adres działającej bazy produkcyjnej.
• Podczas uruchamiania systemu ten adres jest sprawdzany: czy pasuje do roboczego adresu bazowego, czy nie.
• I jeśli nie pasuje (podstawa nie działa) nagłówek systemu został wymieniony.

Zrzut ekranu pokazuje, jak to wygląda. Jest to szczególnie przydatne, gdy programiści (lub konsultanci) mają otwartych wiele baz danych (roboczych, testowych, programistycznych itp.) I mogą nieumyślnie popełniać błędy i zmieniać dane w działającej bazie danych. A jeśli zmieni się nagłówek, to „na maszynie” - oczy w lewym górnym rogu, widzisz jaka to podstawa - tak, test, możesz to zmienić.

W ten sposób zwiększamy bezpieczeństwo zmiany danych w infobase.

Oprócz, sprawdzenie wartości tej stałej jest również przydatne podczas wykonywania niektórych rutynowych zadań... Mianowicie:

• wymiana danych,
• powiadomienia użytkownika,
• niektóre mailingi,
• ciężkie rutynowe zadania.
• Itp.

Gdy programista tworzy takie zaplanowane zadanie, musi sprawdzić, czy jest to baza robocza, czy nie. Jest oczywiste, że w teorii zaplanowane zadania na wszystkich bazach testowych powinny być wyłączone w konsoli klastra. Ale zawsze jest czynnik ludzki, kiedy ktoś stworzył nową bazę danych, załadował do niej nowe dane, coś zmienił, w wyniku czego nastąpiła jakaś krytyczna wymiana z działającymi bazami danych. A potem pojedynek - dlaczego to się stało? Dlatego my przed krytycznymi rutynowymi zadaniami zawsze sprawdzamy, czy jest to baza robocza, czy nie.

Konfiguracje oparte na BSP 2 mają podobny mechanizm: jeśli zmienia się lokalizacja bazy danych, pojawia się pytanie - czy jest to kopia bazy danych, czy też baza danych została przeniesiona. W zasadzie ten mechanizm może być wystarczający, ale znowu może interweniować czynnik ludzki, ktoś nie zrozumie, co się dzieje i wciśnie zły przycisk. W związku z tym, moim zdaniem stała jest bardziej niezawodna.

2. Obsługa inicjalizacji

Następną sztuczką jest obsługa inicjalizacji.

• To jest przetwarzanie dodatku konfiguracyjnego, które zawiera jego aktualną wersję w swoim kodzie.
• Jednocześnie do konfiguracji dodawana jest stała, która przechowuje aktualną wersję przetwarzania inicjalizacji.
• Podczas uruchamiania systemu przeprowadzane jest sprawdzenie
• Jeśli wersja uległa zmianie, niezbędne procedury obsługi są wykonywane i ustawiana jest nowa wartość stała.

Dlaczego jest to potrzebne? Często przy dodawaniu nowej funkcjonalności do konfiguracji konieczne jest wykonanie pewnych czynności w samej bazie danych: np. Dodaliśmy predefiniowany element katalogu, a teraz musimy uzupełnić jego szczegóły. Baz w projekcie może być wiele i ręczne wpisywanie tych danych jest oczywiście złe. Bardziej poprawne:

• Powiększ wersję przetwarzanie inicjalizacji;
• Opisz w kodzie, jak programowo wypełniać dane;
• I potem nowa wersja przetwarzanie automatycznie poprzez magazyn dostaniesz się do wszystkich niezbędnych baz danych, zacznij tam i wykona wszystkie niezbędne czynności.

Na schemacie to procedura operacyjna pokazane w ten sposób:

• Start systemu
• Porównanie stałej wersji z wersją przetwarzającą.
• Jeśli nie pasuje, są realizowane konsekwentnie wszystkie niezbędne obsługi,
• Nowa wartość stałej jest ustawiona.

W rezultacie dane są aktualizowane wszędzie, we wszystkich bazach danych.

3. Katalog predefiniowanych wartości

Następna sztuczka to katalog predefiniowanych wartości.

Często konieczne jest odwoływanie się z kodu do istniejących elementów katalogu, które nie są wstępnie zdefiniowane. Oczywiste jest, że lepiej jest utworzyć predefiniowany element, ale tak się stało, że elementu nie można wstępnie zdefiniować, ale nadal będzie on adresowany.

Jakie są możliwości wdrożenia?

• Zapoznaj się z pozycją według nazwy... Widać, że nazwa się zmieniła - kod przestał działać. słabo.
• Skorzystaj z kodu... Nieco lepiej, ale kod też może się zmienić. Niezbyt dobrze.
• Kontakt według identyfikatora wewnętrznego. Następnie podczas przenoszenia ten kod również nie będzie działał. Ogólnie rzecz biorąc, wszystkie te trzy przypadki nie będą działać, jeśli przeniesiemy modyfikację z jednej bazy do drugiej. Niezbyt dobrze.
• Oferowany utwórz katalog z predefiniowanymi wartościami.

Ten katalog zawiera tylko jeden atrybut o typie katalogu. (link do wszystkich podręczników).

Jeśli w ramach zadania muszę się odnieść do jakiegoś elementu, to do tego odnośnika dodaję predefiniowany element (np. Contractor_Agroimpulse)

Następnie w kodzie przetwarzania inicjalizacji lub ręcznie wpisuję wartość tego katalogu kontrahentem, którego potrzebuję.

W związku z tym po tym będę mógł odnieść się do tego kontrahenta za pośrednictwem katalogu predefiniowanych wartości... Dzięki temu osiąga się, że:

• Podczas przenoszenia modyfikacji między różnymi bazami, wszystkie moje kod działa bez dodatkowej pracy.
• Dodatkowo jest możliwe, że dzisiaj tym kontrahentem jest Agroimpulse, a jutro będzie to inna organizacja, ale nie muszę nic modyfikować w konfiguracji, po prostu biorę i zmieniam jego wartość w katalogu predefiniowanych wartości.

4. Przeglądanie tabel tymczasowych w debugerze

Cóż, ostatnią sztuczką jest wyświetlenie tymczasowych tabel w debugerze.

• Podczas debugowania złożonych zapytań za pomocą tabel tymczasowych muszą mieć możliwość przeglądania treścite tabele tymczasowe.
• Do tych celów mogą użyj specjalnej funkcji aby wyświetlić tymczasowe tabele.
• Ta funkcja wygodnie miejsce w module globalnym.

• I nazwać jakoś krótko, na przykład BT ()

W tym przypadku:

• ja umieścić punkt przerwania w miejscu, w którym mam prośbę.
• W oknie "Oblicz wyrażenie" piszę VT (Żądanie);
• Klikam „Oblicz” i uzyskanie struktury tymczasowych tabel zapytańaby zobaczyć, jakie są tam dane.

To bardzo przydatna funkcja i używamy jej cały czas. Zwłaszcza przy obliczaniu kosztów lub w konfiguracjach takich jak ZUP. Naprawdę nie rozumiem, jak inni żyją bez niej.

Najnowsza wersja platformy ma wbudowane narzędzie,co pozwala na przeglądanie tymczasowych tabel, ale wydaje mi się, że tak niezbyt wygodne. Korzystanie z funkcji jest znacznie lepsze.

Wniosek

Dziękuje za wszystko. Mam małą witrynę, na tej stronie wszystkie te zasady są szczegółowo określone i nie tylko one - wejdź, przeczytaj, napisz do mnie pocztą lub skype.

Ten temat jest dla mnie interesujący, jestem gotowy, aby się na ten temat komunikować. To dla mnie naprawdę ważne, że ty też odniosłeś sukces.

Zostaw swoje nazwisko i numer telefonu, operator skontaktuje się z Tobą pod adresem czas pracy w ciągu 2 godzin.

Moskwa Sankt Petersburg Samara

Zapewnij potężny i wszechstronny zestaw narzędzi dla różnych firm i biznesów. Warto jednak zauważyć, że uniwersalność ma wadę: programy pełnią tylko funkcje ogólne. na potrzeby każdej konkretnej firmy jest dość proste - pomogą w tym ulepszenia 1C.

Korzyści ze współpracy z nami

• Wszystkie usługi związane z rewizją 1C 8.2 są wykonywane zgodnie z ugruntowaną technologią, certyfikowaną zgodnie z międzynarodowym systemem zarządzania jakością ISO 9001: 2001.
• Gwarantujemy minimalne warunki wykonanie prac, pod warunkiem aktywnej współpracy Klienta z ekspertami naszej firmy.
• Ustaliliśmy ceny minimalnetak, że zarówno początkujący, jak i duże firmy mógłby wprowadzić niezbędne ulepszenia do 1C.
• my kontrolujemy jakość wykonanie pracy. Każdy pracownik ma przydzielonego eksperta 1C, który kontroluje pracę.
• my dajemy gwarancje za wykonaną pracę. Jeśli w ciągu dwóch miesięcy Klient wykryje błędy i usterki w działaniu programów 1C, naprawimy je całkowicie bezpłatnie.

Jakie są ulepszenia 1C?

Udoskonalanie 1C to rodzaj „dostrajania” programów 1C, których najczęściej używasz w swojej pracy.

Na jej podstawie wprowadzane są różne modyfikacje, które maksymalnie obejmują przedsiębiorstwa, firmy i organizacje reprezentowane na rynku międzynarodowym. Ale nie możesz zadowolić wszystkich, ponieważ każda firma jest wyjątkowa. To właśnie te „lokalne” ulepszenia są wprowadzane przez specjalistów z 1C: Franchisee Victoria.

Kiedy należy zaktualizować 1C?

Przed wprowadzeniem ulepszeń do 1C musisz odpowiedzieć sobie na kilka pytań:

• Czy specyfika organizacji jest zaimplementowana w typowej funkcjonalności? Nasze doświadczenie pozwala stwierdzić, że większość decyzji o rewizji zapada w pośpiechu. W rezultacie firmy inwestują dużo pieniędzy w ulepszenia i modyfikacje, ale nie uzyskują oczekiwanego rezultatu. Ale musieli tylko skonsultować się ze specjalistą.
• Czy procesy mające na celu automatyzację organizacji są naprawdę ważne właśnie w takiej formie, w jakiej rozwinęły się w firmie? Opracowując konfiguracje dla 1C, specjaliści z 1C: Franchisee Victoria używają metod księgowych, które zostały udowodnione przez czas i doświadczenie wielu firm. Takie techniki są najbardziej efektywne, dlatego lepiej zaufać naszemu doświadczeniu i nieco zrestrukturyzować niektóre procesy biznesowe w firmie.

Eksperci zalecają wprowadzanie ulepszeń tylko pod warunkiem, że wszystkie możliwości wbudowanej funkcjonalności już się wyczerpały. Chcemy zauważyć, że typowa funkcjonalność programów 1C jest dość szeroka i, jeśli jest odpowiednio skonfigurowana, może być używana do rozwiązywania większości standardowych zadań.

Jeśli nie da się obejść bez modyfikacji, eksperci analizują, czy wprowadzone zmiany wpłyną na inne działy rachunkowości.

Naszym celem jest wprowadzanie ulepszeń przy minimalnych zmianach konfiguracji, aby dalsza konserwacja oprogramowania nie stała się „czarną dziurą” i utrapieniem firmy.

W naszej firmie usprawnienia konfiguracji 1C wykonywane są zgodnie z wymaganiami międzynarodowego systemu jakości ISO 9001: 2001.

Jak uszlachetnia się 1C?

Główną przewagą konkurencyjną oprogramowania 1C 8.2 i 8.3 jest możliwość modyfikowania standardowych konfiguracji programu i opracowywania najbardziej optymalnych rozwiązań dla wymagań użytkownika końcowego w oparciu o platformę 1C.
Szeroka funkcjonalność implementuje własny język programowania, a także wbudowane środowisko programistyczne, które zapewnia elastyczność ustawień.

1C w interesie użytkowników oprogramowanie tworzy gotowe rozwiązania, równie zdolne do zaspokojenia potrzeb każdej organizacji, biorąc pod uwagę wyjątkowość i specyfikę każdego przedsiębiorstwa. Szeroki wybór dodatków do podstawowej konfiguracji sprawia, że \u200b\u200bpraca w 1C jest maksymalnie wygodna.

Masz pytanie, potrzebujesz pomocy konsultanta?

Jakie są najczęstsze ulepszenia w 1C?

Najczęstszym rodzajem przeróbek jest modyfikacja interfejsu użytkownika. Głębsze zmiany związane z tworzeniem i implementacją specjalnych algorytmów do systemu są mniej powszechne, ale są też dostępne do implementacji.

Przykłady modyfikacji 1C

1. Elastyczna konfiguracja dostępu i praw użytkownika jest prawdopodobnie najważniejsza dla każdego systemu wielodostępnego. Również w 1C można skonfigurować wartości domyślne, co znacznie przyspiesza proces pracy.
2. Opracowanie i korekta różnych drukowane formularze, w 1C, które są analogiczne do dokumentu papierowego, a także raporty, które są końcowym produktem analizy wprowadzonych danych w programie 1C. Modyfikacje te nie wymagają poważnej ingerencji w konfigurację programu.
3. Opracowanie i wykonanie jasnych i zrozumiałych specyfikacji technicznych dla programisty 1C, ułatwiających dalszą modyfikację i pozwalających z powodzeniem angażować w jej realizację zewnętrznych wykonawców.
4. System 1C jest dość wszechstronny iw początkowej wersji nie zawsze spełnia wszystkie wymagania użytkownika końcowego, dlatego często wymaga opracowania i wdrożenia unikalnej funkcjonalności, zgodnie z życzeniem klienta.
5. Dostrajanie wydajności i wydajności w celu zapewnienia maksymalnej efektywności wykonywania operacji rozliczeniowych

Koszt usług specjalistycznych do pracy z 1C

Prawie wszystkie projekty w prawie każdej dużej firmie integratorskiej 1C polegają na finalizacji typowych konfiguracji i mają na celu głównie optymalizację księgowości działalność gospodarcza organizacja i dostarczanie odpowiedniego regulowanego raportowania. A to z kolei oznacza, że \u200b\u200bw przyszłości wdrażane rozwiązania będą wymagały dopracowania zgodnie z często zmieniającymi się przepisami. W praktyce oznacza to prawie zawsze aktualizację wydań typowych konfiguracji, na podstawie których podjęto decyzję, oraz dostosowanie dokonanych już modyfikacji zgodnie ze zmianami w kolejnej wersji.

Często projektu nie można uznać za całkowicie udany, jeśli klient nie został w organizacji integratora w celu uzyskania wsparcia. A jeśli zastosujesz się do ścisłych zasad zmiany typowych konfiguracji, to wydatki bardzo mało czasu na etapie rozwoju możesz zaoszczędzić wiele, wiele godzin i nerwów w przyszłości na ciągłe aktualizowanie zmienionej konfiguracji. I odwrotnie, niegrzeczne podejście do projektowania kodu, polegające na „diablowej opiece”, wybór szybszych i prostszych, ale niewłaściwych sposobów realizacji zadań, może zmienić aktualizację wynikowej konfiguracji w prawdziwe piekło wsparcia. W przyszłości będzie to skutkować ogromnymi godzinami aktualizacji, dużym obciążeniem programistów w okresie raportowania, dużą liczbą błędów po aktualizacji, niezadowoleniem klienta itp.

Poniżej znajduje się zestaw reguł deweloperskich w typowych konfiguracjach, co znacznie ułatwi dalsze aktualizacje konfiguracji. Ten kod narodził się stopniowo z wieloletniego doświadczenia dużej liczby programistów jednej wspaniałej firmy i, w moim najgłębszym przekonaniu, powinien być obowiązkowy dla wszystkich programistów, niezależnie od działu / projektu / kierunku, w którym pracują.

1. Pojęcie minimalizacji „zniszczenia” typowej konfiguracji

Jeśli zmodyfikowana typowa konfiguracja ma być aktualizowana w miarę wydawania nowych wydań, to programiści powinni zawsze o tym pamiętaj i podejmij kroki w celu ułatwienia aktualizacji. Zawsze powinieneś wybierać te metody rozwiązywania problemów, które zapewnią łatwiejsza aktualizacja konfiguracji w przyszłości, nawet jeśli będą one nieco trudniejsze do wdrożenia. Oczywiście pod warunkiem, że metoda bardziej przyjazna dla aktualizacji nie ma poważnych niedociągnięć w zakresie wydajności, czytelności kodu itp.

2. Komentując zmiany w kodzie:

Absolutnie wszystkie zmiany w kodzie programu modułów powinny być komentowane. Blok wierszy, który przeszedł zmianę, musi być otoczony liniami komentarza o specjalnym formacie. Zasada tworzenia tych linii jest pokazana na przykładzie:

// ++ VION 07/20/2016 0001234 Ulepszenie na początku // - VION 07/20/2016

• // ++ - początek bloku
• // - - koniec bloku
• VION - nazwa (lub pseudonim) dewelopera
• 0001234 - numer zadania według trackera, umieszczany tylko w komentarzu otwierającym, dzięki czemu każda zmiana w kodzie trafia do wyników wyszukiwania globalnego po numerze zadania tylko raz
• Dopracowanie na starcie - dowolny komentarz, używany w razie potrzeby, ale jeśli brakuje numeru zadania, wymagany jest krótki tekst wyjaśniający

Komentarze mają na celu podkreślenie modyfikacji w porównaniu z typową funkcjonalnością. Jeśli deweloper zmieni po pewnym czasie tekst własnej modyfikacji w ramach tego samego zadania, to takie zmiany nie są osobno komentowane (a istniejący komentarz zewnętrzny również się nie zmienia). Jeśli programista wprowadza zmiany w swoim tekście, ale dla innego zadania, lub zmienia kod napisany przez innego programistę, należy zastosować komentarz.

Komentarze w ramkach są wyrównane do lewej strony edytowalnego bloku kodu. Poniższe przykłady pokazują, jak używać komentowania zmian:

2.1 Wstawianie kodu

Przykład:

Procedura OnOpening () Jeśli to jest New () Then FillFieldsDefault (); EndIf; ConfigureFormElements (); // ++ VION 07/20/2016 0001234 ConfigureAdditionalElements (); // - VION 07/20/2016 Widoczność SetFields (); Koniec procedury

2.2 Usuwanie kodu

Przykład:

Procedura otwarta () // ++ VION 07/20/2016 0001234 // If This is New () Then // FillFieldsDefault (); // EndIf;ConfigureAdditionalElements (); // - VION 07/20/2016 Widoczność SetFields (); Koniec procedury

2.3 Modyfikacja istniejącego kodu

Podczas zmiany istniejącego kodu najpierw komentowany jest stary blok, a następnie zapisywana jest nowa wersja.

Przykład:

Procedura OnOpen () Jeśli to jest nowe () Then // ++ VION 07/20/2016 000123 // FillFieldsDefault ();FieldFillSettings \u003d GetFieldsFillSettings (); FillFieldsDefault Advanced (CustomizeFillFields); // - VION 07/20/2016 EndIf; ConfigureFormElements (); SetVisibilityFields (); Koniec procedury

2.4 Dodawanie procedur i funkcji w module

Do dodawania procedur i funkcji, a także do deklarowania zmiennych modułu standardowych obiektów, dodatkowe zasady komentowanie:

• To nie blok dodanych procedur jest komentowany jako całość, ale każdy dodana procedura lub funkcja w osobno.
• Komentarz otwierający jest umieszczany w wierszu przed nagłówkiem procedury lub funkcji, a komentarz zamykający - umieszczany w tej samej linii, gdzie jest napisane „Koniec procedury” lub „Koniec procedury”, oddzielone spacją.
• Komentowanie zmian w istniejących procedurach odbywa się na ogólnych zasadach.

Przykład:

// ++ VION 07/20/2016 000123 Var mSettingsFillFields; Procedura Modyfikuj formularz programowo () ... ... EndProcedure// - VION 07/20/2016 // ++ VION 07/20/2016 000123Procedura Data WysyłkiProcessingSelection () ... ... EndProcedure// - WERSJA 20.07.2016

Ta reguła ułatwia przenoszenie zmian w module w „proceduralnym porównaniu” konfiguracji.

Jeśli umieścisz komentarz zamykający w następnej linii:

Następnie, w „porównaniu proceduralnym”, komentarz ten zostanie uznany za opis następnej procedury w tekście, która zostanie uznana za zmodyfikowaną.

3. Dodawanie obiektów najwyższego poziomu

Nazwy obiekty najwyższego poziomu, utworzone w konfiguracji, koniecznie musi zaczynać się prefiksem firmy lub oddzielnym prefiksem projektu. Z reguły składa się na przykład z dwóch lub trzech wielkich liter i podkreślenia AB_... W związku z tym utworzone obiekty zostaną nazwane AB_NewReference, AB_NewDataRegister, AB_NewDocument itp.

Synonimy (nazwy widoczne dla użytkownika) dodanych obiektów najwyższego poziomu muszą zaczynać się od przedrostka umieszczonego w nawiasach: (AB)... W rezultacie obiekty te zostaną wizualnie wyróżnione na listach i zgrupowane na początku (co ułatwia zarówno testowanie, jak i użytkowanie).

W komentarzu do tworzonego obiektu należy wskazać nazwę dewelopera, datę i numer zadania analogicznie do dodanego kodu, ale bez znaków „++”. Zapewni to, że obiekt konfiguracyjny jest powiązany z zadaniem, którego szuka wyszukiwanie globalne.

Przykład: Utwórz katalog „Projekty”.

Działania deweloperskie: w konfiguracji tworzony jest następujący odnośnik:

• Nazwa: AB_Projects
• Synonim: (AB) Projekty

4. Dodawanie obiektów podrzędnych

Sposób dodawania atrybutów obiektów konfiguracyjnych zależy od tego, do którego obiektu konfiguracyjnego atrybut jest dodawany: do obiektu konfiguracyjnego utworzonego przez dostawcę typowego rozwiązania (tj. Obsługiwanego obiektu) lub do obiektu dodanego w ramach bieżącego projektu ( tj. ma już prefiks) ...

4.1 Dodawanie obiektów podrzędnych do typowych obiektów konfiguracyjnych

Obiekty podrzędne dodane do istniejących (typowych) obiektów konfiguracyjnych muszą przedrostek: AB_AdditionalProps, AB_New TabularPart, AB_UserSettingsForm, AB_LayoutSpecial Invoice... Ale jednocześnie tworzone są synonimy takich podrzędnych obiektów bez przedrostka.

W komentarzu do tworzonego obiektu należy wskazać nazwisko dewelopera, datę oraz numer zadania analogicznie do. Zapewni to, że obiekt konfiguracyjny jest powiązany z zadaniem, którego szuka wyszukiwanie globalne.

Przykład: Utwórz atrybut „Projekt” dokumentu „Zaliczka”.

Działania deweloperskie: w konfiguracji tworzone są następujące właściwości:

• Nazwa: AB_Project
• Synonim: Project
• Komentarz: // VION 07/20/2016 000123

4.2 Dodawanie obiektów podrzędnych do obiektów dodanych w projekcie

Dodawane są obiekty podrzędne dodane do obiektów najwyższego poziomu dodanych do konfiguracji w ramach projektu, czyli zawierające już przedrostek w nazwie bez przedrostka... Tworzone są także synonimy dla takich podrzędnych obiektów bez przedrostka.

W komentarzu do tworzonego obiektu należy wskazać nazwisko dewelopera, datę oraz numer zadania analogicznie do. Zapewni to, że obiekt konfiguracyjny jest powiązany z zadaniem, którego szuka wyszukiwanie globalne. Komentarz można pominąć, jeśli atrybuty są tworzone w ramach tego samego zadania, co sam obiekt najwyższego poziomu.

Przykład: Utwórz atrybut „Responsible” dla katalogu „(AB) Projects”.

Działania deweloperskie: Jeśli zadanie różni się od tego, w którym utworzono katalog „(AB) Projects”, to w konfiguracji tworzony jest następujący atrybut:

• Imię: Odpowiedzialny
• Synonim: odpowiedzialny
• Komentarz: // VION 07/20/2016 000456

5. Dodawanie predefiniowanych elementów

Dodając predefiniowane elementy katalogu, wykresy typów charakterystycznych i plany kont należy stosować te same zasady, co przy dodawaniu obiektów podrzędnych (przekroje tabelaryczne, atrybuty) do obiektów najwyższego poziomu.

5.1 Dodawanie predefiniowanych elementów do typowych obiektów konfiguracyjnych

Konieczne jest dodanie predefiniowanych elementów dla typowych obiektów konfiguracyjnych z przedrostkiem... Nazwa została ustawiona bez przedrostka.

Przykład: Dodać zdefiniowane konto 10.15 - Formy ścisłego raportowania do planu kont „Samonośne”.

Działania deweloperskie: Dodaj następujące wstępnie zdefiniowane konto:

• Nazwa: AB_Statement Forms
• Kod: 10.15
• Imię: Formy ścisłego raportowania

Jeśli potrzebujesz zmienić nazwę predefiniowanego elementu typowego obiektu konfiguracyjnego (na przykład konta), powinieneś pozostawić sam obiekt bez zmian i zmienić programowo nazwę w specjalnym.

5.2 Dodawanie predefiniowanych elementów do obiektów dodanych w ramach projektu

Predefiniowane elementy są dodawane do obiektów konfiguracyjnych dodawanych w ramach projektu, czyli zawierających już przedrostek w swojej nazwie. bez przedrostka w nazwie i tytule.

6. Stosowanie wspólnych modułów i ich ścisła struktura

Procedury i funkcje, które są wielokrotnie używane w konfiguracji, subskrypcjach i programach obsługi zaplanowanych zadań, są umieszczane we wspólnych modułach. W tym celu dodaj własne modułydodane przez obiekty najwyższego poziomu, pozostawiając standardowe moduły niezmieniony... Podczas programowania przydatne będą następujące wspólne moduły (przedrostek „AB_”):

• AB_General (klient, serwer, połączenie zewnętrzne) - do hostowania wspólnych procedur i funkcji.
• AB_Server (tylko serwer) - dla procedur i funkcji, które muszą być wykonywane w środowisku serwera.
• AB_Global - dla procedur i funkcji, które są niewygodne do wywołania w standardowy sposób (poprzez nazwę modułu i kropkę).
• AB_Privileged - za procedury i funkcje, które zawsze muszą być wykonywane z pełnymi prawami.
• AB_Reuse - buforować wartości zwracane przez niektóre funkcje.

Kody bloków funkcyjnych można przenosić do oddzielnych wspólnych modułów duża objętość, ułatwia to debugowanie takiego kodu podczas korzystania z magazynu konfiguracji. W przeciwnym razie programista powinien upewnić się, że dostępny jest odpowiedni wspólny moduł przed dodaniem nowego modułu do konfiguracji.

7. Korzystanie z abonamentów i ich ścisła struktura

Aby obsłużyć różne zdarzenia związane ze standardowymi obiektami konfiguracyjnymi, należy używać mechanizmu subskrypcji zamiast modyfikować moduły samych obiektów, jeśli to możliwe.

Dla każdego wydarzenia może być nie więcej niż jedna subskrypcja (jako obiekt metadanych), którego handler i powiązany kod należy umieścić w oddzielny moduł ogólny (aby zwiększyć równoległość deweloperów pracujących z repozytorium). Nazwa subskrypcji i nazwa modułu udostępnionego muszą być są takie same i dopasowanie przetwarzane wydarzenie. Wskazane jest źródło subskrypcji wszystko obiekty potencjalnie możliwe do przetworzenia (wszystkie katalogi, wszystkie dokumenty itp.).

Procedura obsługi subskrypcji musi zawierać wywołania podprogramów, które wykonują wymagane działania. Są one określane w zależności od rodzaju źródła, a także w pożądanej kolejności. Przeprowadzane jest komentowanie w module subskrypcji podczas dodawania kodu do nowych zadań.

Przykład: Księgując dokument „Zaliczka”, należy dokonać wpisów w rejestrze akumulacji „(AB) Koszty projektu”.

Działania deweloperskie:

1. Utwórz subskrypcję „AB_DocumentsProcessingProcessing” (jeśli taka subskrypcja nie została utworzona wcześniej), określ wszystkie dokumenty jako źródło, zdarzenie - „PostingProcessing”.

2. Utwórz wspólny moduł serwera „AB_DocumentsProcessingProcessing”.

3. W module stwórz procedurę eksportu „Przetwarzanie księgowe”. Wybierz tę procedurę jako procedurę obsługi poprzednio utworzonej subskrypcji. W procedurze, w zależności od typu dokumentu, wywoływane są niezbędne procedury obsługi.

4. Moduł dokumentu „Zaliczka” musi pozostać niezmieniony.

8. Edycja formularzy

8.1 Edycja kształtów typowych obiektów

Jeśli zmiana w standardowym formularzu (zarówno normalnym, jak i zarządzanym) jest niewielka (np. Umieszczenie kilku nowych szczegółów na formularzu), to taką zmianę należy wykonać całkowicie programowo. Oznacza to, że zmiany są wprowadzane tylko w moduł formularza, a sam formularz w konfiguratorze pozostaje niezmieniony... Niektórym programistom ta metoda edycji formularzy może początkowo wydawać się dość czasochłonna. Jednak mając wystarczające doświadczenie w programowo zmieniających się formach, dodanie jednego elementu nie zajmie więcej niż 3-5 minut. Spędzony czas procentuje wielokrotnie przy kolejnych aktualizacjach typowej konfiguracji.

Przykład: W formularzu głównym dokumentu „Zaliczka” dodaj zmienną „Projekt (AB)”.

Działania deweloperskie: W module obsługi formularza „OnCreateAtServer” dodaj procedurę „ModifyFormProgrammatically ()”. W tej procedurze dodaj żądany element, aby utworzyć elementy.

Możliwe jest stworzenie osobnego modułu, który będzie zawierał wszystkie niezbędne procedury i funkcje zmiany standardowych formularzy.

W typowych konfiguracjach opartych na BSP 2 istnieje już specjalna funkcjonalność do tych celów:

W procedurze „OnCreateAtServer” modułu ogólnego „ModifyConfigurationRedefinable” możesz wywołać procedurę obsługi.

Gdzie przez nazwę formularza można wywołać niezbędną procedurę z programową modyfikacją formularza.

Jeśli planujesz dodać do formularza duża liczba elementów lub sekcje tabelaryczne, istnieje również możliwość ręcznej zmiany formularza. W takim przypadku zaleca się utworzenie osobnej zakładki na formularzu i umieszczenie na niej wszystkich niezbędnych elementów. Ułatwi to dalszą aktualizację formularza.

8.2 Edycja kształtów obiektów dodanych w projekcie

Kształty obiektów dodanych w ramach projektu (czyli te z przedrostkiem w nazwie) są edytowane w zwykły sposób.

9. Zasady pracy z rolami

Role ogólne powinny zawsze pozostawać niezmienione (jeśli to możliwe). Ma to na celu ułatwienie aktualizacji zmienionej konfiguracji z nowych wersji, ponieważ porównywanie i przywracanie ról to skomplikowany i żmudny proces.

Należy nadać uprawnienia do obiektów dodanych do konfiguracji w nowymrole utworzone w tym celu.

Należy wdrożyć ograniczenia dostępu do danych dozwolone przez role ogólne programowotak długo jak to tylko możliwe. I tylko wtedy, gdy taki zakaz będzie bardzo trudny do programowej realizacji (lub takie rozwiązanie będzie zawodne), dopuszczalna jest modyfikacja typowych ról. Zmiany w typowych rolach powinny być jak najmniej konieczne i udokumentowane. Na przykład, jeśli potrzebujesz zmienić tekst ograniczeń dostępu w roli (RLS), to zgodnie z zaleceniami należy zakomentować cały przykładowy kod, a następnie dodać kod z niezbędnymi zmianami.

10. Raporty zewnętrzne i przetwarzanie

Większość usprawnień w systemie można wykonać za pomocą dodatkowych raportów i mechanizmu przetwarzania.

W konfiguracjach opartych na BSP 2 (ERP, UT 11, BP 3.0, ZUP 3.0 itd.) Mechanizm ten jest znacznie rozbudowany. Z jego pomocą, bez zmiany konfiguracji, możliwe jest tworzenie raporty zewnętrzne i przetwarzanie (z umieszczeniem polecenia uruchomienia w interfejsie poleceń i możliwością konfiguracji dostępu dla różnych użytkowników), przetwarzanie wypełnienia dokumentu, przetwarzanie tworzenia dokumentu na podstawie, dodatkowe formularze drukarskie itp.

Czy ten artykuł był pomocny?

Opracowany przez całe działy wysoko wykwalifikowanych specjalistów firmy "1C" o typowych i branżowych konfiguracjach, przeznaczony do prowadzenia księgowości biznesowej, a także dostarczania raportowanie podatkowe... Deweloperzy stworzyli pomoc naukowa i od kilkudziesięciu lat wspierają technologicznie i doradczo swoje programy w oparciu o normy i zalecenia ustawodawstwa Federacji Rosyjskiej.

Wydawać by się mogło, że programy już wszystko przewidują: wszelkiego rodzaju dokumenty, podręczniki, rejestry, mechanizmy pracy z nimi, wygodne interfejsy użytkownika, konfiguracje demonstracyjne z wypełnionymi danymi jako rzeczywiste przykłady księgowości.

Typowe konfiguracje są napisane dla typowej księgowości i koncentrują się na przeciętnej i prawie idealnej organizacji.

W prawdziwym życiu księgowość biznesowa może mieć dość złożone i niestandardowe sytuacje. Księgowi i specjaliści chcą widzieć ten lub inny raport w nieco zmodyfikowanej formie, a regularna możliwość przesyłania danych informacyjnych z jednego programu do drugiego (na przykład z księgowości do handlu lub z wynagrodzenia do księgowości) nie uwzględnia wszystkich specyfika organizacji.

W takich przypadkach na ratunek przyjdą ci, którzy rozumieją strukturę konfiguracyjną, możliwości systemu, jego specyficzne mechanizmy i wiedzą, jak efektywnie zastosować te informacje w praktyce. Będą mogli nie tylko wybrać, ale także udoskonalić konfigurację 1C, rozszerzając jej standardową funkcjonalność.

Korzyści ze zmodyfikowanej konfiguracji

Aby móc wprowadzić nawet drobne zmiany (drukowane formularze dokumentów, wygląd dokumentów i podręczników) w standardowych rozwiązaniach aplikacyjnych opartych na platformie 1C: Enterprise 7.7, konieczne było usunięcie konfiguracji ze wsparcia. W przypadku platformy, począwszy od wersji 8.0, problem ten został częściowo rozwiązany: zewnętrzne drukowalne formularze, raporty i formularze można modyfikować lub odtwarzać bez zmiany struktury konfiguracji, a zarządzane formularze platformy 8.3 zapewniają jeszcze więcej opcji.

Moduły rozwiązań 1C: Enterprise, które są otwarte na zmiany, umożliwiają modyfikowanie i dostosowywanie dowolnego rozwiązania aplikacyjnego „dla siebie”. Udoskonalenie programu 1C zapewnia szereg korzyści:

1. Przede wszystkim oprogramowanie dostosowuje się do specyficznych wymagań księgowych organizacji.
2. Za pomocą nowo opracowanych i wprowadzonych do konfiguracji uprawnień i ról użytkowników możliwe jest bardziej elastyczne opisanie dozwolonych i zabronionych czynności podczas pracy z dokumentami i katalogami jednego lub grupy pracowników.
3. Dostosowywanie i zmiana interfejsów użytkownika (w przypadku aplikacji zarządzanych wiele jest wdrażanych w sposób regularny).
4. Możliwość zmiany drukowanych formularzy dokumentów, formularzy i raportów.
5. Zmiana mechanizmów wewnętrznych obliczeń oprogramowania, tworzenie skomplikowanych obliczeń, formuł produkcyjnych, skomplikowanych pól dokumentów itp.
6. Możliwość zmiany wygląd dokumenty, dzienniki dokumentów, rejestry użytkowników, pozycje katalogów.
7. Możliwość dodawania wizualnej reprezentacji obiektów.

Modyfikacja zastosowanych rozwiązań nie wymaga stosowania żadnego oddzielnego oprogramowania - wszystkie narzędzia programistyczne są częścią platformy technologicznej.

Wady dostosowywania konfiguracji

Przy wszystkich oczywistych zaletach udoskonalenie typowych konfiguracji 1C pociąga za sobą nieprzyjemne konsekwencje:

1. Typowe rozwiązanie usunięte z pomocy technicznej 1C z powodu możliwości rewizji traci możliwość automatycznej aktualizacji... Jeśli mimo wszystko aktualizacja zostanie wykonana, wszystkie zmiany wprowadzone w architekturze konfiguracji zostaną utracone. Tylko wykwalifikowany technik będzie mógł aktualizować oprogramowanie i przeprowadzać migrację wszelkich ręcznie napisanych ulepszeń do zaktualizowanego oprogramowania.
2. Dość często zdarza się, że dopracowane samodzielnie napisane mechanizmy konfiguracyjne są następnie wdrażane przez programistów 1C w regularny sposób i są dołączane jako część jednej z aktualizacji. Dzięki temu modyfikacje dokonane wcześniej nie są już potrzebne.
3. Każdy programista 1C jako artysta ma swój własny styl: ktoś z doświadczeniem pisze bardziej kompetentnie i profesjonalnie, ktoś jest bardziej oryginalny. W razie potrzeby zrozumienie kodu innej osoby może być bardzo trudne do tego stopnia, że \u200b\u200bszybsze jest napisanie modułu od zera niż wprowadzanie zmian w kodzie innej osoby. W związku z tym istnieje pewne przywiązanie do programisty, który wprowadza zmiany w programie.
4. Klient nie zawsze posiada wystarczające kwalifikacje, aby skomponować kompetentną zadanie techniczne i jasno wyjaśnij, co ostateczny wynik chce zobaczyć. W rezultacie mogą wystąpić nieporozumienia między obiema stronami i potrzeba dalszego dostosowania zamówienia.

Często zdarza się, że to niepewni użytkownicy rozwiązań oprogramowania 1C: Enterprise, którzy nie zapoznali się ze wszystkimi ustawieniami, metodami księgowania, mechanizmami rozliczeń, nie zrozumieli ustawień drukowanych formularzy i raportów, proszą o zmianę konfiguracji. W takich przypadkach zadaniem dewelopera jest zidentyfikowanie możliwych standardowych rozwiązań zaistniałych problematycznych problemów, nauczenie użytkownika ich obsługi, a wprowadzanie zmian w konfiguracji tylko w przypadku naprawdę pilnej potrzeby.