過去の桐井戸端ＢＢＳ　（桐ver.９）
23093 売上管理をしたいのだがシステムの構築のしかたはどのようなものがいいのでしょうか まろ 2003/10/31-08:42
まろです。
売上管理を作りたいのですが、構築の仕方についてご指導ください。
私は、下記のようにしようとおもっています。

●売上入力
　売上.tbl
　売上入力、納品書発行

●売上マスター
　売上マスター
　売上データ蓄積、売上検索

上記のように、入力ファイルと、蓄積ファイルの２つに分けて管理しようとおもっています。

はたしてこの方法がいいのか悪いのか、ご指導ください。
23096 Re:売上管理の構築のしかた 別所義一 2003/10/31-09:20
記事番号23093へのコメント
まろさん

私は着物の製造卸業ですので加工管理とか、複合加工に伴う原価の蓄積計算など
販売業のみの業種にはない厄介な問題があったのですが
いずれにしても販売管理の基幹をなすのは在庫表だと思います。
在庫表を中心にして売り上げ入力表　売り上げ蓄積表（売り上げ台帳）
（得意先台帳）これらを結合表で結んで請求書の発行等につないでいかなければなりません。
きちっと説明しますとかなり長文になってしまいますのでこのあたりにしておきますが
ちなみに私の作りましたシステムは
表　　　　　　　３８
結合表　　　　　　９
フォーム　　　　１５
レポート　　　　１２

一括処理の行数　２３１６

以上になってしまいました。今もう少しシンプルにしょうと、手直しを始めたところです。

ご参考になるかどうかわかりませんが私の経験談を述べます
23104 Re:売上管理の構築のしかた 尾形 2003/10/31-12:46
記事番号23093へのコメント
こんにちは
LAN環境ですか？
それによって全然考え方が違うと思いますよ

>●売上入力
>●売上マスター
入力用ワーク(一時)ファイルと保存用ファイルという事ですか？

23132 Re:売上管理の構築のしかた 佐田　守弘 2003/11/01-11:10
記事番号23093へのコメント
まろさん
>売上管理を作りたいのですが、構築の仕方についてご指導ください。
との事ですが、本気で質問の意味を考えようとすると、システム構築支援をする様な大仕事になってしまいます。

通常、きちんとシステムを構築するには、業務フローを解析して、
現在の業務フローの上で改善する部分がないのかどうか、そして改善した業務フローに対して、
どの部分をどの様にデータ処理するのか、を考える必要があります。

それはさておき、質問は、
>上記のように、入力ファイルと、蓄積ファイルの２つに分けて
>管理しようとおもっています。
の部分かと思うのですが、入力ファイルと蓄積ファイルの２つに分ける必要があるのかどうか、
また、マスタファイルに直接入力し、単に月次ないし年次で別ファイルとした方が良い場合もあます。

どの様な方法も考えられますし、どれでも構わなかったり、
ある方法では不都合になる場合もあります。
どの様な方法が適しているかは、業務フローによって変ります。

>はたしてこの方法がいいのか悪いのか、ご指導ください。
との事ですが、我々としては、「この様な方法もありますよ」というアイデア提示はできますが、
業務フローを見ているわけではないので、どの方法が最適かの判断はできません。

佐田守弘(KS-00119)

23135 Re:ご指導ありがとうございます。 まろ 2003/11/01-11:46
記事番号23132へのコメント
佐田　守弘さん
ご指導ありがとうございます。

私が構築するシステムは、売上管理も含めた販売管理なんです。
最初にもっと説明したほうがよかったのですが、
在庫管理も含めたシステムです。
私の頭の中では、売上入力を--＞納品書発行--＞保存処理(在庫更新)
こういった流れを検討しています。
なぜ入力ファイルと、蓄積ファイルを分けたかは、在庫更新をしないと
いけないからなんです。

システムの構築に当たるについて、NO23049でも質問したように
入力フォームがメイン＆サブフォームがいいのか
定義づけをしたいのです。

皆さんのご意見をお聞きしたからといって、
その判断で責任をテンカするのではありませんが。

ご指導いただいた内容で検証もしたり。

ともかくいろいろなご意見を参考にしたいのです。
よろしくお願いいたします。



23153 Re:ご指導ありがとうございます。 佐田　守弘 2003/11/01-22:59
記事番号23135へのコメント
まろさん
前にも書きましたとおり、業務フローが分らない限り、的確なコメントのしようがないのです。
特に在庫管理に関しては、業種によって考え方が全く違いますから、一般論としての在庫管理はあり得ません。
「それが分らない上でのアドバイスを」との事なので、外れているかも知れませんが、
外れているかもしれませんが、私の頭に浮かぶ範囲でコメントします。
一番問題となる業種ですが、在庫管理が最も面倒な食品製造業を想定します。
食品製造業の様な(流通行でも同じと思いますが)、生鮮品を扱う場合には、
先入れ先出し管理が大切になるので、ロットを含めた在庫管理になります。
テリトリーが全国に及ぶ場合、どこの倉庫に入っているかも含めて管理する事になります。
また特に製造業だと、検待ち在庫を在庫とみなすか、仕掛りとみなすか、そのあたりの扱いもありますね。

これらが売上データをどの様に扱うかに密接に関係します。
なぜかと言うと、受注があったら、その場で売上を立てて、在庫の商品を確保しなければなりません。
いわゆる「ツバを付ける」事が必要ですね。
そうでないと、受注した後で、在庫が切れているという場合も発生します。

>私の頭の中では、売上入力を--＞納品書発行--＞保存処理(在庫更新)
これは普通の処理です。
さて、在庫の引き当てもせずに売上入力だけを行ったら、どうなるかです。
上記のような事を考えると、受注１件毎にその場で売上を立てて、在庫確保をしなければならないのでは。
であるとすれば、売上はオンラインでマスタに書き込み、その都度在庫管理との照合が必要になるかと思います。

業種によっては、入力ファイルに貯めこみ、まとめて伝票処理と在庫更新を行ってから、
蓄積ファイルに移すもありでしょうけど。

>入力フォームがメイン＆サブフォームがいいのか
>定義づけをしたいのです。
どの様なフォームが良いかは、扱うデータ次第です。

どの様な業種でどの様な商売をするか(要するに業務フロー)抜きにして、
フォームの形式を議論しても意味のない事です。
１件の売上で、数品売るのであれば、必然的にメイン&サブフォームになるはずです。
逆に不動産販売など、一度に１件の商品しか扱わないのであれば、
別の形式になるでしょう。

佐田守弘(KS-00119)
23154 業務内容が分らないと的確なコメントはできません 佐田　守弘 2003/11/01-23:01
記事番号23135へのコメント
まろさん
前にも書きましたとおり、業務フローが分らない限り、的確なコメントのしようがないのです。
特に在庫管理に関しては、業種によって考え方が全く違いますから、一般論としての在庫管理はあり得ません。
「それが分らない上でのアドバイスを」との事なので、外れているかも知れませんが、
外れているかもしれませんが、私の頭に浮かぶ範囲でコメントします。
一番問題となる業種ですが、在庫管理が最も面倒な食品製造業を想定します。
食品製造業の様な(流通行でも同じと思いますが)、生鮮品を扱う場合には、
先入れ先出し管理が大切になるので、ロットを含めた在庫管理になります。
テリトリーが全国に及ぶ場合、どこの倉庫に入っているかも含めて管理する事になります。
また特に製造業だと、検待ち在庫を在庫とみなすか、仕掛りとみなすか、
そのあたりの扱いもありますね。

これらが売上データをどの様に扱うかに密接に関係します。
なぜかと言うと、受注があったら、その場で売上を立てて、在庫の商品を確保しなければなりません。
いわゆる「ツバを付ける」事が必要ですね。
そうでないと、受注した後で、在庫が切れているという場合も発生します。

>私の頭の中では、売上入力を--＞納品書発行--＞保存処理(在庫更新)
これは普通の処理です。
さて、在庫の引き当てもせずに売上入力だけを行ったら、どうなるかです。
上記のような事を考えると、受注１件毎にその場で売上を立てて、在庫確保をしなければならないのでは。
であるとすれば、売上はオンラインでマスタに書き込み、その都度在庫管理との照合が必要になるかと思います。

業種によっては、入力ファイルに貯めこみ、まとめて伝票処理と在庫更新を行ってから、
蓄積ファイルに移すもありでしょうけど。

>入力フォームがメイン＆サブフォームがいいのか
>定義づけをしたいのです。
どの様なフォームが良いかは、扱うデータ次第です。

どの様な業種でどの様な商売をするか(要するに業務フロー)抜きにして、
フォームの形式を議論しても意味のない事です。
１件の売上で、数品売るのであれば、必然的にメイン&サブフォームになるはずです。
逆に不動産販売など、一度に１件の商品しか扱わないのであれば、
別の形式になるでしょう。

佐田守弘(KS-00119)
23155 削除依頼 佐田　守弘 2003/11/01-23:02
記事番号23153へのコメント
管理人様
タイトル名を直して再投稿したので、こちらは削除願います。
23156 Re:売上管理の構築のしかた 悲しげ 2003/11/01-23:10
記事番号23093へのコメント
どもっ、まろさん
#23049からのツリーの続きの筈だと思ったのですが、新たにスレッドを立てられたので、
こちらにコメントします。が、中味は#23052の続きでして、私がやっている売掛管理の例をもう少し詳しく書きます。
ちなみに、私のやり方が「標準だ」とか「定石だ」と云う考えは全くありません。
私の好みの要素を含みつつ、（時期的に真似できる例も存在していなかったため）
殆ど個人的に試行錯誤して採用したものであって、もしかすると、物凄くマイナーなやり方かもしれないことを前提しておきます。

売上入力作業にメイン＆サブを使った理由。
当初は、桐ver5のやり方を踏襲して、いわゆる画面伝票＝グループ項目のある伝票フォーム（単独）でやろうとしましたが、
かなり早期に挫折しました。その理由は、
Win桐での「フォーム形式編集」の類のあまりの使いにくさもありましたが、
もうひとつはいわゆるヘッダ部・フッタ部の自由度の無さ（と私は感じた）でした。
その点、メイン＆サブだと、ヘッダ・フッタに相当するメイン部は、それこそ何でも入れることができるので、
これは大変重宝できました。例を挙げると、消費税算出の丸め方法の別をはじめ値引き・額調整・内金等の処理が簡単、
さらに云えば、前回残高や今回買上に伴う残高の表示とかも難なく。
ただし、サブ＝明細部の合計額＋税額の類をメインに反映させるには、若干のテクを要しますが、
それも既に過去ログで幾つか出ています。
あと、入力データを累積台帳に転記するに際しても、特に税額の扱いについては少々検討を要するところがありますが、
さほど難しい問題でもありません。
あ、もちろん、メイン＆サブでやるなら、古典一括では無理で、徹頭徹尾イベントでやる必要があります。
でも、逆に云えば、その結果、ものすごく色んな処理が可能となります。

次、売上累積台帳で、メイン＆サブを避けた理由。
これは何と云っても速度でしょう。保存記録表はえてして長大表になりがちですから、
そのようなデータをメイン＆サブで表示するとなると、遅くて閉口します
（特に初回、２回目以降はキャッシュが利くから速くなるけど）。
ただ、私の場合、台帳はあくまでデータ保存表であるため、参照するだけ＝項目値を変更しないことを
原則としています（だから置換再計算されてしまう恐れがあるところの項目計算式もなるべく設定しないようにしてある）。
したがって、特にメイン＆サブで以って濃密な制御をすべき必要性も感じませんでした。

＊

例外として、売掛管理とは別な処理ですが、保存記録表の方でメイン＆サブを使わざるを得なかったものも
ひとつ挙げておきます。
それは、薬局で調剤した場合の点数計算の場合です。
計算自体は、それこそ色んな処理をさせますから、メイン＆サブを駆使した入力作業表で行います。
で、計算結果の方は、実は階層性のある３種類のものが算出されるので、
３つの表に分解して保存しています。
これら３つの表データを一度に参照するとなると、これはもうメイン＆サブフォームを使うしかありません。
データが多くなればなるほど、表示が超遅くなります（高速化のための涙ぐましい努力は幾つかしていますが、
それらについては省略）。
あ、結合を使おうとは思いませんでした。理由は極めて単純、苦手だから。(^^;)

余談ながら、「３種類の階層性」（表）とは、
１）処方せん１枚についての計算結果やコメント等。
２）「１日３回服用」とか「１日１回服用」とか「塗り薬」とかは、「『剤』が異なる」とみなされて、
各剤毎に点数が計算されたりされなかったりする。各剤毎の計算結果。
３）上記「１剤」中には複数品目とか飲み方等のデータがあるので、これらの全行。
要するに明細行的なデータ。

ps
LANは想定していません、純然たるスタンドアロン。(^^;)

23157 Re:売上管理の構築のしかた 悲しげ 2003/11/01-23:31
記事番号23156へのコメント
在庫管理については、小売店で扱うような普通の商品ならさほど難しいことはありませんよね。
売上の方だと、売上明細データを転記する際に商品（在庫）マスター表を併合で減算。
仕入だと転記時に加算で済みます。
例えば水物で、バラ１本、10本入箱、100本入梱があったような場合、
事情が許すならば、全て最小の品目（コード）で代表して処理するのが一番簡単です。
が、そうも行かないのであれば、これら商品間に親子関係（所謂「バンドル」）
を設定する方法があります。
この考え方も既にご承知かとは思いますが、一応例示しておきますと

コード　品名　　　　　親子の別　　比　親コード
4001　　バラ１本　　　　親　　　　１
4002　　１０本入箱　　　子　　　１０　　4001
4003　　１００本入梱　　子　　１００　　4001

と云う感じで、在庫の方はすべて裏で親コードに換算して処理します。

他の業態での扱い方は全然知りません。

23158 Re:売上管理の構築のしかた 悲しげ 2003/11/01-23:36
記事番号23157へのコメント
在庫データを、独立した「在庫表」とするか否かの問題もあるかもしれません。
私の好みとしては、前述したバンドル関係データも含めて、在庫数もひとつの商品マスター表に突っ込む派です。

戻る