계산 레지스터의 기본 치수 속성입니다. 복잡한 주기적 계산 1c 언어로 계산 가능

계산 레지스터로 작업할 때 기본 데이터를 얻을 수 있습니다. 이는 레지스터 회전율을 계산하는 독특한 방식으로, 회전율을 계산하는 기능은 단순히 특정 기간 동안의 측정값으로 레지스터 자원을 합산하는 기능이 아니라 더 많은 것을 나타냅니다. 복잡한 기능. 이 기능은 계산 레지스터에 할당된 계산 유형 계획의 상태에 따라 달라지므로 사용자가 제어합니다.

이 섹션에서는 시스템에서 기본 데이터를 얻는 두 가지 기존 방법, 즉 쿼리 언어를 사용하는 방법과 기능적 표기법을 사용하는 방법을 살펴보겠습니다. GetBase(). 이 경우 "기본" 계산 레지스터를 기본 데이터를 얻는 데 필요한 레지스터라고 부르며 "기본" 레지스터(일반적인 경우 여러 개가 있을 수 있음)는 자원의 합산이 수행됩니다.

우리는 이러한 방법을 자세히 고려하지 않고 차이점과 적용 범위만 고려할 것입니다.

GetBase() 메서드

방법 GetBase()객체에 대해 정의됨 계산 RegisterManager.<Имя регистра расчета> 그리고 계산 RegisterRecord.<Имя регистра расчета> . 이 방법을 사용하면 매출액을 얻는 데 필요한 기본 레지스터의 리소스를 지정하고, 매출액을 얻는 데 필요한 컨텍스트에서 필드를 설정하고, 기본 계산과 기본 계산의 측정을 비교하기 위한 규칙을 설정할 수 있습니다. 레지스터.

계산 레지스터 레코드 일치 규칙은 구조에 의해 지정되며, 각 요소는 기본 레지스터의 특정 차원에 대한 기본 계산 레지스터의 차원 목록을 지정합니다. 구조 요소의 이름은 주 레지스터의 차원 이름과 일치해야 하며 구조 요소의 값은 쉼표로 구분된 기본 레지스터의 차원 목록과 함께 문자열이어야 합니다. 특정 차원의 이름을 가진 구조 요소가 지정되지 않으면 해당 차원에 조건이 적용되지 않음을 의미합니다.

기본 레지스터의 차원 이름과 리소스는 다음 형식으로 지정됩니다.<ИмяРегистраРасчета>.<ИмяПоля>.

방법 사용 예:
코드 1C v 8.x 리소스 = 새 어레이(1);
Resources = "기본 발생. 결과, 추가 발생. 결과";

Dimensions = New Structure("개인, 조직");
Dimensions.Individual = "BasicAccruals.Individual,AdditionalAccruals.Employee";
Dimensions.Organization = "기본 적립.조직,추가 적립.조직";

컷 = 새 배열(1);
Sections = "주요 발생액. 방법, 추가 발생액. 방법";
// baseBase 데이터 테이블 계산 = Calculation Register.Deductions.GetBase(Selection,
// 리소스, 차원, 섹션);

위의 예에서 매출액을 받을 때 주 등록의 "개인" 차원은 "기본 발생" 기본 등록의 "개인" 차원 및 "추가 발생" 기본 등록의 "직원" 차원과 비교됩니다. .

기본 데이터 획득을 위한 쿼리 언어 테이블
기본 데이터를 얻기 위해 쿼리 언어로 가상 테이블을 정의합니다. "계산 레지스터.<Имя регистра расчета>.베이스<Имя базового регистра расчета>" . 가상 테이블의 매개변수는 메인 레지스터의 크기, 기본 레지스터의 크기 및 기본 데이터를 얻는 데 필요한 컨텍스트의 필드입니다. 치수 및 컷은 치수 이름이 포함된 문자열의 배열(또는 값 목록)로 지정됩니다.

기본 데이터의 가상 테이블을 사용하여 쿼리를 작성하는 예:
코드 1C v 8.x
Dimensions1 = 배열(2);
Dimensions1 = "개인";
Dimensions1 = "조직";

Dimensions2 = 배열(2);
Dimensions2 = "직원";
Dimensions2 = "조직";

컷 = 새 배열(1);
컷 = "방법";

쿼리 텍스트 = "개인 선택, 계산 유형, AMOUNT(ResultBase)
|발신
|SELECT 개인, 계산 유형, ResultBase
| FROM 계산 Register.Deduction.BaseMainAccruals(&Dimensions1,&Dimensions1,&Aspects)
|어디에서 " + ConditionMain + "
| 모두 결합
|SELECT 직원, 계산 유형, ResultBase
| FROM 계산 Register.Deduction.BaseAdditionalAccruals(&Dimensions1,&Dimensions2,&Actions)
|WHERE " + ConditionAdditional + "
|) 베이스로
|그룹별
| 개인,
| 계산 유형
|";

요청 = 새 요청(RequestText);
Query.SetParameter("차원1", 차원1);
Query.SetParameter("차원2", 차원2);
Query.SetParameter("섹션", 섹션);

// ...WHERE 문의 조건에 사용되는 추가 요청 매개변수 설정// ,..
// 쿼리 선택 가져오기 resultSelection = Query.Execute().Select();

위의 예에서는 GetBase() 메서드의 예와 동일한 데이터 구조와 동일한 문제를 해결한다고 가정합니다. 동시에 소스 코드와 그 복잡성이 눈에 띄게 증가하는 것을 볼 수 있습니다.

비교
기본 데이터를 얻는 함수형 방식과 쿼리를 이용하여 얻는 함수형 방식의 눈에 띄는 차이점은 함수형 방식은 한 번의 메소드 호출로 모든 베이스 레지스터에 대한 기본 데이터를 얻을 수 있으며, 쿼리를 이용하면 기본 데이터를 얻는다는 점이다. 기본 레지스터 수에 따라 여러 테이블을 쿼리합니다. 그러나 데이터를 검색하는 권장 방법은 쿼리를 사용하여 데이터를 검색하는 것입니다. 예를 들어 이를 통해 기본 유형의 계산에서 데이터를 얻을 수 있을 뿐만 아니라 계산에 필요한 추가 정보도 얻을 수 있습니다.

쿼리의 경우 실행 코드의 명백한 복잡성에도 불구하고 함수형 메서드를 사용하여 데이터를 검색하는 성능과 쿼리를 사용하는 성능은 동일합니다.

GetBase() 메서드를 사용하는 짧은 기능 표기법은 기본 데이터 외에 다른 데이터가 필요하지 않고 동시에 코드 줄에 "저장"하려는 경우에만 허용됩니다. 코드 성능상의 이유로 GetBase() 메서드를 사용한 후에도 쿼리를 사용하여 계산하기 위해 추가 데이터를 얻어야 하는 경우에는 GetBase() 메서드를 사용하는 것이 전혀 허용되지 않습니다.

또 다른 고려 사항은 기본 데이터를 선택하기 위한 조건에 관한 것입니다. 실제로 GetBase() 메서드의 경우 하나의 레코드나 특정 등록자(특정 차원별로 선택) 외에는 기본 데이터를 얻을 수 있는 방법이 없습니다. 요청이 있는 경우 개발자는 레코드 선택을 위한 쿼리 언어의 모든 기능을 마음대로 사용할 수 있습니다.

아시다시피 1C 플랫폼은 데이터를 읽을 때 데이터베이스 테이블에 액세스합니다. 그러나 레지스터의 경우 실제 테이블을 기반으로 하는 1C 플랫폼은 다음을 생성할 수 있습니다. 가상 테이블, 이는 데이터베이스에 물리적으로 저장되지 않습니다. 이를 통해 개발자는 실제 테이블에 복잡한 쿼리를 하는 대신 간단한 쿼리만으로 가상 테이블에서 데이터를 즉시 얻을 수 있습니다. 또한 발생할 수 있는 오류도 제거됩니다. 따라서 가능하면 항상 가상 테이블을 사용해야 합니다. 특히 1C: 전문가 시험에 합격할 때. 고려해 봅시다 다른 유형레지스터를 살펴보고 플랫폼이 각 레지스터 유형에 대해 제공하는 가상 테이블을 확인하세요.

정보 레지스터

플랫폼은 주기적 정보 레지스터에 대해서만 가상 테이블을 생성합니다. 다음 유형을 사용할 수 있습니다.

  • 첫 번째 조각
  • 최후의 조각

누적 레지스터

누적 레지스터의 경우 제공되는 가상 테이블 세트도 레지스터 유형에 따라 다릅니다. 아시다시피 누적 레지스터에는 두 가지 유형이 있습니다. 나머지그리고 혁명

잔액 누적 등록

다음과 같은 가상 테이블을 사용할 수 있습니다.

  • 나머지
  • 혁명
  • 잔존 및 회전율

회전수 누적 레지스터

가상 테이블은 하나만 사용 가능

  • 혁명

계산 레지스터

여기에서는 설정에 따라 다음과 같은 가상 테이블도 사용할 수 있습니다.

회계 기록부

회계 레지스터에는 가장 큰 가상 테이블 세트가 있습니다.

  • 나머지
  • 혁명
  • 매출액DtKt
  • 잔존 및 회전율
  • 서브콘토
  • 무브먼트Subconto

그러나 회계 등록부에 액세스하는 속도는 가장 낮습니다. 따라서 누적 레지스터를 사용하여 동일한 잔액이나 매출액을 얻는 것이 가능하다면 이를 사용해야 합니다.

계산 레지스터- 애플리케이션 구성 개체입니다. 이는 복잡한 주기적 계산 메커니즘에 사용되며 수행해야 하는 특정 유형의 계산에 대한 기록을 저장하고 중간 데이터와 계산 결과 자체를 저장하는 데 사용됩니다.

구조

계산 레지스터의 정보는 기록 형태로 저장되며, 각 기록에는 측정 값과 해당 리소스 값이 포함됩니다.

측정레지스터는 정보가 저장되는 섹션을 설명합니다. 자원레지스터에는 저장된 정보가 직접 포함됩니다. 예를 들어, 계산 레지스터의 경우 조직 직원의 기본 발생액, 이는 다음과 같은 구조를 가지고 있습니다:

데이터베이스에 저장된 레코드는 다음과 같습니다.

계산 유형 계획과의 관계

계산 레지스터는 애플리케이션 솔루션에 존재하는 계산 유형 계획 중 하나와 연결됩니다. 이 관계로 인해 각 레지스터 항목에는 필드가 있습니다. 계산 유형, 덕분에 레지스터 메커니즘은 계산 기록이 서로에게 미치는 상호 영향을 추적할 수 있습니다.

주기성

계산 레지스터는 생성된 측정값뿐만 아니라 시간 측면에서도 데이터를 저장합니다. 이것이 각 계산 레지스터 항목에 대해 하나 이상의 필수 필드가 존재하는 이유입니다. 타당성. 계산 레지스터를 생성할 때 개발자는 항목이 레지스터에 입력되는 최소 빈도를 지정할 수 있습니다.

레지스트라에 대한 종속

계산 기록부 상태의 변경은 일반적으로 전표가 전기될 때 발생합니다. 따라서 각 등록 항목은 특정 문서(등록 기관 및 이 문서의 줄 번호)와 연결됩니다. 등록부에 항목을 추가하고 변경하고 삭제하는 것은 하나의 문서와 관련된 모든 항목에 대해 동시에만 가능합니다.

타임라인과의 관계

계산 레지스터는 시간 일정에 연결될 수 있습니다. 타임라인은 계산과 관련된 소스 데이터의 시간 다이어그램을 포함하는 정보의 레지스터입니다. 예를 들어 이 일정의 차원은 작업 일정 및 날짜일 수 있으며 리소스는 해당 날짜의 근무 시간 수일 수 있습니다. 그런 다음 계산 등록 항목을 특정 작업 일정과 연관시킬 수 있으며 향후 내장 언어를 사용하여 계산을 수행하는 데 필요한 작업 시간에 대한 정보를 얻을 수 있습니다.

예를 들어 다음 구조의 타임라인이 있습니다.

재계산

계산 레지스터에는 특수 개체가 포함될 수 있습니다. 재계산:

이러한 개체에서 시스템은 계산 레지스터의 어떤 항목이 관련성을 잃었는지에 대한 정보를 저장하고 기본 기간에 대한 종속성 메커니즘의 작동 및 유효 기간에 대한 제거의 결과로 재계산 대상이 됩니다.

기록의 고유성

시스템은 계산 레지스터에 저장된 레코드의 고유성을 제어합니다. 따라서 계산 레지스터에는 동일한 문서의 동일한 줄과 관련된 두 개의 항목이 포함될 수 없습니다.

계산 레지스터에 의해 구현되는 메커니즘

유효 기간 선점 메커니즘을 사용하면 등록부에 포함된 다른 항목의 분석을 기반으로 정산 등록 항목의 실제 유효 기간을 계산할 수 있습니다.

일반적으로 결제 등록 항목에는 해당 항목이 유효한 기간을 정의하는 두 개의 날짜가 포함됩니다. 이 기간을 입국유효기간이라고 합니다. 그러나 주어진 항목과 관련된 계산 유형이 다른 계산 유형으로 대체될 수 있는 경우 해당 항목의 유효 기간은 "요청된" 기간일 뿐입니다. 즉, "우리는 이 기간 동안 항목이 유효하기를 원합니다. .” 실제로 이 기록의 실제 유효 기간은 이러한 계산 유형을 대체하는 계산 유형의 모든 기록을 유효 기간별로 분석한 후에만 결정될 수 있습니다. 실제 유효 기간은 출품작의 원래 유효 기간의 하위 집합인 기간 집합입니다. 유효 기간 측면에서 주어진 기록을 대체하는 기록이 발견되지 않으면 이 기록의 실제 유효 기간은 유효 기간과 동일합니다. 평생 퇴거의 또 다른 극단적인 경우는 특정 기록이 다른 기록에 의해 완전히 축출되는 경우입니다. 이 경우 실제 응모 유효 기간은 없습니다.

각 결제 등록 항목에는 관련된 결제 유형이 포함되어 있습니다. 유효 기간별로 특정 항목을 대체해야 하는 항목을 결정하기 위해 급여 기록부는 급여 유형이 서로에게 미치는 상호 영향을 설명하는 급여 유형 계획에 대한 링크를 사용합니다. 이 관계를 사용하면 급여 기록부가 각 항목의 실제 유효 기간을 결정할 수 있습니다.

기본 기간 종속 메커니즘을 사용하면 레지스터에 포함된 다른 항목의 분석을 기반으로 계산 레지스터 항목의 기본 값을 얻을 수 있습니다.

베이스는 숫자 값, 이 항목의 결과를 계산하는 데 사용해야 합니다. 기준은 해당 항목이 기준 기간 동안 종속된 다른 항목의 계산 결과를 분석하여 계산됩니다. 따라서 일반적인 경우 계산 레지스터 레코드에는 이러한 유형의 계산이 기준에 따라 달라지는 계산 유형의 레코드를 분석하는 데 필요한 기간, 즉 기준 기간을 결정하는 두 개의 날짜가 포함되어 있습니다. 계산 유형 계획에 대한 링크를 사용하면 계산 레지스터가 기본 기간 동안 특정 계산 유형이 의존하는 계산 유형을 결정할 수 있습니다.

계산 레지스터는 기본 기간에 대한 두 가지 유형의 종속성을 지원합니다.

  • 유효 기간에 대한 의존성;
  • 등록 기간에 따라 다릅니다.

유효 기간에 의존하는 경우, 기준을 얻기 위해 실제 유효 기간과 이 기록의 기준 기간의 교차점이 발견된 기록이 선택됩니다. 특정 영향을 미치는 기록에서 얻을 수 있는 기반의 가치는 일반적으로 해당 기록에 포함된 결과와 동일하지 않습니다. 기준은 지정된 기준 기간과 중복되는 영향 기록의 실제 기간에 비례하여 계산됩니다. 이 레코드와 관련된 차트 데이터가 사용됩니다.

등록 기간에 의존하는 경우, 기준을 얻기 위해 "등록 기간" 필드 값을 기준으로 이 레코드의 기준 기간에 해당하는 기록의 계산 결과가 선택됩니다.

기본 기간에 대한 종속성의 가장 복잡한 버전은 이 레코드의 계산 유형에 대해 "유효 기간이 기본 기간입니다" 속성이 설정된 경우입니다. 이 속성은 이 레코드의 기준 기간이 레코드의 해당 필드에 지정된 기준 기간이 아니라 퇴거 메커니즘의 작동 결과로 얻은 레코드의 실제 유효 기간이 사용됨을 의미합니다. 유효 기간은 일반적으로 일부 기간의 집합입니다.

재계산 레코드를 생성하는 메커니즘은 기존 레코드의 계산 결과에 영향을 미치는 레코드가 레지스터에 나타나는 사실을 모니터링합니다. 분석 결과, 새로운 기록이 기존 기록에 영향을 미칠 가능성이 판단됩니다. 상호 영향계산 유형 및 기본 기간에 대한 동작 및 의존 기간에 대한 변위 메커니즘의 작동을 기반으로 합니다.

재계산 레코드를 생성하는 메커니즘의 결과는 어떤 레지스터 항목을 재계산(재계산)해야 하는지에 대한 정보가 포함된 재계산 레코드 세트입니다.

계산 등록 양식

사용자가 계산 레지스터에 포함된 데이터를 볼 수 있도록 시스템은 계산 레지스터를 표시하는 형식(목록 형식)을 지원합니다. 이를 통해 여러 기준에 따라 표시된 정보를 정렬하고 선택할 수 있습니다.

시스템에서 자동으로 이 양식을 생성할 수 있습니다. 이와 함께 개발자는 계산 레지스터 항목을 추가, 변경 및 삭제할 수 있는 레코드 세트 양식을 포함하여 시스템이 기본 양식 대신 사용할 자신의 양식을 만들 수 있습니다.

계산 레지스터 기능

계산 레지스터가 개발자에게 제공하는 주요 기능은 다음과 같습니다.

  • 지정된 기준에 따라 주어진 간격으로 레코드를 선택하는 단계;
  • 레지스트라에 의한 기록 선택;
  • 지정된 선택을 만족하는 레지스터 엔트리에 대한 기본 값을 획득하는 단계;
  • 주어진 선택을 만족시키는 레지스터 엔트리에 대한 스케줄 데이터를 획득하는 단계;
  • 재계산 대상 기록에 대한 데이터 획득
  • 레지스터에 대한 일련의 레코드 읽기, 수정 및 쓰기.

데이터베이스에 대한 모든 변경 사항은 해당 테이블에 저장됩니다. 1C의 경우 문서, 문서 저널, 디렉토리 및 레지스터 테이블입니다. 1C 레지스터의 유형, 기능 및 사용의 미묘함은 우리 기사에서 논의됩니다.

레지스터의 항목 형성

레지스터에 대한 첫 번째 질문 중 하나는 무엇을 위한 것인가입니다.

종종 기존 레코드를 복제하면서 별도의 테이블을 만들어야 하는 이유는 무엇입니까?

여기에 대한 대답은 매우 간단합니다. 물론 선택 조건을 나열하고 삭제 표시 및 완료를 확인하여 복잡하고 시간이 많이 걸리는 쿼리를 원본 문서 테이블로 격리할 수 있지만 특정 조각을 만드는 것이 훨씬 간단하고 노동 집약적입니다. 문서를 저장할 때 일련의 기록을 직접 저장하고 별도의 테이블에 저장하여 필요에 따라 액세스할 수 있습니다.

그리하여 우리는 레지스터 항목을 생성하는 방법 중 하나가 레지스트라(문서)를 사용하여 작성하는 것임을 알게 되었습니다. 이 옵션은 모든 레지스터 유형에 존재합니다.

문서를 기반으로 등록 레코드를 생성하는 프로세스를 일반적으로 문서 게시라고 합니다. 게시되지 않은 문서 문서는 기록부에 이동이 없으며 실제로는 초안 또는 공백입니다.

레코드를 생성하는 두 번째 옵션은 등록 문서를 생성하지 않고 직접 생성하는 것입니다. 이 방법으로 정보 레지스터에서만 레코드를 생성할 수 있으며, 레지스터 속성에서 "Record mode" 속성에 적절한 값이 있어야 합니다(그림 1).

모든 레지스터에 공통

모든 레지스터의 내부 구조는 그림 2에서 확인할 수 있습니다.

그림 2

좀 더 자세히 살펴보겠습니다:

  • 차원 – 저장되는 섹션을 결정하는 레코드의 속성입니다. 중요한 정보;
  • 자원 – 체계화해야 할 정보가 포함되어 있습니다.
  • 세부 정보 – 추가 정보가 포함된 레코드 필드입니다.
  • 양식 – 목록, 요소 등의 모양에 대한 그래픽 정보가 포함된 속성입니다. 및 내부 모듈;
  • 레이아웃 – 인쇄된 형태의 레지스터.

정보 레지스터

위에서 정보 레지스터에 대해 이야기했으므로 이에 대해 이야기해 보겠습니다.

이것은 아마도 가장 간단하고 이해하기 쉬운 유형의 레지스터일 것입니다. 정보가 저장되는 열과 열을 포함하는 일반 테이블입니다.

정보 레지스터의 중요한 속성 목록은 작습니다(그림 3). 주요 속성에 대해 이야기해 보겠습니다.

그림 3

  1. 주기성, 이는 기록의 고유성이 제어되는 정도를 나타냅니다(1분, 1시간, 1일, 1년 내에 선택한 값에 따라 동일한 측정값을 갖는 두 개의 기록이 존재할 수 없음). 값도 사용할 수 있습니다. 녹음기로”를 선택하지만 이를 위해서는 적절한 녹음 모드를 선택해야 합니다.
  2. 녹음 모드는 실제로 "독립"과 "녹음기에 제출"이라는 두 가지 값 중 하나를 선택합니다.
    1. 독립 모드를 선택한다고 해서 문서에 의해 기록이 생성될 수 없다는 의미는 아니며 등록 기관에 의한 선택 및 기록 고유성 제어만 불가능하다는 것을 이해하는 것이 중요합니다.
  3. 첫 번째 조각에 대한 총계 허용 및 마지막 조각에 대한 총계 허용: (두 점을 하나로 결합해 보겠습니다.) – 해당 확인란을 선택하면 추가 테이블을 사용하여 정보 레지스터에 대한 요청이 이루어질 수 있습니다. 첫 번째 및 마지막 조각)에는 해당 데이터 세트가 포함되어 있습니다. 이 테이블의 매개변수는 데이터를 선택하는 데 필요한 날짜입니다.

누적 레지스터

우리는 그림 2에서 그 중 하나의 구조를 보았습니다. 레지스터의 외관과 내부 구조에 큰 영향을 미치는 주요 속성은 "Register Type"입니다(그림 4).

저장된 정보에 대한 요구 사항에 따라 다음 값을 사용할 수 있습니다.

  • 나머지;
  • 혁명.

첫 번째 경우, 데이터베이스에는 차원 측면에서 자원 이동에 대한 정보뿐만 아니라 운영 유형(영수증 또는 비용)에 대한 정보도 포함됩니다. 또한 쿼리를 생성할 때 합계가 포함된 추가 테이블을 사용할 수 있습니다.

쿼리에서 잔액 및 잔액 및 회전율 테이블을 사용할 때 초보 개발자가 직면하는 주요 문제 중 하나는 쿼리가 특정 날짜에 대한 잔액을 수신할 때 이러한 테이블의 데이터가 다를 수 있다는 것입니다. 여기에는 한 가지 미묘한 차이가 있습니다. 특정 값을 기간 종료 날짜로 지정하면 플랫폼은 선택 기간에 이 값을 포함하지 않고 Remaining 테이블에서 데이터를 가져옵니다.

기간 종료를 포함하는 데이터가 필요한 경우 다음을 수행할 수 있습니다.

  • 잔액 및 매출액 테이블을 사용하십시오.
  • 지정된 날짜보다 1초 큰 날짜에 대한 샘플을 만듭니다(예: 12/31/16 23:59:59가 아니라 01/01/17 00:00:00).
  • 고려 중인 기간의 특정 시점을 포함하는 옵션을 구성하는 데 도움이 되는 Boundary 메서드를 사용합니다(사용 사례: Boundary(EndDate,Inclusive).

회계 기록부

매우 특수화된 레지스터는 설계상 누적 레지스터와 유사합니다. 1C 플랫폼의 다른 유형의 레지스터와의 주요 차이점은 속성 구조에 "계정 차트" 매개변수가 있다는 것입니다(그림 5).

그림 5

계정과목표는 별도의 논의가 필요한 별도의 메타데이터 개체입니다. 계정과목표에 따라 최신 표준 1C 구성에는 4개의 주요 회계 레지스터가 포함됩니다.

  1. 예산 편성;
  2. 국제적인;
  3. 세;
  4. 자립.

회계 기록부의 두 번째 매개변수 특성은 "대응"입니다.

이 상자를 선택하면 신용 계정 AccountKt, 차변 계정 AccountDt 및 이러한 계정에 해당하는 분석(subconto)을 포함하는 이중 항목을 생성할 수 있습니다. 확인란을 선택하지 않으면 등록 항목에 하나의 계좌만 입력됩니다.

계산 레지스터

이것은 아마도 이해하기 가장 어려운 레지스터일 것입니다. 한편, 본질적으로 이는 "회전율" 유형의 누적 레지스터와 매우 유사합니다.

계산 레지스터와 다른 레지스터 간의 정의적인 차이점은 "계산 유형 계획" 매개변수의 속성에 존재한다는 것입니다. 또한 계산 레지스터와 정보 레지스터는 주기적입니다.

각 계산 레지스터에서는 해당 정보 레지스터에 지정된 시간 일정과 기록을 연결하는 기능을 활성화할 수 있습니다. 이를 통해 코드를 사용하여 근무 시간 데이터를 얻을 수 있습니다.

다른 유형의 레지스터에서 사용할 수 있는 차원, 리소스 및 양식 외에도 계산 레지스터에는 관련이 없고 수정이 필요한 기록에 대한 정보가 저장되는 "재계산" 개체가 할당될 수 있습니다.

그들의 주요 용도는 일반적인 구성 1C – 조직 직원의 적립을 통한 업무 등록 및 촉진.

계산 레지스터를 사용하여 해결되는 작업 중 하나는 기본 데이터의 가상 테이블 또는 GetBase() 메서드에 대한 쿼리를 사용하여 레지스터 회전을 얻는 것입니다. 레지스터 회전율은 계산 유형 계획의 설정 및 내용, 계산 레지스터 설정, 기본 데이터의 가상 테이블 매개변수 등을 포함하여 다양한 소스 데이터를 기반으로 획득됩니다. 그러나 기본 데이터를 얻는 데 중요한 역할 중 하나는 계산 레지스터 측정입니다.

기본 데이터의 가상 테이블을 매개변수화하는 차원의 역할

기본 데이터의 가상 테이블의 중요한 매개변수 중 하나는 데이터를 합산할 때 레지스터 항목을 비교하는 차원 목록입니다. 다양한 문제를 해결하려면 다양한 차원 집합에 걸쳐 레지스터 리소스를 합산해야 할 수도 있습니다. 급여를 계산하고 3차원을 갖는 레지스터의 예를 살펴보겠습니다.

  • 조직,
  • 개인,
  • 재분.
다음 문제를 해결하는 것이 필요하다고 상상해 봅시다.
  • 원본 기록과 동일한 부서를 가진 모든 기록에 대한 매출 기록의 특정 기록을 얻습니다. 예를 들어 전체 부서의 발생액에 따라 수당을 계산할 수 있습니다.
  • 동일한 개인 및 부서의 기록에서 매출액을 얻습니다. 저것들. 동일한 부서에서 그에게 발생한 직원 발생액을 받습니다(다른 부서에서 받은 동일한 직원에 대한 발생액은 제외).
  • 동일한 개인 및 동일한 조직의 기록에서 매출액을 수신합니다(동일한 조직 내의 개인에 대한 모든 발생액).

위의 모든 작업은 기본 데이터의 가상 테이블에 대한 쿼리를 사용하여 해결됩니다. 이 경우 "메인 레지스터 측정" 및 "기본 레지스터 측정" 매개변수는 세 가지 작업 모두에 대해 다릅니다. 첫 번째 경우에는 "부서"라는 하나의 차원이 있습니다. 두 번째 - "개인"과 "단위"; 세 번째 - "조직"과 "개인".

기준 데이터 수집 최적화

위에 나열된 경우, 기본 데이터의 가상 테이블에 대한 쿼리를 생성할 때 시스템은 쿼리 언어 측면에서 동일한 테이블을 사용하여 계산 레지스터 테이블의 "왼쪽 조인"을 수행합니다. 이 경우 연결 조건 중 하나는 기본 레지스터와 기본 레지스터의 차원으로 지정된 필드의 값이 동일하다는 것입니다. 물론 이 조건 외에도 유효기간이나 등록기간과 기준기간의 시작과 끝의 비교, 계산방식의 비교 등이 있으나 가장 "엄격한" 제한은 원칙적으로 측정값의 한계입니다.

따라서 결과 쿼리가 효과적으로 작동하려면 비교 차원의 필드를 첫 번째 필드로 포함하는 계산 레지스터 테이블에 인덱스를 갖는 것이 중요합니다.

계산 레지스터의 차원을 인덱싱하는 기능을 사용하면 이러한 문제를 해결할 수 있지만 한 차원을 비교하는 경우에만 해당됩니다(이 예에서는 부서의 데이터를 얻는 작업). 비교 가능한 차원이 2개 이상인 경우 여러 차원에 대한 인덱스를 동시에 구축해야 합니다.

이것이 바로 계산 레지스터의 기본 차원 속성을 통해 해결할 수 있는 문제입니다. 이 속성을 여러 차원으로 설정하면 구성 디자이너는 "기본"으로 표시된 모든 차원에 인덱스를 생성합니다(자세한 내용은 "데이터베이스 테이블 인덱스" 섹션 참조).

위에서부터 특정 차원을 선택하여 기본 데이터 획득을 최적화하기 위해 계산 레지스터에 대해 그러한 인덱스를 하나만 생성할 수 있다는 것이 분명합니다. 따라서 개발 중에 어떤 가상 테이블이 가장 자주 사용될지, 어떤 가상 테이블의 성능 최적화가 가장 중요한지 정확하게 평가하는 것이 중요합니다.

우리의 예로 돌아가 보겠습니다. 개인 및 부서에 대한 데이터를 획득해야 하는 발생은 개인 및 조직에 대한 데이터를 획득해야 하는 발생보다 구성 작업 중에 덜 일반적일 것이라고 가정해 보겠습니다. 그런 다음 "조직" 및 "개인" 차원을 기본 차원으로 기록해야 합니다. 동시에 개인과 부서에 대한 기본 데이터를 얻는 것이 상대적으로 느리다는 사실도 감수해야 합니다.

기본 측정을 ​​선택할 때 "선택성"도 평가해야 합니다. 구성을 운영할 때 특정 차원에 얼마나 많은 값이 있을지 상상해보세요. 이 예에서 한 개인이 매우 적은 수(1~2개)의 조직과 상대적으로 많은 부서를 갖고 있다고 가정해 보겠습니다. 저것들. 개인은 거의 항상 한 조직에 대해 급여를 지급받으며 동시에 여러 부서에 대해 급여가 계산되는 경우가 많습니다. 이러한 상황에서는 "개인" 및 "부서" 차원을 기본 차원으로 선택하는 것이 더 합리적입니다.

하지만 계산 레지스터의 측정 순서를 기억하는 것이 중요합니다.

계산 레지스터의 측정 순서 정보

사실 기본 데이터를 쉽게 얻을 수 있는 인덱스를 생성할 때 시스템은 구성 트리에 있는 순서대로 차원을 포함합니다. 즉, "개인" 및 "부서" 차원을 "전환"하면 인덱스의 필드 순서가 변경됩니다.

이 예에서 "개인" 및 "부서" 차원을 기본 차원으로 선택한 다음 이를 재정렬하면 개인 및 부서에 대한 기본 데이터를 얻는 속도는 변경되지 않지만 상황이 급격히 악화됩니다. 개인 및 조직에 대한 데이터를 수집합니다. "조직" 및 "개인" 필드의 값을 비교할 때 "개인" 필드가 첫 번째 필드가 아니고 조건이 적용되지 않기 때문에 시스템은 부문+개인 색인을 사용할 수 없습니다. 부서. 그리고 개인+부서 지수의 경우에는 “개인” 항목이 1순위가 되기 때문에 부서와 개인에 대한 기초자료 접수와 조직과 개인에 대한 기초자료 접수가 모두 유리할 것입니다. 인덱스가 있으면 시스템은 이를 "부분적으로"(한 번에 하나의 필드) 사용할 수 있습니다. 동시에 "개인" 필드는 "조직" 필드보다 "선택성"이 훨씬 높으며 조직 조건을 결정하는 데 많은 시간이 걸리지 않습니다.

기본 차원이 1인 경우

부서에 대해서만 기본 데이터를 얻는 것과 관련된 예제의 작업을 잊지 마십시오. 다른 두 가지 문제를 해결하기 위해 개인+부문 지수를 생성하면 다음과 같은 문제가 해결되는 것처럼 보입니다. 효과적인 작업하나의 차원 "부서"에 대한 기본 데이터의 가상 테이블입니다. 그러나 여기서 우리는 레지스터 차원(인덱싱 속성)을 인덱싱할 가능성에 대해 기억해야 합니다. 차원을 인덱싱하는 기능을 사용하면 하나의 기본 차원을 기반으로 데이터베이스를 얻는 문제를 효과적으로 해결할 수 있습니다.

따라서 우리가 고려한 예에서는 기본 속성을 "Individual" 및 "Division" 차원으로 설정하고 Indexing 속성을 "Division" 차원으로 설정하고 "Individual" 차원이 "더 높은" 차원인지 확인해야 합니다. '를 '부서' 차원보다 더 많이 사용합니다('조직' 차원의 순서는 중요하지 않음).