1s 7.7에서 8.3으로 로딩 중입니다. 이전 기간의 문서 이전을 통해 표준 구성에서 전환

작동 원리.

데이터가 전송되는 방법에 대한 몇 마디 일반적인 구성 « 회계", 1C:Enterprise 7.7용 에디션 4.5 또는 구성 ""(이하 소스 구성이라고 함)을 표준 구성으로 " 기업회계", 1C:Enterprise 8용 버전 3.0(버전 3.0.52), 이하에서는 "수신기 구성"이라고 합니다.

중요한! 구성에서 데이터 전송이 가능합니다. 회계 1C:Enterprise 7.7 버전 7.70.569 이상용 버전 4.5 또는 구성 " 단순화된 과세 시스템, ed. 1.3"버전 7.70.219 이상.

이전 기간의 규제 작업을 완료한 후 새 기간(연도, 분기, 월)이 시작될 때 소스 구성에서 대상 구성으로 전환하는 것이 좋습니다.

데이터 전송은 소스 구성 정보 베이스의 데이터를 XML 형식의 파일로 다운로드하는 특수 처리를 통해 수행됩니다. 결과 파일은 범용 데이터 로딩 처리를 사용하여 수신자 구성 정보 베이스에 로드됩니다.

데이터를 전송하려면 다음 파일이 필요합니다.

ACC_ACC8 .ert - 외부 처리 데이터 업로드구성에서 외부 파일로 " 회계, 개정판 4.5»;

USN_ACC8 .ert - 구성에서 외부 파일로 데이터를 업로드하는 외부 처리 " 단순화된 과세 시스템, ed. 1.3»;

ACC_ACC8 .xml - 데이터 변환 규칙.

USN_ACC8 .xml - 데이터 변환 규칙.

전송 가능한 데이터.

다음은 소스 구성 정보 베이스에서 수신자 구성으로 전송됩니다.

참고 도서의 요소;

정보베이스 전환일 현재 구성 소스 정보베이스의 회계 계정 현재 잔액에 대한 정보

정보베이스 변환 날짜보다 이후 날짜의 현재 문서입니다.

변환은 두 단계로 수행됩니다.

소스 구성 정보 베이스의 데이터는 다음 위치에 업로드됩니다. 별도의 파일(데이터 파일);

결과 파일은 수신자 구성 정보 베이스에 로드됩니다.

설치.

데이터 마이그레이션 처리를 설치하려면 setup.exe 설치 프로그램을 사용해야 합니다. 프로그램을 시작한 후(번호가 정보 기지 1C: 기업 규모가 크면 잠시 후 데이터 전송 처리가 설치될 정보 기반을 표시해야 하는 대화 상자가 나타납니다. 창은 그림 1과 같습니다. 정보 베이스의 수가 7개보다 많으면 "위" 및 "아래" 버튼을 사용하여 탐색합니다. 여러 정보베이스를 선택한 경우 "경로" 줄에는 마지막으로 선택한 정보베이스의 위치만 반영됩니다. 이 정보는 보조적인 성격을 가지며 작업 결과에 대한 사용자 측의 추가 제어를 위해 선택적으로 사용됩니다. 설치 프로그램, 특별한주의를 기울이지 마십시오. 프로그램 자체가 귀하가 선택한 정보 기반이 설치된 위치를 결정합니다.

그림 1 설치 중 정보베이스 선택 창

또한 데이터 전송 처리가 설치될 폴더를 지정할 수 있으며, 이를 위해서는 폴더 선택 창(점 3개가 있는 버튼 클릭)을 사용하세요. 선택한 폴더의 전체 경로가 선택 라인에 반영됩니다. "설치" 버튼을 클릭하면 선택한 정보베이스 및/또는 선택한 폴더에 필요한 파일이 설치됩니다. 완료 후 "세부 정보" 버튼을 클릭하면 어떤 파일이 어떤 폴더에 기록되었는지 자세한 설치 로그를 볼 수 있습니다. 결과적으로 선택한 폴더는 다음 그림과 같아야 합니다(그림 2 참조).

그림 2 선택한 폴더에 설치된 파일

하위 디렉토리로 ExtForms처리가 설치되었습니다 1C로 전환:회계 8, ed. 3.0및 전송 규칙. 업로드 처리에 주의해 주세요 ACC_ACC8.ert데이터 업로드 규칙은 표준 처리 및 규칙을 대체합니다. 표준 전환 메커니즘을 유지하려면 정보베이스가 아닌 별도의 디렉터리에 새 처리를 설치하세요.

설치 과정은 보고서 설치 예를 통해 더 자세히 설명됩니다. 구성 "1C: 회계 7.7".

운영 절차.

프로그램에서 " 1C: 회계 7.7"다음부터 열어야 합니다. 추가 기능처리 중 " 1C로 전환:회계 8, ed. 3.0"에서 이체 규칙이 있는 폴더를 선택하고(그림 3 참조) 교환 규칙을 다운로드합니다. 모든 이체 규칙을 포함할 필요는 없습니다. 예를 들어 잔액 이체에 필요한 규칙만 사용해야 합니다. 또는 잔액 및 문서. 예를 들어 디렉토리 그룹에는 모든 디렉토리가 필요에 따라 참조로 전송되기 때문에 단일 규칙이 포함될 수 없습니다. 즉, 잔액이나 문서에 관련된 디렉토리만 전송됩니다. 새 정보 베이스에 "쓰레기"가 없습니다. 문서도 모든 것을 포함할 필요가 없습니다. 예를 들어, 일부 문서가 데이터베이스에 없거나 해당 문서를 전송하고 싶지 않은 경우 이 규칙을 활성화할 필요가 없습니다.

그림 3. 데이터 업로드 처리

데이터 파일 이름을 "C:\v77_v8\Exp77_80.xml"로 설정하는 것이 좋습니다. 프로그램에서 기본으로 자주 사용하는 폴더입니다." 1C: 회계 8"플랫폼의 프로그램에서 데이터를 로드할 때" 1C:엔터프라이즈 7.7". 필요한 경우 페이지에서 매개변수를 설정하세요." 옵션".

구성에서 데이터를 다운로드하는 중 " 회계 7.7"다양한 오류가 발생할 수 있습니다. 여기에 제시된 전송 규칙은 데이터 업로드 단계에서 검색을 수행한다는 점에서 표준 규칙과 다릅니다. 전형적인 실수. 어떤 메시지가 표시되는지 생각해 봅시다.

재고 품목의 수량 및 0이 아닌 금액. 자재 수량이 0이고 자재 비용 견적이 0이 아닌 방식으로 입고 구성에 잔액을 입력하는 것은 불가능하며 또한 오류이기 때문에 의미가 없습니다. 따라서 잔액을 이체할 때 해당 포지션(수량이 0인)은 잔액 입력 문서에 포함되지 않습니다. 결과적으로, 데이터 전송 전에 오류를 수정하지 않으면 잔액 전송 시 데이터 소스와 대상의 금액이 일치하지 않게 되어 추가적인 조정 문제가 발생하게 됩니다. 따라서 구성에서 데이터를 다운로드하는 과정에서 " 회계 7.7» 발생한 오류에 대한 메시지가 표시됩니다(그림 4 참조). 또한 오류를 찾으려면 "회계 관리의 명시적 확인" 처리, 즉 "자재 수량이 0인 경우 0이 아닌 금액 없음" 규칙을 사용하는 것이 좋습니다.

그림 4.1 발생한 오류에 대한 메시지

두 번째(세 번째) 수준의 하위 계정에 대한 0이 아닌 잔액, 첫 번째(두 번째) 수준의 잔액은 0입니다. 이것은 잘못된 기록 보관의 매우 흔한 상황입니다. 전형적인 예가 그림 4.2에 나와 있습니다. 이 조건은 분석 회계의 "재등급화" 결과로 발생합니다. 예를 들어 현금 흐름 문서에는 계약이 표시되어 있지만 자본화 문서에는 계약이 없거나 그 반대이거나 계약이 있지만 서로 다릅니다. 이 모든 경우에, 상대방의 잔액이 0이라는 사실에도 불구하고 계약에 따른 잔액은 0이 아닙니다. 자재 및 명명법 회계(보관 위치별 총 회계가 포함된 경우)에서도 유사한 그림이 나타날 수 있습니다. 특히 창고가 재정적으로 책임이 있는 사람인 경우 창고 간 등급 재지정이 가능합니다.

그림 4.2 회계 오류의 예

이것이 실수라는 것은 분명하며 그러한 잔액을 이월하는 것은 의미가 없다는 것이 분명합니다. 이러한 잔액의 이체를 제외하기 위해 '상위 잔액이 0인 경우 잔액을 언로드하지 않음'이라는 매개변수가 있습니다. 이 매개변수가 1로 설정되면 업로드 중에 그림 1에 표시된 메시지가 표시됩니다. 4.3(그림 4.2와 비교), 그러한 위치에 대한 잔액은 언로드되지 않습니다. 다양한 잔액 이체 규칙과 함께 이 매개변수의 다양한 조합을 사용할 수 있습니다. 모든 잔액을 한 번에 이체하지 않고 회계 섹션별로 이체하는 경우 다른 매개변수 값을 사용하여 여러 회계 섹션에서 잔액을 이체할 수 있습니다.

그림 4.3. 오류 메시지

빈 계약 값 또는 외국 계약.문제는 위에서 설명한 것과 유사하며 그 이유는 동일합니다. 즉, 계약에 대한 분석 회계의 등급이 잘못되었습니다(그림 4.4 참조). 하지만 상대방의 잔액은 0이 아니므로 위에서 설명한 검증 규칙은 작동하지 않습니다. 데이터를 전송할 때 잔액 입력 전표를 전기할 때 오류가 발생합니다. 빈 계약 값은 허용되지 않습니다.

그림 4.4 오류를 표시하는 보고서

전송 전에 이러한 오류를 제거하기 위해 데이터 업로드 단계에서 오류 메시지가 표시됩니다(그림 4.5 참조). 동일한 그림은 또 다른 오류가 발생했음을 보여줍니다. 계약이 상대방과 일치하지 않습니다. 계약의 소유자는 또 다른 상대방입니다. 이러한 오류는 종종 수정된 항목에서 발견됩니다. 비표준 구성 또는 오래 전에 생성된 데이터베이스에서는 표준 구성에서도 문서를 작성할 때 계약 준수 여부를 충분히 엄격하게 확인하지 못했습니다.

그림 4.5 회계 오류 메시지

매개변수 "가 1로 설정된 경우 계약서 및 타인의 계약서의 빈 값을 확인합니다. 계약서에 빈 값이 있는지 확인하고 상대방과의 준수 여부를 확인하세요.". 또한 오류를 찾으려면 "회계 관리의 빠른 확인" 처리, 즉 "계약에 대한 빈 분석 없음" 및 "상대방 및 계약 준수" 규칙을 사용하는 것이 좋습니다.

그 외 오류체크도 있으니 자세한 내용은 문의(페이지 하단 연락처) 부탁드립니다.

작업 방법

별도 유형의 문서 또는 선택한 유형의 문서 개별 사본을 업로드하는 예를 사용하여 전체가 아닌 부분적으로 데이터를 전송하는 방법을 보여 드리겠습니다. 데이터 업로드 규칙 하나만 표시하자 " 지불 순서" (그림 5 참조). 이렇게 하면 유형의 문서만 업로드할 수 있습니다. " 지불 순서". 이러한 매개변수를 사용하여 버튼을 클릭하면 " 부리다"를 선택하면 " 유형의 모든 문서가 다운로드됩니다. 지불 순서", "와의 시간 간격에 위치 시작일" 에 의해 " 만료일". 버튼을 누르세요 " PVD 설치", 그 뒤에 메시지 " 결제 주문 데이터 선택".

그림 5 특정 유형의 데이터 업로드 규칙을 설정하는 방법

그런 다음 "조건 추가" 버튼을 클릭하면 선택 속성을 선택할 수 있습니다(그림 6.1 참조). 가장 자주 사용되는 속성은 " 현재문서"를 사용하면 이 유형의 문서 목록에서 개별 문서를 선택할 수 있습니다. 다른 선택 세부 정보를 사용하면 날짜별로 문서를 선택하는 등 문서 그룹을 선택할 수 있습니다. 모든 경우에 문서가 선택됩니다. 매개변수에 의해 지정된 시간 간격 내에서 " 시작일" 그리고 " 만료일".

그림 6.1 단일 문서를 선택하는 방법

중요한! "1C"), 일부 구성에서는 선택 세부 사항에 따라 업로드할 때 문서 선택을 허용하지 않습니다. 이는 다음과 같은 사실 때문입니다. 표준 규칙아, 서류는 기간을 명시하지 않고 요청에 의해 선택됩니다. 이러한 요청이 항상 작동하는 것은 아닙니다.

비슷한 방법으로 전체 디렉터리가 아닌 일부 세부 사항에 따라 선택하여 디렉터리를 업로드할 수 있습니다. 먼저 원하는 데이터 업로드 규칙을 선택한 후 " PVD 설치" 그리고 " 조건 추가". 예를 들어, 그림 6.2는 프로그램 전환 시 함께 있던 직원만 언로드할 수 있는 방법을 보여줍니다. " 1C: 단순화된 과세 시스템, ed. 1.3" 에 " 1C: 기업회계, 에디션 3.0"(또는 사용자가 자주 말했듯이 회계 7.7에서 3.0으로의 전환) 노사 관계가 확립되었습니다.

그림 6.2 디렉토리 요소 그룹을 선택하는 방법

중요한!데이터 전송에 관한 제안된 규칙(회사에서 제안)에서 표준 규칙의 오류가 수정되었습니다. "1C"), 이로 인해 정기적인 디렉터리 세부 정보를 사용하여 언로드할 때 디렉터리 요소가 잘못 선택됩니다. 날짜마다 다른 값이 설정된 것입니다. 이는 표준 규칙에서 디렉터리 요소 선택이 마침표를 지정하지 않고 쿼리를 통해 수행된다는 사실 때문입니다.

디렉터리의 주기적인 세부 정보를 기준으로 선택은 매개변수 "의 날짜에 이루어집니다. 만료일"!!!

데이터 업로드 및 선택 규칙을 조합하여 사용할 수 있습니다. 선택 항목이 설정된 규칙은 "[SELECTION]"으로 표시됩니다. 특정 데이터 업로드 규칙의 선택을 보거나 편집하려면 규칙 목록에서 이 규칙을 두 번 클릭하거나 규칙을 선택한 후 "버튼을 클릭해야 합니다. PVD 설치".

중요한!객체 업로드가 비어 있거나 불완전한 것으로 확인되면 1C:Accounting 8에서 동기화 모드가 설정되어 있는지 확인해야 합니다. 이 경우 전송 후 변경된 객체만 업로드됩니다(디렉터리 .동기 회계 매개변수는 마지막으로 업로드된 문서 매개변수의 위치를 ​​저장하며, 이는 업로드 가능성 확인 기능에 의해 업로드 중에 확인됩니다. 정규직동기화 모드에서는 불가능해집니다. 교환 규칙을 로드한 후 동기화 모드를 확인합니다. 모드가 설치되면 경고 창이 생성되고(그림 6.5 참조) 동기화 모드를 비활성화하라는 메시지가 표시됩니다.

쌀. 6.5 동기화 모드 경고 창

표준 규칙과의 추가 차이점

이전 영수증 유형이 있는 PT&U를 전송할 때 발생하는 오류가 수정되었습니다. 상품 및 서비스 영수증 문서에서 영수증 유형이 2(오래된 값)이고 공급업체 송장이 없는 경우 BP 3.0에서 이 문서가 반품으로 잘못 변환됩니다. 구매자의 문서가 발생합니다.

Division 하위 계정이 있는 수동 작업을 BP PROF 버전으로 이전할 때 발생하는 오류가 수정되었습니다. 이러한 작업은 BP에 기록되지 않으며 "The Division 필드는 비어 있어야 합니다."라는 오류가 발생합니다. 이는 규칙이 CORP 버전에서 작동하도록 설계되었지만 PROF에서는 회계 레지스터의 DivisionDt 및 DivisionKt 차원이 비어 있어야 하기 때문입니다.

디렉토리 그룹이 중복되는 버그를 수정했습니다. 조약결과적으로 이 디렉토리의 요소가 중복됩니다(로드 중 검색이 상위 항목을 고려하여 수행되므로). 이는 그림 6.6에 설명되어 있습니다.

그림 6.6 디렉토리 전송 결과 조약표준 규칙

여기 칼럼에는 부모의(디렉토리 그룹) 이름 포함 2015 동일한 이름을 가진 두 개의 서로 다른 디렉터리 그룹이 있으므로(소스에는 그룹이 하나만 있음) 계약이 중복됩니다.

한 당좌 계좌에서 다른 계좌로 돈을 이체할 때 은행 서류를 이체하는 오류가 수정되었습니다. 안에 혈압 3.0이 경우 문서가 생성됩니다. 당좌계좌에서 인출수술 종류와 함께 조직의 다른 계정으로 이체,세부 사항이 작성되지 않아 수행되지 않습니다. 받는 사람의 계정. 게다가 세부정보가 잘못 입력되었습니다. 계정그리고 직불 계좌. 예를 들어 55와 51이 다르면 이 메시지가 표시되며 교체해야 합니다. 세부정보를 입력하지 못하는 오류 수정 의무의 종류세금 이전 서류에서. 위의 모든 내용은 릴리스 3.0.43.215에 적용됩니다.

소품이 전송됩니다 주요 계약예배 규칙서 상대방.

디렉토리 다운로드 규칙이 변경되었습니다. 명명법, 이제 데이터 선택 방법은 표준 샘플링이므로 세부 사항별로 디렉토리 요소를 선택할 수 있습니다(단순화된 세금 시스템 7.7 - BP 3.0의 표준 규칙에서는 이것이 불가능합니다). 디렉터리를 전송할 때 명명법, 전송되고 품목 가격링크를 통해, 즉 명명법에 따라 이전된 품목의 가격. 이 기능을 활성화하려면 매개변수 값을 1로 설정해야 합니다. 물품 하역 시 가격 업로드.

상대방과의 결제 잔액을 전송할 때 표준 규칙 "USN 7.7 - BP 3.0"에서 오류가 수정되었습니다. 계약 유형은 항상 다음으로 설정되었습니다. 다른. 이제 - 회계 섹션에 따라 잔액 유형에 따라 " 공급업체 및 계약업체와의 계산"계약 유형 = " 공급자와 함께"회계 부문에 따르면" 구매자 및 고객과의 계산"계약 유형 = " 구매자와 함께", 기타 경우에는 계약 유형 = " 다른".

상대방과의 결제 잔액을 전송할 때 표준 규칙 "USN 7.7 - BP 3.0"에서 오류가 수정되었습니다. 상호 결제 금액은 입력 문서의 두 가지 세부 정보에 기록되었습니다. 초기 잔액 합집합그리고 금액Kt. 이로 인해 기초 잔액 입력 전표가 전기되지 않았습니다.

확인하다구매자와 함께" (표준 규칙에서 " 다른"). " 속성의 값이 설정됩니다. 결제 상태", 이것은 중요합니다 올바른 선택수취인 구성의 은행 지불 문서에서 구매자에게 지불하기 위한 송장.

" 형식의 문서를 전송할 때 지불 순서"계약 유형이 다음으로 설정되었습니다." 공급업체와" (표준 규칙에서 " 다른").

저장 위치를 ​​전송할 때 표준 규칙 "USN 7.7 - BP 3.0"에서 오류가 수정되었습니다. 세부 정보가 "입력되지 않았습니다" 창고형".

추가된 매개변수 " 규제 당국과의 교류 포함": 값이 1이면 소품은 통제당국과의 교류형태디렉토리 요소 " 조직"값으로 설정" 교환범용 형식으로", 그렇지 않으면 " ExchangeDisabled"표준 규칙과 같습니다. 이는 EDF 설정을 망치지 않도록 반복적인(정기적인) 전송에 중요합니다.

디렉토리의 다운로드 항목에 대한 검색 규칙이 변경되었습니다." 상대방": 먼저 검색이 수행됩니다. 주석그리고 검문소(이 값이 채워진 경우) 주석그리고 마지막으로 이름. 세 가지 경우 모두 검색에는 그룹 특성(ThisGroup)과 그룹 자체(Parent)가 포함됩니다. 이는 반복적인(정기적인) 이체에 중요하므로 로드 후 이름이 변경된 상대방에 대한 중복을 생성하지 않도록 합니다.

거래상대방을 이전할 때 세부정보를 입력하세요. 국가등록"러시아"를 의미합니다. 이는 상대방 디렉터리를 프로그램에 로드한 후 필요합니다. "1C 회계 8"필수 세부정보를 수동으로 입력할 필요가 없었습니다. 국가등록. 채워지지 않은 경우 디렉토리 요소 " 상대방"자세한 내용은 확인 가능" 세금 번호" 그리고 " 등록. 숫자"그리고 세부사항" 주석" 그리고 " 검문소"가 숨겨집니다.

"직원" 디렉토리를 전송하기 위한 데이터 업로드 규칙이 전송 규칙 "USN 7.7 - BP 3.0"에 추가되었습니다(표준 규칙에서는 개인의 디렉토리만 전송됩니다).

이전 규칙 "USN 7.7 - BP 3.0"에서 직원의 현재 관세율 정보 레지스터에 대한 이전 규칙이 수정되었습니다.

납세를 위한 납부명령 이관 기능

거래 유형이 있는 결제 주문의 경우 세금 이전추가 세부 정보를 입력해야 합니다: KBK - 예산 분류 코드, 컴파일러 상태 등. 이러한 세부 사항의 구조는 다음과 같습니다. 부크 7.7 (USN 7.7) 그리고 혈압 3.0일치하지 않는. 특히 혈압 3.0이러한 세부정보 중 일부는 별도의 디렉터리에 포함되어 있습니다. 세금 유형 및 예산 지불, 결제 주문에 포함된 링크입니다. 디렉토리에는 예를 들어 회계 정책을 편집할 때 정보 베이스에 나타나는 여러 제공 요소가 포함되어 있습니다. 데이터를 전송할 때 이러한 요소는 회계 정책을 로드할 때도 나타납니다. 결제 주문을 업로드 및 다운로드할 때 디렉터리 요소 세금 유형 및 예산 지불결제 주문 세부정보로 대체하기 위해 KBK를 사용하여 검색했습니다. 세. 따라서 회계 정책을 이전한 후에는 필요한 세금이 모두 디렉토리에 나타나는지 확인하고 필요한 경우 보완하는 것이 좋습니다. 지불 주문에서 KBK를 비교(동기화)할 때 소스와 수신자는 4가지 KBK 범주, 범주 14-17, 소득 하위 유형 코드(세금, 벌금, 벌금 등)를 고려하지 않습니다. 디렉토리에서 세금 유형 및 예산 지불이 비트는 0으로 채워집니다. 디렉토리에 새 요소를 추가할 때 숫자 14-17도 0으로 채워야 합니다.

대규모 정보 데이터베이스의 전송.

우선, 대규모 정보베이스를 전송할 때 데이터를 다운로드하는 과정에 매우 오랜 시간이 걸릴 수 있습니다. 이는 상품 잔액과 같이 하나의 회계 섹션에 잔액이 많은 경우에 발생합니다. 업로드 시간을 줄이기 위해 하나의 문서를 분할하는 기술을 사용할 수 있습니다. 초기 잔액 입력" 몇 가지에 대한. 매개변수 값을 설정하면 " 잔액 입력 문서의 라인 수"가 0과 다른 경우(그림 6.3 참조), 하나의 문서에 데이터를 업로드하는 것은 지정된 값으로 제한됩니다. 이는 업로드 시간을 매우 크게(여러 번) 줄일 수 있습니다.

그림 6.3 문서 크기 제한이 있는 데이터 전송 시 매개변수 설정 " 초기 잔액 입력»

참고: 매개변수 값은 하나의 문서에 업로드되는 거래 테이블 행 수를 제한합니다. 초기 잔액 입력", 문서 자체의 줄 수를 지정하는 것이 아닙니다. 따라서 문서 행 수가 매개변수 값과 달라지며 이는 오류가 아닙니다. 문서를 분할할 때 " 초기 잔액 입력” 여러 문서의 경우 각 문서의 줄 끝 부분에 “-1”, “-2” 등의 접미사가 추가됩니다.

중요한!하나의 문서를 분할하기 위해 설명된 알고리즘 " 초기 잔액 입력"여러 개는 데이터 업로드 시간을 줄이기 위해서만 사용됩니다. 모든 문서는 하나의 파일로 업로드됩니다. 데이터 전송은 한 단계로 이루어지며 주석(접미사)이 자동으로 생성되며 하나의 매개변수만 지정됩니다. 그러나 이 기술은 아래에서 설명할 메모리 부족 문제를 해결하지 못합니다.

대규모 정보베이스를 마이그레이션할 때 부족한 문제가 있을 수 있습니다. 랜덤 액세스 메모리: 업로드를 시도하면 적절한 오류 메시지가 표시되거나 표시되지 않고 프로그램이 종료됩니다. 컴퓨터를 더 강력한 컴퓨터로 교체하는 것은 쓸모가 없습니다. 이 경우 데이터를 여러 부분으로 나누어 업로드해야 합니다. 이를 위해서는 지정된 모드를 지원하는 전송 규칙이 필요합니다. 언로드 방법을 살펴 보겠습니다. 첫째, 데이터 전송은 하나의 업로드 규칙만을 사용하여 수행되어야 합니다(그림 6.4 참조). 하나의 규칙에 따라 전송이 불가능한 경우 이를 부분으로 나누어 초기 부분 번호와 최종 부분 번호를 나타냅니다. 각 부분에는 지정된 수의 첫 번째 수준 분석 값(예: 제품 잔액)에 대한 정보가 포함됩니다. 지정된 계정 잔액 값 수 "41". 계정에 대한 총 분석 금액을 알면 제공 횟수를 쉽게 계산할 수 있습니다. 한 번에 얼마나 많은 데이터가 문제 없이 전송되는지(하나의 정보로) 실험적으로 결정해야 하며, 일반적으로 계정 잔액을 업로드할 때 잔액이 수천 개 이상이면 전송 문제가 나타납니다. 단, 회계 섹션의 모든 잔액을 한 번에 업로드할 수 있더라도 데이터 업로드 시간을 절약하기 위해 여러 부분으로 분할하는 것이 좋습니다. 업로드 시간은 비례적이거나 선형적인 것이 아닌 데이터 부분의 크기에 따라 달라집니다. 따라서 예를 들어 10,000개의 제품 잔고를 1,000분의 10으로 나누면 하역 시간을 여러 배로 줄일 수 있습니다. 첫 번째 부분을 옮기는 경우에는 처음 부분의 번호를 표시하지 않을 수 있고, 마지막 부분을 옮기는 경우에는 마지막 부분의 번호를 표시하지 않을 수 있습니다.

중요한!데이터를 부분적으로 전송할 때 문서 주석의 형성과 관련된 매개변수에 접미사를 지정해야 합니다. 초기 잔액 입력" 부분 범위 번호를 변경할 때 접미사를 변경하는 것을 잊지 마십시오. 그렇지 않으면 수신자 구성으로 로드할 때 동일한 주석(접미사)이 있는 문서를 덮어쓰게 됩니다. 데이터 파일의 이름은 특별히 중요하지 않습니다. 언로드 - 로드, 언로드 - 로드 등 순차 전송 전술을 사용할 수 있습니다. 이 경우 데이터 파일 이름을 변경할 필요가 없습니다. 전술을 선택할 수 있습니다. 먼저 모든 것을 언로드한 다음 모든 것을 로드합니다. 후자의 경우 데이터 파일 이름은 업로드될 때마다 변경되어야 합니다. 또 하나의 예입니다. 예를 들어 회계 섹션(예: 상품)의 잔액 수가 10,000이라면 이를 천 단위로 나누고 10개 부분을 얻습니다. 각 부분에는 "-1", "-2", "-3", "-4"와 같은 고유한 접미사가 있어야 합니다. 남은 상품을 모두 내린 다음 모든 상품을 로드하는 경우 데이터 파일도 고유해야 합니다(예: "41_1", "41_2", "41_3", "41_4"). "부분 번호 시작" 및 "부분 번호 끝" 매개변수는 다음 값을 취해야 합니다: 0, 1000; 1001, 2000; 2001, 3000; 3001, 4000.

그림 6.4 데이터를 부분적으로 전송할 때 매개변수 설정

다음 업로드 규칙에서는 데이터 분할 전송이 지원됩니다.

    고정자산

    재료

    재고 품목 비용의 편차

    구매한 자산에 대한 VAT

    미완성 생산

  • 완제품 및 반제품

    판매 비용

    배송된 상품

    현금

    금융 투자

    공급업체 및 계약업체와의 합의

    상대방과의 기타 합의

    세금 및 수수료

    직원과의 합의

    책임자와의 계산

    창립자와의 합의

    다른 채무자 및 채권자와의 화해

    자본금과 준비금

    미래 비용

    이연법인세자산과 부채

    재무 결과

    부외 계정

"먼저 참고서를 옮기고 남은 부분을 옮기세요."와 같은 어리석은 조언을 따르려고 하지 마십시오.첫째, 디렉토리를 부분적으로든 전체적으로든 별도로 이동하는 것은 의미가 없습니다. , 잔액을 언로드할 때 오류가 발생하면 도움이 되지 않습니다.. 오류는 링크를 사용하여 디렉터리를 전송할 때 잔액을 전송할 때(언로드 중에 이를 이해하는 것이 중요함) 실제로 발생할 가능성이 높습니다. 디렉토리가 이미 전송되었는지 여부는 중요하지 않습니다.남은 음식을 내릴 때 제한 없이 계속 내릴 수 있습니다. 둘째, 전체 디렉터리를 전송하는 것은 일반적으로 쓰레기를 전송하는 것이므로 그렇게 해서는 안 됩니다.

언로드가 완료된 후 1C:Accounting 8 프로그램을 시작해야 합니다. 처음과 반복되는 데이터 전송 또는 추가 전송 중에 로드는 표준 처리를 사용하여 수행되어야 합니다(그림 7 참조).

주의, 중요. 치료 XML 형식의 범용 데이터 교환 (일부 릴리스 3.0.43.x에서)오류가 포함되어 있습니다. 수정된 가공을 사용할 수 있습니다. XML 형식의 범용 데이터 교환, 배송에 포함되어 있으며 데이터베이스 디렉토리에 설치됩니다. 회계에디션 4.5.

프로그램에 로딩 후 1C: 회계 8잔액 입력을 위한 문서를 전기해야 하며, 나머지 문서는 다시 전기해야 합니다. 이는 처리를 사용하여 수행하는 것이 가장 좋습니다. 문서의 그룹 전송, 섹션에 있습니다. 관리. 지정된 섹션에 보이지 않는 경우 원하는 명령을 추가하여 작업 표시줄을 구성합니다(그림 7.1 참조).

그림 7.1 액션바 설정

중요한. 처리기 디버깅 모드(Exchange Process.Handler DebuggingMode Flag = True)에서 작동하고 처리기 사용을 허용하지 않으므로 표준 구성의 처리를 사용할 수 없습니다. "검색 필드"디렉토리에 다운로드된 항목을 검색하려면 " 상대방" (위 참조). 보다 정확하게는 로드 중에 사용되는 모든 핸들러는 구성에 내장된 처리에 있습니다. 프로세서다운로드FromAccounting77. 따라서 변경된 규정에 따른 양도는 불가능합니다. 적어도로딩 단계에서.

비슷한 것을 사용할 수 있습니다 외부 처리 1Enterprise77의 정보 기반에서 데이터 전송(배송에 포함되어 있습니다). 아래에서는 이를 사용하는 방법을 설명합니다(다시 한번 - 외부 처리).

언로드가 완료된 후 1C:Accounting 8 프로그램을 시작해야 합니다. 메뉴에서: 파일 - 열기 및 외부 처리 지정 1Enterprise77의 정보 기반에서 데이터 전송.

그런 다음 데이터 로드 옵션(파일에서 데이터 로드)을 지정해야 하는 양식이 표시됩니다(그림 7.2).

그러면 업로드된 파일의 경로를 지정해야 하는 대화 상자가 표시됩니다(그림 7.3 참조).

"데이터 로드"를 클릭하면 데이터 로드 프로세스가 시작됩니다(그림 7.4 참조). 완료되면 대차대조표를 생성하고 소스 구성 데이터베이스의 회전율과 다운로드가 이루어진 대상 구성을 확인해야 합니다. .

데이터 전송 과정에서 오류가 발생하면 메시지 창이 열리며, 여기에서 두 번 클릭하여 오류를 해결할 수 있습니다. 발생한 오류에 대한 설명 및 제거 권장 사항에 대한 보고서를 받으려면 "하이퍼링크"를 클릭해야 합니다. 오류 정보».

반복되는 데이터 전송 중 로드 또는 개별 문서 또는 디렉토리의 추가 전송은 표준 처리 "XML 형식의 범용 데이터 교환"을 사용하여 수행될 수 있으며, 이로 인해 프로세스 속도가 빨라집니다.

데이터 변환 기술.

필요한 경우 변환은 예를 들어 첫 번째 잔액, 그 다음 문서 등 여러 단계로 수행될 수 있습니다. 정보의 재전송이 가능합니다.

잔액은 문서를 통해 이체됩니다. 초기 잔액 입력».

잔액 입력 방법에 대한 자세한 내용은 1C 회사의 ITS 웹 사이트(1C: Enterprise Accounting rev. 3.0)의 기사에서 확인할 수 있습니다.

중요한! 기초 잔액을 입력하기 전에 회계 정책 매개변수를 설정해야 합니다. 조직의 회계 정책 매개변수는 잔액이 입력된 날짜 다음 날에 읽혀집니다. 예를 들어 잔액 입력 날짜가 2013년 12월 31일인 경우 2014년 1월 1일에 설정된 회계 정책 매개변수가 고려됩니다. 이를 통해 현재 회계 정책의 매개변수를 고려할 수 있습니다(예: 2013년에 조직이 단순화된 과세 시스템을 적용했고 2014년부터 전환되었습니다. 공통 시스템- 2013년 12월 31일 현재 잔액을 입력할 때 2014년 회계정책 매개변수가 고려됩니다. 회계 정책이 올바르게 전송되었는지 확인하고 필요한 경우 수정하십시오.

중요한! 나머지 구성을 전송하기 전에 수신자 구성에서 작업을 시작하기로 결정한 경우 수신자 구성에서 작업을 시작하기 전에 먼저 디렉터리를 전송해야 합니다. 그렇지 않으면 잔액을 비어 있지 않은 데이터베이스로 전송할 때 오류가 발생할 수 있습니다.

나는 질문에 대답하고 있습니다!배송 세트에 포함된 처리 및 전송 규칙은 공개되어 있으며 어떤 방식으로든 복사가 방지되지 않습니다. 이는 구매자(라이선시)가 배포 및 복제할 권리가 있음을 의미하지 않습니다. 면허 소지자는 그러한 권리가 없습니다. 라이센스 소유자는 사용할 권리가 있습니다. 이 권리를 행사함으로써 라이센스 사용자는 보관 사본을 생성하고, 변경하고, 무제한의 컴퓨터에서 무제한으로 사용할 수 있습니다. 변환 규칙을 개선하거나 수정하고 이에 더 익숙해지려면 규칙을 프로그램에 로드해야 합니다. 데이터 변환. 이 프로그램은 1C에서 배포하며 사용 규칙을 결정합니다.

구매 이유

정기적으로 업데이트됩니다. 구매 후 6개월 동안 업데이트가 무료로 제공됩니다. Infostart의 TOP 100 간행물에 포함되어 있습니다.

장점

규칙의 텍스트와 처리가 공개되어 있으며 데이터 변환 기술이 사용되며 편집이 쉽습니다.

버전 비교

    2019년 1월 29일 규칙이 3.0.67.70 릴리스로 업데이트되었습니다.

    2018년 7월 5일 규칙이 3.0.63.22 릴리스로 업데이트되었습니다.

    2017년 9월 25일 3.0.52.36 릴리스로 규칙이 업데이트되었습니다.

    2017년 7월 18일 규칙이 3.0.51.16 릴리스로 업데이트되었습니다.

    2016.10.12 기존 입학 방식으로 직업교육훈련을 전환하는 오류 수정

    2016년 9월 8일 규칙이 3.0.44.102 릴리스로 업데이트되었습니다.

    2016/06/18 하위 계정 부서가 있는 수동 작업을 이전할 때 발생하는 오류를 수정했습니다.

    2016년 5월 31일 규칙이 3.0.43.236 릴리스로 업데이트되었습니다. Universal XML Data Exchange 처리의 표준 구성(BP 릴리스 3.0.43.174 - 235)에서는 매개변수 로드 프로시저가 올바르게 작동하지 않습니다. 이 버그를 해결하기 위해 규칙이 변경되었습니다. 또한 제공 패키지에 포함된 Universal Data ExchangeXML 처리를 사용하여 BP 3.0에 로드할 수도 있습니다. 이는 설치 중에 info 디렉토리의 ExtForms 하위 디렉토리에 기록됩니다. 베이스 7.7.

    2016년 5월 25일 규칙이 3.0.43.215 릴리스로 업데이트되었습니다.

    2016년 5월 11일 계약명 길이 제한이 50자에서 100자로 변경되었습니다.

    2016년 2월 23일 규칙이 3.0.43.29 릴리스로 업데이트되었습니다.

    2015년 12월 21일 처리 및 규칙이 릴리스 3.0.42.33으로 업데이트되었습니다.

    2015.11.11 동기화 모드 확인 추가

    2015년 5월 18일 처리 및 규칙이 릴리스 3.0.40.24로 업데이트되었습니다.

    2015.05.14 세금납부서류 양도가 확정되었습니다.

    2015년 4월 8일 처리 및 규칙이 릴리스 3.0.39.56으로 업데이트되었습니다. 릴리스 3.0.39에서는 지불 송장 구조가 변경되었습니다. 더 이상 "서비스" 표 형식 부분이 없으며 이제 상품과 서비스가 하나의 "상품" 표 형식 부분에 있습니다. 따라서 3.0.38의 규칙을 3.0.39로 포팅하는 데 사용할 수 없습니다.

    2015년 4월 2일 처리 및 규칙이 릴리스 3.0.38.53으로 업데이트되었습니다.

    2014년 12월 23일 처리 및 규칙이 릴리스 3.0.37로 업데이트되었습니다.

배송 내용.

패키지에는 다음이 포함됩니다. "ACC_ACC8",환승 규칙 "ACC_ACC8"및 처리 1Enterprise77의 정보 기반에서 데이터 전송. 귀하의 조직에 작업을 수행할 정규 프로그래머가 없는 경우 당사는 전문가의 서비스를 제공할 준비가 되어 있습니다(프로그래머는 다음을 통해 인터넷을 통해 귀하의 컴퓨터에 연결됩니다). 특별 프로그램원격 작업을 위해 필요한 작업을 수행합니다). 가능하다면 작업 기반을 제공하세요. "1C: 회계 7.7", 우리는 데이터를 직접 전송하고 파일을 전송할 수 있습니다. " 1C: 회계 8" 이체 된 잔액으로. 이 서비스 비용은 패키지 총 비용에 포함되지 않습니다.


© 보리스 발야스니코프(Boris Balyasnikov), 2014년 1월, 마지막 변경사항 2019년 1월

1C 7.7 프로그램의 대부분의 사용자는 1C 7.7에서 8.3(8.2)으로의 전환을 복잡하고 프로그래머에게만 적용되는 것으로 상상합니다. 조직에 완전히 재설계된 구성이 없는 경우 이 문서는 귀하를 위해 작성되었으며 1C 8.3 또는 8.2로 전환하는 데 도움이 될 것입니다.

1C 7.7에서 후속 데이터 전송을 위해 1C 8.3(8.2) 데이터베이스를 단계별로 준비하는 방법

작업을 시작하기 전에 후속 데이터 로드를 위해 1C 8.3(8.2) 데이터베이스를 준비해야 합니다.

1 단계

1C 데이터베이스를 최신 릴리스로 업데이트하고 최신 버전 8.2 또는 8.3을 사용하십시오. 1C 기술 지원 웹 사이트에서 현재 릴리스의 관련성을 확인할 수 있습니다.

1C 8.3 플랫폼을 설치하거나 업데이트하는 방법은 비디오 튜토리얼을 참조하십시오.

2 단계

정기적인 월말 결산 작업을 수행합니다. 또한 다음을 통해 회계 기록을 확인할 수 있습니다. 서비스 – 1C 회계 8로의 전환을 위한 데이터 검증.오류가 있으면 수정하세요.

3단계

5단계

데이터 로드를 위한 깨끗한 데이터베이스를 만듭니다. 예상치 못한 상황이 발생할 경우 데이터 다운로드를 즉시 취소하기 위해 필요합니다. 상위 메뉴프로그램 선택 관리 – 데이터 업로드,업로드 파일의 이름과 저장 위치를 ​​지정합니다.

이러한 준비 조치 덕분에 불필요한 개체가 데이터베이스에서 제거되고 1C 데이터베이스가 작아집니다. 결과가 다시 계산되고 데이터베이스의 논리적 무결성이 확인됩니다. 이제 1C 7.7에서 1C 8.3(8.2)으로 데이터 전송을 시작할 수 있습니다.

1C 8.3에 정보 기반을 추가하는 방법은 다음 비디오 강의를 참조하십시오.

1C 7.7에서 1C 8.2 회계 2.0으로 데이터 전송

1C 8.2 회계 2.0 프로그램 릴리스의 최신 버전에서는 1C 7.7 정보 데이터베이스의 번역이 지원되지 않습니다. 1C 회사의 요구 사항에 따라 수행해야합니다. 따라서 1C 8.2 데이터베이스에서 선택하면 서비스 – 정보 데이터베이스에서 데이터 전송 1C Enterprise 7.7, 그러면 오류가 발생합니다.

하지만 특별히 버전 1C 8.2로 전송해야 한다면 어떻게 해야 할까요?

1단계. 1C 7.7에서 데이터 업로드

1C 8.2 회계에 업로드하려면 이전에 1C에서 제공한 파일을 다운로드해야 합니다. 이러한 파일은 데이터베이스의 ExtForms 폴더에 있어야 합니다. 예에서는 D:\1с\77\unp_demo\ExtForms입니다. 1C 프로그램을 로드할 때 데이터베이스 경로를 볼 수 있습니다.

이 처리를 실행해 보겠습니다. 모든 것이 올바르게 완료되면 "1C Accounting 8에 대한 데이터 업로드 중"이라는 메시지가 나타나며 열기 버튼을 클릭하여 선택합니다.

  • 업로드 규칙 – Acc77_80.xml이라는 파일을 ExtForms 폴더에 복사했습니다.
  • 시작 날짜 및 종료 날짜 – 데이터가 다운로드되는 기간입니다.
  • 데이터 업로드 규칙 – 업로드할 개체, 파일에 업로드해야 하는 디렉터리 및 문서.

예제의 데이터 파일은 데스크탑에 복사되지만 다른 폴더를 선택할 수 있습니다. 교환 규칙 로드 버튼을 클릭합니다. 1C 7.7에서 언로드될 개체 목록이 열리고 선택 상자를 제거하거나 선택하여 편집할 수 있습니다.

상황에 따라 데이터를 한꺼번에 업로드하거나 부분적으로 업로드할 수 있습니다. 먼저 디렉터리를 언로드합니다. 그 중 95%가 문제 없이 언로드됩니다. 두 번째 파일에서는 회계 섹션별로 잔액과 매출액을 업로드합니다. 이 옵션은 일부 데이터가 올바르게 업로드되지 않은 경우 사용하는 것이 편리합니다.

2단계. 1C 7.7에서 1C 8.2 회계 2.0으로 로드

선택하다 서비스 – 정보 데이터베이스에서 데이터 전송 1C Enterprise 8, 나타나는 창에서 파일에서 로드를 선택합니다.

1C 7.7에서 데스크탑으로 다운로드한 파일을 선택합니다. 다음 버튼을 클릭하면 파일에서 데이터가 로드됩니다. 1C 7.7 데이터베이스의 계정이 오랫동안 유지된 경우 로드하는 데 오랜 시간이 걸릴 수 있습니다.

다운로드 중에 오류가 발생하면 데이터의 일부만 다운로드되므로 다시 다운로드해야 합니다.

1C 7.7에서 1C 8.3 회계 3.0으로 데이터 전송

1C 7.7에서 1C 8.3으로 데이터베이스를 전송하는 알고리즘은 세부적으로 약간 다르지만 일반적으로 1C 8.2 Accounting 2.0에 대해 위에서 설명한 것과 유사합니다.

1 단계

1C 정보 기반을 업데이트한 후에는 데이터 업로드 규칙을 업데이트해야 합니다. 이는 다음과 같이 수행할 수 있습니다.

1C 8.3 Accounting 3.0을 열고 오른쪽 하단에서 전송 규칙 저장 버튼을 선택한 다음 버전 1C Accounting 7.7을 선택하고 정보 데이터베이스의 ExtForms 디렉터리 경로를 지정하여 규칙을 저장합니다.

2단계. 1C 7.7에서 데이터 업로드

1C 7.7에서 1C 8.3으로 업로드하는 기능은 기본적으로 제공됩니다. 즉, 추가 파일을 다운로드하여 데이터베이스에 추가할 필요가 없습니다.

언로드 처리를 시작하겠습니다. 서비스 – 추가 기능. 1C 8.3 Accounting ed로 전환이라는 비문이 있습니다. 3.0을 선택하고 열기를 클릭합니다.

나타나는 창에서 다음을 입력해야 합니다.

  • 업로드 규칙 - 데이터베이스가 있는 폴더(데이터베이스 경로를 결정하는 방법은 위에 설명되어 있음)인 ExtForms 폴더에서 찾을 수 있는 ACC_ACC8.xml이라는 파일입니다. 이것은 1C 8.3에서 복사한 것입니다.
  • 시작 날짜 및 종료 날짜 – 데이터가 다운로드되는 기간입니다.
  • 데이터 파일 이름 – 업로드된 데이터가 포함된 파일을 복사할 위치입니다.
  • 데이터 업로드 규칙 - 업로드할 개체, 파일에 업로드할 디렉터리 및 문서:

교환 규칙 로드 버튼을 클릭합니다. 1C 7.7에서 언로드될 개체 목록이 표시되며, 선택 상자를 제거하거나 선택하여 편집할 수 있습니다.

여러 파일을 생성하여 부분적으로 업로드하거나 모든 데이터를 한 번에 업로드할 수 있습니다. 수행할 작업은 특정 상황에 따라 다릅니다. 예시에서는 모든 데이터를 한 번에 업로드합니다.

1C Accounting 3.0 (8.3)을 열고 여기를 선택하면 데이터를 로드하는 두 가지 방법이 표시됩니다.

  • 정보 기반에서 데이터로드 - 1C 8.3 프로그램이 자체적으로 데이터를 찾습니다. 설치 기지거기에서 데이터를 복사하여 이 정보베이스에 연결을 시도합니다. 설정을 사용하여 로드해야 할 항목을 지정하고 데이터 로드 버튼을 클릭할 수 있습니다.

  • 파일에서 데이터를 로드하는 것은 우리의 선택일 뿐입니다. 1C 7.7에서 다운로드한 파일을 지정하고 데이터 로드 버튼을 클릭해야 합니다. 아래와 같은 창이 나타나면 다운로드가 성공한 것입니다. 그렇지 않으면 부분적으로 다운로드하여 프로그램이 1C 7.7에서 생성하는 오류를 수정해야 합니다.

1C 7.7의 수정된 표준 구성에서 1C 8.3(8.2)으로 데이터 전송

변경된 1C 7.7 구성에서 데이터를 전송하는 것은 데이터를 전송할 프로그램 버전에 존재하지 않는 다시 작성된 비즈니스 프로세스로 인해 훨씬 ​​더 복잡합니다. 대부분의 경우 이러한 전송은 데이터 전송 경험이 있거나 데이터 변환 구성에 대한 지식이 풍부한 전문가가 수행해야 합니다. 존재하다 일반 원칙 transfer는 다음 구성을 전송하는 데 사용할 수 있습니다.

  • 기능 이전. 새 구성에서는 1C 7.7에 있는 기능을 반복해야 합니다. 추가 문서, 참고 도서 및 세부 정보. 이 데이터베이스의 -CF를 언로드합니다.
  • 올해 연말에. 계정 회전율 비교 ~ 전에컨볼루션과 ~ 후에- 동등해야 합니다.
  • 축소된 1C 7.7 데이터베이스에서 새 버전의 표준 클린 데이터베이스로 데이터를 전송합니다. 1C 7.7, 8.2 또는 8.3에서 계정의 매출액 데이터를 확인하세요. 오류가 있으면 수정하세요.
  • 1C 7.7에서 데이터가 로드된 클린 데이터베이스에 1C 7.7의 기능이 반복된 CF 구성 파일을 업로드해야 합니다.
  • 추가 디렉터리 세부 정보는 데이터 변환 구성을 사용하여 전송할 수 있습니다.

1C 7.7에서 1C 8.3, 8.2로 데이터 전송 후 데이터 확인

매출 대차대조표 보고서를 사용하여 하위 계정, 회계 유형, 부외 계정, 통화에 대한 데이터가 포함된 보고서를 생성하고 데이터가 전송된 1C 8.3(8.2) 데이터베이스의 동일한 보고서와 비교합니다.

1C:Enterprise 8.2로 전환해야 합니까? 이 글을 읽고 계시다면 아마도 이미 이 질문에 긍정적으로 답하셨을 것입니다. 따라서 이제 우리는 새로운 플랫폼으로 전환할 때의 이점에 대해 다시 이야기하지 않고 이 프로세스의 세부 사항과 기능에 직접적으로 초점을 맞출 것입니다.


1. 일반 알고리즘

그래서 당신은 "8"로 전환하기로 결정했고 이것이 어떻게 이루어지고 그것이 당신에게 "위협"하는 것이 무엇인지 알고 싶습니다. 매우 일반적인 견해전환 다이어그램은 다음과 같습니다(그림 1).

쌀. 1. 1C:Enterprise 7.7 플랫폼에서 1C:Enterprise 8.2 플랫폼으로 전환하기 위한 알고리즘


1. 업그레이드.가장 먼저 해야 할 일은 조직에서 신청서를 작성하고, 플랫폼 7.7에 대한 등록 양식을 제출하고, 플랫폼 8.2를 구매하는 것입니다. 이 경우 귀하에게 제공됩니다 할인기존 플랫폼의 비용만큼 50% 이하. 이전 플랫폼은 그대로 유지되며 계속 사용할 수 있지만 다음 플랫폼에서는 제거됩니다. 기술적 지원 1C 회사에서.


2. 업데이트최신 현재 릴리스까지 현재 구성.


3. 전송할 데이터베이스를 준비합니다.암시하다 지원데이터베이스, 현재 청구 기간 마감, 삭제 표시된 항목 데이터베이스 지우기, 회계 오류 수정(있는 경우).


4. 데이터 전송.이것이 메인 스테이지입니다. 알고리즘과 노동 강도는 특정 사례마다 다릅니다.


5. 새로운 구성을 사용하기 위한 인력 교육.플랫폼 7.7과 8.2의 구성은 인터페이스와 기능이 모두 다르기 때문에 새로운 구성을 사용하려면 교육이 필요할 수 있습니다. 적절한 방법론 문헌을 사용하여 직접 연구할 수 있지만 직접 살펴보는 것이 좋습니다. 전문과정 1C에 따르면.


6. 작동.이 단계에서 사용자가 작업을 시작하면 새로운 프로그램, 디버깅 및 수정되었습니다. 가능한 오류자동화된 데이터 전송.

구성의 맥락에서 새로운 플랫폼으로 마이그레이션하는 프로세스를 고려해 보겠습니다. "1c 회계".


2. "1C: 회계 7.7"을 "1C: 회계 8.2"로 변경합니다.

"1C: 회계 7.7"에서 "1C: 회계 8.2"로 데이터를 전송하는 전략 및 메커니즘은 다음 요소에 의해 결정됩니다.

  • 새 프로그램의 회계 시작 시간;
  • 개선의 존재와 복잡성 현재 버전귀하의 구성;
  • 과거 기간 동안의 비즈니스 거래 내역을 보존해야 할 필요성.


우리는 고객에게 새로운 회계 프로그램을 시작하라고 조언합니다. 새해 1월 1일부터 . 이는 대부분의 세금이 발생주의 기준으로 계산되기 때문입니다. 그러므로 수단을 개발하지 않으려면 올바른 전송결과가 누적된 경우 프로그램 작업 시작을 세금 신고 기간 시작과 연결해야 합니다. 물론 분기 초부터 일을 시작할 수도 있고, 심지어 처음부터 일을 시작할 수도 있습니다. 다음 달, 그러나 이러한 전환에는 더 많은 비용이 필요합니다(7.7과 8.2의 문서 구조가 크게 다르기 때문에).


위의 요인들의 조합에 따라 상황은 다음과 같을 수 있습니다.

상황 1:

새해로부터의 전환, 일반적인 구성, 이전 프로그램에서 올바른 계정 잔액이 생성됨


이 옵션은 간단하고 간단하지만 실제로는 극히 드뭅니다. 많은 소규모 회사에서는 새 프로그램에서 작업을 시작하기 직전에 이전 프로그램에서 올바른 잔액을 생성하고 지난 기간의 모든 기본 문서를 제공하고 프로그램에 입력한 경우에만 가능합니다.


이것이 귀하의 경우라면 운이 좋을 것입니다. "1C:Enterprise 7.7" 구성을 최신 버전으로 업데이트하고 "1C:Enterprise 8.2"에 내장된 "1C:Enterprise 7.7 정보 기반에서 데이터 전송" 처리를 사용하기만 하면 됩니다. 전문가의 도움 없이 스스로 할 수 있습니다. 처리에 지정된 지침을 엄격히 따르기만 하면 됩니다.

상황 2:

새해부터의 전환, 일반적인 구성, 이전 프로그램에는 올바른 계정 잔액이 없습니다.


이 경우의 표준 관행은 다음과 같습니다. 이전 프로그램과 새 프로그램에서 동시에 작업 . "전환 기간"(그림 2) 동안 직원은 이전 프로그램의 이전 거래를 종료하고 새 거래에 대한 문서를 새로운 시스템.


쌀. 2. 플랫폼 변경 시 전환 기간


최소한의 손실로 이 기간을 극복하려면 다음 전략을 사용할 수 있습니다.

  • 잔액을 "있는 그대로" 연초로 이체하고 이 데이터를 기반으로 기록을 유지합니다.. "7"에서 올바른 잔액을 얻은 후에는 "8"에서 소급하여 즉시 조정해야 합니다.
  • 잘못된 잔액 이체를 거부하고 이후에 이를 수행하지 않고 새로운 거래에 대한 기본 문서를 G8에 입력합니다. 이 경우 프로그램에 잔액이 있는지 여부는 중요하지 않으며 게시되지 않은 문서는 계정에 아무런 영향을 미치지 않습니다. 1C:Enterprise 7.7에서 올바른 잔액이 수신될 때까지 이 작업을 수행해야 합니다. 다음으로, 결과 잔액은 연초에 새 프로그램으로 이전됩니다. 마지막 단계는 내장 처리를 사용하여 전환 기간 동안 새 프로그램에 도입된 "기본"을 일관되게 구현하는 것입니다. "디렉터리 및 문서의 그룹 처리" .

상황 3:

올해 중반부터의 전환, 일반적인 구성

"1C: 회계 8.2"는 회계에 중요한 여러 메커니즘을 지원하며, 그 성능은 해당 연도 동안 문서에 입력된 데이터에 따라 달라집니다. 이러한 메커니즘 중에는 이미 언급한 발생 기준 세금 계산, 간접 비용 분배 알고리즘 및 월말 마감과 관련된 기타 절차가 있습니다. 이 상황에서는 처음 두 경우처럼 쉽게 새 프로그램으로 전환하는 것이 불가능하다는 것은 바로 이러한 기능 때문입니다. 마이그레이션 중에 발생할 수 있는 오류 수를 최소화하려면 다음을 권장합니다.

  • 연초가 아니라면 적어도 분기 초부터 작업을 시작하십시오.
  • 연초에 잔액을 이체합니다.
  • 현재의 모든 기본 문서를 이전합니다. 보고 기간(연도)를 새 시스템에 도입하고 디렉토리 및 문서의 그룹 처리를 사용하여 회계 및 세금 데이터를 복원합니다.


1. 표준용액 "1C: 데이터 변환 2.1". 이 소프트웨어 제품은 모든 구조와 복잡성의 1C 플랫폼 구성 간에 정보를 전송하는 데 사용할 수 있습니다.

2. 1C 프랜차이즈 개발. 회사를 비롯한 여러 회사에서 « RG-Soft"()에는 이 문제를 해결하는 입증된 방법이 있으며, 이를 통해 데이터 전송 작업에 소요되는 시간과 예산을 크게 줄일 수 있습니다.


상황 4:

지난 기간의 문서 전송을 통해 표준 구성에서 전환

이와 별도로, 거래상대방과의 계약을 통해 장기간(1년 이상) 관계를 유지하는 회사가 있다는 점에 주목합니다. 그러한 회사의 경영진은 프로그램에 비즈니스 거래 내역을 포함하는 데 관심이 있습니다. 이전 프로그램에 입력된 문서가 새 프로그램에 있으면 사용자는 특정 계약/거래에 따른 관계를 쉽고 빠르게 추적할 수 있습니다.


이전 상황과 동일한 메커니즘을 사용하여 이러한 전송을 구현하는 것이 가능합니다. 이 프로세스의 차이점은 모든 문서를 이체할 필요가 없으며 몇 가지 유형의 문서만 이체할 수 있으며 다른 계정의 잔액은 표준 처리를 통해 입력된다는 점입니다. 이 경우 일반적으로 추가로 전송된 문서는 미전기 상태로 남아 있습니다.


이전 프로그램에서 새 프로그램으로 이전 기간의 문서를 전송할 수는 있지만 이러한 전송으로 인해 데이터베이스 크기가 눈에 띄게 증가하고 결과적으로 처리되는 테이블의 크기도 커집니다. 이로 인해 시스템 속도가 느려질 수 있습니다. 따라서 꼭 필요한 경우가 아니면 이 전환 옵션을 사용해서는 안 됩니다. 포함된 정보가 현재 회계 및 세무 신고에 영향을 미치지 않도록 이전 기간에서 이전된 문서를 전기하지 않은 상태로 두는 것이 좋습니다. 참고 목적으로만 역사적 문서를 사용하십시오.


상황 5:

1C:Enterprise 7.7 플랫폼의 비전형 구성에서 전환

위에서 설명한 옵션은 표준 “1C:Enterprise 7.7” 구성에서 마이그레이션할 때 사용되지만 실제로는 수정된 구성을 처리해야 하는 경우가 많습니다. 이 상황에서 전환을 구성하는 것은 고려할 가치가 있는 특별한 옵션입니다.


프로그램 변경 사항의 성격에 따라 다음과 같은 데이터 전송 기술을 사용할 수 있습니다.

· 구성이 약간 변경되었고 기본 메커니즘이 표준 1C 솔루션과 유사한 경우 이전 옵션과 마찬가지로 표준 전환 도구를 사용할 수 있습니다. 프로그램에 맞게 구성하거나 약간만 수정하면 됩니다. 아마도 가장 테스트되고 신뢰할 수 있는 도구는 이미 언급된 "1C: Data Conversion 2.1"일 것입니다. 이 도구사용자의 특정 작동 기술이 필요하지만 도움을 받으면 구성 간 자동 객체 전송을 구성할 수 있습니다.

· 수년에 걸쳐 구성이 근본적으로 재설계된 경우 표준 마이그레이션 도구를 설정하는 것이 이러한 목적을 위해 자체 처리를 작성하는 것보다 더 노동 집약적일 수 있습니다. 1C 플랫폼과 관련되지 않은 회계 프로그램에서 전환을 구성하는 경우에도 비슷한 상황이 발생합니다. 이러한 전환을 수행하는 것도 가능하지만 사전에 생각해보십시오. 만능 교환작동 안 할 것이다. 각각의 특정 사례에는 문제에 대한 개별적인 접근 방식이 필요합니다. 우리 회사는 dbf, xls (Excel에서 1C로의 범용 로더), xml.


플랫폼 7.7에서 8.2로의 전환과 관련하여 언급할 가치가 있는 또 다른 사항에 대한 우려 데이터베이스 통합.


하나의 데이터베이스에 여러 회사의 기록을 유지하는 메커니즘이 없기 때문에 많은 기업은 1C:Enterprise 7.7에서 여러 데이터베이스를 동시에 유지해야 했습니다. 이 문제는 여덟 번째 버전에서 해결되었으므로 데이터 전송 프로젝트의 일부로 여러 데이터베이스를 하나로 결합하는 작업이 발생합니다. 게다가 7개의 베이스는 각각 고유한 특성을 가질 수 있습니다.

위에 제공된 방법을 사용하면 각 데이터베이스와의 상호 작용을 개별적으로 설정할 수 있습니다. 그러나 이 경우와 관련된 여러 하위 작업이 발생합니다.

1. 특정 조직과 관련된 문서의 통합. 이 문제는 접두사 메커니즘을 사용하여 쉽게 해결됩니다. 프로그램에 등록된 각 조직에는 자체 문자 접두사가 할당됩니다. 이 접두사는 문서 번호에 추가되어 번호의 고유성을 보장합니다.

2. 디렉토리의 중복 요소 제어. 여러 정보 소스의 데이터를 단일 정보 소스로 전송할 때 정보 시스템디렉터리의 동일한 요소(예: 새 디렉터리의 동일한 상대방)가 여러 번 반복되는 상황이 발생할 수 있습니다. 따라서 데이터를 전송한 후에는 중복된 디렉터리 요소를 비교하고 병합하는 절차를 수행해야 합니다.


3. 당신이 알아야 할 가능한 어려움

새로운 플랫폼으로의 전환 프로세스를 적절하게 계획하면 많은 문제를 피할 수 있습니다. 그러나 프로젝트 구현 단계에서 이미 공개된 구체적인 기능이 많이 있습니다. 우리는 잘못된 사용자 행동으로 인해 발생하는 다양한 오류에 대해 이야기하고 있습니다. 기술적 기능들플랫폼 "1C:Enterprise". 이러한 점을 더 자세히 고려해 보겠습니다.


3.1. 소스 데이터의 오류

일반적으로 TIN 및 KPP 세부정보를 사용하여 데이터베이스에 있는 객체의 명확한 식별이 가능합니다. 7개에서는 이 두 값이 모두 하나의 TIN/KPP 세부사항에 저장되었으며, 이 세부사항에 입력된 데이터의 정확성에 대한 확인은 없었습니다. 소개가 가능했어요 더 적은 숫자, 구분 기호를 잘못된 위치에 배치하고 완전히 추상적인 TIN을 입력합니다.


일반적인 전송에서는 디렉토리를 생성할 때 필요한 문자 수를 잘라내기만 하면 상대방이 TIN과 KPP로 구분됩니다. 따라서 새 데이터베이스의 세부정보에는 완전히 잘못된 데이터가 기록될 수 있습니다. 따라서 이러한 데이터를 사용하여 전송하는 동안 개체를 정확하게 식별하는 것은 매우 어렵습니다.


또 다른 문제는 통일된 데이터 입력 형식이 없다는 것입니다. 각 사용자는 자신이 가장 좋아하는 이름을 입력할 수 있습니다. 하나의 "7" 데이터베이스에서 사용자가 상대방의 "이름"을 입력하고 "Vympel Management Company"라고 썼고, 다른 "7" 데이터베이스에서는 동일한 상대방이 "Vympel Management Company"로 나열되어 있다고 가정해 보겠습니다. 이러한 상황에서 자동 처리는 이것이 동일한 거래상대방인지 판단할 수 없으며 이를 8개로 두 번 이동시킵니다. 잔액의 일부는 한 요소에 있고 두 번째 부분은 다른 요소에 있기 때문에 이러한 데이터베이스에서 추가 작업을 수행하는 것은 어려울 것입니다.


3.2. 구성 차이

전송 오류의 또 다른 그룹은 구성의 기술적 차이로 인해 발생합니다. 일부 비즈니스 거래는 여러 유형의 문서로 "1C:Enterprise 7.7"에 반영되고 "1C:Enterprise 8"에는 하나씩 반영됩니다. 예를 들어, 자재와 상품의 수령은 새 프로그램에 하나의 문서로 반영되고 이전 프로그램에는 두 개로 반영됩니다. 따라서 '자재수령번호 22'와 '상품수령번호 22' 문서를 전송하려고 하면 고유성 제어 오류가 발생합니다. 동일한 번호의 두 문서를 일정 기간 동안 기록하는 것은 불가능하므로 인위적으로 차이점을 도입할 필요가 있으며, 이러한 차이점을 도입하기 위한 체계는 사전에 합의됩니다.


예를 들어, 이 문제로드된 문서 번호에 추가 접두사를 추가하면 문제가 해결될 수 있습니다. 문서의 각 기능에 대해 이 접두사는 별도로 할당됩니다. 이는 문서를 다운로드한 데이터베이스의 특성이거나 다운로드가 이루어진 문서 유형일 수 있습니다. 다음은 이러한 접두사 형성의 예입니다. 크라스노야르스크의 지점 기지에는 접두사 "KR"이 제공됩니다. 다운로드가 이루어지는 문서 유형 "자료 영수증"에는 접두사 "M"이 지정됩니다. 따라서 7의 문서 번호가 00000031이라면 8의 번호는 다음과 같습니다.

“KR” + “M” + “00000031” = “KRM00000031”

결과적으로 데이터베이스에 고유 번호가 기록됩니다.


3.3. 기술적 문제

1C:Enterprise 플랫폼의 기술적 기능으로 인해 데이터 전송 오류가 발생할 수도 있습니다. 예를 들어, 이름별 표준 검색 메커니즘은 디렉토리 요소 이름의 대문자와 소문자를 구분하지 않습니다. 이 메커니즘을 사용할 때 혼란이 있습니다. 예를 들어, 데이터베이스에는 "l-audio"와 "L-Audio"라는 두 개의 상대방이 있습니다. "L-Audio" 상대방을 검색하면 시스템은 "L-Audio"를 찾습니다. 결과적으로 잘못 작성된 문서가 됩니다.


선택한 데이터 전송 방법 자체에도 주의를 기울일 필요가 있습니다. 위에서 설명한 거래 상대방의 두 배 증가에 대한 예는 회사 지점의 데이터베이스에서 전송될 때 실제로 두 배가 되지 않을 수도 있습니다. 서로 다른 도시에서 운영되는 회사는 서로 다른 도시에서 운영되는 거래상대방도 가질 수 있습니다. Nizhny Novgorod에 있는 L-Audio 회사 지점과 모스크바에 있는 L-Audio 회사 자체는 데이터베이스에서 정확히 동일하게 호출될 수 있습니다. 이러한 혼란을 피하기 위해 사전에 이체 방법을 선택해야 합니다. 이 예에서는 원본 데이터베이스에 따라 상대방을 서로 다른 디렉터리 그룹으로 분리할 수 있습니다. 이러한 기술의 선택은 데이터 로딩 메커니즘에도 영향을 미칩니다.


새로운 문제를 해결하기 위해 위에서 설명한 방법은 충분히 보편적이지 않을 수도 있습니다. 데이터를 마이그레이션할 때 마이그레이션 도구에 사용된 방법을 결합할 수 있는 것이 매우 중요합니다. 예를 들어, 우리는 대부분의 디렉토리 요소를 이름으로 식별합니다. 동시에 "회계를 위한 고정 자산 승인" 문서를 전송할 때 이 방법은 동일한 유형의 소형 고정 자산(사무용품, 가구 등)을 여러 개 입력하는 경우 바람직하지 않은 결과를 제공합니다. 재고번호만 다릅니다. 각 회계 승인 문서는 동일한 대상을 나타냅니다. 그리고 회계를 위해 하나의 개체를 여러 번 수락하는 것은 불가능합니다. 따라서 사용되는 데이터 마이그레이션 도구를 사용자 정의할 수 있는 기능을 제공하는 것이 매우 중요합니다. 이 경우에는 반드시 접속번호(코드)로 OS 검색을 해야 함을 간단히 명시하겠습니다.


결론

현재도 1C:Enterprise 7.7을 사용하는 회사가 꽤 많습니다. 이는 새로운 플랫폼의 장점에 대한 이해 부족, 새로운 기술 학습에 대한 거부감, 전환 과정에서 많은 어려움에 직면할 것이라는 두려움 등의 요인 때문입니다. 1C : 회계의 예를 사용하여 이러한 이유의 대부분이 그다지 중요하지 않음을 보여 주려고 노력했습니다. 활동 전반에 걸쳐 우리는 고객이 어떤 문제에도 대처할 수 있도록 돕습니다. 가능한 어려움 1C:Enterprise 8 플랫폼의 프로그램 구현과 관련됩니다. 전환 문제에 관심이 있거나 1C:Enterprise 8 플랫폼 및 이에 생성된 구성에 관한 다른 질문이 있는 경우 회사 전문가에게 문의하세요. "RG-소프트"당신의 서비스에!