Access自分流 「仕訳処理、法人税申告添付書類」

一昨年は仕訳処理、昨年は法人税申告添付書類作成のプログラムを作っていました。
仕訳処理は当初予定になかったのですが、入金処理をする際、インターネットバンキングの当座入金データを取り込んだところから一連の処理をする運びになりました。

いやー、便利になったもんです。従来は月末の当座入金処理だけでまる一日かかってしまい、請求書の発行が１日遅れていました（二日に投函していました）。それが、インターネットで取り込みできるようになって、月末に入金データの加工（通信費の計算処理）がほとんどできるようになり、一日には確認とデータ変換処理だけで済むようなりました。おかげで一日午後早い時間には締め処理ができるようになり、請求書の一日発送が可能になりました。

インターネットバンキングからのデータはCSVデータなので、簡単にAccessに取り込むことができます。一端取り込んでしまえば、後の加工は思うままです。売掛金入金は摘要欄に得意先のカナ名が入っているので、パターン検索（クエリーでlike ～)としてやれば以前の入力データを参照して、自動入力してやることができます。だいたいこの自動入力で間違っていません。手で振り込み処理をしてるのなら摘要欄の名称が入金の都度、異なることもありますが、ほとんどlikeを使った検索処理で正しく自動入力ができるというのは得意先もインターネットバンキングで入金処理をしているのでしょう。

最初は売掛金入金の取り込みデータだけ選択して処理していましたが、よく考えてみると、その他の取り込みデータを利用して仕訳ができることに気がつきました。当座の動きを仕訳することで９割方の仕訳処理は終わりです。（実際にはその後の１割の処理が結構大変だったのですが。）その他の取り込みデータについても摘要欄をlike文で検索して自動入力してしまえば、自動仕訳できます。

残り仕訳の１割の処理は大変でした。なんせ手でもやったことがない仕訳処理です。
まあ、でもなんとかなるもんで、どうせ販売管理データで作成した帳票から数字を取って起票しているので起票できないわけはないんです。最悪、プレ印刷してそのテキストボックスの数字を取って仕訳明細を作成してしまえば、間違いはありません。

ただ、法人所得税申告用添付書類の作成はまた別です。投資有価証券、受取配当金、前渡金、保証金、リース料、保険料、保険積立金、前払保険料、借入金、長期借入金、支払利息、受取利息、定期預金、定期積金、といった勘定科目は元々販売管理と直接関係がないのでデータそのものの入力がありません。当座から仕訳することになったので、仕訳明細こそデータとして持っていますが、申告書類の添付書類を作成できるだけの詳しいデータ入力はしていません。
法人税申告添付書類の作成には各仕訳データにさらに詳しい内容をヒモヅケしてデータを入力してやらなければなりません。最初はその方法がわかりませんでした。
でもよく考えてみると、例えば保険料なら、どの保険契約に年間どれだけ支払ったかまとめるだけなので、単に仕訳データに別途作成した保険契約一覧テーブルの保険CDをひもづけしてやるだけです。その他の勘定科目も同じことです。
結構、勘定科目としては数がありますが、どの科目についても同じような構造で処理できるので、約半年くらいで作成は終わりました。

斯くして販売管理ソフトの製作はめでたく終わりを迎えることになった次第であります。

Access自分流 「手形処理」

手形処理は簡単なのであまり書くこともないのですが、外注で機能追加の見積もりを取ったら１００万円かかると言われたことがあるので、一応、書いておこうと思います。

手形は受取手形と支払手形があります。受取手形は裏書きして支払にまわすことがあるので、支払伝票入力時に受取手形一覧を参照してデータ入力する必要があります。また、割引手形処理も必要です。

受取手形にしても支払手形にしても手形帳を作成する要領で、入金伝票入力時、支払伝票入力時に受取手形テーブル、支払手形テーブルに手形を登録して行きます。一端、登録してしまえば、裏書処理（支払伝票入力時）、割引処理といった顛末をテーブルに書き込んでいくだけです。あとは月末にその月の満期日集計を行います。
ただ、気をつけないといけないのは決算時は特にそうなのですが、当座残高と整合性を持たせるために、日付については土日祭日を考慮して集計作業を行わなければなりません。
手形満期日フィールドとは別に、実際満期日フィールドを設けて、そのフィールドには土日祭日を考慮した実際の満期日をセットします。土日祭日は銀行休日テーブルを予め作っておいてその日付をチェックします。

実際手形処理はExcelで処理しても良いくらいの簡単な処理ですが、入金処理、支払処理と同時に手形帳に相当する手形管理テーブルが作成でき、後は大した処理をしなくても良いので自作も簡単です。

電算の手形帳があるからといって、通常、手書きの手形帳を無くすことはできません。手形帳を無くす場合は所轄税務署に届けが必要なのであしからず。私の会社では手書き手形帳は作成しています。

Access自分流 「受発注処理、売上仕入処理」

受発注担当者が交代する時、どの程度の引き継ぎ期間が必要か？　私の会社の場合、全く手作業で受発注業務を行うなら半年以上は必要と思います。販売管理システムが完成してしまった現在なら３ケ月あれば引き継ぎ可能です。
引き継ぎを簡単に行うためには担当者が覚えなければならないことを極力少なくしなければなりません。受注した商品の発注先、受注した商品を納品する時の注意、売上する時に同時に請求しなければならない明細、同時に発生する仕入。そういったこまごました作業が得意先ごと納入先ごと仕入先ごと商品ごとに発生します。もし、それを全部覚えてからでないと受発注、売上仕入業務が行えないとしたら、半年でも大変かもしれません。
コンピュータで行う受発注、売上仕入処理はそういった、特殊な業務も自動化したエクスパートシステム的なものでなければなりません。それを自動化することで、人員の交代も簡単になります。熟練労働者でなくても今日、入社してきた人に短期間で業務を任せることができるようになります。ひいては人件費を減らすことができます。
受発注、売上仕入業務の電算化は当にそういった処理です。
しかし、受発注、売上仕入業務に伴う特殊な処理をパッケージソフトで行うは望み薄です。せいぜいできたとしても売上明細と仕入明細の同時発生処理くらいではないかと思います。自作する場合、受発注、売上仕入処理の独自仕様こそ最重要課題です。

受発注処理は売上仕入処理と非常に関連しています。全く同じ処理と言っていいと思います。ここで言ってる処理というのは売掛買掛絡みの処理ではなく、受注、発注、売上伝票発行、仕入明細入力までの作業のことです。受注データはほぼ売上データだし、発注データはほぼ仕入データです。パッケージソフトではこの辺の処理は分割して購入することになるのかもしれませんが、処理として一体のものです。

受注データ入力時に発注書を作成するなんて処理は普通の処理で、行えて当然です。また、ほぼ同じ処理で、同じ商品CDで売上と同時に仕入明細を発生させる処理も当然、行えるようにしなければなりません。その上で私の会社の場合、受発注、売上仕入の同時特殊処理として次のようなものがあります。

１．特定の商品で売上と仕入の商品CDが違う場合がある。また数量が異なる。
２．得意先のある商品について売上時、必ず運賃明細を作成しなければならない。
３．売上１明細について、仕入明細が２明細発生する場合がある。発注先が２ケ所になる。
４．仕入で常時、購入時と返品時の単価が異なる商品がある

こういった処理は全く会社会社の独自仕様なので、パッケージソフトで全て満足できるような機能を持たせるのはまず無理です。自作すればこそです。
あまり処理がこまごましているのでそれぞれの処理の実行方法について書いても仕方ないのはぶきますが、それぞれの処理で商品マスターに必要なデータを持たせなければならない場合もあれば、得意先マスターに持たせる場合もあり、一番条件が厳しい場合では単価マスターに付加データを追加することになります。

少し話しはそれますが、パッケージソフトで単価マスターは通常どのような構造になっているのでしょうか？　２回外注した時は単価は得意先、納入先、商品の依存データにしていました。それは仕様変更で対応してもらいました。現在の販売管理システムでは単価は

　　得意先
　　納入先
　　商品
　　数量
　　売上日

で決まるようにしています。数量依存というのは、納入数量が５個まではいくら、それ以上はいくらといった値決めです。売上日というのは、「いついつからいくら！」ということです。数量依存というのはあまり一般的でないかもしれませんが、売上日依存は必須だと思います。売上するのに得意先ごとに、いちいち「いつからいくら」ということは覚えていられません。一昨年、昨年の価格改定でこの機能がなかったらどうなっていたかと思うと怖くなります。

売上単価の日付依存が必須なように、仕入単価についても日付依存にしておけば営業が見積作成の時に間違いが少ないです。

Access自分流 「支払管理」

実は売掛金の「先方計上」と同じような状況は、買掛金についてもあります。
こちらの買掛金計上金額があっているのに、仕入先の請求金額で支払わなければならないという場合です。実際、売掛金「先方計上」の場合のような件数もありませんし、それほど深刻な問題でもないですが。

よくあるケースとして、仕入先に返品処理してその計上が翌月以降になる場合です。こちらの返品伝票はその月に計上するが、仕入先からの請求書では翌月になってしまう場合です。こちらに責任があって返品させてもらう場合には、道義上仕入先で赤伝処理してもらうまで待つのが筋だと思います。そうなると仕入先の請求金額で支払わなければならないので、当月買掛金額と支払金額が合わなくなります。その場合の繰越管理です。

この場合も「先方計上管理」と同じ方法がとれます。仕入明細に支払計上日フィールドを追加します。返品処理のような場合だと追加行の明細入力は不要です。返品伝票明細の支払計上日をブランクにして翌月繰越にするだけです。

たまに仕入単価が間違っていて、間違った単価で支払う場合もあります（間違いが少額の場合ですが）。仕入先への支払いの場合、支払金額はこちらで決定できるので、仕入先もそれを承知で金額修正が翌々月以降に繰り越すという場合はありません。当月、間違った単価で支払ったとしても翌月には必ず修正がはいります。繰越がでると返って面倒な場合、追加行を作成して支払計上日入力して繰越管理します。

Access自分流 「先方計上管理」

「先方計上」この言い方そのものが自分流です。
最近、「請求書は要らない！」という客先が何件もあります。毎年その数は増えています。商社ではそういったところはないのですが、製造メーカーで自分たちのシステム入力時点で購入金額を確定してしまうところでは、買掛一覧だとか、支払通知書が送られてきます。どうかすると「請求書」そのものが送られてきて、「押印の上返送してくれ！」と言われます。

こちらの請求金額と先方の計上金額が合っている場合は問題ないのですが、値動きがあると金額に差が生じることが多々あります。こちらが間違っている場合は、こちらの売上伝票を修正すれば良いのですが、価格改定の見積書を提出して了解をもらっているにも関わらず、先方計上では旧価格のままになっていたりすると、先方に修正を求めることになります。この先方修正は月をまたぐのが普通です。翌月修正してくれればまだ良いのですが、どうかすると翌々月になったり、修正してもらった数字がまた間違っていたりする場合もあります。こうなると管理が非常に面倒になります。
翌月払いの場合でも、こちらの請求金額通りに先方が支払ってくれないので、差異は売掛残として残ってしまいます。また、修正後支払われた金額は当月売上金額とは異なった金額になります。この繰越管理は非常に面倒なものです。

以前の販売管理システムではExcelで修正依頼をしている売上明細を別途保管したりしていました。面倒だし、繰越明細が多数になってくると非常にわかりずらくなります。また、そういった得意先は年々増えてくるし、販売管理システムで系統的に管理したい項目でした。
調べたことはありませんが、現在販売されているパッケージソフトでそこまで管理できるものはないのではないかと思います。「先方計上管理」は通常の売上、売掛金管理とは全く異なる管理です。自作するなら「先方計上」を管理するのは比較的簡単です。

１．売上明細に先方計上日フィールドを追加する。
２．売上とは関係ない先方計上追加明細を作成する。その追加明細にも先方計上日フィールを用意しておく。
３．先方計上日で小計をとる。

やることはこの３つだけです。
「１」の先方計上日フィールドを追加は説明する必要はないと思います。ちょっと変わっているのは「２」の追加明細の作成です。これは、先方計上明細を売上明細とは別テーブルに作成します。例えばこちらの正しい明細が

りんご　　　２個　単価１１０円　金額２２０円（１）

だったのに、先方計上が

りんご　　　２個　単価１００円　金額２００円（２）

となっていた場合。追加明細テーブルでは常に

りんご　　　２個　単価１００円　金額２００円（３）
りんご　　－２個　単価１００円　金額－２００円（４）

と合計金額が零になるように作成します。この追加明細にも先方計上日フィールを用意しておいて、「３」の集計では（１）（３）（４）の明細について先方計上日フィールドの小計をとります。例えば、こちらでは１月に（１）を売上計上していて先方計上が（２）だった場合、１月の先方計上集計では

金額２２０円（１）　先方計上日ブランク(繰越）
金額２００円（３）　先方計上日１／３１
金額－２００円（４）先方計上日ブランク（繰越）

となります。先方計上金額は２００円、繰越の合計は（１）と（４）の合計２０円になります。実際に入金後の繰越された売掛残は２０円になります。

翌２月に先方で正しく修正されたとします。その場合先方計上通知書では

りんご　　－２個　単価１００円　金額－２００円（５）
りんご　　　２個　単価１１０円　金額２２０円（６）

といった修正明細で計上になっているはずです。２月にこちらの管理では、１月に繰越になった明細について

金額２２０円（１）　先方計上日２／２８
金額－２００円（４）先方計上日２／２８
合計　２０円

と先方計上日に入力します。で、先方計上日で小計をとれば修正された２０円が計上に上がってきます。

一昨年、昨年は価格の値上がりが非常に頻繁に行われました。先方計上を行っている得意先では本当に単価修正を依頼しなければならないケースが多かったです。営業担当者にはその都度、先方購買に修正を依頼してもらいました。修正が翌月確実に行われればまだ良いのですが、修正が翌々月以降になってしまう場合も多々ありました。その間にも修正依頼明細が増えていき、多いところになると、１０明細以上になる時もありました。（金額として１００万円以上です。）
売掛金が確実に入金されるよう管理するのは経理の仕事です。先方計上の管理は非常に面倒ですが、経理の仕事としては非常に重要だと思います。市販のソフトで管理できないのなら自作しなければならない一つの理由付けになると思います。