기준정보 명부 가져오기

상태: 공통 표준 — 2026-10-18 KST 사용자 결정, 2026-10-26 KST 개정(같은 대상 찾기 — CRM 레코드의 이메일주소 약한 키, 레코드 식별 필드에 맞춘 관리코드·등록번호 판정, E.164 비교, 찾는 범위)

적용 대상: company-wide — 기준정보(유닛·당사자·유닛과 당사자의 관계)를 파일 하나로 생성·갱신하는 직원 화면과 그 판정 서버. 처음 쓰는 곳은 Leyve Console의 「세대 명부 가져오기」입니다. 「같은 대상 찾기」의 당사자 순서는 고객·의뢰인· 구성원·거래처 같은 관계 레코드를 가져올 때도 씁니다.

정본 분류: 이 쪽은 leysys-design의 결정 기록 MASTER-DATA-ROSTER-IMPORT-2026-10-18을 회사 공통 표준으로 공개합니다. 규칙을 바꿀 때는 결정 기록과 이 쪽을 함께 고칩니다. 작업 화면의 구성(공식 컴포넌트 합성)은 leysys-design이, 서버 판정·원장·제품별 선택 열과 채택 현황은 해당 제품 저장소가 소유합니다. 문서 변경은 런타임 채택을 증명하지 않습니다. 2026-10-26 KST 개정은 오너 결정 O-7을 따릅니다. 가져오기의 이메일주소는 CRM 레코드에 한해 확인 단계가 있는 약한 키로 쓰고, 이 표준을 함께 고칩니다. O-7의 기록과 관계 레코드의 코드 계약(findSameRecord)은 Zution 관계 코어 계약 v1 (zution-console-proto docs/architecture/relationship-core-contract.md §12 · §17)입니다.

원칙

• 한 파일, 한 행 = 유닛 하나와 그 유닛의 관계 0..1개입니다. 유닛·당사자·관계를 한 번에 넣으므로 사용자가 유닛 → 사람 → 관계 순서를 맞출 필요가 없습니다.
• 흐름은 템플릿 받기 → 파일 선택 → 검증 미리보기 → 오류 행 내려받기 → 확정입니다. 오류 행은 반영하지 않고, 오류 없는 행 전체를 한 번에 반영합니다.
• 같은 대상은 관리코드 → 위치·등록번호 → 이름 + 휴대전화번호 순서로 찾고, CRM 레코드는 마지막에 이메일주소로도 찾습니다. 약한 키(이름 + 휴대전화번호, 이메일주소)로 찾은 행은 사용자가 확인하고, 이름만으로 합치지 않습니다.
• 판정은 서버가 하고 확정은 멱등입니다. 화면의 판정은 미리보기용입니다.
• 필드 이름과 값의 형식은 공간 정보 · 당사자 · 연락처를, 관계와 청구 대상 규칙은 유닛과 당사자의 관계를 따릅니다.

진입 자리와 이름

• 기준정보 유닛 목록의 목록 동작 줄 끝 쪽, [생성] 바로 앞에 [가져오기]를 둡니다. 접근 이름은 「{명부 이름} 가져오기」입니다.
• 「가져오기 / Import」는 파일의 행으로 레코드를 생성하거나 갱신하는 동사입니다. 되돌리는 동작은 없고, 가져온 레코드는 각 화면에서 삭제·제거합니다.
• 화면 제목은 「{명부 이름} 가져오기」입니다. Leyve Console은 「세대 명부 가져오기」이고, 다른 제품은 채택할 때 명부 이름을 정합니다.
• 권한이 없거나 모듈을 이용하지 않으면 버튼을 숨깁니다. 원장을 불러오는 중처럼 상태 때문에 막히면 비활성으로 두고 이유를 보입니다. 버튼 이름을 이유 문장으로 바꾸지 않습니다.

파일

형식과 한도

• CSV(UTF-8)가 정본 입력입니다. 템플릿은 BOM을 붙여 내려 스프레드시트가 한글을 바로 읽게 합니다. 가져오기는 BOM이 있든 없든 UTF-8을 받고, UTF-8로 읽히지 않으면 EUC-KR(CP949)로 한 번 더 읽습니다. 둘 다 아니면 파일 오류입니다.
• 한도는 5MB · 데이터 5,000행입니다. 넘으면 파일 오류입니다. 형식과 한도는 파일 칸 라벨 옆 ⓘ에서 알리고, 입력 아래 설명 줄을 두지 않습니다.
• 템플릿은 머리글 한 줄만 담습니다. 예시 행을 넣으면 지우지 않은 채 그대로 가져와지는 사고가 생기기 때문입니다.
• XLSX 템플릿은 내지 않습니다. XLSX 입력은 제품이 읽기 도구와 보안 경계(수식을 계산하지 않음, 매크로·외부 연결 무시, 크기·행 한도, 첫 시트만)를 자기 결정으로 기록한 경우에만 받습니다.
• 수식 방지 — 가져온 값은 언제나 글자로 다루고 계산하지 않습니다. 글자 열(이름 등)이 = + - @ 탭 · CR로 시작하면 그 행은 오류입니다. 휴대전화번호의 국가번호 +(뒤가 숫자)는 예외입니다. 내려받는 파일(템플릿·오류 행 파일)은 그런 값 앞에 따옴표를 붙이고, 가져오기는 그렇게 붙인 앞 따옴표 하나를 지우고 읽습니다.

열

머리글은 화면 라벨이고, 순서는 유닛 → 당사자 → 관계 → 관리코드입니다. 빌딩·층·유닛 머리글은 프로퍼티의 표시 이름(예: 동 · 층 · 호)으로 내리고, 가져오기는 표준 이름(빌딩 · 층 · 유닛)도 함께 받습니다. 정한 머리글이 아닌 열이 있으면 파일 오류입니다. 예외는 오류 행 파일의 「오류 사유」 열(읽지 않음)과 제품이 채택할 때 정한 선택 열입니다.

묶음	머리글	데이터 이름	필수	값
유닛	빌딩	buildingName	프로퍼티가 빌딩 단계를 쓰면 필수	대장 표기 그대로(「101동」). 접미사를 붙이거나 떼지 않습니다
유닛	층	floorName	선택	「10층」
유닛	유닛	unitName	필수	「1004호」
유닛	타입	typeKey	선택	조직 타입 목록의 이름으로 적고 key로 바꿔 저장합니다. 목록에 없거나 숨긴 타입은 오류입니다
유닛	전유면적	exclusiveArea	새 유닛이면 필수	㎡, 소수 넷째 자리까지의 십진수(「84.9200」)
유닛	주거공용면적 · 기타공용면적	residentialCommonArea · otherCommonArea	선택	㎡. 공급면적·계약면적은 계산값이라 받지 않습니다
유닛	지분	shareValue	선택	비우면 전유면적을 씁니다
당사자	이름	name	관계가 있는 행(공실 제외)에서 필수	「홍길동」 · 「주식회사 예시(가상)」
당사자	당사자 유형	partyType	새 당사자면 필수	개인 · 법인 · 법인 아닌 단체(natural_person · legal_person · unincorporated_organization)
당사자	휴대전화번호	mobileTel	아래 식별 키 중 하나 이상	「010-1234-5678」 또는 국가번호 형식. E.164로 저장합니다
당사자	사업자등록번호	business.registrationNumber	선택	10자리. 형식만 막고 검증식은 경고로 씁니다
당사자	법인등록번호	identifiers(kr_corporate_registration_number)	선택, 법인만	13자리. 화면에서는 가립니다
관계	관계	relationType	선택 — 비우면 유닛만 넣는 행	소유 · 사용 · 공실
관계	사용 유형	occupancyType	사용이면 필수	임차 · 본인 거주
관계	소유 지분	share	선택, 소유만	「1/2」 같은 정확한 분수. 비우면 소유 지분 미확인
관계	시작일	effectiveFrom	관계가 있으면 필수	YYYY-MM-DD
관계	마지막 적용일	effectiveTo(다음 날로 저장)	선택	YYYY-MM-DD. 비우면 끝을 정하지 않은 관계입니다
관계	청구 대상	청구 대상 지정(billing_designation)	선택, 소유 · 사용 행만	「예」면 그 기간 이 당사자를 청구 대상으로 지정합니다. 비우면 기본 규칙으로 정합니다
관계	청구 대상 근거	designationBasis 종류	청구 대상이 「예」면 필수	관리서비스 계약 · 약정(service_contract · agreement). 빈 칸이나 다른 값은 그 행의 오류입니다
관계	근거 참조	designationBasis 참조	청구 대상이 「예」면 필수	관리서비스 계약이면 같은 유닛·당사자·기간을 덮는 그 계약의 관리코드, 약정이면 약정 문서 이름·날짜. 확인 주체는 실행한 사람입니다
관리코드	유닛 관리코드	managementCode(유닛)	선택	기존 유닛을 정확히 가리킬 때 씁니다. 새 유닛에 적으면 그 코드로 등록하고, 비우면 자동 채번(UNT-000001)
관리코드	당사자 관리코드	managementCode(당사자)	선택	같은 규칙. 접두어는 제품이 정합니다

• 개인의 주민등록번호·외국인등록번호는 받지 않습니다. 법이 처리를 제한하는 번호이고(당사자), 명부 업무에서 처리 근거를 확인하지 않았습니다. 받아야 하는 제품은 법령 근거를 기록하고 결정 기록과 이 표준을 먼저 고칩니다.
• 청구 기능이 없는 제품(LeyVote)은 사용 · 공실 · 청구 대상 열을 내지 않습니다. 열은 그 제품에 있는 관계만 둡니다.

행의 모양

• 한 행은 유닛 하나와 관계 0..1개입니다. 관계가 있으면 그 관계의 당사자를 같은 행에 적습니다(공실은 당사자 없음).
• 같은 유닛·같은 당사자가 여러 행에 나오면 하나로 셉니다. 두 번째 행부터는 그 대상의 값 칸을 비워도 됩니다. 채우면 첫 행과 같아야 하고, 다르면 그 대상이 나오는 행 모두 오류입니다.
• 유닛 없이 당사자만 있는 행은 오류입니다. 멤버만 넣는 가져오기의 템플릿은 이 표준의 범위가 아닙니다.
• 당사자에는 식별 키(휴대전화번호 · 사업자등록번호 · 법인등록번호 · 당사자 관리코드)가 하나 이상 있어야 합니다. 이름만으로는 같은 사람인지 알 수 없어, 여러 유닛을 가진 한 사람이 여러 명으로 생기기 때문입니다.
• 파일 안의 행과 이미 있는 관계를 합쳐 함께 검사합니다. 다음은 오류입니다.
  • 같은 유닛·같은 관계 종류에서 같은 당사자의 기간이 겹침. 시작일이 달라도 겹치면 오류입니다(예: 같은 사람의 소유 1/2 2026-01-01부터와 1/2 2026-02-01부터).
  • 같은 유닛·같은 날의 소유 지분 합계가 1을 넘음(그 유닛의 소유 행 모두)
  • 같은 유닛의 공실 기간이 사용 기간과 겹침
  • 같은 유닛·같은 날에 청구 대상 지정이 둘 이상
  • 청구 대상 지정의 근거가 없거나 근거 참조를 확인할 수 없음
  • 파일 안에 같은 관계(유닛·당사자·관계·시작일)가 두 번 나옴
• 한 행이 오류이면 그 행에 기대는 행(같은 새 유닛·새 당사자를 쓰는 행)도 오류이고, 사유에 원인 행 번호를 적습니다.
• 관계 행은 묶음으로 함께 반영합니다. 같은 유닛·같은 관계 종류(소유 / 사용·공실)에서 기간이 겹치는 행은 한 묶음이고, 그중 하나라도 오류이면 묶음 전체를 반영하지 않습니다. 공동 소유자·공동 사용자 일부만 들어가지 않게 하기 위해서입니다. 제외한 묶음의 유닛·구간은 그 관계 종류의 완전성이 「미확인」으로 남습니다.

같은 대상 찾기

비교 전에 글자는 NFC 정규화와 양끝 공백 제거, 관리코드는 대소문자 무시(레코드 식별 필드), 등록번호는 숫자만 남깁니다. 이메일주소는 도메인(@ 뒤)만 대소문자를 무시하고 @ 앞은 그대로 비교합니다 (연락처). 휴대전화번호는 E.164끼리만 비교합니다. 파일의 국내 형식은 E.164로 바꿔 비교하고, E.164로 바꿀 수 없는 파일 값이나 E.164가 아닌 원장 값은 오류입니다. 형식이 달라 새 당사자가 조용히 생기지 않게 하기 위해서입니다.

유닛

1. 유닛 관리코드가 있으면 그 유닛입니다. 그 유닛의 빌딩·유닛이 파일 값과 다르면 오류입니다.
2. 없으면 같은 프로퍼티 안에서 빌딩 + 유닛(대장 표기)이 같은 유닛입니다. 없으면 새 유닛입니다.
3. 접미사만 다른 기존 유닛(「101」과 「101동」)이 있으면 새 유닛으로 두되 경고합니다. 자동으로 맞추지 않습니다.

당사자

1부터 차례로 보고 처음 해당하는 단계에서 정합니다. 기준정보 당사자와 같은 모양의 관계 레코드(고객·의뢰인·구성원· 거래처 등)를 가져올 때도 이 순서입니다.

1. 당사자 관리코드가 기존 당사자를 가리키면 그 당사자입니다. 같은 등록번호의 당사자가 여럿이어도 그중 하나를 관리코드로 고르면 그 당사자입니다. 행의 등록번호 가운데 이 당사자가 아닌 당사자만 가리키는 번호가 있으면 오류 「식별 정보가 서로 다른 당사자를 가리킵니다」입니다.
2. 기존 당사자에 없는 관리코드면 그 관리코드로 새 당사자를 등록합니다. 같은 등록번호의 당사자가 있어도 막지 않고 경고합니다. 등록번호는 중복을 허용하고, 같은 대상을 두 번 등록하면 관리코드로 구분하기 때문입니다 (레코드 식별 필드).
3. 관리코드가 없고 등록번호(사업자등록번호·법인등록번호)가 있으면 그 등록번호의 당사자입니다. 한 등록번호의 당사자가 둘 이상이면 오류 「같은 등록번호의 당사자가 여럿입니다. 당사자 관리코드를 적어 주세요」이고, 서로 다른 등록번호가 서로 다른 당사자를 가리키면 오류 「식별 정보가 서로 다른 당사자를 가리킵니다」입니다. 맞는 당사자가 없으면 새 당사자이며, 이름 · 휴대전화번호나 이메일주소로 이어서 찾지 않습니다.
4. 관리코드도 등록번호도 없으면 이름과 휴대전화번호가 모두 같은 당사자입니다. 둘 이상이면 오류입니다.
5. CRM 레코드에 한해, 4로 찾지 못하면 이메일주소가 같은 레코드입니다. 둘 이상이면 오류입니다. CRM 레코드는 CRM 업무 모듈이 영업 관리(리드 → 기회 → 고객)로 다루는 레코드입니다. 기준정보 당사자·구성원처럼 CRM 레코드가 아니면 이메일주소로 찾지 않고, 이메일주소가 같으면 경고만 합니다.
6. 그 밖에는 새 당사자입니다. 이름만 같으면 합치지 않습니다.

• 약한 키로 찾은 행은 사용자가 확인합니다. 휴대전화번호는 가족이 함께 쓰거나 다시 배정될 수 있고, 이메일주소는 여러 사람이 함께 쓸 수 있습니다. 이름 + 휴대전화번호로 찾은 행은 「이름 · 휴대전화번호로 찾음」을, 이메일주소로 찾은 행은 「이메일주소로 찾음」을 보여 사용자가 확인하게 합니다.
• 새 당사자로 둘 때는 비슷한 당사자를 경고만 합니다. 이름과 휴대전화번호가 모두 같은 당사자, 이름만 같은 당사자 (「이름이 같은 당사자가 있습니다」), 휴대전화번호만 같은 당사자, 이메일주소가 같은 당사자가 있으면 알리고, 2에서는 등록번호가 같은 당사자도 알립니다. 같은 사람이면 당사자 관리코드를 적어 다시 가져옵니다.
• 강한 키(관리코드·등록번호)가 서로 다른 기존 당사자를 가리키면 오류입니다(1 · 3). 우선순위로 하나를 고르지 않습니다. 기존 당사자에 없는 관리코드는 어느 당사자도 가리키지 않으므로 2처럼 새 당사자입니다.
• 파일 안에서도 같은 규칙으로 행끼리 같은 당사자를 묶습니다.
• 찾는 범위는 행을 넣을 소유 범위(조직 또는 워크스페이스)의 원장이고, 후보는 그 안에서 실행한 사람이 조회할 수 있는 레코드뿐입니다. 워크스페이스가 소유하는 레코드는 같은 사람이라도 워크스페이스마다 따로 있고, 다른 워크스페이스의 같은 관리코드와 맞추지 않습니다. 범위 밖 후보의 ID·이름·존재를 응답·오류·경고에 드러내지 않고, 범위 밖과 겹치는지도 알리지 않습니다.

관계

• 유닛·당사자·관계·시작일이 같은 관계가 있고 값도 같으면 「변경 없음」입니다.
• 가져오기는 새 관계(버전)를 만들고, 비어 있던 소유 지분을 채우는 것까지만 합니다. 채우면 새 revision입니다.
• 이미 정한 소유 지분·사용 유형·기간을 바꾸거나 관계를 끝내거나 지우는 일은 관계 화면에서 사유와 함께 합니다. 파일이 그렇게 바꾸려 하면 그 행은 오류 「기존 관계는 {관계 화면}에서 바꿉니다」입니다.

갱신의 범위

• 빈 칸은 「바꾸지 않음」입니다. 가져오기로 값을 지우지 않습니다.
• 유닛은 운영자가 정하는 값(타입·지분)만 갱신합니다. 위치(빌딩·층·유닛)와 면적은 대장 원천 값이라 가져오기로 바꾸지 않으며, 다르면 오류입니다.
• 당사자는 관리코드·등록번호로 찾은 경우 이름·휴대전화번호를 갱신할 수 있습니다. 등록번호와 그 형식을 정하는 당사자 유형은 정정으로만 바꾸므로, 다르면 오류 「등록번호는 정정으로 바꿉니다」입니다.
• 관리코드는 바꾸지 않습니다. 새 레코드에만 적을 수 있습니다.

행 상태와 미리보기

행 상태	뜻	확정할 때
신규	새 유닛·당사자·관계 중 하나 이상을 만듭니다	반영
갱신	새로 만드는 것 없이 기존 레코드의 값을 바꿉니다	반영
변경 없음	파일 값이 지금 값과 같습니다(같은 파일을 다시 올린 경우 등)	아무 일도 없음
오류	이 행을 반영할 수 없습니다. 사유를 그 행에 적습니다	반영하지 않음

• 상태는 행 하나에 하나이며 오류 → 신규 → 갱신 → 변경 없음 순서로 정합니다. 무엇이 생기고 바뀌는지는 「내용」 열에 대상마다 적습니다(예: 「유닛 그대로 · 당사자 신규 · 소유 신규」). 갱신이면 이전 값 → 새 값을 보입니다.
• 경고는 상태가 아닙니다. 반영을 막지 않고 「내용」 열에 함께 둡니다: 이름·휴대전화번호·이메일주소·등록번호가 같은 기존 당사자, 접미사만 다른 기존 유닛, 사업자등록번호 검증식 불일치, 소유 지분 미확인, 소유 지분 합계 1 미만.
• 오류 사유는 행마다 문장 하나이고 열 이름을 넣습니다(「소유 지분: 1/2 같은 분수로 적어 주세요」).
• 부분 반영과 청구 대상 — 청구 대상은 유닛과 당사자의 관계의 규칙으로 정합니다. 규칙이 쓰는 관계 묶음이 반영 뒤에도 완전하고 유효해야 하며, 아니면 그 유닛·구간은 「확인 필요」로 남고 「내용」 열에 경고로 보입니다.
  • 공동 사용자 A·B 중 B 행이 오류이면 그 사용 묶음 전체를 반영하지 않고, 그 유닛·구간은 「확인 필요」입니다. A를 단독 사용자로 정하지 않습니다.
  • 사용자가 없는 확인된 공실에서 공동 소유자 일부 행이 오류이면 소유 묶음 전체를 반영하지 않고 「확인 필요」입니다. 남은 소유자 한 명에게 청구하지 않습니다.
  • 소유 지분 합계가 1/2이어도 사용 묶음이 완전하고 유효하며 사용자가 한 명이면 그 사용자입니다.

작업 화면

• 가져오기는 목록 동작에서 여는 작업 시트입니다. 뒤의 목록 맥락이 남고, 확인만 대화상자로 엽니다. 좁은 화면에서는 화면 폭을 씁니다.
• 단계는 「파일」 → 「검증」 → 「결과」 세 가지이고, 앞 단계로만 돌아갈 수 있습니다.

단계	본문	동작
파일	대상 프로퍼티(읽기 전용) · [템플릿 받기] (「CSV」) · 파일 칸(.csv 한 개). 파일 전체 오류(머리글·인코딩·한도·따옴표)는 오류 알림 하나이고 다음 단계로 가지 않습니다	[취소] · [검증] (파일이 없으면 비활성)
검증	요약 한 줄 「신규 n · 갱신 n · 변경 없음 n · 오류 n」 → 유닛·이름 검색과 행 상태 조건(오류가 있으면 「오류」를 고른 채 엽니다) → [오류 행 내려받기] (오류가 없으면 비활성) → 표 행 · 유닛 · 당사자 · 관계 · 기간 · 상태 · 내용	[이전] · [취소] · [가져오기] (반영할 행이 없으면 비활성)
결과	진행 중에는 진행 표시와 「가져오는 중」. 끝나면 대상마다 건수(유닛·당사자·관계의 생성·갱신, 제외한 오류 행)와, 오류가 있었으면 [오류 행 내려받기]	[닫기]

• 미리보기 표의 첫 열 「행」은 파일의 행 번호입니다. 표는 카드 안에서 가로·세로로 스크롤하고 페이지를 나누지 않으며, 행이 많으면 상태 조건으로 좁힙니다. 관리코드 열은 보이지 않습니다. 조건에 맞는 행이 없으면 「조건에 맞는 행이 없습니다」와 [조건 초기화]를 보입니다.
• 오류 행 파일은 오류 행만 원래 열 그대로 담고 맨 끝에 「오류 사유」 열을 더한 CSV(UTF-8 BOM)입니다. 두 번째 행부터 비워 둔 유닛·당사자 값은 그 대상이 처음 나온 행의 값으로 채워 넣어, 오류 행 파일 하나만 고쳐서 다시 가져올 수 있게 합니다. 원본 파일 전체를 고쳐 다시 올려도 됩니다 — 이미 반영한 행은 「변경 없음」입니다.
• 확정 — [가져오기]를 누르면 확인 대화상자가 건수를 다시 보입니다. 제목 「세대 명부를 가져올까요?」, 본문 「신규 n행 · 갱신 n행을 반영합니다. 오류 n행은 가져오지 않습니다.」(청구 대상을 정할 수 없는 유닛이 남으면 「청구 대상 확인 필요 유닛 n개」를 함께), 동작 [계속 검토] · [가져오기]. 확정 요청 중에는 닫기·이전·다시 확정을 막습니다.
• 그 사이 원장이 바뀌면 아무것도 반영하지 않고 검증 단계로 돌아가 새 결과를 보이며, 「그 사이 바뀐 내용이 있어 다시 검증했습니다」를 알립니다. 끝나면 시트를 닫을 때 목록을 다시 읽습니다.

접근성

• 단계가 바뀌면 초점을 그 단계의 제목으로 옮기고, 지금 단계를 보조 기술에 알립니다(aria-current="step").
• 파일 오류는 즉시 알리고(role="alert"), 검증 요약·진행·결과 건수는 상태 알림(role="status")으로 알립니다.
• 행 상태는 색만으로 알리지 않습니다. 배지에 글자가 있고, 오류 사유는 「내용」 칸의 글자입니다. 표의 접근 이름은 「검증 결과」입니다.
• 내려받기 동작은 파일 형식(「CSV」)을 이름에 넣고, 아이콘은 장식으로 둡니다.

서버 책임

화면은 보여 주기와 미리보기 판정만 합니다. 다음은 서버(또는 그 제품의 판정 경계)가 소유합니다.

1. 판정 권한 — 서버가 같은 규칙으로 다시 검증합니다(dry-run). 화면의 판정과 다르면 서버가 정본입니다. 기간 겹침·소유 지분 합계·청구 대상 근거(계약 참조가 같은 유닛·당사자·기간을 덮는지)도 서버가 확인합니다.
2. 검증 응답 — 행마다 상태·대상별 동작(생성·갱신·그대로)·찾은 키와 확인 필요 여부·오류·경고 코드·대상 ID를 돌려줍니다. 파일 값을 되돌려 보내지 않습니다. 오류 행 파일은 화면이 들고 있는 원본 행에 사유를 붙여 만듭니다. 조회 범위 밖 당사자의 ID·존재는 어떤 코드·사유에도 담지 않습니다.
3. 확정은 멱등 — 요청 키(requestKey), 검증한 원장 revision(expectedRevision — 유닛 원장·당사자 원장·관계 원천), 검증한 내용의 해시를 함께 받습니다. 같은 키의 재시도는 한 번만 반영합니다. revision이나 해시가 다르면 거절하고 다시 검증하게 합니다. 서버가 명시적으로 거절하면 그 키는 버리고, 파일을 다시 고르면 새 키를 만듭니다.
4. 원자성 — 오류 없는 행 전체를 한 트랜잭션으로 반영합니다. 일부만 반영된 상태를 만들지 않습니다.
5. 권한 — 행마다 필요한 권한 키(유닛·당사자 생성·갱신, 관계 생성)를 서버가 판정합니다 (접근 역할 체계). 권한이 없는 동작이 필요한 행은 오류 「접근 권한이 없습니다」입니다.
6. 관리코드 — 비우면 서버가 채번합니다. 적으면 형식·소유 범위 안 유일·다시 쓰지 않음을 검사합니다 (레코드 식별 필드).
7. 기록 — 만들거나 바꾼 레코드마다 로그를 남깁니다. 행위 주체는 실행한 사람, 출처는 「가져오기」입니다. 실행 기록(실행 주체·시각·파일 이름·건수·결과)을 남기고, 원본 파일은 기본으로 저장하지 않습니다.
8. 동시 실행 — 같은 프로퍼티의 가져오기는 한 번에 하나입니다.
9. 한도·인코딩·수식 방지 — 서버도 화면과 같은 한도와 규칙을 적용합니다.
10. 관계 계약 선행 — 관계 열을 반영하는 확정은 유닛 관계 원천의 ID 연결·기간 버전 계약이 고정된 뒤에 켭니다. 그 전의 제품 화면은 시연입니다.
11. 완전성 기록 — 오류로 제외한 관계 묶음이 있으면 그 유닛·관계 종류·구간의 완전성을 「미확인」으로 남깁니다. 고친 행을 다시 가져오거나 관계 화면에서 확인하면 풉니다. 청구 대상 선정은 이 기록을 읽습니다.

제품별 적용

제품	판정	범위
Leyve Console	채택	기준정보 유닛 목록 [가져오기] = 「세대 명부 가져오기」. 유닛만 담은 파일은 당사자·관계 열이 빈 세대 명부이므로 기존 유닛 CSV 가져오기를 이 흐름으로 합칩니다. 기존 열 중 공간 표준 밖의 등록코드·용도는 선택 열로 대응시키고, 그 이름·저장 위치는 채택할 때 정합니다
LeyVote	채택	유닛 목록의 업로드를 이 흐름으로 바꿉니다. 열은 유닛·당사자·소유 관계만입니다. 등기부 Excel 원천은 법정·추출 서식이라 칸 이름은 원천 서식을 따르고(「지분」 칸 = 소유 지분), 행 상태·같은 대상 찾기·오류 행 내려받기·확정 단계를 맞춥니다
Center	해당 없음	고객 등록은 조직(고객) 단위이고 유닛·세대가 없습니다. 지금은 고객 일괄 등록 기능이 없고 이 표준으로 만들지 않습니다. 생기면 이 표준의 행 상태·작업 화면과 당사자 찾기를 따릅니다

• 이 표는 적용 방향이며 배포 완료를 뜻하지 않습니다. 채택 상태는 각 제품 저장소가 기록합니다.
• 회차 업무 데이터(개시 미수금·검침 등)는 기준정보가 아니므로 이 표준의 템플릿·같은 대상 찾기를 쓰지 않습니다. 흐름(검증 미리보기·행 상태·오류 행 내려받기·확정)만 맞추기를 권장합니다.

하지 않는 것

• 멤버·거래처만 넣는 가져오기의 템플릿과, 회차 업무 데이터 가져오기의 템플릿·식별 규칙은 정하지 않습니다. 관계 레코드만 넣는 가져오기도 같은 대상은 「같은 대상 찾기」의 당사자 순서로 찾습니다.
• 가져오기로 관계를 끝내거나 지우지 않습니다. 이사·정정은 관계 화면의 흐름입니다.
• 건축물대장·등기부 연동(원천 값 자동 채움)은 이 표준의 범위가 아닙니다.
• 열 매핑 화면(머리글이 다른 파일의 열을 사용자가 짝짓기)은 두지 않습니다. 템플릿 머리글이 계약입니다.

함께 따르는 표준

• 공간 정보 — 유닛 필드와 유닛과 당사자의 관계
• 당사자 · 사업자 · 연락처
• 레코드 식별 필드 — 관리코드·등록번호·정정
• 대표 소유자와 대표 유닛 — 소유 지분
• 접근 역할 체계 — 권한 키와 행위 주체