해충 구제
거래상대방의 상태가 좋지 않습니다. 종이 없는 전자문서 흐름으로의 전환: 경험, 문제점, 전망

거래상대방의 상태가 좋지 않습니다. 종이 없는 전자문서 흐름으로의 전환: 경험, 문제점, 전망

버전 1.3.8은 버전 1.3 "1C: 전자 문서 라이브러리 8"의 개발 버전으로, 1C:Enterprise 플랫폼 버전 8.3.10.2252 이상에서 개발된 애플리케이션 솔루션에서 전자 문서 교환을 보장하도록 설계되었습니다.

새로운 기능 및 변경 사항

거래 제안 검색 양식에 1C : 비즈니스 네트워크 서비스에 연결하지 않고 검색하는 기능이 추가되었으며 이름으로 공급 업체를 검색하는 기능이 추가되었습니다.
게시된 거래 제안에 대한 보고서를 추가했습니다.
1C:Business Network 서비스에 거래 제안을 게시하는 작업장이 추가되었습니다.
하위 시스템 "1C: 표준 하위 시스템 라이브러리" 버전 2.4.2, "1C: 인터넷 사용자 지원 라이브러리" 버전 2.2.2를 사용하여 조정되었습니다.

버전 1.3.7에서 버전 1.3.8로 전환

정의된 유형이 추가되었습니다. 상대방BED, 정의된 유형 상대방삭제됨 업데이트할 때 반드시새로운 데이터 유형을 설정하고, 그렇지 않으면 삭제하위 시스템 개체의 거래 상대방에 대한 데이터 교환상대방(문서 전자문서패키지, 정보 레지스터 BED 거래상대방 현황).

모듈 변경 사항:

추가된 기능 게시된 제품에 대한 요청 텍스트거래 제안을 게시하고 게시된 상품에 대한 보고서를 생성하기 위한 데이터 소스를 얻습니다. 제품 목록을 수신할 때 FillOfferPackage 메소드에 대한 함수 호출을 구현해야 합니다.

모듈의 변경 사항 거래 제안

절차가 추가됨 업데이트장식조건출판물장식 양식 요소를 게시 상태로 업데이트합니다. 양식의 호출에 상태 요소에 대한 게시 설정을 추가해야 합니다.

역할이 추가됨 보고서거래제안보고서에 액세스하는 데 필요합니다. 공개된 거래 제안.

버전 1.3.7

버전 1.3.7은 버전 1.3 "1C: 전자 문서 라이브러리 8"의 개발 버전으로, 1C:Enterprise 플랫폼 버전 8.3.10 이상에서 개발된 애플리케이션 솔루션에서 전자 문서 교환을 보장하도록 설계되었습니다.

구성 속성 값:

호환성 모드는 "사용하지 않음"으로 설정해야 합니다.
양식 사용 모드는 "사용 안 함"으로 설정할 수 있습니다.
인터페이스 호환성 모드는 "버전 8.2", "버전 8.2. 택시 허용" 또는 "택시. 버전 8.2 허용" 값을 가질 수 있습니다.

새로운 기능 및 변경 사항

Sberbank에서 결제 문서의 상태를 가져오는 기능이 추가되었습니다.
1C:DirectBank 서비스에 연결할 때 Sberbank에 대한 설정 자동 수신을 구현했습니다.
문맥 광고 1C:DirectBank를 표시하는 기능이 추가되었습니다.
1CFresh 클라우드 서비스의 1C: Business Network 서비스와 작동하도록 조정되었습니다.
1C: 비즈니스 네트워크 서비스 참가자를 위한 1C: 거래 제안 서비스에 거래 제안을 게시, 검색 및 주문하는 기능이 추가되었습니다.
적응은 하위 시스템 "1C: 표준 하위 시스템 라이브러리" 버전 2.4.1, "1C: 인터넷 사용자 지원 라이브러리" 버전 2.1.9, "1C: 서비스 기술 라이브러리" 버전 1.0.12를 사용하여 수행되었습니다.

하위 시스템 "상대방과의 교환"

모듈 변경 사항:

문서 날짜, DocBase날짜

하위 시스템 "은행과의 교환"

모듈의 변경 사항 무시할 수 있는 파일 작업:

절차에 설정을 정의할 때코드를 추가해야 합니다:

ElectronicInteraction.WhenDefiningSettings(설정);

절차에 파일 저장 디렉터리를 정의하는 경우코드를 추가해야 합니다:

전자적 상호작용. FileStorage 디렉터리를 정의할 때(FileOwnerType, DirectoryNames);

MessageExchangeWithBanksAttachedFiles 및 EDAttachedFiles 디렉터리가 교환 계획 UpdateInformationBase에 추가되었습니다.
MessageExchangeWithBanksAttachedFiles 및 EDAttachedFiles 디렉터리가 정의된 유형 SignedObject에 추가되었습니다.

클라이언트뱅크) 일반 양식에서 요소 그룹을 이동합니다.

양식 이벤트 핸들러에서 서버에서 생성될 때

&서버에서

…

절차 종료

양식 이벤트 핸들러에서 경고 처리 중

&클라이언트에서

…
// 전자적 상호작용, 은행과의 교환

Elements.GroupAdvertisingDirectBankHorizontally, Elements.TextDirectBankHorizontally);
// 전자거래 종료, 은행과의 교환
절차 종료

요소의 경우 TextDirectBank가로이벤트 핸들러 추가 처리NavigationLinks

&클라이언트에서

절차 종료

공통 모듈 절차로 전자상호작용 지불 순서애플리케이션 솔루션에서.

하위 시스템 "사이트와의 교환"

모듈의 변경 사항 사이트 교환 재정의 가능:

절차가 추가됨 DetailsFormNode 추가, 사이트와의 Exchange 계획 노드 양식에 세부 정보를 추가하는 데 사용됩니다. 교환 노드 양식은 애플리케이션 솔루션과 관련된 세부사항이 있다고 가정하지 않으며 세부사항은 프로그래밍 방식으로 추가됩니다.
절차가 추가됨 입력 필드WhenChangedOnServer, 교환 계획 노드 양식의 입력 필드가 변경되면 Add NodeFormDetails 프로시저에 추가되는 이벤트를 북쪽에서 처리하는 데 사용됩니다.
절차가 추가됨 CheckboxFieldWhenChangedOnServer는 Add NodeFormDetails 프로시저에 추가된 교환 계획 노드 양식의 플래그 필드가 변경될 때 서버에서 이벤트를 처리하는 데 사용됩니다.
절차가 추가됨 ServerFormCreateSite에서 생성할 때, CreateSite 처리 양식에 세부정보를 추가하는 데 사용됩니다.

모듈의 변경 사항 ExchangeSiteClient재정의 가능:

제거된 절차 GroupTableU 카탈로그 유형 정의, 제품 카탈로그 테이블의 그룹 열 값 유형은 교환 설정에 따라 결정됩니다.
절차가 추가됨 입력 필드 변경 시, 교환 계획 노드 양식의 입력 필드가 변경되면 SiteExchangeOverridden.AddNodeFormDetails 프로시저에 추가되는 이벤트를 처리하기 위해 호출됩니다.
절차가 추가됨 확인란FieldOnChange는 SiteExchangeOverridden.AddNodeFormDetails 프로시저에 추가된 교환 계획 노드 양식의 플래그 필드가 변경될 때 이벤트를 처리하기 위해 호출됩니다.
절차가 추가됨 TableFormBeforeFinish편집는 SiteExchangeOverridden.AddNodeFormDetails 프로시저에 추가된 교환 계획 노드 양식의 표 부분에 있는 필드의 BeforeFinishEdit 이벤트를 처리하기 위해 호출됩니다.

하위 시스템 "비즈니스 네트워크"

분할 모드, 공통 모듈에서 일상적인 작업을 실행하기 위한 새로운 방법이 추가되었습니다. 전자상호작용, 절차 템플릿 목록 수신 시, . 일반 모듈 JobQueueOverridable에서 동일한 이름의 메서드를 참조하세요.
라이브러리를 포함할 때 분할 모드로 작업하려면 일반 모듈의 메서드에 대한 호출을 추가해야 합니다. JobQueue재정의 가능:
- 절차에서 템플릿 목록 수신 시:

// 전자적 상호작용
ElectronicInteraction.OnReceiveingListTemplates(TaskTemplates);

절차에서 AliasesHandler를 정의할 때:

// 전자적 상호작용
ElectronicInteraction.WhenDefiningHandlerAliases(MatchNamesAliases);
// 전자 상호작용 종료

모듈의 변경 사항 비즈니스네트워크재정의 가능:
- 프로시저 이름이 다음으로 변경되었습니다. 사용자 연락처 정보 얻기.
- 절차가 기능으로 변경됨 세부사항에 따라 상대방 생성에서는 Account 매개변수가 제거되었습니다.

하위 시스템 "거래 제안"

새로운 하위 시스템 "거래 제안"이 추가되었습니다. 포함하려면 다음이 필요합니다.

공통 모듈에서 재정의된 메서드 개발 TradeOffers클라이언트 재정의 가능, 거래 제안 재정의 가능.
정의된 유형으로 데이터 유형 지정 세부 정보 값 유형 1СBusinessNetwork, 명명법 BED의 종류, 추가 세부정보BED, 거래 제안.

자세한 내용은 삽입 문서를 참조하세요.

버전 1.3.6

버전 1.3.6은 버전 1.3 "1C: 전자 문서 라이브러리 8"의 개발 버전으로, 1C:Enterprise 플랫폼 버전 8.3.8 이상에서 개발된 애플리케이션 솔루션에서 전자 문서 교환을 보장하도록 설계되었습니다. 이 경우 구성 속성 "호환성 모드"를 "버전 8.3.8"로 설정해야 합니다.

이 구성은 버전 2.3.4.112 이상의 "1C: 표준 하위 시스템 라이브러리" 구성 및 버전 2.1.9.4 이상의 "1C: 인터넷 사용자 지원 라이브러리 8" 구성과 함께 사용하기 위한 것입니다.

새로운 기능 및 변경 사항

기본 송장 문서의 형식은 2016년 3월 24일자 연방세청 명령에 따라 지원됩니다(별도의 기본 문서, 송장 전송 측면에서) No. ММВ-7-15/155@ "승인 시" 송장을 포함한 상품 배송(작업 수행), 재산권 양도(서비스 제공에 관한 문서)에 대한 송장 형식 및 문서 제시 형식을 전자 형식으로 제공합니다."
조정 송장을 포함하여 가치 변화에 대한 기본 문서 형식은 2016년 4월 13일자 연방세청 명령에 따라 지원됩니다(별도의 기본 문서, 조정 송장 전송 측면에서) N ММВ -7-15/189@ " 조정 송장 형식과 배송된 상품 비용(수행된 작업, 제공된 서비스) 변경에 대한 문서 제출 형식이 승인되면 조정 송장을 포함한 재산권이 이전됩니다. 전자 양식."
새로운 전자 문서가 추가되었습니다: 상품 양도, 작업 결과 양도, 새로운 형태의 문서 시각적 표현.
수신자로부터 수신 알림을 받을 필요가 없는 단방향 교환 메커니즘이 추가되었습니다.
수신 전자 문서의 압축 풀기를 제어하는 기능(자동 또는 수동), 전자 문서 수신 시 특정 유형의 문서 생성을 구성하는 기능이 추가되었습니다.
전자 문서를 여러 정보 기반 회계 문서에 연결하는 기능이 추가되었습니다.
전자문서의 수신, 발신 구분이 구현되었습니다.
서비스와의 통합이 구현되었습니다. 1C-UMI프로그램에서 웹사이트를 만들고, 온라인 상점과의 교환을 설정할 수 있습니다. 우미.
1CFresh 클라우드 서비스에서 1C-EDO 서비스 작업을 위해 조정되었습니다.

버전 1.3.5에서 버전 1.3.6으로 전환

하위 시스템 "상대방과의 교환"

일반 모듈 상대방과 교환재정의 가능

UPD SCHFDOP 메소드를 추가했습니다.
추가된 방법 UPD 구매자 정보에 대한 데이터를 입력하세요. Federal Tax Service. 이 방법은 UPD(구매자 정보) 기능 SCHFDOP 유형의 전자 문서에 대한 데이터를 준비합니다.
정보보안 객체에 UPD 방식(판매자 정보) 기능 SCHFDOP를 추가했습니다.
추가된 방법 판매자 연방세 서비스의 추가 정보에 대한 데이터를 입력하세요.. STD(판매자 정보) DOP 기능과 같은 전자 문서에 대한 데이터를 준비하는 방법입니다.
추가된 방법 찾기UPDT 문서 만들기정보전송. 전자문서 UPD(판매자 정보) 기능 DOP의 데이터를 IS 객체에 저장하는 방식입니다.
추가된 방법 SCHFIS판매자 정보에 대한 데이터를 입력하세요. Federal Tax Service. 이 방법은 UTD(판매자 정보) SSF 기능 유형의 전자 문서에 대한 데이터를 준비합니다.
추가된 방법 찾기CreateUPDS송장송장. 전자문서 UPD(판매자정보) SSF 기능에서 발생한 데이터를 정보보안객체에 저장하는 방식이다.
방법이 추가되었습니다. 이 방법은 UCD 유형(판매자 정보) 기능 KSCHFDIS의 전자 문서에 대한 데이터를 준비합니다.
추가된 방법 UKID 구매자 정보에 대한 데이터 입력 Federal Tax Service. 이 방법은 UKD(구매자 정보) 기능 KSCHFDIS 유형의 전자 문서에 대한 데이터를 준비합니다.
방법이 추가되었습니다. 전자문서 UCD(판매자 정보) 기능 KSCHFDIS의 데이터를 정보보안 객체에 저장하는 방식입니다.
추가된 방법 판매자 연방세 서비스에 대한 허위 정보에 대한 데이터를 입력하세요.. UCD형(판매자 정보) DIS 기능의 전자문서에 대한 데이터를 준비하는 방법이다.
추가된 방법 찾기CreateUKDDocumentAboutChangeValue. 전자문서 UCD(판매자 정보) 기능 DIS의 데이터를 IS 객체에 저장하는 방식입니다.
추가된 방법 KSCHFIS판매자 정보에 대한 데이터를 입력하세요. Federal Tax Service. 이 방법은 UCD 유형(판매자 정보) 기능 KSCHF의 전자 문서에 대한 데이터를 준비합니다.
추가된 방법 찾기CreateUKDS계정송장. 전자문서 UCD(판매자 정보) 기능 KSCHF의 데이터를 정보보안 객체로 저장하는 방식입니다.
추가된 방법 정보 보안 문서와 함께 발신 유형의 ED 준수. 이 방법은 나가는 전자 문서와 정보 보안 문서 간의 대응을 형성합니다.
추가된 방법 찾기만들기문서전송작업결과. 이 방법은 "상품 양도" 형식으로 받은 위탁 메모 문서를 작성하는 데 사용됩니다.
추가된 방법 찾기작성문서물품이전. 이 방법은 "작업 결과 전송" 형식으로 받은 서비스 제공 증명서 문서를 작성하는 데 사용됩니다.
추가된 방법 설치상태교환완료. 문서 흐름 상태가 다음으로 변경되면 메서드가 호출됩니다. 교환완료, 수정완료 교환완료.
전자문서 생성시 UPD, UKD, 물품이전, 작업결과 이전, 상세내역 문서 날짜, DocBase날짜작성이 필요합니다.

상대방과의 교환 처리

"Torg-12Seller" 레이아웃에서:

"IdStateContract" 필드를 추가했습니다.
표 형식의 "운송 송장" 부분이 추가되었습니다.
"운송 송장 날짜", "운송 송장 번호" 필드가 제거되었습니다.
"상품을 양도한 사람에 대한 정보" 필드를 추가했습니다.

레이아웃에서 권리 양도법:

표 형식 부분 "기본"이 추가되었습니다.
"DocumentBaseName", "DocumentBaseNumber", "DocumentBaseDate", "DocumentBaseAdditionalInformation" 필드가 제거되었습니다.
"CurrencyName" 필드를 추가했습니다.
'클레임' 필드를 추가했습니다.
"실행 날짜" 필드를 추가했습니다.
거래 참가자 속성에서 "팩스" 필드가 "이메일" 필드로 대체되었습니다.
거래 참가자 속성에서 "국가 코드" 필드가 "국가 코드" 필드로 대체되었습니다.
거래 참가자 속성에서 "AddressText" 필드가 "AddressText" 필드로 대체되었습니다.

정의된 유형 업데이트 상대방:

버전 1.3.5에서 업그레이드할 때 정의된 유형의 Counterparty를 업데이트해야 합니다. 그렇지 않으면 BED 개체의 Counterparty 디렉터리에 대한 참조가 업데이트될 때 개체에 대한 참조가 손실되는 문자열 유형으로 대체됩니다. 회복.

업데이트 절차:

정의된 유형 Account의 이름을 AccountBED로 바꿉니다.
BED 1.3.5 지원에서 구성을 제거합니다.
BED 1.3.5 구성과 비교/병합을 실행하고 지원하도록 구성을 설정하는 데 동의합니다.
모든 개체를 선택 취소하고 정의된 계정 유형만 남겨두고 병합을 수행합니다.
구성 업데이트를 시작하고 BED 파일 1.3.6을 선택합니다.
정의된 유형 AccountBED 및 Account에 대한 확인란을 선택합니다. 업데이트에 필요한 기타 데이터베이스 개체를 지정합니다.
업데이트를 수행합니다.

서브시스템 "은행과의 환전"

절차에 은행 명세서 받기공통 모듈 은행클라이언트와 교환선택적 매개변수를 추가했습니다. OpenForm설명기간유형으로 부울. 명세서를 받은 양식에 명세서 요청 기간을 수동으로 변경할 수 있는 기능이 없으면 True로 설정해야 합니다.

하위 시스템 "사이트와의 교환"

교환 노드가 변경됨 사이트 교환, 양식, 개체 모듈:

항목 유형별로 선택하여 항목을 업로드하는 기능이 추가되었습니다(이전에는 항목 그룹에서만 사용할 수 있었습니다).

참고서 추가됨 웹사이트:

1C에서 사이트의 사용자 부분 및 사이트의 관리 영역으로의 사이트 전환을 구성하는 기능이 추가되었습니다.
사이트를 기반으로 ExchangeSite 교환 노드를 생성할 수 있습니다.

처리 추가 웹사이트 만들기:

1C-UMI 도메인에 사이트를 생성하는 기능이 추가되었으며, 사이트가 자동으로 생성되고(사이트 요소) 1C의 데이터로 채워집니다. ExchangeSite 교환 노드가 자동으로 생성되고 사이트와의 첫 번째 전체 교환이 수행됩니다.

일반 모듈 사이트 교환 재정의 가능:

아이템 종류 선택 기능이 추가되었으며, 임의 참고도서 선택 기능이 제거되었습니다.

일반 모듈 ExchangeSite이벤트:

아이템 종류를 선택하는 기능이 추가되었습니다.
사용자 정의 디렉토리를 선택하는 기능이 제거되었습니다.

기타 변경사항

하위 시스템 설정 관세관리도서관 서비스 모델에서 서비스 기술

공통 모듈로 관세재정의 가능 When Forming a List of Services () 메소드에서 InternetUser Support 메소드를 호출한 후 코드를 추가해야 합니다. When Forming a List of Services (Service Providers):

// 전자적 상호작용
전자적 상호작용. 서비스(서비스 제공자) 목록을 작성할 때
// 전자 상호작용 종료

버전 1.3.5

버전 1.3.5는 "1C: 전자 문서 라이브러리 8"의 버전 1.3을 개발한 것으로, 1C:Enterprise 플랫폼 버전 8.3.8 이상에서 개발된 애플리케이션 솔루션에서 전자 문서 교환을 보장하도록 설계되었습니다.

구성 속성 값:

호환성 모드는 "사용하지 않음"으로 설정해야 합니다.
양식 사용 모드는 "사용 안 함"으로 설정할 수 있습니다.
인터페이스 호환성 모드는 "버전 8.2", "버전 8.2. 택시 허용" 또는 "택시. 버전 8.2 허용" 값을 가질 수 있습니다.

새로운 기능 및 변경 사항

라이브러리 기능은 호환 모드가 비활성화된 8.3.8 플랫폼에서 작업하는 특정 기능에 맞게 조정되었습니다.
"표준 하위 시스템 라이브러리"의 하위 시스템이 버전 2.3.3.45로 업데이트되었습니다.
라이브러리에는 하위 시스템 "인터넷 사용자 지원 라이브러리" 버전 2.1.8.3이 포함되어 있습니다.

버전 1.3.4에서 버전 1.3.5로 전환

변경이 필요하지 않습니다.

버전 1.3.4

버전 1.3.4는 "1C: 전자 문서 라이브러리 8"의 버전 1.3을 개발한 것으로, 1C:Enterprise 플랫폼 버전 8.3.6 이상에서 개발된 애플리케이션 솔루션에서 전자 문서 교환을 보장하도록 설계되었습니다. 이 경우 구성 속성 "호환성 모드"를 "사용 안 함"으로 설정해야 합니다. 모달리티 사용 모드는 "사용하지 않음"으로 설정할 수 있으며, 인터페이스 호환 모드는 "버전 8.2", "버전 8.2. 택시 허용" 또는 "택시. 허용 버전 8.2"로 설정할 수 있습니다.

새로운 기능 및 변경 사항

EDI 이벤트에 대한 알림 시스템이 구현되었습니다(새 전자 문서, 새 초대, 인증서 만료 등). 이제 EDF 설정 프로필에서 이메일 알림을 구성하고 팝업 메시지를 사용하여 1C 프로그램에서 직접 이벤트에 대한 알림을 표시할 수 있습니다.
2016년 3월 24일자 연방세청 명령에 따라 송장(UPD 형식)을 포함한 기본 문서 형식이 지원됩니다. ММВ-7-15/155@ “송장 형식 승인 시 송장을 포함하여 상품 배송(작업 수행), 재산권 이전(서비스 제공에 관한 문서)에 관한 문서를 전자 형식으로 제출하는 형식";
2016년 4월 13일 N ММВ-7-15/189@ 연방세청 명령에 따라 조정 송장을 포함하는 가치 변경에 관한 문서 형식이 지원되었습니다."(UKD 형식) "조정 송장 형식 및 선적 상품 비용 변경(수행된 작업, 제공된 서비스)에 대한 제시 형식 문서의 승인 시 조정 송장을 포함한 전자 형식의 재산권 이전"
DirectBank 기술을 사용하여 은행과 교환하여 외부 구성 요소 사용을 지원했습니다.

버전 1.3.2, 1.3.3에서 버전 1.3.4로 전환

신청솔루션 문서목록 양식 변경사항

문서 목록 양식에 플러그인 프로시저를 추가해야 합니다. CounterpartiesClient.Waiting ProcessorEDW와의 교환:

&클라이언트에서

절차 종료

하위 시스템을 업데이트할 때 문서 목록 형식의 이벤트 핸들러에 필요합니다. 서버에서 생성될 때, 열 때, 경고 처리 중

&서버에서
서버에서 생성 시 절차
…
ParameterWhenCreatedOnServer = ExchangeWithCounterparties.ParametersWhenCreatedOnServer_ListForm();
ParameterWhenCreatedOnServer.Form = ThisObject;
ParameterWhenCreatedOnServer.LocationofCommands = Elements.EDO 명령;
ExchangewithCounterparties.WhenCreatedOnServer_ListForm(실패, 표준 처리, 매개변수WhenCreatedOnServer);
절차 종료

&클라이언트에서
열기 절차(실패)
…
// "상대방과의 교환" 하위 시스템.
// "상대방 교환" 하위 시스템이 종료됩니다.
절차 종료

&클라이언트에서
프로시저 프로세스 알림(이벤트 이름, 매개변수, 소스)
…
// "상대방과의 교환" 하위 시스템.
경고 매개변수EDO = CounterpartiesClient.AlertParametersEDO_ListForm()과의 교환;
EDO 알림 매개변수.Form = ThisObject;
EDO 알림 매개변수.DynamicListName = "목록";
ExchangewithCounterpartiesClient.ProcessingAlert_ListForm(이벤트 이름, 매개변수, 소스, EDI AlertParameters);
// "상대방 교환" 하위 시스템이 종료됩니다.
절차 종료

응용솔루션 문서양식 변경사항

문서 양식에서 플러그인 프로시저를 추가해야 합니다. Connectable_WaitingHandlerEDO, 여기서 메소드 호출을 수행해야 합니다.

CounterpartiesClient.Waiting ProcessorEDW와의 교환:

&클라이언트에서
프로시저 Connectable_EDOWaitingHandler()
ExchangeCounterpartiesClient.EDOWaitingHandler(ThisObject);
절차 종료

문서 양식에서는 "EDO 상태" 양식 속성을 제거하고 대신 "장식" 양식 요소를 추가해야 합니다. 애플리케이션 솔루션의 요구 사항에 따라 장식은 "그룹" 양식 요소에 종속될 수 있습니다. 그룹 가시성은 메소드 내부에 설정됩니다. 상대방과의 교환 서버에서 생성된 경우 F.O의 상태에 따라 "상대방과의 교환을 이용하세요."

하위 시스템을 업데이트할 때 문서 형식 이벤트 핸들러에 필요합니다. 서버에서 생성될 때, 열 때, AfterRecordingOnServer, 경고 처리 중"상대방 교환" 하위 시스템의 배치 방법.

예를 들어:

&서버에서

…
// "상대방과의 교환" 하위 시스템.
생성 시 EDO 매개변수 = 상대방과의 교환 Server_DocumentForm()에서 생성 시 매개변수;
생성 시 EDO 매개변수.Form = ThisObject;
생성 시 EDO 매개변수.DocumentLink = Object.Link;
생성 시 EDO 매개변수.DecorationStateEDO = Elements.DecorationStateEDO;
생성 시 EDO 매개변수.EDO 상태 그룹 = Elements.EDO 상태 그룹;
상대방과의 교환.생성시 Server_DocumentForm(거부, 표준처리, EDO 매개변수생성시);
// "상대방 교환" 하위 시스템이 종료됩니다.
절차 종료

&클라이언트에서
열기 절차(실패)
…
// 하위 시스템 "상대방과의 교환"
ExchangeWithCounterpartiesClient.OnOpening(ThisObject);
// "상대방과의 교환" 하위 시스템 종료
절차 종료

&서버에서
절차 AfterRecordOnServer(CurrentObject, RecordParameters)
…
// "상대방과의 교환" 하위 시스템.
ParameterAfterRecord = ExchangeWithCounterparties.ParametersAfterRecordOnServer();
ParameterAfterRecord.Form = ThisObject;
ParameterAfterRecord.DocumentLink = Object.Link;
ParameterAfterRecording.DecorationStateEDO = Elements.DecorationStateEDO;
ParameterAfterRecord.GroupEDOStatus = Elements.GroupEDOState;
ExchangewithCounterparties.AfterRecordOnServer(CurrentObject, RecordParameters,AfterRecordParameters);
// "상대방 교환" 하위 시스템이 종료됩니다.
절차 종료

&클라이언트에서
프로시저 프로세스 알림(이벤트 이름, 매개변수, 소스)
…
// "상대방과의 교환" 하위 시스템.
경고 매개변수 = ExchangewithCounterpartiesClient.AlertParametersEDO_DocumentForm();
AlertParameters.Form = ThisObject;
AlertParameters.DocumentLink = 개체.링크;
경고 매개변수.DecorationEDO 상태 = Elements.DecorationEDO 상태;
경고 매개변수.EDO 상태 그룹 = 요소.EDO 상태 그룹;
ExchangeWithCounterpartiesClient.ProcessingAlert_DocumentForm(EventName, 매개변수, 소스, AlertParameters);
// "상대방 교환" 하위 시스템이 종료됩니다.
절차 종료

ExchangeCounterparties 모듈의 변경 사항

절차가 추가됨 Server_ListForm에 생성될 때, 문서 목록 양식의 "When CreatedOnServer" 이벤트 핸들러에서 호출됩니다. 메소드의 세 번째 매개변수로 메소드에 의해 초기화되는 구조체가 전달됩니다. 매개변수WhenCreatingOnServer_ListForm.
절차가 추가됨 Server_FormDocument를 생성할 때, 문서 양식의 "When CreatedOnServer" 이벤트 핸들러에서 호출됩니다. 메소드의 세 번째 매개변수로 메소드에 의해 초기화되는 구조체가 전달됩니다. 매개변수WhenCreatingOnServer_DocumentForm.
절차가 추가됨 AfterRecordingOnServer, 문서 양식의 "AfterRecordOnServer" 이벤트 핸들러에서 호출됩니다. 메소드의 세 번째 매개변수로 메소드에 의해 초기화되는 구조체가 전달됩니다. 매개변수AfterRecordingOnServer.

모듈의 변경 사항 상대방클라이언트와의 교환.

절차가 추가됨 열 때, 문서 목록 양식 및 문서 양식의 "On opening" 이벤트 핸들러에서 호출됩니다.
절차가 추가됨 처리 중 경고_목록 양식, 문서 목록 양식의 "알림 처리" 이벤트 핸들러에서 호출됩니다. 메소드의 네 번째 매개변수로 메소드에 의해 초기화되는 구조체가 전달됩니다. 경고 매개변수EDO_ListForm.
절차가 추가됨 ProcessAlert_FormDocument, 문서 양식의 "알림 처리" 이벤트 핸들러에서 호출됩니다. 메소드의 네 번째 매개변수로 메소드에 의해 초기화되는 구조체가 전달됩니다. 알림 매개변수EDO_DocumentForm.
모듈의 변경 사항 상대방과의 교환재정의 가능:
추가된 방법 작업 실행자의 데이터 전송을 입력합니다..
예:

// 판매자에게 상품 양도 유형의 전자 문서에 대한 데이터를 준비합니다.
// 옵션:
// LinkToObject - 전자 문서를 생성하는 데 필요한 ED에 대한 링크,

절차 데이터 전송 작업 실행자 채우기(객체 링크, ED 구조, 데이터 트리) 내보내기
연방 세금 서비스의 Act 501 집행자에 대한 데이터를 입력합니다(객체 링크, ED 구조, 데이터 트리).
절차 종료

방법 개체 편집 기능 확인절차가 되었습니다.
추가된 방법 판매자 연방세 서비스의 UPD 정보에 대한 데이터를 입력하세요.. 이 방법은 다음 유형의 전자 문서에 대한 데이터를 준비합니다. UPD(판매자정보) 기능 슈프도프.
추가된 방법 찾기CreateUniversalTransferDocument. 이 방법은 전자 문서의 데이터를 저장합니다. UPD(판매자정보) 기능 SCHFDOPv IS 객체.
추가된 방법 UKDI 판매자 정보 연방세 서비스에 대한 데이터를 입력하세요.. 이 방법은 다음 유형의 전자 문서에 대한 데이터를 준비합니다. UKD(판매자정보) 기능 KSCHFDIS.
추가된 방법 찾기CreateUniversalAdjustmentDocument. 이 방법은 전자 문서의 데이터를 저장합니다. UKD(판매자정보) 기능 KSCHFDIS정보 보안 개체에.

"은행과의 교환" 하위 시스템의 변경 사항

ExchangeWithBanksRedefinable 모듈의 변경 사항

절차 ED 조건이 변경되는 경우추가되었습니다. 전자문서 흐름 상태가 변경되면 호출됩니다.

서비스 모드 작업에 대한 변경 사항

서비스 모드에서 작동하기 위한 대상 구성이 필요한 경우:

공통 모듈 SupplyDataOverridden의 GetProvidedDataHandlers 프로시저에서 다음 코드를 추가합니다.

ElectronicInteraction.RegisterDeliveredDataHandlers(처리기);

일반 속성 데이터 영역 기본 데이터에 루틴 작업인 은행과 외부 모듈 교환 업데이트를 추가합니다.

기타 변경사항

정의되는 유형에 상수를 추가해야 합니다. UseExchangeWithBanks;
제거된 기능 은행과의 교환, 은행과의 직접 교환 권장.

버전 1.3.3

버전 1.3.3은 "1C: 전자 문서 라이브러리" 제품의 버전 1.3을 개발한 것입니다. 1C:Enterprise 플랫폼 8.3 버전 8.3.6 이상에서 작동하도록 설계된 구성을 개발하도록 설계되었습니다.

구성 속성 값:

호환성 모드는 "사용하지 않음"으로 설정해야 합니다.
양식 사용 모드는 "사용 안 함"으로 설정할 수 있습니다.
인터페이스 호환성 모드는 "버전 8.2", "버전 8.2. 택시 허용" 또는 "택시. 버전 8.2 허용" 값을 가질 수 있습니다.

새로운 기능 및 변경 사항

2015년 11월 30일자 명령 No. ММВ-7-10/551@ "전자 형식으로 무역 거래 중 상품 양도에 관한 문서 제출 형식 승인" 및 2015년 11월 30일자 명령 No. ММВ-7-10/552@ "작업 결과 전송에 관한 문서(서비스 제공에 관한 문서)를 전자 형식으로 제출하는 형식 승인 시" 새로운 형식의 전자 문서가 지원됩니다.

"상대방과의 교환" 하위 시스템 변경

모듈에서는 상대방과의 교환재정의 가능변경:

// 위탁 메모 유형의 전자 문서에 대한 데이터를 준비합니다.
// 옵션:
// LinkOnED - 전자문서 생성에 필요한 ED에 대한 링크,
// StructureED - 전자 문서 생성을 위한 구조, 데이터 구조입니다.
// 데이터 트리 - 전자 문서를 작성하기 위한 데이터 트리인 값 트리입니다.
절차 상품 판매자의 데이터 전송 입력(개체 링크, ED 구조, 데이터 트리) 내보내기
협상 12 연방세 서비스 판매자에 대한 데이터 입력(객체 링크, ED 구조, 데이터 트리)
절차 종료

전자 문서 작업 시 조직(RLS)별로 기록 수준에서 액세스를 제한하기 위한 템플릿인 BED를 사용하는 구성에 추가해야 합니다(임베딩 문서 참조).

버전 1.3.2

버전 1.3.2는 "1C: 전자 문서 라이브러리" 제품의 버전 1.3을 개발한 것입니다. 1C:Enterprise 플랫폼 8.3 버전 8.3.6 이상에서 작동하도록 설계된 구성을 개발하도록 설계되었습니다.

구성 속성 값:

호환성 모드는 "사용하지 않음"으로 설정해야 합니다.
양식 사용 모드는 "사용 안 함"으로 설정할 수 있습니다.
인터페이스 호환성 모드는 "버전 8.2", "버전 8.2. 택시 허용" 또는 "택시. 버전 8.2 허용" 값을 가질 수 있습니다.

새로운 기능 및 변경 사항

전자문서 열람을 위해 전자문서 2개 제목(TORG12, 법령, 조정문서)을 하나의 형태로 표시하도록 구현하였습니다. 제목의 모든 정보는 단일 양식으로 수집됩니다. 이와 별도로 두 번째 제목의 형식은 "전자 문서" 형식에서 볼 수 있습니다.
1C 프로그램의 "EDF 설정"에서 전자 형식으로 표준 "EDA 계약"을 체결하는 기능이 구현되었습니다. "템플릿을 사용하여 계약 생성" 명령을 사용하면 임의의 전자 문서가 자동으로 생성되며, 해당 첨부 파일은 계약 파일이 됩니다. 서명 후 문서를 즉시 상대방에게 보낼 수 있습니다.
임의의 전자문서를 첨부파일과 통합 교환합니다. 이제 전자 문서를 사용하여 첨부된 파일에 신속하게 서명하고 상대방에게 보낼 수 있습니다.
급여 프로젝트에서 은행과 전자 문서를 교환하는 기능이 지원됩니다.
조직을 DirectBank에 연결하는 도우미를 추가했습니다.
DirectBank를 지원하는 은행 목록은 인터넷을 통해 업데이트되었습니다.
Sberbank의 다양한 유형의 토큰(전자 키)으로 지원되는 작업: "일반", "터치", "화면 포함".
"표준 하위 시스템 라이브러리"(BSS)의 하위 시스템이 버전 2.3.2.27로 업데이트되었습니다.

버전 1.2.7, 1.3.1에서 버전 1.3.2.19로 전환

모듈에 패딩 없이 프로시저를 추가해야 합니다.

절차 CheckUsingTestMode. 은행과의 교환 테스트를 위한 추가 기능을 활성화하는 기능이 포함됩니다. 아직 응용 솔루션에 사용할 계획은 없습니다.

모듈에서는 일반 작업 재정의 가능변경:

일상적인 작업에 대한 설정을 결정하는 절차(설정) 내보내기
전자 상호 작용. 루틴 작업의 설정을 정의할 때(설정);
절차 종료

모듈에서는 전자서명클라이언트 재정의 가능변경:

추가 인증서 확인(매개변수) 내보내기 절차
ExchangeWithBanksClient.AtAdditionalCertificateVerification(매개변수);
절차 종료

모듈로 전자서명재정의 가능변경:

양식 생성 시 절차인증서 확인(인증서, 추가 확인, 추가 확인 매개변수, 표준 확인) 내보내기
ExchangeWithBanks.WhenCreatingFormVerificationCertificate(
인증서, 추가 확인, 추가 확인 매개변수, 표준 확인);
절차 종료

다음과 같은 공유되지 않은 개체가 추가되었습니다.

;

끊임없는 은행과의 일반 파일 교환.

정의된 유형에 저장 공간기능 옵션상수 추가 UseExchangeWithBanks.

구성이 서비스 모델 모드에서 작동하도록 의도된 경우 구독 처리기를 서비스 모델에서 작동하도록 BED를 작성하는 동안 공유되지 않은 개체 제어 이벤트로 변경해야 합니다.작성하는 동안 공유되지 않은 개체 제어.

버전 1.3.1

버전 1.3.1은 "1C: 전자 문서 라이브러리" 제품의 버전 1.2를 개발한 것입니다. 1C:Enterprise 플랫폼 8.3 버전 8.3.6 이상에서 작동하도록 설계된 구성을 개발하도록 설계되었습니다.

구성 속성 값:

호환성 모드는 "사용하지 않음"으로 설정해야 합니다.
양식 사용 모드는 "사용 안 함"으로 설정할 수 있습니다.
인터페이스 호환성 모드는 "버전 8.2", "버전 8.2. 택시 허용" 또는 "택시. 버전 8.2 허용" 값을 가질 수 있습니다.

새로운 기능 및 변경 사항

1C: 비즈니스 네트워크 참가자를 위해 EDI 서비스를 통해 전자 서명 없이 전자 문서를 교환하는 기능이 구현되었습니다.
은행과의 자율적인 교환 하위 시스템이 구현되었습니다.
"표준 하위 시스템 라이브러리"(BSS)의 하위 시스템이 버전 2.3.1.71로 업데이트되었습니다.

버전 1.2.6, 1.2.7에서 버전 1.3.1로 전환

아키텍처 변경

접두사가 "전자 문서"인 모든 모듈은 접두사가 붙은 모듈로 이름이 변경되었습니다. "상대방과의 교환".모듈 방법 범용새 모듈로 이동 전자상호작용. 기준 치수 ED 정보 베이스 업데이트다음으로 이름이 변경됨 데이터베이스 업데이트.

전자문서 V 전자상호작용:

성이니셜개인

모듈에서 이동된 메소드 목록 전자문서 V 은행과 교환:

은행과 직접 교환 가능
GetDataBankStatementsTreeValues
GetDataBankStatementsTextFormat
구문 분석 트리ExtractsBank

모듈에서 다음으로 이동된 메소드 목록 전자 상호 작용클라이언트 재정의 가능:

문서 확인 수행

모듈에서 이동된 메소드 목록 전자문서클라이언트재정의 가능 V ExchangeWithBanksClient재정의 가능:

구문 분석파일추출물

모듈에서 다음으로 이동된 메소드 목록 전자상호작용클라이언트서버:

GetMessageText(MessageText로 이름이 변경됨)
예액션

모듈에서 이동된 메소드 목록 전자문서클라이언트서버 V 은행과교환클라이언트서버:

DetailsSettings EDSBanks에 채워짐(Filled out Filled DetailsSettingsExchange로 이름 변경됨)
HeaderSettingsEDOSBank의 이름이 HeaderSettingsExchangeWithBank로 변경되었습니다.
GetStatusTextED

모듈에서 다음으로 이동된 메소드 목록 전자 상호작용재정의 가능:

ChangeFormElementProperties
현재디렉터리임시파일
일치하는 기능 옵션 가져오기
일치하는 디렉터리 가져오기
객체 MD의 이름 및 세부 사항에 대한 대응을 얻습니다.
세부사항 및 표시 코드의 대응
객체의 주요 세부정보 구조 가져오기
문자 메시지필요시스템 설정
오류 메시지 편집
접근 권한 위반에 대한 MessageText 준비
DisassembleNameIndividuals
FindReferenceToObject
인쇄된 문서 번호 받기
준비 소스 확인
GetData 법적 개인
설명조직
ED를 처리할 권리가 있습니다
ED를 읽을 권리가 있습니다
저널 등록을 개시할 권리가 있습니다

모듈에서 이동된 메소드 목록 전자문서재정의 가능 V ExchangeWithBanks재정의 가능:

현재 유형의 ED 가져오기
은행 계좌 번호 받기
ED 매개변수를 소스별로 입력하세요.
지불 주문 데이터를 입력하세요
지불 요청 데이터를 입력하세요
개체 편집 기능 확인

이벤트 구독에서 소유자를 녹음할 때 ED의 새 버전 할당그리고 녹화 전 변경 확인OwnerED은행 문서가 삭제되었습니다.

처리에서 이동된 레이아웃 교환상대방 V 은행과 교환:

지불 순서
지불 요구 사항

정의된 유형에 추가해야 합니다.

documentObject.PackageED

인터페이스 변경

공통 모듈에서 은행과 교환, 교환상대방절차가 추가됨 서버에서 생성될 때. EDI 명령을 생성하기 위해 객체 양식을 열 때 호출됩니다. 옵션: 형태– 현재 형태, 팀 배치기본값– EDI 명령이 생성될 하위 메뉴 양식의 요소입니다.
공통 모듈에서 ExchangeWithBanks재정의 가능, 상대방과의 교환재정의 가능 EDM 명령 목록을 생성하기 위한 절차가 추가되었습니다. Teams EDF 개체의 구조 준비. 매개변수 팀 구성EDO배열일 수 있습니다(하위 시스템의 경우). 은행과 교환) 또는 배열 구조( 교환상대방).
EDI 명령 그룹이 제거되었으며 EDI 명령으로 명령 패널을 자동으로 채우는 작업이 더 이상 수행되지 않습니다.

정보베이스 문서 양식에서 EDM 명령을 생성하려면 재정의된 공통 모듈의 절차에서 개체 유형을 생성하는 코드를 추가해야 합니다.

모듈의 예 상대방과의 교환재정의 가능:

EDM 팀 구성.Outgoing.Add("Document.상품 및 서비스 판매");
EDO Commands.Outgoing.Add("Document.Buyer's Order")의 구성;
…
EDF 팀의 구성.Incoming.Add("Document.Receipt of Goods and Services");
EDO Commands.Incoming.Add("Document.InvoiceReceived")의 구성;
…
절차 종료

ExchangeWithBanks재정의 가능:

절차 EDF 팀 객체 구조 준비(EDF 팀 구성) 내보내기
EDO Commands.Add("Document.Payment Order")의 구성;
EDO Commands.Add("Document.PaymentRequest")의 구성;
…
절차 종료

양식을 작성할 때 프로그램 생성 명령을 호출하십시오.

상대방과 교환합니다. 서버에서 생성되면:

OnServer 생성 시 절차(Failure, StandardProcessing)
//EDO 명령
상대방과의 교환.When CreatedOnServer(ThisObject, Elements.EDO Commands);
// EDO 명령 끝
절차 종료

플러그형 양식 처리기 추가 Connectable_Execute EDO 명령:

프로시저 Connectable_Execute EDO 명령(Command)
ElectronicInteractionServiceClient.ExecuteConnectedCommandEDO(Command, ThisForm, Elements.List);
절차 종료

"상대방과의 교환" 하위 시스템 변경

항목이 입력될 기준이 되는 문서 유형으로 정의된 유형 "임의의 근거 ED"를 입력합니다. 임의의 ED(이러한 문서는 정의된 첨부 파일 소유자 유형과 동일한 문서일 가능성이 높습니다.) 또한 이러한 문서에서는 "다음에 대한 기초" 목록에 "Custom ED" 문서를 추가해야 합니다.
문서 양식 및 문서 목록(사용자 정의 ED 입력 기준)에서는 "다음을 기준으로 생성" 하위 메뉴에서 사용자 정의 ED를 비활성화해야 합니다. Custom ED를 입력하는 명령은 EDO 하위 메뉴("파일 추가" 명령)에 있습니다.
권리 양도법, 상품 주문, 주문에 대한 응답, 판매 수수료 대리인 보고서, 설명에 대한 수수료 대리인 보고서, 지불 송장, 제품 카탈로그, 매개변수 그룹의 가격표 레이아웃 "BIC" 필드의 "은행" 필수 작성 속성이 변경되었습니다. 이 필드는 반드시 작성해야 합니다.
송장송장 레이아웃에서 원산지 국가 코드 및 관세 신고 번호 필드의 형식이 변경되었습니다. 보다 정확한 작성을 위해 세관 신고서 표에 통합되어 있습니다. ESF 데이터 준비 절차에서 이러한 요소를 채우는 예는 BED의 데모 데이터베이스에서 찾을 수 있습니다.

ExchangewithCounterpartiesClient 모듈의 변경 사항

OpenEDList 메서드는 더 이상 사용되지 않습니다. 대신, 정보 보안 문서에 대한 전자 문서 교환에 대한 규정 트리를 사용자에게 공개하는 OpenEDTree를 사용하는 것이 좋습니다.

전자 상호작용 모듈의 변경 사항이 재정의됨

재정의를 위해 객체 이름 및 세부 정보에 대한 대응 가져오기에 두 개의 키가 추가되었습니다.

메타데이터의 상품 및 서비스 판매
메타데이터로 상품 및 서비스 수령

ExchangeCounterparties 모듈의 변경 사항

1C-보고 마스터에 대한 데이터를 준비하는 1C-보고 마스터에 대한 Fill DataBy 1SEDOD 방법을 추가했습니다.

계정 양식을 생성할 때 호출해야 하는 Check AccounterV1EDMSWhen CreatedOnServer 메서드를 추가했습니다. 이 방법은 상대방이 1C-EDO 서비스에 연결되어 있는지 확인합니다.
예 거래상대방과 교환 서버에 생성 시 1 SEDO에서 거래상대방 확인:

OnServer 생성 시 절차(Failure, StandardProcessing)
// 전자적 상호작용, 상대방과의 교환
상대방과의 교환 CreatedOnServer(Object.Link)시 1SEDO에서 상대방 확인;
// 전자적 상호작용을 종료하고 상대방과의 교류
절차 종료

NOT 분할 루틴 작업이 추가되었습니다. 상대방 확인BED, 상대방을 선택하고 1C-EDO에 대한 연결을 확인합니다.

분할 정보 레지스터 추가 거래상대방 현황BED, 1C-EDO 서비스에 연결된 계약자에 대한 통계를 수집합니다.

목록 양식 및 상대방 선택 양식의 "EDO" 열에 1C-EDO 서비스에 대한 연결 표시 표시를 추가합니다. "1C-EDO 서비스에 연결됨" 열에 힌트를 추가합니다.
예:

선택하다
선택
WHENCounterparty StatusBED.Status = VALUE(Enumeration.CounterpartyStateBED.Connected)
그러면 0
다른 1
끝
에도처럼 끝나라
디렉터리상대방.이름,
디렉토리상대방.INN,
디렉터리상대방.KPP,
....
디렉터리상대방.이름전체
에서
Directory.Counterparties AS DirectoryCounterparties
LEFT CONNECTION 정보 등록 계약자 현황 BED AS 계약자 BED 현황
소프트웨어(계약자 StatesBED.Counterparty = DirectoryCounterparties.Link)

정보 기반 문서 양식에서는 "ED 상태 텍스트" 양식 속성에서 "ED 교환 사용" 기능 옵션에 대한 링크를 제거해야 합니다. "ED Status" 속성에서 헤더를 제거합니다.

"은행과의 교환" 하위 시스템의 변경 사항

이벤트 구독이 추가되었습니다. 은행 소유자ED와 교환녹화 전그리고 ExchangeWithBanksOwnerEDOnRecording.

정의된 유형 OwnersExchangeWithBanks 및 DirectoryBanks를 추가했습니다.
일반 명령인 SettingsExchangeWithBanks를 추가했습니다.

정의된 유형에 첨부 파일추가하다:

디렉토리링크.MessageExchangeWithBanksAttachedFiles;
DirectoryObject.MessageExchangeWithBanksAttachedFiles;
디렉토리링크.PackageExchangeWithBanksAttachedFiles;
디렉터리 개체.PackageExchangeWithBanksAttachedFiles.

정의된 유형에 첨부파일의 소유자추가해야합니다

documentLink.MessageExchangeWithBanks;
documentLink.PackageExchangeWithBanks.

정의된 유형에 소유자첨부파일객체추가해야합니다

documentObject.MessageExchangeWithBanks;
documentObject.PackageExchangeWithBanks;
documentObject.PackageED

새로운 하위 시스템 "비즈니스 네트워크"를 추가했습니다.

하위 시스템에는 공통 모듈(접두사 Exchange비즈니스네트워크), 치료 비즈니스네트워크, 역할( 관리구독자비즈니스네트워크, 수행Exchange비즈니스네트워크), 정보 등록 식별자비즈니스네트워크. '전자문서 교환 설정' 양식에 서비스 연결 양식을 호출하는 명령이 추가되었습니다.

모듈의 절차와 기능을 완료해야 합니다. 비즈니스네트워크재정의 가능:

방법 세부사항에 따라 상대방 생성. 전달된 매개변수를 사용하여 애플리케이션 솔루션에 상대방을 생성합니다.
방법 IB 사용자 연락처 가져오기. 사용자의 연락처 정보(역할 이름, 이메일 주소)를 수신합니다.
방법 문서 세부사항 통제 실행. 배열 전송을 허용하려면 문서 세부 정보를 확인합니다(발신자와 수신자가 동일해야 함).

버전 1.3.6에서 버전 1.3.7로 전환

지급서류를 파일로 업로드하고 파일에서 은행 명세서를 다운로드하는 형태(처리) 클라이언트뱅크) 요소 그룹 이동 그룹광고DirectBank수평일반적인 형태부터 OfferConnect1SDirectBank.

양식 이벤트 핸들러에서 서버에서 생성될 때배치 방법 ExchangeWithBanksClientServer.ShowAdvertisingDirectBank:

&서버에서
CreateOnServer 시 절차(실패, StandardProcessing)
…
// 전자적 상호작용, 은행과의 교환
ExchangeWithBanksClientServer.ShowAdvertisingDirectBank(
Elements.GroupAdvertisingDirectBankHorizontally, Elements.TextDirectBankHorizontally);
// 전자거래 종료, 은행과의 교환
절차 종료

양식 이벤트 핸들러에서 경고 처리 중 ExchangeWithBanksClient.UpdateAdvertisingDirectBank 메소드를 배치합니다.

&클라이언트에서
프로시저 프로세스 알림(이벤트 이름, 매개변수, 소스)
…
// 전자적 상호작용, 은행과의 교환
ExchangeWithBanksClient.UpdateAdvertisingDirectBank(이벤트 이름,
Elements.GroupAdvertisingDirectBankHorizontally, Elements.TextDirectBankHorizontally);
// 전자거래 종료, 은행과의 교환
절차 종료

요소의 경우 TextDirectBank가로이벤트 핸들러 추가 처리NavigationLinks여기에 ExchangeWithBanksClient.ProcessingNavigationLinkAdvertisingDirectBank 메서드를 배치합니다.

&클라이언트에서
프로시저 TextDirectBankHorizontalNavigationLinkProcessing(요소, FormattedStringNavigationLink, StandardProcessing)
ExchangeWithBanksClient.ProcessingNavigationLinkAdvertisingDirectBank(
NavigationLinkFormatString, StandardProcessing);
절차 종료

절차에 MDI 개체 이름 및 세부 정보에 대한 대응 확인공통 모듈 전자상호작용키와 일치 요소 추가 PaymentOrderIn메타데이터값: 메타데이터 개체의 이름 지불 순서애플리케이션 솔루션에서.

09.06.2017

표준 구성 "1C: Library of Electronic Documents 1.3"의 새 버전 1.3.8이 출시되었습니다.

버전 1.3.8

새로운 기능 및 변경 사항

거래 제안 검색 양식에 1C : 비즈니스 네트워크 서비스에 연결하지 않고 검색하는 기능이 추가되었으며 이름으로 공급 업체를 검색하는 기능이 추가되었습니다.
게시된 거래 제안에 대한 보고서를 추가했습니다.
1C:Business Network 서비스에 거래 제안을 게시하는 작업장이 추가되었습니다.
하위 시스템 "1C: 표준 하위 시스템 라이브러리" 버전 2.4.2, "1C: 인터넷 사용자 지원 라이브러리" 버전 2.2.2를 사용하여 조정되었습니다.

버전 1.3.7에서 버전 1.3.8로 전환

모듈 변경 사항:

추가된 기능 게시된 제품에 대한 요청 텍스트거래 제안을 게시하고 게시된 상품에 대한 보고서를 생성하기 위한 데이터 소스를 얻습니다. 제품 목록을 수신할 때 FillOfferPackage 메소드에 대한 함수 호출을 구현해야 합니다.

모듈의 변경 사항 거래 제안

절차가 추가됨 업데이트장식조건출판물장식 양식 요소를 게시 상태로 업데이트합니다. 양식의 호출에 상태 요소에 대한 게시 설정을 추가해야 합니다.

역할이 추가됨 보고서거래제안보고서에 액세스하는 데 필요합니다. 공개된 거래 제안.

버전 1.3.7

구성 속성 값:

호환성 모드는 "사용하지 않음"으로 설정해야 합니다.
양식 사용 모드는 "사용 안 함"으로 설정할 수 있습니다.
인터페이스 호환성 모드는 "버전 8.2", "버전 8.2. 택시 허용" 또는 "택시. 버전 8.2 허용" 값을 가질 수 있습니다.

새로운 기능 및 변경 사항

Sberbank에서 결제 문서의 상태를 가져오는 기능이 추가되었습니다.
1C:DirectBank 서비스에 연결할 때 Sberbank에 대한 설정 자동 수신을 구현했습니다.
문맥 광고 1C:DirectBank를 표시하는 기능이 추가되었습니다.
1CFresh 클라우드 서비스의 1C: Business Network 서비스와 작동하도록 조정되었습니다.
1C: 비즈니스 네트워크 서비스 참가자를 위한 1C: 거래 제안 서비스에 거래 제안을 게시, 검색 및 주문하는 기능이 추가되었습니다.
적응은 하위 시스템 "1C: 표준 하위 시스템 라이브러리" 버전 2.4.1, "1C: 인터넷 사용자 지원 라이브러리" 버전 2.1.9, "1C: 서비스 기술 라이브러리" 버전 1.0.12를 사용하여 수행되었습니다.

버전 1.3.6에서 버전 1.3.7로 전환

하위 시스템 "상대방과의 교환"

모듈 변경 사항:

문서 날짜, DocBase날짜

하위 시스템 "은행과의 교환"

모듈의 변경 사항 무시할 수 있는 파일 작업:

절차에 설정을 정의할 때코드를 추가해야 합니다:

ElectronicInteraction.WhenDefiningSettings(설정);

절차에 파일 저장 디렉터리를 정의하는 경우코드를 추가해야 합니다:

전자적 상호작용. FileStorage 디렉터리를 정의할 때(FileOwnerType, DirectoryNames);

MessageExchangeWithBanksAttachedFiles 및 EDAttachedFiles 디렉터리가 교환 계획 UpdateInformationBase에 추가되었습니다.
MessageExchangeWithBanksAttachedFiles 및 EDAttachedFiles 디렉터리가 정의된 유형 SignedObject에 추가되었습니다.

양식 이벤트 핸들러에서 서버에서 생성될 때배치 방법 ExchangeWithBanksClientServer.ShowAdvertisingDirectBank:

&서버에서
CreateOnServer 시 절차(실패, StandardProcessing)
…
ExchangeWithBanksClientServer.ShowAdvertisingDirectBank(

절차 종료

양식 이벤트 핸들러에서 경고 처리 중 ExchangeWithBanksClient.UpdateAdvertisingDirectBank 메소드를 배치합니다.

&클라이언트에서

…
// 전자적 상호작용, 은행과의 교환
ExchangeWithBanksClient.UpdateAdvertisingDirectBank(이벤트 이름,
Elements.GroupAdvertisingDirectBankHorizontally, Elements.TextDirectBankHorizontally);
// 전자거래 종료, 은행과의 교환
절차 종료

하위 시스템 "사이트와의 교환"

모듈의 변경 사항 사이트 교환 재정의 가능:

절차가 추가됨 DetailsFormNode 추가, 사이트와의 Exchange 계획 노드 양식에 세부 정보를 추가하는 데 사용됩니다. 교환 노드 양식은 애플리케이션 솔루션과 관련된 세부사항이 있다고 가정하지 않으며 세부사항은 프로그래밍 방식으로 추가됩니다.
절차가 추가됨 입력 필드WhenChangedOnServer, 교환 계획 노드 양식의 입력 필드가 변경되면 Add NodeFormDetails 프로시저에 추가되는 이벤트를 북쪽에서 처리하는 데 사용됩니다.
절차가 추가됨 CheckboxFieldWhenChangedOnServer는 Add NodeFormDetails 프로시저에 추가된 교환 계획 노드 양식의 플래그 필드가 변경될 때 서버에서 이벤트를 처리하는 데 사용됩니다.
절차가 추가됨 ServerFormCreateSite에서 생성할 때, CreateSite 처리 양식에 세부정보를 추가하는 데 사용됩니다.

모듈의 변경 사항 ExchangeSiteClient재정의 가능:

제거된 절차 GroupTableU 카탈로그 유형 정의, 제품 카탈로그 테이블의 그룹 열 값 유형은 교환 설정에 따라 결정됩니다.
절차가 추가됨 입력 필드 변경 시, 교환 계획 노드 양식의 입력 필드가 변경되면 SiteExchangeOverridden.AddNodeFormDetails 프로시저에 추가되는 이벤트를 처리하기 위해 호출됩니다.
절차가 추가됨 확인란FieldOnChange는 SiteExchangeOverridden.AddNodeFormDetails 프로시저에 추가된 교환 계획 노드 양식의 플래그 필드가 변경될 때 이벤트를 처리하기 위해 호출됩니다.
절차가 추가됨 TableFormBeforeFinish편집는 SiteExchangeOverridden.AddNodeFormDetails 프로시저에 추가된 교환 계획 노드 양식의 표 부분에 있는 필드의 BeforeFinishEdit 이벤트를 처리하기 위해 호출됩니다.

하위 시스템 "비즈니스 네트워크"

분할 모드, 공통 모듈에서 일상적인 작업을 실행하기 위한 새로운 방법이 추가되었습니다. 전자상호작용, 절차 템플릿 목록 수신 시, . 일반 모듈 JobQueueOverridable에서 동일한 이름의 메서드를 참조하세요.
라이브러리를 포함할 때 분할 모드로 작업하려면 일반 모듈의 메서드에 대한 호출을 추가해야 합니다. JobQueue재정의 가능:
- 절차에서 템플릿 목록 수신 시:

// 전자적 상호작용
ElectronicInteraction.OnReceiveingListTemplates(TaskTemplates);

절차에서 AliasesHandler를 정의할 때:

// 전자적 상호작용
ElectronicInteraction.WhenDefiningHandlerAliases(MatchNamesAliases);
// 전자 상호작용 종료

모듈의 변경 사항 비즈니스네트워크재정의 가능:
- 프로시저 이름이 변경됨 IB 사용자 연락처 가져오기 V 사용자 연락처 정보 얻기.
- 절차가 기능으로 변경됨 세부사항에 따라 상대방 생성에서는 Account 매개변수가 제거되었습니다.

하위 시스템 "거래 제안"

새로운 하위 시스템 "거래 제안"이 추가되었습니다. 포함하려면 다음이 필요합니다.

공통 모듈에서 재정의된 메서드 개발 TradeOffers클라이언트 재정의 가능, 거래 제안 재정의 가능.
정의된 유형으로 데이터 유형 지정 세부 정보 값 유형 1СBusinessNetwork, 명명법 BED의 종류, 추가 세부정보BED, 거래 제안.

자세한 내용은 삽입 문서를 참조하세요.

버전 1.3.6

새로운 기능 및 변경 사항

기본 송장 문서의 형식은 2016년 3월 24일자 연방세청 명령에 따라 지원됩니다(별도의 기본 문서, 송장 전송 측면에서) No. ММВ-7-15/155@ "승인 시" 송장을 포함한 상품 배송(작업 수행), 재산권 양도(서비스 제공에 관한 문서)에 대한 송장 형식 및 문서 제시 형식을 전자 형식으로 제공합니다."
조정 송장을 포함하여 가치 변화에 대한 기본 문서 형식은 2016년 4월 13일자 연방세청 명령에 따라 지원됩니다(별도의 기본 문서, 조정 송장 전송 측면에서) N ММВ -7-15/189@ " 조정 송장 형식과 배송된 상품 비용(수행된 작업, 제공된 서비스) 변경에 대한 문서 제출 형식이 승인되면 조정 송장을 포함한 재산권이 이전됩니다. 전자 양식."
새로운 전자 문서가 추가되었습니다: 상품 양도, 작업 결과 양도, 새로운 형태의 문서 시각적 표현.
수신자로부터 수신 알림을 받을 필요가 없는 단방향 교환 메커니즘이 추가되었습니다.
수신 전자 문서의 압축 풀기를 제어하는 기능(자동 또는 수동), 전자 문서 수신 시 특정 유형의 문서 생성을 구성하는 기능이 추가되었습니다.
전자 문서를 여러 정보 기반 회계 문서에 연결하는 기능이 추가되었습니다.
전자문서의 수신, 발신 구분이 구현되었습니다.
서비스와의 통합이 구현되었습니다. 1C-UMI프로그램에서 웹사이트를 만들고, 온라인 상점과의 교환을 설정할 수 있습니다. 우미.
1CFresh 클라우드 서비스에서 1C-EDO 서비스 작업을 위해 조정되었습니다.

버전 1.3.5에서 버전 1.3.6으로 전환

하위 시스템 "상대방과의 교환"

일반 모듈 상대방과 교환재정의 가능

UPD SCHFDOP 메소드를 추가했습니다.
추가된 방법 UPD 구매자 정보에 대한 데이터를 입력하세요. Federal Tax Service. 이 방법은 UPD(구매자 정보) 기능 SCHFDOP 유형의 전자 문서에 대한 데이터를 준비합니다.
정보보안 객체에 UPD 방식(판매자 정보) 기능 SCHFDOP를 추가했습니다.
추가된 방법 판매자 연방세 서비스의 추가 정보에 대한 데이터를 입력하세요.. STD(판매자 정보) DOP 기능과 같은 전자 문서에 대한 데이터를 준비하는 방법입니다.
추가된 방법 찾기UPDT 문서 만들기정보전송. 전자문서 UPD(판매자 정보) 기능 DOP의 데이터를 IS 객체에 저장하는 방식입니다.
추가된 방법 SCHFIS판매자 정보에 대한 데이터를 입력하세요. Federal Tax Service. 이 방법은 UTD(판매자 정보) SSF 기능 유형의 전자 문서에 대한 데이터를 준비합니다.
추가된 방법 찾기CreateUPDS송장송장. 전자문서 UPD(판매자정보) SSF 기능에서 발생한 데이터를 정보보안객체에 저장하는 방식이다.
방법이 추가되었습니다. 이 방법은 UCD 유형(판매자 정보) 기능 KSCHFDIS의 전자 문서에 대한 데이터를 준비합니다.
추가된 방법 UKID 구매자 정보에 대한 데이터 입력 Federal Tax Service. 이 방법은 UKD(구매자 정보) 기능 KSCHFDIS 유형의 전자 문서에 대한 데이터를 준비합니다.
방법이 추가되었습니다. 전자문서 UCD(판매자 정보) 기능 KSCHFDIS의 데이터를 정보보안 객체에 저장하는 방식입니다.
추가된 방법 판매자 연방세 서비스에 대한 허위 정보에 대한 데이터를 입력하세요.. UCD형(판매자 정보) DIS 기능의 전자문서에 대한 데이터를 준비하는 방법이다.
추가된 방법 찾기CreateUKDDocumentAboutChangeValue. 전자문서 UCD(판매자 정보) 기능 DIS의 데이터를 IS 객체에 저장하는 방식입니다.
추가된 방법 KSCHFIS판매자 정보에 대한 데이터를 입력하세요. Federal Tax Service. 이 방법은 UCD 유형(판매자 정보) 기능 KSCHF의 전자 문서에 대한 데이터를 준비합니다.
추가된 방법 찾기CreateUKDS계정송장. 전자문서 UCD(판매자 정보) 기능 KSCHF의 데이터를 정보보안 객체로 저장하는 방식입니다.
추가된 방법 정보 보안 문서와 함께 발신 유형의 ED 준수. 이 방법은 나가는 전자 문서와 정보 보안 문서 간의 대응을 형성합니다.
추가된 방법 찾기만들기문서전송작업결과. 이 방법은 "상품 양도" 형식으로 받은 위탁 메모 문서를 작성하는 데 사용됩니다.
추가된 방법 찾기작성문서물품이전. 이 방법은 "작업 결과 전송" 형식으로 받은 서비스 제공 증명서 문서를 작성하는 데 사용됩니다.
추가된 방법 설치상태교환완료. 문서 흐름 상태가 다음으로 변경되면 메서드가 호출됩니다. 교환완료, 수정완료 교환완료.
전자문서 생성시 UPD, UKD, 물품이전, 작업결과 이전, 상세내역 문서 날짜, DocBase날짜작성이 필요합니다.

상대방과의 교환 처리

"Torg-12Seller" 레이아웃에서:

"IdStateContract" 필드를 추가했습니다.
표 형식의 "운송 송장" 부분이 추가되었습니다.
"운송 송장 날짜", "운송 송장 번호" 필드가 제거되었습니다.
"상품을 양도한 사람에 대한 정보" 필드를 추가했습니다.

레이아웃에서 권리 양도법:

표 형식 부분 "기본"이 추가되었습니다.
"DocumentBaseName", "DocumentBaseNumber", "DocumentBaseDate", "DocumentBaseAdditionalInformation" 필드가 제거되었습니다.
"CurrencyName" 필드를 추가했습니다.
'클레임' 필드를 추가했습니다.
"실행 날짜" 필드를 추가했습니다.
거래 참가자 속성에서 "팩스" 필드가 "이메일" 필드로 대체되었습니다.
거래 참가자 속성에서 "국가 코드" 필드가 "국가 코드" 필드로 대체되었습니다.
거래 참가자 속성에서 "AddressText" 필드가 "AddressText" 필드로 대체되었습니다.

정의된 유형 업데이트 상대방:

업데이트 절차:

정의된 유형 Account의 이름을 AccountBED로 바꿉니다.
BED 1.3.5 지원에서 구성을 제거합니다.
BED 1.3.5 구성과 비교/병합을 실행하고 지원하도록 구성을 설정하는 데 동의합니다.
모든 개체를 선택 취소하고 정의된 계정 유형만 남겨두고 병합을 수행합니다.
구성 업데이트를 시작하고 BED 파일 1.3.6을 선택합니다.
정의된 유형 AccountBED 및 Account에 대한 확인란을 선택합니다. 업데이트에 필요한 기타 데이터베이스 개체를 지정합니다.
업데이트를 수행합니다.

서브시스템 "은행과의 환전"

하위 시스템 "사이트와의 교환"

교환 노드가 변경됨 사이트 교환, 양식, 개체 모듈:

항목 유형별로 선택하여 항목을 업로드하는 기능이 추가되었습니다(이전에는 항목 그룹에서만 사용할 수 있었습니다).

참고서 추가됨 웹사이트:

1C에서 사이트의 사용자 부분 및 사이트의 관리 영역으로의 사이트 전환을 구성하는 기능이 추가되었습니다.
사이트를 기반으로 ExchangeSite 교환 노드를 생성할 수 있습니다.

처리 추가 웹사이트 만들기:

1C-UMI 도메인에 사이트를 생성하는 기능이 추가되었으며, 사이트가 자동으로 생성되고(사이트 요소) 1C의 데이터로 채워집니다. ExchangeSite 교환 노드가 자동으로 생성되고 사이트와의 첫 번째 전체 교환이 수행됩니다.

일반 모듈 사이트 교환 재정의 가능:

아이템 종류 선택 기능이 추가되었으며, 임의 참고도서 선택 기능이 제거되었습니다.

일반 모듈 ExchangeSite이벤트:

아이템 종류를 선택하는 기능이 추가되었습니다.
사용자 정의 디렉토리를 선택하는 기능이 제거되었습니다.

기타 변경사항

하위 시스템 설정 관세관리도서관 서비스 모델에서 서비스 기술

// 전자적 상호작용
전자적 상호작용. 서비스(서비스 제공자) 목록을 작성할 때
// 전자 상호작용 종료

버전 1.3.5

구성 속성 값:

호환성 모드는 "사용하지 않음"으로 설정해야 합니다.
양식 사용 모드는 "사용 안 함"으로 설정할 수 있습니다.
인터페이스 호환성 모드는 "버전 8.2", "버전 8.2. 택시 허용" 또는 "택시. 버전 8.2 허용" 값을 가질 수 있습니다.

새로운 기능 및 변경 사항

라이브러리 기능은 호환 모드가 비활성화된 8.3.8 플랫폼에서 작업하는 특정 기능에 맞게 조정되었습니다.
"표준 하위 시스템 라이브러리"의 하위 시스템이 버전 2.3.3.45로 업데이트되었습니다.
라이브러리에는 하위 시스템 "인터넷 사용자 지원 라이브러리" 버전 2.1.8.3이 포함되어 있습니다.

버전 1.3.4에서 버전 1.3.5로 전환

변경이 필요하지 않습니다.

버전 1.3.4

새로운 기능 및 변경 사항

EDI 이벤트에 대한 알림 시스템이 구현되었습니다(새 전자 문서, 새 초대, 인증서 만료 등). 이제 EDF 설정 프로필에서 이메일 알림을 구성하고 팝업 메시지를 사용하여 1C 프로그램에서 직접 이벤트에 대한 알림을 표시할 수 있습니다.
2016년 3월 24일자 연방세청 명령에 따라 송장(UPD 형식)을 포함한 기본 문서 형식이 지원됩니다. ММВ-7-15/155@ “송장 형식 승인 시 송장을 포함하여 상품 배송(작업 수행), 재산권 이전(서비스 제공에 관한 문서)에 관한 문서를 전자 형식으로 제출하는 형식";
2016년 4월 13일 N ММВ-7-15/189@ 연방세청 명령에 따라 조정 송장을 포함하는 가치 변경에 관한 문서 형식이 지원되었습니다."(UKD 형식) "조정 송장 형식 및 선적 상품 비용 변경(수행된 작업, 제공된 서비스)에 대한 제시 형식 문서의 승인 시 조정 송장을 포함한 전자 형식의 재산권 이전"
DirectBank 기술을 사용하여 은행과 교환하여 외부 구성 요소 사용을 지원했습니다.

버전 1.3.2, 1.3.3에서 버전 1.3.4로 전환

신청솔루션 문서목록 양식 변경사항

문서 목록 양식에 플러그인 프로시저를 추가해야 합니다. CounterpartiesClient.Waiting ProcessorEDW와의 교환:

&클라이언트에서

절차 종료

하위 시스템을 업데이트할 때 문서 목록 형식의 이벤트 핸들러에 필요합니다. 서버에서 생성될 때, 열 때, 경고 처리 중

&클라이언트에서
열기 절차(실패)
…
// "상대방과의 교환" 하위 시스템.
// "상대방 교환" 하위 시스템이 종료됩니다.
절차 종료

응용솔루션 문서양식 변경사항

문서 양식에서 플러그인 프로시저를 추가해야 합니다. Connectable_WaitingHandlerEDO, 여기서 메소드 호출을 수행해야 합니다.

CounterpartiesClient.Waiting ProcessorEDW와의 교환:

&클라이언트에서
프로시저 Connectable_EDOWaitingHandler()
ExchangeCounterpartiesClient.EDOWaitingHandler(ThisObject);
절차 종료

예를 들어:

&서버에서
OnServer 생성 시 절차(Failure, StandardProcessing)
…
// "상대방과의 교환" 하위 시스템.
생성 시 EDO 매개변수 = 상대방과의 교환 Server_DocumentForm()에서 생성 시 매개변수;
생성 시 EDO 매개변수.Form = ThisObject;
생성 시 EDO 매개변수.DocumentLink = Object.Link;
생성 시 EDO 매개변수.DecorationStateEDO = Elements.DecorationStateEDO;
생성 시 EDO 매개변수.EDO 상태 그룹 = Elements.EDO 상태 그룹;
상대방과의 교환.생성시 Server_DocumentForm(거부, 표준처리, EDO 매개변수생성시);
// "상대방 교환" 하위 시스템이 종료됩니다.
절차 종료

ExchangeCounterparties 모듈의 변경 사항

절차가 추가됨 Server_ListForm에 생성될 때, 문서 목록 양식의 "When CreatedOnServer" 이벤트 핸들러에서 호출됩니다. 메소드의 세 번째 매개변수로 메소드에 의해 초기화되는 구조체가 전달됩니다. 매개변수WhenCreatingOnServer_ListForm.
절차가 추가됨 Server_FormDocument를 생성할 때, 문서 양식의 "When CreatedOnServer" 이벤트 핸들러에서 호출됩니다. 메소드의 세 번째 매개변수로 메소드에 의해 초기화되는 구조체가 전달됩니다. 매개변수WhenCreatingOnServer_DocumentForm.
절차가 추가됨 AfterRecordingOnServer, 문서 양식의 "AfterRecordOnServer" 이벤트 핸들러에서 호출됩니다. 메소드의 세 번째 매개변수로 메소드에 의해 초기화되는 구조체가 전달됩니다. 매개변수AfterRecordingOnServer.

모듈의 변경 사항 상대방클라이언트와의 교환.

절차가 추가됨 열 때, 문서 목록 양식 및 문서 양식의 "On opening" 이벤트 핸들러에서 호출됩니다.
절차가 추가됨 처리 중 경고_목록 양식, 문서 목록 양식의 "알림 처리" 이벤트 핸들러에서 호출됩니다. 메소드의 네 번째 매개변수로 메소드에 의해 초기화되는 구조체가 전달됩니다. 경고 매개변수EDO_ListForm.
절차가 추가됨 ProcessAlert_FormDocument, 문서 양식의 "알림 처리" 이벤트 핸들러에서 호출됩니다. 메소드의 네 번째 매개변수로 메소드에 의해 초기화되는 구조체가 전달됩니다. 알림 매개변수EDO_DocumentForm.
모듈의 변경 사항 상대방과의 교환재정의 가능:
추가된 방법 작업 실행자의 데이터 전송을 입력합니다..
예:

방법 개체 편집 기능 확인절차가 되었습니다.
추가된 방법 판매자 연방세 서비스의 UPD 정보에 대한 데이터를 입력하세요.. 이 방법은 다음 유형의 전자 문서에 대한 데이터를 준비합니다. UPD(판매자정보) 기능 슈프도프.
추가된 방법 찾기CreateUniversalTransferDocument. 이 방법은 전자 문서의 데이터를 저장합니다. UPD(판매자정보) 기능 SCHFDOPv IS 객체.
추가된 방법 UKDI 판매자 정보 연방세 서비스에 대한 데이터를 입력하세요.. 이 방법은 다음 유형의 전자 문서에 대한 데이터를 준비합니다. UKD(판매자정보) 기능 KSCHFDIS.
추가된 방법 찾기CreateUniversalAdjustmentDocument. 이 방법은 전자 문서의 데이터를 저장합니다. UKD(판매자정보) 기능 KSCHFDIS정보 보안 개체에.

"은행과의 교환" 하위 시스템의 변경 사항

ExchangeWithBanksRedefinable 모듈의 변경 사항

절차 ED 조건이 변경되는 경우추가되었습니다. 전자문서 흐름 상태가 변경되면 호출됩니다.

서비스 모드 작업에 대한 변경 사항

서비스 모드에서 작동하기 위한 대상 구성이 필요한 경우:

공통 모듈 SupplyDataOverridden의 GetProvidedDataHandlers 프로시저에서 다음 코드를 추가합니다.

ElectronicInteraction.RegisterDeliveredDataHandlers(처리기);

일반 속성 데이터 영역 기본 데이터에 루틴 작업인 은행과 외부 모듈 교환 업데이트를 추가합니다.

기타 변경사항

정의된 유형에 저장 공간기능 옵션상수를 추가해야 합니다 UseExchangeWithBanks;
제거된 기능 은행과의 교환, 은행과의 직접 교환 권장.

버전 1.3.3

구성 속성 값:

호환성 모드는 "사용하지 않음"으로 설정해야 합니다.
양식 사용 모드는 "사용 안 함"으로 설정할 수 있습니다.
인터페이스 호환성 모드는 "버전 8.2", "버전 8.2. 택시 허용" 또는 "택시. 버전 8.2 허용" 값을 가질 수 있습니다.

새로운 기능 및 변경 사항

2015년 11월 30일자 명령 No. ММВ-7-10/551@ "전자 형식으로 무역 거래 중 상품 양도에 관한 문서 제출 형식 승인" 및 2015년 11월 30일자 명령 No. ММВ-7-10/552@ "작업 결과 전송에 관한 문서(서비스 제공에 관한 문서)를 전자 형식으로 제출하는 형식 승인 시" 새로운 형식의 전자 문서가 지원됩니다.

버전 1.2.7, 1.3.1에서 버전 1.3.2.19로 전환

"상대방과의 교환" 하위 시스템 변경

모듈에서는 상대방과의 교환재정의 가능변경:

// 위탁 메모 유형의 전자 문서에 대한 데이터를 준비합니다.
// 옵션:
// LinkOnED - 전자문서 생성에 필요한 ED에 대한 링크,
// StructureED - 전자 문서 생성을 위한 구조, 데이터 구조입니다.
// 데이터 트리 - 전자 문서를 작성하기 위한 데이터 트리인 값 트리입니다.
절차 판매자에게 상품 데이터 전송 입력(볼륨 링크)

동료!

일부 구성에서는 오류로 인해 데이터를 다운로드할 수 없으므로 연방 세금 서비스에 보고서를 제출할 수 없습니다.

거래 상대방과의 거래(TIN/KPP 확인이 통과되지 않는 이유)는 긴 과정이며 종종 연방세 서비스에 정보를 전송하고 질문이 있는 경우 상대방에 대한 증명서를 제공하면 됩니다. 스스로 문제를 해결하려고 노력하고 늦게 신고하면 벌금을 받기보다는 스스로 처리할 수 있습니다.

이제 1C: 회계 8판 구성의 예를 사용하여 이러한 상황에서 벗어나는 몇 가지 기술에 중점을 둘 것입니다. 3.0.

따라서 트릭 번호 1은 다음과 같습니다. Accounting 8의 기본 제공 거래 상대방 확인은 TIN/KPP가 있는 상대방에만 적용됩니다. 검증을 통과하지 못한 상대방으로부터 TIN/KPP를 제거하면 오류 메시지가 표시되지 않습니다. 보고서 검증 모듈에서는 단순히 고려 대상에서 제외됩니다.

트릭 2번: 거래상대방을 확인할 때 "상대방 상태"라는 특별 정보 레지스터가 채워집니다. 이것이 당신이 작업해야 할 것입니다.

훈련 기반의 예를 사용하여 이 옵션을 고려해 보겠습니다. 검증되지 않은 거래상대방 목록은 다음과 같습니다.

프로그램은 예를 들어 Camellia 거래 상대방의 상태가 "KPP가 연방세청 데이터베이스의 데이터와 일치하지 않습니다"라고 보고합니다. 그러한 거래상대방은 수표를 통과하지 못하며 프로그램에서는 해당 거래상대방이 포함된 VAT 보고서를 다운로드하는 것을 허용하지 않습니다.

무엇을 할 수 있나요?

"상대방 상태"정보 등록을 엽니 다 - Ch. 메뉴 - 모든 기능 - 정보 레지스터:

"계약자 상태" 정보 등록에서 원하는 상대방이 있는 줄에 커서를 놓습니다.

그리고 확인 상태를 "체크포인트가 연방세청 데이터와 일치하지 않습니다."에서 "상대방이 연방세청 데이터베이스에 있습니다."로 변경합니다.

"(EDI)는 러시아 회사 및 조직에서 실제로 구현되는 내용을 매우 정확하게 반영하지 않습니다. 가장 간단한 경우에는 종이 문서의 전자 카드 관리에 관한 것이고, 더 복잡한 경우에는 전자 사본의 추가 회로를 만드는 것에 관한 것입니다. 그러나 여기의 원본은 항상 종이 문서입니다. 이것이 바로 이번 검토에서 원본 문서가 전자 형식으로 제공될 때 "실제" EDF의 구현 옵션을 가리키는 "종이 없는 전자 문서 관리"(BED)라는 용어를 사용하기로 결정한 이유입니다. 동시에, 종이 문서를 없애는 것 자체가 목적이 아니라 업무의 질과 효율성을 향상시키는 수단일 뿐이라는 점을 강조하고 싶습니다.

BED로의 전환에 대한 논의는 2008년부터 주 차원에서 꽤 오랫동안 활발하게 진행되어 왔습니다. 그러나 이 프로세스가 얼마나 역동적이고 성공적입니까? 오늘날의 결과가 7~10년 전 예측과 다른 이유는 무엇입니까? 이러한 질문에 대한 답변을 얻기 위해 우리는 EDMS/ECM 도구 개발자와 해당 시스템의 구현 및 운영에 관련된 전문가에게 문의했습니다.

BED로의 전환과의 관련성은 무엇입니까?

Business Logic(IT 그룹)의 Alfresco 사업부 책임자인 Oleg Beilezon은 이 주제가 상업 조직과 정부 조직 등 다양한 유형의 고객과 점점 관련성이 높아지고 있다고 말합니다. 모든 사람은 이미 말 그대로 종이 더미에 빠져 있습니다. 이는 물리적으로 문제가 되고 있으며, 많은 직원의 데스크탑과 캐비닛에는 검토, 동의, 서명, 저장 및 "세금 신고" 문서가 넘쳐나고 있으며 점점 더 어려워지고 있습니다. 그들을 관리하기 위해. 그의 의견으로는 많은 정부 규제 기관(예: 연방세청)이 이를 깨달았기 때문에 공식 문서의 종이 없는 배포로 전환할 것을 강력히 권장합니다. 심지어 필수 요구 사항도 마찬가지입니다.

EOS 회사의 마케팅 부서 책임자인 Elena Ivanova는 종이 없는 문서 흐름으로의 전환을 통해 기업이 비용을 절감하고 비즈니스 프로세스의 효율성을 높일 수 있지만 그러한 변화에는 다음이 필요하다는 점을 명심해야 한다고 지적합니다. 기술 솔루션 구현, 규정 변경, 전자 문서 사용으로 인해 발생하는 위험 최소화와 관련된 특정 비용. 일반적으로 상황은 분명합니다. 종이 문서의 흐름이 많아질수록 종이 없는 교환 문제가 더욱 시급해집니다. 그녀는 "지금" 추가 비용이 필요하고 직원들이 종이 문서의 일반적인 프로세스와 속성을 포기하지 않으려는 것이 이러한 전환을 지연시키는 주요 장벽이라고 생각합니다. 그러나 개발자에게는 구현 문제를 극복할 수 있는 도구가 있습니다.

그러나 이제 장기적인 경제 위기 상황에서 모든 회사가 이를 수행할 준비가 되어 있는 것은 아니라고 ELAR Corporation의 ECM 솔루션 개발 부서 책임자인 Dmitry Shmailov는 말합니다. 또한 BED는 생산 자동화, 중요한 작업을 위한 솔루션 및 비용 절감을 목표로 하는 시스템, 즉 돈을 벌 수 있는 프로젝트와 같은 비즈니스의 우선 순위가 아닙니다.

InterTrust for Business Development의 부사장인 Vadim Ipatov는 조직 및 기술 문제 외에도 규제 요구 사항도 있으며 오늘날에도 여전히 종이 원본 사용에 중점을 두고 있다고 회상합니다. 특히 문서의 장기(특히 영구) 보관 문제는 여전히 해결되지 않은 상태로 남아 있습니다. 전체 볼륨에서 이러한 문서가 차지하는 비중은 적어 보이지만 닻처럼 종이 원본을 전체적으로 버리는 과정을 방해합니다.

의사소통 수단으로 사용되는 문서에 관해 이야기한다면 오늘날 가장 일반적인 메커니즘은 이메일입니다. 여기에는 조직적, 법적, 기술적 문제가 없는 것으로 보입니다. 그러나 실제로 이메일은 전통적인 종이 버전의 상호 작용을 구현하며, 자동으로 구현되면 IT를 사용해도 관리하기 어려운 엄청난 양의 정보가 생성됩니다. 즉, 질적으로 다른 통신 아키텍처가 필요합니다. 전문가는 이를 사용하려면 ECM에 대한 이해를 재고하고 ECM을 사람, 프로세스 및 관련 콘텐츠를 통합하는 시스템으로 포지셔닝해야 한다고 강조합니다. 오늘날에는 종이 없는 문서 흐름이 아니라 종이 없는 문서화된 작업 프로세스 중 사람들의 상호 작용에 대해 이야기하는 것이 더 정확합니다.

전통적으로 EDMS 문제는 기업 내부 비즈니스 프로세스의 자동화 문제로 이해되었으며 상당 부분 조직 및 관리 문서와 관련되었습니다. 그러나 최근 몇 년 동안 상업 회사 간, 정부 기관 내, 기업 및 개인과 정부 기관의 상호 작용 등 조직 간 문서 교환 문제의 관련성이 급격히 증가했습니다. 이러한 모든 영역은 이제 조직 간 전자 문서 흐름으로의 전환이라는 관점에서 빠르게 발전하고 있습니다.

이에 대해 Taxkom의 마케팅 부국장인 Ernest Kolesnikov는 분석가들의 예측을 언급합니다. 2017년까지 상대방과의 EDI 메커니즘 사용은 22.5%에 도달할 것입니다. 이미 새로운 VAT 신고서가 도입된 후(거의 모든 납세자가 이를 전자적으로 제출해야 함) 수동 데이터 입력을 사용하면 회계가 상대방과의 불일치에 대한 자동 요청을 받을 가능성이 높기 때문에 문서 자동화 문제가 특히 중요해졌습니다. . 그는 또한 러시아 연방 노동법 49.1장이 원격 근무 시 EDI 사용을 허용하고 있으며, 2016년 7월 1일부터 "주식 회사에 관한" 연방법 개정안이 발효되어 주주들이 이를 허용할 것임을 상기시킵니다. EDI를 사용하여 원격으로 회의에 참여합니다.

1C의 전자 문서 교환 프로젝트 관리자인 Artem Tanan은 BED로 전환하는 주요 동기는 기업의 경쟁력 강화에 대한 열망이라고 확신합니다. 시장의 리더가 되고자 하는 사람들은 법적 허가가 있기 오래 전에 그러한 변화를 준비하기 시작했으며 실제로 이러한 기회를 가장 먼저 습득했습니다. 2013~2014년으로 돌아갑니다. 소매 체인, 유통업체, 통신 사업자 등과 같이 경쟁이 치열하고 기술 산업에 종사하는 기업에서는 상대방과 전자적으로 상호 작용하는 방법을 사용하기 시작했습니다. 이를 통해 VAT 환급 가속화 및 세금 위험 감소에서 최적화에 이르기까지 포괄적인 효과를 얻을 수 있었습니다. 비용을 절감하고 상대방과의 상호작용 효율성을 높입니다. 공급 회사의 압력으로 상대방도 BED로 전환하기 시작했습니다. 2015년에는 법률이 개발되고 세금 보고서 제출에 대한 여러 가지 새로운 규제 요건이 등장하면서 프로세스가 더욱 널리 퍼졌습니다. 최근 몇 년 동안 서비스에 연결된 사용자 수가 크게 증가했습니다.

종이 없는 전자문서 관리로의 전환 실천

Elena Ivanova에 따르면 지점 및 원격 장치와 상호 작용할 때 전자 원본을 전송하는 관행이 점점 더 널리 보급되고 있습니다. 거래 상대방과 기본 회계 문서(법률, 송장 등)를 교환하고 해당 전문 교환 서비스와의 통합이 점점 더 대중화되고 있습니다. 그러나 그녀는 많은 조직이 여전히 전자 원본 문서를 사용할 때 발생하는 위험을 경계하고 있으며 모든 유형의 전자 문서 사용이 여전히 "금지"되는 주제라고 지적합니다.

Oleg Beilezon은 "전자 원본 작업으로의 전환에 관해 이야기할 때 회사에서는 '우리가 원한다'라는 단어로 시작하고 그 뒤에는 '하지만...'이라고 말합니다."라고 말합니다. "그럼 극복할 수 있는 여러 가지 이유가 있습니다. 일부 부서가 준비되지 않았고, 예산이 할당되지 않았으며, 조직의 전통을 깨뜨릴 수 없습니다." 그러나 그는 일반적으로 종이 없는 기술로의 전환을 위한 프로젝트가 있지만 역 전환을 위한 프로젝트에 대해서는 들어본 바가 없기 때문에 문서 흐름의 전자화 추세가 꽤 잘 보인다고 믿습니다. BED가 다루는 많은 영역이 있습니다. 이는 고전적인 EDMS, 조직의 재무 문서 흐름 및 법적으로 중요한 재무 문서 순환입니다. 법적으로 중요한 조직 및 행정 문서 흐름이 다소 정체되어 있습니다. 법적 미묘함이 너무 많고 충분한 실무가 개발되지 않았습니다. 다양한 액세스 분류를 가진 문서의 전자 저장 및 처리는 (일반적으로 정당하게) 이를 구현하는 시스템에 다소 엄격한 요구 사항이 부과되기 때문에 훨씬 뒤처져 있습니다.

Directum 비즈니스 분석가인 Maxim Kainer는 EDMS/ECM을 구현할 때 자동화된 프로세스를 통해서만 종이 인쇄 비용을 절감할 수 있지만 조직 전체의 총 인쇄량이 증가할 수 있는 경우가 많다고 말합니다. 또한 ECM을 통해 특정 비즈니스 프로세스를 자동화하는 경우가 10% 미만이므로 이 프로세스 내에서도 문서 인쇄를 피할 수 있습니다. 일반적으로 그는 지금까지 조직이 종이 없는 문서 흐름으로 전환한다는 이야기는 없다고 생각합니다.

일반적으로 종이를 없애는 작업은 그 자체로 끝이 아니며 목표는 특정 비즈니스 프로세스를 최적화하고 구현 속도를 높이고 단순화하는 것이라고 Vadim Ipatov는 강조합니다. 그의 추정에 따르면 대부분의 고객 조직은 지원 문서(지침, 결의안, 실행 보고서 등)의 전체 범위를 포함하여 내부 전자 시스템을 완전히 구현했습니다. 그의 회사 고객 중 많은 정부 기관에서 공공 서비스 제공 및 시민 호소 작업이 대부분 자동화되었습니다. 요청이 전자 채널을 통해 수신된 경우 전적으로 전자적으로 처리됩니다. 조직, 행정 및 규제 문서 분야에서 "디지털화"는 상대적으로 99.9%에 도달할 수 있지만 적어도 단일 종이 사본의 명령, 명령 또는 규정이 여전히 필요합니다. 이는 전통과 규정 모두에 의해 결정됩니다. 입법 규범. 계약 작업을 할 때 상황은 비슷합니다. 준비 및 승인의 전체 과정은 전적으로 전자적으로 이루어지지만 당사자가 서명한 두 사본은 여전히 종이에 "살아 있습니다".

EDMS로의 전환에서 중요한 역할은 정확히 EDMS 사용자로서 조직의 IT 부서에서 수행됩니다. 이들은 내부 작업(사용자 요청 처리, 작업 및 작업 분배 측면에서 프로젝트 관리, 승인 등)에 이러한 도구를 사용합니다. , 그들은 자신의 예를 통해 어떻게 종이를 완전히 없앨 수 있는지 보여줍니다.

Dmitry Shmailov는 "종이 없는 기술로의 전환이 일반화되고 있으며 생산 요구에 의해 주도되고 있습니다. 종이 없이 작업하는 것이 수익성이 높습니다."라고 동의합니다. - BED는 기업 내부 문서 흐름과 매우 관련성이 높습니다. 오늘날 전자 문서가 점차 법적 지위를 획득함에 따라 상대방과 EDMS에서 작업하는 것이 일반화되고 있습니다.” 그러나 동시에 그는 특별 체제를 적용하는 조직에서는 국가 또는 상업 비밀을 구성하거나 특별한 가치가 있는 문서가 여전히 종이에 저장되어 있다고 지적합니다. 이러한 문서화를 위해 BED로 전환하는 것은 불가능하거나 최고 수준의 보안을 보장하는 것과 관련되어 있어 비용이 많이 들고 어렵고 종종 비용을 정당화하지 못합니다.

Ernest Kolesnikov에 따르면, 상대방과의 전자 문서 교환은 초기 단계에서 보다 성숙한 상태로 전환하는 단계를 겪고 있습니다. EDF 운영자는 처음에 문서 트래픽을 생성하는 대규모 기업을 유치하는 전술을 선택했으며 주요 비즈니스 부문에서는 전자 형식의 문서 교환이 보편화되고 있으며 다른 부문에서는 파일럿 프로젝트가 진행 중입니다. 이 프로세스는 규제 기관의 조치에 의해 크게 자극되고 때로는 시작되기도 합니다. 자동화의 일반적인 사례는 대부분의 문서가 전자 형식으로 변환되고 최대의 재정적 효과가 보장되는 전국에 영토 분포를 갖는 동일한 소유의 회사 그룹입니다. 동시에 전문가는 다음과 같은 중요한 점을 지적합니다. “회사에서 회계가 수행되는 방식에 따라 많은 것이 달라집니다. 모든 것이 법대로라면 투명성이 높아지는 것은 환영할 일이지만 상황이 반대라면 질서를 회복하는 도구로 작용하지만 이는 빠른 과정이 아니다”라고 말했다.

BED의 가장 확실한 적용 분야는 전자 배송 메모 및 송장으로의 전환입니다. 그러나 Artem Tanan은 규제 기관이 이러한 방향으로 신속하게 움직이려는 분명한 욕구를 보여주고 있음에도 불구하고 상당히 많은 개인적 어려움이 발생하고 있다고 지적합니다. 예를 들어, 전자 송장 교환으로의 전환은 과세 기간 마지막 날에 서비스가 제공되는 상황(통신, 인터넷, 유틸리티 등)과 전자 문서의 확인이 포함된 송장으로 인해 방해를 받았습니다. 관리 운영자는 이르면 다음 달 초에 데이트를 했습니다. 이 문제는 연방법 382-FZ를 채택하고 재무부의 후속 설명을 통해 매우 빠르게 해결되었습니다.

BED로 가는 길의 장애물

몇 년 전만 해도 이 질문에 대한 주된 대답은 '규제 및 입법 체계의 준비 부족'이라는 주제였지만, 이제 전문가들은 이 문제를 언급할 때 이를 우선순위에 두지 않습니다. Maxim Kainer는 "조직에서는 종이 문서에서 벗어나는 데 관심이 없습니다."라고 말합니다. - 종이 문서를 인쇄하고 작업하는 데 드는 비용은 그리 크지 않으므로 비용을 줄이는 것이 이점으로 간주됩니다. ECM 시스템은 종이 없는 문서 흐름으로 전환하기 위해 구현되는 것이 아니라 프로세스의 투명성과 가속화, 위험 감소 등과 같은 보다 구체적이고 명백한 다른 효과를 얻기 위해 구현되고 있습니다. 더욱이 때로는 프로세스를 전자 형식으로 변환하는 것이 단순히 의미가 없는 경우도 있습니다. 전자 서명 인증서의 가격이 상당히 높기 때문이기도 합니다.” 동시에 그는 또한 규제 프레임워크의 단점, 즉 다양한 공식의 모호함과 일반적인 자문 성격으로 인해 입증된 작업 패턴을 단순히 변경하고 싶지 않은 조직에 선택권이 남아 있다는 점도 지적했습니다. 동시에 그는 대부분의 기업에서 IT 인프라 수준의 변화가 필요하기 때문에 새로운 접근 방식을 급격하게 강요해서는 안 된다고 확신합니다.

입법 체계의 문제에 대해 말하면서 Elena Ivanova는 많은 규제 문제가 조직 자체의 책임이라는 사실에 주목합니다. “여러 면에서 경영진의 의지가 BED의 발전에 중요한 역할을 합니다.”라고 그녀는 확신합니다. - 관리자가 종이 없이 일하라고 하면 원하든 원하지 않든 모두가 그 일을 할 것입니다. 조직 경영진의 그러한 동기 부여 조치가 없다면 BEA의 경제적 타당성과 효과를 보지 못한다는 의미입니다. BED 구현 프로세스의 원동력 역할을 하고 관리자에게 모든 기쁨을 전달할 수 있는 인력이 부족하다는 문제도 있습니다.”

Dmitry Shmailov도 그녀의 의견에 동의합니다. “물론 BED 개발 측면에서 법안이 서방 국가에 비해 뒤떨어져 있다고 말할 수 있지만 법안 개정이 제공하는 기회조차 모든 사람이 활용하지 않는다는 것이 훨씬 더 중요합니다. 오히려 지연이 있습니다. 많은 BED 기술은 소수의 조직에서만 사용됩니다. 고객의 경우 전자 회계 주제가 개발 및 심화되고 회계 문서를 전자 형식으로 처리 및 저장하기 위한 통합 모델이 구축되는 추세를 확인했습니다. BED로의 완전한 전환은 전자 서명을 위한 단일 신뢰 공간이 부족하기 때문에 크게 제한됩니다. 또한, 경우에 따라 전자 문서의 저장 및 사용이 불가능해지는 정보 보호 요구 사항도 잊지 마세요. 글쎄요, 자금조달은 여전히 중요한 요소입니다.”

Ernest Kolesnikov는 잘 알려진 말을 의역하여 러시아 전자 문서 관리의 두 가지 주요 문제인 법률과 사람을 언급합니다. “법률에는 공백이 있습니다. 예를 들어 형식은 소수의 문서에 대해서만 승인되었고 다른 유형에 대한 작업은 현재 진행 중입니다. 머지않아 보편적인 양도서류 형식이 승인될 예정인데, 어떤 서류든 붙일 수 있는 만능용기에 대한 이야기도 나오고 있다. 비정형 문서를 사용하는 사법 관행만으로는 모든 기업이 두려움 없이 EDI로 전환할 수 있기에는 아직 충분하지 않지만 시간이 흐르고 상황은 더 좋게 변화하고 있습니다. 두 번째 주요 문제는 사람과 삶의 지배적인 현실입니다. 우리는 종종 고객의 의견을 듣습니다. 고객이 강요할 경우에만 종이를 거부할 것입니다."

기존 프로세스의 프레임워크 내에서 새로운 기술을 도입하려면 주로 인력 재교육과 혁신을 적용하려는 회사 경영진의 욕구가 필요하지만 프로세스는 본질적으로 동일하게 유지된다고 Artem Tanan은 말합니다. 그는 구체적인 조언을 제공합니다. BED를 구현하려면 책임자를 임명하고 세 가지 주요 작업을 수행해야 합니다. 문서 작업을 위한 새로운 절차를 구축하고, 직원을 교육하고, 선택한 상대방에 대해 이전 절차를 포기하는 기한을 결정합니다. 문서 작업을 위한 새로운 절차를 간단하고 이해하기 쉽게 만들고 기존 절차와 최소한의 차이를 가지려면 BED와 회계, 관리 및 EDMS 프로그램의 통합을 지원해야 하며 더 나아가 BED를 만드는 것이 필요합니다. 그들 중 필수적인 부분입니다. 별개의, 아마도 가장 문제가 되는 블록은 상대방을 포함시키는 문제입니다. BED 고객의 상대방을 연결하는 것뿐만 아니라 문서 작업을 위한 새로운 절차로 전환하는 데도 도움이 필요합니다. 그렇지 않으면 BED를 사용해도 구매 및 판매 장부의 정보에 오류와 불일치가 남아 있으며 기타 부정적인 결과가 발생합니다. 전문가는 향후 몇 년 동안 BED를 다른 비즈니스 시스템과 통합하고 계약자를 참여시키는 문제가 우리나라의 BED 기술 보급 측면에서 중요한 역할을 할 것이라고 확신합니다.

무엇을 해야 할까요?

Elena Ivanova는 “현재 러시아에서는 공공 부문이든 상업 부문이든 종이를 완전히 버리는 것은 불가능합니다.”라고 말합니다. - 우선, 조직의 BED 전환을 유도할 수 있는 입법적 틀 마련이 필요하다. 부분적으로 이것은 이제 SMEV M의 개선과 관련하여 정부 기관에서 나타나기 시작했습니다.” 그녀는 많은 부분이 EDMS 공급업체에 달려 있다고 믿습니다. BED로의 전환에 따른 경제적 효과를 정당화하고 기술적 솔루션을 제공할 수 있습니다. EDMS/ECM 영역의 표준화와 관련된 전문 커뮤니티 및 조직에서 일하고 주 규제 기관과 상호 작용하는 것도 중요합니다.

또한 EDMS 공급업체 자체가 BED로의 전환에 대한 모범을 보여야 한다고 Dmitry Shmailov는 확신합니다. 이들 기업 역시 업무 효율성을 높이기 위해 전자문서 관리가 필요합니다. 고객이 부족한 상황에서 성공 요인은 자신의 비즈니스에서 BED 기술을 테스트할 수 있습니다. EDMS 공급업체는 고객의 개별 요구 사항과 특성을 충족하고 고려하는 최신 개발을 제공함으로써 기술 개발 측면에서 큰 도움이 될 것입니다.

Maxim Kainer는 또한 BED로의 전환에 대한 경제적 타당성에 대해 다음과 같이 말합니다. “종이 없는 문서 흐름으로의 전환을 위해서는 IT 솔루션 구현이 종이 미디어 지원 작업(장비 구입 및 유지 관리, 소모품, 운송 및 배달 비용, 보관 및 검색 비용). 세계 전문가들은 절반 이상의 사례에서 특정 ECM 솔루션에 대한 투자 회수 기간이 1년 반 이하라고 말합니다.” 이 프로세스에서 공급업체의 실제 참여는 "종이 없이 작업하는 것이 가능하고 수익성이 있다"는 아이디어를 홍보하고, 입법 프로세스에 참여하고, 클라우드 모델 및 SaaS 사용을 포함한 솔루션 비용을 절감하는 것으로 구성될 수 있습니다.

BED에 극복할 수 없는 장벽은 없지만 해결될 수 있고 해결해야 하는 문제가 있다고 Ernest Kolesnikov는 말합니다. 확실히 긍정적인 점은 정부 당국이 국가 자동화에 막대한 투자를 하고 있다는 점이다. 지난 10년 동안 생활과 일이 훨씬 더 즐거워졌다고 할 수 있다. 문제가 있지만 규제 기관, 개발자, 고객의 공동 노력을 통해 식별되고 해결됩니다. “어느 시점이 되면 사회의 정보량이 충분한 양에 도달할 것이며 종이에 문서를 옛날 방식으로 표시하는 것은 과거의 일이라는 것을 모든 사람이 이해할 것입니다.”라고 그는 확신합니다. “이제는 우리가 인터넷 없이 어떻게 살았는지 상상하기 힘들지만, 전자 문서 처리를 하면 상황은 똑같을 것이라고 생각합니다.”

Artem Tanan은 "우리는 기업이 더 이상 종이 흐름에 대처할 수 없고 규제 기관의 요구 사항을 충족하지 못하는 "마지막 요청"을 기다리지 말 것을 권장합니다."라고 조언합니다. - 어떤 유형의 거래/문서와 BED를 사용할 상대방을 지금 결정한 다음 책임자를 지정하고 마감일을 설정해야 합니다. 필요한 경우 해당 분야에서 충분한 역량을 갖춘 전문가를 참여시켜 할당된 작업의 고품질 구현을 보장합니다. 방법론적 또는 기술적 성격의 어려움이 발생하는 경우 BED 문제에 대한 실무 그룹에서 전문 플랫폼에 대한 토론을 위해 문제를 제기하십시오. 단일 기업에서 BED로 전환할 때 구체적인 업무를 설정해야만 다른 시장 참여자들도 이해할 수 있는 성공적인 경험을 얻을 수 있다. SF 운영자, 소프트웨어 벤더 및 파트너 네트워크와 함께 대기업이 이러한 경험을 복제하는 것이 BED 기술을 시장에 배포하는 가장 효과적인 방법입니다.”

우리는 이미 많이 해왔던 일을 계속합니다.

Chernomyrdin V.S.

얼마 전 한 고객이 잘 알려진 문제로 다시 한 번 저에게 접근했습니다. 그의 회사는 1C 업데이트를 설치했습니다. 그리고 프로그램이 제대로 작동하지 않아 작업이 중단되었습니다. 프로그래머나 사용자로서 1C의 소프트웨어 제품을 접한 사람이라면 누구나 이 상황에 매우 익숙하다고 생각합니다.

물론 이번 경우에는 가능한 한 빨리 모든 문제를 해결하려고 노력했고 그 결과 사무가 정상으로 돌아 왔습니다. 하지만 이런 상황에서도 의뢰인으로부터 많은 부정적인 평가를 받았습니다. 그런 다음 1C 소프트웨어 제품에서 왜 그렇게 많은 문제가 지속적으로 발생하는지, 왜 클라이언트로부터 부정적인 반응이 그렇게 많은지, 다른 프로그래머를 포함하여 1C 프로그래머 자신이 종종 싫어하는 이유에 대해 생각했습니다.

이 기사에서 나는 그러한 부정적인 결과를 초래하는 이유에 대한 내 버전을 제공하기로 결정했습니다. 가능한 한 많은 독자가 텍스트를 이해할 수 있도록 특정 용어를 가능한 한 적게 사용하려고 노력할 것입니다.

동시에 나 자신은 한동안 1C 프로그래밍에만 전념했고 오늘은 1C의 소프트웨어 제품을 업무에 매우 적극적으로 사용하고 있으며 다음을 포함하여 돈을 벌 수 있는 기회를 주신 이 회사에 매우 감사합니다. 나.

하지만 한편으로는 부정적인 이유도 이해해야 한다고 생각합니다. 적어도 모든 것을 직관과 감정의 수준에 두지 않기 위해서입니다.

1C는 어떻게 시작됐나요? 기억하자!

개인적으로 저는 버전 6.0부터 1C 소프트웨어로 작업을 시작했습니다. 제 생각에는 이 프로그램이 Excel 스프레드시트에 보관된 다양한 회계 옵션보다 조금 더 복잡했습니다.

가장 성공적인 릴리스인 1C 7.7을 포함하여 7번째 버전으로 대체되었습니다. 그것은 이미 상당히 강력한 소프트웨어 제품이었으며 소련 이후 공간 전체에 널리 퍼졌습니다. 이때까지 대부분의 사용자는 1C 작업에 너무 익숙해서 이러한 프로그램을 사용할 수 있는 능력이 회계사, 다양한 사무실 직원, 관리자, 점주 등을 고용하기 위한 조건 중 하나가 되었습니다.

원칙적으로 1C 7.7은 다양한 유형의 회계와 관련된 문제를 성공적으로 해결했습니다. 더욱이, 이 소프트웨어 제품은 여전히 일부 경우에 사용되며 이는 인기를 나타냅니다.

이제 이 소프트웨어는 광범위한 기능과 동시에 시스템의 복잡성에 놀랐습니다.

오늘날 1C 회사는 고객에게 전체 생태계를 제공합니다.

개발자를 위한 강력한 플랫폼.
다양한 유형의 회계 및 분석을 유지하기 위한 환경
다양한 상용 장비 연결 가능
가장 광범위한 파트너 네트워크
웹사이트 제작을 위한 다기능 CMS

동시에, 함께 또는 개별적으로 이 생태계의 모든 구성 요소가 최상의 방식으로 기능하지 않습니다. 종종 문제가 발생하고 작업 실패, 추가 시간과 돈이 필요하며 이는 물론 거절을 초래합니다.

1C 업데이트: 작동 방식

오늘날 1C 제품군의 소프트웨어 제품이 어떻게 작동하는지 간략하게 상기시켜 드리고 싶습니다. 대부분의 경우 사용자는 플랫폼과 이 플랫폼에 작성된 애플리케이션(소위 구성)으로 구성된 하나 이상의 소프트웨어 제품을 구매합니다.

다음으로, 프로그래머는 선택한 구성의 작동을 특정 회사의 요구에 맞게 조정하고, 종종 추가 플러그인을 설치하고, 특정 보고서를 수정하고, 이 회사의 내부 문서 흐름에 참여하는 새 문서를 생성합니다.

동시에 플랫폼과 모든 구성 모두에서 개발자의 버그가 상당히 많습니다. 그리고 시스템 자체가 너무 복잡하고 방대해서 1C 프로그래머의 도움으로 이러한 버그를 수정하는 것은 매우 어렵고 가장 중요한 것은 최종 사용자에게 수익성이 없다는 것입니다. 더욱이 플랫폼과 구성 자체는 모듈성이 부족하다는 점에서 불쾌한 품질로 구별됩니다.

따라서 버그를 수정하려면 업데이트를 설치해야 합니다. 이 경우 전체 플랫폼 및/또는 구성이 매번 업데이트됩니다. 당연히 이러한 솔루션에는 많은 시간이 걸리며 구성에 대해 이야기하는 경우 프로그래머가 수행한 설정, 추가 플러그인 및 기타 수정 작업을 다시 수행해야 할 가능성이 높습니다.

그러나 이것은 1C 업데이트 상황에서 가장 슬픈 일이 아닙니다. 가장 슬픈 점은 개발자 웹사이트에 업데이트가 매우 자주, 때로는 한 달에 3~4번 출시된다는 점입니다. 어떤 경우에는 중요하지 않은 오류가 수정되고 다른 경우에는 전체 시스템 작동과 관련된 심각한 버그가 수정됩니다.

각각의 새 버전은 이전 버전의 버그에 대한 기능 및 일종의 "패치"를 추가하여 오래된 오류를 수정하지만 거의 항상 새로운 오류를 도입합니다. 따라서 업데이트 설치는 대부분 예측할 수 없는 프로세스입니다.

모듈성 부족: 왜 그렇게 중요한가요?

먼저 플랫폼에 대해 직접 이야기 해 봅시다. 1C 프로그래머는 이것이 얼마나 번거로운지 알고 있습니다. 위에서는 모듈성이 부족하다는 점에 대해 이미 썼습니다. 제품 코드에는 소위 하위 시스템이 포함되어 있지만 모듈성 요구 사항을 충족하지 않으므로 단순히 코드를 구조화하려는 일종의 시도일 뿐입니다.

개인적으로 모듈성 부족이 문제라고 생각하는 이유는 무엇입니까? 예를 들어 이해해 봅시다. 무역 관리의 성공적인 운영을 위해 필요한 일부 기능을 개선하거나 잔고 저장 수단을 변경해야 한다고 가정해 보겠습니다. 그러나 1C 플랫폼에서는 모든 것이 서로 연결되어 있으므로 급여, 회계 등을 작업하려면 업데이트를 끌어야 합니다. 등등.

모듈성이 없으면 아주 작은 변화라도 적용하려면 전체 어레이, 전체 플랫폼을 연구해야 합니다.

동시에 1C 플랫폼은 매우 크고 번거롭습니다. 오늘날에는 너무 많은 내용이 포함되어 있어 처음에는 풍부한 가능성 때문에 감탄을 불러일으키기도 합니다. 하지만 이 플랫폼을 사용하면 감탄은 금방 사라집니다. 1C 개발자는 프로그램을 보편적으로 만들기 위해 플랫폼에 다양한 기능을 추가했습니다.

이제 강력한 도구, 편리한 시각적 인터페이스 및... 시스템의 복잡성으로 인해 많은 문제와 버그가 발생합니다.

또 다른 예를 들어보겠습니다. 내 작업에는 무역만 필요하다고 가정해 보겠습니다. 회사는 모바일 인터페이스, 회계, 온라인 상점, 기타 구성 요소 등 다른 어떤 것도 사용하지 않습니다. 하지만 무슨 일이 있어도 업데이트를 받으면 사용하지 않는 구성 요소의 작동에 필요한 기능을 포함하여 전체 플랫폼을 받게 됩니다. 저것들. Commerce를 사용하고 업데이트가 회계와 함께 작동하도록 설계되었음에도 불구하고 전체 플랫폼을 다운로드하여 설치해야 합니다.

라이센스 정책 및 시스템 버그

플랫폼을 업데이트할 때 사용자는 라이센스 키가 작동하지 않는다는 사실에 직면하는 경우가 많습니다. 개인적으로 이러한 상황이 발생하지 않은 경우 검색 엔진에 "업데이트 후 1C 작동이 중지되었습니다"를 입력하면 이 문제가 얼마나 널리 퍼져 있는지 확인할 수 있습니다.

상황을 상상해보십시오. 예를 들어 직원이 30명인 회사가 있습니다. 업데이트 후 프로그램이 라이센스 키 수락을 중단했습니다. 회사의 업무가 마비되었습니다. 회사는 손실을 입습니다.

중요한 문제는 업데이트 시 플랫폼 동작을 예측할 수 없다는 점입니다.

라이센스가 자주 실패한다는 사실 외에도 플랫폼을 업데이트한 후에는 제대로 작동하지 않을 수 있는 새로운 기능이 포함될 수도 있습니다. 그러나 실제로는 새 버전의 프로그램에서만 작업 품질을 확인하고 새로운 버그를 식별할 수 있습니다. 진행중.

플랫폼은 매우 크고 번거롭기 때문에 단시간에 프로그래머와 함께 테스트하는 것은 비현실적이라는 점을 상기시켜 드리겠습니다. 그리고 각 업데이트마다 이 모든 것을 고려해야 합니다.

따라서 프로그래머의 상황은 다음과 같습니다.

업데이트할 때마다 플랫폼이 완전히 업데이트되고, 앞으로 사용하지 않을 도구를 제거하거나 설치하지 않을 방법이 없기 때문에 혼란이 많이 발생합니다.
그럼에도 불구하고 업데이트는 필요합니다. 이는 프로그래머가 알려졌거나 아직 식별하지 못한 현재 버그를 "치료"할 수 있는 유일한 기회이기 때문입니다.
게다가 새 업데이트에는 일반적으로 다음 버전에서 수정될 새로운 버그가 포함되어 있습니다.

따라서 원은 닫힙니다. 그리고 프로그래머는 새로운 문제가 발생함에도 불구하고 계속해서 새로운 버전을 설치해야 합니다.

버그가 왜 이렇게 많나요?

내 의견으로는 버그가 많은 주된 이유는 시스템의 복잡성 때문입니다. 이제 1C 플랫폼은 Windows 32 및 64비트, Linux, 서버 버전, 모바일 등에서 사용할 수 있습니다. 유지 관리의 복잡성은 매우 높으며 실습에서 알 수 있듯이 1C 개발자는 유지 관리에 대처할 수 없습니다.

모듈성이 부족하기 때문에 모든 오류를 식별하고 이러한 번거로운 소프트웨어 제품을 디버깅하는 것이 사실상 불가능하기 때문에 추가적인 어려움도 발생합니다. 결과적으로 새로운 업데이트가 지속적으로 출시되고 있습니다.

버그가 끊임없이 존재하고 그 상황이 발생하는 또 다른 매우 중요한 이유는 경쟁이 부족하기 때문입니다. 실제로 1C는 이제 독점 기업입니다.

물론 대체 소프트웨어 제품이 만들어지고 있으며 그 중 일부는 꽤 괜찮습니다. 그러나 지금까지는 모두 특정 문제를 해결할 수 있는 적용된 솔루션인 반면 1C는 전체 생태계입니다.

또한 1C 회사는 매우 강력하고 공격적인 마케팅으로 구별되며 모두가 이 소프트웨어에 대해 알고 있습니다.

그렇기 때문에 오늘날 1C는 소비에트 이후 공간에서 합당한 경쟁자가 없다고 주장합니다. 그리고 경쟁이 부족하면 항상 제품 자체의 품질이 저하됩니다. 1C의 예에서 볼 수 있듯이 지속적인 "원시"업데이트, 지속적인 버그, 업데이트에 대한 자세한 문서 부족 등이 있습니다.
따라서 저는 개인적으로 모든 고객에게 꼭 필요한 경우가 아니면 업데이트하지 말라고 조언합니다. 그건 그렇고, 나도 1C의 기원에 있었던 사람들 중 한 사람으로부터 같은 조언을 받았습니다.

물론 현재 버전에는 확실히 몇 가지 버그가 있지만 문제 없이 작업한다면 이러한 버그는 그다지 중요하지 않습니다. 새 버전에서는 어떤 일이 일어날지 예측하는 것은 불가능합니다. 따라서 업데이트는 업무에 꼭 필요한 경우에만 설치해야 합니다.

주력. 일반적인 구성

1C 소프트웨어 제품 라인은 표준 구성을 기반으로 합니다. 1C 웹 사이트에는 기성품 박스형 솔루션이 많이 있습니다.

그러나 대부분의 사용자는 다음 4가지 구성만 사용합니다.

기업회계
무역관리
제조공장 관리
급여 및 인사 관리

그리고 각 구성에는 플랫폼과 동일한 단점이 있습니다.

모듈성 부족
부피가 크고 불필요한 기능이 많음
새 버전의 새로운 버그
예측할 수 없는 업데이트 결과

또한 각 업데이트마다 정확히 무엇이 업데이트되었는지 분석하고 업데이트 자체를 수행하며 구성을 재구성해야 합니다. 그러나 구성 업데이트도 너무 자주 나타나서 이해하는 것이 문제가 됩니다.

게다가 모듈성이 부족하기 때문에 사용하지 않는 기능에 변경사항이 영향을 주더라도 업데이트를 해야 하는 경우가 많습니다. 이 기능의 오류로 인해 다른 모듈이 제대로 작동하지 않을 수 있기 때문입니다.

Trade에 대해 이야기하면 실제로 사람들이 이 구성 요소 전체 기능의 30% 이하를 사용하는 것으로 나타났습니다. 상황은 다른 일반적인 구성에서도 유사합니다. 최대한 많은 기능을 구현하기 위해 개발자는 모든 것이 상호 연결되는 매우 번거롭고 복잡한 제품을 만들었으므로 불필요한 기능을 비활성화하는 것조차 항상 가능한 것은 아닙니다.

예를 들어 Trade를 업데이트할 때 개발자는 새로운 보너스 시스템을 추가했습니다. 클라이언트는 보너스를 전혀 사용하지 않습니다. 그는 그것들이 필요하지 않습니다. 그러나 이러한 보너스를 비활성화하려고 하면 할인 시스템이 잘못 작동하기 시작합니다. 실제로 이런 상황에 직면했습니다. 물론 이 문제를 해결하려면 프로그래머의 도움이 필요했습니다.

최근 저는 프로젝트를 완료한 후에는 모든 고객에게 업데이트를 전혀 하지 말 것을 권고한다는 결론에 도달했습니다. 저는 업무에 필요한 모든 것을 구성했고 고객 및 그의 직원과 함께 구성을 테스트하고 모든 것이 잘 작동하는지 확인했습니다. 따라서 주요 변경 사항이 발생할 때까지 구성을 업데이트할 필요가 없습니다.

공격적인 마케팅과 그 결과

내 고객은 내 조언에 반하여 업데이트를 설치하는 경우가 많습니다. 왜 이런 일이 발생합니까?

프로그래머 동기부여

1C 프로그래머는 클라이언트가 가능한 한 자주 소프트웨어를 업데이트하는 데 관심이 있습니다. 그것은 단순히 그들에게 유익합니다. 업데이트할 때마다 구성을 다시 구성해야 합니다. 따라서 업데이트의 도움으로 말 그대로 허공에서 수입을 얻습니다.

회사가 업데이트 없이 일부 구성에서 조용하고 안정적으로 운영되는 상황을 상상해 보십시오. 그러나 예를 들어 다른 보고서를 생성하거나 추가 처리를 설치해야 하는 경우가 있었습니다. 당연히 이 경우 전문가에게 문의합니다.

다음에는 어떻게 되나요? 1C 프로그래머가 와서 프로그램이 오랫동안 업데이트되지 않은 것을 확인했습니다. 그는 고객에게 이것이 얼마나 나쁜지 말하고 업데이트 없이는 고객이 필요로 하는 보고서를 설정하거나 다른 작업을 수행할 수 없다고 설명하고 이전 버전에 있는 많은 오류 등으로 그를 놀라게 합니다. 등등. 일반적으로 클라이언트가 업데이트를 구입하고 설치하도록 설득합니다.

실제로 대부분의 경우 업데이트가 객관적으로 필요하지 않습니다. 그러나 프로그래머가 수행하는 작업량에 따라 수수료도 크게 늘어납니다. 그건 그렇고, 이것이 많은 사용자가 1C 프로그래머에 대해 부정적인 태도를 갖는 이유입니다. 그들의 관점에서 볼 때 그들은 작업을 시작하기 전에 완벽하게 작동했던 작업에 대해 프로그래머에게 금액의 90%를 지불합니다. 동일한 기능에 대해 여러 번 비용을 지불해야 합니다.

1C의 공격적인 마케팅

1C 회사 자체도 사용자가 가능한 한 자주 업데이트되도록 하는 데 관심이 있습니다. 결과적으로 사용자는 새로운 업데이트에 대한 미리 알림, 플랫폼 또는 구성 업데이트 필요성에 대한 경고를 자주 받습니다. 그러나 동시에 사이트에는 업데이트 시 사용자가 받게 될 내용, 수정된 버그, 나타나는 기능에 대한 자세한 정보가 충분하지 않습니다. 저것들. 특정 업데이트 설치 필요성을 객관적으로 평가하는 것은 불가능합니다. 결과적으로 많은 사용자가 안전을 위해 업데이트합니다.

서비스 및 프랜차이즈의 단점

1C 회사에는 고객 서비스가 거의 없다고 생각합니다. 이 회사는 영업 부문에서 탁월한 성과를 거두고 있으며 매우 공격적이고 효과적인 마케팅 정책을 갖추고 있습니다. 하지만 유지관리가 필요하다면 많은 어려움에 직면하게 될 것입니다.

1C 웹 사이트에는 1C 소프트웨어 제품에 대한 유지 관리 서비스를 제공하는 해당 지역의 인증 파트너를 찾을 수 있는 전체 섹션이 있습니다. 이들 파트너는 인증을 받았으며 제휴 수수료를 지불합니다. 모든 것이 정상인 것 같습니다.

그러나 실제로 1C 회사는 실제로 파트너와 협력하지 않습니다.

회사가 파트너 자격을 얻으려면 직원 중에 인증된 전문가가 있으면 충분합니다.
그 후에는 누구도 반복적인 점검이나 시험을 실시하지 않습니다. 따라서 인증된 프로그래머가 유일한 전문가일 수 있으며 완전히 다른 사람들이 귀하를 섬기러 올 수도 있고 완전히 그만둘 수도 있지만 회사는 파트너 자격을 잃지 않습니다.
1C는 실제로 파트너와 협력하지 않고 교육을 제공하지 않으며 작업 품질을 통제하지 않습니다.

그러한 정책의 결과는 많은 사람들에게 알려져 있습니다. 1C 파트너 목록에 특정 회사가 있다고 해서 고품질 서비스가 보장되는 것은 아닙니다.

나는 이미 1C가 전체 생태계라고 언급했습니다. 어떤 면에서는 애플과도 비교할 수 있다. 하드웨어, 소프트웨어 및 리셀러로 구성된 전체 시스템이 구축되어 있습니다. 1C에는 플랫폼도 있고 구성도 있으며 인증된 리셀러도 있습니다.

그러나 Apple이 생산부터 파트너 작업까지 모든 단계에서 품질을 매우 엄격하게 통제하고 최고 품질이 이 브랜드의 중요한 경쟁 우위 중 하나라면 1C 회사에서는 모든 것이 완전히 다릅니다. 여기에는 서비스가 거의 없으며 파트너의 작업을 통제하는 사람이 없기 때문에 소프트웨어를 사용한 판매 후 작업 품질이 매우 낮습니다.

1C 회사가 주로 제품 소비자에게 마케팅 노력을 기울이는 것도 흥미 롭습니다. 사용자에. 그리고 구성 작업은 전적으로 프로그래머에게 초점이 맞춰져 있습니다. 결과적으로 한 가지가 광고되지만 실제로는 구매자가 완전히 다른 것을받은 것으로 나타났습니다.

그리고 여기에 1C 프로그래머와 소프트웨어 제품 자체에 대한 부정적인 이유도 나타납니다.
1C로만 일하던 것을 그만두고 비즈니스 컨설팅을 시작하면서 업무에 다양한 소프트웨어 제품을 사용하기 시작했습니다. 이들은 Drupal의 사이트와 ZOHO CRM, ATOL RMK, Redmine 및 기타 여러 시스템과 같은 시스템이었습니다. 그리고 거의 모든 서비스와 프로그램에는 지속적이고 빈번한 업데이트가 필요하지 않습니다. 그리고 업데이트할 때 문제가 그리 많지 않습니다.

1C 회사는 판매와 지속적인 업데이트라는 두 가지 방향으로 수익을 창출합니다. 하지만 클라이언트가 그것과 무슨 관련이 있습니까? 다른 선택의 여지가 없기 때문에 그는 비용을 지불하고 업그레이드해야 합니다. 게다가 기업에서 사용하는 모든 제품은 동시에 업데이트되어야 합니다.

예를 들어, Trade를 사용하는 경우 귀하와 관련된 일부 버그를 수정하는 정말 유용한 업데이트가 출시되었습니다. 회계도 업데이트해야 합니다. 왜냐하면 동일한 구성 버전 간에만 데이터 교환이 가능하기 때문입니다. 업데이트하지 않고 회계를 종료하기로 결정한 경우 무역에서 회계로 문서를 업로드하는 것이 더 이상 작동하지 않습니다.

결과적으로 고객은 지속적으로 고장이 나고 이를 복원하기 위해 정기적으로 비용을 지불하는 시스템을 사용해야 합니다. 물론 고객은 부정적이 됩니다. 그러나 그는 다른 소프트웨어 제품으로 전환할 수 없으며 단순히 가치 있는 대안을 찾지 못합니다.

예, 우리나라에는 다른 회계 시스템이 있으며 그 중 일부는 기능 측면에서 점차적으로 1C를 따라잡고 있습니다. 하지만 마케팅은 정말 좋은 일이에요! 따라서 고객은 대안을 찾지 못하고 지속적인 부정적인 태도에도 불구하고 추가 비용을 지불합니다.

1C: Bitrix - 어려움, 기능, 마케팅

전통적으로 1C 라인의 일부로 분류되는 또 다른 제품은 1C-Bitrix 웹 사이트 관리 시스템입니다. 동시에 많은 사용자는 Bitrix를 구매하는 것으로 충분하며 사이트와 데이터를 1C에 통합하는 모든 문제가 해결될 것이라고 확신합니다.

1C 소프트웨어 제품을 구매하고 1C-Bitrix에서 웹 사이트를 주문하는 사용자는 공통 브랜드를 보고 이러한 제품이 항상 문제 없이 함께 작동하는 동일한 라인의 제품이라고 확신합니다.
실제로 CMS Bitrix는 1C 회사와 아무런 관련이없는 전문가가 개발 한 별도의 제품입니다. 나중에 이 CMS에 1C 라인 제품과의 통합 도구가 추가되었고 "1C-Bitrix"라는 새로운 이름이 나타났습니다. 이는 1C 회사가 Bitrix의 대규모 지분을 구입하고 이 CMS를 소프트웨어와 함께 사용하기로 결정했기 때문에 발생했습니다.

결과는 어땠나요?

온라인 상점 데이터베이스와 1C 소프트웨어 제품의 통합이 실제로 제공됩니다. 그러나 이는 매우 복잡하고 전문가의 도움 없이는 데이터 교환을 설정하는 것이 거의 불가능하며 변경하기가 매우 어렵습니다.

또한 1C를 설정한 프로그래머는 Bitrix를 설치하고 구성할 수 없습니다. 여기에는 Bitrix 전문가인 웹 프로그래머가 필요합니다. 통합은 부분적으로 1C 프로그래머, 부분적으로 Bitrix 전문가에 의해 구성됩니다. 그리고 사용자가 누구에게 연락해야 할지 전혀 모르는 경우도 있습니다.

예를 들어 이런 상황이 있었습니다. 최신 업데이트 이후 고객과 사이트의 데이터 교환이 중단되었습니다. 나는 1C 전문가에게 문의했지만 그는 우리를 도울 수 없었습니다. 그의 의견으로는 문제가 Bitrix 측에 있었기 때문입니다. 우리는 Bitrix 프로그래머를 찾았습니다. 그는 또한 손을 내밀고 문제는 여전히 1C쪽에 있다고 말했습니다. 해당 사이트와의 데이터 교환이 약 2주 동안 이루어지지 않았습니다. 클라이언트는 웹사이트에서 가격과 잔액을 수동으로 다운로드하고 주문을 언로드해야 했습니다. 결국 우리는 운이 좋았습니다. 나는 Bitrix와 1C를 모두 아는 프로그래머에게 연락했고 그는 교환 모듈을 설정했습니다.

Bitrix 및 1C: 서로 다른 시스템, 일반적인 단점

최신 버전의 Bitrix에 익숙한 웹 개발자라면 이제 저를 이해하실 것입니다. 1C 소프트웨어 제품과 마찬가지로 최신 버전의 Bitrix는 광범위한 기능을 갖춘 매우 강력하지만 동시에 불필요하게 복잡해졌습니다. 오늘날 Bitrix의 관리자(웹 프로그래머)의 도움 없이는 사용자가 제품 카탈로그에 새 카테고리를 설정할 수도 없는 경우가 많습니다. 지능형 검색을 구성하려면 각 제품 유형에 대해 고유한 매개변수를 설정해야 하기 때문입니다.

동시에 웹 사이트와 1C 프로그램을 유지하려면 다양한 전문가가 필요합니다. 결국 이들은 다른 제품입니다. 이들은 서로 다른 목적으로 사용되고, 서로 다른 플랫폼을 갖고 있으며, 이를 사용하려면 다양한 기술에 대한 지식이 필요합니다.

이력서 대신

그럼 요약해 보겠습니다. 1C 라인의 소프트웨어 제품은 다음과 같은 이유로 전문가들 사이에서 부정적인 영향을 미칩니다.

높은 시스템 복잡성
모듈성 부족
모든 업데이트의 버그
업데이트에 대한 자세한 문서가 부족합니다.
업데이트 설치의 예측할 수 없는 결과

이 모든 것은 플랫폼과 1C 구성 모두에 적용됩니다.

사용자의 부정적인 반응은 다음과 같은 이유로 인해 발생합니다.

업데이트 설치로 인해 예측할 수 없는 결과가 발생합니다. 프로그램은 언제든지 작동을 멈출 수 있습니다. 다만, 이전 버전의 버그로 인해 업데이트가 필요합니다.
1C 회사와 프로그래머 모두 업데이트 비용을 지불해야 합니다. 동시에 사용자에게 보이는 이점은 대부분의 경우 미미하며 새 버전을 설치한 후 프로그램 기능을 복원하는 데 드는 비용의 대부분을 지불해야 합니다.

1C 프로그래머에 대한 부정적인 점도 분명해졌습니다.

사용자는 프로그램에 대한 부정적인 생각을 전문가에게 전달합니다. 결국 업데이트 설치 및 구성 설정에 대한 비용을 지불받는 것은 1C 프로그래머입니다.
다른 분야에서 일하는 프로그래머는 1C를 전문으로 하는 동료가 본질적으로 "공기 판매"에 대한 대가로 돈을 받는 경우가 많다는 것을 이해합니다. 이는 전문가가 직접 클라이언트에 업데이트를 적용할 때 특히 두드러집니다.
1C의 통제력 부족으로 인해 임의의 사람들이 소프트웨어 제품 서비스에 참여하고 있으며 이는 긍정적인 이미지에 기여하지 않습니다.

제가 개인적으로 내린 결론은 이렇습니다. 아마도 내가 뭔가에 대해 전적으로 옳지 않을 수도 있고, 뭔가를 놓쳤을 수도 있습니다. 어쨌든 나는 비판을 위해서가 아니라 고객이 1C 라인 프로그램과 1C 프로그래머에 대해 부정적인 태도를 가질 수 있는 이유를 이해하기 위해 이 기사를 쓰기로 결정했습니다.

태그: 태그 추가