도움을 받아 문제 해결을 강력하게 단순화하는 방법을 보여줍니다.
오늘 우리는 문자 그대로 10-15 분 안에 디렉토리와 초기 잔액을 구성하고 간단하게 전송하는 방법을 분석 할 것입니다.
그리고 이건 - 대량 작업시작된 대부분의 새 구성에는 거의 불가피합니다.
따라서 동료에게 전화하면 매우 유용합니다.
특히 그들이 이미 KD 3을보고 겁을 먹었다면 :)
네, 그녀를 처음 볼 때 무화과는 없습니다.
그러나 실제로 모든 것이 매우 간단합니다. 너무 간단해서 지루할 수도 있습니다. :)
오늘 비디오에 정확히 무엇
공유하는 4 개의 동영상입니다. enterpriseData 범용 교환 형식.
또한 예를 보여 드리겠습니다. 모델 교환 규칙의 개선 1C에서 : 데이터 변환 3.0
총 기간- 34 분. 함유량:
- 1C : 회계 8 및 1C : ERP의 예에서 Exchange 설정
- Data Conversion 3.0에서 표준 규칙 및 범용 교환 형식을로드하는 방법
- CD 3.0에서 메타 데이터 구조 전송
- 첫 번째 데이터 교환을 수행하는 방법
- 규칙 개정 변환
- 구성을 변경하지 않고 새 규칙을로드하는 방법 ( 지원 철회없이)
노트이 문제를 해결할 때로드 규칙은 수신자 구성에서만 변경됩니다. 그리고 소스 구성은 표준 규칙에 따라 작동합니다.
그러한 작업이 Data Conversion 2.0에서 해결 되었다면, 소스와 수신자 모두의 규칙에서 변경이 이루어져야합니다.
이 비디오 자습서는 BSP와 관련이 있습니다. 버전 2.3.2 (2.3.2.43 이전의 모든 어셈블리).
이전 버전의 BSP를 사용하는 경우 0은 변경된 인터페이스 및 고급 기능에 대해 "수정"합니다. 이렇게하려면 비디오에서 직접 예제를 반복하십시오.
비디오 1 :
Data Conversion 3.0에서 일반 구성간에 교환 규칙로드
이 학습에서는 일반적인 구성간에 교환 규칙을 변경할 때 준비 단계를 수행합니다.
- CD에 교환 형식의 구조로드 (
- 전환 만들기
- 일반 구성에서 규칙 파일 언로드
- 교환 관리자 모듈 언로드
비디오 2 :
CD 3.0의 교환 규칙 마무리
이 레슨에서는 데이터를로드 할 때 오브젝트의 세부 사항을 보충하는 방법을 보여줍니다.
소스 구성에서 개체를로드 할 때“Downloaded from BP 3.0”주석을 설정하면 문제가 해결됩니다.
문제를 해결하려면 객체 변환 규칙 변경"수신 된 데이터를 기록하기 전에"이벤트가 발생하는 경우.
개발 된 규칙은 나중에 사용하기 위해 외부 처리로 저장됩니다.
비디오 3 :
일반적인 구성 간 범용 교환 설정
이 학습서에서는 일반적인 교환간에 새로운 교환을 설정하는 방법을 보여줍니다.
소스 구성에서 설정 한 다음 대상 구성으로로드됩니다.
또한이 비디오에서 우리는 방법을 보여줍니다 구성 변경없이 새로운 교환 규칙을 업로드하십시오.
비디오 4 :
교환 규칙을 사용하여 기초 잔액 이전
이 단원에서는 초기 잔류 물을 전달하는 일반적인 기능을 보여줍니다.
추신
예, txt / dbf / ole 등을 통한 교환 존재할 권리가 있습니다. 웹 서버에 도킹하거나 기성품 형식에서 외부 응용 프로그램을 전송하는 등의 특별한 경우가 있습니다.
그러나 표준 교환의 경우- 표준 방법이 더 빠르고 간단합니다.
기성품 범용 솔루션이있을 때 누군가 자전거를 발명하면- 이마에 글을 쓰는 것과 같습니다.“저는 도구를 가지고 있지 않습니다. 공부하고 싶지 않습니다. 돈을 위해 목발을 만들 것입니다.” .
P.P.S.
Data Conversion 3.0이 복잡하지 않다는 것을 보여 드리고자합니다.
특이한-예. 모든 것이 즉시 명확하지는 않습니다. 매우 혼합 된 점이 있습니다-예.
그러나 기성품 지침과 비디오의 도움으로 말 그대로 1-2 주 안에 마스터 할 수 있습니다.
이 기사를 내 메일로 보내기
1C 데이터베이스간에 교환을 도입해야하는 주된 이유는 다음과 같이 지점이 존재하고 회계 유형이 분리 되었기 때문입니다. 회사는 종종 여러 정보 데이터베이스에서 작업합니다. 교환 1C 8.3을 설정하면 두 개의 프로그램에 동일한 문서와 디렉토리를 입력 할뿐만 아니라 다양한 지사 및 부서에 필요한 시스템 오브젝트를 빠르게 공급할 수 있으므로 이중 작업이 필요 없습니다.
지점 간 교환이 필요한 경우 RIB (Distributed Information Base)가 사용됩니다. 이것은 동일한 구성을 교환하기위한 메커니즘입니다. 트리는 상호 연결된 노드 쌍 아래에서 가장 중요한 루트 노드입니다. 이 시스템의 모든 노드에서 변경할 수 있으며 다른 관련 노드로 전송됩니다. 또한 데이터뿐만 아니라 루트 노드에서 하위 노드로 구성 변경 사항을 배포합니다.
예를 들어, 거래 유형에서 운영 유형을 유지 관리하고 회계 유형으로 조정하는 등 회계 유형을 분리해야하는 경우 유연한 데이터 동기화 설정을 갖춘 범용 교환 메커니즘을 사용할 수 있습니다.
최신 1C 개발 중 하나는 EnterpriseData 데이터 교환 형식입니다. 사용하기 쉽고 1C 데이터베이스와 타사 프로그램간에 회사 내에서 교환 할 수 있습니다.
기업에서의 데이터 교환 구현은 순차적 절차의 형태로 표현 될 수 있습니다.
우선, 교환이 어느베이스 사이인지 결정해야합니다. 양자 또는 일방적 교환 일 것인가? 일방적 인 경우, 어떤 데이터베이스가 정보를 전송하고 어떤 데이터베이스 만 수신 할 것인지; 복잡한 지점 네트워크 인 경우 데이터베이스 구성 체계를 처방해야합니다.
그런 다음 적절한 형식을 선택하십시오 : RIB, universal format; 교환 규칙에 따라 교환; 교환 규칙없이 교환하십시오.
다음 단계는 교환을위한 운송 선택입니다. 다양한 기술을 이용할 수 있으며, 디렉토리 (로컬 또는 네트워크), FTP 리소스, COM 연결, 웹 서비스 및 이메일과 같은 주요 기술을 강조합니다.
네 번째 단계는 데이터, 문서, 디렉토리 및 필요한 경우 전송할 개별 세부 사항에 대한 세부 사항 정의입니다.
결론적으로 교환 빈도 일정이 정해져 있습니다.
1C 8.3 교환을위한 각 구성 옵션에는 신중한 준비가 필요합니다. 그 구현은 각 사용자의 힘을 넘어서는 것입니다. 여기에서 많은 뉘앙스를 고려하고 교환의 원리를 이해해야합니다. 데이터베이스에 개선 사항이 있거나 추가 항목이 많은 경우 튜닝에 특히주의를 기울여야합니다. 요구 사항, 플랫폼 버전이 다르거 나 구식 버전의 구성이 사용되는 경우, 엔터프라이즈 규모가 크며 많은 데이터베이스로 구성된 자동화 시스템을 사용합니다. 실수는 여기에서 허용되지 않습니다. 치명적인 결과를 초래할 수 있습니다. 1C에서 독립적 인 교환 구현은 일반적인 구성간에 간단한 정보 전송을 구성해야하는 경우에만 권장됩니다.
당신의 능력을 의심한다면, 저축하는 것이 아니라 교환 1C 8.3을 설정하는 어려운 과제를 해결하는 데 도움을 줄 유능한 전문가에게 의뢰하는 것이 좋습니다.
전문가의 도움없이 1C 교환을 구성하기로 결정한 경우 먼저 데이터베이스 복사본을 테스트하고 작업중인 데이터베이스에서 작업을 시작하기 전에 오류가 발생할 경우 원래 상태로 돌아갈 수 있도록 구성을 업로드하는 것이 좋습니다.
아래는 Trade Management 11 (UT)과 Enterprise Accounting 3.0 (BP)의 일반적인 구성간에 일방적으로 1C 8.3 교환을 설정하는 자세한 예입니다. 예를 들어 도매 및 소매업에 종사하는 많은 회사와 관련이 있습니다. 관리 기록은 관리 부서에서 유지 관리되고 BP에서 규제되며 사용자의 작업을 용이하게하기 위해 교환이 필요합니다.
이러한 알고리즘은 1C 8.3 플랫폼의 다른 일반적인 구성에도 적합합니다.
우선, 우리는 정보 수신자를위한 준비 작업, 즉 BP. 엔터프라이즈 모드에서 프로그램을 실행하십시오. 데이터 동기화 상수를 설정해야합니다 (섹션 관리 → 데이터 동기화).
접두사 필드에주의하십시오. 여기서 오브젝트가 처음 작성된 프로그램을 이후에 디렉토리 코드 또는 문서 번호의 값으로 구별 할 값을 지정해야합니다. 이 예에서 일반적인 약어 인 BP 및 UT가 적합합니다. 1C 8.3 교환 설정이 많은 수의 데이터베이스와 동일한 구성간에 복잡한 교환을 위해 수행되는 경우 각 데이터베이스마다 고유 한 지정이 필요합니다.
BP는 정보의 수신자 일 뿐이므로 UT 구성을 진행합니다.
여기서 BP뿐만 아니라 동기화를 포함하고 접두사를 지정해야합니다. 이 정보는 NSI 및 관리 → 데이터 동기화 설정에서 사용할 수 있습니다.
설정 방법을 선택하십시오 설정을 수동으로 지정하십시오. 더욱이.
두 프로그램이 모두 동일한 로컬 네트워크에있는 경우 직접 연결 옵션을 설정하고이 네트워크의 정보 보안 카탈로그에 대한 연결 매개 변수를 지정하고 사용자에 대한 인증 정보를 작성합니다 (BP 데이터베이스). 더욱이.
시스템은 지정된 데이터의 정확성을 확인하고 긍정적 인 결과 인 경우 1C 8.3 교환 설정 창을 표시합니다.
데이터 업로드 규칙 변경 링크를 클릭하여 교환 설정을 구성하십시오. 우리는 문서에 사용 된 문서 만 언로드하고 창고와 문서를 분리하지 않고 조직 및 계약 작업 옵션을 NSI에 대해 설명합니다. 현재 연도의 3 월 1 일에 교환이 시작됩니다.
입력 한 규칙이 기록되고 닫힙니다.
예는 정보의 단방향 전송에 관한 것이므로 다음 설정 창에서 다른 프로그램에서 데이터를 수신하려면 Do not send 값을 설정하십시오. 쓰고 닫으십시오. 더욱이.
이제 입력 한 매개 변수를 확인하고 올바른 경우 다음을 클릭하고, 그렇지 않으면 이전을 클릭하여 이전 단계로 돌아가십시오.
그런 다음 동기화를 수행하도록 제공됩니다. Finish를 클릭하십시오.
필요한 경우 두 구성의 동일한 객체의 상관 관계를 수행하면 데이터 일치를위한 창이 열립니다. 비교를 수행하고 다음을 클릭하십시오.
객체를 전송할 때 문제 상황이 발생할 수 있으므로 데이터를 동기화 할 때 경고 링크를 클릭하여 결과를 볼 수 있습니다.
동기화가 완료되면이 프로세스가 성공적으로 완료되었음을 알리는 창이 표시됩니다.
여기에서 Configure 명령 또는 동기화 스크립트에서 자동 교환 일정을 구성 할 수 있습니다.
데이터 공유를 설정해야합니까?
15 년 동안 우리는 1C를 프로그램하고 무료 비디오 교육을 제공합니다
우리는 1C 교환을 설정 한 경험이 풍부한 프로그래머 팀을 보유하고 있습니다.
1C 구성 사이에서
다른 프로그램과 1C 교환을 설정합니다.
왜 우리를 선택 했습니까?
주말과 공휴일에도 긴급한 작업에 대해 최대 2 시간의 반응 시간.
5 년에서 20 년 사이에 "1C"에 경험이있는 40 명 이상의 풀 타임 프로그래머.
수행 된 작업에 대한 비디오 지침을 제공합니다.
클라이언트에게 편리한 메신저를 통한 실시간 커뮤니케이션.
99 %의 작업이 원격 액세스 (TeamViewer 또는 RDP)를 통해 수행되므로 작업을 완료하는 데 필요한 시간이 크게 줄어 듭니다.
2006 년부터 1C의 공식 파트너.
소기업에서 대기업에 이르기까지 성공적인 자동화 경험.
고객의 99 %가 감사장으로 입증 된 결과에 만족합니다.
인쇄 (Ctrl + P)
범용 형식을 통한 교환
표준 서브 시스템 라이브러리의 "데이터 교환"서브 시스템에는 서로 다른 정보베이스 간의 정보 교환을위한 4 가지 옵션 (기술)이 있습니다.
- 분산 정보베이스 (RIB);
- 범용 형식을 통한 데이터 교환;
- 교환 규칙에 따른 데이터 교환 (교환 규칙은 "데이터 변환"구성, 버전 2.1을 사용하여 작성 됨);
- 교환 규칙이없는 데이터 교환.
이 기사에서는 다음을 통해 데이터를 교환하는 기술에 대해 설명합니다. 범용 EnterpriseData 형식. 이 기술은 버전 2.3.1.62부터“표준 서브 시스템 라이브러리”에서 사용할 수 있습니다. 2016 년 초에 출시되었습니다. 현재, 최신 버전의 BSP 2.3 ( "1C : Enterprise 8.3"플랫폼과 함께 사용하기 위해 호환 모드가 비활성화 된 버전 8.3.8.1652보다 낮지 않음)은 2.3.6.17 릴리스입니다.
무화과. BSP 2.3 최신 릴리스 1 개
응용 프로그램 솔루션 1C를 제공하기위한 파일 중에는 "라이브러리 버전"이라는 텍스트 파일이 있는데, 여기에는 응용 프로그램이 개발 된 BSP 버전을 기반으로 작성됩니다 (예 : 적용된 솔루션 UT 11.3.3.231에 기초하여 BSP 2.3.5.65가 작성 됨).
"1C : Enterprise 8.3"플랫폼과 함께 사용하기 위해서는 버전보다 낮지 않습니다. 8.3.10.2168 호환되지 않는 호환 모드 출시 버전 BSP 2.4.
EnterpriseData 형식 설명
EnterpriseData 형식은 무엇입니까?
이는 정보베이스의 오브젝트 (상대방, 송장 등)를 설명하거나이 오브젝트가 삭제되었다는 사실을보고 할 수있는 형식입니다. EnterpriseData 형식으로 파일을 수신 한 구성이 그에 따라 반응 할 것으로 예상됩니다. 새 오브젝트를 작성하고 파일에서 삭제 된 것으로 표시된 오브젝트를 삭제합니다. UT, RT, UNF, BP 구성간에 정보를 교환하기위한 것입니다. 또한이 형식은 다른 정보 시스템과 정보를 교환하는 데 사용될 수 있습니다. 이는 자체 소프트웨어의 특성이나 교환에 참여하는 정보 기반의 구조에 의존하지 않으며 사용에 대한 명시 적 제한을 포함하지 않습니다.
EnterpriseData 형식 버전
형식 데이터는 그림 3과 같이 일반 데이터베이스 구성 분기의 XDTO 패키지에 저장됩니다. 2
그림 2 XDTO-EnterpriseData 데이터 형식 패키지 그림. 그림 2는 여러 XDTO 패키지가 있음을 보여줍니다. 이들은 다른 버전의 형식입니다. 형식 버전 번호는 X.Y.Z로 구성되며, 여기서 X.Y는 버전이고 Z는 부 버전입니다. 오류 수정 및 기타 변경 사항이있는 경우 부 버전이 증가합니다. 이전 버전의 형식을 기반으로하는 데이터 변환 논리의 기능이 유지됩니다 (형식을 통한 현재 데이터 전송 알고리즘의 이전 버전과의 호환성 유지). 변환 논리에 대한 새로운 형식 기능 지원은 자발적입니다. 이러한 변경의 예로는 오류 수정, 형식 개체의 속성 변경, 속성 추가, 데이터 변환에 필수적이지 않은 사용이 있습니다. 다른 경우에는 형식을 변경할 때 메이저 버전이 증가합니다. X-전역 재구성의 경우 Y-다른 경우.
형식은 XML 파일 형식으로 오브젝트 (문서 또는 참조 요소)의 표현을 설명합니다. 버전 1.0.1에는 다양한 필드 (금융, 제조, 조달 및 판매, 창고 운영)의 94 개 오브젝트에 대한 설명이 포함되어 있습니다. 일반적으로 유형 이름은 잘 이해되어 있으며 추가 설명이 필요하지 않습니다 (예 : "완료된 작품의 문서"또는 "참조. 상대방"). 보시다시피 문서 유형에 대한 설명은 접두사 "Document."로 시작하고 디렉토리 항목은 접두사 "Directory"로 시작합니다. 형식에 대한 자세한 정보는 찾을 수 있습니다
그러나 최신 버전 1.3이 가장 일반적으로 사용되는 버전 1.0입니다. 버전 간에는 큰 차이가 없습니다. 체재 EnterpriseDataExchange_1_0_1_1
웹 서비스를 통해 교환 할 때 사용됩니다.
노트 EnterpriseData 데이터 형식 패키지와 함께 패키지가 사용됩니다. 교환 메시지 전환 규칙을 만들 때 이 패키지는 타입 객체를 포함합니다 추가 정보,이는 모든 유형의 값을 가질 수 있으며 구성 개체간에 변환 규칙을 만들 때 사용됩니다. 데이터 형식이 아닙니다. 정확히 감사합니다 추가 정보, XDTO 패키지에서 형식 데이터를 변경하지 않고 교환 규칙을 적용하고 구성 할 수 있습니다.
무화과. 3ExchangeMessage XDTO 패키지 구조 EnterpriseData 형식으로 데이터를 교환하는 방법은 무엇입니까?
EnterpriseData 형식의 데이터 교환과 구성 교환은 파일 교환입니다. 외부 응용 프로그램으로부터 수신 된 파일에 대한 응답으로 구성이 파일을 처리하고 응답 파일을 작성합니다. 파일 공유가 발생할 수 있습니다 :
- 전용 파일 디렉토리를 통해
- fTP 디렉토리를 통해
- 정보베이스 측면에 배포 된 웹 서비스를 통해 데이터 파일은 매개 변수로 웹 메소드에 전달됩니다.
노트. 타사 응용 프로그램과 Infobase 측면의 구성간에 양방향 데이터 교환을하려면 여러 설정을 수행해야합니다. 타사 응용 프로그램을 Infobase에 등록해야하며 교환 채널을 파일 또는 FTP 디렉토리를 통해 정의해야합니다. 그러나 간단한 통합의 경우 타사 응용 프로그램에서 정보베이스로 정보를 전송하기에 충분하고 정보를 다른 응용 프로그램으로 다시 전송할 필요가없는 경우 (예 : 판매 정보를 1C로 전송하는 온라인 상점 통합 : 회계) 외부 설정이 필요없는 웹 서비스를 통한 간단한 작업 버전.
동기화 중에 구성 교환 계획을 사용하여 교환하는 경우, 전송 된 정보의 양을 최소화하기 위해 마지막 동기화 이후 발생한 변경에 대한 정보 만 전송됩니다. 첫 번째 동기화시 구성은 EnterpriseData 형식의 모든 개체를 XML 파일로 업로드합니다 (모든 개체가 타사 응용 프로그램에 "새로 포함되어 있기 때문에").
타사 응용 프로그램 이후의 다음 단계는 XML 파일의 정보를 처리하여 다음 동기화 세션 동안 섹션에 배치해야한다는 것입니다.
수신 메시지를 수신 한 후 구성은 이전 메시지에서 전송 된 모든 변경 사항이 성공적으로 동기화 된 것으로 표시합니다. 다음 동기화 세션 동안 오브젝트의 동기화되지 않은 변경 사항 (새 항목 작성, 기존 항목 변경 및 삭제) 만 외부 애플리케이션으로 전송됩니다.
데이터가 외부 응용 프로그램에서 구성으로 전송되면 그림이 반전됩니다. 신청서는 섹션을 작성해야합니다
파일을 처리 한 후 구성은 수신 측 메시지와 구성 측에서 동기화 할 새 데이터를 포함하는 XML 파일을 생성합니다 (마지막 동기화 세션 이후에있을 경우).
1C : Enterprise 플랫폼의 엔터프라이즈 플랫폼에서 애플리케이션 솔루션과의 데이터 교환에 대한 자세한 내용을 볼 수 있습니다.
"범용 형식을 통한 교환 관리자"의 일반 모듈.
정보베이스에서 교환 형식으로 데이터를 업로드하기위한 규칙과 교환 형식에서 정보베이스로 데이터를로드하기위한 규칙을 완전히 설명하는 절차 및 기능은 공통 형식 (일반 형식을 통한 교환 관리자 모듈)으로 개발됩니다.
무화과. 4 범용 형식을 통한 교환 관리자 모듈의 구조 모듈은 구성된 교환 규칙에 따라 "데이터 변환"구성, 개정판 3.0을 사용하여 자동으로 작성되거나 구성 프로그램에서 수동으로 작성됩니다.
이 모듈은 여러 개의 큰 섹션으로 구성되며 각 섹션에는 고유 한 절차 및 기능 그룹이 포함됩니다.
- 의견. 모듈의 첫 번째 줄에는 변환 이름이 포함 된 주석이 포함됩니다. 이 행은 "데이터 변환"프로그램, 버전 3.0에서 명령을 사용할 때 모듈을 식별하는 데 필요합니다 (예 : // 2017/06/01 19:51:50에서 UP2.2.3 변환
- 변환 절차. 여기에는 데이터 동기화의 다른 단계에서 수행되는 사전 정의 된 절차가 포함되어 있습니다. 변환 전, 변환 후, 지연된 채우기 전.
- 데이터 처리 규칙 (AML). 데이터 처리 규칙을 설명하는 절차와 기능을 포함합니다.
- FFP (개체 변환 규칙). 여기에는 객체 변환 규칙과 이러한 객체의 속성 변환 규칙을 설명하는 절차와 기능이 포함되어 있습니다.
- 사전 정의 된 데이터 변환 규칙 (PKPD). 사전 정의 된 데이터를 변환하기위한 규칙을 채우는 절차가 포함되어 있습니다.
- 알고리즘. 다른 규칙 (AML 또는 PKO)에서 호출 된 임의 알고리즘이 포함되어 있습니다.
- 매개 변수. 변환 매개 변수를 채우는 논리가 포함되어 있습니다.
- 범용. 규칙과 알고리즘에 널리 사용되는 절차와 기능을 포함합니다.
관리자 모듈의 여러 유형의 절차에 사용되는 절차 및 기능의 매개 변수가 아래에 설명되어 있습니다.
구성 요소 교환. 유형-구조. 교환 세션의 일부로 초기화 된 매개 변수 및 교환 규칙을 포함합니다.
교환 방향. 유형-문자열. 보내기 또는 받기
데이터 IB. 유형-디렉토리 객체 또는 문서 객체.
전환 이벤트 절차
변환 프로세스 중에 호출되는 세 가지 사전 정의 된 프로 시저가 있습니다.
- 전환 전. 데이터 동기화를 수행하기 전에 호출됩니다. 일반적으로이 절차에서는 다양한 변환 매개 변수의 초기화, 기본값 채우기 등의 논리가 배치됩니다. 부품 교환.
- 변환 후. 데이터 동기화가 완료된 후 지연된 채우기가 완료되기 전에 호출됩니다. 매개 변수 : 부품 교환.
- 연기 된 충전 전. 채우기를 보류하기 전에 호출됩니다. 여기서 지연 될 오브젝트 테이블을 정렬하거나 조정하는 논리를 찾을 수 있습니다. 매개 변수 : 부품 교환.
AML 절차
데이터 처리 규칙을 작성하십시오. 데이터 처리 규칙을 채우는 논리가있는 내보내기 절차 특정 개체에 대한 처리 규칙을 규칙 테이블에 추가하는 다른 프로 시저에 대한 호출을 포함합니다 (아래 절차 참조). 더하다) 매개 변수 : 방향 교환, 데이터 처리 규칙
AddPOD_<ИмяПОД>. 특정 개체에 대한 규칙에 따라 테이블을 채우는 일련의 절차. 이러한 절차의 수는 "데이터 변환"프로그램 버전 3.0에서이 변환에 제공되는 AML 수에 해당합니다. 매개 변수 : 데이터 처리 규칙 (교환 테이블의 일부로 초기화 된 값 테이블).
아래에_<ИмяПОД>_ 처리 중. 절차는 핸들러 텍스트를 포함합니다 처리 할 때 특정 AML. 처리기는 개체 수준에서 변환 논리를 구현하도록 설계되었습니다. 예를 들어, 객체의 내용에 따라 특정 FFP를 특정 객체에 할당합니다. 매개 변수 :
- IB 데이터또는 XDTO 데이터 (교환 방향에 따라) :
- 보낼 때 객체 ( 참조 객체,문서 객체);
- 수령시 XDTO 객체에 대한 설명이 포함 된 구조
- FFP 사용. 유형 - 구조. 키에는 이름이 FFP 인 문자열과 유형 값이 포함됩니다. 부울 (진실 -FFP가 사용됩니다. 그릇된 -FFP는 사용하지 않습니다).
- 부품 교환.
아래에_<ИмяПОД>_ 샘플 데이터. 함수는 핸들러 텍스트를 포함합니다. 언로드 할 때. 핸들러는 언로드 할 오브젝트를 선택하기위한 임의 알고리즘을 구현하도록 설계되었습니다. 반환 값 : 언로드 할 객체의 배열. 배열에는 정보베이스의 객체에 대한 참조와 언로드 할 데이터가있는 구조가 모두 포함될 수 있습니다. 매개 변수 : 부품 교환.
FFP 절차
개체 변환 규칙을 작성하십시오. 객체 변환 규칙을 채우는 논리가있는 내보내기 절차입니다. 특정 객체를 규칙 테이블로 변환하기위한 규칙을 추가하는 다른 절차에 대한 호출을 포함합니다 (아래 절차 참조). PCO 추가) 매개 변수 : 방향 교환, 변환 규칙 (교환 테이블의 일부로 초기화 된 값 테이블).
AddPCO_<ИмяПКО>. FFP 테이블을 특정 개체에 대한 규칙으로 채우는 일련의 절차. 이러한 절차의 수는 "데이터 변환"프로그램 개정판 3.0에서이 변환에 제공된 FFP 수에 해당합니다. 매개 변수 : 변환 규칙 (교환 테이블의 일부로 초기화 된 값 테이블).
PKO_<ИмяПКО>_ 데이터 전송시. 절차는 핸들러 텍스트를 포함합니다 보낼 때 특정 FFP의 경우. 핸들러는 데이터를 업로드 할 때 사용됩니다. Infobase 개체에 포함 된 데이터를 XDTO 개체 설명으로 변환하는 논리를 구현하도록 설계되었습니다. 매개 변수 :
- IB 데이터. 유형 - 참조 객체, 문서 객체. 정보베이스의 처리 된 오브젝트.
- XDTO 데이터. 유형 - 구조. XDTO 객체 데이터에 액세스하도록 설계되었습니다.
- 부품 교환.
- 언로드 스택. 유형 - 정렬. 중첩을 고려하여 내 보낸 객체에 대한 링크를 포함합니다.
PKO_<ИмяПКО>_ 데이터 변환 XDTO. 절차는 핸들러 텍스트를 포함합니다 데이터를 변환 할 때 XDTO 특정 FFP의 경우. 핸들러는 데이터를로드 할 때 사용됩니다. 임의의 XDTO 데이터 변환 로직을 구현하도록 설계되었습니다. 매개 변수 :
- XDTO 데이터. 유형 - 구조. 사전 처리 된 XDTO 객체 속성으로 액세스를 단순화합니다.
- 수신 데이터. 유형 - 참조 객체, 문서 객체. XDTO 데이터를 변환하여 형성된 정보베이스 개체입니다. 정보베이스에 기록되지 않았습니다.
- 부품 교환.
PKO_<ИмяПКО>_ 수신 된 데이터 기록 전. 절차는 핸들러 텍스트를 포함합니다 수신 한 데이터를 기록하기 전에 특정 FFP의 경우. 핸들러는 데이터를로드 할 때 사용됩니다. 정보베이스에 오브젝트를 쓰기 전에 수행해야하는 추가 논리를 구현하도록 설계되었습니다. 예를 들어, 기존 IB 데이터에 변경 사항을로드해야하는지 또는 새 데이터로로드해야하는지 여부입니다. 매개 변수 :
- 수신 데이터. 유형 - 참조 객체, 문서 객체. XDTO 데이터를 변환하여 생성 된 데이터 항목입니다.
이 데이터가 정보베이스에 새로운 데이터 인 경우 기록됩니다 (매개 변수 IB 데이터 가치를 포함 찾으시는 주소가 없습니다).
그렇지 않으면 수신 데이터 스스로를 교체 IB 데이터 (에서 모든 속성 수신 데이터 이월 IB 데이터).
수신 된 데이터로 IS 데이터를 표준으로 교체 할 필요가없는 경우 전송 논리를 등록한 다음 매개 변수를 설정해야합니다. 수신 데이터 값 찾으시는 주소가 없습니다:
- IB 데이터. 유형 - 참조 객체, 문서 객체. 수신 된 데이터에 대응하는 인포베이스 데이터 요소. 일치하는 데이터가 없으면 포함 찾으시는 주소가 없습니다.
- 속성 변환. 유형 - 가치 표. 교환 세션의 일부로 초기화 된 현재 개체의 속성을 변환하기위한 규칙을 포함합니다.
- 부품 교환.
PKPD 절차
사전 정의 된 데이터에 대한 변환 규칙 작성. 사전 정의 된 데이터 변환 규칙을 채우는 논리가있는 내보내기 절차. 매개 변수 : 방향 교환, 변환 규칙 (교환 테이블의 일부로 초기화 된 값 테이블).
알고리즘
"데이터 변환"버전 3.0 프로그램에서는 AML 및 PKPD 핸들러에서 호출되는 임의의 알고리즘을 작성할 수 있습니다. 알고리즘의 이름, 매개 변수 및 내용은 규칙을 개발하는 동안 결정됩니다.
매개 변수
변환 옵션을 작성하십시오. 구조가 변환 매개 변수로 채워지는 내보내기 절차. 매개 변수 : 변환 옵션 (유형 - 구조).
범용 절차 및 기능
관리자 모듈의 절차를 따르십시오. 매개 변수 : 이름 절차 (선), 매개 변수 (구조). 이름과 매개 변수가 입력에서 수신되는 모듈의 비 수출 프로 시저를 호출하도록 설계된 내보내기 프로 시저입니다. 메소드를 사용하지 않고 회선에서 프로 시저 또는 함수를 호출 할 수 있습니다 운영.
관리자 모듈의 기능을 실행하십시오. 매개 변수 : 이름 절차 (선), 매개 변수 (구조). 기능, 과제는 유사하다 RunManagerModule 절차. 차이점은 함수를 호출하고 값을 반환한다는 것입니다.
“1C”는 XML을 기반으로하는 새로운 EnterpriseData 비즈니스 데이터 교환 형식의 첫 번째 버전을 도입했으며, 작성자가 생각한 것처럼 회사 자체에서 만든 응용 프로그램 솔루션과 개별 구성 요소의 상호 작용을 통합 할뿐만 아니라 범용 정보 통합 메커니즘으로도 사용됩니다. 물론 1C : Enterprise를 포함한 모든 소프트웨어 플랫폼의 모든 비즈니스 응용 프로그램
이 회사는 오랫동안 독립 개발자의 소프트웨어와 응용 프로그램의 정보 상호 작용을위한 개방형 표준을 만들고 사용하는 방법을 연습 해 왔지만 지금까지는 개별적인 전문 주제 영역에만 관심이있었습니다. 이것은 전자 상거래 문제를 해결하기 위해 거의 15 년 전에 CommerceML 형식을 작성했으며 1C 응용 프로그램과 외부 뱅킹 시스템과 통신하기위한 Client-Bank 및 DirectBank입니다. 반면 EnterpriseData는 재무, 생산, 조달 및 판매, 창고 운영 등 기업의 모든 영역을 포괄 할 수있는 보편적 인 메커니즘입니다. 첫 번째 버전의 형식에는 다양한 비즈니스 영역의 94 가지 유형의 문서에 대한 설명이 포함됩니다. "1C"는 새 문서를 추가하고 기존 문서를 자세히 설명 할 계획입니다.
“1C”의 대표자들이 설명 하듯이 EnterpriseData의 출현은 회사의 응용 프로그램을 다른 개발자의 소프트웨어에 통합 할뿐만 아니라 1C : Enterprise 소프트웨어 제품군 내에서 정보 통신의 통합 메커니즘을 만들 필요가 있다고 설명합니다. 최근까지 이러한 문제를 해결하기 위해 다양한 솔루션이 종종 사용되었으며, 종종 각 특정 사례에 대해 생성되었습니다. “1C”제품의 EnterpriseData 로의 번역은 이미 시작되었으며 최신 버전의 주요 응용 프로그램 (“1C : ERP Enterprise Management 2.0”,“1C : Accounting 8”3.0,“1C : Accounting 8 CORP”3.0,“1C : Retail)에서 사용됩니다. "2.0,"1C : 무역 관리 "11). 동시에, 이미 테스트 된 특수 알고리즘이 범용 도구보다 더 효율적으로 작동하기 때문에 이미 사용 된 표준 (CommerceML, 은행과 협력)을 EnterpriseData로 대체 할 수 없습니다.
“1C”는 새로운 형식이“1C : Enterprise”플랫폼에서 응용 프로그램을 작성하는 독립적 인 개발자들 사이에서 널리 사용될 것으로 믿고 표준 하위 시스템 라이브러리 (“1C : Enterprise”용 SDK와 같은)의 일부로 기성품 소프트웨어 구성 요소를 제공합니다.
EnterpriseData 표준을 사용하는 경우 응용 프로그램 간의 데이터는 적절한 XML 체계를 사용하여 XML 파일 형식으로 전송되는 반면 웹 서비스, 디렉토리를 통한 파일 교환, FTP 및 전자 메일과 같은 다양한 메커니즘을 사용하여 물리적 정보를 전송할 수 있습니다. 중요한 점은 상호 작용 알고리즘이 수신자가 자신에게 전송 된 데이터를 수신하고 처리하는 사실을 확인할 수 있다는 가능성을 의미합니다. XML 파일 자체는 압축 형식 (ZIP)으로 실제로 배신되므로 종종 정보 트래픽을 줄일 수 있습니다.
"1C"는 EnterpriseData 형식의 추가 개발과 점점 더 많은 응용 프로그램에서의 지원을 약속합니다. 이 표준은 회사 자체에 의해 관리되며, 제작자는 독립적 인 산업 표준으로 전환 할 계획이 없습니다.
27.08.2015
1C Company는 새로운 XML 기반 EnterpriseData 비즈니스 데이터 교환 형식의 첫 번째 버전을 출시했습니다. 이 형식을 사용하면 개발자는 누구이며 의도 한 활동 영역에 관계없이 회사에서 사용하는 이기종 비즈니스 자동화 시스템간에 데이터 교환을 효과적으로 구성 할 수 있습니다.
이 표준의 릴리스는 타사 소프트웨어와의 통합을 위해 자사 제품의 개방성을 높이는 1C 회사의 다음 단계가되었습니다. 회사 "1C"는 항상이 영역에 특별한주의를 기울였습니다. 제품 "1C"는 상업 정보를 XML 형식으로 교환하는 데 사용되는 CommerceML 형식을 지원합니다. 1C : 엔터프라이즈 시스템과 정보 뱅킹 시스템의 주요 개발자와 함께 1C가 개발 한 원격 뱅킹 서비스 시스템 (클라이언트-뱅크) 모듈간에 재무 문서를 교환하는 형식에는 특별한 언급이 필요합니다. 오늘날 수백 개의 러시아 은행 (러시아 Sberbank, VTB 24, Gazprombank, 러시아 농업 은행 포함)에서 지원하는이 형식은 실제로 업계 표준이되었습니다. 이 방향은 DirectBank 직접 교환 기술에서 더욱 발전하여 1C : Enterprise의 은행과 더욱 편리하고 안전하게 상호 작용할 수 있습니다.
또한 "1C"가 지원하는 이전 형식은 주로 특정 활동 영역 (전자 상거래, 은행 시스템과의 통합)에서만 서로 다른 조직 간의 데이터 교환 문제를 해결하는 데 도움이되었습니다. 이제 새로운 EnterpriseData 형식은 재무, 생산, 조달 및 판매, 창고 운영 등 기업의 모든 영역을 포괄합니다. 이 형식의 첫 번째 버전에는 다양한 비즈니스 영역의 94 가지 유형의 문서에 대한 설명이 포함되어 있습니다. 형식은 확장 가능하며 1C는 새 문서를 추가하고 기존 문서를 자세히 설명합니다.
타사 응용 프로그램을 "1C"프로그램과 통합 할 때이 형식을 사용하는 것이 좋습니다. 또한이 형식은 다른 정보 시스템 간의 정보 교환에 사용될 수 있습니다. 소프트웨어의 기능이나 교환에 참여하는 정보베이스의 구조에 의존하지 않으며 사용에 대한 명백한 제한을 포함하지 않습니다.
현재 Enterprise Data 형식은 1C 회사 자체의 소프트웨어 제품간에 데이터를 동기화하는 데 이미 사용되며 제품에서 지원됩니다.
- 1C : ERP 엔터프라이즈 관리 2.0
- 1C : 회계 8, 판 3.0
- 1C : 회계 8 CORPORATION, 개정 3.0
- 1C : 리테일, 에디션 2.0
- 1C : 무역 관리, 판 11
1C 제품 통합의 가장 일반적인 사례 중 하나는 1C : 회계 탠덤-1C : 거래 관리입니다. 이 두 회사의 인기있는 제품은 73 가지 유형의 문서를 EnterpriseData 형식으로 교환하여 데이터를 최신 상태로 유지하고 서로 동기화 할 수 있습니다. 1C 회사의 개발자는 EnterpriseData 형식을 채택하면 코드를 통합하여 1C : Enterprise 시스템을위한 애플리케이션 솔루션을 개발하는 품질과 속도를 향상시킬 수있었습니다.
1C 제품과 통합 된 타사 제품의 경우이 형식을 사용하면 시스템 구현 및 지원에 대한 개발 량과 인건비가 모두 줄어 듭니다. 이전에는 각 제품이 자체 데이터 교환 형식을 지원할 때 데이터 교환 시스템에 N 개의 제품이있는 경우 새로운 제품을 추가하려면 2 * N 변경이 필요했습니다 (그림 1 참조). 기존의 각 제품마다 새 제품에서 데이터 가져 오기를 지원하기 위해 변경이 필요했고 새 제품은 기존 제품에서 데이터 가져 오기를 지원해야했습니다. 단일 형식을 도입 한 후 새 제품을 추가하려면 EnterpriseData 형식으로 가져 오기 및 내보내기 만하면되며 기존 제품은 변경되지 않습니다.
그림 1 단일 형식이없는 데이터 교환
그림 2 EnterpriseData 형식을 통한 통신
이 형식은 상향식 호환성을 지원합니다. 1C 소프트웨어와 EnterpriseData 형식의 데이터를 교환하는 모든 타사 프로그램은 새 형식의 형식이 출시 될 때 계속 작동합니다.
- 1C에서 자체 개발 통합 : 일반적인 1C 솔루션과 함께 엔터프라이즈 플랫폼 (맞춤형 및 순환 형)
- 1C의 솔루션과 다른 (1C 이외의) 시스템 통합 : 엔터프라이즈 플랫폼
- 1C 이외의 다른 시스템과의 상호 작용을 구성합니다.
