매장이 두 곳 이상일 때 매출을 한 화면에서 보는 방법. 다점포 매출, 매장별 매출 비교, 통합 정산 관련 내용도 함께 담았습니다. 다점포·체인 관리 — 여러 매장 재고·매출을 한 화면에.
가게 하나일 때는 그날 마감하고 장부 한 번 맞추면 끝난다. 문제는 두 번째 매장을 열면서 시작된다. 본점 매출은 본점 POS에, 2호점 매출은 2호점 POS에 남는다. 각각은 잘 돌아가는데, 두 곳을 합친 숫자가 어디에도 없다. 그래서 대부분 사장님이 저녁마다 두 군데 전화를 돌리거나, 직원이 카톡으로 보낸 숫자를 엑셀에 다시 옮겨 적는다. 이 방식이 무너지는 지점은 정해져 있다. 하나는 옮겨 적다가 틀리는 것이고, 다른 하나는 시차다. 2호점 마감이 늦으면 그날 전체 매출은 다음 날 아침에야 나온다. 어제 얼마 팔았는지를 오늘 점심에 아는 상태로는 판단할 게 별로 없다. 여러 매장 매출을 통합해서 본다는 것은, 각 매장에서 발생한 판매·매입·시재를 **한 데이터베이스에 모아 두고 화면에서 매장별로 나눠 보거나 합쳐 보는 것**을 말한다. 귀금속프로그램에서 이걸 지원하느냐 아니냐는 매장이 하나일 때는 티가 안 나지만, 둘부터는 매일 티가 난다.

첫 번째는 각 매장이 따로 쓰는 프로그램의 데이터를 주기적으로 내려받아 합치는 방식이다. 엑셀로 내보내서 취합하는 것도 여기 속한다. 초기 비용이 거의 안 든다는 게 장점이고, 사람 손이 매일 들어간다는 게 단점이다. 매장이 두 곳이면 버틸 만하고, 세 곳부터는 취합 담당이 따로 필요해진다. 두 번째는 본점 서버에 매장들이 접속해서 쓰는 방식이다. 데이터가 처음부터 한 곳에 쌓이니 합칠 일이 없다. 대신 본점 인터넷이나 컴퓨터가 멈추면 다른 매장도 같이 멈춘다. 예전에 이 구조를 많이 썼고, 지금도 쓰는 곳이 있다. 세 번째는 클라우드에 데이터를 두고 매장마다 접속하는 방식이다. 어느 매장이 꺼져 있어도 나머지가 영향을 안 받고, 사장님은 집에서 휴대폰으로 봐도 같은 숫자가 나온다. 요즘 나오는 귀금속프로그램은 대체로 이쪽이다. 월 사용료가 붙는 대신 서버를 직접 관리할 일이 없다. 어느 쪽이 맞는지는 매장 수와 거리에 달렸다. 한 건물 안에 두 개면 두 번째도 쓸 만하고, 지역이 떨어져 있으면 세 번째가 편하다.

합쳐 놓기만 하면 "이번 달 총 얼마"밖에 안 나온다. 총액은 어제와 오늘이 다르다는 것만 알려 주고 왜 다른지는 말해 주지 않는다. 매장별로 나눠 볼 때 의미가 생긴다. 귀금속 매장에서 매장별로 비교해 볼 만한 항목은 대체로 이런 것들이다. 매출액, 매입액(금 매입 포함), 건수, 건당 평균 단가, 품목별 구성(순금·14K·18K·다이아·시계), 그리고 재고 회전. 이 중에서 총매출보다 먼저 봐야 하는 건 **건수와 건당 단가**다. 매출이 줄었을 때 손님이 줄어든 것인지, 손님은 그대로인데 객단가가 떨어진 것인지에 따라 할 일이 완전히 달라진다. 금 매입이 섞이는 것도 귀금속 특유의 문제다. 매입은 돈이 나가는 거래인데 장부에는 거래로 잡힌다. 매장별 비교를 할 때 매입 비중이 높은 매장과 판매 위주 매장을 같은 잣대로 세우면 엉뚱한 결론이 난다. 판매와 매입을 나눠서 볼 수 있어야 한다. 기간 비교도 챙길 항목이다. 이번 달과 지난달, 올해 이달과 작년 이달. 귀금속은 계절을 심하게 타서 5월과 8월 매출을 나란히 놓으면 뭘 봐도 이상하게 보인다.
'실시간'이라는 말이 붙어도 실제 동작은 프로그램마다 다르다. 판매 등록하는 순간 본사 화면에 뜨는 것도 있고, 몇 분 간격으로 올리는 것도 있고, 마감을 눌러야 넘어가는 것도 있다. 도입 전에 이 부분을 구체적으로 물어봐야 한다. "실시간 지원"이라고만 적혀 있으면 마감 시점 동기화인 경우가 흔하다. 여기서 걸리는 게 인터넷 끊김이다. 매장 인터넷이 잠깐 나가도 판매는 계속 받아야 한다. 그래서 로컬에 먼저 저장하고 연결이 돌아오면 올리는 구조인지, 아니면 연결이 없으면 아예 등록이 안 되는지가 갈린다. 후자면 통신 장애가 곧 영업 중단이다. 시계도 봐야 한다. 매장마다 PC 시각이 조금씩 다르면 같은 거래가 다른 날짜로 잡힌다. 월말 하루 차이로 이번 달 매출이 다음 달로 넘어가는 일이 실제로 생긴다. 서버 시각을 기준으로 잡는지 확인해 둘 항목이다.

매장 세 곳 매출을 더하면 전체 매출이 나올 것 같지만, 그렇게 안 되는 거래가 몇 가지 있다. **매장 간 이동**이 대표적이다. 본점 재고를 2호점으로 넘겨서 2호점이 팔았다면, 이 물건은 몇 번 잡혀야 하나. 이동을 매출로 잡는 프로그램이면 본점에서 한 번, 2호점에서 한 번 해서 전체 매출이 부풀려진다. 이동은 매출이 아니라 재고 이동으로 처리하고, 통합 화면에서는 제외해야 숫자가 맞는다. **교환과 반품**도 매장을 넘나든다. 본점에서 산 걸 2호점에서 바꾸는 손님은 늘 있다. 이때 취소가 어느 매장 매출에서 빠지느냐가 정해져 있어야 한다. 원래 판 매장에서 빼면 판매 실적은 맞고 그날 시재는 안 맞는다. 처리한 매장에서 빼면 반대다. 어느 쪽이든 규칙이 정해져 있고 통합 화면이 그 규칙대로 계산하면 된다. 정해 두지 않으면 매달 다투게 된다. **사업자 단위**도 확인할 항목이다. 매장마다 사업자등록번호가 따로면 세금계산서와 부가세 신고는 각각이다. 통합 화면은 사장님이 보려고 합친 것이고, 신고는 여전히 매장별로 간다. 이 둘을 같은 화면에서 각각 뽑아낼 수 있는지 봐야 한다.

매출보다 먼저 통합 효과가 나는 쪽이 재고다. 손님이 찾는 물건이 이 매장에 없어도 2호점에 있으면 팔 수 있는데, 있는지 없는지를 모르면 그냥 돌려보내게 된다. 여러 매장 재고를 한 화면에서 본다는 건 품번으로 검색했을 때 매장별 수량이 같이 뜬다는 뜻이다. 여기까지 되면 전화 한 통으로 확인하던 일이 없어진다. 더 들어가면 그 자리에서 이동 요청을 걸고, 받는 매장이 승인하면 재고가 넘어가는 것까지 처리된다. 귀금속은 품번 관리가 까다로운 편이다. 같은 디자인이라도 중량과 순도가 다르면 다른 물건이고, 낱개마다 중량이 다른 상품도 많다. 매장마다 품번 체계를 따로 쓰고 있으면 합쳐 봐야 검색이 안 된다. 통합을 하기 전에 **품번과 분류 체계를 하나로 맞추는 작업**이 먼저다. 이게 다점포 전환에서 시간이 제일 많이 드는 부분이다.

첫 매장에서 쓰던 방식을 그대로 두 번째 매장에 복사하면 대개 나중에 다시 손본다. 두 번째를 열기 전에 정해 두면 편한 항목이 몇 가지 있다. 품번 체계와 분류 코드를 통일한다. 앞에서 말한 그 작업이다. 매장 하나일 때 정리하는 것과 두 곳 데이터를 맞추는 것은 품이 다르다. 직원 권한을 나눈다. 매장 직원이 다른 매장 매출까지 볼 필요는 없다. 자기 매장만 보이고 사장님만 전체가 보이는 구조가 기본이다. 권한을 매장 단위로 끊을 수 있는지 확인해 둔다. 마감 시간과 규칙을 맞춘다. 어느 매장은 밤 9시에 마감하고 어느 매장은 다음 날 아침에 하면 통합 숫자의 기준일이 흔들린다. 데이터를 내보낼 수 있는지도 본다. 프로그램을 바꿀 일이 생겼을 때 지난 거래를 못 꺼내면 매장 수만큼 발이 묶인다. 엑셀이든 CSV든 전체 거래를 내려받을 수 있는지는 도입 전에 물어볼 항목이다.
숫자를 모아 놨어도 안 보면 소용이 없다. 다점포를 운영하는 사장님들이 실제로 매일 보는 항목은 대체로 몇 개로 좁혀진다. 매장별 오늘 매출과 건수. 이 둘만 나란히 있어도 어느 매장이 조용한지 바로 보인다. 여기에 전주 같은 요일 숫자를 붙이면 판단이 빨라진다. 귀금속은 요일 편차가 커서 어제와 비교하는 것보다 지난주 같은 요일과 비교하는 게 낫다. 매입 금액. 금 매입은 현금이 나가는 거래라 시재와 직결된다. 매장별 매입액이 갑자기 뛰면 시재를 확인해야 한다. 미수와 외상. 매장마다 단골 관리 방식이 달라서 통합해 놓고 보면 어느 매장 미수가 쌓이고 있는지가 드러난다. 재고 금액. 매일 볼 필요는 없지만 주 단위로는 본다. 매장별 재고 금액이 매출 대비 어느 정도인지가 회전율이고, 이 숫자가 매장마다 크게 벌어지면 물건 배분을 조정할 때가 된 것이다.
한국공식금거래소 소아벨라
금은방·금거래소 창업을 실제로 진행한 곳에서 절차와 조건을 확인해 보세요.