판매를 기록하는 방법

판매를 기록할 때 만들어지는 것

Skyline Nexus에서 판매 한 건은 transactions 테이블의 sell 유형 행 하나와, 판매 라인 묶음, 그리고 0개 이상의 결제 기록으로 이루어집니다. 이 셋은 의도적으로 분리되어 있습니다. 인보이스는 고객에 대한 청구권입니다. 라인은 선반에서 나간 물품입니다. 결제는 들어온 돈입니다. ERP에서 판매를 다룰 때 생기는 혼란의 대부분은 이 셋을 하나의 사건으로 취급하는 데서 옵니다. 매장 계산대에서는 대개 같은 순간에 일어나기 때문입니다.

회계상으로 이들은 같은 사건이 아닙니다. 인보이스는 수익과 매출채권을 만듭니다. 라인은 재고를 줄이고 매출원가를 만듭니다. 결제는 매출채권을 정산하고 현금을 움직입니다. 외상으로 판매하면 결제는 몇 주 뒤에 일어나고, 그 사이 매출채권은 재무상태표에 남아 있습니다. 선수금을 받으면 인보이스가 생기기 전에 돈이 먼저 들어옵니다. 실제 기업에서 이 모든 경우가 일어나기 때문에 시스템은 이를 모두 모델링합니다.

따라서 판매를 기록할 때의 실무적인 질문은 어떤 버튼을 누르느냐에 그치지 않습니다. 지금 이 셋 중 무엇을 만들고 있으며, 무엇을 의도적으로 아직 만들지 않고 있는가 하는 질문입니다. 그 답은 거의 전적으로 양식의 한 필드, 곧 아래에서 설명할 “상태” 필드가 결정합니다.

같은 문서로 들어가는 세 개의 문

왼쪽 메뉴에 “판매”라는 드롭다운이 있습니다. 그 아래 여러 항목은 모두 같은 종류의 문서를 작성하며, 양식을 얼마나 많이 보여 주느냐와 얼마나 빨리 입력할 수 있느냐만 다릅니다.

완성된 문서는 어느 문을 사용했든 “모든 판매”(/sells)에 나열됩니다. 임시저장과 견적서는 아직 실제 인보이스가 아니어서 판매 목록을 어지럽히지 않도록 “임시저장 목록”(/sells/drafts)과 “견적서 목록”(/sells/quotations)이라는 별도 목록을 가집니다. POS 영수증도 “POS 목록”(/pos)에 따로 나타납니다.

일부 동작을 설명해 주므로 알아 둘 만한 구현상의 사실이 하나 있습니다. “판매 추가” 양식은 POS 화면과 같은 컨트롤러로 제출됩니다. 하나의 저장 루틴 위에 앞단 화면이 둘 있는 것입니다. 그래서 어느 화면에서 시작했든 세금 규칙, 재고 규칙, 원장 기록이 동일하며, POS 영수증과 “판매 추가” 인보이스를 회계상 다르게 처리할 것이라고 기대해서는 안 되는 이유도 여기에 있습니다.

• “POS”(/pos/create)는 터치 중심의 계산대 화면입니다. 고객 한 명, 상품 그리드, 결제 패널로 몇 초 만에 끝납니다. 소매, 식당, 모든 대면 판매에 알맞은 문입니다.
• “판매 추가”(/sells/create)는 전체 인보이스 양식입니다. 인보이스 번호 체계, 통화, 결제 조건, 배송, 사용자 정의 필드, 여러 결제 행 등 모든 필드가 보입니다. B2B 인보이스, 배송 기반 판매, 외상 조건이 있는 모든 거래에 알맞은 문입니다.
• “직접 판매”(/sells/direct/create)는 단순한 인보이스를 위한 “판매 추가”의 축약판입니다.
• “임시저장 추가”(/sells/create?status=draft)와 “견적서 추가”(/sells/create?status=quotation)는 같은 양식을 상태가 미리 지정된 채로 여는 것으로, 실수로 확정하는 일을 막아 줍니다.
• “판매 주문서 추가”(/sells/create?sale_type=sales_order)는 나중에 인보이스로 발행할 고객 주문을 기록합니다. POS 설정에서 판매 주문서가 켜져 있을 때만 나타납니다.

“판매 추가” 화면 입력하기

첫 번째 카드는 “판매 상세”입니다. “위치 선택”은 필수이며 형식적인 항목이 아닙니다. 판매가 어느 재고를 차감할지, 어떤 인보이스 번호 체계를 쓸지, 어떤 결제 계좌를 제시할지, 그리고 전자세금계산서를 신고하는 경우 해당 판매를 신고할지 여부까지 결정합니다. 전자세금계산서는 지점별로 활성화되기 때문입니다. “인보이스 번호 체계”는 인보이스가 받을 번호를 결정합니다. “판매 날짜”는 문서의 회계 일자이며 기본값은 현재 시각입니다. “인보이스 통화”와 “SAR 환율”은 외화 판매가 설정된 경우에만 나타납니다.

“인보이스 번호”는 일부러 손대기 어렵게 되어 있습니다. 인보이스 번호 편집 권한을 가진 사용자에게만, 그리고 문서가 임시저장 상태일 때만 표시되며, “자동 생성하려면 비워 두십시오”라는 도움말이 붙어 있습니다. 올바른 설계입니다. 계산원이 덮어쓸 수 있는 인보이스 번호는 일련번호가 아니며, 끊어진 일련번호는 세무 조사관이 가장 먼저 알아차리는 것입니다.

“고객” 카드에서는 거래처와 “결제 조건”을 입력하며, 결제 조건은 숫자와 “개월” 또는 “일” 단위로 입력합니다. 이 화면에는 별도의 만기일 필드가 없습니다. 만기일은 결제 조건에서 계산되며, 비워 두면 고객 자체의 기본 결제 조건이 적용됩니다. 그래서 인보이스마다가 아니라 고객 기록에 결제 조건을 설정하는 데 5분을 쓸 가치가 있습니다.

상태가 거의 모든 것을 결정합니다

“판매 추가”의 “상태” 필드에는 “최종”, “임시 저장”, “견적서”, “견적 송장”이 있습니다. 이후의 거의 모든 동작이 이 필드에 좌우되므로 양식에서 가장 결정적인 필드입니다.

임시 저장 규칙에는 의도적인 예외가 하나 있으며, 예상치 못하게 당하기 전에 알아 두는 편이 좋습니다. POS 설정에 있는 “임시저장 인보이스의 재고 차감”이라는 비즈니스 설정을 켜면, 순수한 임시 저장 문서도 저장 시점에 재고를 줄이고 판매, 이익, 매출원가, 현금 흐름 보고서에 완료된 현금 판매와 똑같이 집계됩니다. 기본값은 꺼져 있으며, 제품의 도움말도 이를 분명히 밝힙니다. 임시 저장 문서를 실제로 피킹 문서로 쓰는 경우에만 켜고, 그렇게 하면 임시 저장 문서가 재무적으로 실재하게 된다는 점을 이해하십시오.

실무 원칙은 이렇습니다. 물품이 나갔고 고객이 돈을 빚지고 있다면 상태는 “최종”입니다. 그 밖의 경우라면 거래가 아니라 의도를 기록하고 있는 것입니다. 실수가 걱정된다는 이유로 임시 저장을 회피 수단으로 쓰지 마십시오. 끝내 확정되지 않은 임시 저장 문서는 어디에도 나타나지 않는 판매가 됩니다.

• “최종”은 실제 인보이스입니다. 재고를 줄이고, 결제를 받으며, 총계정원장에 기록될 수 있고, 전자세금계산서가 활성화된 곳에서는 세무 당국에 신고됩니다.
• “임시 저장”은 작업 중인 문서입니다. 원장에 기록되지 않으며 결제도 받지 않습니다. 저장 루틴은 상태가 임시 저장, 견적서, 견적 송장인 판매에 대해 결제 기록 작성을 거부합니다. 기본적으로 재고에도 영향을 주지 않습니다.
• “견적서”는 제안입니다. 아무것도 움직이지 않습니다. 재고도, 원장도, 결제도 없습니다.
• “견적 송장”(프로포마)은 인보이스 이전 단계의 문서입니다. 견적서와 마찬가지로 아무것도 움직이지 않습니다.

판매의 세금은 어떻게 계산됩니까

세금은 두 수준에서 판매에 들어올 수 있으며, 그 차이가 중요합니다. 라인 세금은 개별 상품 행에 붙는 세율입니다. 주문 세금은 상품 그리드 아래의 “주문 세금” 필드에서 선택하여 문서 전체에 적용하는 단일 세율입니다. 대부분의 기업은 둘 중 하나만 씁니다. 한 문서에서 둘을 함께 쓰면 다른 시스템에서는 문제가 생기기 쉬운데, Skyline Nexus는 바로 그 특정 오류를 막도록 만들어져 있습니다.

주문 세금은 이미 자체 라인 세금이 붙은 라인을 제외한 과세표준에 부과됩니다. 자체 세율이 문서 세율과 같은 라인은 문서 세금의 과세표준에 아무것도 더하지 않습니다. 쉽게 말해, 시스템은 부가가치세 위에 부가가치세를 부과하지 않으며, 이미 문서 세율로 과세된 라인에 이중으로 과세하지 않습니다. 이는 인보이스 합계 루틴의 계산 규칙이지, 체크하는 것을 기억해야 하는 설정이 아닙니다.

가격이 세금 포함인지 별도인지는 인보이스가 아니라 상품의 속성입니다. 상품 양식에 “판매 가격 세금 유형”이라는 필드가 있고, 선택지는 “포함”과 “제외”입니다. 라인에는 세전 단가와 세금 포함 단가가 모두 저장되므로 인보이스는 다시 계산하지 않고도 어느 쪽이든 표시할 수 있습니다. 판매 양식의 행별 세금 선택기는 비즈니스에서 인라인 세금이 켜져 있을 때만 나타납니다. 꺼져 있으면 세금은 상품과 주문 세금 필드에서 옵니다.

반올림은 인보이스별 결정이 아니라 비즈니스 설정입니다. 기본값은 라인마다 반올림해 합산하는 대신 전체 정밀도로 합산한 뒤 인보이스 끝에서 한 번 반올림하는 방식입니다. 두 방식은 긴 인보이스에서 최소 통화 단위 몇 개만큼 차이가 나는데, 고객에게는 대수롭지 않지만 원장과 맞아야 하는 부가가치세 신고에는 매우 중요합니다.

결제는 인보이스와 별개의 기록입니다

양식 맨 아래의 “결제 추가” 카드는 선택 사항입니다. 각 결제 행에는 “금액”, “결제일”, “결제 방법”, “결제 계좌”와 선택 항목인 “결제 메모”를 입력합니다. “결제 행 추가”를 쓰면 한 인보이스를 여러 결제 수단으로 나눌 수 있어, 고객이 일부는 현금으로, 일부는 카드로 낼 때 유용합니다. 행 아래에는 “총 지불할 금액”, “총 결제 금액”, “거스름돈”, “잔액”이 표시됩니다.

외상 판매라면 “외상 판매 — 전액 미납”을 체크하십시오. 결제 금액이 0이 되고, 결제 행이 숨겨지며, 저장 루틴이 결제 기록 생성을 완전히 건너뜁니다. 인보이스는 발행되고, 매출채권은 남으며, 돈은 나중에 회수합니다. 이것이 외상 판매를 기록하는 올바른 방법이며, 금액이 0인 결제 행을 입력하는 것은 올바른 방법이 아닙니다.

문서의 결제 상태는 입력하는 것이 아니라 계산되는 값입니다. 받은 총액이 인보이스 합계 이상이면 결제 완료, 일부만 받았으면 부분 결제, 아무것도 받지 않았으면 미납입니다. 이 계산은 결제가 추가, 수정, 삭제될 때마다 다시 실행되므로, 이후의 결제는 인보이스를 수정하지 말고 판매 목록의 “결제 추가”(/payments/add_payment/{id})로 회수해야 합니다. 숫자를 맞추려고 인보이스를 수정하는 것은 잘못된 본능이며, 거래 취소 및 정정에 관한 가이드에서 다룹니다.

판매가 재고에 미치는 영향

판매를 “최종”으로 저장하면 각 라인이 해당 사업 지점에서 그 상품 변형의 가용 수량을 줄입니다. 재고 관리 대상이 아닌 상품은 건너뜁니다. 재고 관리가 꺼진 상품에 대해서는 차감 루틴이 아무것도 하지 않으므로, 같은 화면에서 서비스와 인건비를 판매해도 마이너스 재고가 생기지 않습니다.

이어서 사람들이 잘 보지 못하지만 알아야 할 두 번째 단계가 실행됩니다. 판매된 각 수량은 그것이 나온 특정 구매 라인에 배분되고, 그 배분이 저장됩니다. 이 대응 관계가 매출원가를 추정치가 아닌 실제 값으로 만듭니다. 시스템은 어떤 원가의 어떤 구매가 어떤 판매에 공급되었는지 알고 있습니다. 배치와 유효기간 규칙을 적용하는 것도, 초과 판매가 허용되지 않을 때 소프트웨어가 초과 판매를 거부할 수 있는 것도 이 배분 덕분입니다.

이 배분은 판매 시점에 만들어지므로, 그 사이 재고가 움직인 뒤 몇 주 늦게 기록한 판매는 당시에 기록했을 때와 다르게 배분됩니다. 이는 버그가 아니라 산술이며, 판매는 발생한 당일에 기록해야 한다는 가장 강력한 실무적 근거입니다.

총계정원장에 기록되는 것

최종 판매는 내부 이벤트를 발생시키고, 회계 모듈이 이를 수신합니다. 모든 설정이 갖춰져 있으면 이 리스너가 분개를 작성합니다. 분개는 매출채권 통제 계정을 인보이스 총액으로 차변에 기록하고, 순액을 수익으로, 세액을 부가가치세 매출세액으로 대변에 기록합니다. 상품 카테고리에 별도의 수익 계정이 있으면 수익이 카테고리별로 나뉘므로, 상품과 서비스를 함께 파는 기업은 수작업 분석 없이 손익계산서에서 이를 따로 볼 수 있습니다.

세 가지 조건이 모두 충족되어야 기록되며, 원장이 고장 났다고 결론 내리기 전에 세 가지를 모두 확인할 가치가 있습니다. 첫째, 판매가 “최종”이어야 합니다. 임시 저장, 견적서, 견적 송장은 설계상 건너뜁니다. 둘째, /accounting/settings의 회계 설정에서 “매출 거래 자동 전기”가 켜져 있어야 합니다. 셋째, 계정이 매핑되어 있어야 합니다. 매출채권 계정, 수익 계정, 부가가치세 매출세액 계정을 /accounting/settings/mapping에서 설정합니다. 매핑이 빠져 있어도 아무것도 손상되지 않으며, 단지 기록을 거부할 뿐입니다.

월말에 사람들을 당황하게 하는 네 번째 관문이 있습니다. 판매 날짜가 속한 회계 기간이 열려 있어야 합니다. 기간이 마감되었거나 잠겨 있으면, 마감된 달로 조용히 소급 기록되는 대신 기록이 거부됩니다. 이는 올바른 동작이며 기간 마감의 존재 이유 그 자체입니다. 다만 잠긴 달의 날짜로 된 판매가 원장에 도달하려면 기간을 다시 열거나 날짜를 바로잡아야 한다는 뜻입니다.

해당되는 경우의 전자세금계산서

사우디아라비아에서는 판매를 “최종”으로 저장하면 전자세금계산서 모듈이 인보이스를 자동으로 생성하고 신고합니다. 이 기능은 비즈니스 전체가 아니라 사업 지점별로 활성화되므로, 한 지점은 전자세금계산서 체계로 운영하고 다른 지점은 아직 등록하지 않을 수 있습니다. 설정은 /zatca/configuration에 있습니다.

신고는 멱등적입니다. 시스템은 이미 신고한 내역을 기록하며 같은 인보이스를 두 번 신고하지 않습니다. 신고가 실패해도 판매는 저장됩니다. 이는 의도적인 선택입니다. 세무 당국의 엔드포인트에 연결할 수 없다는 이유로 판매를 잃는 것은 몇 분 늦게 신고하는 것보다 훨씬 나쁘기 때문입니다. 실패한 신고는 판매 화면에서 다시 보낼 수 있습니다.

인보이스가 한 번 신고되면 편집이 잠깁니다. 시스템의 메시지는 명확합니다. 인보이스가 이미 신고되어 더 이상 편집할 수 없으며, 정정하려면 대변표나 차변표를 발행해야 한다는 것입니다. 소프트웨어가 까다롭게 구는 것이 아닙니다. 신고된 인보이스는 이제 세무 당국이 보유한 문서이며, 이를 변경하는 유일한 합법적 방법은 또 다른 문서를 발행하는 것입니다.

저장한 뒤

판매는 인보이스 번호, 고객, 합계, 결제 상태, 그리고 해당되는 경우 전자세금계산서 상태와 함께 “모든 판매”에 나타납니다. 행 메뉴에서 조회, 인쇄, 결제 추가, 결제 보기, 반품 시작을 할 수 있습니다. /sells/show/{id}의 상세 화면은 라인, 세금 내역, 결제 이력을 한곳에 보여 주므로, 누군가 특정 인보이스에서 무슨 일이 있었는지 물을 때 열어야 할 화면입니다.

판매 후 고객 잔액이 다시 계산되므로 매출채권이 고객 원장과 매출채권 연령 분석에 즉시 나타납니다. 원장 기록이 활성화되고 설정되어 있다면, 같은 수치가 회계 모듈을 통해 시산표와 재무상태표에도 나타납니다. 둘이 맞지 않는다면 산술 오류보다는 위에서 설명한 세 가지 기록 관문 중 하나가 원인인 경우가 대부분입니다.

간단한 점검표

• 지점이 맞습니까? 지점이 재고, 번호 체계, 결제 계좌, 전자세금계산서를 결정합니다.
• 상태가 “최종”입니까? 그 밖의 상태는 아직 판매가 아닙니다.
• 판매 날짜가 입력하는 날이 아니라 실제로 판매가 일어난 날입니까?
• 고객이 결제하지 않았다면, 금액 0인 결제 행 대신 “외상 판매 — 전액 미납”을 체크했습니까?
• 외상 판매라면 인보이스가 올바르게 연령 분석되도록 결제 조건을 설정했습니까?
• 저장한 뒤가 아니라 저장하기 전에 합계 영역의 세금 수치가 맞는지 확인했습니까?