자동화 시스템대부분의 경우 관리 시스템은 별도의 데이터베이스로 구성되며 지리적으로 분산된 구조를 갖는 경우가 많습니다. 동시에 올바르게 구현된 데이터 교환은 다음을 위한 필수 조건입니다. 효율적인 작업그러한 시스템.

교환의 초기 설정에는 1C:Enterprise 플랫폼의 제품의 경우와 같이 동종 소스를 처리하는 경우에도 프로그래밍 측면에서 뿐만 아니라 컨설팅 측면에서도 여러 가지 작업이 필요할 수 있습니다. 1C 교환 설정(또는 1C 8.3의 데이터 동기화라고도 함)이 통합 프로젝트에서 가장 시간이 많이 걸리고 비용이 많이 드는 작업이 될 수 있는 이유를 이 기사에서 살펴보겠습니다.

1C 환경에서의 데이터 교환을 통해 다음을 수행할 수 있습니다.

• 문서의 이중 입력을 제거합니다.
• 관련 비즈니스 프로세스를 자동화합니다.
• 분산된 부서 간의 상호 작용을 최적화합니다.
• 다양한 부서의 전문가 작업에 대한 데이터를 즉시 업데이트합니다.
• 다양한 회계 유형을 "구분"합니다.*

*한 회계 유형의 데이터가 다른 회계 유형과 크게 다른 경우, 정보의 기밀성을 보장하고 정보 흐름을 "구분"하는 것이 필요합니다. 예를 들어, 1C UT와 1C 회계 간의 데이터 교환에는 규제 회계 데이터베이스에 관리 데이터를 업로드할 필요가 없습니다. 여기서는 1C의 동기화가 불완전합니다.

상상해보면 표준 프로세스기본 데이터 교환 구현, 해당 개체 중 하나 이상이 1C 제품인 경우 다음 단계를 구분할 수 있습니다.

• 교환 구성 조정
• 전송의 정의(교환 프로토콜)
• 규칙 설정;
• 일정.

1C 교환 구성 확인

교환 대상은 '출처'와 '수신자'로 나눌 수 있습니다. 동시에 그들은 두 가지 역할을 동시에 수행할 수 있는데, 이를 양방향 교환이라고 합니다. 소스와 대상은 필요에 따라 논리적으로 결정됩니다. 기능성시스템.*

*예를 들어, “1C:Enterprise”를 기반으로 개발된 재무회계 유지 및 재무 프로세스 관리 솔루션인 “WA: Financier”를 통합할 때 WiseAdvice 전문가들은 이를 마스터 시스템으로 권장합니다. 이는 애플리케이션 정책의 규칙을 준수하고 그에 따라 솔루션의 효율성을 보장하기 위한 제어 도구의 가용성 때문입니다.

다음으로, 사용자로부터 수신 및 기록된 요구 사항을 기반으로 교환할 데이터 목록이 생성되고, 그 양과 교환 빈도에 대한 요구 사항이 결정되며, 오류 처리 및 예외 상황(충돌) 처리 프로세스가 규정됩니다.

같은 단계에서 기존 시스템의 규모와 기업 구조에 따라 교환 형식이 결정됩니다.

분산된 정보 기반

• RIB는 각 교환 쌍에 대한 명확한 "마스터-슬레이브" 제어 구조를 사용하여 동일한 1C 데이터베이스 구성 간의 교환을 의미합니다. RIB는 기술 플랫폼의 요소로서 데이터 외에도 데이터베이스의 구성 변경 및 관리 정보를 전송할 수 있습니다(단, 마스터에서 슬레이브로만 가능).

1C의 범용 데이터 교환

• 1C:Enterprise 플랫폼의 구성과 타사 시스템 모두를 사용하여 1C 데이터베이스의 교환을 구성할 수 있는 메커니즘입니다. 교환은 "교환 계획"에 따라 데이터를 범용 xml 형식으로 전송하여 수행됩니다.

엔터프라이즈데이터

• 1C:Enterprise 플랫폼에서 생성된 제품 간에 자동화 시스템을 사용하여 xml 형식의 데이터 교환을 구현하도록 설계된 1C의 최신 개발입니다. EnterpriseData를 사용하면 교환과 관련된 수정이 단순화됩니다. 이전에는 새로운 구성이 시스템에 포함되면 해당 시스템과 기존 시스템 모두에 대해 데이터를 가져오고 내보내는 메커니즘을 구현해야 했습니다. 이제 EnterpriseData를 지원하는 시스템은 수정이 필요하지 않으며 단 하나의 진입점과 출구만 있습니다.

전송의 정의(교환 프로토콜)

1C:Enterprise 8 플랫폼 시스템의 경우 일반적으로 허용되는 범용 표준(xml, 텍스트 파일, Excel, ADO 연결 등). 따라서 교환 데이터의 전송을 결정할 때 타사 시스템의 데이터베이스 기능에 의존해야 합니다.

디렉터리 동기화

효과적인 디렉터리 동기화의 기본 원칙은 단일 진입점이 존재한다는 것입니다. 그러나 역사적으로 서로 다른 규칙에 따라 채워져 있던 디렉터리 작업에 대해 이야기하는 경우 교환을 "공통 분모"로 가져오기 위해 동기화 필드를 명확하게 정의해야 합니다.*

*이 단계에서는 데이터 소스 측의 참조 데이터를 정규화하는 작업을 수행해야 할 수도 있습니다. 디렉터리와 해당 볼륨의 상태에 따라 요소를 비교하고, 오류와 중복 항목을 인식, 식별하고, 누락된 필드를 채우고, 동기화 필드를 할당하는 프로세스에는 전체 전문가 그룹의 작업이 필요할 수 있습니다. 통합자(마스터 데이터 정규화 기술의 소유자)의 일부와 고객 측.

규칙 설정

소스 시스템의 데이터를 수신기에 표시하는 기능은 올바르게 정의된 교환 규칙에 따라 달라집니다. XML 형식으로 표시되는 규칙은 소스-수신자 개체의 주요 세부 사항의 일치를 규제합니다. 1C:데이터 변환 솔루션은 일회성 및 영구 교환을 구현하기 위한 규칙 생성을 자동화하도록 설계되었습니다.

교환 계획 중 데이터 손실이 없음을 보장합니다. 이것 요소 1C:Enterprise 플랫폼의 모든 구성은 1C 교환 절차를 완전히 설명합니다: 데이터 구성("식별" 세부 정보가 포함된 문서) 및 노드(수신기-송신기 정보 기반), 선택한 교환 방향에 대한 RIB 활성화.

교환 계획에 입력된 데이터의 모든 변경 사항은 기록되고 "변경됨" 표시를 받습니다. 변경된 데이터가 수신자-송신자 노드에서 서로 일치할 때까지 부호는 재설정되지 않으며 시스템은 두 노드 모두에 제어 메시지를 보냅니다. 데이터를 업로드하고 두 시스템 모두에서 완전한 준수를 확인한 후 기호가 재설정됩니다.

1C 교환 일정

정기적인 교환을 자동화하기 위해 데이터 업로드 빈도가 설정됩니다. 교환 빈도는 필요성과 기술적 역량에 따라 다릅니다. 또한 1C:Enterprise 플랫폼의 구성을 통해 이벤트 발생 시 데이터 교환을 구성할 수 있습니다.

교환을 구현하는 표준 프로세스를 고려한 후 다양한 단계에서 개선이 필요한 요소에 주목해 보겠습니다.

• 비표준, 고도로 수정된 데이터베이스 구성
• 다른 버전플랫폼 "1C:Enterprise";
• 오랫동안 업데이트되지 않은 구성 버전
• 이전에 변경된 교환 대상
• 비표준 교환 규칙의 필요성
• 기존 참고서의 세부 사항 세트와 구성은 매우 다릅니다.

기본 데이터 교환을 구현하기 위한 표준 조치에도 전문 지식이 필요하므로 1C 전문가의 참여로 수행하는 것이 좋습니다. 위에 설명된 모든 단계를 완료한 후에만 구성에서 교환 설정을 진행해야 합니다. 1C:UPP 및 1C:Retail(1C:UT와의 교환은 동일한 방식을 사용하여 설정됨)의 예를 사용하여 데이터베이스 통합을 살펴보겠습니다. 표준 동기화에는 SCP - SCP 교환도 포함되어 있으며 이는 대규모 산업 기업의 대규모 자동화 시스템에 일반적입니다.

"서비스" 하위 메뉴에서 "플랫폼의 제품과 데이터 교환..."을 선택합니다("소매"와의 직접 교환을 선택하면 COM 개체 수준에서 오류가 발생하는 경우가 많습니다). 서비스 메시지에 주목하자 " 이 기회사용 불가."

이 문제를 해결하려면 "통신 구성"을 선택해야 합니다.

...그리고 확인란을 선택하세요. 그런 다음 오류 메시지를 무시하십시오.

데이터 동기화 설정에서 "소매"로 거래소 생성...을 선택하세요.

로컬 또는 네트워크 디렉터리를 통해 연결 설정을 구성하기 전에 디스크에 디렉터리용 공간이 있는지 확인해야 합니다. 일반적으로 30~50MB를 초과하지 않지만 예외적인 경우 최대 600MB가 필요할 수 있습니다. 구성자에서 직접 필요한 디렉터리를 생성할 수 있습니다.

네트워크 디렉터리를 통해 연결하는 경우 FTP 주소를 사용하여 연결을 구성하라는 메시지가 표시되며 이메일"다음"을 클릭하여 무시하십시오.

설정에서 접두사를 수동으로 입력합니다. 기호데이터베이스(일반적으로 BP, UPP, RO)에 대해 데이터 다운로드에 대한 규칙과 시작 날짜를 설정합니다. 문서 이름에 접두사가 표시되어 해당 문서가 생성된 데이터베이스를 나타냅니다. 업로드 규칙을 편집하지 않으면 기본적으로 사용 가능한 모든 매개변수에 따라 데이터가 업로드됩니다.

작업을 반복하지 않도록 "소매"에 대한 교환 설정 파일을 만듭니다. 동기화 설정 후 즉시 데이터를 전송해야 하는 경우 체크박스를 선택하세요.

교환 프로세스를 자동화하려면 일정을 설정해야 합니다.

메뉴 "소매".

확인란을 선택하고 "동기화"를 선택하십시오.

Production Enterprise Management를 선택하여 "역방향" 설정을 수행합니다.

UPP에서 생성된 설정 파일을 로드합니다.

체크 표시를 하면 시스템이 자동으로 주소를 선택합니다.

우리는 UPP와 동일한 방식으로 행동합니다.

검증 데이터 비교 (이 작업은 교환을 구현하는 과정에서 가장 노동 집약적일 수 있으므로 준비 단계에서 수동으로 데이터 비교를 수행하는 것이 좋습니다.) 마우스를 더블클릭하면 비교창이 열립니다.

동기화에 오류가 있는 경우 "세부 정보..."가 "사용 안함..."으로 대체됩니다.

"세부정보..."는 거래소에 대한 업데이트된 정보가 포함된 로그를 엽니다.

준비가 된.

안녕하세요, 블로그 사이트 독자 여러분! 데이터 변환 구성이 있으면 1C:Enterprise 8.2의 특정 문서 및 참고 도서에서 데이터를 교환하는 데 필요한 모든 도구가 있습니다. 이 문서에서는 데이터 변환 구성 버전 2.1.4.1에서의 작업에 대해 설명합니다.

데이터 변환 구성 배포 패키지의 일부로 처리 파일 MD82Exp.epf를 찾아보겠습니다.
소스 및 대상 데이터베이스 구성의 메타데이터 구조에 대한 설명을 다운로드해야 합니다.

또한 동일한 배포의 일부로 처리 파일 V8Exchan82.epf를 찾을 수 있습니다.
원본 데이터베이스를 언로드하고 대상 데이터베이스를 로드하는 데 필요합니다.

1C 구성이 동일하면 어떻게 되나요? 그런 다음 노트에 설명된 다른 방법을 시도해 볼 가치가 있습니다. 동일한 데이터베이스 간에 데이터를 교환하는 데에도 사용할 수 있습니다.

버전 1C 7.7에서 버전 1C 8.2로 데이터를 전송해야 하는 경우 어떻게 해야 합니까? 그런 다음 설명된 팁을 사용해야 합니다.

그럼 시작해 보겠습니다.

먼저 소스 및 대상 메타데이터 구조에 대한 설명을 언로드해 보겠습니다.

1. 1C:Enterprise 8.2 모드에서 소스 데이터베이스를 열고 MD82Exp.epf 처리를 시작하겠습니다.
   소스 메타데이터 구조에 대한 설명을 다운로드합니다.
   소스 메타데이터 구조를 Rules1.xml 파일에 저장해 보겠습니다.

1. 1C:Enterprise 8.2 모드에서 수신자 데이터베이스를 열고 MD82Exp.epf 처리를 시작하겠습니다.
   수신기 메타데이터 구조에 대한 설명을 다운로드합니다.
   수신자 메타데이터 구조를 Rules2.xml 파일에 저장해 보겠습니다.

두 구성의 메타데이터 구조에 대한 설명을 로드해 보겠습니다.

1. 1C:Enterprise 8.2 모드에서 데이터 변환 구성을 실행해 보겠습니다.
2. "구성" 디렉터리(디렉터리->구성)를 열어 보겠습니다. 구성 정보를 저장합니다.
   교환 규칙을 구성할 수 있습니다.
3. 소스 구성에 대한 정보를 추가해 보겠습니다. "추가" 버튼이나 "삽입" 키를 클릭하세요.
4. 소스 메타데이터 구조 Rules1.xml을 사용하여 파일 경로를 표시해 보겠습니다. “다운로드” 버튼을 클릭하세요.
   이제 "Configurations" 디렉터리에 다음이 있음을 알 수 있습니다. 새로운 요소소스 구성의 이름으로.

1. 수신기 구성에 대한 정보를 추가해 보겠습니다. "추가" 버튼이나 "삽입" 키를 클릭하세요.
2. 수신자 메타데이터 구조 Rules2.xml을 사용하여 파일 경로를 표시해 보겠습니다. “다운로드” 버튼을 클릭하세요.
   이제 수신기 구성 이름과 함께 "Configurations" 디렉터리에 새 요소가 나타나는 것을 볼 수 있습니다.

따라서 소스 및 대상 정보를 로드했습니다. 이제 교환 규칙을 구성할 수 있습니다.
다음 단계에서는 "Configurations" 디렉터리에 새로 생성된 요소를 사용하여 선택합니다.
'전환' 디렉토리에 있습니다.

1. '전환' 디렉터리(디렉터리->전환)를 엽니다. 이 가이드에는 정보가 포함되어 있습니다.
   교환이 수행되는 구성과 방향이 결정됩니다.
2. 새로운 요소를 추가해 보겠습니다. "추가" 버튼이나 "삽입" 키를 클릭하세요.

1. "Configurations" 디렉터리의 소스 구성을 나타냅니다. "구성 - 소스:" 필드.
2. "Configurations" 디렉터리에서 수신기 구성을 지정해 보겠습니다. 필드 "구성 - 수신기:".

1. “확인” 버튼을 클릭하세요.
2. "정보" 대화 상자가 나타나며 이를 통해 다음을 기반으로 모든 교환 규칙을 자동으로 생성할 수 있습니다.
   구성 개체의 이름과 일치하거나 수동으로 하나의 규칙만 일치합니다.

1. "정보" 대화 상자에서 첫 번째 옵션을 선택하면 텍스트가 포함된 다른 대화 상자가 나타납니다.
   “데이터 업로드 규칙을 만드시겠습니까?” “확인” 버튼을 클릭하세요.

좋습니다. 교환 규칙을 구성했습니다. 남은 것은 이러한 교환 규칙을 파일에 업로드하는 것뿐입니다.

변환 규칙이 준비되었습니다! 이제 데이터를 교환해 볼까요?

1C:Enterprise 8.2 모드에서 원본 데이터베이스를 열고 처리를 시작해 보겠습니다.
소스 데이터를 로드합니다.

처리 파일 V8Exchan82.epf입니다. 또는 "도구" -> "기타 데이터 교환" -> "XML 형식의 범용 데이터 교환"을 엽니다.

1. 처리 중 "데이터 업로드" 탭에서 규칙 파일의 이름을 선택합니다(여기에 저장했습니다: C:\Bases\DataExchangeRules.xml).
   우리는 데이터 교환 규칙을 다운로드하는 데 동의합니다. "예" 버튼을 클릭해 보겠습니다.
2. 데이터 파일의 이름을 지정해 보겠습니다. (예: C:\Bases\Data Upload.xml). 파일이 존재하지 않으면 생성됩니다.

1. 기간을 표시해 보겠습니다. "데이터 업로드" 버튼을 클릭하세요(상단 패널에 위치).

이제 수신자 데이터베이스에 데이터를 로드해 보겠습니다. 1C:Enterprise 8.2 모드로 열어서 처리를 시작해 보겠습니다.

처리 파일 V8Exchan82.epf입니다. 또는 "도구" -> "기타 데이터 교환" -> "XML 형식의 범용 데이터 교환"을 엽니다.

1. 처리 중 "데이터 로드" 탭에서 데이터 파일 이름을 선택합니다(여기에 저장했습니다: C:\Bases\Data Upload.xml).
2. "데이터 로드" 버튼을 클릭합니다(상단 패널에 위치).

데이터가 로드되었습니다!

대상 데이터베이스와 원본 데이터베이스 문서의 표 형식 부분에서 특정 세부 정보가 다른 경우가 있습니다.
수신자는 "Directory" 유형의 속성을 가질 수 있고, 소스는 동일한 이름을 가진 속성을 가질 수 있지만 유형은 "Enumeration"입니다.
어떻게 해야 하나요? 이 객체를 올바르게 변환하기 위한 규칙을 설정하는 방법은 무엇입니까? 기사의 팁을 활용하세요.

버전 1C:Enterprise 8.1 및 1C:Enterprise 8.0에도 동일한 단계가 적용됩니다. 데이터 변환 구성 배포에는 MD81Exp.epf 및 V8Exchan81.epf, MD80Exp.epf 및 V8Exchan.epf 버전에 대한 처리 파일이 포함되어 있습니다.

또한 데이터 변환 구성을 사용하면 버전 1C:Enterprise 7.7에서 데이터를 다운로드할 수 있습니다. 첨부된 파일은 V77Exp.ert(데이터 다운로드), V77Imp.ert(데이터 다운로드), MD77Exp.ert(구성 메타데이터 구조에 대한 설명 다운로드)입니다.

이 기사에서는 이러한 치료법을 사용하는 방법을 자세히 설명합니다.

실생활에서 1C 데이터베이스 하나로 버티는 보기 드문 회사입니다. 가장 일반적인 상황은 회계와 급여라는 두 가지 기반입니다.

기지가 연결되어 있어야합니다. 급여가 발생하고 발생한 세금은 지불을 위해 회계 부서에 전달되어야합니다.

여러 데이터베이스를 연결하려면 Exchange 1C가 있습니다. 그는 어떻게 일합니까?

Exchange 1C 란 무엇입니까?

체인점과 중앙 사무실이 있습니다. 모든 상점과 사무실에는 창고가 있습니다. 상품은 창고에서 창고로(주로 중앙창고에서 매장창고로) 이동되어 매장에서 판매됩니다.

1C Retail 데이터베이스는 사무실에서 사용되며 각 매장에서는 동일한 데이터베이스가 사용됩니다. 매장의 기지는 사무실의 기지에 종속됩니다.

사무실에서는 창고에서 창고로 상품 이동에 대한 문서가 작성되고 가격이 설정됩니다. 문서는 하위 데이터베이스에 업로드되고 상품은 거기에 "나타납니다".

상점은 완료된 상품 판매에 대한 문서를 작성합니다. 문서가 사무실 데이터베이스에 업로드되고 매출이 거기에 "나타납니다".

이 체계를 분산 정보 베이스(RIB)라고 합니다. 문서 "업로드" 절차 – 양방향 1C 교환. 그리고 이 방식을 설정하는 것이 URIB 또는 URIBD(Distributed Information Database Management)입니다.

1C에서 디렉토리 교환 원리

1C 디렉토리 (그리고 "컴플렉스에 있는" 모든 디렉토리 세트를 NSI라고 함 - 규범적 참고정보) – 일반적으로 다른 데이터베이스에서도 동일해야 합니다. 이는 데이터베이스가 여러 개 있어도 상품, 창고, 계약자 목록이 서로 다른 데이터베이스에서 동일하다는 것을 의미합니다.

일반적인 관행은 한 데이터베이스에서 디렉터리 편집이 허용되고 다른 데이터베이스로 복사("마이그레이션")되는 경우입니다. 이전에 논의한 것처럼 각 1C 요소에는 GUID라는 고유 식별자가 있습니다. 디렉터리는 일반적으로 GUID와 함께 복사되므로 분산 정보 시스템 전체에서 동일합니다.

그렇지 않으면 처음에 여러 개의 기존 데이터베이스가 연결되거나 동시에 다른 데이터베이스에 디렉터리가 생성될 수 있는 경우 해당 GUID가 달라집니다. 이에 대한 일치 메커니즘이 있습니다. 1C 교환 중 특수 정보 레지스터에는 GUID xxx를 갖는 데이터베이스 No. 1의 요소가 GUID yyy를 갖는 이 데이터베이스의 요소와 동일하다는 정보가 기록됩니다. 처음에는 더 이상 동일하지 않은 기존 요소를 자동으로(이름, 세금 식별 번호 및 체크포인트 등 기타 세부 정보를 사용하여) 또는 수동으로 비교해야 합니다.

1C의 문서 교환 원칙

1C의 문서는 등록부에 따라 게시된 후 "게시"된 것으로 간주됩니다. 이로 인해 전송 중에 이해할 수 있는 어려움이 발생합니다.

한 가지 옵션은 문서만 전송하고 다운로드한 후 다시 전송하는 것입니다. 이 방법은 자주 사용되지만 오류가 발생할 수 있습니다. 프로세스 중 조건이 문서가 원래 데이터베이스에 게시된 당시의 조건과 다를 수 있으므로 문서가 새 데이터베이스에 게시되지 않을 수 있습니다.

또 다른 옵션은 문서와 등록부를 함께 전송하는 것입니다. 우리가 이해하는 바와 같이 질문은 즉시 발생합니다. 일반적으로 모든 문서를 전송한 다음 전체 등록부를 일반적으로 전송하거나 전송된 문서의 이동만 전송하도록 선택해야 합니다.

Nomenclature 디렉토리에서 항목을 전송해야 한다고 가정해 보겠습니다. 이 디렉토리에는 10개의 필드가 있으며 그 중 5개는 문자열과 숫자이고 5개는 다른 디렉토리에 대한 링크입니다.

따라서 명명법의 한 요소를 전송할 때 다른 디렉토리의 5개 요소도 검색하여 전송해야 합니다.

따라서 하나의 디렉토리 요소 또는 하나의 문서를 전송할 때 100개 이상의 다른 1C 개체를 링크를 통해 전송할 수 있습니다.

실제로 거의 모든 구성 참조는 어떤 방식으로든 서로를 참조한다고 합니다.

1C 교환 계획

분산 데이터베이스를 생성하고 1C 교환을 수행했다고 가정 해 보겠습니다. 상품이 중앙 창고로 구매되었으며 매장으로 배송될 준비가 되었습니다. 사무실의 1C에서 그들은 소개했습니다. 필요한 서류상품의 이동. 상점에 로드해야 합니다.

무엇을 해야 할까요? 전체 1C 교환을 다시 수행하시겠습니까? 길고 비효율적입니다! 사무실에서 사용자가 정확히 무엇을 추가하거나 변경했는지 계산하여 변경 사항만 매장으로 전송되도록 하는 것이 훨씬 더 좋을 것입니다.

이에 대한 1C 교환 계획이 있습니다. 프로그래머는 매장과 같은 다른 데이터베이스와의 1C 교환을 수행하기 위해 미리 1C 교환 계획을 만듭니다.

1C 교환 계획은 사용자가 디렉토리로 작업할 때 기록하고 이 데이터베이스와의 마지막 1C 교환 이후 추가되거나 변경된 내용을 문서화합니다.

URIB 1C 생성

그래서 우리는 처음부터 분산 데이터베이스를 만들 것입니다. 처음에는 "모" 사무실 기반이 있습니다. 여기에서 종속될 매장의 데이터베이스를 선택합니다.

일반적인 구성에는 이미 표준 1C 교환 계획이 있습니다. 의도된 베이스 유형은 이름에서 직관적으로 명확합니다.

• 웹사이트와 1C 교환: 1C:Bitrix 웹사이트와 교환
• 1C UPP-UT 또는 UT-Retail 교환: 자매 구성과의 일반적인 교환
• 전체 – 동일한 구성을 기반으로 하는 데이터베이스와의 1C 교환.

RIB(분산 정보 기반)는 1C "전체" 교환 계획을 기반으로 만들 수도 있습니다. 구성자에서 이 1C 교환 계획에서 "분산 정보 베이스" 확인란을 선택해야 합니다.

구성자에서 생성된 1C 교환 계획은 이 구성으로 교환할 것임을 나타냅니다. 엔터프라이즈 모드에서는 동일한 1C 교환 계획에서 이제 이 구성을 기반으로 특정 데이터베이스를 지정해야 합니다.

1C 교환 계획(Operations/Exchange Plan; 다른 메뉴에 있을 수도 있으며 주로 Service/XXX 메뉴에 있음)으로 이동해 보겠습니다.

1C 교환 계획의 데이터베이스 목록에는 그림에 녹색 원이 있는 데이터베이스가 있습니다. 이 요소는 THIS BASE를 나타냅니다. 나머지 요소는 1C가 교환되는 기타 염기를 나타냅니다.

모든 요소의 이름과 코드를 모두 입력해야 합니다.

상점 하위 베이스를 생성하려면 다음을 수행하십시오.

• "스토어 기반"으로 만든 1C 교환 계획 요소의 목록에 커서를 놓습니다.
• "작업/초기 이미지 생성" 메뉴 항목을 선택합니다.

결과적으로 초기 데이터가 업로드된 하나의 데이터베이스가 생성됩니다. CURRENT BASE를 제외하고 1C 교환 계획의 각 요소에 대해 이 작업을 반복해야 합니다.

1C 교환 이론

1C 교환 이론은 매우 간단합니다.

• 데이터베이스 중 하나(일반적으로 센터의 데이터베이스)는 일정 또는 "이벤트"(특정 사용자의 데이터베이스에 로그인 등)에 따라 1C 교환을 시작합니다.
• 1C 교환은 데이터베이스에서 파일을 다운로드하는 것으로 구성됩니다.
• 파일은 슬레이브 데이터베이스가 해당 파일을 선택할 수 있는 위치(일반적으로 공유 또는 FTP, 덜 자주 이메일)로 이동되어야 합니다.
• 슬레이브 데이터베이스는 수신된 파일을 다운로드합니다.
• 정보가 수신되었다는 확인으로 슬레이브 데이터베이스는 "응답" 파일을 업로드하고, 이 파일은 동일한 방식으로 중앙 데이터베이스에 다시 로드됩니다.
• 1C 교환 세션이 완료되었습니다.

파일을 통하지 않고 예를 들어 두 데이터베이스 간의 직접 COM 연결을 통해 1C를 교환하는 다른 방법이 있습니다. 장점:

• "파일을 저장하고 전송할 공간"이 필요하지 않습니다.
• 확인을 다시 업로드할 필요가 없습니다.
• 처음 두 점으로 인해 모든 일이 더 빠르게 진행됩니다.

그러나 제한 사항은 분명합니다. COM 연결을 시작하려면 베이스가 서로 액세스할 수 있어야 합니다.

RIB 1C 설정

상수에서 일반적인 구성(작업/상수 또는 서비스/프로그램 설정) - 일반적으로 예 일반 설정 1C 교환. 이는 어떤 데이터베이스에서 생성되었는지 쉽게 확인할 수 있도록 요소 코드와 문서 번호의 접두사입니다. 디렉토리와 문서가 생성된 장소에 대한 정보를 저장하는 내부 방법도 있습니다.

이제 생성된 데이터베이스 간에 1C 정보를 주기적으로 교환하는 프로세스가 어떻게 수행되는지 구성해야 합니다.
1C의 모든 RIB 설정은 표준 구성으로, 일반적으로 서비스/분산 정보 기반/RIB 노드 구성 메뉴에 있습니다.

이전에 생성된 각 "원격 매장 기반" 요소에 대해 설정 요소를 추가해야 합니다.

설정은 파일(공유), 파일(FTP), 파일(이메일) 등 1C 교환 방법을 나타냅니다.

씬 클라이언트에서 분산 1C 정보 기반 생성 및 설정

다음을 기반으로 일반적인 구성에서 유사한 설정을 살펴보겠습니다. 씬 클라이언트– 무역 관리 개정 11.
설정(및 처음부터 생성)은 인터페이스의 관리 탭에 있습니다. 항목 "데이터 교환".

“분산 정보베이스에 거래소 생성”을 선택하세요.

처음부터 1C는 하위 데이터베이스와 정보를 교환하는 방법을 표시하도록 요청합니다. 다음은 "볼 위의 파일을 통해" 구성 옵션입니다.

다음은 FTP 파일을 통한 구성 옵션입니다.

1C 교환 설정의 이름입니다.

그리고 즉시 "초기 이미지", 즉 기본 정보를 업로드하는 슬레이브 데이터베이스 자체를 생성하라는 제안이 제시됩니다.

씩(thick) 클라이언트의 구성과 달리 두 1C 교환 설정이 모두 한 곳에 있습니다.

우리는 메타데이터 구조를 알고 있습니다. 정보 기반소스와 수신기. 이 정보는 소스 정보 베이스의 어떤 객체를 수신자 정보 베이스의 어떤 객체로 변환해야 하는지 결정하는 데 충분합니다. 즉, 소스 정보 베이스와 수신자 정보 베이스의 객체 사이에 어느 정도 일치성을 설정할 수 있습니다. 예를 들어, 소스 정보베이스의 명명법 디렉터리가 수신자 정보베이스의 명명법 디렉터리(또는 다른 디렉터리)에 해당하도록 지정할 수 있습니다.

소스 개체와 대상 개체 간의 이러한 대응을 "개체 변환 규칙" 또는 OCR이라고 부릅니다.

표시된 예는 "두 개체를 하나로" 교환(또는 변환) 규칙의 경우 "사용자" 및 "개인" 디렉터리에 대한 개체의 대응이 설정됨을 보여줍니다. 즉, 소스 정보베이스의 "Users" 디렉터리 개체를 수신 정보베이스의 "Users" 디렉터리 개체로 전송해야 한다고 지정됩니다.

개체 간의 대응이 설정되면 이러한 개체의 세부정보를 전송하는 방법을 결정할 수 있습니다. 즉, 한 디렉터리의 "이름" 특성이 다른 디렉터리의 "이름" 특성에 해당하도록 지정해야 합니다.

소스 개체와 대상 개체의 속성(또는 세부 정보) 간의 이러한 대응을 "속성 변환 규칙" 또는 PCS라고 부릅니다.

표시된 예에서는 "사용자" 개체를 변환하기 위한 규칙의 경우 개체의 속성(또는 세부 정보) 간에 3개의 대응 관계가 설정되어 있음을 보여줍니다. 소스 정보 베이스의 "Users" 디렉토리의 "Name" 속성은 수신자 정보 베이스의 "Users" 디렉토리의 "Name" 속성으로 변환되어야 함을 나타냅니다.

객체의 속성 간의 대응관계가 지정되면 프로그램은 두 개의 정보 베이스에서 객체를 일치시키는 기준(즉, 소스 객체를 사용하여 대상에서 객체를 검색하는 방법을 표시해야 함)을 지정해야 합니다. 이러한 비교를 위해서는 해당 개체 변환 규칙에 대한 "검색" 확인란을 사용하십시오. 확인란을 선택하면 이 속성을 사용하여 해당 개체에 대한 검색이 수행됩니다. 주어진 예에서 수신자 정보베이스의 객체 검색은 "이름" 속성을 사용하여 수행된다는 것이 분명합니다. 여러 항목을 사용하여 검색을 설정한 경우 해당 항목을 모두 동시에 사용하여 검색이 수행됩니다(즉, 조건은 "AND"로 부과됩니다. 이 경우 일치 규칙은 다음과 같습니다. 정보 베이스에서 검색) - 모든 검색 세부 정보가 소스 개체 검색 세부 정보와 일치하는 개체에 대한 수신기입니다.

또한 사전 정의된 참고 도서 요소, 특성 유형 계획 및 열거 값 간의 대응 관계를 설정할 수 있습니다. 우리는 이러한 비교를 VKZ의 "가치 변환 규칙"이라고 부를 것입니다.

표시된 예는 "에이전트 계약 유형" 개체 변환 규칙에 대해 열거 값 사이에 대응 관계가 설정되었음을 보여줍니다. 즉, 원본 정보베이스의 "Rent" 열거 값은 대상 정보베이스의 "Rent" 열거 값으로 변환되어야 합니다.

우리는 객체, 속성 및 값을 변환하는 규칙을 알게 되었습니다. 얼핏보면 아주 간단한 규칙비교를 통해 한 정보베이스에서 다른 정보베이스로 데이터를 전송할 수 있습니다.

감사합니다, 블라디미르 밀킨(교사 및 개발자).

1C 데이터 변환 교과서 (2 판) 교환 규칙에 대한 자세한 소개

우리는 교환 규칙이 무엇인지, 왜 필요한지 알고 있습니다. 교환 규칙 작업의 추가 기능을 자세히 살펴보겠습니다. 데이터 교환(변환) 규칙에 대한 설정을 열어 보겠습니다.

교환 규칙은 다음과 함께 데이터의 소스 및 대상 구성을 지정합니다.

"고급" 탭:

교환 규칙 저장을 위한 기본 파일 이름, 7.7용 데이터 업로드 및 다운로드 모듈, 교환 규칙 이름을 지정할 수 있습니다.

"매개변수" 탭:

사무실에서 상품 주문만 접수한다고 가정해 보겠습니다. 따라서 하역 서비스를 금지하는 것이 좋습니다. 참조 요소 명명법 속성 서비스가 True로 설정된 경우 언로드되지 않는 것이 보장됩니다. 원격 사무실이 서비스 주문을 수락하기 시작하면 규칙을 변경하지 않도록 선택적으로 서비스 언로드를 즉시 제어하는 ​​것이 가장 좋습니다.

이 경우 "데이터 변환" 구성 작업을 위한 두 가지 새로운 기술(핸들러 사용 및 매개변수 설정)을 배워야 합니다.

매개변수는 처리 변수에 액세스하는 데 사용할 수 있는 언로드 알고리즘의 특수 데이터 구조입니다. 변환 규칙에 대한 매개변수의 구조 설정은 "Data Conversion" 구성에서 이루어지며, 매개변수 값 설정은 데이터 업로드 및 다운로드를 처리하는 형태로 가능합니다.

매개변수를 편집하려면 편집된 교환 규칙에 대한 전환 디렉터리 요소의 양식을 열고 매개변수 탭으로 이동하세요. 새 디렉터리 요소 매개변수를 만들어 보겠습니다. 매개변수 이름을 UnloadServices로 지정하겠습니다. 매개변수 이름은 작성할 때 매개변수 구조에서 이를 참조하는 데 사용됩니다. 프로그램 코드핸들러에서. 이름은 처리 양식에서 매개변수의 표 부분에 표시됩니다. 만능교환데이터. 업로드를 설정할 때 매개변수가 대화상자에 표시되도록 하려면 "대화상자에 설정" 확인란을 선택하고 매개변수 값 유형을 선택해야 합니다. 대화 상자에서 매개변수로 작업하려면 변환 디렉토리 요소 형식에서 "버전 2.01 형식으로 매개변수 다운로드" 확인란도 선택해야 합니다.

단순히 매개변수를 지정하는 것만으로는 충분하지 않습니다. 언로드 알고리즘은 요소를 언로드하는 경우와 그렇지 않은 경우를 "이해"해야 합니다. 비슷한(그리고 다른 많은) 경우에는 핸들러 메커니즘이 사용됩니다. 그 본질은 데이터 업로드 및 로드를 위한 모든 기본 알고리즘 실행의 핵심 지점에서 교환 규칙을 생성할 때 개발자가 작성한 코드가 처리된다는 사실에 있습니다. 당연히 그러한 섬세한 도구를 사용하려면 주의와 사려 깊음이 필요합니다. 자체 핸들러를 작성하기 전에 핸들러에서 사용할 수 있는 모든 변수와 사용 방법은 물론 핸들러 유형 및 호출 기능을 설명하는 "Data Conversion 2.0" 구성에 대한 도움말을 주의 깊게 읽어 보시기 바랍니다. 데이터 교환 알고리즘에 포함됩니다.

우리의 목적을 위해서는 "언로드 전" 언로드 규칙 핸들러를 사용해야 합니다. 명명법 데이터 업로드 규칙을 열고 "이벤트" 탭의 "업로드 전" 필드에 다음 프로그램 코드를 배치해 보겠습니다.

우리 핸들러는 무엇을 합니까? 프로그램 코드를 작성할 때 데이터 업로드 알고리즘의 변수를 사용했습니다. 매개변수 구조는 데이터 교환 처리 양식에 지정된 UnloadServices 매개변수에 액세스하는 데 사용됩니다. 개체 변수는 페이징되는 개체에 대한 액세스를 제공합니다. 그리고 Refusal 변수를 사용하면 현재 개체 언로드 거부를 제어할 수 있습니다. 핸들러는 객체가 언로드되기 직전에 실행되므로 객체 언로드를 취소할 수 있습니다.

V8 - V8 교환 및 업로드 및 다운로드 처리(최소 2.0.18.1)에만 해당

한 구성에서 다른 구성으로 매개변수를 전송할 수 있습니다. 이렇게 하려면 "매개변수" 탭에서 "업로드 시 매개변수 전달" 확인란을 선택하면 충분하며 이 매개변수는 교환 파일에 배치되고 데이터 로드 시 해당 값에 액세스할 수 있습니다. 값이 변환되어야 하는 매개변수에 대한 변환 규칙을 지정할 수 있습니다. "업로드 시 매개변수 전달" 확인란을 사용하면 데이터 업로드 시 대화 상자에서 편집된 매개변수만 전송할 수 있습니다. 이 대화 상자에 없는 매개변수를 전달해야 하는 경우 프로시저를 호출해야 합니다.

업로드 매개변수 탭에는 서비스가 언로드되거나 언로드되지 않는 값을 변경하는 매개변수가 나타납니다.