|
1. 자재관리 프로젝트 ▶
서론
현재 액세스 프로젝트성 모델링에 대한 관심과 기대는 크지만, 단지 액세스를 오피스군의 일부 프로그램 정도로 생각하고
있습니다. 즉 액세스에 대한 정보 부족으로, 기존의
액세스개발자(MOD)가 소수라서, 기업에 적용시킬 모델링
개발을 할 여력이 없던가? 아니면 구입가격이 높아서 배울 수 있는 동기부여 결여 및 전문학원이 거의 없어서라는 이유로 액세스에 접근하지 못하고
있습니다.
OFFICE BETA 버전의 추가기능 XML를 사용해 본 결과, 업무통합 및 인트라넷 등 신규 단넷 도입은 업무 프로세스에 많은 변화가 나타날 것은
분명합니다. 이중 하나가 액세스의 경우, 전문 프로그램
개발자가 아니더라도 DB를 구축하고 업무를 개선시킬 수 있는 방법을 담고 있어 프로그램을 전공하지 않은 사람이라도 쉽게 접근하여 웹과 연계하여 개발할 수
있습니다. 따라서 업무 프로세스에 대한 전문가라면 어느 정도 프로그램 작성이 가능하게 될
것입니다.
본인이 여기서 설명하고자 하는 것은 프로그램의 소스를 공개하는 것에 초점을 둔 것이 아니라 자신의 업무 프로세스를 분석하여 DB 설계 및 제작하는 과정을 보여주고자 하는 데 목적을 두고
있습니다. 여기서 메뉴얼 방식으로 설명한다면 프로세스에 대한 내용을 담기 어렵다는
판단 하에 접근방법을 달리하여 설명하고자 합니다. 따라서 사용자의 업무 목적에 부합되도록 최선을 다하여 설명할 것이며, 단계별 설명 보충이 필요하다면 추가 질의할
예정입니다.
▶ 본론
그럼 이윤이란 어떤 공식에서 출발하여 설명될 수 있을까요?
즉, INPUT(투입) - OUTPUT(산출) 공식으로 결론을 내릴 수가
있습니다.
단순한 목적에 준하는 모델링 사례분석을 통하여 프로그램의 접근방법을 설명하고자
합니다.
● 사례
구분 |
내용 |
회사의 규모 인원
|
30명 |
매출
|
년 150억원 |
전표처리
|
100(건/일), 2,500(건/월), 30,000(건/년) |
데이터용량
|
추정 년 5M(액세스의 최대용량 2G) |
품목코드
|
5,000개 |
사용자
|
4명(네트워크 13명까지 가능) |
주목적
|
재고관리 및 공정별 투입 원가분석 |
프로세스
|
입고 -> 공정 -> 완성 -> 판매
(일반적으로 청구->구매->구매요청서->입고->불출) |
- 입 고 : 거래처로부터 자재가 반입되어 품목별로 입고단가
- 공 정 : 입고된 자재에 대한 회사내부에서 가공처리
- 완 성 : 공정처리에서 완제품
- 판 매 : 거래처별로 완제품을 판매
단, 설명상 입고 품목을 가공하여 다른 품목으로 변경하여 설명되어야 하나 설명의
이해를 돕기 위해 과정별 단가구분만 하고 품목은 단계별 일정하다는
가정 하에 설명하고자 합니다. |
- 응용적용대상 : 자동차부품, 설비시스템을 사용하는 기업, 중소도매,
제약회사(BOM(BILL OF MATERIAL))에 대한 내용을 포함예정)
* 공정별 공정단계추가에 대한 COST CENTER를 지정하면 제조 공정별 원가분석까지 가능
* 현재 원가분석은 1단계로 제한하여 설명
- 결과물
* 거래처별 입고 & 판매까지 내역서
* 입고 & 판매 자재전표
* 입고 & 판매 수량 및 금액(이동평균법) 재고
=>과정별 총 보고서가 약 30개 정도 출력(추가가능)
☞ 참고하기
제일 중요한 것은 업무상 프로토타입을 기획하고, 프로그램상 관계알고리즘을 정확하게 판단하여 설계하는
것입니다 |
1. 테이블의 구성
※ 테이블을 구성할 때 주의 사항
1. 필요이상으로 많은 테이블 관계설정을 하지
않는다.
2. 무결성을 지킨다.
3. 적정한 필드크기를 선택한다.
4. 차후 추가될 테이블의 범위를 감안하여 설계한다.
5. 프로세스에 대한 관련 공감대를 형성한 후 테이블 설계작업을 한다.
6. 영문으로 작성하는 습관(설명상 필요하여 한글필드 사용) |
※ 주의 사항 |
1. 품목코드 작성 |
|
- 품목조합 : 00-000-00 |
품목코드의 변동이 많은 경우 관계형 설정은
바람직하지 않습니다.
이유는 관계형 설정을 할
경우, 삭제를 한다던가 품목명을 변동하면 기존의
자재전표에 변동되어 나타나 기존 값도 변해 다른
결과를 얻을 수 있습니다.
따라서 작성한 판단,
데이터의 속성 및 크기를 고려하여 설정할
필요성이 있습니다. 품목코드의 자릿수에는 일정한
규칙이 있어야 합니다.
예로 자재하위에 단가를 삽입한 이유는 단계별
단가가 고정된 것이 아니라 차후 단계별
단가변동이 있으면 현재 입력된 단가를 변동시켜
적용을 시키기 위해 만든 것입니다.
품목구분1, 2, 3 으로 나눈 이유는 품목코드의 조합
가능성을 보이기 위해 만든 것입니다. |
2. 거래처 등록 |
|
- 우편번호 검색방식을 이용하여 나머지
주소만 입력할 수 있는 고객관리프로그램과
연동하여 만드는 것이 좋습니다. |
3. 전표 입력 |
|
- 전표의 수가 많다면 입고, 공정, 완재,
판매의 한 테이블에서 작성되도록 하는 것 보다
별도의 테이블과 연결되도록 작성하는 것이
데이터의 안정성 및 속도 면에서 효율적입니다.
만들 때는 테이블의 크기와 PC의 사양을 고려하여
차후 관리차원까지 고려하여 개발해야 합니다.
필드수가 10개, 레코드가 300,000개가 있다면 용량은...
등등, 이와 같이 평가한 후 테이블 구성 조직도를
구성해야 합니다. 그렇다고 최대용량이 2GB라고
해서 무조건 액세스로 개발하지 는 말아야 합니다.
- 여기서는 많은 쿼리를 사용했지만 쿼리를 많이
사용한다는 것은 프로그램의 속도를 저하시키는
것이 될 수 있으며, 필터방식으로 단계전표를
처리하는 것은 처음 처리속도에는 문제가 없지만
나중에 많은 전표를 검색하다 보면 속도가
낮아짐을 알 수 있습니다. |
● 테이블: 거래처
1 페이지
이름 |
형식 |
크기 |
거래처코드(PK) |
텍스트 |
25 |
거래시작일 |
날짜/시간 |
8 |
회사이름 |
텍스트 |
25 |
대표자이름 |
텍스트 |
50 |
전화번호1 |
텍스트 |
50 |
전화번호2 |
텍스트 |
25 |
팩스 |
텍스트 |
25 |
주소 |
텍스트 |
25 |
우편번호 |
텍스트 |
25 |
EMAIL |
하이퍼링크 |
- |
비고 |
텍스트 |
50 |
● 테이블 : 자재상위
이름 |
형식 |
크기 |
일련번호(PK) |
정수(Long) |
4 |
전표번호 |
정수(Long) |
20 |
전표구분 |
텍스트 |
4 |
발행일 |
날짜/시간 |
8 |
부서코드 |
정수(Long) |
4 |
발행자 |
텍스트 |
25 |
거래처코드 |
텍스트 |
25 |
수정일 |
날짜/시간 |
8 |
● 테이블 : 자재하위
이름 |
형식 |
크기 |
일련번호(PK)
|
정수(Long)
|
4
|
전표번호(FK)
|
텍스트
|
15
|
품목코드
|
텍스트
|
15
|
창고코드
|
정수(Long)
|
4
|
단위
|
텍스트
|
5
|
단가
|
실수(Double)
|
8
|
수량
|
실수(Double)
|
8
|
금액
|
실수(Double)
|
8
|
제품구분
|
텍스트
|
25
|
비고
|
텍스트
|
25
|
● 테이블 : 품목코드상위
이름
|
형식
|
크기
|
품목코드(PK)
|
텍스트
|
15
|
품목상위명
|
텍스트
|
25
|
품목구분1
|
텍스트
|
2
|
품목구분2
|
텍스트
|
3
|
품목구분3
|
텍스트
|
2
|
단가1
|
실수(Double)
|
8
|
단가2
|
실수(Double)
|
8
|
단가3
|
실수(Double)
|
8
|
단가4
|
실수(Double)
|
8
|
비고
|
텍스트
|
25
|
- 품목코드(기본키)
예) 11-111-11 : 품목구분1 - 품목구분2 - 품목구분3
- 품목상위명
예) 현대-엔진-오일 : 품목명1 - 품목명2 - 품명3
- 단가
단가1 - 입고
단가2 - 공정
단가3 - 완성
단가4 - 판매
● 테이블 : 품목구분1, 품목구분2, 품목구분3
이름
|
형식
|
크기
|
품목구분1,2,3(PK)
|
텍스트
|
2
|
품목명1
|
텍스트
|
15
|
비고
|
텍스트
|
15
|
* PK(PrimaryKey) : 기본키,
● 진행과정
- 업무 프로세스과정 정리
- 관계형 설정, 데이터의 크기 등 검토
- 담당자의 프로세스에 대한 결과물 검토
- 초기프로세스와 진행프로세스결과와 지속적인 비교분석
목차 |
다음
|