실생활에서 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 교환 설정이 모두 한 곳에 있습니다.
RIB(분산 정보 기반) 기술을 사용하면 1C Enterprise 구성을 기반으로 지리적으로 분산된 시스템을 만들 수 있습니다. 이를 통해 노드의 높은 자율성과 신속한 정보 교환 기능을 결합하여 신뢰할 수 있는 통신 채널이 없는 부서와도 공통 정보 공간을 가질 수 있습니다. 우리 기사에서 우리는 기능과 실질적인 구현플랫폼 8.2에서 이 메커니즘의
우선 스스로에게 물어봅시다: 왜 자동 교환이 필요한가? 현대 기술, 저렴하고 빠른 인터넷, 어려움 없이 원격 작업을 구성할 수 있습니다. RDP, 씬 및 웹 클라이언트, VPN을 사용한 네트워크 연결 등 방법 선택의 폭이 그 어느 때보다 넓습니다. 고려해야 할 사항이 많습니다. 그러나 이러한 모든 방법에는 통신 채널의 품질에 크게 의존한다는 한 가지 중요한 단점이 있습니다.
심지어 완벽한 직업현지 공급자의 통신 채널 가용성을 100% 보장하는 것은 불가능합니다. 백본 공급자의 문제, 전원 공급 장치 부족, 통신 회선의 물리적 손상 및 기타 여러 요인으로 인해 이 작업을 극복할 수 없습니다. 동시에 원격 창고나 창고에서 정보 기반에 접근할 수 없습니다. 소매점상당히 심각한 손실을 초래합니다. 그리고 마지막으로, 고품질 통신 채널을 제공하는 데 비용이 많이 들거나 문제가 되는 장소(예: 도시 외곽의 산업 지역)가 있다는 사실을 잊지 마십시오.
RIB 메커니즘을 사용하면 이러한 단점을 제거할 수 있습니다. 각 부서에는 의사소통이 전혀 없는 경우에도 자율적으로 작업할 수 있는 자체 정보 기반 사본이 있습니다. 외부 세계. 전송되는 정보의 양이 적기 때문에 모바일 인터넷을 포함한 모든 통신 채널을 사용하여 교환할 수 있습니다.
플랫폼 8.2의 RIB는 RIB 플랫폼 7.7의 추가 개발을 나타내는 근본적으로 새로운 것이 아닙니다. 이제 이 기술은 더 쉽게 접근할 수 있고 더 단순해졌습니다. 별도로 구매해야 했던 RIB 구성 요소와 달리 RIB는 많은 표준 구성의 필수 부분이며 전적으로 사용자 모드에서 작동하므로 설정 단계에서도 구성기 없이도 작업을 수행할 수 있습니다.
이 시점에서는 실용적인 부분으로 넘어갈 시간이지만, 한 가지 여담을 더 만들어야 합니다. 사실 이미 발생한 것처럼 보이는 플랫폼 8.2로의 전환으로 인해 실제로는 두 가지 유형의 구성이 등장했습니다. 관리형 애플리케이션, 8.2 플랫폼용 "네이티브"이며 8.1부터 적용되어 오래된 기술과 메커니즘을 계속 사용합니다. 구성(엔터프라이즈 회계, 급여 및 HR 관리)의 상당 부분이 조정되거나 과도기적이므로 할인될 수 없습니다. 따라서 기사의 첫 번째 부분은 이러한 구성(기본적으로 8.1 플랫폼)에 대해 다루고 두 번째 부분에서는 관리되는 애플리케이션(플랫폼 8.2)을 기반으로 구성에 대한 자동 교환 설정을 살펴보겠습니다.
실제 작업을 고려해 보겠습니다. Enterprise Accounting 2.0 구성에 대해 FTP를 통해 자동 교환을 설정하는 것입니다. RIB가 다음을 사용하여 교환을 허용한다는 사실에도 불구하고 이메일또는 공유 파일 리소스를 사용하는 경우 가장 간단하고 가장 좋은 방법으로 FTP를 사용하는 것이 좋습니다. 믿을 수 있는 방법연락. 자신만의 FTP 서버를 설정하는 방법을 읽어보거나 호스팅 제공업체의 FTP 서비스를 사용할 수 있습니다.
우선 교환 노드를 구성해야 합니다. 이렇게 하려면 관리자 권한으로 구성을 시작하고 거래 - 교환 계획.
나타나는 목록에서 다음을 선택하세요. 가득한계획하거나 조직별, 하나의 데이터베이스에 여러 회사에 대한 기록이 보관되어 있고 그 중 하나에 대해서만 교환이 필요한 경우. 열리는 창에는 이미 하나의 노드가 있습니다. 중앙 노드이므로 코드와 이름을 표시하여 편집해야 합니다.
그런 다음 분기에 대한 또 다른 노드를 생성하여 동일한 방식으로 채웁니다(추가하려면 더하기 기호가 있는 녹색 원을 클릭). 다음 단계는 이미 만들어진 정보 기반인 이 노드에 대한 초기 이미지를 생성하는 것입니다. 파일 모드. 이렇게 하려면 다음을 클릭하세요. 마우스 오른쪽 버튼으로 클릭원하는 노드에 마우스를 놓고 드롭다운 목록에서 선택하세요. 시작 이미지 만들기.
이제 다음으로 넘어가자 서비스 - DIB(분산 정보 베이스) - RIB 노드 구성.
열리는 창에서 버튼을 클릭하세요 추가하다원격 호스트, 교환 유형(FTP를 통해) 및 서버 연결 매개변수를 지정하여 새 교환을 구성합니다.
서표 자동교환 교환 일정 설정, 이벤트별 교환(작업 시작 및 종료 등)을 설정할 수 있습니다. 이러한 설정은 교환이 수행될 사용자를 대신하여 이루어지므로 해당 사용자에게 데이터 교환 권한이 있는지 확인하십시오.
도구 - 프로그램 설정에서 문서 번호 매기기를 위한 노드 접두사를 지정하는 것을 잊지 마십시오(그렇지 않으면 동일한 번호를 가진 다른 문서를 받게 됩니다). 여기에서 다른 교환 매개변수도 구성할 수 있습니다. 동일한 탭에서 교환 작업을 수행할 사용자를 선택해야 하며, 이를 수행하지 않으면 일정이 작동하지 않습니다. 교환은 다음 경우에만 이루어집니다. 이 사용자프로그램에 로그인했습니다.
이것으로 중앙 노드 구성이 완료되었으며, 이제 주변 노드에 대해서도 유사한 설정을 수행하여 초기 이미지를 기존 정보 보안 시스템으로 연결해야 합니다. 그런 다음 데이터 교환을 시작할 수 있습니다. 제어하려면 다음을 사용해야 합니다. 통신 모니터, 이를 통해 업로드/다운로드의 성공 여부를 모니터링할 수 있을 뿐만 아니라 발생하거나 지연된 움직임으로 인한 충돌도 표시됩니다(교환을 수행한 사용자가 데이터베이스에서 작업을 수행할 수 있는 충분한 권한이 없는 경우). 유효성 이 악기의자동 교환 중에 발생하는 다양한 유형의 문제를 빠르고 효과적으로 해결할 수 있습니다.
이 시점에서 교환 설정이 완료된 것으로 간주되어 분산 모드에서 작업을 시작할 수 있습니다. 특히 구성을 업데이트하거나 변경하는 것에 대해 자세히 살펴보는 것이 좋습니다. 이러한 작업은 중앙 노드에서만 사용할 수 있으며, 모든 변경 사항은 다음 교환 중에 주변 노드에 자동으로 전파됩니다. 자동으로 변경하려면 주변 데이터베이스가 배타적 모드에 있어야 합니다. 그렇지 않으면 다음을 실행해야 합니다. 구성자그리고 실행 데이터베이스 구성 업데이트수동으로.
1C 버전 7.5가 등장한 이후 다양한 구성 간의 교환이 필요해졌습니다. 개발됨 다양한 방법그리고 메커니즘. 이 기사에서는 다양한 구성 간의 교환에 사용되는 최신(1C:Enterprise 8.2 플랫폼용) 메커니즘을 설명합니다. 이 기사는 자신만의 교환을 생성하거나 표준 교환을 분석하는 초보 프로그래머를 위한 것입니다. 교환 절차에 대한 설명은 진공 상태에서의 일종의 구형 교환과 같은 유토피아적인 교환 아이디어를 사용합니다.
데이터 교환 문제에 대한 설명
교환은 서로 다른 두 구성 간에 발생합니다. 이를 소스와 수신기라고 부르겠습니다. 기본적으로 교환 방향은 단방향으로 간주됩니다. 소스 및 대상 구성의 메타데이터 구조가 다릅니다. 일부 유형의 문서는 정기적으로 교환해야 합니다.
일반적으로 양방향 교환 문제는 두 개의 단방향 교환 작업으로 나누어지며, 소스와 수신자만 교환됩니다.
어려움
- 구성 문서에는 다양한 세트그리고 디테일의 구성
- 일부 문서 세부정보 복합형(디렉토리).
- 이미 전송된 문서가 소스 구성의 문서에 의해 수정된 경우 싱크 구성으로 다시 전송해야 합니다.
- 동시에 두 개의 데이터베이스에 디렉토리가 채워지면 요소 중복이 가능합니다. 또는 디렉터리에 중복된 항목(동일한 세부 정보가 포함된 디렉터리 요소)이 있는 경우 "불필요한" 요소가 문서에 남게 됩니다. 예를 들어 오랫동안 사용되지 않아 삭제 표시된 요소입니다. .
해결 방법
1단계: 개체 일치
소스 구성 문서의 세부 사항을 수신기 구성 문서의 세부 사항에 매핑하기 위한 규칙을 생성하기 위해 교환 규칙이 생성됩니다.교환 규칙 특수 파일 XML 형식 Source 객체를 Receiver 객체로 변환하기 위한 대응 및 규칙을 설명합니다. 교환 규칙 생성은 "데이터 변환" 구성을 사용하여 자동화됩니다. 수신기 및 소스 구성에서 특수 처리를 사용하여 해당 구성의 메타데이터 구조를 설명하는 XML 파일이 다운로드되고 "데이터 변환"에 로드됩니다.
교환 규칙을 설명할 때 시스템이 소스 개체에 해당하는 개체를 수신기에서 검색하는 데 사용되는 세부 정보(소위 핵심 세부 정보)를 표시해야 합니다.
현대 교환 체계에서는 세부 사항에 따른 일치가 다음 경우에만 사용됩니다. 초기 설정교환. 작업 중에 디렉터리의 주요 세부 정보가 변경될 수 있지만 개체 간의 연결이 끊어져서는 안 됩니다. 이를 위해 "교환 대상 일치" 레지스터가 수신기 구성에 채워집니다. 레지스터에는 소스 구성의 GUID(고유 개체 식별자)와 수신기에서 이에 해당하는 개체의 전역 고유 식별자가 포함됩니다.
2단계. 변경된 객체 등록
1C:Enterprise 8 플랫폼에는 교환 구성을 위해 특별히 설계된 메타데이터 개체인 Exchange Plan이 있습니다.교환 계획에는 데이터 교환에 참여할 수 있는 노드에 대한 정보가 포함되며, 교환할 데이터의 구성을 결정하고, 교환 중에 분산 정보 기반 메커니즘을 사용해야 하는지 여부를 나타냅니다. 하나의 응용 솔루션여러 교환 계획이 있을 수 있으며 각 계획은 자체 데이터 교환 절차를 설명할 수 있습니다. 예를 들어, 데이터가 원격 창고 및 원격 사무실과 교환되는 경우 창고와 교환되는 데이터의 구성이 상당히 다양하므로 두 가지 교환 계획(하나는 창고와의 교환용, 다른 하나는 사무실용)이 있을 가능성이 높습니다. 사무실과 교환하기 위한 데이터 구성보다 더 좁습니다.
매우 간단한 형태로,교환 계획(메커니즘을 사용하지 않음) 분산 데이터베이스 data)는 데이터 수신 노드의 식별자와 업로드하려는 객체의 식별자라는 두 개의 열이 있는 테이블로 표시될 수 있습니다. 교환 계획은 특정 메타데이터 개체를 모니터링하도록 구성됩니다. 교환 계획에 포함된 메타데이터 개체가 변경되면 변경된 개체의 전역 식별자가 변경 기호와 함께 교환 계획에 포함됩니다. 데이터를 업로드한 후 변경 플래그가 재설정됩니다.
3단계. 운송
데이터 교환 토폴로지는 매우 이상합니다. 소스에서 수신기 데이터베이스에 대한 직접 액세스와 간접 액세스가 모두 가능합니다. 첫 번째 경우에는 소스에서 수신기로 직접 연결하는 ADO 연결을 사용할 수 있습니다. 이 옵션은 사용자 관점에서 매우 편리합니다. 수신기에서 교환 매개변수와 사용자 인증을 한 번 구성한 후 버튼을 한 번 클릭하여(또는 일정에 따라) 교환을 수행합니다.
수신기에 직접 액세스할 수 없는 경우 데이터는 중간 장치에 업로드됩니다. XML 파일, 수신측으로 전송되어 다운로드됩니다. 공유 FTP 리소스를 사용하는 것도 가능합니다.
교환을 설정하기 전에
삭제 표시된 중복 항목 및 개체
교환을 설정하기 전에 디렉토리에서 중복된 요소를 제거하십시오. 삭제 표시된 개체를 삭제합니다.
디렉토리 및 정보 레지스터 입력
디렉토리 및 정보 레지스터를 입력하려면 하나의 소스가 있어야 합니다. 그러면 겉보기에 동일한 움직임이 대차대조표에서 "접어지지" 않기 때문에 잘못 동기화된 요소를 지속적으로 수정해야 할 필요성이 없어집니다.
결론
결과적으로 교환 체계를 만드는 것은 다음과 같습니다.- 교환 규칙은 "데이터 변환" 구성에서 생성됩니다.
- 교환 계획이 생성되고 초기화됩니다.
- 교환을 위해 정보 기반이 준비 중입니다. 중복 제거
- 교환을 초기화하면 정보 레지스터 "교환 대상의 대응"이 채워집니다.
- 적절한 전송이 선택됩니다(파일을 통해 직접 액세스).
- 정기적인 데이터 교환이 이루어집니다.
서지
추신 건설적인 비판과 추가를 환영합니다.
회계에 직원과의 정산 거래를 반영하려면 1C ZUP 8.3 프로그램과 회계 8.3 간의 데이터 교환이 필요합니다. 1C ZUP 8.3 프로그램에서 인사 기록을 유지하고 급여를 계산하는 경우 1C ZUP 8.3에서 1C 회계 8.3으로 데이터를 다운로드하는 방법을 여기에서 읽으십시오.
소수의 직원으로 인사기록 및 급여계산이 가능합니다. 회계 프로그램 1C 8.3 회계. 그러나 귀하의 조직에 급여 및 인력에 대한 더 큰 규모의 상세한 회계가 필요한 경우 이를 위해 다음이 필요합니다. 추가 프로그램 1C 8.3 급여 및 인사 관리. 두 프로그램에 기록을 보관하는 것은 그리 편리하지 않지만 1C는 이 문제를 해결했습니다. 이제 ZUP 3.1에서 Accounting 3.0까지 1C 8.3 데이터베이스 간의 데이터 교환이 자동으로 발생합니다. 하지만 이를 위해서는 1C 8.3 Accounting과 ZUP 간의 동기화를 설정해야 합니다. 기술 전문가의 개입 없이 직접 이 작업을 수행하는 방법을 이 기사에서 읽어보세요. 몇 단계를 거쳐 ZUP 3.1에서 회계 3.0까지 1C 8.3 데이터베이스 간의 데이터 교환을 설정하는 방법은 아래를 참조하십시오.
1단계. 1C ZUP 3.1에서 동기화 설정
"관리"섹션(1)에서 1C ZUP 8.3으로 이동하여 "데이터 동기화"링크(2)를 클릭합니다. 교환 설정 창이 열립니다.
열리는 창에서 "데이터 동기화"(3) 옆의 확인란을 선택하고 "데이터 동기화 설정" 링크(4)를 클릭합니다. 설정 창이 열립니다.
열리는 창에서 "데이터 동기화 설정" 버튼(5)을 클릭하고 "엔터프라이즈 회계, 에디션 3..."(6) 링크를 클릭합니다. 설정을 계속할 수 있는 창이 열립니다.
새 창에서 "수동으로 설정 지정"(7)을 선택하고 "다음" 버튼(8)을 클릭합니다. 교환 매개변수를 입력할 수 있는 창이 열립니다.
열리는 창에서 일부 시스템 교환 매개변수를 지정해야 합니다. 먼저 다른 프로그램에서 연결 옵션을 선택해야 합니다. 이 예에서는 "이 컴퓨터의 프로그램에 직접 연결..."(9)입니다. 이 방법은 1C 8.3 회계 프로그램이 하나의 컴퓨터 또는 하나의 컴퓨터에 있는 경우에 사용됩니다. 지역 네트워크 1C 8.3 ZUP으로. 다음으로 다른 프로그램에서 연결 매개변수를 지정해야 합니다. 이 예에는 두 가지 가능한 옵션이 있습니다.
- ~에 이 컴퓨터또는 로컬 네트워크의 컴퓨터에서
- 1C:Enterprise 서버에서
이 예에서는 두 번째 옵션(10)을 선택하고 "서버 클러스터"(11) 및 "Infobase 이름"(12) 필드를 채웁니다. 다음 단계(2단계)에서 이러한 필드에 대한 데이터를 가져올 위치를 읽어보세요.
그런 다음 "1C:Enterprise Authentication"(13)을 선택하고 1C 8.3 Accounting에 로그인하는 데 사용하는 사용자(14)와 비밀번호(15)를 입력합니다. 데이터가 입력되었으므로 이제 "확인..." 버튼(16)을 클릭하여 연결을 확인하십시오. 만약에 수표가 통과될 거야성공하면 잠시 후 "연결 확인이 성공적으로 완료되었습니다"라는 메시지가 나타납니다. 문제가 발생하면 다음과 같은 오류 메시지가 표시됩니다. 간단한 설명문제.
다음 단계에서는 서버 클러스터 및 데이터베이스 이름에 대한 데이터를 가져올 수 있는 위치를 설명하고, 세 번째 단계에서는 동기화 설정으로 돌아갑니다.
2단계. 1C 8.3에서 클러스터 및 정보베이스 이름에 대한 데이터를 가져오는 위치
1C에 로그인하면 시작 메뉴가 표시됩니다. 이 메뉴에서 1C 8.3 회계 (1)에서 동기화를 설정하는 데이터베이스를 한 번 클릭하십시오. 그런 다음 "변경" 버튼(2)을 클릭합니다. 데이터베이스 편집 창이 열립니다.
이 창에는 서버 클러스터(3)에 대한 데이터와 정보베이스 이름(4)이 표시됩니다.
이제 동기화 설정으로 돌아가겠습니다.
3단계. 1C ZUP 3.1에서 동기화 설정을 계속합니다.
첫 번째 단계에서는 연결 확인을 중단했습니다. 모든 것이 잘 진행되었다면 “다음” 버튼(1)을 클릭하세요. 다음을 위한 창이 열립니다. 추가 사용자 정의동기화
새 창에는 1C ZUP에서 1C Accounting으로 데이터를 업로드하기 위한 규칙 (2)이 표시됩니다. 이러한 설정을 변경하려면 "변경" 링크(3)를 클릭하십시오. 교환 규칙 설정이 열립니다.
이 창에서 교환 시작 날짜(4)를 지정하고 교환할 조직을 선택(5)할 수 있습니다. 1C 8.3 회계에서 거래를 생성하는 방법을 선택할 수도 있습니다.
- "직원별 세부정보 포함"(6);
- "직원 요약"(7).
설정을 저장하려면 "저장 및 닫기" 버튼(8)을 클릭하십시오. 다음 설정으로 이동하려면 "다음"(9)을 클릭하세요. 추가 설정을 위한 창이 열립니다.
이 창에는 1C Accounting에서 1C ZUP로 데이터를 업로드하기 위한 규칙(10)이 표시됩니다. 필요한 경우 "변경" 링크(11)를 클릭하여 이전 설정과 유사하게 변경할 수 있습니다. 계속하려면 "다음" 버튼(12)을 클릭하세요. 동기화 설정에 대한 일반 정보가 포함된 창이 열립니다.
오류가 없으면 성공적인 데이터 동기화에 대한 메시지가 포함된 창이 열립니다(15). 프로그램은 기본적으로 동기화하라는 메시지를 표시합니다(16). 이렇게 하려면 "다음" 버튼(17)을 클릭하세요. 데이터 일치 정보가 포함된 창이 열립니다.
새 창에서 동기화되지 않은 데이터가 있는 디렉터리를 볼 수 있습니다(18). 설정에 지정된 날짜부터 두 가지 다른 정보 기반(1C ZUP 및 1C 회계)의 정보를 동기화하므로 두 데이터베이스의 특정 디렉터리에 동일한 값이 있어야 합니다. 이러한 참고 서적에는 예를 들어 " 개인", "조직", "회계에 임금을 반영하는 방법." 이 창에는 데이터가 일치하지 않는 디렉터리(18)가 표시됩니다. 프로그램은 두 데이터베이스 모두에 누락된 디렉터리 요소를 자동으로 생성합니다. 이렇게 하려면 "다음" 버튼(19)을 클릭하세요. 데이터를 동기화하기 위해 다음 창이 열립니다.
열리는 창에서 프로그램은 전송될 데이터의 구성에 대해 알려줍니다. 이 데이터 목록을 보여주는 보고서를 보려면 "구성 보고서..."(20) 링크를 클릭하십시오. 교환을 완료하려면 "다음"(21)을 클릭하세요. 교환 절차가 시작되며 시간이 좀 걸립니다.
데이터 교환이 완료되면 동기화가 완료되었음을 나타내는 창이 열립니다(22). 이 창에서는 소위 "교환 일정"을 구성할 수 있습니다. 두 데이터베이스 간의 데이터 교환이 자동으로 발생하는 임시 규칙입니다. 이러한 규칙을 구성하려면 "구성" 버튼(23)을 클릭하세요. 데이터 동기화 스크립트가 열립니다.
스크립트 창에서 “일정 설정” 아이콘을 클릭하세요. 규제 업무"(24). 교환 일정 설정이 열립니다.
이 설정에서는 프로그램이 데이터를 교환해야 하는 시간 간격을 재량에 따라 설정할 수 있습니다. 예를 들어, "Repeat after" 필드(25)에서 교환이 반복되는 시간(초)을 설정할 수 있습니다. 설정을 저장하려면 "확인"(26)을 클릭하십시오.
데이터베이스 간의 동기화를 성공적으로 구성하고 데이터 교환을 시작했습니다. “데이터 동기화” 창에서 교환 설정을 변경하고 동기화 프로세스를 제어할 수 있습니다. "데이터 동기화" 링크(28)를 클릭하여 "관리" 섹션(27)을 통해 입력할 수 있습니다.
읽다,
간단한 실제 사례를 살펴보겠습니다. 도매 및 소매업에 종사하는 회사가 있고 이 회사에서도 다른 회사와 마찬가지로 회계가 수행된다고 가정해 보겠습니다. 기업에는 각각 UT(무역 관리)와 BP(기업 회계)라는 두 개의 표준 데이터베이스가 있으며 각 데이터베이스에는 자체 기록이 보관되며 UT에는 무역과 관련된 모든 거래를 반영하는 관리가 있습니다. BP에는 회계가 있습니다. 이중 작업을 하지 않기 위해, 즉 두 개의 데이터베이스에 동일한 문서를 생성하지 마십시오. (결국 이동은 관리 및 회계에 포함되어야 합니다.) 우리는 이러한 데이터베이스 간의 동기화를 설정하겠습니다.
단방향 데이터 교환을 설정하겠습니다., UT ---> BP에서. 양방향 교환을 설정하는 것도 가능하지만 실제로는 이것이 필요한 경우가 많지 않으므로 이 예에서는 고려하지 않겠습니다.
BP에서 거래소를 설정하기 위한 준비 단계
동기화 설정을 시작하겠습니다. 먼저 1C "Enterprise Accounting 3.0" 데이터베이스(수신자)로 이동합니다. 이 데이터베이스에 대해 동기화가 활성화되어 있는지 확인해야 합니다. 이를 위해서는 먼저 데이터베이스로 이동해야 합니다. 데이터베이스가 열리자마자 탭으로 이동하세요. "관리" ---> "데이터 동기화 설정"
우리 앞에 펼쳐진다 새로운 삽입, 정보베이스 접두어를 제외하고 아래 스크린샷과 동일한 방식으로 작성해야 합니다. 접두사는 두 글자로 구성되어야 하며 무엇이든 설정할 수 있지만 1C 표준에 따르면 구성 이름으로 접두사를 설정하는 것이 좋습니다. 즉, "Enterprise Accounting"의 경우 접두사는 "BP"입니다. 복잡한 교환을 설정하고 여러 회계 데이터베이스가 있는 경우 접두사는 서로 분명히 달라야 하며 여기서는 조직 이름의 처음 두 글자를 약어로 사용할 수 있습니다.
UT에서 데이터 동기화를 계속 설정합니다.
수신자 데이터베이스(BP 3.0)에서 필요한 모든 작업을 수행한 후 데이터 교환 설정을 계속하려면 소스 데이터베이스(UT 11.1)를 열어야 합니다. "관리" 탭으로 이동하여 왼쪽 메뉴에서 "데이터 동기화 설정"을 선택하세요.. 동기화가 활성화되지 않은 경우 확인란을 사용하여 활성화하고 소스 기본 접두사를 지정하는 것을 잊지 마십시오. 아래 이미지에 표시된 대로 1~4단계를 모두 완료한 후에는 "데이터 동기화" 하이퍼링크(5단계)를 클릭해야 합니다.
나타나는 새 창에서 녹색 더하기 기호(데이터 동기화 설정)를 클릭하고 드롭다운 메뉴에서 "Enterprise Accounting 3.0" 항목을 선택해야 합니다.
UT와 BP 간의 데이터 교환에서 중요한 사항 설정
이제 1C의 데이터 동기화 설정 창이 표시되고 "수동으로 설정 지정"을 선택하고 "다음"을 클릭합니다.
1C에서 데이터 교환을 계속 설정합니다. 다음 탭에서 수신기 정보 베이스에 연결하는 옵션(프로그램에 직접 연결), 연결 매개 변수(이 컴퓨터 또는 로컬 네트워크에서), 디렉터리를 선택해야 합니다. 수신기 베이스와 필요한 인증 데이터(데이터베이스의 사용자 이름 및 비밀번호)가 있습니다.
다음 페이지에서는 BP 3.0(수신자) 구성에서 데이터를 보내고 받는 규칙을 작성해야 합니다. "데이터 업로드 규칙 변경"을 클릭하세요.
"데이터 전송 규칙"창이 우리 앞에 열렸으며 여기에서 다음 매개 변수를 설정했습니다.
- 어떤 참조 데이터가 전송될지(이 예에서는 문서와 문서에 사용된 참조 데이터에만 관심이 있으므로 적절한 항목을 선택했습니다. 첫 번째 항목인 "모두 보내기"를 선택하면 모든 참조 도서가 다시 로드됩니다) 문서와 함께 정보가 문서에 사용되지 않은 경우 회계에 어떤 식으로든 영향을 미치지 않기 때문에 수신자에게는 쓸모가 없는 경우가 많습니다.)
- 모든 정보는 언제부터 전송되어야 합니까?(이 문서에서는 수동 동기화를 고려하지 않습니다.)
- 어느 조직에 데이터를 보낼지(이 예에서는 IP "기업가"라는 조직 하나를 선택했습니다)
- 계약 체결 규칙
- 종합창고
- 문서를 창고별로 롤업해야 합니까?
설정을 완료한 후 "저장 및 닫기"를 클릭합니다.
이 예에서는 UT에서 BP로의 단방향 교환을 설정하고 사용하므로, "Enterprise Accounting 3.0"에서 데이터를 얻기 위한 규칙 설정에 관심이 없으므로 "다음"을 클릭합니다.
새 창에서는 RB(수신자 기반)에 대한 규칙을 구성하라는 메시지가 표시됩니다. 포인트 1에서는 데이터베이스 이름을 지정하고 접두사를 지정합니다. PREFIX는 이 기사의 시작 부분에서 BP 데이터베이스 자체에 설정한 것과 동일해야 하며, 접두사가 다른 경우 1C 프로그램의 데이터 동기화가 작동하지 않습니다.그런 다음 포인트 2를 클릭한 다음 포인트 3을 클릭합니다.
단락 3에서는 문서가 데이터베이스에 로드될 때 문서가 처리되도록 허용해야 합니다. "저장 후 닫기"를 클릭하세요.
이제 창이 아래와 같이 보일 것입니다. "다음"을 클릭하십시오.
이 창에는 1C에서 생성되는 동기화에 대한 참조 정보가 포함되어 있습니다. "다음" 버튼을 클릭하시면 됩니다. 데이터 동기화를 설정할 때 프로그램에서 오류가 발생한 경우 1C 전문가가 즉시 도움을 드릴 수 있도록 당사에 문의해야 합니다!
다음 단계 프로그램은 데이터 교환 설정을 생성한 후 즉시 동기화를 제안합니다.. 이에 동의하고 "완료"를 클릭합니다.
동기화 진행 방법에 대한 정보를 볼 수 있는 창이 나타납니다. 수신기 베이스가 비어 있지 않은 경우, 즉 기록이 이미 보관되어 있으면 1C 프로그램의 사용자에게 개체를 수동으로 비교하라는 메시지가 표시됩니다. 데이터를 동기화할 때 1C의 개체 비교는 동일한 수신기 개체를 다음과 비교하는 것입니다. 동일한 객체소스에서.
예를 들어 UT에 "PharmGroup LLC"라는 이름과 TIN 1234567을 가진 상대방이 있고 BP에도 TIN 1234567을 가진 상대방이 있지만 이를 비교하지 않으면 이름이 "PharmGroup"이라고 가정해 보겠습니다. 동기화 단계에서 데이터를 비교할 때 두 개체를 비교한 다음 수신기(Enterprise Accounting 3.0)에서 동기화한 후 TIN 1234567과 각각 "PharmGroup LLC" 및 "PharmGroup"이라는 두 개의 이름을 가진 두 개의 상대방을 갖게 됩니다. 피하기 위해 비슷한 상황개체를 일치시키는 메커니즘이 발명되었습니다.
이 예에서는 수신자 데이터베이스가 비어 있으므로 개체 비교 창이 열리지 않았습니다. 그러나 일부 작업을 수행한 후 시스템은 사용자에게 추가 데이터를 추가하라는 메시지를 표시하고 다음 창을 표시합니다. 추가 데이터를 전송할 필요가 없으며 이전에 필요한 모든 것을 이미 구성했으므로 이 단계에서는 "전송에 문서를 추가하지 않음"을 선택합니다. "다음"을 클릭하세요.
1C 간의 데이터 교환의 마지막 단계
마지막 단계에서 프로그램은 동기화가 성공했음을 사용자에게 알리는 다음 창을 표시하고 "마침"을 클릭합니다. 이 시점에서 "Trade Management 11.1"(UT)에서 "Enterprise Accounting 3.0"(BP)으로의 단방향 교환에서 데이터베이스 간의 동기화가 완료됩니다.
