Admin관련

Admin 관련 사항입니다.

문서 설명

1. AM, PM role - PM이 프로젝트 회계관리에 대한 내용입니다.
2. AM role - 회계담당자가 처리해야 할 업무에 대한 설명입니다.
3. Admin 관련 - 시스템 담당자가 처리해야할 업무입니다.

회계관련해서 검사 부분까지는 회계담당자(AM)이 처리하는 부분입니다. PM과 Admin은 프로젝트 회계관리 부분은 동일한 권한을 가지고 있습니다. Admin은 PM의 프로젝트 관리외에 ERP 시스템에 관련된 사항을(메뉴, 언어, 단위 등) 설정하는 기능이 추가된 것입니다.

시스템 설정 관련

ERP 시스템 자체에 대한 내용입니다.

일부 내용은 보안 때문에 개별 파일로만 전달됩니다.

ngnix 관련 설명

Wildcard certificate에 대한 설명이다.

tcamp32.synology.me 가 인증서를 발급 받았으므로, 하위 서버에 대한 접근은 *.tcamp32.synology.me 으로 가능하다.

즉, 포트번호 없이 접근해도 된다는 의미, ngnix 설정이다.

• Synology nas에서

로그인 포털 >> 고급 (생성)

역방향 프록시를 설정한다. --> 패킷이 도달하면, HSTS 활성화 (443 포트로 들어온 놈)을 찾아서,

만들어 놓은 list 예를 들어 https(443) ---> http://localhost:xxx (포트)로 넘김

• 확인 필요

1) localhost가 아닌 내부 IP(192.169.xxx.xxx)로 연결하면 에러나는 듯? (에러 안나야 하는데)

2) HSTS가 2개가 동작하는 경우, 둘다 응답하는 문제, 동일 IP 한개에서만 답변하므로.

 만약 하나의 IP를 share 하고
 두 개의 서버에서  443으로 처리 한다고 하면, 서버 둘에 모두 443이 동작하나? 아니면 먼저 도착한 서버만 응답하나?

• 참조 - Wildcard certificate 순서

1) Wildcard certificate 설정

DDNS를 enabled 시킨다. - floating IP에 대해서 추적 dns 연결

Control panel / Security / Certificate 에서 add

체크 사항
- Let's Encrypt 체크
- Set as default certificate

• Get a Certificate from Let's Encrypt

* 다음 설정을 한다.
- Domain name : tcampXX.synology.me
- Email : 본인의 e-mail
- Subject Alternate Name: *.tcampXX.synology.me   (인증서를 받을 사이트 이름, 여기서는 wildcard * 로 설정, 모두)

• Control Panel / Login Portal / Advanced 텝에서

이 과정은 ngnix과정으로 Reverse proxy 설정라고도 한다. 내용은 포트 443(https)로 보내고, 443에서는 서버이름, 예를 들어 dolibarr, nocodb, n8n 으로 (wildcard 부분) 들어온 서버 주소를 정상적인 80포트로 연결해 주는다. (이를 HSTS 라고 함)

Reverse Proxy 설정

• Source

https 로 들어 오는 주소, 예를 들어 https://n8n.tcampxxx.synology.me 이고 포트는 443

HSTS enable 시키고,

• Destination

host name, localhost (내부 주소도 되나? 192.168.xxx.xxx, 할당된 포트

• 참고 : HSTS

Reverse proxy 환경에서 HSTS (HTTP Strict Transport Security)는 웹 보안 강화를 위한 중요한 HTTP 응답 헤더입니다. 이 개념을 간단히 설명하면 다음과 같습니다:

---

🔐 HSTS란?

HSTS (HTTP Strict Transport Security)는 웹 서버가 브라우저에게 "앞으로 이 도메인에 대해 HTTPS로만 접속하라"고 지시하는 보안 메커니즘입니다. 이는 MITM(중간자 공격)이나 SSL Stripping 같은 공격을 방지하는 데 효과적입니다.

---

🧩 Reverse Proxy와 HSTS의 관계

Reverse proxy는 클라이언트와 실제 서버 사이에 위치하여 요청을 중계합니다. 이때 HSTS는 다음과 같은 방식으로 적용됩니다:

1. Reverse Proxy가 HTTPS를 처리하는 경우:

  - 클라이언트는 Reverse Proxy와 HTTPS로 통신.
  - Reverse Proxy가 HSTS 헤더를 클라이언트에게 전달하거나 직접 설정.
  - 실제 백엔드 서버는 HTTP로 통신할 수도 있음 (내부망).

2. HSTS 헤더 설정 위치:

  - Reverse Proxy에서 직접 설정하는 것이 일반적입니다 (예: Nginx, Apache, HAProxy).
  - 예시 (Nginx):
    ```nginx
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    ```

3. 주의사항:

  - HSTS는 HTTPS 연결에서만 작동합니다. HTTP에서는 무시됩니다.
  - 한번 설정되면 브라우저는 해당 도메인에 대해 강제로 HTTPS를 사용하므로, 실수로 HTTP만 지원하는 서비스가 있으면 접근 불가 문제가 생길 수 있습니다.

---

✅ HSTS의 주요 옵션

- `max-age`: 브라우저가 HTTPS만 사용하도록 강제하는 기간 (초 단위). - `includeSubDomains`: 모든 서브도메인에도 적용. - `preload`: 브라우저에 미리 등록 요청 가능 (엄격한 보안 필요 시).

---

디렉토리 구조

exposed: documents /var/www/documents

exposed: html /var/www/html/custom (portainer 설정에서도 확인 할 것)

언어팩 관련

업그레이드를 한 이후에는 TW ERP에 맞게 언어 팩을 수정해 주어야 한다. (일부 파일 교체)

• 수정 원본 파일 위치: /var/www/html/custom/bug_fix (tw subfolder)

• 웹서버 디렉토리: /var/www/htdocs/langs/ko_KR (/zh_TW)

/var/www/htdocs/langs/ko_KR# cp ../../custom//bug_fix/*.* ./ - 한글 언어팩 수정
/var/www/htdocs/langs/zh_TW# cp ../../custom/bug_fix/tw/*.* ./ - 대만 언어팩 수정

• Alias 적용 이후

bug/fix directory (원본) : var/www/htdocs/custom/bug_fix, 대만은 sub-directory로 tw
Target directory (위치):   var/www/htdocs/langs/ko_kr, 대만은 var/www/htdocs/langs/zh_TW

Third Parties 수정 관련

협력사로 번역되는 Third parties 부분은 다른 언어 팩과 조금 다르다. 여러개가 섞여 있어서 그런듯...

• Thirdparties 위치와 해당 예약어(?) 찾기

디렉토리 위치: /var/www/html/core/menus/standard/eldy.lib.php (파일에서)
$newmenu->add("/societe/list.php?leftmenu=thirdparties", $langs->trans("List"), 1, $user->hasRight('societe', 'lire'), , $mainmenu, 'thirdparties_list', 2);
여기서 확인해 보면, lang 파일에서 "List"로 되어 있다.

• 언어팩(langs) 위치

언어팩 위치는 다음과 같다.

디렉토리 위치 : /var/www/html/langs/ko_KR
사용 파일: 'ThirdParties' => '거래처 관리' ??? --> 어디서 수정하는 거야?

• 기타 변경 가능한 UI 요소

탭 구성: card.php에서 $head 배열을 수정
버튼 스타일: CSS는 /theme/eldy/style.css.php 또는 사용하는 테마 폴더에서 수정
필터 및 검색창: list.php 내의 print_search_form() 함수

• 수정일반 사항

1. UI 변경
2. 기능 변경
3. 권한 설정

비즈니스 로직관련

업무 로직 관련 사항입니다.

신규 사이트 등록관련

ERP에는 Multicompany 모듈이 설치되어 있다. 따라서, 추가적인 국가 혹은 별도의 조직을 생성하여 사용할 수 있다.

Multi-company 모듈을 사용한다고 하더라도, 기본적으로 설정이 다른 것에 추가되는 것이므로, 기본 업무 로직 설정이 중요하다.

Company 구성

다국적 국가의 조직을 구성할 경우이다. 혹은 추가 조직을 구성하는 경우에 화폐가 다른 경우 설정하는 방법이다.

다국적 국가 조직 구성에서 주의해야할 점은 현지화(Currency) 설정이다.

• 주의 사항

1. 일단 기본 설정을 한다. (현재는 TWD로 되어 있음)
2. Dictionary에서 해당 국가 화폐(Currency)를 설정한다.

• 기타 설정(Dictionary) 부분

• 해당 화패 선택

• Multi-Company에서 확인 (아직 TWD로 되어 있음)

• KRW(한국 원)으로 수정

• Multi-Company 구성에서 한국 원(\, KRW)으로 수정되어 있음

처음 ERP 구성

처음 ERP를 구성하는 방버은 다음과 같다.

1. 조직도 구성하기, 인원과 조직을 구성한다. - Tag/Category 만들기
2. 조직별, 인원별 회계 코드를 결정한다.
3. 조직별 권한을 결정한다. - 회계 권한 작성 / 검사(회계) / 승인(PM)
4. 개별적 접속해서 개인정보 검사 및 업데이트를 진행한다.
5. 회계 기준 마련: CoA설정 (default: UK_base)
6. 회계 설정 - 기본 값 설정 (CoA에서 처리 안되는 경우, default로 설정하는 계정 설정)
7. Journal 설정
8. Bank 설정

Users & Groups

사용자와 그룹을 설정한다.

• Group 설정 - 퍼미션 설정

회계에서 작성, 검사, 승인을 설정하는 그룹을 만들고, 퍼미션을 설정한다.

참고: 현재 그룹 설정

- PWO: Project Working Organization, 작성 그룹
- PSO: Project Support Organization, 회계 그룹
- PM_ERP: 승인 그룹이다.

각 그룹의 퍼미션

• PWO

다른 사용자 검색 부분, 본인의 정보 수정을 허용하고, 기타 필요한 권한을 허용한다.

비용전표(Expense Report)에서 본인과 본인 조직의 것을 읽고, 작성하는 권한을 부여한다.

• PSO

필요시, 인원관리 부분도 허용한다. 하지만, 익숙하지 않은 경우, 조직도 수정 오류가 있으므로, 해당 권한 부여에 주의한다.

프로젝트 현황 및 다른 프로젝트 비용 청구를 위해서는 모든 프로젝트에 접근해서 확인 할 수 있도록 허용한다.

프로젝트 접근 권한 허용 (타 프로젝트도 조회할 수 있는 경우)

비용전표(Expense Report)를 처리 할 수 있게 권한을 부여한다. 아래 권한은 본인의 비용전표만 보이도록 한 경우이다.

필요한 경우, Read all expense reports(...not subordinates)를 허용하는 경우에는 다른 프로젝트의 비용전표도 조회가능하다.

급여의 경우, 다른 프로젝트에서 조회가 안되는 것을 기본으로 하는데, bank 부분과 권한 충돌이 있다.

Billing 메뉴에서 회계담당자가 속해 있는 담당자만 확인이 가능하게 설정하더라도, bank와 총계정원장(Ledger, jornals)에서 급여 부분은 확인이 가능하다. 이것을 제한하고자 하면, bank access 부분과 총계정원장 접근에 대한 제한을 고려해야 한다. 현재는 salary에서 회계담당자가 속해있는 프로젝트만 조회 및 입력이 가능하도록 되어 있다.

• PM_ERP

사용자의 비밀번호도 변경할 수 있는 권한을 부여한다.

타인의 비밀번호도 수정할 수 있는 권한 부여, 단 생성은 관리를 위해서 administrator만 가능하게 되어 있다.

비용 전표의 경우, 모든 권한을 허용해 놓았고, 회계담당자와 조직 구성에서 수직구조가 되지 않는 경우 (1명의 회계담당자가 여러 프로젝트를 관리하는 경우) PM이 본인의 프로젝트에 비용전표에 접근하기 어려운 경우가 있어서 모든 전표를 읽을 수 있게 설정하기도 한다. (회계담당자가 해당 프로젝트에 속해 있지 않아, 회계 담당자 작성 내용이 보이지 않는 경우 있음)

급여의 경우, 모든 내용을 다 볼 수 있게 설정한다.

Accounting 설정

Administrator 만 설정이 가능하다.

설정사항은 account 메뉴에서 기록한다.

• Accounting Jornals - 분개장(기록장) 설정하기, 프로젝트당 2개 (BQ, ER)

은행 기록장과 비용 기록장 2개를 설정한다. 주로 사용하는 것은 비용 분개장(기록장, ER)이다.

• Chart of accounts model - 회계 모델 종류 (원래는 여러개가 있는데, 현재 것에서는 사용하는 것만 남겨 놓음)

• Chart of accounts - 선택, 사용 중인 CoA 모델

사용 중인 계정(Account) 모델이고, 필요에 따라 추가 삭제하여 사용할 수 있다.

필요없는 것을 삭제 안하고 그대로 두는 이유- ERP는 본사에서 회계 정보를 확인하기 위하여 사용하기도 하지만, 현지 국가(대만)의 세무신고로도 사용된다. 따라서, 현지 필요에 따라 계정을 추가 혹은 사용해야하는 경우가 있기 때문에, 임의로 삭제하지 않고, 추가 생성의 경우에도 6개 항목 범주에서 설정하여 사용한다. 특히 ENG-BASE의 그룹(범주) CAPIT, IMMO, THIRDPARTY, STOC, FINN, EXPENSE, INCOME에서 검토 후에 해당 (어카운트) 코드를 추가하도록 한다.

• Chart of individual accounts - 멤버(사용자)의 프로젝트 회계 코드 할당 상태

총계정원장에 기록의 경우, 여러 프로젝트들이 섞여 있기 때문에 이를 구분할 필요가 있다. 이러한 구분을 위해서 각 멤버들을 등록할 때, 회계 계정을 설정하게 되어 있는데, 이를 조회하는 화면이다.

• Default accounts - 기본 계정

아직 장부상 기록되지 않은 내용, 계정이 할당되지 않은 것에 대한 기본 기록으로, 처리의 경우 해당 내용을 사용하게 된다.

특히 고객의 경우 411, 공급업체에 대해서는 322, 비용보고서의 사용자(멤버)의 비용은 우선 421로 구분한다. 그룹으로 나누어 보면 편리하다. 고객과 협력사 그리고 내부의 비용 혹은 자금으로 구분하는 것으로 볼 수 있다.\

기타 VAT에 대한 설정은 부가가치세 계정과 중복이다. (둘 중에 1개에만 설정하면 됨)

• Bank accounts - Banks|Cash 메뉴와 동일함

• VAT accounts - 부가세 설정

부가세는 판매 부가세가 있고, 구매 부가세가 있다. 구매 부가세의 경우 환급이 되므로 이를 관리하게 된다. 판매 부가세의 경우, 세무서에서 해당 부가세를 발급한 경우가 있는지 확인하는 경우가 있고, 대만의 경우, 환급이 되므로, 판매사에 부가세를 별도 신고로 부담하게 하는 경우가 종종 있다.

• Tax accounts - 세금 처리 계정

세금의 처리의 경우, 집계 주체에 따라서 구분이 되어야 한다. 예를 들어, 급여에 대한 세금은 본사에서는 비용으로 집계가 되지만, 대만법에서는 비용으로 허용이 되지 않아서, 비용 부분에서 제외 되어야 한다. 수익에서는 제외되어 합산 되는 경우.

이러한 차이로 인하여, 별도로 구분되어 처리되어야 한다. 현지 회계법인을 사용하고 있으므로, 부가세를 제외한 세금처리는 별도로 하지 않고, 비용전표에서 처리한다. 하지만, 해당 내용에 대한 구분을 위한 계정은 할당되어 있다.

• Expense report accounts

비용전표에서 사용하는 계정의 별칭을 두는 것이다. 예를 들어 6261은 통신료라는 이름으로 조회 가능하다. 회계 담당자는 적당한 것이 없는 경우, 번호로 추가 혹은 수정 가능하다.

• 참고 - 일반 회계 기능에 대한 설정

은행계좌 거래 직접 기록 해제의 경우, 은행 계좌를 자동으로 읽어 오는 기능을 활성화 할 경우, 은행계좌 직접기록을 막아 놓는다.

회계 계정 표준화를 위한 자리 수 설정 6자리 사용시 나머지 "00" 붙여서 사용하기

기타 회계상 필요에 따라 설정 적용하여 사용할 수 있다.

회계 계정 설정

회계 계정라는 것은 필요에 의해서, 비용 사용 내역을 구분하기 위해서 설정해 놓는 것이다.

예를 들어 같은 PJT의 경우라도, sub group이 있는 경우, 이를 구분하기 위해 사용한다. 이를 sub-ledger (부분분개장)이라고 구분한다.

특히, 하나의 은행 계좌에서 여러 개의 sub로 나누어져 있는 경우에는 관련 인원별로 회계 코드를 별도로 놓아서, 구분할 수 있다.

• 주의 사항

1. ERP의 비용은 사람의 비용 사용을 기준으로 하기 때문에, 1사람은 1개의 비용 코드를 갖는다.
2. 비용 전표(Expense Report, ER) 작성시, PJT 번호를 물리기 때문에, 프로젝트 별로 구분은 기본이다.
3. 1개의 프로젝트에서 여러개의 비용을 구분하는 경우, 회계 계정을 다르게 두어서 구분하는 용도이다.
4. 회계 계정의 등록은 사용자 카드에서 등록하고, 회계 계정 자체는 그룹의 Tags/Categories에서 확인 한다.

• 회계 계정의 등록 - 사용자 카드

사용자를 설정할 경우, 사용자의 정보 중에 회계 계정을 등록한다.

! 주의사항
이것은 사용자의 은행 계좌(계정)을 말하지 않는다. 사용자의 은행 계좌는 HR 및 은행에 별도로 등록할 수 있다.

프로젝트에 속해 있는 혹은 프로젝트 계정을 말한다. ( 회계계정 = 프로젝트 비용 코드 )

• Accounting에서 실제 회계 계정의 사용

• 주의: 회계 계정의 통일성 유지

본 내용은 반드시 지켜야할 내용은 아니지만, ERP 활용에서 일관성을 유지하기 위한 내용이다.

1. 프로젝트 그룹 태그를 구성한다.
2. 사용자 설정시, 그룹 태그를 사용한다.
3. 회계 계정을 그룹 태그와 동일하게 유지한다.

이렇게 하면, 프로젝트 그룹 = 프로젝트 비용 구분이 동잏라게 유지된다.

• 참고: 일부 태그는 회계 계정(이름)과 다르게 설정된 경우 있음, 임시 활용 때문임.

신규 멤버 추가의 예

신규 멤버를 추가하는 것과 관련된 내용입니다.

신규 멤버 추가하기

• 준비 사항

1. 사용자 이름, 영문, 현지어
2. e-mail 주소: 암호 잊어버릴 경우 자동사용
3. 관련 프로젝트 이름(회계코드)

• 중요 규칙

1. 사용자 ID는 회사 email ID를 사용한다. 예를 들어 HONGGILDOG@ls-electric.com의 경우, HONGGILDONG이 ID가 되어야 함
2. 사용자 ID를 임의로 생성하는 것은 금지하며, (필요시 임시생성 OK) 회사 email 부여 받고 사용한다. (현채인의 사번은 email 주소임)
3. 사용자 이름은 성: 영문성 현지이름, 이름 부분 영어이름 으로 구성 할 것 (검색시 확용)
4. 프로젝트 회계 코드 반드시 넣을 것 (준비사항 동일)
5. 작업 그룹 : 일반 사용자는 PWO 사용 할 것 (PSO는 권한이 많아서 주의)

• 신규 멤버 등록 절차

요약설명

- 신규 멤버 생성: 이름(규칙 주의), email (회사), ERP ID, 초기 암호(LS@.....) 부여
- PJT 회계코드, 실제 사용 email 입력 
  (생성 클릭 후) 
- 신규 생성 후, working group 할당 (권한 부여)

참고: 아이디_부여

1. 신규 멤버 생성

Home에서 new 생성

회사에 부여받은 email ID = ERP ID

현채인 사번은 email ID임

2. PJT 회계 코드 부여 (필수)

사용하는 email을 등록 하기 (초기엔 회사메일로 해도 됨) - 비번 잊어 버렸다고 관리자에게 계속 연락 오므로, 실사용 email 등록 권장

PJT 회계 코드

• TYC-TMP : 신호 타오위엔 프로젝트
• SB02 : 신호 유지보수
• KHH-YL : 가오슝 엘로 라인
• KHH-RL-S : 가오슝 레드라인 남부
• KHH-RL-N : 가오슝 레드라인 북부

3. 그룹(PWO) 할당 사용자 그룹을 할당해 준다. 사용자 그룹

1) PM 그룹 - 모든 권한 (승인)
2) PSO 그룹 - 회계 권한 (검토 요청)
3) PWO 그룹 - 사용자 그룹

신규 멤버 삭제하기

멤버 삭제의 경우, 개인 프로파일에서 삭제하면 제거 가능

• 주의 사항

프로젝트 테그를 먼저 삭제하여야만 개인 프로파일이 삭제됨

• 사용자가 삭제되지 않는 경우

• Tag를 제거한 후, 삭제 가능

경리월보 계정과 CoA

경리월보 계정에 대한 ERP CoA 할당

경리월보 계정에서 6개 항목에 대한 매출 집계를 별도로 할 것

Account Ballance에서 해당 부분으로 할당할 수 있게 변경.

• 주의사항

1. CoA로 할당할 경우 - 처음 부터, 매출용 비용처리용 어카우트가 철저히 관리되어야 함
2. 처리 후 coa 변경 과정 - 변경시, Expense binding >> 바인딩완료(조정/수정) 부분에서 별도로 수정하는 것 활용

CoA 할당 수정 과정

• Accouting에서 이미 binding 된 것 수정 (해당 전표 찾아서 수정 버튼 클릭)

비용전표 묶음(Expense binding) >> 바인딩완료(조정/수정) 부분

• 계정(Account) 수정하기

틀린 계정을 수정하거나, 집계 목적에 따른 계정으로 다시 분류 한다. (초기에 계정이 확정되어 있다면 문제 없음)

• 참고 : TW ERP에서 사용중인 CoA

프로젝트 개별비 처리 방안

프로젝트 개별비 6개 항목에 대해서 처리하는 방법에 대한 설명이다.

프로젝트 개별비는 현지에서 발생하는 프로젝트 진행매출항목으로 6가지가 지정되어 있다.

[참고] - 프로젝트 개별비 분류 6가지 (단, 현지 운반비와 이에 따른 부가세는 제조운반비 1개로 통일)

1) 제조지급수수료 (용역) - 현지 외주 용액

2) 제조교육훈련비 (기타) - 현지 교육비

3) 제조지급수수료(용역) - 현지 채용 인건비

4) 제조지급수수료(기타) - PJT시운전비, 검사료 및 관련 (임시) 인건비 포함

5) 제조운반비 및 VAT - 현지 운송비 및 현장 물품대 VAT (재고 운반 부가세)

6) 제조소모품비(기타) - 현장 투입 소모성 공구, 안전용구 포함

이에 대한 처리는 다음과 같은 방식이 추천된다.

1. CoA로 선언해서 사용하는 방법
2. Expense report의 공개/비공개 note 부분에 추가하는 방법
3. Expense report의 항목에서 최종 작성시 설명(Description)부분에 추가하는 방법
4. Extrafield 부분 개발
5. 사용자 #1,#2, ..., #6를 주고, 조직을 PJT_개별비 항목으로 함 : Sub-ledger로 등록해서(Accounting Code) 개별비를 사용하는 경우 (인원 혹은 조직으로 구분되어 집계 가능)

[참고]
2번과 5번의 차이는 web상에서 바로 조회가 되는 것인지, 아니면, data export를 통해서, 엑셀에서 조회하는 것인지의 차이임
2번의 경우, Data export를 사용하여, 일단 파일로 필터링하여 추려내는 방법이다.
5번의 경우, Sub-ledger에서 Accouting Code를 선택하여, 화면에서 바로 확인 가능하다. (1번 방법도 동일)

본사 ERP 실적 입력에서 주의해야 할 사항은 본사 ERP (오라클)는 SPG별로 입력되기 때문에, 개별 SPG별 ERP 번호에 맞춰 입력해야지만, 최종 PMS에서 여러 SPG를 합해서 프로젝트 진행율로 나타난다. SPG별 입력은 현재는 본사인원이 임의로 SPG별로 입력하는 것으로 알고 있음. 해당 프로세스에 대한 정확한 지침이나 방향은 확인 필요. 본사 ERP 입력 방식에 따라서, 다음의 방법 중에서 선택하여 사용한다. '25년 12월 현재는 미정

• CoA로 선언해서 사용하는 방법

1) Project ID와 해당 CoA조합으로 확인 가능

2) (미확인) - 본사 ERP의 코드가 바뀐다고함, 따라서, 자주 바뀌는 경우에는 CoA가 너무 많아져서, 복잡

3) 단, 항목이 6개 밖에 되지 않으므로, 기간과 조합하면, 자주 바뀌어도 CoA 별 총합은 변함없으므로, 실제 본사 ERP 입력에는 문제 없음

• Note 부분 활용 - Expense Report의 공개/비공개 note 부분에 추가 (외형적 방법)

1) Tools Export에서 note는 바로 구분하여 엑셀 파일로 추가 가능

2) Export의 경우에, 해당 note를 모두 export하여, 나중에 엑셀에서 해당 부분 부분합 결산

3) 장점 - 바뀌는 본사 ERP번호(PMS Task) 번호를 그대로 유지 가능

4) 단점 - 코드가 너무 많아져서, 현장에서 확인 어려움

5) 권장 사항 - 개별비 부분은 Expense Report를 별도로 1개로 만드는 것 추천 (여러 건 청구 지양)

• Description 필드 활용 - Expense Report에서 세부 작성으로 들어간 다음 (note 작성 이후)

1) Note 부분이 아니라, 해당 line에서 구분 가능 (1개의 ER에서 여러 개 비용(영수증) 처리 경우)

2) Tools의 expense에서 explaination 부분을 export해야함

• Extrafield 부분 개발

해당 부분을 새롭게 개발하는 방법은 이미 공개되어 있으나, 유지관리 목적에서 권장되지는 않는 방법이다.

하지만, 해당 모듈에서는 더 많은 기능을 제공하지만, 상대적으로 더 복잡해지기도 하므로, 양날의 검과 같다. 시스템에 맞추면, 복잡해질 수 있음.

• Sub-ledger로 등록해서 사용: Accouting Code 멤버로 등록

프로젝트 개별비를 멤버로 등록하여, 해당 멤버의 비용으로만 처리

Sub-ledger에서 멤버의 Accouting Code를 참조하여, 별도로 구분함

프로젝트 번호(계약번호)로 구분되고, 항목은 Accounting code로 분류 가능

• 제언

여러가지 방식이 있는데, 현재 PMS 및 본사 ERP에서 운용하기 편한 방법을 고려하여, 상기의 방식 중 하나로 선택하여 사용하는 것을 권장한다.