Jak otworzyć 

Udoskonalenie standardowych konfiguracji 1c. Dodawanie predefiniowanych elementów

Czy potrzebujesz rozszerzyć funkcjonalność 1C? Potrzebujesz programu do rozwiązania nie tylko typowych, ale i specyficznych problemów Twojego przedsiębiorstwa? Usługa modyfikacji 1C firmy Active-IT pomoże Ci szybko rozwiązać te problemy.

Przeprowadzamy modyfikacje standardowych konfiguracji 1C o dowolnym poziomie złożoności: od stworzenia indywidualnego drukowane formularze przed wprowadzeniem algorytmu naliczania premii za godziny pracy itp.

Czas realizacji- do 5 dni. W przypadku opóźnienia do 10 dni bezpłatnie dokonamy dla Państwa poprawek.

Kolejną zaletą współpracy z nami jest to, że zawsze wykonujemy swoją pracę w dobrej wierze. Nie pracujemy według schematu „rozumiem”. zadanie techniczne==> wykonałem zadanie ==> oddałem i zapomniałem.” Przyjmujemy zlecenie techniczne, sprawnie wykonujemy naszą pracę, pozwalamy ocenić efekt i w razie potrzeby skorygować rewizję bez dodatkowej opłaty.

Koszt programisty 1C

Koszt modyfikacji konfiguracji: 1500 rubli. za godzinę pracy programisty.

W rezultacie otrzymujesz:

  • Współpraca z doświadczonymi programistami.
  • Tworzenie i wdrażanie ulepszeń o absolutnie dowolnym poziomie złożoności.
  • Realizacja prac w możliwie najkrótszym czasie – do 5 dni.
  • Gwarancja zwrotu pieniędzy w przypadku opóźnienia.
  • Zapewnienie jakości.

Zamów modyfikacje do księgowości 1C od Active-IT!
Dostosuj z nami pracę 1C do specyfiki swojego przedsiębiorstwa.

Prawie wszystkie projekty w prawie każdej dużej firmie integrującej 1C polegają na udoskonalaniu standardowych konfiguracji i mają na celu głównie optymalizację rachunkowości działalność gospodarcza organizowanie i składanie odpowiedniej sprawozdawczości regulowanej. A to z kolei oznacza, że ​​w przyszłości wdrażane rozwiązania będą wymagały modyfikacji zgodnie z często zmieniającym się ustawodawstwem. W praktyce prawie zawsze oznacza to aktualizację wydań standardowych konfiguracji, na których opierało się rozwiązanie i dostosowanie już dokonanych modyfikacji zgodnie ze zmianami w kolejnym wydaniu.

Często projektu nie można nazwać całkowicie udanym, jeśli klient nie pozostaje w organizacji integratora w celu uzyskania wsparcia. A jeśli będziesz przestrzegać ścisłych zasad zmiany standardowych konfiguracji, to po wydaniu bardzo mało czasu na etapie rozwoju możesz zaoszczędzić wiele, wiele godzin i nerwów w przyszłości na ciągłej aktualizacji zmienionej konfiguracji. I odwrotnie, niegrzeczne podejście do projektowania kodu w stylu „nie przejmuje się” i wybieranie szybszych i prostszych niż poprawnych sposobów realizacji zadań może zmienić aktualizację powstałej konfiguracji w prawdziwe piekło do obsługi. W przyszłości będzie to skutkować ogromnymi godzinami aktualizacji, dużym obciążeniem programistów pracą w okresie raportowania, duża liczba błędy po aktualizacji, niezadowolenie klientów itp.

Poniżej znajduje się zestaw zasad programistycznych w typowych konfiguracjach, które znacznie ułatwią dalsze aktualizacje konfiguracji. Kod ten narodził się stopniowo z wieloletniego doświadczenia dużej liczby programistów jednej wspaniałej firmy i, moim zdaniem najgłębsze przekonanie, powinno być obowiązkowe dla wszystkich programistów, bez względu na dział/projekt/kierunek, w którym pracują.

1. Koncepcja minimalizacji „zniszczenia” konfiguracji standardowej

Jeśli zmodyfikowana konfiguracja standardowa ma być aktualizowana po wydaniu nowych wersji, powinni to zrobić programiści zawsze o tym pamiętaj i podjąć kroki ułatwiające aktualizację. Zawsze powinieneś wybierać takie 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 wygodniejsza metoda aktualizacji nie będzie miała poważnych wad w obszarze wydajności, zrozumiałości kodu itp.

2. Komentowanie zmian w kodzie:

Absolutnie wszystkie zmiany w kodzie programu modułów wymagają komentarza. Blok wierszy, który uległ zmianie, musi być otoczony wierszami komentarza o specjalnym formacie. Zasadę tworzenia tych linii pokazano na przykładzie:

//++ VION 20.07.2016 0001234 Finalizacja na starcie //-- VION 20.07.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 kodu pojawia się w wynikach wyszukiwania globalnego po numerze zadania tylko raz
  • Ulepszenia na początek— dowolny komentarz, stosowany w razie potrzeby, ale w przypadku braku numeru zadania wymagane jest krótkie objaśnienie

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

Obramowujące komentarze są wyrównane do lewej krawędzi edytowanego bloku kodu. Poniższe przykłady pokazują, jak korzystać z komentowania zmian:

2.1 Wstawianie kodu

Przykład:

Procedura przy otwieraniu() Jeśli jest to nowy(), to wypełnij pola domyślnie(); koniecJeśli; UstawElementyForm(); //++ VION 20.07.2016 0001234 Skonfiguruj elementy dodatkowe(); //-- VION 20.07.2016 SetFieldVisibility (); Zakończ procedurę

2.2 Usuwanie kodu

Przykład:

Procedura OnOpen() //++ VION 20.07.2016 0001234 //Jeśli to jest nowe() To // Wypełnij pola domyślne(); //KoniecJeśli; Skonfiguruj elementy dodatkowe(); //-- VION 20.07.2016 SetFieldVisibility (); Zakończ procedurę

2.3 Modyfikacja istniejącego kodu

Zmieniając istniejący kod, należy najpierw zakomentować stary blok, a następnie napisać nową wersję.

Przykład:

Procedura OnOpen() Jeśli jest to New(), to //++ VION 20.07.2016 000123 //Domyślnie wypełnij pola(); FieldFillSetting = GetFieldFillSetting(); FillFieldsDefaultExtended(SettingFillFields); //-- VION 20.07.2016 EndIf; UstawElementyForm(); UstawWidocznośćPola (); Zakończ procedurę

2.4 Dodawanie procedur i funkcji do modułu

W przypadku dodanych procedur i funkcji oraz przy deklarowaniu zmiennych modułowych obiektów standardowych obowiązuje: dodatkowe zasady formatowanie komentarzy:

  • Komentuje się nie blok dodanych procedur jako całość, ale każdy dodana procedura lub funkcja do osobno.
  • Komentarz otwierający umieszczany jest w linii poprzedzającej nagłówek procedury lub funkcji, natomiast komentarz zamykający na tej samej linii, gdzie jest napisane „Koniec procedury” lub „Koniec procedury”, oddzielone spacją.
  • Komentowanie zmian w ramach istniejących procedur odbywa się za pomocą Główne zasady.

Przykład:

//++ VION 20.07.2016 000123 Zmienna mSettingField Wypełnianie; Procedura ModifyFormProgrammatically () ... ... Zakończ procedurę//-- VION 20.07.2016 //++ VION 20.07.2016 000123 Procedura DateShipmentProcessingSelection () ... ... Zakończ procedurę//-- VION 07.20.2016

Zasada ta umożliwia łatwe przenoszenie zmian w module w ramach „proceduralnego porównania” konfiguracji.

Jeśli umieścisz komentarz zamykający w następnym wierszu:

Następnie podczas „porównania proceduralnego” uwaga ta zostanie uznana za opis kolejnej procedury w tekście, która zostanie uznana za zmienioną.

3. Dodawanie obiektów najwyższego poziomu

Nazwy obiekty najwyższego poziomu, utworzone w konfiguracji, Koniecznie musi zaczynać się od przedrostka Twojej firmy lub przedrostka konkretnego projektu. Z reguły składa się z dwóch lub trzech wielkie litery i podkreśla np AB_. Odpowiednio utworzone obiekty zostaną wywołane AB_Nowy katalog, Rejestracja AB_NewInformation, AB_Nowy dokument itp.

Synonimy (nazwy widoczne dla użytkownika) dodanych obiektów najwyższego poziomu muszą zaczynać się od przedrostka ujętego w nawiasy: (AB). Dzięki temu obiekty te zostaną wizualnie wyróżnione na listach i zgrupowane na początku (co ułatwi zarówno testowanie, jak i użytkowanie).

W komentarzu tworzonego obiektu należy podać nazwę dewelopera, datę i numer zadania, analogicznie do dodawanego kodu, ale bez znaków „++”. Dzięki temu obiekt konfiguracyjny będzie powiązany z zadaniem znalezionym w wyniku wyszukiwania globalnego.

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

Działania deweloperskie: w konfiguracji tworzony jest następujący katalog:

  • Nazwa: AB_Projects
  • Synonim: (AB) Projekty

4. Dodawanie obiektów podrzędnych

Sposób dodawania szczegółów obiektu konfiguracyjnego zależy od tego, do jakiego obiektu konfiguracyjnego dodawana jest właściwość: do obiektu konfiguracyjnego utworzonego przez dostawcę standardowe rozwiązanie(czyli obiekt objęty wsparciem) lub obiekt dodany w ramach bieżącego projektu (czyli posiadający już przedrostek).

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

Obiekty podrzędne dodawane do istniejących (typowych) obiektów konfiguracyjnych muszą być poprzedzone: AB_Dodatkowe rekwizyty, AB_NewTabularPart, Ustawienia AB_FormUser, Faktura AB_LayoutSpecial. Ale jednocześnie powstają synonimy takich podrzędnych obiektów bez prefiksu.

W komentarzu tworzonego obiektu należy podać nazwę dewelopera, datę i numer zadania, na wzór . Dzięki temu obiekt konfiguracji zostanie powiązany z zadaniem i zostanie znaleziony podczas wyszukiwania globalnego.

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

Działania deweloperskie: w konfiguracji tworzony jest następujący atrybut:

  • Nazwa: AB_Projekt
  • synonim: projekt
  • Komentarz: // VION 20.07.2016 000123

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

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

W komentarzu tworzonego obiektu należy podać nazwę dewelopera, datę i numer zadania, na wzór . Dzięki temu obiekt konfiguracyjny będzie powiązany z zadaniem znalezionym w wyszukiwaniu globalnym. Komentarz można pominąć, jeśli detale są tworzone w ramach tego samego zadania, co sam obiekt najwyższego poziomu.

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

Działania deweloperskie: Jeżeli zadanie jest inne niż to, w którym utworzono katalog „(AB)Projekty”, to w konfiguracji tworzone są następujące szczegóły:

  • Nazwa: Odpowiedzialny
  • synonim: odpowiedzialny
  • Komentarz: // VION 20.07.2016 000456

5. Dodawanie predefiniowanych elementów

Dodając predefiniowane elementy ksiąg referencyjnych, planów typów charakterystycznych i planów kont należy stosować te same zasady, co przy dodawaniu obiektów podrzędnych ( części tabelaryczne, szczegóły) w obiekty najwyższego poziomu.

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

Niezbędne jest dodanie predefiniowanych elementów dla typowych obiektów konfiguracyjnych z przedrostkiem. Nazwa jest określona bez prefiksu.

Przykład: Dodaj predefiniowane konto 10.15 do planu kont „Rachunek kosztów” – Ścisłe formularze raportowania.

Działania deweloperskie: Dodaj następujące predefiniowane konto:

  • Nazwa: AB_FormsStrictReporting
  • Kod: 10.15
  • Nazwa: Ścisłe formularze raportowania

Jeśli zachodzi potrzeba zmiany nazwy predefiniowanego elementu typowego obiektu konfiguracyjnego (na przykład faktury), należy pozostawić sam obiekt bez zmian, a zmianę nazwy przeprowadzić programowo w specjalnym pliku .

5.2 Dodawanie predefiniowanych elementów do obiektów dodanych w projekcie

Elementy predefiniowane dodawane są do obiektów konfiguracyjnych dodanych w ramach projektu, czyli posiadających już przedrostek w nazwie bez prefiksu w imieniu i tytule.

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

Procedury i funkcje wielokrotnie wykorzystywane w konfiguracji, procesory do subskrypcji i zadań rutynowych znajdują się we wspólnych modułach. W tym celu należy dodać własne moduły, dodane przez obiekty najwyższego poziomu, pozostawiając standardowe moduły niezmienione. Podczas programowania przydatne będą następujące moduły ogólne („AB_” to przedrostek):

  • AB_Ogólny cel (klient, serwer, połączenie zewnętrzne) - aby uwzględnić wspólne procedury i funkcje.
  • AB_serwer (tylko serwer) - dla procedur i funkcji, które muszą być wykonane w środowisku serwerowym.
  • AB_Globalny - dla procedur i funkcji, których wywoływanie w standardowy sposób jest niewygodne (poprzez nazwę modułu i kropkę).
  • AB_Uprzywilejowany - dla procedur i funkcji, które zawsze muszą być wykonywane z pełnymi uprawnieniami.
  • AB_Użyj ponownie - do buforowania wartości zwracanych przez niektóre funkcje.

Możesz umieścić kod bloków funkcjonalnych w oddzielnych wspólnych modułach duża objętość w tym przypadku debugowanie takiego kodu jest uproszczone w przypadku korzystania z magazynu konfiguracji. W innych przypadkach programista powinien upewnić się, że odpowiedni wspólny moduł jest dostępny przed dodaniem nowego modułu do konfiguracji.

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

Aby obsłużyć różne zdarzenia związane ze standardowymi obiektami konfiguracyjnymi, zamiast w miarę możliwości dokonywać modyfikacji w modułach samych obiektów, należy skorzystać z mechanizmu subskrypcji.

Dla każdego zdarzenia może być nie więcej niż jeden abonament(jako obiekt metadanych), w którym należy umieścić procedurę obsługi i powiązany kod oddzielny wspólny moduł(w celu zwiększenia równoległości pracy programistów z pamięcią masową). Nazwa subskrypcji i wspólna nazwa modułu muszą być są takie same I korespondować 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 podprocedur wykonujących wymagane akcje. Dostęp do nich jest możliwy w zależności od rodzaju źródła i w wymaganej kolejności. Odbywa się komentowanie w module subskrypcji podczas dodawania kodu dla nowych zadań.

Przykład: Przy księgowaniu dokumentu „Zaliczka” dokonaj wpisów w rejestrze akumulacyjnym „(AB) Koszty Projektu”.

Działania deweloperskie:

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

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

3. W module utwórz procedurę eksportu „ProcessingProcessing”. Wybierz tę procedurę jako procedurę obsługi wcześniej 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 standardowych obiektów

Jeśli zmiana w standardowym formularzu (zarówno zwykłym, jak i zarządzanym) jest niewielka (np. dodanie kilku nowych szczegółów do formularza), to taką zmianę należy przeprowadzić całkowicie programowo. Oznacza to, że zmiany wprowadzane są tylko w moduł formularza, a sam formularz pozostaje w konfiguratorze niezmienione. Niektórzy programiści mogą początkowo uznać tę metodę edycji formularzy za dość uciążliwą. Mając jednak wystarczające doświadczenie w programowo zmieniających się formularzach, dodanie jednego elementu zajmie nie więcej niż 3-5 minut. Poświęcony czas procentuje wielokrotnie przy kolejnych aktualizacjach standardowej konfiguracji.

Przykład: Na formularzu głównym dokumentu „Zaliczka” dodaj szczegół „Projekt (AB)”.

Działania deweloperskie: W procedurze obsługi formularza „When CreatedOnServer” dodaj procedurę „EditFormProgrammatically()”. W tej procedurze dodaj żądany element do elementów formularza.

Istnieje możliwość stworzenia osobnego modułu, który będzie zawierał wszystkie niezbędne procedury i funkcje umożliwiające zmianę standardowych formularzy.

W typowych konfiguracjach opartych na BSP 2 istnieje już specjalna funkcjonalność służąca tym celom:

W procedurze „When CreateOnServer” modułu ogólnego „Modyfikacja konfiguracji zastąpiona” możesz wywołać własny moduł obsługi.

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

Jeśli planujesz dodać do formularza duża ilość elementów lub części tabelarycznych, możliwe jest również ręczne przekształcanie. W takim przypadku zaleca się utworzenie osobnej zakładki na formularzu i umieszczenie na niej wszystkich niezbędnych elementów. Dzięki temu przyszłe aktualizacje formularzy będą znacznie łatwiejsze.

8.2 Edycja kształtów obiektów dodanych w ramach projektu

Kształty obiektów dodanych w ramach projektu (czyli tych, które mają przedrostek w nazwie) edytowane są w zwykły sposób.

9. Zasady pracy z rolami

Role ogólne należy zawsze pozostawić niezmienione (jeśli to możliwe). Jest to konieczne, aby ułatwić aktualizację zmienionej konfiguracji z nowych wersji, ponieważ porównywanie i przywracanie ról to złożony i żmudny proces.

Należy nadać uprawnienia do obiektów dodanych do konfiguracji w nowym role stworzone w tym celu.

Należy wdrożyć odmowy dostępu do danych dozwolone przez typowe role programowo, póki jest to możliwe. I dopiero wtedy, gdy taki zakaz byłby bardzo trudny do programowego wdrożenia (lub takie rozwiązanie byłoby zawodne), dopuszczalna jest modyfikacja standardowych ról. Zmiany w typowych rolach powinny stanowić niezbędne i udokumentowane minimum. Na przykład, jeśli chcesz zmienić tekst ograniczeń dostępu w roli (RLS), to zgodnie z , powinieneś zakomentować cały przykładowy kod, a następnie dodać kod z niezbędnymi zmianami.

10. Zewnętrzne raporty i przetwarzanie

Większość usprawnień w systemie można wprowadzić korzystając z mechanizmu Dodatkowych raportów i przetwarzania.

W konfiguracjach opartych na BSP 2 (ERP, UT 11, BP 3.0, ZUP 3.0 itp.) mechanizm ten jest znacznie rozbudowany. Za jego pomocą, bez zmiany konfiguracji, możliwe jest tworzenie zewnętrznych raportów i przetwarzanie (z umieszczeniem polecenia uruchomienia w interfejsie poleceń i możliwością konfiguracji dostępu dla różnych użytkowników), przetwarzanie wypełniania dokumentu, przetwarzanie tworzenie dokumentu na podstawie dodatkowych drukowanych formularzy itp.

Czy ten artykuł był pomocny?

1C 8.2 i 8.3 ma bardzo znaczące przewaga konkurencyjna— możliwość udoskonalenia standardowych konfiguracji 1C i opracowania własnych rozwiązań w oparciu o platformę. Osiąga się to dzięki wbudowanemu środowisku programistycznemu;

Firma 1C w trosce o swoich klientów stara się produkować rozwiązania, które najlepiej będą odpowiadać wszystkim organizacjom na rynku. Każda firma, podobnie jak człowiek, jest wyjątkowa. Jest to swego rodzaju „dostrojenie” konfiguracji 1C do własnych potrzeb.

Jakie nowe rzeczy są zwykle robione w 1C?

Z reguły modyfikacje dotyczą części interfejsowej programu. Jednak są też poważne modyfikacje w konfiguracjach – wprowadzenie nowych podsystemów, nowych algorytmów.

Przykłady zmian w 1C 8.3:

  • Konfigurowanie uprawnień użytkownika i wartości domyślne. Elastyczna konfiguracja uprawnień - bardzo ważny punkt. Użytkownicy i ich uprawnienia to coś, bez czego nie da się pracować w żadnym systemie wieloużytkownikowym.
  • Zmiana i tworzenie nowego drukowane formularze. Wydrukowany formularz jest papierowym odpowiednikiem dokumentu w 1C. Możliwe jest zarówno udoskonalenie istniejących, jak i dodanie nowych. Edycję wydrukowanych formularzy można przeprowadzić bez zmiany konfiguracji.
  • Tworzenie nowych i modyfikacja istniejących raporty. Raport jest produktem końcowym każdej analizy System informacyjny, w tym 1C Enterprise. Raporty w programie można modyfikować bez zmiany konfiguracji.
  • . Z reguły klient bez wiedzy technicznej nie zawsze może napisać kompetentne specyfikacje techniczne dla programistów. Jednocześnie samo zadanie może zostać wykonane samodzielnie lub przez firmy zewnętrzne.
  • Dodawanie do konfiguracji nowa funkcjonalność. 1C jest systemem uniwersalnym i nie może uwzględniać życzeń każdego klienta. Kompetentni specjaliści są w stanie znacznie rozszerzyć funkcjonalność programu i zintegrować go „płynnie”.
  • Optymalizacja wydajności 1C. System 1C Enterprise jest jednym z liderów w swoim segmencie pod względem wydajności. Jednak uzyskać maksymalna prędkość Aby system działał, wymagane są pewne zmiany, które są dostosowywane do infrastruktury informatycznej Klienta.

Cena za godzinę pracy specjalisty 1C

Koszt pracy związanej z modyfikacją standardowych konfiguracji 1C jest zwykle szacowany w roboczogodzinach.

Cóż, wszyscy inni, witajcie w kocie.

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

Kiedy więc realizujemy projekt (przez „My” mam na myśli wszystkich ludzi zajmujących się automatyzacją procesów biznesowych), mamy nadzieję, że następnie sprawnie 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 konsultacyjne typu „skąd wzięły się te liczby”, czy poprawienie niezrozumiałych błędów itp. Ponieważ jednak prawie wszystkie projekty polegają na dostosowaniu jakiegoś standardowego rozwiązania do potrzeb klienta, konfiguracja ze wsparciem musi być okresowo aktualizowana do nowych wersji:

  • Jeśli zastosujesz się do pewnych zasad programowania, po wydaniu bardzo małej ilości pracy na etapie projektu, w przyszłości możesz zaoszczędzić na utrzymaniu i aktualizacji konfiguracji.
  • I odwrotnie, jeśli na etapie projektu wystąpiły błędy, pośpiech lub nieprawidłowe formatowanie kodu, to później może to skutkować prawdziwym piekłem wsparcia i aktualizacji.

Czy ktoś kiedykolwiek musiał aktualizować konfigurację, która została przepisana bez żadnych znaków identyfikacyjnych? Czy rozumiesz, jak trudne jest porównywanie konfiguracji starego dostawcy z nową konfiguracją, ręczne analizowanie każdego przypadku „dwukrotnej zmiany” przy porównaniu z bieżącą konfiguracją itp. To wszystko jest dość problematyczne.

9 prostych zasad projektowania modyfikacji w standardowych konfiguracjach

1. Koncepcja minimalizacji „zniszczenia” konfiguracji standardowej

To pierwsze nie jest nawet regułą, jest rodzajem koncepcji minimalizacji „zniszczenia” standardowej konfiguracji.

Jej istotą jest to, że zawsze należy wybierać takie metody rozwiązywania problemów, które pozwolą w przyszłości łatwiej dokonać aktualizacji konfiguracji, nawet jeśli takie rozwiązanie będzie nieco trudniejsze do wdrożenia. Oczywiste jest, że należy to zrobić bez fanatyzmu, w rozsądnych granicach, jednak programista musi zawsze pamiętać, że konfiguracja pozostaje w ramach wsparcia i przeanalizować, jak bardzo jego kod skomplikuje aktualizację konfiguracji w przyszłości, wybierając najodpowiedniejsze rozwiązanie.

2. Komentowanie zmian w kodzie

Druga zasada jest taka, że ​​l każda zmiana kodu musi zostać skomentowana.

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 końcowy(zaczyna się od znaków //-- )
  • A zmiany wprowadzone przez programistę znajdują się pośrodku.

Jest to zasada obowiązująca przy wszelkich zmianach.

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

  • Przedrostek projektu- domyślnie używamy FTO
  • Nazwa domeny dewelopera. Tworzy się go bardzo wygodnie: firma jest duża, rozproszona i jeśli nie znasz programisty, ale musisz go o coś zapytać, możesz wziąć jego pseudonim z tego tagu, umieścić @fto.com.ru na prawo i wyślij mu list, aby w ten sposób się z nim skontaktować.
  • Następny przychodzi data modyfikacji. Gdy zmiany zachodzą w ramach kilku zadań, te wiązki komentarzy można zagnieździć w sobie i nie zawsze jest jasne, do którego bloku otwierającego należy dany komentarz zamykający, dlatego skupiamy się na dacie. Dodatkowo na dacie od razu widać, kiedy dokonano modyfikacji: trzy lata temu, pół roku temu czy wczoraj.
  • Potem przychodzi numer zadania, Który jest umieszczony jedynie w komentarzu otwierającym. Dlaczego tylko tam? Aby podczas globalnego wyszukiwania według numeru zadania, w wyborze uwzględniany był tylko początek zmian kodu, z którego można następnie spojrzeć w dół, w przeciwnym razie wystąpią dublety. Na przykład, przesyłając zadanie do przeglądu kodu, bardzo wygodnie jest wyszukiwać konkretnie według tagu.

Przykłady

Tak to wygląda Wprowadź kod:

Tak to wygląda usuwanie kodu- nie usuwamy kodu całkowicie, komentujemy kod. Dzięki temu zawsze możesz zobaczyć, co zostało skomentowane, a jeśli coś się stanie, możesz szybko wrócić.

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

Działa odrębna zasada aby dodać procedury, funkcje i zmienne modułu globalnego. W tym przypadku komentarz zamykający jest umieszczony w tej samej linii, co słowo kluczowe Zakończ procedurę. Dlaczego to zrobiono? Aby ułatwić przenoszenie modyfikacji za pomocą „porównania proceduralnego”.

Tutaj na zdjęciu możecie to zobaczyć używając „porównania proceduralnego” możesz po prostu zaznaczyć tę procedurę podczas łączenia, i zostanie on całkowicie przeniesiony (wraz ze znakami). Lub odwrotnie, możesz odznaczyć pole obok, aby go nie przenosić.

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

3. Dodawanie obiektów najwyższego poziomu

Kolejną zasadą jest dodanie do konfiguracji obiektów najwyższego poziomu (katalogi, dokumenty, rejestry itp.).

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

  • Po pierwsze, wizualnie podkreśla dodany element w konfiguracji i w kodzie od razu widać, że to nasz dodany obiekt.
  • Po drugie, niepowtarzalność nazwy została osiągnięta, ponieważ dostawca może dodać własny obiekt o tej samej nazwie. A jeśli użyjemy własnego przedrostka, mamy gwarancję, że nasza nazwa będzie niepowtarzalna.

Synonimy obiektów muszą zaczynać się od przedrostka w nawiasach. Dzięki temu możemy podświetlić dodany obiekt w interfejsie.

Oczywiście jest to bardzo kontrowersyjna zasada i jego użycie należy uzgodnić z klientem. Nasi klienci byli zadowoleni z tego schematu, więc zakorzenił się u nas i stał się częścią zasad. Ale tutaj to ty i klient decydujecie, czy powinniście to zrobić, czy nie.

No i ostatnia zasada: komentarze do wszystkich dodanych obiektów muszą zawierać specjalną etykietę z nazwą programisty i numerem zadania. Etykieta ta przypomina komentarz otwierający z modułu, tyle że bez znaków specjalnych - przy jej pomocy zawsze mogę zrozumieć kto, kiedy i w jakim celu dodał ten obiekt.

Podsumowując:

  • Nazwy są podawane z przedrostkiem,
  • Synonimy - z przedrostkiem w nawiasach
  • A komentarz musi zawierać specjalny tag.

4. Dodawanie obiektów podrzędnych

Przez dodanie podobiektów mam na myśli dodanie rekwizytów, układów, formularzy itp. w obiekty konfiguracyjne.

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

  • W typowym obiekcie konfiguracyjnym
  • Lub do jakiegoś obiektu, który został dodany wcześniej w ramach projektu.

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

Aby dodać obiekty podrzędne do standardowych obiektów konfiguracyjnych Obowiązują poniższe zasady.

  • Nazwy muszą zaczynać się od tego samego przedrostka. Dzięki temu osiągamy niepowtarzalność nazwy i wizualnie też zawsze jest jasne, że to jest nasz obiekt.

  • Synonim jest wypełniany bez przedrostka, bo tutaj nie ma już potrzeby podkreślania naszych obiektów, naszych detali.

  • I w końcu, komentarz zawiera również specjalny tag, aby było jasne, kto, kiedy i dlaczego.

Podsumujmy zatem, jak działa dodawanie obiektów podrzędnych do typowych obiektów konfiguracyjnych:

  • Nazwy są podawane z przedrostkiem,
  • Synonimy według ogólnych zasad
  • Komentarze zawierają specjalną etykietę.

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

  • Ich nazwy nie mogą zawierać przedrostka, bo wiadomo już, że obiekt jest już wyjątkowy i nie ma potrzeby specjalnie go w inny sposób podkreślać.

  • Synonimy dla takich obiektów podrzędnych są również podawane bez przedrostka, ponieważ nie jest wymagana żadna specjalna selekcja.

  • A komentarz zawiera specjalną etykietę tylko wtedy, gdy ten obiekt podrzędny został dodany w ramach innego zadania. Bo jeśli moje zadanie mówi, że muszę dodać dokument, który zawiera takie a takie szczegóły, to nie muszę przy każdym szczególe umieszczać takiej etykiety. Ale jeśli zadanie jest zupełnie inne, pamiętaj o zaznaczeniu, aby było jasne, dlaczego to zrobiłem.

Podsumujmy teraz sposób dodawania obiektów podrzędnych do obiektów dodanych w ramach projektu:

  • Imiona bez przedrostka.
  • Synonimy bez przedrostka.
  • Komentarze powinny zawierać specjalną etykietę tylko wtedy, gdy są dodawane w ramach innego zadania.

Jeśli połączymy tę regułę dla obu przypadków i „rozłożymy ją na kawałki”, otrzymamy następującą tabelę:

  • Nowe obiekty:
    • Nazwa zaczyna się od przedrostka.
    • Synonimy - z przedrostkiem w nawiasach.
    • Komentarz zawiera etykietę.
  • Obiekty podrzędne, które dodajemy do obiektów ogólnych:
    • Imiona zaczynają się od przedrostka,
    • Synonim według ogólnych zasad
    • Wstaw tag w komentarzu.
  • A jeśli do obiektów dodanych w projekcie dodamy obiekty podrzędne, to
    • Nie ma dla nich specjalnych zasad,
    • Jeśli jednak zadanie jest inne, to w ten sam sposób umieszczamy tag w komentarzu.

5. Dodawanie predefiniowanych elementów

Kolejną zasadą jest dodawanie predefiniowanych elementów.

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

  • Gdy dodamy predefiniowany element do typowego obiektu konfiguracyjnego (do podręcznika, do planu typów charakterystyk)
  • A kiedy dodanego w projekcie obiektu dodamy predefiniowany element.

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

  • Jego Nazwa podobny musi zaczynać się od przedrostka. Tym samym gwarantujemy niepowtarzalność jego nazwy i będziemy w stanie od razu wizualnie zidentyfikować dodany przez nas element.
  • Kod i nazwa zostanie uformowany według ogólnych zasad,
  • Ale etykieta tutaj, niestety, nie ma gdzie tego umieścić. Dlatego nie będzie możliwe znalezienie tego dodanego predefiniowanego elementu za pomocą globalnego wyszukiwania zadań.

A jeśli do obiektów dodanych w ramach projektu dodamy predefiniowane elementy, To

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

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

  • Predefiniowane elementy obiektów ogólnych dodawane są 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 stosowania wspólnych modułów i organizacji dla nich ścisłej struktury.

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

Po drugie, proszę o tym pamiętać wspólne moduły dodawane są zgodnie z zasadami dodawania obiektów najwyższego poziomu(nazwa i synonim z przedrostkiem, tag w komentarzu itp.)

Trzeci, nazwy modułów muszą być podobne do odpowiednich modułów standardowych.

Nie ma potrzeby wymyślania koła na nowo: nazywamy to tak samo, jak jest to zwyczajowo w standardowych konfiguracjach - dla każdej funkcjonalności własny moduł, odpowiadający ogólnie przyjętym oznaczeniom w 1C. Na przykład:

  • FTO_Klient ogólnego przeznaczenia,
  • FTO_Serwer ogólnego przeznaczenia,
  • FTO_Ogólnego przeznaczenia Globalny,
  • Serwer FTO_RoutineTasks
  • Itp.

A niektóre duże zadania indywidualne możesz (i prawdopodobnie powinieneś) umieścić w oddzielnych wspólnych modułach.


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

Kolejną zasadą jest korzystanie z subskrypcji i ich ścisła struktura. Jaka jest jego istota?

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

  • Przed nagraniem
  • Podczas nagrywania
  • Itp.

  • Oczywiście, że możesz wziąć edytować standardowy moduł obiektowy, wstawiając swój kod do odpowiedniej procedury. Ale to - zła droga.
  • Lepsza zamiast tego dodaj subskrypcję, aby przetworzyć to wydarzenie.

Subskrypcja dodawana jest według następujących ustalonych zasad:

  1. Na wszystkie zdarzenia tego samego typu w systemie dodawany jest tylko jeden abonament. Przykładowo, jeśli muszę zastosować własny algorytm dla różnych katalogów w zdarzeniu „Przed zapisaniem katalogu”, to dla wszystkich tych katalogów korzystam tylko z jednej dodanej subskrypcji „Przed zapisaniem katalogu”.
  2. Źródło wybiera wszystkie obiekty w tej klasie(na przykład wszystkie katalogi)
  3. Dla dodanej subskrypcji tworzony jest osobny moduł, który nazywa się dokładnie tak samo(tylko dla wygody).
  4. W głównym programie obsługi zdarzeń zdefiniowany jest warunek analizujący typ obiektu(rodzaj katalogu).
  5. I już W zależności od rodzaju obiektu wykonywane są określone czynności.

Mogę pokazać na przykładzie. Załóżmy, że jest takie zadanie: księgując dokument „Raport zaliczkowy”, dokonaj wpisów we wcześniej dodanym rejestrze akumulacji.

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

  • Jako źródło podajemy DocumentObject (wszystkie dokumenty);
  • Nasz moduł dodany powyżej służy jako moduł obsługi.

I już w module, w samym handlerze ustalamy, jaki dokument do nas przyszedł i w zależności od jego rodzaju wywołujemy taką lub inną procedurę.

Jest jedna subskrypcja, ale działania mogą być inne. T Można 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ł dokumentów pozostaje niezmieniony - nie będzie już pojawiał się w „dwukrotnie zmienianych”.


8. Edycja formularzy

Następną zasadą jest edycja formularzy.

Tutaj podkreślimy dwa punkty, dwie sytuacje:

  • Kiedy edytujemy standardowe formularze;
  • Oraz kiedy edytujemy formularze dodane w ramach projektu.

Pierwsza sytuacja to edycja standardowe formularze, formy typowych obiektów. To najbardziej kontrowersyjny punkt regulaminu. Kiedyś, w czasach konwencjonalnych formularzy, kiedy projekty wykonywano głównie na UPP, odbyliśmy wiele dyskusji na temat tego, co zrobić z formularzami. Jakie były opcje?

  • Bezpośrednia edycja zwykłych formularzy polega na tym, że po prostu zmieniam kształt ręcznie. Dzięki tej opcji za każdym razem, gdy dostawca wprowadza zmiany w tym formularzu, muszę ponownie przenieść wszystkie moje zmiany. Zła droga.
  • Innym sposobem jest utworzenie kopii formularza. To wtedy robię kopię standardowego formularza, wyznaczam go jako główny i wprowadzam w nim zmiany. Ale znowu, jeśli dostawca zmieni ten formularz, muszę ręcznie przenieść jego zmiany do mojej wersji. Nie jest to najlepszy sposób.
  • Inną opcją jest utworzenie osobnej zakładki. Tworzymy osobną zakładkę na formularzu i umieszczamy na niej nasze elementy. Oczywiste jest, że ta metoda nie jest elastyczna, ponieważ czasami trzeba wstawić element w określonym miejscu formularza. Lub musisz zmienić właściwości standardowych elementów, przypisać do nich nową procedurę obsługi itp. Dlatego to niezbyt elastyczny sposób- to też nie działa zbyt dobrze.
  • W rezultacie wybraliśmy metodę całkowicie programowej edycji formularzy. Nowi programiści, którzy na początku nie zetknęli się z tą metodą, mają trudności z programową edycją formularza. Ale w rzeczywistości - nie. Z własnego doświadczenia powiem, że trzeba to po prostu poprawić. Dodatkowo mamy już dawno napisane moduły z procedurami eksportu dla programowo zmieniających się formularzy, a wszystko to odbywa się w miarę łatwo. Kiedy pojawiły się formularze zarządzane, całkowicie przenieśliśmy tę praktykę programowego zmieniania formularzy do formularzy zarządzanych. Poza tym redakcja kontrolowana forma Programowanie stało się w zasadzie proste – nie da się go porównać z formami konwencjonalnymi.

Pokażę ci na przykładzie. W procedurze obsługi OnCreationOnServer dodaję wywołanie mojej procedury EditFormProgrammatically, gdzie programowo dodaję elementy do formularza.

W konfiguracjach opartych na BSP 2(takich jak ERP, księgowość itp.) dodano Procedura obsługi zdarzeńForm.WhenCreatedOnServer(), które m.in. wchodzi Również do nadpisywanego modułu.

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

Wydaje się, że jest to trudne, że ten schemat jest uciążliwy, ale w rzeczywistości, jeśli wszystkie projekty są wykonywane według tych zasad, to programista, otrzymując zadanie, od razu wie, gdzie szukać, gdzie co dodać. Dlatego uważam, że jest to bardzo wygodne.

Dodatkowo w konfiguracjach opartych na BSP 2 przedefiniowano inne procedury obsługi formularzy - takie jak When ReadingOnServer(), BeforeWritingOnServer() itp. W tych programach obsługi możesz także aktywnie używać przesłaniania wywoływanych procedur. Co więcej, moduł przedefiniowany przez dostawcę teoretycznie się nie zmienia i można w nim napisać własny kod bez obawy o konflikty.

Jeśli edytujemy formularz dodany w ramach projektu, to nie musimy nic szczególnego robić, edytujemy go w zwykły sposób, ręcznie.

9. Zasady pracy z rolami

I ostatnia zasada to zasady pracy z rolami.

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

  1. Jeśli to możliwe, to typowe role powinny zawsze pozostać bez nazwy. Musisz dokładnie przemyśleć, czy naprawdę konieczna jest zmiana typowej roli, czy też możesz zrobić coś inaczej.
  2. Przypisujemy uprawnienia do dodanych obiektów konfiguracyjnych w nowych, specjalnie stworzonych rolach. Dlatego też, gdy dodaję do konfiguracji raport, a nie ma dla niego odpowiedniej roli, którą wcześniej dodaliśmy, tworzę osobną rolę. Następnie ta rola jest dodawana do wymaganych profili. Ale typowe role się nie zmieniają.
  3. I jeśli nastąpią zmianyRLS, wówczas są one formatowane zgodnie z zasadami edycji modułów.

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

Wymieniłem więc wszystkie dziewięć proste zasady rejestracja modyfikacji.

Dodatkowe obiekty i techniki ułatwiające życie

Na koniec omówię kilka obiektów i technik, które mogą ułatwić życie programisty.

1. Samoidentyfikacja baz testowych

Pierwszą techniką jest samoidentyfikacja testowych baz danych.

Chodzi o to:

  • istnieje pewna stała, która przechowuje adres działającej produktywnej bazy danych.
  • Podczas uruchamiania systemu adres ten jest sprawdzany: czy pasuje do działającego adresu bazowego, czy nie.
  • I jeśli to nie pasuje(baza nie działa), następnie Nagłówek systemowy jest wymieniany.

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ą przypadkowo popełnić błąd i zmienić dane w działającej bazie danych. A jeśli tytuł zostanie zmieniony, to „automatycznie” - spójrz w lewy górny róg, zobacz, jaka to baza danych - tak, przetestuj, możesz to zmienić.

W ten sposób zwiększamy bezpieczeństwo zmieniających się danych w bazach danych.

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

  • wymiana danych,
  • powiadomienia użytkowników,
  • jakieś mailingi
  • ciężkie zadania regulacyjne.
  • Itp.

Kiedy programista tworzy takie rutynowe zadanie, musi sprawdzić, czy jest to baza robocza, czy nie. Oczywiste jest, że teoretycznie we wszystkich testowych bazach danych rutynowe zadania powinny być wyłączone w konsoli klastra. Ale gdy ktoś stworzył, zawsze występuje czynnik ludzki nowa baza, załadowałem do niego nowe dane, coś zmieniłem i w rezultacie nastąpiła krytyczna wymiana zdań z działającymi bazami danych. A potem rozgrywka – dlaczego tak się stało? Dlatego my przed krytycznym rutynowe zadania Zawsze sprawdzamy, czy jest to działająca baza danych, czy nie.

W konfiguracjach bazujących na BSP 2 występuje podobny mechanizm: jeśli lokalizacja baza informacyjna się zmienia, wówczas 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 czynnik ludzki może przeszkodzić, ktoś nie zrozumie, co się dzieje i naciśnie niewłaściwy przycisk. Dlatego, moim zdaniem stała jest bardziej niezawodna.

2. Przetwarzanie inicjujące

Następną sztuczką jest przetwarzanie inicjujące.

  • Jest to przetwarzanie dodane do konfiguracji, które zawiera w swoim kodzie jego aktualną wersję.
  • Jednocześnie do konfiguracji dodawana jest również pewna stała, która przechowuje aktualną wersję przetwarzania inicjującego.
  • Po uruchomieniu systemu przeprowadzana jest kontrola,
  • Jeżeli wersja uległa zmianie, wykonywane są niezbędne procedury obsługi i ustawiana jest nowa wartość stałej.

Dlaczego jest to konieczne? Często dodając nową funkcjonalność do konfiguracji konieczne jest wykonanie pewnych czynności w samej bazie danych: np. dodałeś predefiniowany element katalogu i teraz musisz uzupełnić jego szczegóły. W projekcie może znajdować się wiele baz danych i ręczne wypełnianie tych danych jest oczywiście złe. Bardziej poprawne:

  • Powiększ wersję przetwarzanie inicjujące;
  • Opisz w kodzie kolejność programowego wypełniania danych;
  • I potem nowa wersja przetwarzania automatycznie przez pamięć przejdzie do wszystkich niezbędnych baz danych, uruchomi się tam i wykona wszystkie niezbędne czynności.

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

  • Uruchomienie systemu
  • Porównanie wersji stałej z wersją przetworzoną.
  • Jeśli to nie pasuje, są przeprowadzane po kolei wszystko, co konieczne obsługi,
  • Ustawia nową wartość stałej.

Dzięki temu wszędzie, we wszystkich bazach dane są aktualizowane.

3. Katalog predefiniowanych wartości

Następną sztuczką jest odwołanie się do predefiniowanych wartości.

Często istnieje potrzeba uzyskania dostępu do istniejących elementów katalogu z kodu, który nie jest predefiniowany. Oczywiste jest, że lepiej jest utworzyć element predefiniowany, ale zdarza się, że elementu nie można predefiniować, ale nadal będzie można uzyskać do niego dostęp.

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

  • Odwołaj się do elementu po nazwie. Oczywiste jest, że nazwa się zmieniła - kod przestał działać. Źle.
  • Kontakt poprzez kod. Trochę lepiej, ale kod też może się zmienić. Niezbyt dobrze.
  • Kontakt poprzez identyfikator wewnętrzny. Następnie podczas przesyłania 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 predefiniowanych wartości.

Katalog ten zawiera tylko jeden atrybut typu DirectoryLink(link do wszystkich podręczników).

Jeżeli w ramach zadania muszę odwołać się do jakiegoś elementu, dodaję do tej książeczki predefiniowany element (np. Counterparty_Agroimpulse)

Następnie albo w kodzie przetwarzania inicjalizacji, albo ręcznie, wypełniam wartość tego katalogu potrzebnym kontrahentem.

Odpowiednio po tym Mogę skontaktować się z tym kontrahentem poprzez katalog predefiniowanych wartości. Dzięki temu osiąga się:

  • Podczas przenoszenia modyfikacji pomiędzy różne podstawy wszystko moje kod działa bez żadnych dodatkowych modyfikacji.
  • Poza tym jest możliwe, że dzisiaj tym kontrahentem będzie Agroimpulse, a jutro będzie to inna organizacja, ale ja nie muszę nic modyfikować w konfiguracji, po prostu idę i zmieniam jego wartość w katalogu z predefiniowanymi wartościami.

4. Wyświetl tabele tymczasowe w debugerze

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

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

  • I nazwa jakoś krótki, na przykład VT()

W tym przypadku:

  • I Ustawiłem punkt przerwania w miejscu, w którym mam prośbę.
  • W oknie „Oblicz wyrażenie” piszę VT (Zapytanie);
  • Klikam „Oblicz” i Otrzymuję strukturę tymczasowych tabel zapytań aby zobaczyć, jakie dane się tam znajdują.

Jest to bardzo wygodna funkcja, korzystamy z niej cały czas. Zwłaszcza przy kalkulacji kosztów, czy w konfiguracjach takich jak ZUP. Szczerze mówiąc, nie rozumiem, jak inni mogą bez niej żyć.

W najnowszej wersji platformy pojawiła się wbudowane narzędzie co pozwala przeglądać tabele tymczasowe, ale myślę, że tak niezbyt wygodne. Korzystanie z własnej funkcji jest znacznie lepsze.

Wniosek

Dziękuje za wszystko. Mam małą stronę internetową, na tej stronie wszystkie te zasady i wiele innych są szczegółowo określone - wejdź, przeczytaj, napisz do mnie e-mailem lub na Skype.

Ten temat jest dla mnie interesujący, jestem gotowy go omówić. Jest dla mnie bardzo ważne, żeby Tobie też wszystko się ułożyło.

Dowolny, nawet mała organizacja ma swój własny zestaw procesów biznesowych. Aby efektywnie pracować i otrzymywać najwyższy zysk duże procesy biznesowe wymagają automatyzacji. Programy 1C doskonale radzą sobie z tą funkcją. Ale niestety nie ma programów idealnych, tak jak każdy człowiek ma swoje własne wyobrażenia o doskonałości. Programista 1C może pomóc Ci ulepszyć Twój program. Po zmodyfikowaniu standardowego 1C otrzymasz program, który w pełni odpowiada Twoim pomysłom i potrzebom.

Wersja 1C- zestaw działań umożliwiających konfigurację i modernizację programów 1C pod kątem potrzeb Twojego przedsiębiorstwa.

Jak aktualizujemy programy 1C

Aby osiągnąć idealny wynik, gdy klient otrzyma dokładnie to, co zamierzał finalizując programy 1C, oferujemy następujący schemat pracy:

  1. klient raportuje informacje o zainstalowanych;
  2. klient wprowadza naszego specjalistę w podstawowe zasady pracy swojej organizacji, komunikuje istotę problemu, opisuje, co dokładnie chciałby ulepszyć;
  3. Do klienta przydzielany jest programista 1C, który będzie z nim współpracował przez cały czas współpracy z naszą firmą i będzie świadomy wszystkich cech rozliczania biznesu klienta. Osobisty programista 1C będzie w pełni odpowiedzialny za wykonanie wdrożonych ulepszeń;
  4. sporządzane są specyfikacje techniczne. Na podstawie otrzymanych informacji nasi programiści 1C wyciągną niezbędne wnioski i zaproponują opcje rozwiązania problemu poprzez modyfikacje lub wprowadzenie zmian w 1C;
  5. uzgodniono koszty czasu i pieniędzy na sfinalizowanie 1C;
  6. prace uzgodnione z klientem są realizowane;
  7. Wyniki pracy są testowane i dostarczane do klienta.

Najczęstsze modyfikacje 1C

Poniżej wymieniamy szczególnie popularne ulepszenia w programach 1C:

  • Tworzenie katalogów i szczegółów. kreacja dodatkowe miejsca przechowywanie informacji, takich jak numery samochodów
  • Udoskonalanie lub rozwój nowych form drukarskich. Zmiana wygląd rachunki, faktury i inne drukowane formy dokumentów zgodnie z wymaganiami Twojej organizacji.
  • Twórz nowe lub modyfikuj istniejące raporty. Twórz dodatkowe lub edytuj istniejące raporty dla księgowych, menedżerów lub dyrektorów firm.
  • Ustawianie praw dostępu. Ograniczanie lub rozszerzanie dostępu użytkowników do informacji w bazie danych.
  • Rozwój terapii. Tworzenie przetwarzania w celu uproszczenia systemów wprowadzania informacji, analizy działań przedsiębiorstwa, automatycznie wykonywanych funkcji, np. wydruku pakietu dokumentów lub pobrania informacji z pliku Excel (*.xls).
  • Konfigurowanie wymiany 1C. Import/eksport danych z jednego programu 1C do drugiego.
  • Konsultacje z użytkownikami 1C. Wyjaśnienie lub przeszkolenie użytkowników w zakresie pracy z wprowadzonymi ulepszeniami.
  • Aktualizacja zmienionych konfiguracji. Aktualizujemy konfiguracje zmienione zarówno przez naszych, jak i zewnętrznych programistów 1C.

Zalety powierzenia nam ulepszeń w 1C

Powodów, dla których zlecanie modyfikacji w naszej firmie jest opłacalne jest kilka:

  • Wysoka jakość. Nasi programiści 1C to wysoko wykwalifikowani specjaliści, co potwierdzają odpowiednie certyfikaty 1C.
  • Niska cena. Nasza firma jest mała, ale szybko się rozwija, eliminujemy pośredników między klientem a programistą, dzięki temu udaje nam się utrzymać koszty usług 1C na niskim poziomie, od 1000 rubli. za godzinę pracy specjalistycznej.
  • Szybkie zakończenie prac. Opóźnianie realizacji Twojego zadania nie jest opłacalne dla naszej firmy. Dlatego masz gwarancję otrzymania wyniku swojej pracy nie później niż w ciągu trzech dni roboczych. Jeśli zadanie jest małe, prawdopodobnie będziesz w stanie uzyskać potrzebną modyfikację w 1C w dniu, w którym się z nim skontaktujesz.
  • 100% gwarancji na wykonanie modyfikacji. Nasza firma gwarantuje funkcjonalność usprawnień wprowadzonych przez naszych pracowników w Państwa programie. W ciągu roku od jego wdrożenia możesz nam zgłosić, czy znajdziesz ukryte wady, a my w możliwie najkrótszym czasie całkowicie bezpłatnie je naprawimy.
  • Pomimo tego, że jesteśmy zlokalizowani geograficznie w Petersburg, Możemy zdalnie wykonać dla Ciebie każdą pracę, niezależnie od tego gdzie na świecie się znajdujesz.