1s, co się zmienia po wyłączeniu trybu zgodności. Zmień lub wyłącz tryb zgodności

W tym artykule przyjrzymy się palecie właściwości konfiguracyjnych na przykładzie 1C Trade Management 11 na platformie 8.3.

Ustawianie właściwości konfiguracyjnych 1C

Przyjrzyjmy się bliżej każdemu z ustawień konfiguracyjnych.

  • Podstawowy tryb uruchamiania— może przyjmować wartości aplikacji zarządzanej lub zwykłej. W przyszłości będzie można to ustawić osobno dla każdego użytkownika.
  • Wbudowana opcja językowa— definiuje domyślną składnię języka programowania. Jeśli to zmienisz, konfiguracja modułów nie zmieni automatycznie języka.
  • Główna rola— rola w konfiguracji domyślnej. Zwykle instalowana jest rola z największymi uprawnieniami.
  • Zarządzany (lub zwykły) moduł aplikacji— moduł opisujący globalne zmienne konfiguracyjne i procedury obsługi konfiguracji globalnej - Przed uruchomieniem systemu, Po uruchomieniu systemu, Przed wyłączeniem systemu, Po wyłączeniu systemu, Przetwarzanie zdarzeń zewnętrznych.
  • Moduł sesji— procedura obsługi działająca podczas uruchamiania systemu, w której zwyczajowo inicjuje się .
  • Zewnętrzny moduł przyłączeniowy - Moduł dostępny poprzez połączenie zewnętrzne zawiera procedury obsługi - Przy wyłączeniu systemu, Przy uruchomieniu systemu.

Uzyskaj 267 lekcji wideo na 1C za darmo:

  • Główny język— domyślny język interfejsu.
  • Szybkie fakty, szczegółowe informacje, logo, ekran powitalny, prawa autorskie— pola informacji o właściwościach dla informacji konfiguracyjnych.
  • Adres informacji o dostawcy i konfiguracji— właściwości, w których należy podać informacje o deweloperze i stronę o tym rozwiązaniu.
  • Główna forma raportu, ustawienia raportu, opcje raportu— formularze, które domyślnie otwierają się dla odpowiednich obiektów.
  • Dostawca- firma, która przeprowadziła rozwój.
  • Wersja- wersja konfiguracji, właściwość powinna prawie zawsze odpowiadać wersji dostawcy.
  • Zaktualizuj adres katalogu— miejsce w Internecie, z którego możesz pobrać najnowsze aktualizacje.
  • informacje referencyjne— ogólne informacje referencyjne na temat konfiguracji. Zaznaczenie Dołącz do treści pomocy dodaje aktualne informacje referencyjne do ogólnej listy dokumentacji.
  • Tryb kontroli blokady danych- wybór trybu. Dostępne są 3 opcje - kontrolowane(za blokowanie odpowiada programista konfiguracji), automatyczny(SZBD odpowiada za blokowanie), automatyczne i kontrolowane(tryb kombinowany, kontrolowany na poziomie obiektu).
  • Tryb automatycznego numerowania obiektów- możliwe są dwie opcje, zwolnić automatycznie I nie zwalniaj automatycznie. Pierwsza opcja pozwala na uzupełnienie luk w numeracji, jeśli takie wystąpią. Nie zwalniaj automatycznie sprawia, że ​​numeracja jest ciągła.
  • Tryb zgodności- flaga czysto techniczna, która pozwala włączyć lub wyłączyć tryb zgodności ze starszymi wersjami konfiguracji - 8.1 i 8.2.13 oraz 8.3. Te dwie wersje platformy miały charakter przejściowy, dodano nowe obiekty metadanych, przez co system wymaga ponownej konwersji konfiguracji. Trzeba się z tym bardzo ostrożnie obchodzić,

Koszt pracy i opcje tłumaczeń z różnych wydań

Tłumaczenie 8.1 → 8.2.13 Tłumaczenie 8.2.13 → 8.2.16 Tłumaczenie 8.2.16 → 8.3.10
cena, pocierać. * 54 000 ₽ 12 000 ₽ 76 800 rubli

Lista wszystkich zmian w poszczególnych wersjach platformy dostępna jest pod poniższymi linkami:
Dla platformy 8.2:
http://downloads.v8.1c.ru/content/Platform/8_2_19_106/1cv8upd.htm

Przed rozpoczęciem pracy nad tłumaczeniem do wersji 8.3 potrzebujesz:

Sprawdź kontrolowany tryb blokowania. Jeśli używana jest opcja „Automatyczna”, podczas migracji do wersji 8.3 mogą być wymagane dodatkowe koszty przejścia do trybu blokowania zarządzanego.
Jeśli używasz trybu zgodności z wersją 8.2.16 i nowszą, musisz sprawdzić, czy tabele zostały zrestrukturyzowane
Określ, jakie typy klientów są używane (cienki, gruby, klient sieciowy)
Sprawdź, czy istnieją komputery z systemem Linux

Tłumaczenie konfiguracji 8.1 → 8.2.13

Koszt pracy: 54 000 rubli.

Tłumaczenie konfiguracji 8.2.13 → 8.2.16 (w tym restrukturyzacja)

Kluczowe zmiany:
Zmieniono sposób przechowywania stałych i ustawienia rejestrów akumulacji. Każdy obiekt ma własną tabelę bazy danych
Implementacja zarządzanego mechanizmu blokowania została przerobiona.
Dla zdarzenia dziennika technologicznego „TLOCK” właściwość „Txt” jest zapisywana tylko w trybie zgodności z wersją 8.2.13
Zmniejszono wpływ trybu debugowania na szybkość działania w trybie 1C:Enterprise dla cienkiego klienta, grubego klienta, serwera i połączenia zewnętrznego.
Zoptymalizowano wykonanie zapytania w postaci „ValueType(Field1) = ValueType(Field2)” jeśli „Field1” i „Field2” zawierają wartości typu referencyjnego.
W przypadku pól formularzy zarządzanych, które wyświetlają atrybuty typu złożonego, przyspieszono otwieranie listy szybkiego wyboru w przypadkach, gdy typ złożony zawiera typy referencyjne z różnymi ustawieniami szybkiego wyboru.
Dla nowego niezależnego i nieokresowego rejestru informacji indeks wymiaru jest grupowany

Zmiany wymagające zmian konfiguracyjnych:

Gdy tryb zgodności jest wyłączony, wymagany jest parametr „Period” metody menedżera rejestru informacji okresowych „Get()”. W trybie zgodności z wersją 8.2.13 i wersją 8.1 zachowanie pozostaje niezmienione (metody można użyć bez podawania parametru, ale wynik jest niezdefiniowany).
W przypadku jednoczesnego użycia metod „SetValue()” i „UseFromDataSource()” obiektu „DataLockElement” zgłaszany jest wyjątek. W trybie zgodności z wersją 8.2.13 zachowanie nie uległo zmianie (pierwszeństwo ma wartość ustawiona metodą „UseFromDataSource()”).
Nie jest obsługiwane przechowywanie wartości danych, które nie obsługują serializacji. W trybie zgodności zachowanie się nie zmieniło.
Jeśli baza danych jest oparta na plikach, należy dokonać konwersji bazy danych. Po rozpoczęciu konwersji praca z tą bazą informacji z poprzednimi wersjami platformy 1C:Enterprise 8 nie będzie możliwa. Jeśli programowanie odbywa się przy użyciu repozytorium konfiguracji, przed konwersją bazy danych należy wykonać kopię repozytorium

WAŻNY. Aby uzyskać efekt zmiany trybu zgodności należy dokonać restrukturyzacji poprzez konfigurator: „Administracja → Testowanie i korekta → Restrukturyzacja tabel bazy danych”.

Najpierw należy przeprowadzić restrukturyzację na bazie testów i zmierzyć czas wykonania tej operacji.
Jeśli używasz wersji serwera 1C starszej niż 8.2.19, na przykład wersji 8.3, podczas restrukturyzacji mogą wystąpić następujące błędy:

W takim przypadku musisz wykonać następujące czynności:
Zainstaluj oddzielny serwer 1C w wersji 8.2.19 i wdróż na nim badaną bazę danych
Otwórz bazę danych w konfiguratorze na serwerze 1C w wersji 8.2.19, zmień tryb zgodności na „Nie używaj”
Przebuduj tabele bazy danych
Po zakończeniu restrukturyzacji przenieś bazę informacji do oryginalnej wersji serwera 1C 8.3

Koszt przeniesienia konfiguracji z trybu zgodności 8.2.13 do trybu 8.2.16 (tryb niezgodny przy korzystaniu z platformy 8.2.16, 8.2.19 oraz tryb zgodności 8.2.16 przy korzystaniu z platformy 8.3) wynosi 12 000 rubli.

Wzór umowy o pracę można pobrać.

Tłumaczenie konfiguracji 8.2.16 → 8.3.10

Prace związane z translacją konfiguracji obejmują następujące modyfikacje konfiguracji:

1. Wyeliminuj konflikty nazw właściwości. Zmiana nazw zmiennych, aby pasowały do ​​nowych właściwości, które pojawiły się w 1C:Enterprise 8.3.
2. Wyeliminuj sprzeczne nazwy obrazów. Zmiana nazw obrazów na nazwy pasujące do nazw z biblioteki obrazów.
3. Udoskonalenie kodu przy zmianie właściwości konstrukcji stałej. Zastąpienie wskazania właściwości konstrukcji stałej odtworzeniem konstrukcji stałej lub zastąpienie jej użytkowania podobnym typem „Konstrukcji”.
4. Zastąpienie umieszczania wartości niemożliwych do serializacji w pamięci tymczasowej kodem obsługiwanym w 1C:Enterprise 8.3.
5. Zastąpienie wywoływania metody „Show” dla szczegółów zarządzanych formularzy wykorzystaniem właściwości „CurrentElement”, „CurrentPage” i metody „Activate”
6. Zastąp nazwy obiektów metadanych dłuższe niż 80 znaków nazwami o długości maksymalnie 80 znaków w przypadku obiektów metadanych
7. Zmiana nazw metod i właściwości, zgodnie z metodologią migracji do wersji 8.3.
8. Ulepszenie mechanizmów pracy z zaznaczeniami, formatowaniem warunkowym, grupowaniem i porządkiem na listach dynamicznych.
9. Udoskonalenie kodu dla zapytań ze słowem kluczowym „WYNIKI OGÓLNE”, rozładowywanych w
„Pomijanie wyniku zapytania poprzez grupowanie”, aby zachować dotychczasową logikę pracy.
10. Zmiany w nazwach klas obiektów COM. Zastąpienie nazw „V82.COMConnector” przez „V83.COMConnector” i „V82.Application” przez „V83.Application”.
11. Odmowa w kodzie programu zdarzenia „Rozpoczęcie selekcji z listy” dla pól wejściowych w trybie selekcji z listy
12. Odmowa w kodzie programu właściwości „Przycisk Lista Wyborów” dla pól wejściowych poprzez ustawienie właściwości „Przycisk Lista rozwijana”.
13. Zmiana kodu w celu uwzględnienia zmiany typu wartości zwracanej przez metodę kontekstu globalnego „SafeMode()”
14. Zmiana kodu w celu uwzględnienia zmiany wyniku zapytania o stałe (przy dostępie do pola „Wartość” tabeli stałych, jeśli stała przechowuje wartość typu „Value Storage”, „UniqueIdentifier” lub „Odniesienie do tabeli zewnętrznego źródła danych”.
15. Zamiana właściwości konfiguracyjnej „MainRole” na „MainRoles”
16. Odmowa właściwości „User” i „Password” dla obiektu „InternetProxy” i zastąpienie ich metodami „Set()”, „User()”, „Password()”.
17. Dopracowanie kodu do obsługi komendy „Pokaż na liście”, zgodnie z metodą przejścia do wersji 8.3.
18. Dopracowanie kodu w celu zachowania dotychczasowej logiki działania systemu w przypadku zmiany wartości zwracanej właściwości SystemInformation.OSVersion,
19. Dopracowanie kodu w celu zachowania dotychczasowej logiki systemu w przypadku odmowy użycia wyliczenia systemowego OptionOpenWindow, które nie jest już dostępne w wersji 8.3.
20. Udoskonalenie kodu uwzględniające rezygnację z korzystania z okien modalnych.
21. Ulepszenie kodu obsługującego klienta sieciowego, mianowicie odmowa wywołań serwera i otwieranie okien w „Przed zamknięciem”, odmowa wywołań serwera w „Po zamknięciu”.
22. Udoskonalenie kodu w celu umożliwienia poprawnego wykorzystania funkcji RoleAvailable() przy przekazywaniu funkcji jako parametru do brakującej roli.
23. Dla aplikacji zarządzanej: począwszy od wersji 8.3.8 w procedurach obsługi zdarzeń aplikacji zarządzanej BeforeSystemShutdown, WhenSystemShutdown, a także w procedurach obsługi zdarzeń formularza zarządzanego będącego w trybie zamykania, BeforeClosing, WhenClosing, Zabrania się otwierania okien i wykonywania jakichkolwiek wywołań serwerowych. Należy poprawić konfigurację, aby formularze można było poprawnie zamykać - bez wywołań serwera.
24. Konflikt nazw zmiennych: w module formularza nie można używać nazwy zmiennej FormParameters. Dlatego konieczne jest zmodyfikowanie wszystkich zarządzanych modułów formularzy, które używają zmiennych o nazwie FormParameters, zmieniając nazwy tych zmiennych.

Cena za te prace jest wstępna i obowiązuje dla większości konfiguracji. Przed przystąpieniem do pracy przy zawieraniu umowy sprawdzamy konfigurację i Po sprawdzeniu potwierdzamy cenę i warunki współpracy. Sprawdzanie jest konieczne, ponieważ konfiguracje mogą być bardzo różne, w tym mocno przepisane.

Koszt pracy: 76 800 rubli.

Wzór umowy o pracę można pobrać.

Koszt przeniesienia konfiguracji do trybu zgodności z wersją 8.3.10 może wynosić zwiększony, Jeśli:
Konfiguracja korzysta z formularzy zarządzanych
Należy porzucić stosowanie modalności
Konieczne jest zachowanie funkcjonalności konfiguracji w systemie operacyjnym Linux

Została udostępniona nowa wersja platformy 8.3.11, która umożliwia dodawanie i zmianę obiektów metadanych poprzez rozszerzenie. Czy naprawdę możemy teraz wdrożyć jakiekolwiek ulepszenia bez usuwania konfiguracji ze wsparcia? Czy warto obiecywać klientowi góry złota bez żadnych konsekwencji?

Przede wszystkim musisz zdawać sobie sprawę z ograniczeń, jakie mają rozszerzenia.

Ograniczenia tworzonych obiektów

W tej chwili możesz stworzyć:

  • Katalogi
  • Dokumentacja
  • Rejestry informacyjne
  • Plany wymiany

Możesz dodać szczegóły do:

  • Katalogi
  • Dokumentacja

Z czym skończymy? Nie wszystkie typy obiektów metadanych można dodać. Najbardziej popularne i popularne, ale wciąż nie wszystkie. Dodatkowo do rejestrów informacyjnych nie można dodawać nowych wymiarów i zasobów. Można jedynie utworzyć zupełnie nowy rejestr.

Funkcjonalność rozszerzeń zależy od trybu zgodności konfiguracji, do której zastosowane jest rozszerzenie.

Tryb zgodności 8.3.8- można jedynie zmieniać formy obiektów i ich modułów, dodawać własne raporty i obróbki.

Tryb zgodności 8.3.10- możesz zmieniać moduły ogólne, moduły obiektów i menedżerów, role, używać dyrektyw „Przed”, „Po”, „Zamiast” dla dowolnych modułów.

Tryb zgodności „Nie używaj”- możesz korzystać ze wszystkich funkcjonalności rozszerzeń, łącznie z dodawaniem nowych obiektów.

W tej chwili standardowy UT 11.3 ma tryb zgodności 8.3.8. W UT 11.4 tryb zgodności to 8.3.10, czyli np. dla UT większość funkcjonalności rozszerzeń nie jest dostępna, w tym tworzenie obiektów metadanych.

To wydaje się nasuwać pytanie: dlaczego po prostu nie wyłączyć obsługi roota, ustawić tryb zgodności na „Nie używaj” i spokojnie korzystać z rozszerzeń? W przypadku zmiany trybu zgodności zachowanie formularzy i wyników zapytań może ulec zmianie, tj. zachowanie systemu jako całości. Zdecydowanie zaleca się, aby nie zmieniać trybu zgodności bez uprzedniego przetestowania. Oczywistym jest jednak, że możliwe wydaje się pełne przetestowanie (lub przynajmniej częściowe przetestowanie wykorzystanych dokumentów) całego rozwiązania aplikacyjnego. Dlatego nie należy korzystać z tej opcji.

Podczas podłączania rozszerzenia do konfiguracji standardowej i wypożyczania obiektów standardowych, rozszerzenie kontroluje tryb zgodności z konfiguracją główną oraz typy pożyczanych obiektów i ich szczegóły. Jeżeli monitorowane właściwości nie są zgodne, rozszerzenie zostaje wyłączone i nie będzie działać do czasu usunięcia przyczyny. Oznacza to, że w przypadku dużej aktualizacji istnieje duże prawdopodobieństwo zmiany co najmniej jednej z kontrolowanych właściwości i spowodowania utraty funkcjonalności rozszerzenia.


Ponadto, jeżeli modyfikacje są istotne, następuje wymiana wielu procedur i funkcji konfiguracji standardowej, konieczne będzie ich uważne monitorowanie i w razie potrzeby dostosowanie do konfiguracji standardowej, z zachowaniem wcześniej wprowadzonych zmian.


W powyższych przypadkach nadal będziesz potrzebować pomocy programisty i ewentualnie znacznej ilości czasu na modyfikację (ale wciąż mniej niż przy aktualizacji konfiguracji usuniętej ze wsparcia).

wnioski

  • Nowa odsłona platformy zapewniła nowe możliwości wykorzystania rozszerzeń, możliwe stało się dodawanie obiektów metadanych, jednak pomimo tego funkcjonalność posiada pewne ograniczenia.
  • Tryb zgodności konfiguracji, do której zastosowane jest rozszerzenie, znacznie ogranicza możliwości rozszerzenia; zmiana trybu zgodności nie jest zalecana.
  • Duże aktualizacje nadal wymagają uwagi programistów, ponieważ istnieje duże prawdopodobieństwo zmiany kontrolowanych właściwości.

Wielu słyszało słowo „1C: Kompatybilny!”, Ale niewielu wie, co się za nim kryje. Dla większości oznacza to po prostu prawidłowe działanie oprogramowania i wsparcie dla produktu 1C. Niedawno musiałem zdobyć certyfikat „1C: Kompatybilny!”. uzupełnić konfigurację i chcę powiedzieć, jaką pracę musi wykonać programista i co daje ten certyfikat.

Po pierwsze, certyfikacja ma na celu podniesienie jakości programów napisanych w systemie 1C:Enterprise 8 i skierowana jest do użytkowników. Kupując oprogramowanie z etykietą „1C: Kompatybilny!” kupujący może być pewien, że:

  • Do produktu dołączona jest szczegółowa dokumentacja zawierająca przejrzysty opis instalacji produktu, opis jego działania i strukturę danych;
  • przy każdej aktualizacji będą opisane innowacje w nowej wersji oraz opis procesu aktualizacji;
  • w przypadku aktualizacji do nowej wersji lub wydania wszystkie aktualne dane zostaną przeniesione (zgodnie z instrukcją przeniesienia);
  • oprogramowanie będzie zawierało znany wszystkim pulpit i ustawienia (lub pozycję menu serwisowego w zwykłej aplikacji), do których przyzwyczajeni są wszyscy użytkownicy standardowych konfiguracji;
  • Pakiet dostawy obejmuje bazę demonstracyjną, którą można wykorzystać do szkolenia w zakresie oprogramowania;
  • Kod oprogramowania jest napisany zgodnie ze standardami 1C, opatrzony komentarzami opisującymi działanie kodu.

Certyfikacja poprawi nastawienie konsumentów do Twojego produktu i zwiększy sprzedaż produktów.

Wszystkie prace certyfikacyjne spadają na barki programisty. Poniżej krótko opisano główne wymagania certyfikacyjne. Jeśli opracowujesz konfigurację, która będzie wymagała certyfikacji w przyszłości, radzę natychmiast zapoznać się z wymaganiami 1C, abyś decydując się na certyfikację nie musiał. aby przepisać komentarze i przerobić interfejs dla całej konfiguracji. Ale od razu powiem, że większość pracy polega na stworzeniu dokumentacji i zestawów dostaw. Moim zdaniem najtrudniejszą rzeczą w pisaniu kodu jest początkowe wypełnienie bazy danych, śledzenie wersji i wyświetlenie komunikatu o zmianach w nowej wersji.


Certyfikatem mogą zostać objęte:
  1. Programy przeznaczone do masowej dystrybucji współpracujące z programami systemu 1C:Enterprise (konfiguracje, raporty, dodatki do konfiguracji standardowych, komponenty zewnętrzne, banki klienckie, oprogramowanie wymiany)
  2. Komputery przeznaczone do użytku w połączeniu z systemem oprogramowania 1C:Enterprise 8 jako serwery 1C:Enterprise 8
  3. Kasa fiskalna i inny specjalistyczny sprzęt podłączony.
  4. Urządzenia mobilne przeznaczone do organizowania pracy z danymi 1C:Enterprise bezpośrednio na urządzeniu mobilnym.

Twórca konfiguracji musi spełnić następujące warunki:

  1. Nie możesz używać słowa „1C” ani logo „1C” w nazwie konfiguracji bez zgody 1C.
  2. Wymagana jest pisemna gwarancja kierownika oraz pieczątka firmy producenta, że ​​produkt nie narusza niczyich praw autorskich.
  3. Należy numerować wersje konfiguracji zgodnie z Systemem standardów i metod opracowywania konfiguracji dla platformy 1C:Enterprise 8. Ponadto wydanie nowej wersji musi zapewniać przejście z poprzedniej z zachowaniem danych, a w przypadku wydania nowej wersji należy zapewnić przejście z zachowaniem danych lub opisać procedurę migracji do nowej edycji.
  4. Nie można używać terminu „konfiguracja standardowa” w odniesieniu do tworzonej konfiguracji.
  5. Jeśli konfiguracja została napisana w trybie aplikacji zarządzanej, należy to uwzględnić w dokumentacji. Powinien także działać w sieci i cienkim kliencie. Jeśli w kliencie WWW nie można wykonać niektórych funkcji, należy to opisać w dokumentacji.
  6. Konfiguracja musi umożliwiać rozróżnienie pierwszego i kolejnych przebiegów. Przy pierwszym uruchomieniu konfiguracja musi wykonywać obowiązkowe wstępne wypełnianie bazy danych i powinna mieć opcjonalnie opcjonalne wypełnianie, aby uprościć pracę z bazą danych. Po pierwszym uruchomieniu lub po pierwszym uruchomieniu nowej wersji konfiguracja powinna udostępnić raport o dokonanych zmianach w bazie danych.
  7. Wszystkie obiekty metadanych muszą mieć zdefiniowany synonim
  8. Obiekty metadanych najwyższego poziomu muszą być posortowane alfabetycznie, z wyjątkiem obiektów z przedrostkiem „Usuń”. Powinny być na dole.
  9. Musi istnieć rola administratora ze wszystkimi uprawnieniami z wyjątkiem interaktywnego usuwania.
  10. Jeśli jest podział ról, to powinien nastąpić podział na role, w których przysługują wszystkim prawa wspólne, i role, w których przysługują inne prawa. Na przykład rola „Podstawowe prawa”
  11. Należy podać informacje referencyjne głównych obiektów konfiguracyjnych.
  12. Należy używać zarządzanego trybu blokowania.
  13. Podpowiedzi muszą zostać wypełnione dla wszystkich elementów, w których użytkownik wprowadza dane.
  14. W przypadku aplikacji zarządzanej zawsze powinien znajdować się pulpit, ostatnią sekcją powinna być sekcja administracyjna.
  15. Dla zwykłej aplikacji powinien istnieć wspólny i kompletny interfejs, a także możliwość przełączania go z menu „Narzędzia”.
  16. W przypadku normalnej aplikacji wszystkie elementy formularza muszą być wyrównane.
  17. W kodzie każda linia powinna zawierać tylko jedną instrukcję, tekst kodu powinien być wyrównany z tabulatorami, przy sprawdzaniu modułów i sprawdzaniu konfiguracji nie powinno być błędów. Funkcje muszą mieć komentarze opisujące akcję, parametry i zwracany wynik.