2026년 9월 21일 (월) 06:58 기준 최신판

Admin 관련 사항입니다.

비즈니스 로직, ERP 내부 운영에 대한 administrator 뿐만 아니라, 시스템 자체의 root 관련 기능도 혼재되어 있습니다. 전체적인 관리를 위한 포인트를 모아 놓은 것입니다.

문서 설명

AM, PM role - PM이 프로젝트 회계관리에 대한 내용입니다.
AM role - 회계담당자가 처리해야 할 업무에 대한 설명입니다.
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() 함수

수정일반 사항

UI 변경
기능 변경
권한 설정

기타 전문적인 시스템 관련해서 참조 문서

시스템관리 참조

비즈니스 로직관련

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

신규 사이트 등록관련

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

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

Multi Company 구성

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

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

주의 사항

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

기타 설정(Dictionary) 부분

해당 화패 선택

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

KRW(한국 원)으로 수정

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

국가 설정으로 들어가는 법

Home → Setup → Modules/Applications
Multi-company에서 설정 (톱니바퀴) 클릭

국가별 default 설정이 가능함

화면언어
Main currency

Currency 구성

다국적 통화 등록 방법

Multi-company는 하나의 모듈이다. 따라서,

Dolibarr ERP에서 Currency를 사용하도록 설정하고, (복잡해서, 대부분 off함)
Muli-company에서 Main currency를 등록 사용함

새로운 통화 추가(사용 enable)

Home → Setup → Dictionaries

Currencies (통화) 선택

신규 통화 추가

* Code : TWD, KRW, USD 등
* Name : Taiwan Dollar 등
* Symbol : NT$, ₩, $

저장

Multi-Currency 모듈 활성화

Home → Setup → Modules/Applications
Multi-Currency 모듈 활성화
설정 화면에서 사용하려는 통화 선택
환율 입력

Dolibarr는 Multi-Currency 모듈을 통해 여러 통화를 관리하며, 메인 통화 대비 환율을 등록해야 됨.

# 환율 변동을 지속적으로 변경해 주어하는 불편함이 있음, Main 통화만 사용하고, 환율은 별도로 계산하는 방식 추천

처음 ERP 구성

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

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

전체 tag/category 메뉴

전체 태그, 카테고리를 조정하는 메뉴는 tools 메뉴의 카테고리로 들어간다.

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로 나누어져 있는 경우에는 관련 인원별로 회계 코드를 별도로 놓아서, 구분할 수 있다.

주의 사항

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

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

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

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

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

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

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

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

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

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

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

Bank Accounts의 Journal 연결

Accounts를 설정하고, 이를 별도의 분개장(Journal)을 만들어야지, 별도로 집계된다.

즉, CoA를 통한 계정과목 별로 집계는 되는 데, 그 집계 내용 중에서 프로젝트 별로 어디에 속하는 지 구분하기 위해서는 journal(분개장)이 필요하다.

따라서, 다음의 과정을 설정해 주어야 한다.

분개장을 만들고 (임의의 분개장)
분개장 CoA 코드 (혹은 그룹) 결정 - 비용인지, product인지 구분
은행계좌 연결

이것은 admin 계정만 가능하고, 처음 설정 1회만 해 주면 된다.
또한, 프로젝트 개별비 내용만 별도로 만드록 싶으면, 여기서 Journal(분개장)을 만들어서, accouting 작업할 때, 별도로 기록하게 할 수 있다.

분개장 연결의 예

Defualt accounts

ERP 처음 사용을 위해서, 기본적으로 설정해야 할 계정에 대한 설명입다. 계정 사용에서 가장 중요한 부분이고, 이에 대한 설명이 잘 없어서, 여기서 많이 delay된다.

default account

기본 계정이라고 하면, 일단 무엇인지 모르지만, 시작점을 지정하는 것이다. 즉,

고객 - 411-Customers

협력공급사 - 401-Suppliers

GL 계정 (General Ledger, 총계정원장) 4-Amounts receivable and payable

직원 (현채인) 비용 - 421-Staff Cost (직원 지급 비용 총괄]

기타 deault account

Product

Account (from the Chart Of Account) to be used as the default account for the sold products (used if not defined in the product sheet) - 33 - Ongoing production of goods

* Account (from the Chart Of Account) to be used as the default account for the sold services (used if not defined in the service sheet) - 34 - Ongoing production of services

* Account (from the Chart Of Account) to be used as the account for transitional bank transfers - 58 - Internal Transfers [내부이체]

* Account (from the Chart Of Account) to be used as the account for unallocated funds either received or paid i.e. funds in "wait[ing]" - 471 - Waiting Accounts [임시계정]

VAT accounts

부가세 항목 결정

대만의 경우 영세율과 부가세 5%가 있다.

* 매출 부가세 : 6312

* 매입 부가세 : 6311

기타 세금 : Tax accounts

기타 세금에 관련된 내용이다. 별도의 세금 혹은 세금과 관련된 진흥회비 등 세금 성격이 붙는 것들을 정의하여 사용할 수 있다.

ACT Annual corporation tax TW - Taiwan 697

   IT	income tax	TW - Taiwan	695	
   OPT	Other payroll taxes	TW - Taiwan	647	
   OTD	Other taxes, duties and similar payments (tax administrations)	TW - Taiwan	635	
   TOP	Taxes and similar payments on remuneration (tax administrations)	TW - Taiwan	631

비용계정 설정

기타 항목(Dictionary) 설정이라고도 한다. 즉 비용 계정 중에 코드로 지정해서 사용할 수 있는 것이다.

실제 expense report 작성할 때 코드를 사용할 수 있어야 하는데, 이 부분에 대해서는 별다른 언급은 없다. 단지 label을 이용해서 검색이 가능하다. 추후 code 사용 여부 확인할 것

* ERP 내부적으로 사용하는 code를 말하는 것일 지도 모름, 아직 코드로 활용되는 것 없음

* Expense Report 작성 중 "유형" 부분 입력 창 검색 화면

SL_Group 활용

SL_Group은 Salary_Group을 설정하는 것이다.이것은 only blilling의 Salary에서만 사용하는 tag/group으로 설정도 유니크하다.

급여 입력 화면

Billing >> salary 메뉴에서 입력

* 급여 입력시 SL_Group 선택

* 현재 급여 구분 기준은 단순 프로젝트 구분으로 사용 - 단 하위 프로젝트가 여러 개의 경우에는 추가로 구분 tag/group 생성할 것

* 기타 구분자 추가할 수 있음

SL Group은 2가지 의미를 갖고 있다.

1) 프로젝트별 그룹 - 프로젝트별 그룹

2) pay band별 그룹 - 역무에 따른 pay band 설정

TW ERP에서는 1)의 프로젝트 별 그룹으로 설정하는 것으로 사용한다. 즉, 프로젝트별 slary를 취합하기 위해서, billing의 경우 tag를 부여하여, 나중에 확인하기 위한 것이다.

!참고: Project 별로 구분되기 때문에 SL_Group(tag/group)으로 구분하는 것은 이중으로 구분하는 것이다. 따라서, 나중에는 2) pay band로 변경해서 사용해도 된다.

SL_Group 설정

SL_Group의 설정은 일반적인 tag/group (tools >> tags/group설정 메뉴)와 달리, finance 모듈 설정에서만 만들 수 있다.

SL_Group 작성하는 법

(admin만 가능하다)

1. Home >> 모듈 / 응용 프로그램 진입

2. Finance >> Salary 선택

3. Complementary attributes (salaries) tab 선택 및 수정

* 2-1 Finance에서 Salary 진입

* 2-2 Salary 항목 세부 조정

* SL_Group의 list를 수정하거나, 필요시 새로운 구분자를 추가한다.

* 2-2 Salary 항목 세부 조정

* SL_Group의 list를 수정하거나, 필요시 새로운 구분자를 추가한다.

참고

* SL_Group외에 추가적인 입력항 만들기 (항목: test)

* Billing 입력시 추가된 test filed

신규 멤버 추가의 예

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

신규 멤버 추가하기

준비 사항

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

중요 규칙

사용자 ID는 회사 email ID를 사용한다. 예를 들어 HONGGILDOG@ls-electric.com의 경우, HONGGILDONG이 ID가 되어야 함
사용자 ID를 임의로 생성하는 것은 금지하며, (필요시 임시생성 OK) 회사 email 부여 받고 사용한다. (현채인의 사번은 email 주소임)
사용자 이름은 성: 영문성 현지이름, 이름 부분 영어이름 으로 구성 할 것 (검색시 확용)
프로젝트 회계 코드 반드시 넣을 것 (준비사항 동일)
작업 그룹 : 일반 사용자는 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를 제거한 후, 삭제 가능

Multi-company 구성시 주의사항

멀티컴패니는 하나의 ERP서버에서 여러 개를 운영할 때 사용하는 모듈이다. 개별적으로 설치해서 사용해도 되지만, 여건상 1대에서 모든 데이터를 사용하는 것이다.

시스템 관리상 편리하지만, 반대로, 서버 1대에 여러 정보를 사용하므로, 백업 등의 관리에 특별한 주의를 요한다.

멀티 사용자

기본적으로 사용자들은 서로 시스템을 넘어서 사용할 수 없다. 즉, 대만 사용자가 이집트 사용자를 조회할 수 없다.

그러나, 시스템 관리자(Administrator)는 관리 측면에서 모든 사이트를 봐야 하기 때문에, 여러 사이트 운영관리자는 필연적으로 관리자(Administrator) 권한을 갖게 된다.

엑셀을 이용한, 사용자 일괄 추가

사용자를 일괄로 추가할 수 있다. 단, 이미 추가된 사용자는 삭제하고, 다시 올리는 것만 가능하다.

즉, 다음과 같은 제약이 있다.

 Insert - 가능(O), 추가하는 것은 엑셀, csv 파일로 가능
 update - 불가(X)

수작업으로 update하거나, DB에 직접 access하는 방법만 가능하다. 단, 3rd party 프로그램을 구매해서 사용 가능하다.

SQL 방법의 경우, 프로그램적인 요소를 사용해야 하고, dolibarr 설치 환경이 docker 이므로, docker 환경과 docker 네트워크, 일반 네트워크 등을 이해하는 경우에만 SQL 업데이트를 사용하는 것이 바람직하다.

기본 회계, 세금 코드 설정

기본 회계 계정과목(CoA)를 설정해 주어야 한다.

주의사항

처음 멀티컴패니를 이용해서, 다른 조직/국가를 생성할 때, 기본값(defualt)는 회계코드(CoA)를 복사하지 않는다.

또한, 버전 간의 오류로 복사한다고 해서, 바로 사용하지 못하는 경우도 있다.

따라서, 회계코드(CoA)를 복사하기 보다는

현재 사용중인 CoA를 export 한다. (Tools 메뉴)
Export한 CoA를 해당 멀티컴패니 모듈에서 admin이 import하여 사용한다.

만약, 회계코드를 복사하여 그래도 사용하는 경우에는 (CoA만 복사하여 사용하는 경우이다. 해당 CoA에 할당된 값을 복제하는 것은 아님, 마치 목차나 양식만 복사해오는 것과 동일)

멀티컴패니 생성할 때, 맨 아래, copy사용 부분을 체크해 주면된다.

나중에 그림 추가, 멀티컴패니 생성, 수정에서 맨 아래 라디오 버튼 클릭 화면 추가

기본 회계설정

기타 회계설정과 동일 (아마 작성해 놓았을 듯... 다 따로 있어서 그렇지..)

Accouting에서 설정(Setup)

내용 순서.

Accouting Journal

프로젝트가 여러 개의 경우, 새롭게 만들어 줄것, default는 1개를 사용하게 되어 있음.

Chart of accouts models

사용중인 CoA 모델에서 선택하여 사용, 없으면, 신규로 import해서 사용

생성/수정으로 copy한 경우

안보이는 경우도 있다. import를 하면, 이전 것은 무시되어 update가 되므로, import 후에는 보이기도 한다.

Accounting period

회기년도를 입력한다. 각 국가의 회기기간에 맞춘다.

Defualt Accouting

가장 중요한 항목으로 이것이 설정되지 않으면, 아예 동작하지 않는다. 짇금 당장 처리하지 못하더라도 발생된 사항을 일단 모아녾는 temporary 계정 역할을 하므로, 반드시 설정해 주어야 한다.

기본적인 설정 사항은 다음과 같다.

번호	설명	할당 계정(코드)
Customer/Users
1	Account used for "customer" third parties	411 - Customers
2	Account used for the "vendor" third parties	401 - Suppliers
3	Accounting account used for user third parties	410 - Customers and Related Accounts
4	Account used by default for "users" on expense reports	421 - Staff - Remuneration due
Product
5	Account to be used as the default account for the sold products, used if not defined in the product sheet	33 - Ongoing production of goods
Service
6	Account to be used as the default account for the sold services, used if not defined in the service sheet	34 - On-going production of services
기타
7	Account to be used as the account for transitional bank transfers	58 - Internal transfers
8	Account to be used as the account for unallocated funds either received or paid, i.e. funds in waiting	471 - Waiting Accounts

VAT Accounting

VAT를 사용하는 나라에서는 해당 VAT를 설정해 준다.

VAT 요율(%) 설정 및 매입 부가세 6312, 매출 부가세 6311이다.

TAX Accounting

VAT를 제외한 기타 세금은 여기서 추가해고 해당 account code를 할당한다.

나중에 그림 추가할 것. Accounting >> Setup >> Tax Accounting 임

Closure Accounting

결산 계정, 할당하면, 결산과 이월 코드를 입력해 주면, 자동 반영된다.

추후 사용

해당 국가 혹은 프로젝트 마감 결산에서 활용할 수 있다.

잘 사용하면 아주 유용한 기능이지만, 본사 회계와 관련되어 반영되지 않는 항목들이 있어서, 이러한 것들이 완전히 정의되지 않은 상태에서 사용하면 문제가 있어서, 우선 결산에 대한 부분을 회계와 확정한 후에 사용하는 것이 좋다.

Bank 설정 및 계정

은행 계정 설정에서 주의해야 할 것은

Journal 설정
bank account 할당이다.

Journal 설정

프로젝트가 1개만 관리할 경우, default 사용해도 됨.

프로젝트가 여러개을 경우, 은행(BQ), 비용(ER)을 추가로 만들어 주고, 연결해 주어야 한다.

Bank account 할당.

수금 계좌: Saving bank의 경우에는 Account를 그룹 코드 : 70을 사용한다. 비용 계좌 : Expense bank의 경우에는 Account를 그룹 코드: 60-shopping을 사용한다.

경리월보 계정과 CoA

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

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

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

주의사항

CoA로 할당할 경우 - 처음 부터, 매출용 비용처리용 어카우트가 철저히 관리되어야 함
처리 후 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) 제조소모품비(기타) - 현장 투입 소모성 공구, 안전용구 포함

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

CoA로 선언해서 사용하는 방법
Expense report의 공개/비공개 note 부분에 추가하는 방법
Expense report의 항목에서 최종 작성시 설명(Description)부분에 추가하는 방법
Extrafield 부분 개발
사용자 #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에서 운용하기 편한 방법을 고려하여, 상기의 방식 중 하나로 선택하여 사용하는 것을 권장한다.

선처리 방법

개별비 처리용 ID를 별도로 생성 (생성자가 아예 다르게 만듬)

CoA 구성

해당 CoA로 구분 - 본사 PMS에서 Task 번호 연동 고민 필요

여러개 CoA번호로 발생 위험 있음

ER작성시 구분

- 개별비 처리용 ID 생성 : 사람처럼처리 (로그인을 달리해야 함)

예시)
YL : 프로젝트 개별비
RLM : Red line 프로젝트 개별비 처리용 
* 처음부터 구분해서 사용

후처리 방법

일반적인 비용전표(ER) 처리하듯이 하고, binding 과정에서 Journal(분개장)에서 변경해줌 (즉, 다른 공책에 번호 바꿔서 저장) CoA 그룹은 6(Expense) 이하 번호 할당해야 함

CoA 구성

해당 CoA로 구분 - 본사 PMS에서 Task 번호 연동 고민 필요

여러개 CoA번호로 발생 위험 있음

Accouting Journal 별도로 생성

회계처리시, 바인딩(Binding)에서 해당 account 번호로 수정

예시)
개별비 YL : accouting journal 생성
개별비 RLM : accouting journal 생성
* Binding에서 account 번호를 변경함

회기년도 관리

회기년도를 마감 및 관리하는 내용입니다.

1년에 1번 이전 기록을 마감하고, 새로운 회기년도를 관리하기 위한 내용입니다.

admin만 가능합니다.

1. 회기년도 설정하기, fiscal period open

회기년도 이름을 지정(보통 연도)하고, 시작기간과 끝기간을 설정해 준다.

해당 설정은 admin만 가능하고, Accounting 메뉴에서 설정으로 들어가야 만들 수 있다.

2. 회기년도 마감하기, fiscal period close 회계기간(회기)이 마감이 되면, 해당 기간을 마감한다.

회기가 마감되면, 해당 회기의 내용을 수정하거나 변경할 수 없으니 주의한다.

fiscal period를 close할 경우, 경고문과 함께 마감이 되는 것을 알려 준다.

주의 - 해당 회기를 마감하면, 해당 기간 내용을 수정하거나 변경, 삭제가 불가능하다.