집 용법 1c 8.3 자신의 데이터 교환을 설정하는 방법. 신진 대사에 영향을 미치는 BP와 UT의 차이점

1c 8.3 자신의 데이터 교환을 설정하는 방법. 신진 대사에 영향을 미치는 BP와 UT의 차이점

이 기사를 내 메일로 보내기

1C 데이터베이스 간의 교환을 도입해야 하는 주요 이유는 지점의 존재와 회계 유형의 분리, tk입니다. 회사는 종종 여러 정보 베이스에서 일합니다. 1C 8.3 교환을 설정하면 두 개의 프로그램에 동일한 문서와 디렉토리를 입력하고 다양한 지점과 부서에 필요한 시스템 개체를 신속하게 제공하는 이중 작업을 제거할 수 있습니다.

지점간 교환이 필요한 경우에는 RIB(Distributed Infobase)를 사용합니다. 동일한 구성 간에 교환하기 위한 메커니즘입니다. 그것은 트리이며, 그 위에 가장 중요한 루트 노드가 있고, 상호 연결된 한 쌍의 노드 아래에 있습니다. 변경 사항은 이 시스템의 모든 노드에서 수행할 수 있으며 다른 관련 노드로 전파됩니다. 또한 데이터뿐만 아니라 루트 노드에서 하위 노드로 구성 변경 사항을 배포합니다.

예를 들어 거래 기반에서 운영 계정을 유지 관리하고 규제 유형을 분리해야 하는 경우 회계 유형에서 유연한 데이터 동기화 설정이 있는 범용 교환 메커니즘을 사용할 수 있습니다.

1C의 최신 개발 중 하나는 EnterpriseData 데이터 교환 형식입니다. 사용하기 쉽고 회사 내에서 1C 데이터베이스와 타사 프로그램 간에 교환하기 위한 것입니다.

기업에서 데이터 교환의 구현은 순차적 절차로 나타낼 수 있습니다.

우선, 어떤 기지 사이에 교환이 있어야 하는지를 결정할 필요가 있습니다. 양방향 또는 단방향 교환입니까? 단방향인 경우 어떤 베이스가 정보를 전송하고 어떤 베이스만 수신할지; 이것이 복잡한 분기 네트워크인 경우 데이터베이스 구축 계획을 규정해야 합니다.

그런 다음 적절한 형식을 선택합니다. RIB, 범용 형식; 교환 규칙에 따른 교환 교환 규칙이 없는 교환.

다음 단계는 교환을 수행할 전송을 선택하는 것입니다. 사용 가능 큰 선택기술, 우리는 주요 기술을 강조합니다: 디렉토리(로컬 또는 네트워크), FTP 리소스, COM 연결, 웹 서비스, 이메일.

네 번째 단계는 문서, 디렉토리 및 필요한 경우 전송할 개별 세부 정보와 같은 데이터의 정의입니다.

그리고 결론적으로 교환 주기에 대한 일정이 정해져 있습니다.

교환 1C 8.3을 설정하기 위한 각 옵션에는 신중한 준비가 필요합니다. 구현은 모든 사용자의 권한을 넘어서는 것이므로 많은 뉘앙스를 고려하고 교환 원칙을 이해해야 합니다. 베이스에 개선 사항 또는 추가 기능이 많이 포함되어 있는 경우 설정에 특별한 주의를 기울여야 합니다. 세부 정보, 플랫폼 버전이 다르거나 오래된 구성 버전이 사용되는 경우, 기업이 크고 많은 수의 데이터베이스로 구성된 자동화된 시스템을 사용합니다. 여기서 실수는 허용되지 않습니다. 돌이킬 수 없는 결과를 초래할 수 있습니다. 1C에서 교환을 독립적으로 구현하는 것은 일반적인 구성 간에 간단한 정보 전송을 설정해야 하는 경우에만 권장됩니다.

당신의 능력이 의심된다면 돈을 저축하지 말고 결정을 도울 유능한 전문가에게 연락하는 것이 좋습니다 어려운 일교환 설정 1C 8.3.

전문가를 포함하지 않고 1C 교환을 구성하기로 결정한 경우 먼저 데이터베이스 복사본을 테스트하고 작업 데이터베이스에서 작업을 시작하기 전에 구성을 업로드하여 오류가 발생한 경우 원래 상태로 돌아갈 수 있도록 하는 것이 좋습니다. .

아래에서 우리는 자세한 예 1C 8.3 표준 구성 Trade Management 11(UT)과 Enterprise Accounting 3.0(BP) 간에 일방적으로 설정을 교환합니다. 이 예는 도소매 무역을 주도하는 많은 회사와 관련이 있습니다. UT에서는 관리 회계가 유지되고 BP는 규제되며 사용자 작업을 용이하게 하기 위해 교환이 필요합니다.

이 알고리즘은 1C 8.3 플랫폼의 다른 일반적인 구성에도 적합합니다.

우선 정보수신자를 위한 준비작업을 진행합니다. BP를 위해. 엔터프라이즈 모드에서 프로그램을 실행합니다. 데이터 동기화 상수를 설정해야 합니다(관리 → 데이터 동기화 섹션).

접두사 필드에 주의하십시오. 여기서 나중에 개체가 원래 생성된 프로그램(참조 코드 또는 문서 번호의 값으로)을 구별할 수 있는 값을 지정해야 합니다. 이 예에서는 일반적인 약어가 적합합니다. BP 및 UT, 1C 8.3 교환이 동일한 구성뿐만 아니라 많은 수의 베이스 간의 복잡한 교환을 위해 구성된 경우 각 베이스는 이해할 수 있는 고유한 지정을 입력해야 합니다.

PSU는 정보 수신기일 뿐이므로 UT 설정을 진행합니다.

여기에서 뿐만 아니라 BP에서도 동기화를 활성화하고 접두사를 지정해야 합니다. 이 정보는 마스터 데이터 및 관리 → 데이터 동기화 설정 섹션에서 확인할 수 있습니다.

설정 방법 선택 수동으로 설정을 지정합니다. 더 나아가.

두 프로그램이 같은 위치에 있을 때 직접 연결 옵션을 설정합니다. 지역 네트워크, 이 네트워크의 IS 디렉토리에 연결하기 위한 매개변수를 지정하고 사용자에 대한 인증 정보도 입력합니다(BP 데이터베이스에 있음). 더 나아가.

시스템은 지정된 데이터의 정확성을 확인합니다. 긍정적인 결과교환 설정 창을 표시합니다 1C 8.3.

데이터 업로드 규칙 편집 링크는 교환을 수행하기 위한 설정을 제공합니다. 우리는 NSI를 명확히 할 것입니다 - 문서에 사용되는 것만 업로드하고, 조직을 선택하고, 계약 작업 옵션을 링크하지 않고 창고별로 문서를 분리합니다. 교환은 올해 3월 1일에 시작됩니다.

도입된 규칙이 기록되고 닫힙니다.

예에서 우리는 단방향 정보 전송에 대해 이야기하고 있기 때문에 다음 설정 창에서 다른 프로그램에서 데이터를 수신하려면 값을 보내지 않음으로 설정하십시오. 기록하고 닫습니다. 더 나아가.

이제 입력한 매개변수를 확인해야 하며 올바르면 다음을 클릭하고, 그렇지 않으면 뒤로를 클릭하여 이전 단계로 돌아갑니다.

그러면 동기화하라는 메시지가 표시됩니다. 완료를 클릭합니다.

두 구성의 동일한 개체를 연관시켜야 하는 경우 데이터 비교 창이 열립니다. 매핑을 수행하고 다음을 클릭합니다.

개체를 전송할 때 문제 상황이 발생할 수 있으므로 데이터 동기화 시 경고 링크를 클릭하여 결과를 볼 수 있습니다.

동기화가 완료되면 이 프로세스가 성공적으로 완료되었음을 확인하는 창이 표시됩니다.

여기에서 Configure 명령을 사용하거나 그 이후에 동기화 스크립트에서 일정을 구성할 수 있습니다. 자동 실행교환.

각 계획에는 저장할 수 있는 변경 사항에 대한 정보인 특정 요소 목록이 있습니다. 이 목록을 "교환 계획의 구성"이라고 합니다. 구성을 확장할 수 있지만 구성 지원이 제거됩니다.

"계획 레이아웃"은 동기화가 작동하는 바로 그 규칙을 저장합니다. 우리가 더 연구해야 할 것은 이 변환 패키지(등록 규칙, 교환 규칙, 통신원 교환 규칙)입니다.

"1C: 급여 및 HR 3"(ZUP) 및 "1C: Enterprise Accounting 3"(BP) 구성 간의 데이터 동기화 예를 고려하십시오. 이 작업에서 지원에서 구성을 제거해야 함을 즉시 확인합니다. 이것은 조건에 따라 필요합니다.

모델 교환 규칙을 개선해야 할 필요성을 보여주는 살아있는 예

예를 들어, 고객이 다음과 같은 문제로 문의했습니다. ZUP과 BP 간에 동기화할 때 "조세 당국에 등록" 디렉토리의 데이터를 전송할 수 없습니다. 이 데이터는 "임금 반영 회계” 문서. 이제 BP 수신자 측면에 있는 이 문서의 표 부분에는 비어 있는 "등록 ..."이 포함되어 있으며 사용자는 디렉토리에 이러한 항목을 수동으로 생성해야 합니다. 동의합니다. 불편합니다. 이 점을 개선할 수 있습니다.

문제 해결: 교환 계획 ExchangeSalary3Accounting3에서 변환 패키지를 마무리합니다. 표준 "1C Exchange Rules"에 "Registration with the Tax Authority" 디렉토리에 대한 새로운 "Object Conversion Rule"(PKO)을 추가하고 이에 따라 이 디렉토리(PKS)의 "Property Conversion"을 추가해 보겠습니다. 우리는 표준 "객체 등록 규칙"을 확실히 마무리할 것입니다. 교환 노드에서 디렉토리 변경 사항을 등록할 필요가 있었습니다. 그리고 특파원 기반의 "1C 교환 규칙"을 수정합니다.

우리는 이것을 어디에서 편집할 것인가? 규칙을 작성하고 변경하려면 "1C: 데이터 변환 2" 구성이 필요합니다.

PZUP-BP 교환 계획의 표준 변환 규칙 개선

따라서 교환 계획에 대한 구성기의 구성에 ExchangeSalary3Accounting3을 추가하여 1C 교환 규칙을 마무리하기 시작하겠습니다. 새로운 요소- 세무 당국의 등록 디렉토리. "1C: 급여 및 엔터프라이즈 관리 3" 및 "1C: 엔터프라이즈 회계 3" 구성 모두에서 이 변경을 수행합니다.

구성을 저장하고 업데이트합니다.

엔터프라이즈 모드에서 각 데이터베이스에 대해 1C:Enterprise 8.3 플랫폼용 MD83Exp.epf 처리를 사용하여 메타데이터 구조에 대한 설명을 업로드합니다. 처리는 "1C: 데이터 변환" 키트에서 찾을 수 있습니다.

다음 단계에서는 ZUP 및 BP에서 변환 패키지를 언로드합니다. 패키지는 등록 규칙, 교환 규칙, 해당 교환 규칙의 3개 파일로 구성되어야 합니다.

이 기사의 프레임워크 내에서 데이터 동기화가 구성되는 방법에 대한 설명은 없습니다. Coderline 웹사이트의 전문가 기사 섹션에서 읽거나 웨비나 녹화를 시청할 수 있습니다. 이제 이 옵션은 데이터베이스에 이미 구성되어 있습니다. 따라서 동기화 설정(관리 -> 데이터 동기화 -> 데이터 동기화 설정)으로 이동하여 "규칙 로드" 버튼을 클릭합니다. "동기화 규칙"이라는 형식이 표시됩니다. "추가" 버튼을 클릭하고 "파일에 규칙 저장" 옵션을 선택합니다.

다음은 언로드 후 얻을 수 있는 패키지입니다.

다른 사람도 똑같이 해보자 정보 기반"1C: 기업 회계".
결과적으로 규칙 편집을 위한 모든 준비 작업이 완료되었습니다. 우리는 다음을 가지고 있습니다:

"1C: Data Conversion 2"(ZUP 및 BP용)에 로드하기 위한 메타데이터 구조에 대한 설명.

1C에 업로드하는 데 필요한 1C 교환 규칙 및 등록 규칙이 포함된 변환 패키지: 데이터 변환 2(ZUP 및 BP용).

"1C: 데이터 변환 2"로 이동합니다. 두 정보 베이스에 대해 다음 단계를 수행하십시오.

구성의 메타데이터 구조를 로드합니다.

변환을 생성하고 변환 패키지에서 1C 데이터 교환 규칙을 로드합니다(규칙 파일은 ExchangeRules라고 함).

등록을 만들고 변환 패키지(규칙 파일은 RegistrationRules라고 함)에서 등록 규칙을 로드합니다.

우리는 직접 정제를 진행합니다. 1C 교환 규칙인 "조세 당국에 등록" 참고서에 새로운 객체 변환 규칙(PKO)을 추가합니다. 이 디렉토리에 대한 속성 변환 규칙(PCS)과 데이터 업로드 규칙(PDS)을 추가합니다. 이러한 종류의 구체화는 ZUP 패키지의 규칙과 BP 패키지의 교환 규칙 모두에 대해 수행되어야 합니다. 교환 규칙을 해당 파일인 ExchangeRules로 언로드합니다.

새 요소를 등록하는 규칙으로 넘어갑시다. 우리는 참고서 "조세 당국에 등록"을 추가합니다. RegistrationRules 패키지에서 적절한 파일로 등록 규칙을 업로드하십시오. 이 작업은 두 기지 모두에 대해서도 수행됩니다.

수정된 교환 규칙 및 등록 규칙이 준비되었습니다. 이제 교환 규칙(ExchangeRules)의 내용을 BP 패키지에서 ZUP 패키지의 해당 규칙(CorrespondentExchangeRules)으로 복사합니다. BP 패키지의 해당 규칙(CorrespondentExchangeRules)에서 ZUP 패키지의 교환 규칙(ExchangeRules) 내용을 복사합니다.

결과는 다음과 같아야 합니다.

이것으로 "1C: 데이터 변환 2"의 작업이 완료됩니다. 수정된 변환 규칙 패키지가 준비되었으며 정보 베이스에 다시 업로드하고 동기화를 확인해야 합니다.

패키지의 파일을 ZIP 아카이브로 아카이브하고 변환 패키지를 ZUP 및 BP에 업로드합니다.

모든 준비가 완료되었습니다. 테스트가 남아 있습니다.

문제의 조건을 기억합시다. "세무 당국에 등록"디렉토리를 언로드하기 위해 등록하고 "1C : 기업 회계 3"측면에 "회계에 임금 반영"문서의 PM이 어떻게 작성되는지 확인해야했습니다.

소스 "1C: Salary and Enterprise Management 3"에서 언로드할 디렉토리를 등록합니다. 동기화를 수행합니다. 우리는 수신기 데이터베이스로 이동하여 데이터를 수신하기 위한 동기화도 수행합니다. 이제 변경 사항을 등록하는 데 필요한 디렉토리가 교환 계획에 나타납니다.

"1C: Enterprise Accounting 3" 측면을 확인합니다.

요약하다. 작업 결과가 성공적으로 완료되었습니다. ZUP - BP 교환 계획을 확정하고 변경 사항 등록을 위한 새로운 요소를 추가하고 데이터 동기화를 위한 변환 규칙을 완료했습니다.

거래 활동에 종사하는 많은 기업가는 관리 효율성을 향상시키기 위해 두 개의 1C: 회계 8 프로그램을 동시에 취득합니다. (이하 BP)및 "1C: 무역 관리 8" (이하 UT).

BP는 규제된 회계 및 보고를 유지하는 데 사용되며 UT는 운영 및 관리 회계회사.
이러한 공유의 성공 소프트웨어 제품 BP와 UT 구성 간의 데이터 교환 구성에 크게 의존합니다.

일반적인 데이터 교환의 다음 기능을 이해하면 구성 간의 교환 과정에서 발생하는 오류와 각 구성에서 개별적으로 계정 위반을 방지하는 데 도움이 됩니다.

이 기사를 작성할 때 소프트웨어 제품에 대한 1C 문서의 자료가 사용되었습니다. 교환 설정 방법은 htm-file "에 자세히 설명되어 있습니다. 나누는구성 Trade Management(11) 및 Enterprise Accounting "은 1C: Accounting 2.0(이하 BP) 및 1C: Trade Management 11(이하 UT)을 모두 설치할 때 템플릿 카탈로그에 있습니다. 파트너 회의 1C에서 받은 권장 사항 및 개인적인 경험 RG-Soft Project Consulting LLC의 클라이언트를 위한 교환 설정 생성 및 변경에 대한 작성자입니다.

1. 단방향 또는 양방향 교환을 설정합니다.

먼저 현금 및 비현금 거래와 관련된 문서만 BP 구성에서 UT 구성으로 업로드할 수 있다는 점에 유의해야 합니다. 여기에는 들어오는 현금 주문, 나가는 현금 주문, 현재 계정으로의 수금 및 현재 계정에서 상각이 포함됩니다. BP에서 생성된 물품 이동 문서는 UT에 업로드되지 않습니다.

회사 1C는 UT에 있는 은행과 교환할 것을 권장합니다. "이를 통해 지급 문서 등의 본격적인 작업이 보장됩니다. 간단한 일들어오는 문서와 함께. 그러나 이 파일은 BP에 완전히 업로드된 상태에서 클라이언트 은행 파일에서 UT로 거의 단일 지불 주문을 업로드할 수 없는 상황이 있었습니다.

이는 클라이언트 은행 파일의 내용에 대한 보다 엄격한 검사가 UT에 추가되었다는 사실 때문입니다. 예를 들어 TIN 완료 확인, 문서 번호 확인, 2002년 10월 3일의 중앙 은행 규정 N2-P "현금 없는 지불 러시아 연방(2003년 3월 3일, 2004년 6월 11일, 2007년 5월 2일, 2008년 1월 22일 수정).

단방향 교환(UT에서 BP로)을 설정하는 것은 모든 문서와 참조 정보가 UT로 채워진 경우에만 의미가 있습니다. 따라서 이 데이터베이스에 있는 요소의 중복을 피할 수 있습니다.

이렇게 하려면 다음 교환 시나리오를 구성해야 합니다. UT 구성에서 언로드만 저장되는 교환 시나리오를 만들고(그림 1), BP 구성에서 교환 시나리오를 만들고 다운로드만 저장합니다.

이러한 교환 시나리오에서 BP에서 생성된 모든 추가 문서 및 디렉토리는 교환을 위해 등록되지만 UT에는 로드되지 않으므로 주기적으로 등록을 재설정하는 것이 좋습니다. 그렇지 않으면 교환 BP의 메시지 파일이 지속적으로 증가하여 교환 프로세스가 느려집니다.

이를 위해 처리를 사용하는 것이 좋습니다. RegisterChangesForExchange82.epf, 구성 전달 "Data conversion, rev. 2.1"에서 찾을 수 있습니다. 구성이 설치된 후 처리는 업데이트 설치 디렉토리에 있습니다. ...\1c\Conversion\...version_number…

규정 및 참조 정보가 UT와 BP 모두에 채워지면 양방향 교환을 구성해야 하지만 자동이 아닌 대화형 모드에서 교환을 시작하여 중복을 추적해야 할 수 있습니다(그림 2). .

문서 수준에서만 데이터 교환을 제한하기 위해 단방향 교환을 구성 할 필요가 없으며 BP 측의 교환 필터에서 날짜보다 큰 날짜를 설정하면 충분합니다. 마지막 문서(그림 5 참조). 그러나 날짜에 필터를 설정하기 전에 BP의 문서가 이전에 교환을 위해 등록되지 않았는지 확인해야 합니다. 그렇지 않으면 등록된 문서가 교환 중에 다른 데이터베이스로 전송됩니다.

데이터 변경 우선 순위

교환이 먼저 UT에서 수행된 다음 BP에서 수행되면 UT에서 다운로드한 데이터가 우선합니다. 예를 들어 UT에서 "현재 계정에 대한 영수증" 문서를 입력하고 UT에서 먼저 교환을 시작한 다음 BP에서 - 문서가 BP 구성에 나타납니다. 그런 다음 BP 구성의 회계사가 이 문서를 변경했습니다. 후속 교환 중에 교환 시작 순서가 변경되지 않은 경우 문서에 대한 변경 사항은 UT의 데이터로 덮어씁니다.

두 데이터베이스에서 변경된 개체와의 올바른 교환을 위해 1C는 개체가 데이터베이스 중 하나에서만 편집되도록 작업을 구성하는 것이 좋습니다. 다른 데이터베이스에서는 이러한 개체를 보기 위해서만 열어야 합니다. 이렇게 하려면 사용자 액세스 권한 설정을 사용해야 하지만 이 접근 방식은 교환 중에 충돌이 없음을 보장합니다. 교환 기간 동안 하나 또는 다른 데이터베이스에서 개체가 변경될 때 발생하는 불일치(그림 3).

2. 신진대사에 영향을 미치는 BP와 UT의 차이점

상대방 계약

UT 구성에는 상대방의 계약에 대한 분석이 없습니다. UT 구성에서 수행되는 모든 작업은 BP 구성으로 로드될 때 항상 UT 시스템 자체에서 생성 및 제어하는 별도의 계약에 따라 실행됩니다.

BP 구성에 필수 매개변수가 있는 계약이 없으면 그러한 계약이 생성됩니다. 계약 검색은 이전에 UT에서 다운로드한 계약 수에서만 수행됩니다.

UT의 관리 조직

릴리스 11.0.6.9부터 사전 정의된 요소 "관리 조직"이 조직 디렉토리의 UT에 나타납니다. 이 요소는 현재(단일 또는 그 중 하나) 조직에 매핑되거나 변경되어서는 안 됩니다. 문서 파일에서 이 개체의 사용에 대해 자세히 읽을 수 있습니다. "documentation.htm의 변경 사항 및 추가 사항" UT 배송에 포함됩니다.

회사 구조

관리 회계를 위한 UT에서는 회사 부서 목록이 포함된 "기업 구조" 디렉토리가 사용됩니다. 문서를 작성할 때 기업 부문의 표시는 필수입니다.

"Enterprise Structure" 디렉토리의 요소는 BP의 "Organization Units" 디렉토리의 요소에 매핑되지 않습니다. Subdivision 속성이 비어 있는 문서가 UT에 업로드되는 것을 방지하려면 교환 설정에서 기본값을 채워야 합니다(그림 4).

표 섹션의 창고

UT에서 사용할 계획이라면 새로운 기회문서의 표 섹션에서 창고를 지정한 다음 교환 계획 노드의 설정에서 일반화된 창고를 설정해야 합니다. 이 창고는 UT에서 BP 구성으로 문서를 언로드할 때 대체됩니다. 문서의 표 부분 (그림 4).

항목 형식

BP에서 UT로 데이터를 업로드할 때 "항목 유형" 속성이 명명법에 채워지지 않습니다. 이는 명명법이 BP가 아닌 UT 구성에서 생성될 때 교환기가 시나리오를 제공하기 때문입니다. . UT의 상품 이동에 대한 문서에는 서비스를 설명하는 별도의 표 섹션이 없으므로 (서비스는 상품 테이블에 채워짐) UT 문서에 지정된 서비스가 올바르게 이전되도록 BP의 표 섹션에서 다음을 수행해야 합니다.

1. 참조 정보 섹션에서 "항목 유형" 참조 도서를 열고 "서비스" 항목 보기로 이동하여 "모든 작업"을 클릭하고 편집을 활성화하고 항목 유형 - 서비스를 선택합니다.

2. 항목(서비스) 변경 - "모든 작업" 클릭 - 편집을 허용하고 서비스 유형으로 이 항목 유형을 선택합니다.

3. 교환 필터 설정(그림 5)

문서 업로드(다운로드) 날짜 변경

1) 날짜를 앞당기기 전에, 설정이 변경된 시점에 노드에 교환을 위해 등록된 문서가 없도록 교환 세션을 수행하여 데이터베이스를 동기화해야 합니다. 그렇지 않으면 이러한 문서가 설정을 변경한 후 언로드의 결과로 이전에 업로드된 경우 수신 데이터베이스에서 삭제 표시가 될 수 있습니다.

2) 날짜를 뒤로 이동할 수 있습니다. 업로드된 데이터의 영역만 확장합니다. 이 경우 이전에 마감된 기간의 문서는 자동으로 교환 등록되지 않습니다. 이렇게 하려면 문서를 변경하거나 처리를 사용해야 합니다. RegisterChangesForExchange82.epf.

조직별로 필터링

이 필터를 활성화하면 데이터 교환이 허용되는 조직 목록을 제한할 수 있습니다. 활성화된 필터가 있으면 조직 디렉토리 자체의 언로드와 조직과 관련된 기타 데이터(디렉토리 및 문서)의 언로드에 모두 영향을 미칩니다.

업로드 필터의 작동 원리는 다음과 같습니다. 새 설정은 모든 데이터에 적용됩니다 - 거래소 생성 시 또는 새 설정 적용 후 변경된 데이터에 대해서만 - 거래소가 완료된 후 생성되므로 데이터 교환을 생성할 때 가능한 한 책임감 있게 필터 설정에 접근하는 것이 좋습니다.

예시:거래소를 생성할 때 사용자는 조직별로 필터를 설정합니다. 지정된 조직의 데이터만 수신 데이터베이스에 업로드되었습니다. 또한 사용자는 모든 조직에 대한 데이터를 수신 데이터베이스에 업로드해야 한다고 결정했습니다. 그러나 설정은 새로 변경된 데이터에만 적용되므로 사용자가 변경할 때까지 기존 문서 및 디렉토리는 수신 데이터베이스에 업로드되지 않습니다.

4. 데이터베이스 중 하나에서 개체 제거

삭제 표시

이전에 사용된 디렉토리 요소가 추가 계정에 사용되지 않을 수 있으며 사용자는 이 디렉토리를 삭제 표시로 표시하는 것이 옳다고 생각합니다. 삭제 표시된 개체는 교환에 참여하지 않습니다. 이 기능을 고려해야 합니다.

중복 제거

중복 교환 중에 발생한 개체를 제거하려면 처리를 사용하는 것이 좋습니다. 값 검색 및 바꾸기.epf, ITS 디스크의 \1CITS\EXE\ExtReps\Unireps82\SearchAndChange\ 디렉토리에 있습니다. 그리고 두 정보 베이스의 개체 비교의 정확성을 확인하기 위해 정보 레지스터 "정보 베이스 개체의 일치"를 열 수 있으며 이 레지스터의 항목을 수동으로 수정할 수 있습니다. 데이터베이스 중 하나에서 개체를 삭제한 후에도 정보 레지스터 레코드에는 삭제된 개체와 일치하는 항목(연결 끊김)이 남아 있으므로 다른 개체와 일치시키거나 레코드를 삭제해야 합니다.

5. 추가 설정

현금 흐름 항목

UT를 구성하려면 소품 "corr. BP에 사용 및 업로드될 현금 흐름 항목에 대한 "계정"입니다.

BP 구성의 경우: 디렉토리 요소에 현금 흐름 유형을 입력해야 할 수 있습니다.

사용자

디렉토리 요소 사용자는 교환에 참여하는 개체 중 하나에 책임이 있는 것으로 표시된 경우 다른 데이터베이스로 전송할 수 있습니다. 이러한 개체의 경우 권한을 설정해야 합니다.

기본 접두사 및 조직 접두사

UT에서 접두사는 항상 고정 길이와 구분 기호(하이픈) "-"를 갖습니다. 따라서 infobase 접두사가 지정되지 않았거나 조직 접두사가 지정되지 않은 경우 0으로 대체됩니다. 그러나 교환을 설정할 때 infobase 접두사는 항상 CB(UT의 경우)와 BP(각각 BP 구성의 경우)에 채워집니다.

이 솔루션은 문서 번호 및 개체 코드를 생성하기 위한 표준입니다. 접두사는 고정된 길이를 가지며 문서 번호에서 하이픈으로 구분됩니다. 앞으로 데이터베이스에 여러 조직이 있는 경우 접두사를 설정하는 것으로 충분하며 모든 개체의 번호를 다시 매길 필요가 없습니다.

오류 수정

우리 기사에서 가장 중요한 포인트"1C: Trade Management 8" rev.11과 "1C: Accounting 8" rev.2.0 간의 데이터 교환 조직.

RG-Soft Project Consulting LLC의 전문가는 특정 조직의 회계 기능에 대한 교환 설정뿐만 아니라 기존 교환의 오류를 수정하는 방법도 제공할 준비가 되어 있습니다.

1C 데이터 변환 튜토리얼(에디션 2) 교환 규칙에 대한 자세한 내용

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

교환 규칙은 추가로 데이터의 소스 및 대상 구성을 정의합니다.

"고급" 탭:

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

"매개변수" 탭:

사무실이 상품에 대한 주문만 수락한다고 가정하면 하역 서비스를 금지하는 것이 바람직합니다. 카탈로그 명명법의 항목에 필수 서비스가 True로 설정되어 있으면 언로드되지 않도록 보장됩니다. 원격 사무실에서 서비스 주문도 수락하기 시작하는 경우 규칙을 변경하지 않도록 즉시 서비스 언로드 제어를 선택 사항으로 만드는 것이 가장 좋습니다.

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

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

매개변수를 편집하려면 편집 가능한 교환 규칙에 대한 Conversions 디렉토리 요소의 양식을 열고 매개변수 탭으로 이동하십시오. Parameters 디렉토리의 새 요소를 생성해 보겠습니다. Unload Services라는 매개변수의 이름을 지정해 보겠습니다. 매개변수 이름은 작성할 때 매개변수 구조에서 참조하는 데 사용됩니다. 프로그램 코드핸들러에서. 이름은 범용 데이터 교환을 처리하는 형태로 매개변수의 표 섹션에 표시됩니다. 언로딩을 설정할 때 매개변수가 대화 상자에 표시되도록 하려면 "대화 상자에서 설정" 상자를 선택하고 매개변수 값 유형을 선택해야 합니다. 대화 상자에서 매개변수로 작업하려면 변환 조회에서 요소 형식으로 "버전 2.01 형식으로 매개변수 업로드" 상자도 선택해야 합니다.

매개변수를 지정하는 것만으로는 충분하지 않습니다. 언로드 알고리즘이 요소를 언로드하는 경우와 그렇지 않은 경우를 "이해"해야 합니다. 그러한(및 기타 많은) 경우에 핸들러 메커니즘이 사용됩니다. 그 본질은 데이터 업로드 및 다운로드를 위한 모든 기본 알고리즘 실행의 핵심 지점에서 교환 규칙을 생성할 때 개발자가 작성한 코드가 처리된다는 사실에 있습니다. 당연히 이러한 섬세한 도구를 사용하려면 주의와 사려가 필요합니다. 자신의 핸들러를 작성하기 전에 핸들러에서 사용할 수 있는 모든 변수와 사용 방법을 설명하고 핸들러 유형과 데이터 교환 알고리즘을 호출합니다.

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

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

교환 V8 - V8 전용 및 2.0.18.1 미만이 아닌 다운로드 및 다운로드 처리

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

Unloading parameters(언로드 매개변수) 탭에는 이제 매개변수가 있어 서비스가 언로드되거나 언로드되지 않는 값을 변경합니다.

이 기사에서는 BP 3.0과 UT 10.3 간의 일반적인 데이터 교환이 어떻게 구성되는지 설명합니다. (BP 3.0과의 교환은 릴리스 10.3.20부터 가능)

나는 다음 요구 사항에 따라 교환을 설정합니다. 일괄 상품 이동은 BP로 이전되어야 합니다. 은행 이동에 대한 정보만 BP에서 언로드됩니다.

교환을 설정하려면 다음 단계를 따르세요.

1. 어떤 데이터베이스에서 첫 번째 언로드를 수행할지 결정합니다. 원칙적으로 모든 데이터베이스에서 첫 번째 언로드를 수행할 수 있습니다. 예를 들어 저는 UT 10.3에서 첫 번째 언로드를 수행했습니다. 이렇게 하려면 UT에서 다음을 수행해야 합니다.

1.1. 계정 설정에서 "데이터 교환 사용" 확인란을 선택하고 "IB 접두사"를 지정합니다(BP 2.0과 달리 접두사의 문자 수는 2개로 제한됨).

1.2. "데이터 동기화 설정" 버튼을 클릭하여 교환 계획("도구->1C: Enterprise 8.2 플랫폼의 제품과의 데이터 교환: 데이터 교환") 생성을 위한 도우미를 시작합니다.

도우미의 구성 단계에 대해서만 간략하게 설명하겠습니다.

a) "데이터 동기화 설정 단계 선택"에는 새 교환 계획을 생성하거나 이미 생성된 계획을 계속하는 두 가지 옵션이 있습니다. 제 경우에는 UT 10.3에서 새 계획을 생성하기로 선택하고 회계에서 설정을 계속합니다.

b) 데이터 전송 방법을 선택하고 공유 폴더에 있는 파일을 사용합니다.

c) 동기화 매개변수를 설정하려면 여기에서 다른 데이터베이스의 이름(반드시 "BP"를 표시할 필요는 없음)과 접두사(여기서 정확히 지정해야 함)를 지정해야 하며 업로드 규칙과 관련된 매개변수도 지정해야 합니다. (예: "문서 업로드 시작 날짜", "창고별 분석 업로드", "상각 비용 조정", 업로드 선택 구성 등)