1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

会計ソフトの作成 8 補助科目

1
Posted at

勘定科目は仕訳に必須で、この作業を進める中で知りましたが、JIS規格が存在し、JISだと4桁、自分の使用し続けてきたソフトでは3桁で構成されていますが、先頭が「1」で始まれば資産科目とかの約束があって、そこから外れる事はしない方が無難です。
一方、補助科目というのは、勘定科目を更に細かく分類したいという事で設定するもので、必須では無いし何か公準の約束事がある訳でも無いようです。
むしろ、どこの会社でも社内で別のシステムがあり、取引先には取引先コードとか、顧客には顧客コードとか、社員には社員番号とかが振られていると思いますが、補助科目コードは、そのコードをそのまま流用できると良いのでは考えています。
例えば、販売管理システム上で取引先A社のコードが[111] となっているなら、勘定科目 売上[511] 補助科目コード[111] 補助科目名「A社」としておくということです。
こうしておくと、補助元帳で残高の推移を確認するとかの場合、補助科目名でA社との取引であることが自明となっている、販売管理システムの作業されていた方が経理業務に来たとしても違和感が生じない、整合性が保持されていることが保証されるならSQL的に突き合わせることも可能となると思います。
また、当座預金を[121]とすると、補助科目は全銀協の銀行番号なんかでもよいかもしれません。
このように考えた場合、補助科目の持つ意味は、勘定科目ごとに異なる、例えば同じ[111]がある時は、取引先のコード、別な勘定科目の中では、顧客のコードということになります。
この状態を構成するために次のテーブルを用意しました。

CREATE TABLE kaikei."ma_補助科目" (                                                           
    id integer NOT NULL,
    created_at timestamp without time zone,
    updated_at timestamp without time zone,
    "勘定科目コード" text NOT NULL,
    "補助科目コード" text NOT NULL,
    "補助科目名" text NOT NULL
);

CREATE SEQUENCE kaikei."ma_補助科目_id_seq"
    AS integer
    START WITH 1
    INCREMENT BY 1
    NO MINVALUE
    NO MAXVALUE
    CACHE 1;

ALTER SEQUENCE kaikei."ma_補助科目_id_seq" OWNED BY kaikei."ma_補助科目".id;
ALTER TABLE ONLY kaikei."ma_補助科目"
  ALTER COLUMN id SET DEFAULT nextval('kaikei."ma_補助科目_id_seq"'::regclass);

ALTER TABLE ONLY kaikei."ma_補助科目"
  ADD CONSTRAINT "ma_補助科目_pkey" PRIMARY KEY (id);

ALTER TABLE ONLY kaikei."ma_補助科目"
  ADD CONSTRAINT "u_ma_補助科目コード" UNIQUE ("勘定科目コード", "補助科目コード");


ALTER TABLE ONLY kaikei."ma_補助科目"
  ADD CONSTRAINT "f_ma_補助科目勘定科目コード"
    FOREIGN KEY ("勘定科目コード")
      REFERENCES kaikei."ma_勘定科目"("勘定科目コード")
        ON UPDATE CASCADE DEFERRABLE;

UNIQUE ("勘定科目コード", "補助科目コード")の部分は、
これをもって、この2つのコードを被参照列としようとしているからです。
本来なら、id列を被参照列とし、trans_仕訳明細内では、このidを記録するようにする方が筋ですが、その場合、テーブルを眺めただけではどのような仕訳が行われているのかが全くつかめないという事になり、いちいちviewを経由して眺めたり、補助科目の打ち間違いとかを直接テーブルのデータを書き換えて訂正するとかが困難です。(勘定科目-補助科目の組み合わせから、そのidを調べてそれに訂正する作業となります。この構成をとったテーブルも作成した事もありますが、これは結構面倒な作業で、間違いの訂正でまた間違えるとかも…)
ただ、採用した方の参照整合性をとる場合、勘定科目+補助科目の組み合わせに対する参照となるので、例えば現金[111]などのような、およそ補助科目が想定されない勘定科目をどうするのかという問題が生じます。これがidを参照していれば起こらない問題です。
しょうがないので、補助科目の無い勘定科目は唯一の補助科目[9999]を持つということで逃げを打つこととしました。[9999]には意味はありません。補助科目体系が現在3桁なので、それと被らないものなら何でも可です。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?