공간 정보
상태: 공통 표준 — 2026-10-17 KST 사용자 결정(같은 날 「지분」 추가, 2026-10-18 의결권자 지분의 기본값 1, 같은 날 「유닛과 당사자의 관계」와 유닛 상세
소유·사용탭 추가)적용 대상: company-wide — 프로퍼티(단지·건물)와 그 안의 빌딩·층·유닛을 다루는 제품·서비스(Leyve Console·Center, LeyVote 등)의 화면 라벨, 코드·API·DB 이름, 문서·데모·테스트의 예시 값
정본 분류: 이 쪽이 공간 필드의 정본입니다. 결정 근거·제품 현황·이행 단계는 leysys-design의 결정 기록
SPACE-FIELDS-2026-10-17에 있습니다. 「유닛과 당사자의 관계」 절은 결정 기록UNIT-OWNERSHIP-OCCUPANCY-TAB-2026-10-18을 공개하며, 규칙을 바꿀 때는 그 결정 기록과 이 절을 함께 고칩니다. 이름 짓기·저장 구조·예시 값의 공통 규칙은 공통 입력 정보, 관리코드는 레코드 식별 필드, 공유자별 소유 지분은 대표 소유자와 대표 유닛, 유닛·당사자·관계를 파일로 넣는 흐름은 기준정보 명부 가져오기를 따릅니다. 각 제품의 채택 현황·데이터 이행·의도적 편차는 해당 제품 저장소가 소유합니다.
원칙
- 의미는 건축물대장과 집합건물법이 정합니다. 빌딩·층·유닛과 면적의 뜻은 국토교통부 건축물대장(표제부·전유부· 전유공용면적)과 「집합건물의 소유 및 관리에 관한 법률」의 전유부분·공용부분을 따릅니다.
- 대장에서 온 값과 운영자가 정한 값을 섞지 않습니다. 주용도·동명칭·호명칭·면적처럼 대장에서 가져온 값은 원천 값으로 두고, 타입·표시 이름처럼 운영자가 정하는 값은 따로 둡니다. 한쪽을 다른 쪽으로 덮어쓰지 않습니다.
- 공간과 사람은 불변 ID로 잇습니다. 이름이나 「101동 1004호」 같은 글자로 소유자·계약·의결권을 잇지 않습니다.
- 이름은 공통 입력 정보의 규칙을 씁니다. 코드·API는 camelCase, DB는 snake_case이고 임의로 줄이지 않습니다.
공간 단계
| 단계 | spaceType | 기본 라벨 | 영어 라벨 | 건축물대장 |
|---|---|---|---|---|
| 프로퍼티 | property | 프로퍼티 | Property | 관리 대상 단지·건물 하나(표제부 여럿을 묶을 수 있음) |
| 빌딩 | building | 빌딩 | Building | 동(동명칭) |
| 층 | floor | 층 | Floor | 층(지상·지하 구분과 층번호) |
| 유닛 | unit | 유닛 | Unit | 호(호명칭) — 전유부분 하나 |
표시 이름
- 프로퍼티는 빌딩·층·유닛 단계마다 표시 이름과 사용 여부를 둡니다. 예를 들어 아파트 단지는 빌딩을 「동」, 유닛을 「호」로 부릅니다. 표시 이름이 없으면 기본 라벨(빌딩 · 층 · 유닛)을 씁니다.
- 표시 이름은 화면 라벨만 바꿉니다. key·저장 값·검색·정렬 규칙은 그대로입니다.
- 쓰지 않는 단계(예: 단일 건물이라 빌딩 단계가 없음)는 화면에서 그 칸을 감추고 값은 비워 둡니다.
| 필드 | 코드 / DB | 한국어 라벨 | 영어 라벨 |
|---|---|---|---|
| 단계 표시 이름 | levelLabels: { building, floor, unit } / level_labels | 표시 이름 | Display name |
| 단계 사용 여부 | levelsInUse: { building, floor, unit } / levels_in_use | 사용 여부 | In use |
프로퍼티 필드
| 필드 | 코드 / DB | 한국어 라벨 | 영어 라벨 | 원천·규칙 |
|---|---|---|---|---|
| 관리코드 | managementCode / management_code | 관리코드 | Management code | PRP-000001 |
| 이름 | name | 이름 | Name | 운영자 입력. 중복 허용 |
| 약칭 | shortName / short_name | 약칭 | Short name | 전각 7칸 표시 규칙 |
| 주소 | address | 주소 | Address | 주소의 필드. 지번 필드는 두지 않습니다 |
| 대지면적 | siteArea / site_area | 대지면적 | Site area | 표제부 |
| 건축면적 | buildingArea / building_area | 건축면적 | Building area | 표제부 |
| 연면적 | totalFloorArea / total_floor_area | 연면적 | Total floor area | 표제부 |
| 용적률 산정용 연면적 | floorAreaForRatio / floor_area_for_ratio | 용적률 산정용 연면적 | Floor area for FAR | 표제부 |
| 건폐율 | buildingCoverageRatio / building_coverage_ratio | 건폐율 | Building coverage ratio | 표제부(%) |
| 용적률 | floorAreaRatio / floor_area_ratio | 용적률 | Floor area ratio | 표제부(%) |
| 주구조 | mainStructure / main_structure | 주구조 | Main structure | 표제부 원문 |
| 지상 층수 | aboveGroundFloorCount / above_ground_floor_count | 지상 층수 | Floors above ground | 표제부 |
| 지하 층수 | belowGroundFloorCount / below_ground_floor_count | 지하 층수 | Floors below ground | 표제부 |
| 세대수 | householdCount / household_count | 세대수 | Households | 표제부 |
| 호수 | unitCount / unit_count | 호수 | Units | 표제부. 계약의 과금 수량과 다른 값입니다 |
| 사용승인일 | useApprovalDate / use_approval_date | 사용승인일 | Use approval date | 표제부(YYYY-MM-DD) |
- 주소는 프로퍼티의 소재지 하나입니다. 주소 종류(
addressType)를 두지 않고, 대장 조회에 쓰는 법정동 코드 (legalDistrictCode)를 함께 저장합니다. 지번주소는 저장하지 않습니다(도로명주소 API의 참고항목도addressLine1에 넣지 않음). - 대장 원천의 연결(원천 종류·대장 관리번호·조회 시각)은 제품이 정하되, 원천 값과 운영자 수정 값을 구별해 남깁니다.
유닛 필드
| 필드 | 코드 / DB | 한국어 라벨 | 영어 라벨 | 원천·규칙 |
|---|---|---|---|---|
| 관리코드 | managementCode / management_code | 관리코드 | Management code | UNT-000001 |
| 프로퍼티 | propertyId / property_id | 프로퍼티 | Property | 불변 ID |
| 이름 | name | 이름 | Name | 기본은 「{빌딩} {유닛}」(예: 「101동 1004호」). 운영자가 바꿀 수 있음 |
| 약칭 | shortName / short_name | 약칭 | Short name | 예: 「101-1004」 |
| 빌딩 | buildingName / building_name | 빌딩(표시 이름) | Building | 대장 동명칭 그대로(「101동」 · 「A동」) |
| 층 | floorName / floor_name | 층(표시 이름) | Floor | 대장 층 이름 그대로(「10층」 · 「지하1층」) |
| 유닛 | unitName / unit_name | 유닛(표시 이름) | Unit | 대장 호명칭 그대로(「1004호」 · 「B101호」) |
| 타입 | typeKey / type_key | 타입 | Type | 조직이 관리하는 목록의 key(아래 「타입」) |
| 주용도 | registeredUse: { code, name } / registered_use_code·registered_use_name | 주용도 | Registered use | 건축물대장 주용도 원천 값 |
| 전유면적 | exclusiveArea / exclusive_area | 전유면적 | Exclusive area | 전유부분 면적. 분양 공고의 (주거)전용면적과 같은 값 |
| 주거공용면적 | residentialCommonArea / residential_common_area | 주거공용면적 | Residential common area | 공동주택의 계단·복도·현관 등 지상층 공용 |
| 기타공용면적 | otherCommonArea / other_common_area | 기타공용면적 | Other common area | 지하층·관리사무소 등 |
| 공급면적 | supplyArea(계산) | 공급면적 | Supply area | 전유면적 + 주거공용면적. 저장하지 않습니다 |
| 계약면적 | contractArea(계산) | 계약면적 | Contract area | 공급면적 + 기타공용면적. 저장하지 않습니다 |
| 지분 | shareValue / share_value | 지분 | Share value | 의결권 · 공용부분 부담의 기준(아래 「지분」). 비어 있으면 전유면적 |
| 지분율 | shareRatio(계산) | 지분율 | Share ratio | 지분 ÷ 같은 프로퍼티 유닛의 지분 합. 저장하지 않습니다 |
- 빌딩·층·유닛 값은 대장 표기를 그대로 저장합니다. 화면 라벨만 프로퍼티의 표시 이름을 따르고, 값에 접미사를 덧붙이거나 떼지 않습니다.
- 정렬은 빌딩·층·유닛의 자연숫자 오름차순(「2동」이 「10동」보다 앞)이고, 같으면 불변 유닛 ID순입니다.
- 면적은 제곱미터(㎡) 값을 소수 넷째 자리까지의 십진수 문자열로 저장합니다(예:
"84.9200"). 합계·비율은 십진수로 계산하고 부동소수점으로 반올림하지 않습니다.
지분
- 지분은 유닛의 의결권과 공용부분 관리비 부담의 기준입니다. 「집합건물의 소유 및 관리에 관한 법률」에 따라 규약에 정함이 없으면 전유부분의 면적 비율이므로(제12조 ① · 제17조 · 제37조 ①),
shareValue가 비어 있으면 전유면적을 지분으로 씁니다. - 규약이 달리 정하면(예: 세대마다 같은 지분) 그 값을
shareValue에 넣습니다. 지분은 면적처럼 소수 넷째 자리까지의 십진수 문자열이고, 지분율은 저장하지 않고 계산합니다. - 공간과 관계없는 투표(예: 단체 · 조합의 일반 투표)도 지분으로 의결권을 셉니다. 이때는 투표 제품이 의결권자에게 같은 이름 (
shareValue「지분」)으로 직접 두고, 비어 있으면 1입니다(한 사람 한 지분 — 규약 · 정관이 달리 정하면 그 값). 값의 모양은 유닛 지분과 같습니다. - 한 유닛을 여럿이 나눠 가진 공유자별 몫은 「소유 지분」(예: 1/2)이며 지분과 다릅니다. 대표 소유자와 대표 유닛의
numerator·denominator로 따로 저장하고, 면적이나 지분에서 만들거나 추정하지 않습니다.
타입
- 타입은 조직이 관리하는 목록입니다(예: 「84A」 · 「59B」 · 「상가」). key는 고정하고 이름은 바꿀 수 있으며, 쓰인 항목은 지우지 않고 숨깁니다(레코드 식별 필드).
- 유닛 목록의 기본 조건(필터)은 타입입니다. 주용도는 대장의 사실 값이며 타입을 대신하지 않습니다.
- 상세에서 타입과 주용도는 함께 「분류 정보」(속성)에 둡니다. 주용도는 원천 값이라 대장을 다시 조회할 때만 바뀝니다.
유닛과 당사자의 관계
유닛과 당사자(개인·법인·법인 아닌 단체 — 당사자)의 관계는 소유 · 사용 · 청구 대상입니다. 셋 모두 기간이 있는 관계 사실이며, 사람에게 붙는 역할이 아닙니다.
원칙
- 원천은 관계 하나입니다. 소유·사용·공실·청구 대상 지정은 유닛↔당사자 관계 한 곳이 소유합니다. Leyve Console에서는 관리서비스 관계, LeyVote에서는 명부 확정의 소유 관계입니다. 같은 사실을 화면마다 따로 입력하지 않습니다.
- ID로 잇습니다. 유닛·당사자·관계는 고유코드(
id)로 잇습니다. 이름·동/호·전화번호로 찾아 잇지 않습니다 (레코드 식별 필드). 다른 현장의 관계를 자동으로 합치지 않습니다. - 기간으로 버전을 둡니다. 기간은
[effectiveFrom, effectiveTo)반열린 구간입니다. 시작일은 포함하고effectiveTo는 포함하지 않으며,effectiveTo가 비어 있으면 끝을 정하지 않은 관계입니다. 값을 바꾸면 새 버전(revision)을 남기고 과거 버전을 덮어쓰지 않습니다. - 관계 사실이며 역할이 아닙니다. 데이터 이름은 관계 종류(
relationType)이고role을 쓰지 않습니다. 「역할」은 접근 역할 체계의 직원 접근 역할에만 씁니다. 관계가 있다고 그 당사자에게 화면 접근이 생기지 않습니다. - 청구 대상 명부는 계산한 결과입니다. 명부를 따로 저장해 고치지 않고 관계에서 계산합니다. 이미 발행한 고지서·세금계산서는 발행할 때의 값을 그대로 둡니다.
관계 필드
의미의 계약입니다. DB 구조를 정하지 않으며, 제품의 이름이 다르면 어댑터에서 대응시킵니다.
| 필드 | 코드 | 뜻 |
|---|---|---|
| 관계 · 버전 | relationId · revision | 관계와 그 버전의 불변 ID |
| 관계 종류 | relationType | ownership(소유) · occupancy(사용) · vacancy(공실 — 사용이 없음을 확인한 기간) · billing_designation(청구 대상 지정) |
| 소유 범위 | organizationId · workspaceId | 관계가 속한 조직·현장 |
| 유닛 · 당사자 | unitId · partyId | 고유코드. 공실 기록에는 당사자가 없습니다 |
| 기간 | effectiveFrom · effectiveTo | 반열린 구간. effectiveTo가 null이면 끝을 정하지 않은 관계입니다 |
| 소유 지분 | share | 소유만. { numerator, denominator } 또는 null(대표 소유자와 대표 유닛의 정확한 비율). 유닛 「지분」(shareValue)과 다릅니다 |
| 사용 유형 | occupancyType | 사용만. lease(임차) · owner_occupied(본인 거주). 고정 key이며, 늘릴 때는 결정 기록과 이 표준을 먼저 고칩니다 |
| 청구 대상 근거 | designationBasis | 청구 대상 지정만, 필수. 근거 종류 service_contract(관리서비스 계약) · agreement(소유자·사용자 약정), 참조(계약 관리코드 또는 약정 문서), 확인 기록(…VerifiedAt · …VerifiedBy). 계약은 같은 유닛·당사자·기간을 덮어야 합니다 |
| 청구 대상 | billingSubject(계산) | 청구 구간마다 partyId 또는 null, 근거 designated(지정) · occupant(사용자) · vacant_owner(공실 소유자) · unresolved(확인 필요), 계산에 쓴 관계 revision. 저장하지 않습니다 |
- 화면에는 시작일과 마지막 적용일(
effectiveTo의 전날)을 보입니다: 「2026-03-01 ~ 2026-11-30」, 끝이 없으면 「2026-03-01 ~」. - 「사용자」는 공동주택관리법의 사용자(임차인 등)입니다. 로그인하는 계정의 「사용자」와 다른 관계 사실이므로 유닛 관계를 보여 주는 화면에서만 씁니다. 영어는 Owner · Occupant · Billed party입니다.
청구 대상 정하기
- 구간 — 청구 기간을 모든 관계의 경계(
effectiveFrom과effectiveTo)에서 나누고, 구간마다 청구 대상을 정합니다. 관계가 끝난 뒤의 구간은effectiveTo(마지막 적용일의 다음 날)부터 시작합니다. 월중 이사·승계는 구간의 경계가 되고, 일할 계산은 청구 제품의 규칙입니다. - 선정 순서 — Leyve Console의 기본 규칙입니다. 다른 청구 제품은 자기 규칙을 문서로 둡니다.
- 근거가 확인된 유효한 청구 대상 지정이 있으면 그 당사자입니다.
- 지정이 없고 사용자가 있으면 사용자입니다.
- 사용자가 없음이 확인된 공실이면 소유자입니다(공실 소유자 부담).
- 하나로 정해지지 않으면(사용자가 둘 이상, 지정 없는 공동 소유 공실) 「확인 필요」(
unresolved)입니다. 대표 소유자로 대신하지 않습니다.
- 완전성 전제 — 규칙이 쓰는 관계 묶음이 완전하고 유효할 때만 자동으로 정합니다. 아니면 「확인 필요」로 둡니다.
- 사용자를 고를 때는 그 유닛·구간의 사용 묶음이 완전해야 합니다. 원천이 완전하다고 알리고, 가져오기 오류로 빠진 행이 없어야 합니다. 공동 사용자 중 한 명이 빠진 묶음에서 남은 사람을 고르지 않습니다.
- 공실 소유자를 고를 때는 사용·공실 기록이 그 구간을 덮어 사용자가 없음이 확인되고, 소유 집합이 완전하며 확인된 소유 지분의 합계가 정확히 1이어야 합니다. 공동 소유자 일부만 등록된 공실을 남은 소유자 한 명에게 청구하지 않습니다.
- 규칙이 쓰지 않는 묶음은 선정을 막지 않습니다. 소유 지분 합계가 1/2이어도 사용 묶음이 완전하고 사용자가 한 명이면 그 사용자입니다. 소유 집합은 사용자가 없어 소유자로 넘어갈 때만 봅니다.
- 사용 기록도 공실 기록도 없는 날짜는 공실로 보지 않고 「확인 필요」입니다.
- 유효하지 않은 관계 — 다음 관계가 있으면 그 관계가 속한 묶음은 유효하지 않고, 그 묶음을 쓰는 선정은 「확인 필요」입니다. 저장할 때도 이런 관계를 새로 받지 않습니다.
- 같은 유닛·같은 관계 종류에서 같은 당사자의 기간이 겹침(시작일이 달라도)
- 같은 날 확인된 소유 지분의 합계가 1을 넘음
- 공실 기간과 사용 기간이 겹침
- 같은 날 청구 대상 지정이 둘 이상이거나, 근거가 없거나 확인되지 않은 지정
유닛 상세의 소유·사용 탭
- 탭 이름은
소유·사용(영어 Ownership & occupancy)입니다. 소유와 사용은 근거·기간·당사자가 다른 두 관계이고 둘을 아우르는 업무 용어가 없어 가운뎃점으로 잇습니다. 이렇게 잇는 탭 이름은 유닛 상세의 이 탭 한 곳뿐입니다. 사용 관계가 없는 제품은 담은 것만 이름에 두어소유라고 씁니다. - 자리는 업무 탭의 맨 앞입니다:
일반 · 속성 · (현황) · 소유·사용 · (그 밖의 업무 탭) · 노트 · (메시징) · 로그. 관계를 조회할 권한이 없으면 탭을 두지 않습니다. - 카드는 「소유」 → 「사용」 → 「청구 대상」 순서입니다. 청구 대상은 앞의 두 카드에서 계산합니다.
| 카드 | 열 | 머리글 현황 | 원천이 완전하고 비었을 때 |
|---|---|---|---|
| 소유 | 소유자 · 소유 지분 · 기간 | 「현재 n명」 | 「등록된 소유자가 없습니다」 |
| 사용 | 사용자 · 사용 유형(임차 · 본인 거주) · 기간. 공실 기간은 사용자 칸에 「공실」 | 「현재 n명」 또는 「공실」 | 「등록된 사용 정보가 없습니다」 |
| 청구 대상 | 기간 · 청구 대상 · 근거(지정 · 사용자 · 공실 소유자 · 확인 필요) | 없음(첫 행이 현재 기간) | 「청구 대상을 정할 관계가 없습니다」 |
- 기간 버전 — 모든 기간 버전을 한 표에 둡니다. 기간 옆에는 오늘(현장 시간대) 기준 「현재」 · 「예정」 · 「종료」를 보입니다. 날짜에서 계산한 표시이며 상태가 아닙니다. 순서는 현재 → 예정 → 종료이고, 같은 묶음 안에서는 시작일이 늦은 것부터입니다. 길어지면 카드 안에서 스크롤하고 페이지를 나누지 않습니다. 한 버전 안의 값 변경 이력은 관계 화면의 이력과 유닛
로그가 보여 줍니다. - 소유 지분은
1/2처럼 분수로 보이며 반올림한 퍼센트로 바꾸지 않습니다. 비어 있으면 「소유 지분 미확인」입니다. 대표 소유자는 이름 옆 「대표」로 보이며, 의결권 행사자나 결제자를 뜻하지 않습니다. - 공실과 미확인을 구별합니다. 등록된 공실 기록만 「공실」입니다. 「확인 필요」 행의 근거 칸에는 이유 하나를 적습니다: 사용 묶음 미확인 · 소유 집합 미확인 · 관계 겹침 · 근거 없는 지정 · 사용 기록 없는 날짜 · 사용자 둘 이상 · 공동 소유 공실.
- 빈 상태 · 확인 필요 · 권한 필요 — 「등록된 ○○이(가) 없습니다」는 원천이 완전한 집합이라고 알려 줄 때만 씁니다. 원천을 확인할 수 없으면 「확인 필요」, 조회가 제한되면 「권한 필요」이고, 0명이나 빈 목록으로 바꾸지 않습니다. 읽을 수 없는 소유자의 이름·수·존재는 드러내지 않습니다.
- 카드는 조회 전용입니다. 관계는 기간·버전·사유를 가진 별도의 기록이고, 새 관계는 소유 집합의 완전성·소유 지분 합계·기간 겹침을 함께 검사해야 하므로 유닛 속성처럼 카드 폼으로 고치지 않습니다. 편집은 관계를 소유한 화면 한 곳에서 합니다. 카드 푸터 끝에 그 화면으로 가는 링크(Leyve Console 「관리서비스 관계에서 변경」)를 두고, 이동한 화면은 이 유닛으로 거른 상태로 엽니다. 그 화면을 조회할 권한이 없으면 링크를 두지 않습니다.
- 별도 관계 화면이 없어 유닛 상세가 그 원천의 유일한 편집 자리인 제품(LeyVote의 소유 지분·대표 지정)은 카드 [편집]을 둡니다. 저장하면 새 revision과 이력을 남기고 과거 버전을 덮지 않습니다.
- 이름을 누르면 그 당사자의 상세를 위에 한 장 더 엽니다. 유닛 상세가 이미 위에 겹쳐 연 두 번째 장이면 이름은 글자로만 둡니다.
제품별 적용
| 제품 | 유닛 상세 탭 | 비고 |
|---|---|---|
| Leyve Console | 일반 · 속성 · 소유·사용 — 「소유」 · 「사용」 · 「청구 대상」 | 원천은 관리서비스 관계입니다. 기준정보 메뉴의 「소유·점유」 링크를 이 탭으로 대신합니다 |
| LeyVote | 일반 · 속성 · 소유 — 「소유」와 「대표 소유자」 · 「소유관계 설정 이력」 | 사용·청구 대상 기능이 없어 그 카드와 탭 이름을 만들지 않습니다. 유닛 의결권은 유닛 「지분」이며 소유 지분으로 나누거나 역산하지 않습니다. 확정된 회의의 의결권 snapshot과 제출·서명·위임 증거는 다시 계산하지 않습니다 |
| Center | 해당 없음 | 고객 계약이 조직 × 상품의 SaaS 계약이라 유닛·소유 원장이 없습니다. 빈 탭이나 가짜 소유 필드를 만들지 않습니다 |
- 이 표는 적용 방향이며 배포 완료를 뜻하지 않습니다. 채택 상태는 각 제품 저장소가 기록합니다.
- 당사자 상세 쪽 보기(한 사람의 소유·사용 유닛 목록)와 관계 화면 자체의 흐름은 이 표준의 범위가 아닙니다.
예시 값
- 프로퍼티: 이름 「예시마을 3단지」, 약칭 「예시마을3단지」, 주소 「서울특별시 중구 세종대로 110」(우편번호 04524), 관리코드
PRP-000001. - 유닛: 이름 「101동 1004호」, 약칭 「101-1004」, 빌딩 「101동」, 층 「10층」, 유닛 「1004호」, 전유면적
"84.9200", 관리코드UNT-000001. - 관계 기간: 시작일 2026-03-01, 마지막 적용일 2027-02-28이면
effectiveFrom"2026-03-01",effectiveTo"2027-03-01"이고 화면에는 「2026-03-01 ~ 2027-02-28」로 보입니다. - 실제 단지·건물의 대장 값(동·호·면적)을 예시에 옮겨 적지 않습니다.
피할 이름
| 쓰지 않는 이름 | 대신 |
|---|---|
dongName, block, building(값) | buildingName |
level(층 값), floor(값) | floorName |
room, hoName, unit(값) | unitName |
alias, displayName(약칭 뜻) | shortName |
exclusiveUseArea, 「전용면적」 라벨 | exclusiveArea, 「전유면적」 |
votingArea, 「의결권 면적」(투표 무게의 뜻) | shareValue, 「지분」 |
| 공유자별 몫을 맨 「지분」으로 부르기 | 「소유 지분」 |
mCode, mgmtCode, 무작위 16진수 · 위치 값으로 만든 코드(UN-101-702) | managementCode UNT-000001 |
lotNumberAddress, jibunAddress, 「지번주소」 | address(도로명주소 필드) |
| 한국어 라벨을 값으로 저장(「상가」 · 「오피」) | typeKey + 조직 목록의 이름 |
role, 「역할」(소유자·사용자·청구 대상을 가리킬 때) | relationType, 관계 종류 |
| 유닛 관계 탭을 「소유·점유」 · 「입주자등」으로 부르기 | 소유·사용(사용 관계가 없으면 소유) |
| 청구 대상 명부를 따로 저장해 고치기 | 관계에서 계산한 billingSubject |