표준 1c 구성의 개선. 사전 정의된 요소 추가

1C의 기능을 확장해야 합니까? 표준 문제뿐만 아니라 기업의 특정 문제도 해결하려면 프로그램이 필요합니까? Active-IT의 1C 수정 서비스는 이러한 문제를 신속하게 해결하는 데 도움이 됩니다.

우리는 모든 복잡성 수준의 표준 1C 구성에 대한 수정을 수행합니다. 인쇄된 양식근무 시간 등에 대한 보너스를 계산하는 알고리즘을 도입하기 전에

처리 시간- 최대 5일. 최대 10일 지연되는 경우 무료로 수정해 드립니다.

우리와 함께 일하는 것의 또 다른 장점은 우리가 항상 선의로 일을 한다는 것입니다. 우리는 "알았다" 계획에 따라 일하지 않습니다 기술적인 업무==> 일을 마쳤어요 ==> 제출하고 잊어버렸어요.” 우리는 기술적인 업무를 받고, 업무를 효율적으로 수행하며, 결과를 평가하고 필요한 경우 추가 비용 없이 수정 사항을 조정할 수 있습니다.

1C 프로그래머의 비용

구성 수정 비용: 1500 문지름. 프로그래머 작업 시간당.

결과적으로 다음을 얻습니다.

숙련된 프로그래머와의 협업.
절대적으로 모든 수준의 복잡성에 대한 개선 사항을 생성하고 구현합니다.
최단 시간(최대 5일) 내에 작업을 완료합니다.
시간 지연 시 환불 보장.
품질 보증.

Active-IT에서 1C 회계 수정을 주문하세요!
우리와 함께 기업의 특성에 맞게 1C 작업을 사용자 정의하십시오.

거의 모든 대규모 1C 통합 회사의 거의 모든 프로젝트는 표준 구성 개선으로 구성되며 주로 회계 최적화를 목표로 합니다. 경제 활동적절한 규제 보고를 구성하고 제출합니다. 이는 결국 구현된 솔루션이 자주 변경되는 법률에 따라 수정되어야 함을 의미합니다. 실제로 이는 거의 항상 솔루션의 기반이 되는 표준 구성의 릴리스를 업데이트하고 다음 릴리스의 변경 사항에 따라 이미 수정된 사항을 적용하는 것을 의미합니다.

클라이언트가 지원을 위해 통합업체 조직에 남아 있지 않으면 프로젝트가 완전히 성공했다고 할 수 없는 경우가 많습니다. 그리고 표준 구성 변경에 대한 엄격한 규칙을 준수한다면 지출 후 시간이 거의 없다개발 단계에서는 다음을 수행할 수 있습니다. 앞으로 많은 시간과 신경을 절약할 수 있습니다.변경된 구성을 지속적으로 업데이트합니다. 반대로, 코드 설계에 대한 무례하고 "상관하지 않는" 태도, 작업을 구현하는 올바른 방법보다 더 빠르고 간단한 방법을 선택하면 결과 구성 업데이트가 지원하기 정말 지옥으로 변할 수 있습니다. 앞으로 이로 인해 엄청난 업데이트 시간이 발생하고 보고 기간 동안 개발자의 작업량이 가중될 것입니다. 많은 수의업데이트 후 오류, 고객불만 등

다음은 추가 구성 업데이트를 크게 촉진하는 일반적인 구성의 개발 규칙 세트입니다. 이 코드는 한 훌륭한 회사의 수많은 개발자들의 수년간의 경험을 통해 점차적으로 탄생했으며 제 생각에는 가장 깊은 확신, 작업하는 부서/프로젝트/방향에 관계없이 모든 개발자에게 필수입니다.

1. 표준 구성의 “파괴”를 최소화하는 개념

수정된 표준 구성이 새 릴리스가 출시될 때 업데이트되도록 의도된 경우 개발자는 다음을 수행해야 합니다. 항상 이것을 기억하세요업데이트를 용이하게 하기 위한 조치를 취합니다. 당신은 항상 다음과 같은 문제 해결 방법을 선택해야 합니다. 더 쉬운 구성 업데이트미래에는 구현하기가 다소 어렵더라도 말입니다. 물론 업데이트에 더 편리한 방법이 성능, 코드 이해성 등의 영역에서 심각한 단점이 없다는 조건에서만 가능합니다.

2. 코드 변경 사항에 주석 달기:

모듈의 프로그램 코드에 대한 모든 변경 사항은 반드시 주석 처리되어야 합니다. 변경된 줄 블록은 특별한 형식의 주석 줄로 둘러싸여야 합니다. 이러한 선을 형성하는 원리는 다음 예에 나와 있습니다.

//++ VION 07/20/2016 0001234 시작 시 마무리 //-- VION 07/20/2016

//++ - 블록의 시작
//— — 블록 끝
VION - 개발자의 이름(또는 별명)
0001234 - 추적기에 따른 작업 번호는 시작 주석에만 배치되므로 각 코드 변경은 작업 번호에 의한 전역 검색 결과에 한 번만 나타납니다.
초기 개선— 필요한 경우 사용되는 임의의 설명이지만 작업 번호가 없는 경우 짧은 설명 텍스트가 필요합니다.

설명은 표준 기능과 비교하여 수정 사항을 강조하기 위한 것입니다. 개발자가 동일한 작업의 일부로 일정 시간이 지난 후 자신이 수정한 텍스트를 변경하는 경우 해당 변경 사항은 별도로 주석 처리되지 않습니다(기존 외부 주석도 변경되지 않음). 개발자가 자신의 텍스트를 변경했지만 다른 작업을 수행하거나 다른 개발자가 작성한 코드가 변경된 경우 주석을 사용해야 합니다.

테두리 주석은 편집된 코드 블록의 왼쪽 가장자리에 정렬됩니다. 아래 예에서는 변경 주석을 사용하는 방법을 보여줍니다.

2.1 코드 삽입

예:

Open()에 대한 절차 이것이 New()인 경우 기본값()으로 필드를 채웁니다. endIf; SetFormElements(); //++ VION 07/20/2016 0001234 ConfigureAdditionalElements(); //-- VION 2016/07/20 SetFieldVisibility (); 절차 종료

2.2 코드 제거

예:

프로시저 OnOpen() //++ VION 07/20/2016 0001234 //새 항목인 경우() 그러면 // 기본 필드를 채웁니다(); //EndIf;추가 항목 구성(); //-- VION 2016/07/20 SetFieldVisibility (); 절차 종료

2.3 기존 코드 수정

기존 코드를 변경할 때 이전 블록을 먼저 주석 처리한 다음 새 버전을 작성해야 합니다.

예:

절차 OnOpen() 새로운 경우() 다음 //++ VION 07/20/2016 000123 //기본값으로 필드 채우기(); FieldFillSetting = GetFieldFillSetting(); FillFieldsDefaultExtended(SettingFillFields); //-- VION 2016.07.20 EndIf; SetFormElements(); SetFieldVisibility (); 절차 종료

2.4 모듈에 프로시저 및 기능 추가

추가된 프로시저 및 함수와 표준 개체의 모듈 변수 선언에는 다음이 적용됩니다. 추가 규칙주석 서식 지정:

전체적으로 언급되는 것은 추가된 절차의 블록이 아니라, 각추가된 프로시저나 기능 갈라져.
시작 주석은 프로시저 또는 함수 헤더 앞 줄에 있고, 종료 주석은 다음과 같습니다. 같은 줄에, 공백으로 구분된 "절차 종료" 또는 "절차 종료"라고 표시됩니다.
기존 절차 내 변경 사항에 대한 설명은 다음을 사용하여 수행됩니다. 일반 규칙.

예:

//++ VION 07/20/2016 000123 변수 mSettingField 채우기; 프로시저 수정양식프로그래밍 방식으로 () ... ... 프로시저 종료//-- VION 2016/07/20 //++ VION 2016/07/20 000123절차 날짜배송처리선택 () ... ... 프로시저 종료//-- 비온 2016.07.20

이 규칙을 사용하면 구성의 "절차적 비교"에서 모듈의 변경 사항을 쉽게 전송할 수 있습니다.

다음 줄에 종료 코멘트를 넣으면:

그런 다음 "절차 비교" 중에 이 설명은 텍스트의 다음 절차에 대한 설명으로 인식되어 변경된 것으로 간주됩니다.

3. 최상위 개체 추가

이름 최상위 객체,구성에서 생성되었으며, 반드시회사 접두사 또는 특정 프로젝트 접두사로 시작해야 합니다. 원칙적으로 2~3개로 구성됩니다. 대문자예를 들어 밑줄 AB_. 따라서 생성된 개체는 다음과 같이 호출됩니다. AB_새 디렉토리, AB_NewInformationRegister, AB_새 문서등.

추가된 최상위 개체의 동의어(사용자에게 표시되는 이름)는 괄호로 묶인 접두사로 시작해야 합니다. (AB). 결과적으로 이러한 개체는 목록에서 시각적으로 강조 표시되고 시작 부분에 그룹화됩니다(이로 인해 테스트와 사용이 더 쉬워집니다).

생성된 객체의 주석에는 추가되는 코드와 유사하게 개발자 이름, 날짜 및 작업 번호를 표시해야 하지만 "++" 기호는 제외됩니다. 이렇게 하면 구성 개체가 전역 검색으로 찾은 작업과 연결됩니다.

예: "Projects" 디렉터리를 만듭니다.

개발자 작업: 구성에 다음 디렉터리가 생성됩니다.

이름: AB_Projects
동의어: (AB) 프로젝트

4. 하위 개체 추가

구성 개체 세부 정보를 추가하는 방법은 속성이 추가되는 구성 개체(공급업체가 생성한 구성 개체)에 따라 다릅니다. 표준 용액(즉, 지원 중인 개체) 또는 현재 프로젝트의 일부로 추가된 개체(즉, 이미 접두사가 있는)입니다.

4.1 표준 구성 개체에 하위 개체 추가

기존(표준) 구성 개체에 추가된 하위 개체는 다음을 수행해야 합니다. 접두사가 붙다: AB_추가 소품, AB_NewTabularPart, AB_FormUserSettings, AB_LayoutSpecialInvoice. 그러나 동시에 그러한 하위 개체의 동의어가 생성됩니다. 접두사 없음.

생성된 객체의 코멘트에는 와 유사하게 개발자 이름, 날짜, 작업 번호를 표시해야 합니다. 이렇게 하면 구성 개체가 전역 검색으로 찾은 작업과 연결됩니다.

예: "선지급" 문서의 "프로젝트" 속성을 생성합니다.

개발자 작업: 다음 속성이 구성에 생성됩니다.

이름: AB_Project
동의어: 프로젝트
댓글: // VION 07/20/2016 000123

4.2 프로젝트 내에 추가된 객체에 하위 객체 추가

프로젝트 내 구성에 추가된 최상위 개체에 추가된 하위 개체(예: 이름에 이미 접두사 포함)가 추가됩니다. 접두사 없음. 이러한 하위 개체에 대한 동의어도 생성됩니다. 접두사 없음.

생성된 객체의 코멘트에는 와 유사하게 개발자 이름, 날짜, 작업 번호를 표시해야 합니다. 이렇게 하면 구성 개체가 전역 검색으로 찾은 작업과 연결됩니다. 세부 정보가 최상위 개체 자체와 동일한 작업의 일부로 생성된 경우 설명을 생략할 수 있습니다.

예: "(AB) 프로젝트" 디렉터리에 "책임" 속성을 만듭니다.

개발자 작업: 작업이 "(AB) 프로젝트" 디렉터리가 생성된 것과 다른 경우 구성에 다음 세부 정보가 생성됩니다.

이름: 담당
동의어: 책임
댓글: // VION 07/20/2016 000456

5. 미리 정의된 요소 추가

사전 정의된 디렉토리 요소, 특성 유형 차트 및 계정 차트를 추가할 때 하위 개체를 추가할 때와 동일한 규칙을 사용해야 합니다( 표 부분, 세부 정보)를 최상위 개체로 변환합니다.

5.1 표준 구성 객체에 미리 정의된 요소 추가

일반적인 구성 개체에 대해 사전 정의된 요소가 반드시 추가됩니다. 접두사가 있는. 이름이 주어집니다 접두사 없음.

예:"원가회계" 계정과목표 – 엄격한 보고 양식에 사전 정의된 계정 10.15를 추가합니다.

개발자 작업: 다음과 같은 사전 정의된 계정을 추가합니다.

이름: AB_FormsStrictReporting
코드: 10.15
이름: 엄격한 보고 양식

일반적인 구성 개체(예: 송장)의 사전 정의된 요소의 이름을 변경해야 하는 경우 개체 자체를 변경하지 않은 상태로 두고 특수 .

5.2 프로젝트 내에 추가된 개체에 미리 정의된 요소 추가

사전 정의된 요소는 프로젝트 내에 추가된 구성 개체에 추가됩니다. 즉, 이름에 이미 접두사가 포함되어 있습니다. 접두사 없음이름과 직위에.

6. 공통 모듈의 사용과 엄격한 구조

구성에서 반복적으로 사용되는 절차와 기능, 구독 및 루틴 작업을 위한 프로세서는 공통 모듈에 위치합니다. 이러한 목적을 위해 다음을 추가해야 합니다. 자체 모듈, 최상위 개체에 의해 추가되고 표준 모듈은 남김 변하지 않은. 다음 공통 모듈(“AB_”는 접두사임)은 개발 중에 유용합니다.

AB_범용 (클라이언트, 서버, 외부 연결) - 일반적인 절차 및 기능을 수용합니다.
AB_서버 (서버 전용) - 서버 환경에서 반드시 실행해야 하는 프로시저 및 기능입니다.
AB_글로벌 - 표준 방식(모듈 이름 및 기간을 통해)으로 호출하기 불편한 프로시저 및 기능의 경우.
AB_특권 - 항상 전체 권한으로 실행되어야 하는 프로시저 및 기능의 경우.
AB_재사용 - 일부 함수의 반환 값을 캐시합니다.

기능 블록의 코드를 별도의 공통 모듈에 넣을 수 있습니다. 대용량, 이 경우 구성 저장소를 사용할 때 해당 코드 디버깅이 단순화됩니다. 다른 경우에는 개발자가 구성에 새 모듈을 추가하기 전에 적합한 공통 모듈을 사용할 수 있는지 확인해야 합니다.

7. 구독 이용 및 엄격한 구조

표준 구성 개체와 관련된 다양한 이벤트를 처리하려면 가능하면 개체 자체의 모듈을 수정하는 대신 구독 메커니즘을 사용해야 합니다.

각 이벤트마다 다음이 있을 수 있습니다. 구독은 1개 이하(메타데이터 객체로서) 핸들러와 관련 코드가 배치되어야 합니다. 별도의 공통 모듈(개발자의 스토리지 작업 병렬성을 높이기 위해) 구독 이름과 공통 모듈 이름은 다음과 같아야 합니다. 동일하다그리고 대응하다이벤트가 처리되고 있습니다. 구독 소스가 표시됩니다 모두잠재적으로 처리 가능한 개체(모든 디렉터리, 모든 문서 등)

구독 처리기 프로시저에는 필요한 작업을 수행하는 하위 프로시저에 대한 호출이 포함되어야 합니다. 소스 유형과 필요한 순서에 따라 액세스됩니다. 새 작업에 대한 코드를 추가할 때 구독 모듈에서 주석 처리가 수행됩니다.

예: "선납금" 전표를 전기할 때 누적등록부 "(AB)사업비"에 기재합니다.

개발자 작업:

1. "AB_DocumentsProcessingProcessing" 구독을 생성하고(이러한 구독이 이전에 생성되지 않은 경우) 모든 문서를 소스로 지정하며 이벤트는 "ProcessingProcessing"입니다.

2. 공통 서버 모듈 “AB_DocumentsProcessing”을 생성합니다.

3. 모듈에서 "ProcessingProcessing" 내보내기 프로시저를 생성합니다. 이전에 생성된 구독에 대한 처리기로 이 프로시저를 선택합니다. 절차에서는 문서 유형에 따라 필요한 핸들러가 호출됩니다.

4. "선불" 문서 모듈은 변경되지 않습니다.

8. 양식 편집

8.1 표준 개체의 모양 편집

표준 양식(일반 양식과 관리 양식 모두)에 대한 변경 사항이 작은 경우(예: 양식에 몇 가지 새로운 세부 정보 추가) 이러한 변경은 완전히 프로그래밍 방식으로 수행되어야 합니다. 즉, 변경 사항은 다음에만 적용됩니다. 양식 모듈, 양식 자체는 구성자에 남아 있습니다. 변하지 않은. 일부 개발자는 처음에는 이 양식 편집 방법이 상당히 번거로울 수 있습니다. 그러나 프로그래밍 방식으로 양식을 변경하는 데 충분한 경험이 있으면 하나의 요소를 추가하는 데 3~5분도 걸리지 않습니다. 소요된 시간은 표준 구성에 대한 후속 업데이트를 통해 여러 번 보상됩니다.

예: '선불' 문서 기본 양식에 '(AB) 프로젝트' 세부정보를 추가합니다.

개발자 작업: 양식 처리기 "When CreatedOnServer"에 "EditFormProgrammatically()" 프로시저를 추가합니다. 이 절차에서는 원하는 요소를 양식 요소에 추가합니다.

표준 양식을 변경하는 데 필요한 모든 절차와 기능을 포함하는 별도의 모듈을 만드는 것이 가능합니다.

BSP 2 기반의 일반적인 구성에는 다음과 같은 목적을 위한 특수 기능이 이미 있습니다.

일반 모듈 "구성 재정의"의 "CreateOnServer" 절차에서 고유한 핸들러를 호출할 수 있습니다.

양식 이름으로 양식을 프로그래밍 방식으로 수정하여 필요한 절차를 호출할 수 있습니다.

양식에 추가할 계획이라면 많은 수의 요소또는 테이블 형식 부품의 경우 수동으로 재구성할 수도 있습니다. 이 경우 양식에 별도의 탭을 만들고 필요한 모든 요소를 그 위에 배치하는 것이 좋습니다. 이렇게 하면 향후 양식 업데이트가 훨씬 쉬워질 것입니다.

8.2 프로젝트 내에 추가된 개체의 모양 편집하기

프로젝트 내에 추가된 개체의 형태(즉, 이름에 접두사가 있는 개체)는 일반적인 방법으로 편집됩니다.

9. 역할 작업의 원칙

일반 역할은 항상 변경되지 않은 상태로 유지되어야 합니다(가능한 경우). 역할을 비교하고 복원하는 것은 복잡하고 힘든 프로세스이기 때문에 이는 새 릴리스에서 변경된 구성을 쉽게 업데이트하는 데 필요합니다.

구성에 추가된 개체에 대한 권한을 할당해야 합니다. 새로운이 목적을 위해 생성된 역할입니다.

일반적인 역할에 의해 허용되는 데이터에 대한 액세스 제한을 구현해야 합니다. 프로그래밍 방식으로, 가능하지만. 그리고 그러한 금지 사항을 프로그래밍 방식으로 구현하기가 매우 어려운 경우(또는 그러한 솔루션을 신뢰할 수 없는 경우)에만 표준 역할을 수정하는 것이 허용됩니다. 일반적인 역할에 대한 변경은 최소한으로 필요하고 문서화되어야 합니다. 예를 들어 역할(RLS)에서 액세스 제한 텍스트를 변경해야 하는 경우 에 따라 모든 샘플 코드를 주석 처리한 다음 필요한 변경 사항이 포함된 코드를 추가해야 합니다.

10. 외부 보고 및 처리

대부분의 시스템 개선은 추가 보고서 및 처리 메커니즘을 사용하여 수행할 수 있습니다.

BSP 2(ERP, UT 11, BP 3.0, ZUP 3.0 등) 기반 구성에서는 이 메커니즘이 크게 확장되었습니다. 도움을 받으면 구성을 변경하지 않고도 외부 보고서를 생성하고 처리(명령 인터페이스에 실행 명령을 배치하고 다양한 사용자에 대한 액세스를 구성하는 기능 포함), 문서 작성 처리, 추가 인쇄 양식 등을 기반으로 문서 작성

이 기사가 도움이 되었나요?

1C 8.2 및 8.3은 매우 중요한 경쟁 우위— 1C 표준 구성을 수정하고 플랫폼을 기반으로 자체 솔루션을 개발하는 기능. 이는 내장된 개발 환경 덕분에 달성됩니다.

고객을 걱정하는 1C 회사는 시장의 모든 조직에 가장 적합한 솔루션을 생산하려고 노력하고 있습니다. 사람과 마찬가지로 모든 회사는 독특합니다. 이는 귀하의 필요에 맞게 1C 구성을 "조정"하는 것입니다.

1C에서는 일반적으로 어떤 새로운 일이 수행됩니까?

일반적으로 수정은 프로그램의 인터페이스 부분과 관련됩니다. 그러나 새로운 하위 시스템, 새로운 알고리즘 도입 등 구성에 대한 심각한 수정도 있습니다.

1C 8.3의 변경 사항 예:

사용자 권한 설정및 기본값. 유연한 권한 구성 - 매우 중요한 점. 사용자와 그들의 권리는 다중 사용자 시스템에서 작업하는 것이 불가능한 것입니다.
변화와 새로운 창조 인쇄된 양식. 인쇄된 양식은 1C의 문서와 동일한 종이입니다. 기존 항목을 개선하고 새 항목을 추가하는 것이 모두 가능합니다. 구성을 변경하지 않고도 인쇄된 양식을 편집할 수 있습니다.
새 항목 만들기 및 기존 항목 수정 보고서. 보고서는 모든 분석의 최종 결과물입니다. 정보 시스템, 1C Enterprise 포함. 프로그램의 보고서는 구성을 변경하지 않고도 수정할 수 있습니다.
. 일반적으로 기술에 능숙하지 않은 클라이언트가 항상 프로그래머를 위한 유능한 기술 사양을 작성할 수는 없습니다. 동시에 작업 자체는 사내에서 또는 타사에서 완료할 수 있습니다.
구성에 추가 새로운 기능. 1C는 보편적인 시스템이므로 모든 고객의 희망 사항을 고려할 수 없습니다. 유능한 전문가는 프로그램의 기능을 크게 확장하고 이를 "완벽하게" 통합할 수 있습니다.
1C 성능 최적화. 1C Enterprise 시스템은 성능 측면에서 해당 부문의 리더 중 하나입니다. 그러나 획득하려면 최대 속도시스템이 작동하려면 고객의 IT 인프라에 맞게 맞춤화된 일부 변경이 필요합니다.

1C 전문가의 한 시간 작업 가격

표준 1C 구성을 수정하는 작업 비용은 일반적으로 노동 시간으로 추정됩니다.

글쎄요, 모두들 고양이에 오신 것을 환영합니다.

추가 지원 및 업데이트를 용이하게 하기 위해 표준 1C 구성을 마무리하는 규칙 및 기술

따라서 우리가 프로젝트(“우리”라는 단어는 비즈니스 프로세스 자동화에 참여하는 모든 사람을 의미함)를 수행할 때 해당 프로젝트가 원활하게 지원되기를 바랍니다. 원칙적으로 모든 것이 잘 이루어지고 고객이 만족하면 이런 일이 발생합니다.

지원은 매우 구체적인 작업 세트로 특징지어집니다. 이는 "이 숫자의 출처"와 같은 상담 작업 또는 이해할 수 없는 오류 수정 등이 될 수 있습니다. 그러나 거의 모든 프로젝트에는 고객의 요구 사항에 맞게 일부 표준 솔루션을 적용하는 작업이 포함되므로 지원 구성은 정기적으로 새 릴리스로 업데이트되어야 합니다.

일부 개발 규칙을 따른다면 프로젝트 단계에서 거의 노동력을 들이지 않고도 나중에 구성을 유지하고 업데이트하는 비용을 절약할 수 있습니다.
반대로, 프로젝트 단계에서 일부 오류, 성급함 또는 잘못된 코드 형식이 있는 경우 나중에 엄청난 지원과 업데이트가 발생할 수 있습니다.

식별 표시 없이 다시 작성된 구성을 업데이트해야 했던 사람이 있습니까? 이전 공급업체 구성을 새 구성과 비교하고, 현재 구성과 비교할 때 "두 번 변경된" 각 사례를 수동으로 구문 분석하는 것이 얼마나 어려운 일인지 이해하십니까? 이것은 모두 상당히 문제가 있습니다.

표준 구성의 수정을 설계하기 위한 9가지 간단한 규칙

1. 표준 구성의 “파괴”를 최소화하는 개념

첫 번째는 규칙조차 아니며 표준 구성의 "파괴"를 최소화하기 위한 일종의 개념입니다.

그 핵심은 그러한 솔루션을 구현하기가 다소 어렵더라도 미래에 더 쉬운 구성 업데이트를 제공할 수 있는 문제 해결 방법을 항상 선택해야 한다는 것입니다. 이 작업은 광신적인 생각 없이 합리적인 한도 내에서 수행되어야 한다는 것은 분명하지만 개발자는 구성이 계속 지원된다는 점을 항상 기억하고 자신의 코드가 향후 구성 업데이트를 얼마나 복잡하게 하는지 분석하여 가장 적절한 솔루션을 선택해야 합니다.

2. 코드 변경 사항에 주석 달기

두 번째 규칙은 내가 모든 코드 변경 사항은 주석 처리되어야 합니다..

우리 회사에서는 다음 계획을 사용합니다.

변화의 시작은 오프닝 코멘트(기호로 시작 //++ )
결국 - 마무리 코멘트(기호로 시작 //-- )
ㅏ 개발자가 변경한 사항은 중간에 있습니다..

이는 모든 변경에 대한 필수 규칙입니다.

시작 및 종료 댓글에는 변경 표시가 있습니다.. 그것은 다음을 포함합니다 구성요소:

프로젝트 접두사- 기본적으로 FTO를 사용합니다.
개발자 도메인 이름. 매우 편리하게 구성되어 있습니다. 회사는 규모가 크고 분산되어 있으며 개발자를 모르지만 그에 대해 물어봐야 할 경우 이 태그에서 그의 별명을 가져와 @fto.com.ru를 입력할 수 있습니다. 그에게 연락할 수 있도록 편지를 보내세요.
다음은 온다 수정 날짜. 여러 작업의 프레임워크 내에서 변경 사항이 발생하면 이러한 주석 묶음은 서로 중첩될 수 있으며 이 종료 주석이 어느 시작 블록에 속하는지 항상 명확하지 않으므로 날짜에 중점을 둡니다. 또한 날짜는 수정된 날짜(3년 전, 6개월 전 또는 어제)를 즉시 표시합니다.
그럼 온다 태스크 번호, 어느 시작 코멘트에만 배치됨. 왜 거기에만? 따라서 작업 번호로 전역 검색을 수행하는 동안 코드 변경의 시작 부분만 선택 항목에 포함되며, 여기서 아래를 볼 수 있습니다. 그렇지 않으면 이중이 발생합니다. 예를 들어 코드 리뷰에 작업을 제출할 때 태그별로 구체적으로 검색하는 것이 매우 편리합니다.

예

이것이 바로 그 모습이다 코드를 입력하세요:

이것이 바로 그 모습이다 코드 제거- 코드를 완전히 제거하지 않고 코드에 주석을 달았습니다. 이로 인해 주석 처리된 내용을 항상 확인할 수 있으며, 문제가 발생하면 빠르게 돌아갈 수 있습니다.

이것이 바로 그 모습이다 코드 변경: 먼저 벤더 코드를 모두 주석 처리한 후, 자신만의 코드를 추가합니다.

별도의 규칙이 작동합니다. 프로시저, 함수 및 전역 모듈 변수를 추가하려면. 이 경우 닫는 설명은 다음과 같은 줄에 배치됩니다. 예어절차 종료. 왜 이런 일이 일어났습니까? "절차적 비교"를 사용하여 수정 사항을 편리하게 전송할 수 있습니다.

여기 사진을 보면 알 수 있죠 "절차적 비교"를 사용하면 병합할 때 이 절차를 간단히 강조할 수 있습니다., 그리고 (마크와 함께) 완전히 전송됩니다. 또는 그 반대로 전송하지 않도록 옆에 있는 확인란을 선택 취소할 수 있습니다.

그리고 종료 코멘트가 다음 줄에 있으면 다음 절차에 할당되며 추가 비용 없이 단순히 이전하는 것은 불가능합니다.

3. 최상위 개체 추가

다음 규칙은 구성에 최상위 개체(디렉터리, 문서, 레지스터 등)를 추가하는 것입니다.

이 규칙은 객체 이름은 접두사로 시작해야 합니다.무엇을 위해?

첫째, 구성과 코드에 추가된 요소를 시각적으로 강조합니다. 이것이 우리가 추가한 객체라는 것이 즉시 분명해집니다..
둘째, 이름의 고유성이 달성되었습니다., 공급자가 동일한 이름을 가진 자체 개체를 추가할 수 있기 때문입니다. 그리고 자체 접두사를 사용하면 이름이 고유하다는 것이 보장됩니다.

객체 동의어는 괄호 안의 접두사로 시작해야 합니다.. 이를 통해 인터페이스에 추가된 개체를 강조 표시할 수 있습니다.

물론 이는 매우 논란의 여지가 있는 규칙이며, 그 사용은 고객과 합의되어야 합니다. 우리 고객들은 이 계획에 만족했고, 그래서 그것은 우리에게 뿌리를 내리고 규칙의 일부가 되었습니다. 하지만 여기서 이 작업을 수행할지 여부를 결정하는 것은 귀하와 고객의 몫입니다.

마지막 규칙은 추가된 모든 객체에 대한 주석에는 개발자 이름과 작업 번호가 포함된 특수 라벨이 포함되어야 한다는 것입니다. 이 레이블은 특수 문자 없이만 모듈의 시작 주석과 유사합니다. 이 레이블을 사용하면 누가, 언제, 어떤 작업을 위해 이 개체를 추가했는지 항상 이해할 수 있습니다.

요약하면 다음과 같습니다.

이름은 접두사로 지정됩니다.
동의어 - 괄호 안에 접두어 포함
그리고 댓글에는 특수 태그가 포함되어야 합니다.

4. 하위 개체 추가

하위 개체를 추가한다는 것은 소품, 레이아웃, 양식 등을 추가하는 것을 의미합니다. 구성 객체로.

여기서는 하위 개체를 추가하는 두 가지 상황을 즉시 강조해야 합니다.

일반적인 구성 개체에서
또는 프로젝트 내에서 이전에 추가된 일부 개체에.

이러한 각 상황을 개별적으로 고려해 보겠습니다.

표준 구성 개체에 하위 개체를 추가하려면다음 규칙이 적용됩니다.

이름은 동일한 접두사로 시작해야 합니다.. 이로 인해 우리는 이름의 고유성을 얻었으며 시각적으로도 이것이 우리의 대상이라는 것이 항상 분명해졌습니다.

동의어는 접두사 없이 입력됩니다., 여기서는 더 이상 개체, 세부 사항을 강조할 필요가 없기 때문입니다.

그리고 마지막으로, 댓글에는 특수 태그도 포함되어 있습니다., 누가, 언제, 왜하는지 명확하게 알 수 있습니다.

따라서 일반적인 구성 개체에 하위 개체를 추가하는 방법을 요약해 보겠습니다.

이름은 접두사로 지정됩니다.
일반 규칙에 따른 동의어
그리고 댓글에는 특별한 라벨이 포함되어 있습니다.

ㅏ 프로젝트 내에서 이전에 추가된 개체에 하위 개체를 추가하는 경우이름에 이미 접두사가 포함되어 있는 경우:

그들의 이름에는 접두사가 포함되어서는 안 됩니다., 개체가 이미 고유하다는 것이 이미 분명하고 다른 방법으로 특별히 강조 표시할 필요가 없기 때문입니다.

이러한 하위 개체에 대한 동의어도 접두사 없이 지정됩니다., 특별한 선택이 필요하지 않기 때문입니다.

그리고 이 하위 개체가 다른 작업의 일부로 추가된 경우에만 주석에 특수 레이블이 포함됩니다. 내 작업에 이러한 세부 사항이 포함된 문서를 추가해야 한다고 명시되어 있으면 각 세부 사항에 대해 그러한 레이블을 붙일 필요가 없기 때문입니다. 하지만 업무가 완전히 다른 경우에는 왜 그 일을 했는지 명확히 알 수 있도록 표시를 꼭 합니다.

이제 프로젝트 내에 추가된 개체에 하위 개체가 추가되는 방법을 요약해 보겠습니다.

접두사가 없는 이름입니다.
접두사가 없는 동의어.
그리고 댓글이 다른 작업의 일부로 추가되는 경우에만 특수 라벨을 포함해야 합니다.

두 경우 모두에 대해 이 규칙을 결합하고 "조각으로 나누면" 다음 표를 얻을 수 있습니다.

새로운 객체:
- 이름은 접두사로 시작됩니다.
- 동의어 - 괄호 안에 접두사가 있습니다.
- 댓글에 라벨이 포함되어 있습니다.
일반 객체에 추가하는 하위 객체:
- 이름은 접두사로 시작합니다.
- 일반 규칙에 따른 동의어
- 댓글에 태그를 달아주세요.
그리고 프로젝트 내에 추가된 개체에 하위 개체를 추가하면
- 이들에게는 특별한 규정이 없으며,
- 하지만 작업이 다른 경우에는 동일한 방식으로 댓글에 태그를 추가합니다.

5. 미리 정의된 요소 추가

다음 규칙은 미리 정의된 요소를 추가하는 것입니다.

여기서는 정확히 같은 방식으로 두 가지 상황을 구분할 수 있습니다.

일반적인 구성 개체(참조 서적, 특성 유형 계획)에 사전 정의된 요소를 추가하는 경우
그리고 프로젝트 내에 추가된 개체에 미리 정의된 요소를 추가하는 경우입니다.

일반 구성 객체에 미리 정의된 요소를 추가하는 경우,

그의 이름비슷한 접두사로 시작해야 합니다.. 따라서 우리는 이름의 고유성을 보장하고 추가된 요소를 즉시 시각적으로 식별할 수 있습니다.
코드 및 이름형성될 것이다 일반 규칙에 따라,
하지만 상표여기서는 불행하게도 둘 곳도 없어. 따라서 전역 작업 검색을 사용하여 추가된 사전 정의된 요소를 찾는 것은 불가능합니다.

ㅏ 프로젝트 내에 추가된 객체에 미리 정의된 요소를 추가하는 경우, 저것

그의 이름에는 접두사가 포함되지 않습니다., 어떻게든 강조할 필요가 없기 때문입니다.

따라서 이전 표와 유사점을 그리면 다음과 같습니다.

일반 객체에 대해 미리 정의된 요소에는 접두사,
나머지는 모두 일반 규칙에 따라 특별한 접두사를 추가할 필요가 없습니다.

6. 공통 모듈의 사용과 엄격한 구조

다음 규칙은 공통 모듈의 사용과 이를 위한 엄격한 구조의 구성에 관한 것입니다.

첫째, 반복적으로 사용되는 다양한 프로시저, 함수, 구독 핸들러 및 루틴 작업의 경우 표준 모듈을 변경하지 않고 자체 모듈을 추가해야 합니다. 그리고 개발자가 표준 모듈에 일종의 내보내기 절차를 배치하려는 경우에는 그렇게 할 필요가 없으며 자신만의 모듈을 만들어야 합니다.

두 번째로 주의할 점은 공통 모듈은 최상위 개체 추가 규칙에 따라 추가됩니다.(이름 및 접두사와 동의어, 주석의 태그 등)

제삼, 모듈 이름은 해당 표준 모듈과 유사해야 합니다..

휠을 재발명할 필요가 없습니다. 표준 구성에서 관례적인 것과 동일한 방식으로 호출합니다. 각 기능에 대해 1C에서 일반적으로 허용되는 지정에 해당하는 자체 모듈이 있습니다. 예를 들어:

FTO_범용 클라이언트,
FTO_범용 서버,
FTO_범용 글로벌,
FTO_RoutineTasksServer
등.

그리고 일부 대규모 개별 작업당신은 할 수 있습니다 (그리고 아마 그래야 할 것입니다) 별도의 공통 모듈에 넣기.

7. 구독 이용 및 엄격한 구조

다음 규칙은 구독 사용과 엄격한 구조입니다. 그 본질은 무엇입니까?

일반 객체와 관련된 다양한 이벤트를 처리하려면 구독을 사용해야 합니다., 와 같은:

녹음하기 전에
녹음할 때
등.

물론 가져갈 수도 있어요 표준 개체 모듈을 편집하고,적절한 절차에 코드를 삽입하면 됩니다. 하지만 이것은 - 나쁜 방법.
더 나은이것 대신에 이 이벤트를 처리하려면 구독을 추가하세요..

구독은 다음과 같이 합의된 규칙에 따라 추가됩니다.

시스템에서 동일한 유형의 모든 이벤트에 대해 하나의 구독만 추가됩니다.. 예를 들어, "디렉터리 쓰기 전" 이벤트에서 다양한 디렉터리에 대해 자체 알고리즘을 사용해야 하는 경우 이러한 모든 디렉터리에 대해 "디렉터리 쓰기 전"이라는 추가 구독 하나만 사용합니다.
소스는 이 클래스 내의 모든 개체를 선택합니다.(예: 모든 디렉터리)
추가된 구독의 경우 정확히 동일하게 호출되는 별도의 모듈이 생성됩니다.(편의상).
기본 이벤트 핸들러에서는 객체 유형을 분석하는 조건이 정의됩니다.(디렉토리 유형).
그리고 이미 객체 유형에 따라 특정 작업이 수행됩니다..

예를 들어 보여드릴 수 있습니다. 다음과 같은 작업이 있다고 가정합니다. "사전 보고서" 문서를 게시할 때 이전에 추가된 누적 등록부에 항목을 입력합니다.

먼저 모든 규칙에 따라 일반 모듈 FTO_DocumentsProcessingProcessing을 추가합니다.

DocumentObject(모든 문서)를 소스로 지정합니다.
위에 추가된 모듈은 핸들러로 사용됩니다.

그리고 이미 모듈의 핸들러 자체에서 어떤 종류의 문서가 우리에게 왔는지 확인하고 해당 유형에 따라 하나 또는 다른 프로시저를 호출합니다.

구독은 하나이지만 작업은 다를 수 있습니다. 티프로시저가 호출되는 순서를 제어할 수도 있습니다.

결과적으로 구독을 생성하는 절차는 다음과 같습니다.

하나의 구독,
하나의 공통 모듈
그리고 다른 것은 필요하지 않습니다. 문서 모듈은 변경되지 않은 상태로 유지됩니다. 더 이상 "두 번 변경된" 항목에 표시되지 않습니다.

8. 양식 편집

다음 규칙은 양식을 편집하는 것입니다.

여기서는 두 가지 사항, 두 가지 상황을 강조하겠습니다.

표준 양식을 편집할 때
그리고 프로젝트 내에 추가된 양식을 편집할 때.

첫 번째 상황은 편집 중입니다.전자 표준 양식, 전형적인 사물의 형태. 이것은 규칙에서 가장 논란이 많은 부분입니다. 한때, 기존의 양식이 나오던 시절, 주로 SCP를 중심으로 프로젝트를 진행하던 시절, 우리는 양식을 어떻게 해야 할지 많은 논의를 하기도 했습니다. 옵션은 무엇이었나요?

일반 양식 직접 편집수동으로 모양을 변경하는 것뿐입니다. 이 옵션을 사용하면 공급업체가 이 양식을 변경할 때마다 모든 변경 사항을 다시 전송해야 합니다. 나쁜 방법.
또 다른 방법은 양식 복사본 만들기. 표준 양식을 복사하여 기본 양식으로 지정하고 변경하는 작업입니다. 하지만 공급업체가 이 양식을 변경하면 변경 사항을 내 버전으로 수동으로 전송해야 합니다. 최선의 방법은 아니다.
또 다른 옵션은 별도의 탭 생성. 양식에 별도의 탭을 만들고 그 위에 요소를 배치합니다. 때때로 요소를 양식의 특정 위치에 삽입해야 하기 때문에 이 방법은 유연하지 않습니다. 또는 표준 요소의 속성을 변경하고 해당 요소에 새 핸들러를 할당해야 하는 등의 작업이 필요합니다. 그러므로 이 유연하지 않은 방식- 그것도 잘 안 돼요.
결과적으로 우리는 완전히 프로그래밍 방식으로 양식을 편집하는 방법을 선택했습니다.. 처음에 이 방법을 접하지 못한 새로운 개발자는 프로그래밍 방식으로 양식을 편집하는 것이 매우 어렵다는 것을 알게 됩니다. 그러나 실제로는 그렇지 않습니다. 내 경험으로 볼 때 나는 당신이 그것을 더 잘해야 한다고 말할 것입니다. 게다가 우리는 프로그래밍 방식으로 양식을 변경하기 위한 내보내기 절차가 포함된 모듈을 오랫동안 작성해 왔으며 이 모든 작업이 매우 쉽게 수행됩니다. 관리되는 양식이 등장했을 때 프로그래밍 방식으로 양식을 변경하는 이러한 방식도 관리되는 양식으로 완전히 전환되었습니다. 게다가 편집도 통제된 형태프로그래밍은 일반적으로 쉬워졌습니다. 기존 형식과 비교할 수 없습니다.

예를 들어 보여 드리겠습니다. OnCreateOnServer 처리기에서 EditFormProgrammatically 프로시저에 대한 호출을 추가합니다. 여기서 프로그래밍 방식으로 양식에 요소를 추가합니다.

BSP 2 기반 구성(ERP, 회계 등) 추가 이벤트 handlerForm.WhenCreatedOnServer(), 무엇보다도, 들어 온다또한 재정의된 모듈에.

그래서 재정의된 모듈에 자신만의 코드를 추가할 수 있습니다.- 예를 들어 WhenCreatingOnServer() 프로시저에 포함됩니다. 여기서는 양식의 이름을 정의하고 이에 따라 하나 또는 다른 프로시저를 호출하여 프로그래밍 방식으로 요소를 추가합니다.

이 계획은 번거롭고 어려운 것처럼 보이지만 실제로 모든 프로젝트가 이러한 규칙에 따라 수행되면 개발자는 작업을 받을 때 어디를 볼지, 어디에 무엇을 추가할지 즉시 알 수 있습니다. 그래서 참 편리한 것 같아요.

또한 BSP 2 기반 구성에서는 When ReadingOnServer(), BeforeWritingOnServer() 등과 같은 다른 양식 처리기가 재정의됩니다. 그리고 이러한 핸들러에서는 호출된 프로시저의 재정의를 적극적으로 사용할 수도 있습니다. 게다가 공급자가 재정의한 모듈은 이론적으로 변경되지 않으며 충돌에 대한 두려움 없이 자신만의 코드를 작성할 수 있습니다.

프로젝트의 일부로 추가된 양식을 편집하는 경우 특별한 작업을 수행할 필요가 없습니다. 일반적인 방법으로 직접 편집합니다.

9. 역할 작업의 원칙

마지막 규칙은 역할 작업의 원칙입니다.

역할 작업의 원칙은 다음과 같습니다.

가능하다면 일반적인 역할은 항상 이름을 지정하지 않은 상태로 두어야 합니다.. 전형적인 역할을 바꾸는 것이 정말로 필요한지, 아니면 뭔가 다르게 할 수 있는지 신중하게 생각해야 합니다.
특별히 생성된 새 역할에 추가된 구성 개체에 대한 권한을 할당합니다.따라서 구성에 보고서를 추가했는데 이전에 추가한 적절한 역할이 없으면 별도의 역할을 만듭니다. 그런 다음 이 역할이 필수 프로필에 추가됩니다. 그러나 일반적인 역할은 변하지 않습니다.
그리고 변경사항이 있는 경우RLS, 그런 다음 모듈 편집 규칙에 따라 형식이 지정됩니다..

예를 들어 RLS를 변경해야 하는 경우 시작 주석을 작성하고 이전 코드에 주석을 추가한 다음 내 코드를 추가하고 종료 설명을 추가합니다. 누가, 왜(어떤 작업에서), 언제 변경했는지는 항상 명확합니다.

그래서 9개를 모두 나열했어요 간단한 규칙수정사항 등록.

삶을 더 쉽게 만들어주는 추가 개체 및 기술

마지막으로 개발자의 삶을 더 쉽게 만들어 줄 수 있는 몇 가지 개체와 기술을 다루겠습니다.

1. 테스트 데이터베이스의 자체 식별

첫 번째 기술은 테스트 데이터베이스를 자체 식별하는 것입니다.

요점은 다음과 같습니다.

작동 중인 생산 데이터베이스의 주소를 저장하는 상수가 있습니다..
시스템이 시작되면 이 주소가 확인됩니다.: 작업 중인 기본 주소와 일치합니까, 아니면 일치하지 않습니까?
그리고 일치하지 않는 경우(베이스가 작동하지 않음) 시스템 헤더를 교체하는 중입니다..

스크린샷은 어떻게 생겼는지 보여줍니다. 이는 개발자(또는 컨설턴트)가 많은 데이터베이스(작업, 테스트, 개발 등)를 열어두고 실수로 실수를 해서 작업 데이터베이스의 데이터를 변경할 수 있는 경우에 특히 유용합니다. 제목이 변경되면 "자동으로" – 왼쪽 상단을 보고 어떤 종류의 데이터베이스인지 확인하세요. 예, 테스트해 보세요. 변경할 수 있습니다.

이러한 방식으로 정보베이스의 데이터 변경을 더욱 안전하게 만듭니다.

게다가, 일부 일상적인 작업을 수행할 때 이 상수의 값을 확인하는 것도 유용합니다.. 즉:

데이터 교환,
사용자 알림,
일부 우편물
무거운 규제 업무.
등.

개발자는 이러한 일상적인 작업을 생성할 때 그것이 작업 기반인지 아닌지를 확인해야 합니다. 이론적으로 모든 테스트 데이터베이스에서 클러스터 콘솔에서 일상적인 작업을 비활성화해야 한다는 것은 분명합니다. 그러나 누군가가 창조할 때 항상 인적 요소가 있습니다. 새로운 기지, 새로운 데이터를 로드하고 무언가를 변경했으며 그 결과 작업 데이터베이스와 일부 중요한 교환이 발생했습니다. 그리고 대결-왜 이런 일이 일어 났습니까? 그렇기 때문에 우리는 크리티컬하기 전에 일상적인 작업우리는 항상 작동 중인 데이터베이스인지 여부를 확인합니다..

BSP 2 기반 구성에는 유사한 메커니즘이 있습니다.: 위치인 경우 정보 기반변경되면 질문이 제기됩니다. 이것이 데이터베이스의 복사본인지 아니면 데이터베이스가 이동되었는지입니다. 원칙적으로 이 메커니즘은 충분할 수 있지만 인적 요소가 간섭할 수 있으며 누군가는 무슨 일이 일어나고 있는지 이해하지 못하고 잘못된 버튼을 누를 것입니다. 그렇기 때문에, 제 생각에는 상수가 더 안정적입니다.

2. 초기화 처리

다음 트릭은 초기화 처리입니다.

이는 코드에 현재 버전이 포함된 구성에 추가된 처리입니다.
동시에 초기화 처리의 현재 버전을 저장하는 일부 상수도 구성에 추가됩니다.
시스템이 시작되면 점검이 수행됩니다.
그리고 버전이 변경된 경우 필요한 핸들러가 실행되고 새로운 상수 값이 설정됩니다.

이것이 왜 필요한가요? 구성에 새 기능을 추가할 때 데이터베이스 자체에서 일부 작업을 수행해야 하는 경우가 많습니다. 예를 들어 사전 정의된 디렉터리 요소를 추가한 후 이제 해당 세부 정보를 입력해야 합니다. 프로젝트에는 많은 데이터베이스가 있을 수 있으며 이 데이터를 수동으로 작성하는 것은 물론 좋지 않습니다. 더 정확함:

버전 확대초기화 처리;
프로그래밍 방식으로 데이터를 채우는 순서를 코드로 설명;
그리고 나서 새로운 처리 버전스토리지를 통해 자동으로 필요한 모든 데이터베이스로 이동하여 실행됩니다. 필요한 모든 조치를 취할 것입니다.

도표에서는 이 운영 절차다음과 같이 표시됩니다.

시스템 시작
상수 버전과 처리 버전 비교.
일치하지 않는 경우, 실시되고있다순차적으로 필요한 모든 것 핸들러,
상수에 대한 새 값을 설정합니다..

결과적으로 모든 데이터베이스의 모든 위치에서 데이터가 업데이트됩니다.

3. 사전 정의된 값의 디렉토리

다음 트릭은 미리 정의된 값을 참조하는 것입니다.

사전 정의되지 않은 코드에서 기존 디렉터리 요소에 액세스해야 하는 경우가 종종 있습니다. 미리 정의된 요소를 만드는 것이 더 낫다는 것은 분명하지만, 요소를 미리 정의할 수 없어도 여전히 액세스할 수 있는 경우가 있습니다.

어떤 구현 옵션이 있나요?

이름으로 요소 참조. 이름이 변경된 것이 분명합니다. 코드 작동이 중지되었습니다. 심하게.
코드로 연락하기. 조금 나아졌지만 코드도 변경될 수 있습니다. 아주 좋은하지.
내부 식별자로 연락하세요.그러면 이 코드를 전송할 때도 작동하지 않습니다. 일반적으로 한 데이터베이스에서 다른 데이터베이스로 수정 사항을 전송하면 이 세 가지 경우가 모두 작동하지 않습니다. 아주 좋은하지.
제공 미리 정의된 값의 디렉터리 생성.

이 디렉터리에는 DirectoryLink 유형의 속성이 하나만 포함되어 있습니다.(모든 참고 도서에 대한 링크).

작업의 일부로 일부 요소를 참조해야 하는 경우 이 참조 서적에 사전 정의된 요소(예: Counterparty_Agroimpulse)를 추가합니다.

그런 다음 초기화 처리 코드에서 또는 직접 이 디렉터리의 값을 필요한 상대방으로 채웁니다.

이에 따라 이 후 사전 정의된 값의 디렉터리를 통해 이 상대방에게 연락할 수 있습니다.. 이로 인해 다음이 달성됩니다.

사이에 수정 사항을 전송할 때 다른 기지다 내꺼야 코드는 추가 수정 없이 작동합니다..
또한 오늘은 이 상대방이 Agroimpulse이고 내일은 다른 조직일 수도 있지만 구성에서 아무것도 수정할 필요가 없으며 사전 정의된 값 디렉터리에서 해당 값을 변경하기만 하면 됩니다.

4. 디버거에서 임시 테이블 보기

마지막 방법은 디버거에서 임시 테이블을 보는 것입니다.

임시 테이블을 사용하여 복잡한 쿼리를 디버깅하는 경우 콘텐츠를 볼 수 있어야 합니다.이것들 임시 테이블.
이러한 목적을 위해 할 수 있다 특별한 기능을 사용하다임시 테이블을 보려면
이 기능 편안한 전역 모듈에 배치.

그리고 이름어떻게든 짧게(예: VT())

이 경우:

나 중단점을 설정했습니다.내가 부탁하는 곳에서.
"Calculate Expression" 창에서 VT(Query)를 작성합니다.;
'계산'을 클릭하고 임시 쿼리 테이블의 구조를 얻습니다.어떤 데이터가 있는지 확인해보세요.

이것은 매우 편리한 기능이므로 우리는 항상 사용합니다. 특히 비용을 계산할 때나 ZUP와 같은 구성에서는 더욱 그렇습니다. 솔직히 말해서 그녀 없이는 다른 사람들이 어떻게 사는지 이해가 안 돼요.

최신 버전의 플랫폼이 등장했습니다. 내장 도구임시 테이블을 볼 수 있지만 내 생각에는 별로 편리하지 않습니다. 자신의 기능을 사용하는 것이 훨씬 좋습니다.

결론

모두에게 감사드립니다. 저는 작은 웹사이트를 가지고 있습니다. 이 사이트에는 이러한 모든 규칙과 기타 사항이 자세히 설명되어 있습니다. 들어와서 읽고, 이메일이나 Skype로 저에게 편지를 보내주세요.

이 주제는 나에게 흥미롭습니다. 이에 대해 토론할 준비가 되어 있습니다. 모든 일이 당신에게도 잘되는 것이 나에게는 정말 중요합니다.

심지어 소규모 조직고유한 비즈니스 프로세스 세트가 있습니다. 효과적으로 일하고 받기 위해 최고 이익대규모 비즈니스 프로세스를 자동화해야 합니다. 1C 프로그램은 이 기능을 훌륭하게 수행합니다. 그러나 불행히도 각 사람이 완벽함에 대한 자신의 생각을 가지고 있는 것처럼 이상적인 프로그램은 없습니다. 1C 프로그래머는 프로그램 개선에 도움을 줄 수 있습니다. 표준 1C를 수정하면 귀하의 아이디어와 요구 사항을 완벽하게 충족하는 프로그램을 받게 됩니다.

개정판 1C-기업의 요구 사항에 맞게 1C 프로그램을 구성하고 현대화하는 일련의 작업입니다.

1C 프로그램을 개선하는 방법

이상적인 결과를 얻기 위해 고객이 1C 프로그램을 마무리할 때 의도한 것을 정확하게 받으면 다음 작업 계획을 제공합니다.

클라이언트는 설치된 에 대한 정보를 보고합니다.
고객은 우리 전문가에게 조직 업무의 기본 원칙을 소개하고 문제의 본질을 전달하며 정확히 개선하고 싶은 것이 무엇인지 설명합니다.
1C 프로그래머가 고객에게 배정되어 우리 회사와 함께 일하는 전체 시간 동안 고객과 협력하고 고객 비즈니스 회계의 모든 기능을 알고 있습니다. 1C 개인 프로그래머는 자신이 구현한 개선 사항의 성능에 대해 전적인 책임을 집니다.
기술 사양이 작성되었습니다. 받은 정보를 바탕으로 1C 프로그래머는 필요한 결론을 도출하고 수정 또는 1C 조정을 통해 문제 해결을 위한 옵션을 제공합니다.
1C를 마무리하는 데 드는 시간과 비용이 합의됩니다.
고객과 합의한 작업이 구현됩니다.
작업 결과는 테스트를 거쳐 고객에게 전달됩니다.

1C의 가장 일반적인 수정

아래에는 1C 프로그램에서 특히 인기 있는 개선 사항이 나열되어 있습니다.

디렉토리 및 세부정보 생성. 창조 추가 장소자동차 번호 등 정보 저장
새로운 인쇄 형태의 개선 또는 개발. 변화 모습조직의 요청에 따라 청구서, 송장 및 기타 인쇄된 형태의 문서.
새 보고서 만들기 또는 기존 보고서 수정. 회계사, 관리자 또는 회사 이사를 위한 추가 보고서를 생성하거나 기존 보고서를 편집합니다.
접근 권한 설정. 데이터베이스 정보에 대한 사용자 액세스를 제한하거나 확장합니다.
치료법 개발.정보 입력 시스템을 단순화하기 위한 처리 생성, 기업 활동 분석, 자동으로 수행되는 기능(예: 문서 패키지 인쇄 또는 Excel 파일(*.xls)에서 정보 다운로드)
1C 교환 설정.하나의 1C 프로그램에서 다른 프로그램으로 데이터 가져오기/내보내기.
1C 사용자에게 컨설팅.구현된 개선 사항을 사용하기 위한 사용자 설명 또는 교육.
변경된 구성을 업데이트하는 중입니다.우리는 우리와 타사 1C 프로그래머가 변경한 구성을 업데이트합니다.

1C 개선을 우리에게 맡길 때의 이점

우리 회사에 개조를 주문하는 것이 수익성이 있는 데에는 여러 가지 이유가 있습니다.

고품질.당사의 1C 프로그래머는 관련 1C 인증서로 확인된 우수한 전문가입니다.
저렴한 비용.우리 회사는 작지만 빠르게 성장하고 있으며 고객과 프로그래머 사이의 중개자를 제거합니다. 이로 인해 1C 서비스 비용을 1000 루블에서 낮은 수준으로 유지할 수 있습니다. 전문 작업 시간당.
빠른 작업 완료. 귀하의 업무 완료를 지연시키는 것은 우리 회사에 이익이 되지 않습니다. 따라서 귀하는 근무일 기준으로 3일 이내에 작업 결과를 받을 수 있습니다. 작업이 작다면 연락한 날 1C에서 필요한 수정을 받을 수 있을 가능성이 높습니다.
수정 성능을 100% 보장합니다.우리 회사는 귀하의 프로그램에서 직원이 개선한 기능을 보장합니다. 구현 후 1년 이내에 숨은 결함을 발견하면 알려주시면 최대한 빠른 시일 내에 전액 무료로 고쳐드리겠습니다.
지리적으로 우리나라에 위치해 있음에도 불구하고 세인트 피터스 버그, 귀하가 세계 어디에 있든 원격으로 모든 작업을 수행할 수 있습니다.