제 생각에는 미리 정의된 요소를 사용한 프로그래밍 작업이라는 아이디어가 매우 정확합니다. 작업할 때 고려해야 할 뉘앙스가 있습니다.
먼저 구성에 미리 정의된 요소가 있고 IS(정보 베이스)에 미리 정의된 요소가 있다는 것을 스스로 명확하게 이해해야 합니다. 기술적으로 사전 정의된 정보 보안 요소는 디렉토리의 가장 일반적인 요소이며, "사전 정의된 데이터의 이름" 속성은 해당하는 사전 정의된 구성 요소를 나타냅니다. 그것들은 일반적인 요소와 다르지 않습니다. 따라서 일반적인 정보보안 요소는 미리 정의될 수 있고, 미리 정의된 요소는 일반 정보보안 요소가 될 수 있다. 이렇게 하려면 속성에 원하는 값을 입력하면 됩니다. "미리 정의된 데이터 이름".
때때로 이 속성에는 개발자가 의도한 값이 아닌 값이 포함되어 있습니다. 결과적으로 1C 작동에 오류가 발생합니다. 기본적으로 작업이 불가능한 크리티컬부터 알고리즘의 논리가 중단되는 비크리티컬까지.
조건부로 구별할 수 있습니다. 세 가지 유형의 오류:
1. "미리 정의된 요소가 데이터에 없습니다";
3. 미리 정의된 요소의 잘못된 사양;
1. "미리 정의된 요소가 데이터에 없습니다" - o정보 보안 데이터의 구성에 설명된 사전 정의된 요소가 없습니다.
이는 디버그하고 수정하기 가장 쉬운 오류 유형입니다. 그 단순성은 플랫폼이 "미리 정의된 요소가 데이터에 없습니다"라는 상황을 매우 정확하게 보고하고 이를 해결하는 방법이 매우 명확하다는 것입니다.
"디렉터리.연락처 정보 유형.담당자의 이메일" 코드에서 누락된 요소에 액세스하면 메시지가 표시됩니다.
"VALUE(디렉토리.연락처 정보 유형.담당자의 이메일)" 요청의 요소에 액세스할 때 다음 메시지가 표시됩니다.
이 오류는 요소가 구성에 설명되어 있지만 해당 요소가 데이터베이스에서 해당 요소와 연결되지 않은 경우 발생합니다.
우선, 이 상황이 항상 잘못된 것은 아니라는 점을 분명히 하겠습니다. 대부분의 사용자에게는 사용되지 않는 일종의 프로그램 논리에서 미리 정의된 데이터를 사용하는 것이 가능합니다. 이 경우 구성의 모든 사용자에 대해 디렉토리를 복잡하게 만들지 않기 위해 구성에서 사전 정의된 요소를 정의하는 것이 논리적이지만 모든 정보 보안 시스템에서 요소를 생성하는 것이 아니라 다음과 같은 정보 보안 시스템에 대해서만 생성하는 것이 논리적입니다. 필요한 구성 논리가 사용됩니다. 이 경우 프로그래머는 디렉터리에 대해 "미리 정의된 데이터를 업데이트하지 않음" 속성을 지정하고 모듈 기능에 액세스할 때 프로그래밍 방식으로 요소를 생성할 수 있습니다. 또는 사용자가 사전 정의된 모듈 요소를 기존 일반 요소에 독립적으로 바인딩할 수 있도록 허용합니다.
또한 RIB 모드에서 작업할 때는 미리 정의된 요소의 자동 생성이 사용되지 않습니다. 새 요소는 중앙 데이터베이스에서 전송되어야 하며 다른 UID를 가진 노드에서 생성되어서는 안 됩니다.
저것들. 때로는 오류가 일치하지 않는 요소에 대한 참조이지 해당 요소 자체의 존재가 아닌 경우도 있습니다.
요소가 생성되지 않은 이유를 분석해야 합니다. 아마도 일부 프로그램 모드가 실행될 때 생성되어야 할 것입니다. 예를 들어 RIB에서 교환을 완료한 후입니다. 아니면 실수로 삭제되었을 수도 있습니다.
논리가 미리 정의된 요소를 자동이 아닌 별도의 모드로 채우는 경우 이름으로 액세스를 사용하기 전에 " 디렉토리.연락처 정보 유형.담당자의 이메일"예외적인 상황을 방지하려면 요소가 이미 데이터베이스에 있는지 확인하는 것이 좋습니다. 요소가 누락된 경우 사용자에게 이에 대해 알리고 요소를 채우기 위해 수행해야 하는 모드를 설명하십시오. 이러한 확인을 위해 , 데이터 쿼리를 실행할 수 있습니다.
요청 = 새 요청; Request.Text = "SELECT | 연락처 정보 유형. Link | FROM | 디렉토리. 연락처 정보 유형 HOW 연락처 정보 유형 | WHERE | 연락처 정보 유형. 사전 정의된 데이터 이름 = "" 이메일연락처사람"""; 항목이 누락되었습니다.InData = Query.Execute().Empty();
그래도 데이터베이스 데이터에 오류가 있는 경우 정보 보안 요소의 사전 정의된 요소에 바인딩해야 합니다. 저것들. 프로그램 코드가 이 이름으로 액세스해야 하는 정보 보안 요소를 시스템에 설명할 필요가 있습니다. 기술적으로 바인딩은 단순히 " 속성에 미리 정의된 요소의 이름을 지정하는 것입니다.사전 정의된 데이터 이름" IS 요소를 설치하려면 다음 코드를 실행하세요.
2. "미리 정의된 요소가 고유하지 않습니다." - h이중 사전 정의된 요소:
이는 미리 정의된 하나의 요소에 여러 정보보안 요소가 결합된 상황이다. 이 경우 미리 정의된 이름에 액세스하면 해당 요소가 무작위로 선택됩니다. 이 상황은 항상 잘못되었습니다. 그 어려움은 플랫폼이 어떤 식으로든 이를 보고하지 않는다는 것입니다. 알고리즘이 잘못 작동하기 시작합니다.
플랫폼은 중복 요소를 편집하려고 할 때만 "사전 정의된 요소가 고유하지 않습니다."라는 오류를 보고합니다.
요소를 편집할 필요가 없는 한 누구도 오류에 대해 알 수 없습니다.
예를 들어 디렉터리에 RIB가 사용되고 사전 정의된 데이터의 속성에 "자동 업데이트" 모드가 지정된 경우 이러한 복제본이 생성될 수 있습니다. 이 경우 교환을 수행할 때 구성이 업데이트되면 사전 정의된 데이터의 인스턴스 하나가 생성됩니다. 동일한 이름을 가진 사전 정의된 요소의 두 번째 인스턴스는 교환 중에 중앙 데이터베이스에서 전송됩니다.
또한, 서로 다른 정보 보안 요소가 서로 다른 데이터베이스의 사전 정의된 요소에 해당하는 경우 구성 간 교환 처리를 사용할 때 이러한 중복이 발생합니다. 이 경우 미리 정의된 데이터의 복사본 중 하나가 데이터베이스에 이미 존재하며, 두 번째 복사본은 다른 UID로 데이터를 로드할 때 제공됩니다. 데이터 전송을 수행하는 경우 기본으로 간주되는 데이터베이스 요소를 결정하고 이를 하위 데이터베이스에서 사용해야 합니다. 하위 데이터베이스에서는 이전 요소의 사용을 기본 데이터베이스의 요소로 대체해야 합니다.
데이터베이스의 이러한 오류는 다음과 같은 쿼리로 식별할 수 있습니다.
SELECT 연락처 정보 유형. 사전 정의된 데이터 이름, QUANTITY(다양한 연락처 정보 유형. 참조) AS 사전 정의된 FROM 디렉터리 수. 연락처 정보 유형 AS 연락처 정보 유형 GROUP BY 연락처 정보 유형. 사전 정의된 데이터 이름 HAVING QUANTITY (다양한 유형의 tactInformation.Link) > 1
이 쿼리는 둘 이상의 정보 보안 요소가 연결된 사전 정의된 요소 목록을 반환합니다.
이러한 요소가 있는 경우 해당 요소 중 하나에 대해 미리 정의된 요소와의 연결을 제거해야 합니다. 저것들. 이 이름을 사용할 때 프로그램 코드가 어떤 정보 보안 요소를 참조해야 하는지 시스템에 대해 명확하게 결정해야 합니다.이렇게 하려면 코드를 실행하면 됩니다.
3. 사전 정의된 요소의 사양이 잘못되었습니다.
오류는 미리 정의된 요소가 프로그램 논리에서 제공되지 않는 요소에 해당한다는 것입니다. 이러한 오류는 진단하기 가장 어렵습니다. 처음 두 가지 유형과 달리 구성에서 이러한 오류를 자동으로 확인할 수 없습니다. 이는 작업의 논리를 분석해야만 식별할 수 있습니다. 의심스러운 경우 올바른 요소가 사용되고 있는지 확인할 수 있습니다.
이렇게 하려면 명령 중 하나를 실행하면 됩니다.
//원하는 미리 정의된 Notify에 연결된 정보 보안 요소 정의(Directories.Types of Contact Information.Email of the ContactPerson) //선택한 Notify가 첨부된 미리 정의된 요소 정의(Link to Element.Name of the Predefine Data) )
이러한 오류가 확인되면 이전 요소와의 잘못된 연결을 제거하고 새 요소와의 연결을 추가해야 합니다. 연산 코드는 처음 두 가지 유형의 오류를 수정하는 코드와 유사합니다.
프로그램 작업 중이나 구성 모드에서의 오류에 대해 간략히 설명합니다.
"미리 정의된 요소는 다음에 속하지 않습니다.<Имя справочника>" - 구성기의 이름과 일치하지 않는 이름으로 미리 정의된 요소를 쓰려고 하면 오류가 발생합니다..
"미리 정의되지 않은 개체는 미리 정의된 하위 연속 보기 레코드를 가질 수 없습니다." - 사전 정의된 계정과목표의 요소를 사전 정의되지 않은 상태로 만들려고 하면 오류가 발생합니다. 오류를 제거하려면 각 요소 하위 접점 라인에서 "사전 정의" 플래그를 제거해야 합니다.
"미리 정의되지 않은 개체는 주요 계산 유형의 사전 정의된 레코드를 가질 수 없습니다."- 계산 유형 계획의 미리 정의된 요소를 미리 정의되지 않은 상태로 만들려고 하면 오류가 발생합니다. 오류를 제거하려면 요소 선행 계산 유형의 각 라인에 대해 "사전 정의" 확인란을 제거해야 합니다.
"미리 정의된 요소가 고유하지 않습니다."- 8.3.4와 호환 모드가 없는 구성 릴리스에 대한 정보 기반을 업데이트할 때 구성자에서 오류가 생성됩니다. 업데이트하기 전에 중복 항목을 확인하고 제거해야 합니다.
"미리 정의된 요소의 이름이 고유하지 않습니다." - 플랫폼으로 업데이트할 때 구성에 동일한 이름의 미리 정의된 요소가 여러 개 있는 경우 오류가 발생합니다.8.3.6.2332 이상. 구성에서 중복을 제거해야 합니다.
미리 정의된 데이터로 작업하려면 처리를 권장합니다. 사전 정의된 데이터로 모든 작업을 수행할 수 있으며 모든 정보 보안 개체(디렉터리, 계정과목표, PVC, PVR)에서 처음 두 가지 유형(중복 및 누락 요소)의 오류가 있는지 구성 전체를 확인할 수도 있습니다. .
1C:Enterprise 8.x 플랫폼에서 작업할 때 프로그램 코드를 일반(미리 정의되지 않은) 디렉터리 요소에 바인딩해야 하는 경우가 종종 있습니다. 예를 들어 조직에는 거의 모든 메커니즘에 사용되는 5가지 유형의 가격이 있을 수 있습니다. 이 경우 특정 가격에 대한 프로그래밍 방식의 액세스는 기껏해야 디렉토리의 코드를 사용하거나 최악의 경우 요소 이름을 사용하여 수행됩니다.
보고서에서 필요한 가격을 얻기 위해 이름별 요청에서 가격 유형별로 선택이 사용되는 방식을 목격했습니다(다음 스크린샷 참조).
또한 디렉터리 요소의 이름이나 코드에 연결하면 요소에 대한 링크를 받을 때 항상 디렉터리 테이블에서 검색이 수행됩니다. 표준 시스템 세부 사항이 DBMS에 의해 색인화된다는 사실에도 불구하고 어떤 경우에는 이를 검색하는 데 상당한 리소스가 필요할 수 있습니다. 또한, 예를 들어 요소에 대한 링크가 이미 "미리 알려진" 경우 참조 테이블을 사용하여 검색 쿼리를 수행하지 않는 것이 더 합리적입니다.
탈출구로 "항목 가격 유형" 디렉토리에서 자주 사용되는 각 요소에 대한 링크를 별도의 상수로 저장하고 요청에서 해당 요소로부터 값을 얻을 수 있습니다. 그러나 이 경우 개발자는 해당 요소마다 별도의 상수를 추가해야 합니다. 이러한 요소가 "항목 가격 유형" 디렉터리뿐만 아니라 다른 디렉터리("개체 범주", "품질", "명명법" 등)에도 있는 경우 상황은 훨씬 더 복잡해집니다. 그러면 시스템의 상수 수가 여러 배로 늘어날 수 있습니다!
물론 각 디렉토리에 미리 정의된 요소를 추가하는 것이 가능하며 해당 요소에 액세스하는 것이 훨씬 쉬워질 것입니다. 그러나 기본 개체를 변경하면 공급업체 패키지에서 구성을 업데이트하기가 더 어려워집니다.
구성 메타데이터 구조 개발 측면과 시스템 성능 측면 모두에서 보다 최적의 접근 방식이 있습니다. 이것이 오늘 우리가 이야기할 내용입니다.
범용 솔루션
범용 솔루션의 본질은 다음과 같습니다. 개발자가 미리 정의된 요소를 추가할 디렉터리가 생성됩니다. "값" 속성이 조회에 추가되었습니다. 이 속성의 유형은 "사전 정의된 조회 요소 -> 관련 값" 대응이 생성될 값에 따라 달라집니다. 디렉터리 메타데이터 구조는 다음과 같습니다(다음 스크린샷 참조).
미리 정의된 요소를 얻으려면 가장 좋은 옵션은 전역 메서드를 사용하는 것입니다. "미리 정의된 값(<Имя>)" . 사전 정의된 요소의 전체 경로가 매개변수로 메소드에 전달됩니다. 구문은 VALUE() 쿼리 언어 함수와 유사합니다.
개발을 쉽게 하기 위해 미리 정의된 요소와 관련된 값을 가져오는 기능을 공통 모듈에 배치하는 것이 좋습니다. 기사 끝에 있는 링크를 통해 다운로드할 수 있는 테스트 구성에서 내보내기 기능이 있는 공통 모듈 "사전 정의된 요소의 값"이 생성되었습니다. "사전 정의된 요소의 GetValue(<ИмяПредопределенногоЭлемента>)" . 함수의 프로그램 코드는 미리 정의된 요소에 대한 참조를 받은 다음 요청을 사용하여 "값" 속성의 값을 받습니다. 다음 스크린샷은 전체 함수 목록을 보여줍니다.
보시다시피, 함수는 매개변수로 전달된 사전 정의된 요소의 "값" 속성에 대한 요청을 생성합니다. 함수 매개변수는 미리 정의된 요소의 이름이 포함된 문자열입니다.
생성된 메커니즘이 올바르게 작동하려면 "값" 속성에서 해당 요소를 선택하여 사용자 모드에서 사전 정의된 요소를 일반 디렉터리 요소와 연결해야 합니다. 성능에 미치는 영향 문제로 넘어 갑시다.
성능에 미치는 영향
이름별 검색 옵션과 사전 정의된 요소의 링크별 검색 옵션에 대해 속도 테스트를 수행했습니다. 검색은 20,000개의 항목이 있는 "제품" 디렉토리에서 이루어졌습니다. 파일 데이터베이스에 대한 테스트를 수행한 결과 다음과 같은 결과가 나왔습니다.
결과는 파일 버전의 작업에 대해 미리 정의된 요소를 사용하여 다른 디렉터리의 자주 사용되는 요소를 얻는 것이 거의 4배 느린 것으로 나타났습니다!
클라이언트-서버 버전의 작업에서는 테스트 결과가 완전히 다른 그림을 보여줍니다. 원하는 요소에 대한 링크를 얻는 속도는 크게 감소하지 않았지만(테스트 중 하나에서는 이름 검색에 0.002초, 미리 정의된 요소를 통해 작업할 때 0.0008초가 나타났습니다), 프로그램의 신뢰성이 크게 향상되었습니다!
결론
일반 디렉터리 요소에 연결해야 하는 경우가 자주 있는 경우에는 코드나 이름으로 바인딩을 사용하지 않는 것이 좋습니다. 이 접근 방식은 시스템 안정성과 성능을 저하시킵니다.
플랫폼에서 작업하는 동안 예를 들어 디렉토리 요소 "PriceNomenclature Types"와 같은 이름을 변경한 후 대부분의 비표준 보고서 작업이 실패하는 상황에 여러 번 직면했습니다.
코드나 이름을 통해 일반 디렉터리 요소에 더 많은 알고리즘이 연결될수록 시스템의 안정성이 떨어집니다.
또한 이 접근 방식을 사용하면 미리 정의된 요소를 추가해야 하는 경우 표준 구성 개체를 변경하지 않아도 됩니다. 이렇게 하면 향후 구성 업데이트 프로세스가 다소 쉬워질 것입니다.
다운로드할 파일:
- 기사의 예제가 포함된 테스트 데이터베이스 업로드.
안녕하세요.
오늘은 사전 정의된 요소와 관련하여 플랫폼 8.3의 혁신에 대해 이야기하겠습니다.
소개
실제로 초기에는 사전 정의된 이름을 찾기 위해 디렉터리 요소를 살펴보고 싶었던 경우가 매우 많았음을 상기시켜 드리겠습니다. 예를 들어 사전 정의된 두 개의 상대방을 생성하고 이름을 IPSidorov 및 OOOMeteor로 지정했습니다. 그리고 그들은 그들에게 몇 가지 논리를 꿰매었습니다.
모든 것이 디버깅되고 해결되었을 때 작업이 반대 방향으로 제기되었고 LLC에는 개별 기업가를 위한 논리가 필요하고 개별 기업가에게는 LLC의 논리가 필요하다는 것이 밝혀졌습니다. “문제 없습니다.”라고 말하고 엔터프라이즈 모드에서는 요소의 이름을 바꿉니다. 결국 코드를 입력하는 것이 훨씬 더 어렵습니다. 1년이 지나면 IP Sidorov에 대한 추가 논리를 설정하는 새로운 작업이 주어집니다. 컨피규레이터로 가서 로직을 작성하고 검사를 시작해도 아무것도 작동하지 않습니다. 왜냐하면... IPSidorov 구성자 및 기업 - OOOMeteor에서. 뇌가 망가져서 이 갈퀴를 부수고 싶습니다. 가장 간단하고 분명한 것은 미리 정의된 요소의 이름을 목록 형태로 표시하는 것입니다. 문제는 다음과 같습니다. 이 메서드를 사용하면 8.2에서 미리 정의된 이름만 얻을 수 있습니다. 하지만 이 방법에는 요청을 통해 얻을 수 없다는 단점이 있습니다. 저것들. 첫 번째 불편한 점은 디렉토리에 대한 참조에서 미리 정의된 이름을 얻는 것입니다.
두 번째 불편한 점은 이미 디렉터리 요소가 있고 이를 미리 정의해야 할 때입니다. 미리 정의된 요소를 만들고 디렉터리에 두 개의 요소를 가져옵니다. 하나는 미리 정의되어 있고 다른 하나는 작동 가능하며 모든 문서에서 참조됩니다. 링크를 교체하면 확실히 도움이 되지만 데이터베이스가 크면 어렵습니다.
이제 요점으로
첫 번째는 이제 디렉토리에 "미리 정의된 데이터 업데이트" 속성이 있다는 것입니다.
이 분야는 우리에게 무엇을 제공합니까? "자동으로 업데이트하지 않음"으로 설정된 경우 사전 정의된 요소를 추가하면 해당 요소가 디렉터리에 바로 표시되지 않습니다. 저것들. 메타데이터는 데이터와 아무 관련이 없습니다. 그리고 디렉터리에 생성하지 않은 경우 디렉터리 관리자를 통해 해당 이름으로 액세스하면 구문 오류가 발생합니다.
매우 흥미롭습니다. 그런데 왜요? 디렉토리에 요소를 어떻게 만들 수 있나요? 원하는 대로 생성하거나 기존 항목에 연결할 수 있습니다. 이제 디렉토리에는 "미리 정의된 데이터 이름" 속성이 있습니다. "Directories.Contractors.CreateElement()"를 통해 평소와 같이 프로그래밍 방식으로 디렉터리 요소를 생성하고 사전 정의된 요소의 이름과 동일한 "PredefoundDataName" 속성을 채웁니다. 또는 요소가 이미 존재하는 경우 해당 개체를 가져오고 "사전 정의된 데이터 이름"을 다시 채웁니다. 모두.
그리고 마지막으로 시럽 조금
이 새로운 속성은 읽기 및 쓰기에만 사용할 수 있는 것이 아니라 요청에서도 사용할 수 있습니다. 이렇게 하면 쿼리에서 조건을 부과하고 사전 정의되었는지 여부를 결정할 수 있습니다.
관심을 가져주셔서 감사합니다.
사전 정의된 요소와 일반 요소의 차이점은 누구나 알고 있습니다. "사전 정의된 요소는 구성자 모드에서 생성되며 1C:Enterprise 모드에서는 삭제할 수 없습니다." 사용자 모드에서는 특수 아이콘을 사용하여 사용자가 추가한 요소와 사전 정의된 요소를 구별할 수 있습니다(다음 스크린샷 참조).
기본적으로 미리 정의된 요소는 다양한 구성 개체에 알고리즘을 바인딩하기 위해 개발자가 생성합니다. 예를 들어, "Quality" 디렉토리의 "Manufacturing Enterprise Management" 구성에서 개발자는 사전 정의된 요소 "New"를 추가했습니다.
이 요소는 많은 구성 모듈에서 사용됩니다. 따라서 "상품 및 서비스 수령" 문서에서 "품질" 차원이 있는 모든 기록부에 게시할 때 미리 정의된 요소의 값이 대체됩니다. 다음은 "단체 물품" 등록부 게시표 작성 목록입니다.
// 제품 등록을 통한 제품 조직. MoveSet = 이동합니다. 제품조직; 영수증 유형 = 이체인 경우. 상품 수령 유형. 그럼 창고로 // 레지스터 레코드세트의 구조와 일치하는 값 테이블을 가져옵니다.모션테이블 = 모션셋. 언로드() ; // 모션 테이블을 채웁니다.범용. LoadValueTable(제품 테이블, 운동 테이블) ; // 필드가 누락되었습니다.무브먼트 테이블. FillValues(조직, "조직" ) ; 무브먼트 테이블. FillValues(정의되지 않음, "수수료 대리인"); 무브먼트 테이블. FillValues(Directories.Quality.New, "Quality" ) ; // 미리 정의된 요소에서 품질을 채웁니다.따라서 미리 정의된 요소의 특성과 목적은 매우 간단합니다. 데이터베이스 테이블에 저장되는 방식과 일반 요소와 어떻게 다른지 살펴보겠습니다.
차이점
테스트 구성에서는 "Products" 디렉터리가 생성되었습니다. "Test Elements" 그룹이 생성되었습니다. 기사 시작 부분의 스크린샷에서 그룹의 내용을 볼 수 있습니다. "제품" 디렉터리의 경우 SQL 데이터베이스에는 다음 구조의 해당 테이블 "_Reference37"이 있습니다.
하지만 세부 정보가 구성 트리 및 SQL 테이블의 필드와 일치하는지 어떻게 확인할 수 있습니까?
우리는 테이블 구조에 대한 설명과 함께 값 테이블을 반환하는 표준 전역 컨텍스트 메서드 "GetDatabaseStorageStructure()"를 사용할 것입니다.
값의 "필드" 테이블에서는 SQL 테이블의 필드와 메타데이터 트리의 개체 세부 정보 간의 대응 관계를 볼 수 있습니다. 이 예에서는 "Products" 디렉터리의 구조를 고려합니다. 모든 디렉토리에는 부울 유형의 표준 속성 "미리 정의됨"이 있으며, 이는 사전 정의된 요소에 대해 TRUE로 설정됩니다.
데이터베이스의 디렉터리 저장 구조가 포함된 테이블을 기반으로 하면 "사전 정의" 필드가 "IsMetadata" 필드에 해당한다고 확실히 말할 수 있습니다. SQL 데이터베이스의 "_Reference37" 테이블 내용을 살펴보면 다음과 같은 내용을 볼 수 있습니다.
사전 정의된 요소에 대한 항목에서 "IsMetadata" 필드의 값은 TRUE 플래그에 해당하는 "0x01"로 설정됩니다. 일반 요소의 경우 값은 "0x00"으로 설정됩니다. 이것이 미리 정의된 요소와 일반 요소의 주요 차이점입니다. 다른 모든 필드는 사용자가 추가한 일반 항목의 필드와 동일한 방식으로 데이터베이스에 저장됩니다.
미리 정의된 요소는 매우 흥미로운 용도로 사용될 수 있습니다. 도움을 받으면 요소 그룹이 추가될 수 있는 디렉터리 및 기타 개체에서 삭제/삭제 표시되는 것을 방지할 수 있습니다. "Test Elements" 그룹을 삭제하거나 삭제 표시를 하려고 하면 그러면 다음과 같은 오류가 발생합니다.
따라서 미리 정의된 요소는 해당 요소가 배치된 그룹도 "미리 정의"되게 만듭니다.
완성
사전 정의된 요소는 대부분의 구성에서 필수적인 부분입니다. 이를 사용하면 개발이 단순화되고 기능 구성이 논리적으로 더욱 "조화롭고" 통합적으로 만들어집니다.
네 번째 수업에서는우리는 계속해서 프로그램에 대해 알아갈 것입니다. 오늘 우리는 실제적인 예와계층적 디렉터리를 학습하고 사전 정의된 요소를 만드는 방법도 알아보세요..
코스 4회 수업 시간:
00:19
과정 3과의 숙제를 완료한 후 Employees 디렉터리의 변경 사항
00:35
디렉토리의 세부정보 순서 편집
02:54
디렉토리 생성
03:40
계층적 디렉터리 생성 및 설정
05:10
명명법 디렉터리에 서비스 및 제품 그룹 만들기
06:05
명명법 디렉토리 작성
07:14
디렉토리 항목을 다른 그룹으로 전송하는 3가지 방법
08:21
창고 디렉토리 생성
09:19
사전 정의된 디렉토리 요소 생성
11:25
창고 디렉토리 작성
12:20
4과 자료에 대한 시험을 치르세요.
계층적 디렉터리– 해당 요소를 계층적으로 배열할 수 있는 디렉토리입니다. 예를 들어 Nomenclature 디렉토리에는 제품, 서비스 등의 그룹을 생성할 수 있으며, 여기에 해당 그룹에 속한 요소가 있습니다. 또한 디렉터리 그룹에는 다른 그룹이 포함될 수 있으므로 다단계 계층 구조가 생성됩니다.
또한 디렉터리는 디렉터리 요소가 그룹이 아닌 동일한 디렉터리의 다른 요소와 관련되는 또 다른 유형의 계층 구조도 지원합니다. 이러한 유형의 계층 구조( 요소 계층)은 예를 들어 하나의 디비전(이 경우 디비전은 그룹이 아니라 디렉토리의 요소임)이 여러 다른 디비전을 포함할 수 있는 디비전 디렉터리를 생성할 때 사용할 수 있습니다. 이러한 유형의 계층 구조는 거의 사용되지 않습니다.
디렉토리 양식– 디렉토리의 시각적 표현. 디렉토리로 수행하려는 특정 작업에 따라 디렉토리를 "다른 보기"로 표시해야 합니다. 그래서 4강에서는 목록 형태와 디렉토리 요소 형태로 세부사항의 순서를 편집했습니다.
시스템은 자동으로 양식을 생성(생성)하지만 필요한 경우 개발자가 독립적으로 양식을 "그릴" 수 있습니다.
디렉토리에는 총 5가지 양식(양식 유형)이 있습니다.
- 요소 모양– 디렉토리 요소를 생성하거나 편집합니다.
- 그룹 모양- 디렉토리 그룹을 생성하거나 편집합니다.
- 목록 양식– 디렉토리 요소 목록을 표시합니다.
- 선택 양식- 특정 형식의 필드에서 이 디렉토리의 요소 중 하나를 선택하는 데 사용됩니다. 예를 들어, 창고 필드의 입고 문서에 있는 창고 디렉토리에서 특정 창고를 선택하려면 다음과 같이 하십시오.
- 그룹 선택 양식– 특정 형식의 필드에서 이 디렉토리의 그룹 중 하나를 선택하는 데 사용됩니다.
사전 정의된 디렉터리 요소– 구성자 모드에서 개발자가 생성한 디렉토리 요소이며 내장된 1c 언어에서 이름으로 액세스할 수 있습니다.
일반 디렉토리 요소와 사전 정의된 디렉토리 요소 사이에는 근본적인 차이가 있습니다. 일반 요소는 구성이 일정하지 않습니다. 사용자 작업 중에 요소가 생성, 편집 및 삭제될 수 있으므로 알고리즘을 실행할 때 의존해서는 안 됩니다(요소의 코드 및 이름은 사용자가 변경할 수 있음).반면에 미리 정의된 요소는 영구적입니다. 작동 중에 사용자가 해당 요소의 이름을 바꾸더라도 내장된 1c 언어에서 액세스할 수 있습니다. 이는 미리 정의된 요소에 소품을 가짐으로써 달성됩니다. 이름, 이는 사용자가 사용할 수 없습니다. 일반 디렉터리 요소에는 이러한 속성이 없습니다.
중요한! 기술적으로 사용자는 미리 정의된 디렉터리 요소를 삭제할 수 있지만 일반적으로 사용자에게는 미리 정의된 디렉터리 요소를 삭제할 수 있는 권한이 거부됩니다.
해당 과정의 4과 숙제
강좌의 네 번째 수업에 대한 숙제는 이론 시험을 성공적으로 마친 후 즉시 제공됩니다.
