過去の桐井戸端ＢＢＳ　（桐ver.９）
19055 システムの作り方(得意先コード管理)を教えて下さい。 しぼうかん 2003/02/21-00:48
最近ちょっと質問しすぎかもしれませんが、またお願い致します。

質問内容は得意先管理の方法はＡパターンとＢパターンどちらが良いのでしょうか？
または、どちらも良くないとしたらどんな風に得意先一覧.TBLを作ればいいのでしょうか？と言うことです。

もちろんシステムの組み方は会社の事情によりいろいろ有ることはわかりますが、
このような場合に一般的と思われる方法を知りたいのです。
また現在は納品書＆請求書の発行システムは桐で行い、売上げ台帳は手書きで行うという、
おかしなシステムになっているのですが、将来はこの納品書＆請求書システムで入力したデータから
売上げ台帳も作る様にしたいと思っています。


１．Ａ社営業部に１万円、Ａ社営業部管理課に２万円、Ａ社業務部に３万円
　　の請求書をそれぞれ別に発行します。

２．売上げ金額は部署名無しでＡ社として６万円が入金されます。

３．自社の売上げ台帳も営業部と営業部管理課と業務部を一緒にＡ社の売上げとしてまとめて記帳しています。

上記の１.〜３.の方法は変更出来ません。


　今は請求書発行管理の為に得意先一覧にはあ社営業部とあ社営業部業務課
とあ社業務部を別のレコードとして作り、納品書.WFM入力の時に、
それぞれにコードを割り付け以下の通りにしています。
また部署名ごとに請求書を発行する会社は数社だけです。

そして現在Ａパターンでシステムを組んでいますが、同じ会社で入金も一緒なのに
部署別に別コードをつける事に何か違和感を感じます。そこでＢパターンも考えてみました。


＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Ａパターン

　　　　　　　　得意先一覧.TBL)
　　　　

　　　　　　得意先　　　　｜　コード
　　　　　−−−−−−−−−−−−−−−
　　　　　あ社営業部　　　｜　1001
　　　　　−−−−−−−−−−−−−−−
　　　　　い社　　　　　　｜　1002
　　　　　−−−−−−−−−−−−−−−
　　　　　あ社業務課　　　｜　1003
　　　　　−−−−−−−−−−−−−−−
　　　　　あ社営業部業務課｜　1004
　　　　　−−−−−−−−−−−−−−−
　　　　　う社　　　　　　｜　1005　　　　



　　　　　　　
　　　　　　　　　　納品書.WFM
　

　　得意先[得意先]　締月[締月]　コード[コード]←コードは表示されない
　
請求書番号[請求書番号]←請求書番号は[得意先]＋[締月]がユニークな値の時に自動的に連番で入力される。
　売上金額[売上金額]


※納品書.WFMのデータを[請求書番号]によってグループ化して、[コード]と
　[請求書番号]以外は請求書.RPTで印刷する。


＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

しかし、同じ会社なのに部署別に別コードをつける事に何か違和感を感じ、
Ｂパターンを考えました。


Ｂパターン

　　　　　　　　得意先一覧.TBL)
　　　　

　　　　　　得意先　　｜　コード
　　　　　−−−−−−−−−−−−−−−
　　　　　　　あ社　　｜　　1001
　　　　　−−−−−−−−−−−−−−−
　　　　　　　い社　　｜　　1002
　　　　　−−−−−−−−−−−−−−−
　　　　　　　う社　　｜　　1003





　　　　　　　　　　納品書.WFM
　

　　得意先[得意先][部署]　締月[締月]　コード[コード]←コードは表示し
　　　　　　　　　　　　　　　　　　　　　　　　　　　ない　　
請求書番号[請求書番号]←請求書番号は[得意先]＋[部署]＋[締月]がユニー
　　　　　　　　　　　　クな値の時に自動的に連番で入力される。
　売上金額[売上金額]
　　　　　

※納品書.WFMのデータを[請求書番号]によってグループ化して、[コード]と
　[請求書番号]以外は請求書.RPTで印刷する。

※納品書.TBLに項目として[部署名]を持って、必要な時に納品書.WFMに入力
　する。


19060 Re:システムの作り方(得意先コード管理)を教えて下さい。 悲しげ 2003/02/21-14:44
記事番号19055へのコメント
ども、しぼうかんさん

>１．Ａ社営業部に１万円、Ａ社営業部管理課に２万円、Ａ社業務部に３万円
>　　の請求書をそれぞれ別に発行します。
>
>２．売上げ金額は部署名無しでＡ社として６万円が入金されます。
>
>３．自社の売上げ台帳も営業部と営業部管理課と業務部を一緒にＡ社の売上
>　　げとしてまとめて記帳しています。
>
>上記の１.〜３.の方法は変更出来ません。

似たような、と云うか、上記１〜２のようなパターンは我が零細小売店でも存在しております。
で、このような場合にどうしているのかと云うと、
得意先サマに対して「仕組みを変えろ」と云う訳には行かないので、
私は速攻で３を変更することにしています。
つまり、当店の売上台帳においてもＡ社営業部、Ａ社営業部管理課、Ａ
社業務部にそれぞれ別コードを割り当てて別得意先として扱っています。
入金の入力も、総額として一括して行うのではなく各々の額に分割して
入金入力するか、あるいは一箇所に一括入力した後に振り替え入力をしています。
（こうしないと請求書発行時に困るし）

「Ａ社＊」として束ねる必要があるのは、売上台帳上で「集計」する場合しかないような気がします。
かくして、問題の所在は「３の変更に向けて社内でどう説得するか」に移って来るような気がします。
（やや無責任モード）(^^;)(^^;)
19061 Re:入金の振り分けが大変ですね 宮城 2003/02/21-18:48
記事番号19060へのコメント
しぼうかんさん、悲しげさん、こんばんは。

私が今まで経験してきたところでは、いずれも細かいところに合わせてコードを振っておりました。

そして、私がケース想定するならば、２は次のようにします。

２．売上げ金額は部署名無しでＡ社として５（or７）万円が入金されます。

現実はこちらのほうがはるかに多いはずというか、このときどうするかが
決まっていないと、システムになりません。

悲しげさんの「一箇所に一括入力した後に振り替え」が現実的でしょうね。

19062 Re:システムの作り方(得意先コード管理)を教えて下さい。 悲しげ 2003/02/21-19:31
記事番号19060へのコメント
例によって細かいことですが(^^;)

>２．売上げ金額は部署名無しでＡ社として６万円が入金されます。

ここは入金入力に関してでしょうから、主語は「売上金額は」ではなく「入金額は」でしょうね？
19065 集計方法についてお聞かせください。 しぼうかん 2003/02/21-20:17
記事番号19060へのコメント
悲しげさん、宮城さん、お返事ありがとうございます。

>>ここは入金入力に関してでしょうから、主語は「売上金額は」では
>>なく「入金額は」でしょうね？

はい"売上金額"では無く"入金額は"です。

>「３の変更に向けて社内でどう説得するか」に移って来るような気　
>がします。

う〜ん、私にはそんな力が無いのでちょっと無理そうです。

が、現在は悲しげさんや宮城さんと同じく、請求書の宛名が違うときは、
それぞれ別コードを当てているのですが、その方法がシステムの組み方として"全然間違っている"という訳でも
無いことがわかっただけでもちょっと安心しました。

ただこの場合、将来現在の売上台帳と同じ様に会社別に印刷する時、

>「Ａ社＊」として束ねる必要があるのは、売上台帳上で「集計」する

>悲しげさんの「一箇所に一括入力した後に振り替え」が現実的でしょうね。

この「集計」をするための項目として[得意先コード]が使えなくなるので集計方法がまだわかりません。

まああえてするならば[得意先]に部署名が入る時は部署名の前に空白を１文字入れて、
#文字位置を使って部署名をのぞいた会社名を取り出した[得意先２]の様な項目を作り、
この項目を元に集計するという方法が思いつくのですが、
なんとなく普通の方法で無いような気がします。よくわからないのですが(^_^;)

そこで[得意先コード]でデータを集計またはリンク出来るように[会社名]と[部署名]を
分けたＢパターンを考えたのですが、これもふりがなから得意先名を表引きしようとした時に
部署名を得意先名と同時に表引き候補として表示することが出来ないという欠点が有り、
ちょっとまだ悩みはつきませんね。(?_?)

お二方の使われている、または考えられた集計方法とはどのような方法なのでしょうか？
19067 Re:桐９の表引きは進化しました 今村　誠 2003/02/21-21:05
記事番号19065へのコメント
しぼうかんさんこんにちは
>そこで[得意先コード]でデータを集計またはリンク出来るように[会社名]と[部署
>名]を分けたＢパターンを考えたのですが、これもふりがなから得意先名を表引き
>しようとした時に部署名を得意先名と同時に表引き候補として表示することが出
>来ないという欠点が有り、ちょっとまだ悩みはつきませんね。(?_?)
ここに関しては、桐８まではできませんでしたが、
桐９からは参照項目として２項目、表引き項目として２項目使えるようになりました。
表引きの設定画面をご覧になってみては。

19068 グループ化指定の文字n ONnoji 2003/02/21-21:42
記事番号19055へのコメント

>１．Ａ社営業部に１万円、Ａ社営業部管理課に２万円、Ａ社業務部に３万円
>　　の請求書をそれぞれ別に発行します。
>
>２．売上げ金額は部署名無しでＡ社として６万円が入金されます。
>
>３．自社の売上げ台帳も営業部と営業部管理課と業務部を一緒にＡ社の売上
>　　げとしてまとめて記帳しています。
>
>上記の１.〜３.の方法は変更出来ません。

しぼうかんさん、こんばんは。

次ぎのようなコード（文字列）を考えてみました。

得意先　　　　｜　コード
−−−−−−−−−−−−−−−
あ社(代表)　　｜　100100
−−−−−−−−−−−−−−−
あ社営業部　　｜　100101
−−−−−−−−−−−−−−−
あ社業務課　　｜　100102
−−−−−−−−−−−−−−−
あ社営業部業務課｜　100103


実際に試したわけではないので、恐縮ですが…

フォームならば、
グループ項目のオブジェクトの属性の［グループ項目］タブの［グループ化指定］
や、

レポートならば、グループ設定の［詳細］、

行集計ならば、
［集計グループ］に項目を指定して、［詳細］ボタンを実行すると［グループ化指定］ウィンドウが開きます。

項目「コード」が文字列ならば［指定］の［▽］を選ぶと

・全体
・単語
・区切り文字
・文字n

のどれかひとつが選べます。

「文字n」を選んで、４を指定すれば、"100100"〜"100103"は、
同じグループ("1001")として扱われるような気がします。

実際に試したわけではないので、タラレバの話ですいません。


19069 新大陸の発見ですね。 しぼうかん 2003/02/21-22:25
記事番号19067へのコメント
おおっ!ちょっと驚きました。桐８から桐９へこんなところが進化していたとは。
管理工学でももう少し細かく進化した所を紹介してくれればいいのに。

と、あいさつが遅れました、今村さん有り難うございました。
これは使えそうです。
が、まだ会社の方は桐８のままなので、将来バージョンアップしたときには
この機能を使えば、何とかなる方法を見つけられそうな気がします。(^_^)


19070 Re:集計方法についてお聞かせください。 悲しげ 2003/02/21-22:57
記事番号19065へのコメント
>>「３の変更に向けて社内でどう説得するか」に移って来るような気がします。
>
>う〜ん、私にはそんな力が無いのでちょっと無理そうです。

これは「上記の１.〜３.の方法は変更出来ません。」の、とりわけ売上台帳の
仕様変更にかかっているのですが、でも「そんな力が無いのでちょっと無理」
と云われてしまったら、この話はそもそも無かったことになってしまうような
気が・・・・(?_?)

>>「Ａ社＊」として束ねる必要があるのは、売上台帳上で「集計」する
>
>>悲しげさんの「一箇所に一括入力した後に振り替え」が現実的でしょうね。
>
>この「集計」をするための項目として[得意先コード]が使えなくなるので集計方
>法がまだわかりません。

私が書いた「一箇所に一括入力した後に振り替え」は、入金入力のことであり、
これは手作業での振り分けしか有り得ないので、得意先コードとは全く関係ありません。
（コードと個々の入金額自体の関係に何らの相関性もない筈ゆえ）

集計は色々なやり方があると思います。ちなみに私はその必要を感じていないので
（今のところ、手作業で十分なので）そのような集計もさせたことはないのですが(^^;)

>まああえてするならば[得意先]に部署名が入る時は部署名の前に空白を１文字入
>れて、#文字位置を使って部署名をのぞいた会社名を取り出した[得意先２]の様な
>項目を作り、この項目を元に集計するという方法が思いつくのですが、なんとな
>く普通の方法で無いような気がします。よくわからないのですが(^_^;)

強いてやるとすれば、しぼうかんさんのこのやり方に近くなりそうな気がします。
補足するならば、#文字位置関数だけではなく、これを#部分列関数と組み合わせる必要がありますけどね。
えぇ、もちろん邪道だとは思いますけどね。(^^;)
でも、シロートとしての妙なこだわりで、私はどうしても並びを意識してしまうのです。
コードは結構行き当たりバッタリに割り付けせざるを得ませんから、
コード順に並べると、見た目の並びが美しくなくて・・・・。
あ、でもヨミ（またはフリガナ）項目も内蔵しているなら、並べ替えの第一要素をそれにして、
コード関係（#19068のONnojiさんの例）を第二にすればいいかもしれませんね。

19071 お詫びと訂正 しぼうかん 2003/02/21-23:01
記事番号19055へのコメント
説明もれと説明ミスを発見しました。

[得意先コード]は現在はカウンタ項目になっているので1001,1002,1003という風にはなっていません。

[得意先コード]の様な項目がカウンタ項目でいいのかどうかはわかりませんが。

あと質問のシステムの桐のバージョンは８なのですが、もし桐９の場合の解決法でも
近い将来バージョンアップした時に必ず役に立つので助かります。

19073 うーん、うーん しぼうかん 2003/02/22-03:59
記事番号19068へのコメント
ONojiさん、はじめましてこんばんわ、じゃなくておはようございますになってしまいました。
具体例を挙げてのお返事ありがとうございました。

まず現在の[得意先コード]のデータ型について別ツリーで書きましたが、
間違った風にとれる書き方をしてしまった事をお詫びします。

で、ONojiさんに紹介して頂いた方法は納品書＆請求書システムで得意先コードさえ正しく入力されれば、
部署別に発行した請求書データでも売上台帳で集計することは可能だという気がします。

ただ、[得意先コード]を数値型(注１)で作ったとして実際に頭の中で得意先一覧に
得意先コード正しく入力出来るのか実際の入力時のイメージがなかなかつかめずに考えこんでしまい、
返事が遅れてしまったのですが、下記の様な得意先一覧表を入力する事をイメージをしてみました。

(注１).文字列型だと得意先コードを自動的に付ける事が出来ないと思うので、
人間が表全体を見て付ける事になると思います。
すると、制約条件などであるていど制御出来るとしても、コードの付け間違いが
生じる可能性があるような気がするのでコードは自動的に付けられる様にしたいと思いました。
思うばっかりで自信はないのですが(^^;)



>　　　　　　　　　(Ｃ表)　　　　

>　連番｜　得意先 　｜コード｜得意先1｜得意先2｜　　　　　
>　　１｜え社　 　　｜100100｜え社　 ｜　　　 ｜　
>　　２｜あ社 代表 ｜100200｜あ社　 ｜代表 ｜　　　　　　　　　　　　　　
>　　３｜う社　 　　｜100300｜う社 　｜　　 　｜
>　　↓｜　　↓ 　　｜　↓　｜　↓ 　｜　↓ 　｜　　　　　　　　　　　　
>　８３｜い社　 　　｜108300｜い社 　｜　　 　｜　
>　８４｜あ社 営業部｜100201｜あ社 　｜営業部 ｜　　　　　　　　　　　　　　
　　
　　　　　　　　　　　　　　　　　　　　　　　　　　
> 　 　　　　　(Ｄ表)

>　｜　｜得意先　　 ｜コード｜得意先1｜得意先2｜　　　　
> ｜　｜あ社 営業部｜100201｜あ社　 ｜営業部 ｜
> ｜　｜あ社 代表 ｜100200｜あ社　 ｜代表 　｜　　　　　　　　　　　　　　
>　｜　｜い社　　　 ｜108300｜い社　 ｜　　 　｜
>　｜　｜　　↓　　 ｜　↓　｜　↓　 ｜　↓ 　｜　　　　　　　　　　　　　　
>　｜　｜う社　　 　｜100300｜う社　 ｜　　　 ｜
> ｜　｜え社　　 　｜100100｜え社　 ｜　　　 ｜　　　　　　
　　　　　　　　　　　
　　　　　　
　(Ｃ表)の様に整列しない場合でも(Ｄ表の様に[得意先]で整列する場合でもコードを
自動的に付けるには、社名と部署名の間に空白を入れるなどして[得意先]を[得意先1]と
[得意先2]に分け、[得意先1]の値を&得意先1に取り、[得意先1]に重複する社名データが
無ければ[コード]の&最大値に＋100、重複社名があれば[得意先1]を&得意先1で絞り込み、
[コード]を項目集計して&最大値に＋1を[コード]に入力する。といった様な
イベントを書けば上記の表のように[コード]の自動入力は出来るような気がしますが、
何か違和感を感じています。

なんか頭がもうろうとしてきましたので、訳のわからない説明をしてるかもしれません。
一眠りしてからまた考えてみます。

19075 Re:区切り文字はいいアイデアですね 今村　誠 2003/02/22-08:48
記事番号19073へのコメント
しぼうかんさんこんにちは、ふりがな項目を得意先名と部署の間で
特定の区切り文字で括ったが一番良さそうな気がします。
売上げと入金は別テーブルになると思うので、売上げをイベントなり
一括処理でなり、会計tblに書き出してそのとき必要なのが、
得意先コードだと思います。これは重複値があると計算できないので
カウンタをされたがいいとおもいます。
会計tblへの変換作業tblには計算式でふりがなを表引きさせて
売上金額と請求書番号と印刷日（請求日）等を記入しておきます。
会計tblでは入金は１行でいいので仕訳日記帳の感覚で作れば
いいのではないでしょうか。
得意先ごとの入金と売り上げの明細が知りたいときは、別フォームを作り
グループ指定でふりがなの区切り文字を指定したらいいと思います。
ふりがなの推奨例
とよた豊田自動車:整備課
えぬてNTT:広報課
19077 ご自身で納得できて、使いやすい方法を見つけ出せばよいのではありませんか？ ONnoji 2003/02/22-11:05
記事番号19073へのコメント

>ONojiさん、はじめましてこんばんわ、じゃなくておはようございますになってしまい
>ました。
>具体例を挙げてのお返事ありがとうございました。
>で、ONojiさんに紹介して頂いた方法は納品書＆請求書システムで得意先コードさえ正
>しく入力されれば、部署別に発行した請求書データでも売上台帳で集計することは可
>能だという気がします。
>ただ、[得意先コード]を数値型(注１)で作ったとして実際に頭の中で得意先一覧に得
>意先コード正しく入力出来るのか実際の入力時のイメージがなかなかつかめずに考え
>こんでしまい、返事が遅れてしまったのですが、下記の様な得意先一覧表を入力する
>事をイメージをしてみました。
>(注１).文字列型だと得意先コードを自動的に付ける事が出来ないと思うので、人間が
>表全体を見て付ける事になると思います。
>すると、制約条件などであるていど制御出来るとしても、コードの付け間違いが生じ
>る可能性があるような気が
>するのでコードは自動的に付けられる様にしたいと思いました。思うばっかりで自信
>はないのですが(^^;)

しぼうかんさん、こんにちは。

取引先コードは、一意に相手先が決まれば何でもＯＫだと思います。
「一意に決まる」とは、同じ取引先コードが複数存在しないという意味です。

このように重複が存在しない状態をユニークと呼びますが、
ユニークであれば、コードは何でもいいと思いますよ。

取引先マスター表( .tbl )の重複禁止の索引を作れば、重複を防ぐことが出来ると思います。

自動的に取引先コードを割当てるとのことですが、これは新規に発生した取引先の割当てのことでしょうか？
新規の割当ては、重複しない内容ならば何でもＯＫですので、
たとえば、取引先マスター表( .tbl )を昇順に並べ替えて、
最後の取引先コードを（必要なら数値化して）取得して、それに１加算すればＯＫです（必要ならば文字列に変換）。

老婆心ながら…
ところで、入力している際に未登録の取引先の入力原票に遭遇した場合ですが、
この場合には、この入力原票の入力は後回しにすると紛れがありません。
そして、しかるべき権限をもった人に取引先マスター表( .tbl )に新規取引先を登録してもらい、
その後に、後回しにした入力原票の入力を行うとよいと思います。
このようにせず、入力途中で新規取引先を登録を行うといった欲張った設計をすると、
紛れが生じやすく、ミス等を誘発しやすくなると思います。
「最初に登録ありき、後に入力する」が紛れがなく安全だと思います。

すこしでも参考になれば幸いです。


以下は蛇足です。(^^ゞ

これはあくまでも私( ONnoji )の個人的な感想ですが…

取引先コードは一般にはＩＤといわれるものですが、重複しないデータであれば何でもいいのです。
学生時代の学籍番号や運転免許証やパスポートの番号がこれにあたります。
なおＩＤは、数字の０〜９を用いた番号でなくてもかまいません。
重複しないデータであれば何でもいいということを思い出してください。
例えば自動車のナンバーにはひらがなが部分的に使われています。

ただ、一般的には数字の０〜９を用いたほうが、ＩＤの取り扱いが簡単になります。
ここで注意ですが、数字の０〜９を用いるのだから数値だと早合点してはいけません。
数値というのは重量や高さとか、試験の点数といった、掛けたり割ったり足したり引いたりするための値のことです。
ＩＤの目的は一意にデータを特定するものであって、ＩＤは計算の対象ではありません。
したがってＩＤは文字列であることが自然です。(^^ゞ
もちろん取り扱いのことを考えて、数値にしても問題ありません（重複しないデータであれば何でもＯＫなのですから…）。

＜追伸＞

>まず現在の[得意先コード]のデータ型について別ツリーで書きましたが、
>間違った風にとれる書き方をしてしまった事をお詫びします。

わざわざ御丁寧なお詫びを書かれるには及びませんよ。
私は、しぼうかんさんが数値型のコードを使っているだろうと想像していました。
ただし、カウンタ型とは予想外でしたが…(^^ゞ

なお、解決策はひとつとは限りません。複数の解決策があるかもしれません。
しぼうかんさんが、自身で納得できて、使いやすい方法を見つけ出せばよいのではありませんか？
最初から完璧を期すのは困難です…、しかし試行錯誤は成功への確実な歩みだと信じます。(^^v

19078 悪あがきをしてみます。 しぼうかん 2003/02/22-12:19
記事番号19070へのコメント
おはようございます。悲しげさん。今、目が覚めました(*_*)


>でも「そんな力が無いのでちょっと無理」と云われてしまったら、この話はそもそも無
>かったことになってしまうような気が・・・・(?_?)


１.〜３.に納品書＆請求書システムをなんとか合わせられないかなと思いました。


>私が書いた「一箇所に一括入力した後に振り替え」は、入金入力のことであり、
>これは手作業での振り分けしか有り得ないので、


入金.tblに振り分けしないで入力して、逆に納品書＆請求書システムで部署別入力した
請求金額を自動的に会社別にグループ化(桐の事でなく一般用語としての意味)して
売上台帳に持って行き、入金.tblで入力したデータと一緒に出来ないかなあと思ったのです。

いろいろなご意見を出して頂いたので、もう少しがんばってみます。

19080 入れなくなっていました。 しぼうかん 2003/02/23-12:14
記事番号19075へのコメント

なんか井戸端へ入れなくなっていました。

今村さんにほめて頂くと方向性にちょっと自信が出てきました。(^_^)


>ふりがな項目を得意先名と部署の間で特定の区切り文字で括ったが一番良さ
>そうな気がします。


[ふりがな]で区切りですか、[得意先]で区切るのに比べてどう違うんでしょう。
素人考えだと[得意先]で区切った方が視認性がいいような気がしますがよくわかりません。
いままで得意先一覧の[ふりがな]は納品書入力フォームでの表引き時に表示する
会社名を５０音順に並べ替えて表示させる為だけに使ってました。
が、たぶん何か深い意味があると思うので使うときをイメージして、少し考えてみます。


>得意先コードだと思います。これは重複値があると計算できないので
>カウンタをされたがいいとおもいます。


あっ、やはりそうでしたか、確か過去ログで佐田先生がコードについて、
コードには意味を持たせる必要はなくて、ただユニークな値であることのみが重要です。
という様な事が書いてあったので、なるほど！と思いカウンタ項目にしていました。

そして自分なりに今までのお返事を整理してみるとグループ化の為の３つの
方法を教えて頂いた様に思います。それを別ツリーでまとめてみます。

19081 入れなくなっていました。２ しぼうかん 2003/02/23-12:40
記事番号19077へのコメント
なんか井戸端へ入れなくなっていました。


ONnojiさん、訳のわかりずらい説明を読んで頂き、お返事ありがとうございます。
コードについては、確か過去ログで佐田先生がコードについて、
コードには意味を持たせる必要はなくて、ただユニークな値であることのみが重要です。
という様な事が書いてあったので、なるほど！と思いカウンタ項目にしていました。


>自動的に取引先コードを割当てるとのことですが、これは新規に発生した取引先の割当てのことでしょ
>うか？


はい、そうです。カウンタ項目にしていたので、コードに自動的に＋１を加算していました。


>ところで、入力している際に未登録の取引先の入力原票に遭遇した場合ですが、
>この場合には、この入力原票の入力は後回しにすると紛れがありません。
>そして、しかるべき権限をもった人に取引先マスター表( .tbl )に新規取引先を登録してもらい、
>その後に、後回しにした入力原票の入力を行うとよいと思います。
>このようにせず、入力途中で新規取引先を登録を行うといった欲張った設計をすると、
>紛れが生じやすく、ミス等を誘発しやすくなると思います。
>「最初に登録ありき、後に入力する」が紛れがなく安全だと思います。


なるほどたしかに得意先の登録はシステム管理者が行い、
と入力担当者と別にする方がシステムとして論理的な感じがします。
そして、たぶんこれがシステム管理の正しい方法なのだと思います。
が、うちのようなちっちゃい零細企業では登録管理者と入力担当者を分けるという事は
ちょっと出来そうもありません。(^^;)
ただ、考え方というのは他の部分を考えるときにも手助けとなると思うので
しっかりおぼえておきます。

そして自分なりに今までのお返事を整理してみると
皆さんからグループ化の為の３つの方法を教えて頂いた様に思います。
それを別ツリーでまとめてみます。

19082 ちょっと考えを整理してみました。 しぼうかん 2003/02/23-12:53
記事番号19055へのコメント
今まで教えて頂いた事を元に自分なりに３つの方法に整理してみました。

(１)得意先を[得意先]と[部署]の２つに分け[得意先]＋[部署]の違いによってコードを付けて行く。

この方法が一番いいような気がしますが、桐９でないと納品書入力フォームで"ふりがな"による表引き時に
[得意先]しか表示されないため[部署]が違うときに正しい[得意先コード]を選ぶことができないので、
まず桐９にバージョンアップした時にやる事にしました。

(２)[得意先]には得意先と部署名を入れて、[得意先コード]の前半部分と後半部分に
別の意味を持たせる事により、コードの前半部分で同一の会社かどうかを判断させて、
売上台帳へデータ集計時のグループ化に利用して、
コードの前半と後半を合わせた全部では、納品書フォームの[得意先]を請求書フォームで
グループ化する時に区別、集計する為の項目として使う。

(３)部署名を含む[得意先]または[ふりがな]に区切り文字を入れて、
例えば[得意先]に区切り文字をいれるとすると、[得意先]を[得意先1]と[得意先2(部署)]に分割し、
[得意先1]は同一の会社かどうかを判断させて、
売上台帳へのデータ集計時のグループ化に利用し、[得意先]は納品書フォームのデータの
請求書フォームでのグループ化する時に区別、集計する為の項目として使う。

(２)と(３)は集計に使う項目は違うけれど、やろうとしている事は同じだと思います。
そこで今は[得意先コード]の自動的入力の簡単さを考え、(３)の方法で考えて見ようと思っています。

悲しげさん、宮城さん、今村さん、ONojiさんのアドバイスのおかげでとりあえず
進むべき方向がわかってきました。
どうやってシステムを組むかというような事は桐のマニュアルを見ても書いてあるはずもないことなので、
大変参考になりました。ありがとうございました。
また何か進展があったら報告致します。m(_ _)m

19083 Re:悪あがきをしてみます。 悲しげ 2003/02/23-13:51
記事番号19078へのコメント
どもっ、しぼうかんさん

>１.〜３.に納品書＆請求書システムをなんとか合わせられないかなと思いました。

>入金.tblに振り分けしないで入力して、逆に納品書＆請求書システムで部署別入力した
>請求金額を自動的に会社別にグループ化(桐の事でなく一般用語としての意味)して売上
>台帳に持って行き、入金.tblで入力したデータと一緒に出来ないかなあと思ったので
>す。

上記の言い回しとの関連で、しぼうかんさんの文章からその趣旨を読み取ることが
難しい理由を少し書かせていただきます（失礼ながら）。

……「と思いました」「と思ったのです」と締められておりまして、
これらが過去形であることから、その趣旨を推し量るべきなのかもしれません。
が、見方によっては次のようなふたつの解釈が可能です。
いずれも、これまでの考え方を詳しく再説明されているようなのですが、

１．これまではそのように考えてやってきた。が、この度の指摘を受けて、
　　悔い改める(^^;)ことにした。

２．その基本線を変えるつもりはないと云う前提で、改めてこれまでやってきたことの理由（詳しい再説明）を付記した。

今回の件は、１のようにも思えるのですが、２であることも否定できず、
どっちの方向でコメントを返してよいのか、けっこう悩みます。(^^;)
前置き的な「と思いました」「と思ったのです」の後に、「だからどうする」を続けるべきだと思います。
むしろ後の方こそが肝心かと。

19084 意味のある符丁（符号）＝コードもありますよ ONnoji 2003/02/23-14:07
記事番号19081へのコメント

>なんか井戸端へ入れなくなっていました。
>ONnojiさん、訳のわかりずらい説明を読んで頂き、お返事ありがとうございます。
>コードについては、確か過去ログで佐田先生がコードについて、
>コードには意味を持たせる必要はなくて、ただユニークな値であることのみが重要です。という様な事
>が書いてあったので、なるほど！と思いカウンタ項目にしていました。

しぼうかんさん、こんにちは。

確かに今回のような取引先コードの場合には意味を持たせる必要はありません。
しかし、単にコードといっても色々ありそうですよ。

取引先コードは相手を特定するＩＤの役目をするので、ユニークであれば事足ります。
社員コードも同じですね。

ところで、私達がコードと呼んでいるものは、日本語では"符号"や"符丁"といった物のことです。

"符号"や"符丁"という考えの場合には意味があることが多いです。

"モハ"、"クモハ"といった符丁（符号）は鉄道の車両の種類を示すもののようです。
"Ｄ５１"、"Ｃ６２"といった符丁（符号）は蒸気機関車の動輪の数＋型番のようです。

コンピュータ処理では、ある製品をそれを表すコードで入力することが多くあります。

例えば、90EL PT38 8" S40 というのは溶接継手の規格を表しますが、
これをコンピュータに入力する時には、（以下例のコードは架空のものです）

90EL　…　"01"　形式
PT38　…　"03"　材質
8"　…　"08"　口径
S40　…　"02"　厚さ

のように符号化して、 "01030802" と入力原票のコード欄に転記します。
※この転記作業には記入内容が無効か否かチェックする効果もあります。

そして、入力原票を受け取った電算室のキーパンチャーは "01030802" とキー入力する次第です。

このように、大分類＋中分類＋小分類＋小小分類 といったコード化は普通にありますよ。

ですから、意味のある符丁（符号）＝コードもあるということも覚えておいて下さいね。

>>自動的に取引先コードを割当てるとのことですが、これは新規に発生した取引先の割当てのことでしょ
>>うか？
>はい、そうです。カウンタ項目にしていたので、コードに自動的に＋１を加算していました。

これは私( ONnoji )の個人的な感想ですが…
加算するためにカウンタ型にするというのは…これでもいいですけれど、
アプリを作る場合には、最終値を取得して加算するのが一般的なような気がします。

>>「最初に登録ありき、後に入力する」が紛れがなく安全だと思います。
>なるほどたしかに得意先の登録はシステム管理者が行い、と入力担当者と別にする方がシステムとして
>論理的な感じがします。
>そして、たぶんこれがシステム管理の正しい方法なのだと思います。
>が、うちのようなちっちゃい零細企業では登録管理者と入力担当者を分けるという事はちょっと出来そ
>うもありません。(^^;)
>ただ、考え方というのは他の部分を考えるときにも手助けとなると思うのでしっかりおぼえておきま
>す。

システム管理の正しい方法か否かはさておいて、
私が申し上げたかったことは、入力担当者が同じだとしても、
入力途中で取引先マスター登録を同時に行うような欲張ったデザインは止めて、
多少面倒でも、取引先マスター登録と入力作業を別々にする方が安全性が高いですよということです。

業務アプリでは、安全性や堅牢性を重視して、デザインすることをお勧めいたしますね。

>そして自分なりに今までのお返事を整理してみると皆さんからグループ化の為の３つの方法を教えて頂
>いた様に思います。それを別ツリーでまとめてみます。

是非がんばってください。
長々と書き連ねましたが、それでは失礼いたします。(^.^)/~~~

19086 Re:ちょっと考えを整理してみました。 今村　誠 2003/02/23-15:39
記事番号19082へのコメント
しぼうかんさんこんにちは
>(１)得意先を[得意先]と[部署]の２つに分け[得意先]＋[部署]の違いによっ
>てコードを付けて行く。
>
>この方法が一番いいような気がしますが、桐９でないと納品書入力フォーム
>で"ふりがな"による表引き時に
>[得意先]しか表示されないため[部署]が違うときに正しい[得意先コード]を
>選ぶことができないので、まず
>桐９にバージョンアップした時にやる事にしました。

桐８でしたいときは得意先tblに計算項目を追加します。
得意先に[得意先]と[部署]と[ふりがな]の項目があるとすると
[表引ふりがな]なる項目を新設します。
その計算式に#sstr([ふりがな],1,2)+[得意先]+":"+[部署]を設定します。
　納品書（請求書）の[得意先コード]の表引き条件の指定で
比較項目を[ふりがな]表引き表は得意先.tbl
検索項目に[表引ふりがな]値項目に[得意先コード]で
得意先コードは特定できます。


19089 関係のない言い訳と今の考えです。 しぼうかん 2003/02/23-18:04
記事番号19083へのコメント
悲しげさん、毎度説明不足、というより説明ベタご迷惑お掛けしております。

書き言葉だけで自分の考えを伝えるのは本当に難しいです。
せっかく助言頂いた時にちょっと自分のしようとしている事とちがうなあと思っても、
「その方法は私の希望する目的には合いません」みたいに書いてしまっては、
せっかく書き込んで頂いた方を不愉快な気分にしてしまうと思っています。
そういう恩を仇で返すよう発言はしたくないので、悲しげさんが整理して頂いた２.の方の考えを
遠回しに書いたつもりなのです。

ただ、問題の結論がでるまでは"考えの本線に当たる考え以外のいろいろな意見も頂きたいなあ"と
いつも思っているので、お返事の内容が全然違うと思う時以外はお返事の内容を制限する様な
言葉はなるべく使わないようにしています。

実際少し前のスレッドで悲しげさんに教えて頂いたＴＡＢキーを使ったキーダウンイベントも
ＴＡＢキーを使うという所が、自分の意図する方法と違うので"ちょっと使えないかな"と
思いつつも試してみて、その過程で調べた関連内容を組み合わせて使ってみると、
希望通りにうまく出来たという事もあったりします。

と、いろいろ言い訳を書いてみましたが、悲しげさんがおっしゃっている問いかけの「だからどうする」という所は、
やはり今の時点では、最初に投稿した通り１.〜３.は変更せずに
何とか出来ないかもう少し悪あがきしてみよう。という気持ちです。
悔い改めていなくてすいません。(^^;)


19090 間違った引用深く反省です。 しぼうかん 2003/02/23-19:15
記事番号19084へのコメント
よくマスコミが政治家の発言の全部をいわないで一部の言葉を取り出して批評することがありますが、
うっかりそれと同じ事をやってしまったようです。

ONojiさんがおっしゃっている通り一般的にはコードは意味のある物もたくさんありますね。
というか、意味のあるコードの方が圧倒的に多いかもしれません。
私が使っている[得意先コード]は別のファイルで検索や絞り込みを行う為に、
その得意先を特定する事だけが目的なのでコードの内の一種と入った方が正しい表現みたいです。

佐田先生が過去ログでおっしゃっていた事も一般的なコードについてでは無くて、
質問された方の"コード"が私と同じ目的のコードだったのかもしれません。
よく調べもせずに説明不足のまま引用するのはいけませんね。深く反省します。


>システム管理の正しい方法か否かはさておいて、
>私が申し上げたかったことは、入力担当者が同じだとしても、
>入力途中で取引先マスター登録を同時に行うような欲張ったデザインは止めて、
>多少面倒でも、取引先マスター登録と入力作業を別々にする方が安全性が高いですよということです。


ちょっと意味が分かりにくい所があるのですが、例えば、２件の納品書データがあって、
２件目の納品書データの得意先が登録されていない時に、
２件目の納品書データの入力途中で、取引先マスター登録をして、
その後２件目の納品書データの入力を済ます。この方法が「入力途中で取引先マスター登録を同時に行う」という事なのでしょうか、

それとも、１件目の納品書データを入力してから、２件目の納品書データ入力の前に取引先マスター登録を済ましてから
２件目のデータを入力する。この方法が「入力途中で取引先マスター登録を同時に行う」という事なのでしょうか。
今現在の方法だと後の方のやり方でやっています。


>是非がんばってください。
>長々と書き連ねましたが、それでは失礼いたします。(^.^)/~~~


ありがとうございます。がんばります!!
19092 ＩＤは使い捨てが肝要ということですね。 ONnoji 2003/02/23-20:09
記事番号19090へのコメント
しぼうかんさんは No.19090「間違った引用深く反省です。」で書きました。
>よくマスコミが政治家の発言の全部をいわないで一部の言葉を取り出して批評することがありますが、うっかりそれと同
>じ事をやってしまったようです。
>
>ONojiさんがおっしゃっている通り一般的にはコードは意味のある物もたくさんありますね。
>というか、意味のあるコードの方が圧倒的に多いかもしれません。
>私が使っている[得意先コード]は別のファイルで検索や絞り込みを行う為に、その得意先を特定する事だけが目的なので
>コードの内の一種と入った方が正しい表現みたいです。
>
>佐田先生が過去ログでおっしゃっていた事も一般的なコードについてでは無くて、質問された方の"コード"が私と同じ目
>的のコードだったのかもしれません。
>よく調べもせずに説明不足のまま引用するのはいけませんね。深く反省します。

しぼうかんさん、こんばんは。

ご丁寧なリプライをいただき恐縮です。

前回、意味のある符号＝コードの話を書いたのは、
私の( ONnoji )の老婆心からであり、軽い気持ちで書いただけなんですよ。

そんなに気にされると返って当方が恐縮してしまいました。m(__)m


そうですね…個人的な感想ですが…

どうやら、私達はコンピュータに入力する数字を見ると、
これらの数字をすぐにコードと呼んでしまう傾向があるようです。

まあ、コードとは符号や記号のことなので、これは決して間違えではないのですが…

しかし、よく考えてみると…
実体を特定するコードと、実体の性質を表現するコードと大きく二種類あるようですね。

実体を特定するコードの方は、コードと呼ぶよりＩＤと呼んだ方がスッキリしているようです。
実体の性質を表現するコードの方はそのまま○×△コードと呼べばいいようです。

今回の取引先コードは取引先ＩＤと表現するのがいいようですね。
社員コードは社員ＩＤという具合になりますね。

このようなＩＤの場合には実体の性質を表す符号を混ぜないことが肝要に思います。

それから、蛇足ですが…
実体は現在存在していても、将来消滅する場合があります。
取引先が倒産したり、社員が退職したり…消滅します。

このような場合には、そのＩＤはそのままとして、再利用はしないことが肝心です。
ＩＤは使い捨てが肝要ということですね。
なんらかの理由で取引関係がなくなった場合には、そのデータを消去するのではなく、
［取引停止］といった項目にチェックを入れる等がいいようです。

社員の場合も、［退職］といた項目に項目にチェックを、［退職日］という項目に日付を入れる等。

ＩＤを再利用してしまうと、過去に遡ってデータを調べることが困難になってしまいます。
このことは容易にご想像できますよね。

蛇足の蛇足…

残念ながら、同窓会の名簿などでは、［ご逝去］という項目も必要となってきます。(T_T)

>>多少面倒でも、取引先マスター登録と入力作業を別々にする方が安全性が高いですよということです。
>今現在の方法だと後の方のやり方でやっています。

後者のこととご理解下さい。


それでは、失礼いたします。(^.^)/~~~

19093 別の方法に頭が回りませんでした。 しぼうかん 2003/02/23-22:25
記事番号19086へのコメント

今村さん、いつもお世話になっています。

過去ログで確かあったのですが、
応用方法を考える前に別の解決法を探る方向へいってしまってました。
なるほど#部分列(#SSTR)を使えばよかったですね。
この方法だと桐９じゃなくても出来ますね。
この方法でやってみようと思います。
何とかなりそうです。ありがとうございました。
19096 Re:システムの作り方(得意先コード管理)を教えて下さい。 野良犬 2003/02/24-01:12
記事番号19055へのコメント
数日前に書き込もうとしたのですが、うまく送信できなかったのでもう一度アップします。
いまさらで恐縮なんですが、一つの意見として参考にしてください。

次の２パターンが考えます。
１．入れ子になるケース（たとえばあ社に　Ａ部１課、Ａ部２課、Ｂ部など請求先があり、あ社全体、Ａ部の合計、Ａ部１課の小計、と階層ごとの集計が必要なケース）
２．入れ子にはならないケース

１の方はちょっとややこしいので２の場合でよいと仮定します。
このようなケースがOracleやMS SQL server のようなＲＤＢＭＳであるなら、たいてい次のように設計すると思います。

得意先一覧.tbl
[得意先コード][得意先]
1001　　　　　　あ社

得意先部署一覧.tbl（請求先一覧と考える）
[得意先コード][部署コード][部署]
1001　　　　　　1　　　　　営業部
1001　　　　　　2　　　　　業務課
・・・・・・

と２つの表に分けます。ただし、桐でこのような設計にするといろいろと面倒なことが起こります。
そこで、これらを合わせて１つの表にもどします。

得意先一覧.tbl
[得意先コード][得意先][請求先コード][請求先]
1　　　　　　　あ社　　　1001　　　営業部
2　　　　　　　い社　　　1002　　　
1　　　　　　　あ社　　　1003　　　業務課
1　　　　　　　あ社　　　1004　　　営業部業務課
3　　　　　　　う社　　　1005

さて、こうするとＡパターンとかなり互換性を維持したまま、かなりすっきりしました。
（入れ子にする必要が無いなら）
ここで、[請求先名称]という計算項目を作り[得意先]+[請求先]とすれば、Ａパターンの[得意先]になりますね。
　で、この形式のデメリットは[得意先コード]と[得意先]の整合性を強制する仕組みがないことでが、
運用面や入力画面の工夫である程度回避可能です。
　
つまり、得意先一覧を頻繁に更新しないのであれば、上記の設計はよい選択枝になりえます。

では。

19105 質問があるのですが。 しぼうかん 2003/02/25-20:55
記事番号19096へのコメント
野良犬さん、はじめましてこんにちは（すごいハンドル名ですね。）


新しい考え方はいつでも大変参考になります。


１つのレコードに２つのコード(※１)を使う方式はボーッと考えては見たのですが，
どうもその形が想像出来ませんでした。

※１私の言うコードとはある項目をユニークな値で特定することのみを目的とする物で、
例えば[得意先コード]が決まれば必ず[得意先]が決まるという事だけを目的としたオブジェクトです。

なるほどこういう使い方が正しい使い方なのかと思うような
いかにも"データベース"っぽい形です。

今迄の私の入力の方法は例えば[得意先コード]を入力して[得意先]を表引きするという形ではなくて、
表テーブルの表引き条件で[ふりがなの頭の２文字]という項目にふりがな２文字を
入力して得意先一覧の[ふりがなの頭の２文字]と言う項目と照合して[得意先]を値項目として表引きしてきて入力し、
その時に同時にイベントで得意先一覧の[得意先コード]を変数を介して
納品書テーブルの[得意先コード]へ項目代入するという方法をとっています。

＞で、この形式のデメリットは[得意先コード]と[得意先]の整合性を強制する仕組みがないことでが、
運用面や入力画面の工夫である程度回避可能です。


運用面でいま私が想像出来る方法というのはコードは全て計算式で自動的に割り振られる方式がミスが少ないと思うので、
[請求書コード]はのデータ型はカウンタ型で作り、[得意先コード]は数値型として、
例えば、得意先登録時に[得意先]を入力するとその値をソース値更新イベントなどで多重化した得意先一覧で[得意先]を検索して、
同じ値があればそのレコードの[得意先コード]を変数にり、入力中の[得意先コード]へ項目値代入を行い、
同じ値がなければ[得意先コード]を項目集計して＆最大値に＋１を足した数値を入力中の[得意先コード]に項目値代入する。
そして入力前イベントのソース値取得コマンドで[得意先コード]が未定義で無いときは[得意先コード]は変更しない様にしておく。
という方法がおもいつくのですが、
このイベントを使った方法は野良犬さんが想像した[得意先コード]の入力方法と比べて問題有りでしょうか。まずまずＯＫでしょうか？


入力画面で思いついたのは得意先一覧の入力画面を下記の"あ図"の様なメインサブフォームを作る事は可能でしょうか。
（サブフォームはとりあえず２行表示にしてあるけれど実際の[請求先]データは何件でも
入力出来る様にしておき、[得意先コード]でリンクさせる。)

このフォームが可能なら[得意先コード]は得意先一覧のメインフォームでデータ型をカウンタ型に出来て、
[請求先コード]もサブフォームでカウンタ型に設定出来る様なのでどちらもイベントを使わずに
自動的に入力可能なので自然な気がするのですが・・・

このフォームは野良犬さんが紹介して下さった"OracleやMS SQL server"の様な得意先一覧.tblと
得意先部署一覧.tblを別々に開いて入力するのは入力が複雑になるので同一画面で同時に得意先一覧.tblに有る
[得意先]と[得意先コード]と得意先部署一覧.tblにある[得意先コード]と[請求先コード]を入力出来るように考えたのでが、
桐の仕様上この様なフォームは出来ないのでしょうか？1

あるいは結合表なら可能でしょうか？2

もちろんわかる質問だけでかまわないのですし出来るかどうかだけでもいいですし、
できそうかどうかだけでもけっこうです、教えて頂けないでしょうか。

あ図

ここ迄をメインフォーム←｜→ここからはサブフォーム　　　
　　　　　　　　　　　　｜　　　　　　　　　　　　　　　リンク項目　
　　　　　　　　　　　　｜　　　　　　　　　　　　　　　　↓
[得意先]｜[得意先コード]｜[請求先]｜[請求先コード]…｜[得意先コード]
　あ社　｜　　　１　　　｜営業部　｜　　１　　　　　｜　　　１
　　　　｜　　　　　　　｜業務部　｜　　２　　　　　｜　　　１
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
　い社　｜　　　２　　　｜　　　　｜　　１　　　　　｜　　　２
　　　　｜　　　　　　　｜　　　　｜　　　　　　　　｜
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
　う社　｜　　　３　　　｜　　　　｜　　１　　　　　｜　　　３
　　　　｜　　　　　　　｜　　　　｜　　　　　　　　｜
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
　　　　｜　　　　　　　｜　　　　｜　　　　　　　　｜

19107 古い蛍光灯でした 悲しげ 2003/02/26-00:03
記事番号19055へのコメント
すいません、やっと事情がのみ込めました。(^^;)

私は「請求書」と云えば、特定の締め日に発行する
-------------------------------------------------------------
前月御請求額　御入金額　繰越額　今月お買上げ額　今月御請求額
-------------------------------------------------------------
のような形を想定していました。※
だから、請求書上の得意先コードと入金入力時の得意先コードが異なることは考え難い。
なぜなら、完全回収であれば問題はないのだが、
一部の部署で未収が発生した場合にはその額を（他ならぬ当該部署あてに）次回の請求に反映させなければならないので、
請求／入金系の得意先コードは同一でなければならない、との頭があったからです。
（台帳自体は、請求／入金用のいわば「請求先コード」とは別に
「台帳用の得意先コード」を併用させることが有りうるにせよ）

しぼうかんさんが仰る「請求書」と云うのは、上記のようなものではなく、
要するに納品書と同義の、例えば納品書と請求書が複写になっているような
納品・請求書、云ってみれば単なる（あるいは随時の）「伝票」なのですね。
そのように想定して、ようやく#19055の

>１．Ａ社営業部に１万円、Ａ社営業部管理課に２万円、Ａ社業務部に３万円
>　　の請求書をそれぞれ別に発行します。
>２．売上げ金額は部署名無しでＡ社として６万円が入金されます。
>３．自社の売上げ台帳も営業部と営業部管理課と業務部を一緒にＡ社の売上
>　　げとしてまとめて記帳しています。

が矛盾なく理解できました。(^^;)
と云う訳で、私のコメントはそもそもの前提が異なっておりまして(^^;)
これじゃ話が噛み合わない訳で、どうも失礼いたしました。<(_ _)>

──とこれだけではナンですので、もうひとこと。(^^;)

上記※のような形の請求書は発行しないのですか？
ちなみに、参考になるどころか、混乱にますます拍車をかけるかもしれませんが(^^;)、
当店のやり方を素描しておきます。
まず売上伝票（納品＝請求伝票にもなりうる）入力と入金伝票入力は、入力用の作業表で行っています。
入力が完了したら、売掛台帳にデータを転記・保存します（ふたつの入力作業表は転記後に中味を空にします）。
請求書の作成は、この売掛台帳から、任意の期間・任意の得意先のデータを絞り込んで行わせています。
請求額の算出に際しては、得意先マスター表から前回請求額などのデータを取得させますし、
請求書発行後には得意先マスター表にて今回／前回の請求額などは振り替えておきます。
この方式は、私の昔のハンドルネームが『オラ・フデキ』だったことに密接に関係しているのですが、
それはさておき(^^;)、このような場合、売上入力−入金入力−保存台帳−得意先マスターを通して、
得意先コード類の一貫性は必要になってくると思います。

19115 下位階層を有する得意先コード 悲しげ 2003/02/26-14:43
記事番号19055へのコメント
下位階層を有する得意先で、請求時と入金時の階層（部署）が異なるような場合について、
私んとこの例を挙げてみます。
これは、納品時に納品・請求伝票を渡すだけのところと、月締めで集計請求書を発行するところとで扱いを異にしています。
この区別は、当初から熟慮して設計したと云うことでもなく、
色々試行して来た結果において、この方法がベターかなと行き着いたと云うことです。
運用如何では今後も変更することはあり得るとの前提で、ま、単なるひとつの例としてお読み下さい。

Ａ）納品時に納品・請求伝票を渡すだけの得意先
　（月締めで集計請求書を発行する必要がない）
これはけっこう融通が利くと云うか、アバウト可能な場合が多いのですが、
しいて挙げればふたつのパターンがありました。

Ａ−１）得意先コードをひとつで代表する
普通はこれで十分です。違いは、請求書の宛名くらいでしょうか？
宛名は手書き追記でもいいし、項目として[部署名]を増設しておき
　　#表引き([得code],=,"得意先.tbl",[得code],[得意先名],"得coad順",1)
　　+#cond([部署名],"《"+[部署名]+"》")
ってな方法もありうるかと思います。
当店では、明細行に設けている[備考]欄の１行目に部署名を記述しておくことで対処することが多いです。
入金の入力も同様に[備考]欄に付記しています。

Ａ−２）得意先コードを部署毎に分ける
例えば対役所の場合とかは、部署が沢山あり、部署毎に頻繁に売上が立ち、
且つ入金時期も１週間で入ったり２ケ月かかったりとまちまちであったり、
ときには払込みを忘れ去られていたりすることもあったり・・・等、１本の得意先だけで対応していると、
どの部署の売上／入金／残高なのかがワケワカメになって来ること必定です。
このような場合は、部署毎に適度に得意先（コード）を分割しています。
売上／入金は各部署毎のコードで対応させます。
たまに違ったりすることが必ずありますが、
そのような時は後で正しいコードに振替え入力します。

Ｂ）月締めで集計請求書を発行する場合
こちらの方は、売上／入金／請求を貫いて、得意先コードは（部署毎に）ひとつでなければなりません。
そうじゃないと、残高や月次繰越額が無茶苦茶になってしまいますから。
得意先コードの分割を規定するのは、当店の場合は請求書です。
つまり相手方が「某」部署毎に月締め請求書を出して欲しいと云う、
その「某」部署を分割の単位としています。
この場合に、入金が全部署一括であったとしても、
当店ではなるべく部署毎の額に置き換えて入金入力させています（必要に応じて、
ひとつの部署に一括入力後、振替え入力も有り）。
あと、入金が部署毎で請求は１本ってとこは未体験です。(^^;)

補足するに、いずれの場合も得意先コードは、売上／入金／請求書発行時のみならず、
台帳にも一貫させています。なぜなら、それが最も無難だと思われますから。


ＰＳ
上記は「単なるひとつの例」を挙げただけであって、
このとおりにすべきだと云うことでは決してありませんし、
そうしないと私が不愉快に思うと云うようもことも全くありませんので、
この点、念を押しときます。(^^;)

19119 大長編ですが読んでいただけますか？ しぼうかん 2003/02/26-19:34
記事番号19107へのコメント
-------------------------------------------------------------
前月御請求額　御入金額　繰越額　今月お買上げ額　今月御請求額
-------------------------------------------------------------

イメージとしては上記項目の内の前月御請求額，御入金額，繰越額，今月御請求
額（前月繰越分含む）を除く、今月御買上げ額のみを請求額として印刷する方式です。
つまり前月売上げが１万で未入金のまま今月売上げが２万あった場合、
今月の請求書に印刷される請求額は３万ではなくて２万なのです。
誤解を恐れずにいうならば、請求の入金と台帳処理は実際は会社名のみで管理しているにもかかわらず、
請求書の発行先名だけは別個の会社として印刷しているわけです。
あと複写納品書は納品書控えと請求明細書と納品書と受領書の４枚複写から成り、
納品時には納品書と受領書を送付し、納品書控えと請求明細書は持っていて、
複写請求書は請求書控えと請求書の２枚複写で先方送付時には複写納品書についていた
請求明細書と請求書をセットして封筒で送るという形です。

そして桐のシステムには関係がことなのですがシステム作りの背景として私の会社の多分、
特殊な業務分理について少し説明させて頂くと、まず私の会社では経理と事務（業務）が分離しいて、
業務は納品書と請求書の発行と売掛台帳と買掛台帳の記帳と売上実績表と買掛仕入一覧表を行い
それ以外は経理がやっています。
ですから売上の入金を速やかに納品書＆請求書システムに入力する事が出来ず、
月締め後にやっと遅れて、振替伝票（入金伝票）を借りて台帳記帳する形なのです。

実際の業務処理の流れで説明すると仮に２月20日締め売上に計上されるあ社営業部に
１万とあ社営業部業務課へ２万の納品がそれぞれ１回あるとすると

１）納品日に合わせて納品書を各１通発行し、２月20日前後にあ社営業部へ１万と
あ社営業部業務課へ２万の請求書をそれぞれ１通発行します。

２）他の末日締めの会社への請求書の発行が完了するのを待って３月初めに部署別の
仕分けをせずにあ社売上げとして３万を売掛台帳に手書き記帳します。

３）この時同時に経理より２月分の振替伝票（入金伝票）を借りて入金も売掛台帳に手書きで記帳します。
この振替伝票は"あ社営業部用の１万"と"あ社営業部業務課用の２万"の２枚あるのでは無くて
"あ社用の３万"と書かれた１枚だけです。

４）さらに同時に売上実績表をエクセルで作成していますが、この時も会社名は
"あ社営業部"と"あ社営業部業務課"では無くて"あ社"１件として売上３万を計上します。


悲しげさんのシステムの流れの納品書入力から売掛台帳への自動転記、
または入金伝票入力から売掛台帳への自動転記を行い、その売掛台帳から会社＆部署名と
締日で絞り込んで請求書発行というのは多分標準的な方法だと思うのですが、
上記の通り経理と業務が分離している事により入金伝票からの逐次売掛台帳への自動転記が出来ず、
締後、一括入力方式しかとれません。
入金伝票が発行され次第経理より伝票を借りて逐次入力すれば、いいのですが、
これには人事的に非常に難しい所があり当分無理だと思います。

そこで入金処理の部分の逐次入力を締め後の一括入力で行う事でも使えるシステムを
"無いよりまし"的な発想で何とか作りたいと思っています。

なにしろ２年前までは納品書，請求書とも手書きで発行していて，昨年末までは
納品書，請求書に別々に同じデータを入力して印刷していたぐらい遅れていて、
最近やっと納品書と請求書を連動させる事が出来るようになったばかりなのです。
19120 大長編ですが２ しぼうかん 2003/02/26-19:36
記事番号19107へのコメント

長々と説明しましたがまとめとして、
１）までしか桐でのシステム化が出来ていないので２），３），４）を桐でシステム化するために
入力された納品書データを部署付きの請求先社名での集計と売掛台帳用の部署名無しの社名での集計を
可能にする為の得意先一覧の作り方が知りたいのです。


候補１．として今現在は皆さんに教えて頂いた事を参考にして、[得意先]と[部署]を別項目とし、
[得意先]と[部署]を合わせたデータに一意に対応する[得意先コード]（カウンタ項目）を１項目を使った
得意先一覧テーブルで得意先を管理する。
そして納品書入力フォームで入力した納品書データを集計して、請求書を印刷する時は
得意先一覧から表引き(項目計算式で)した[得意先コード]で集計して、
売掛台帳へはやはり得意先一覧から表引き(項目計算式)で表引きした[得意先]で
集計して自動転記をする方法を予定しています。
もし野良犬さんに教えて頂いた方法が何とかならなかったらこの方法でやってみようと思っています。


ただこのばあい得意先一覧の[得意先]はユニークな値にならないのでこの[得意先]に
対応する[コード]をカウンタ項目に出来ません。

野良犬さんが最初の方で紹介して下さった。得意先一覧テーブルを得意先一覧と
得意先部署一覧の様に２つの表で管理すれば[得意先]と[部署]それぞれに[得意先コード]と
[部署コード]をカウンタ項目で設定出来るのですが、例えば得意先一覧を開いて[得意先]を入力後、
得意先部署一覧を開いて[得意先]と[部署]を入力するといった風にかなり入力が煩雑に成ってしまいます。

そこで野良犬さんが次に紹介して下さった１つの表に２つのコードを使う方法は
[部署コード］はカウンタ項目として自動化出来るのですが、[得意先コード]は
自動入力する方法がまだ思いつきません。

そこで野良犬さんへのツリーで自分なりに考えた事が可能かどうかを質問したのですが、
結合表に関しては無理みたいです。

なぜなら実表を更新する結合表では行挿入が出来ないと書いてありましたが、
得意先一覧フォームでは新規会社登録の為の行挿入が必須ですので。

また悲しげさんの方法を見ていて気がついたのですが候補１．で入力した得意先一覧フォームで
新規得意先を登録後、納品書入力フォームに移る時のコマンドボタンで
得意先一覧.tblと得意先部署一覧.tblの２つの表へ併合処理または書き出しをする事で
得意先一覧.tblの[得意先コード]と得意先部署一覧.tblの[部署コード]をカウンタ項目として
設定して２つのコードを管理する方法がもしかしたらうまく行くような気もしてきました。
明日、明後日中までには試してみたいと思っています。


>ちなみに、参考になるどころか、混乱にますます拍車をかけるかも
しれませんが(^^;)、

どんなご意見（例えば説明が分かりにくいと一言であっても)も必ず参考になりますし、
ありがたい事です。もし違うなあと思うご意見であってもそれは自分で取捨選択すれば良いことだと思います。
しかしお返事がもらえなければどうしようもないですから。


この掲示板のギネスブックに登録されるぐらいのこんな長い説明を読んで頂きありがとうございました。（^_^;)

19123 Re:大長編 悲しげ 2003/02/26-21:25
記事番号19120へのコメント
どもっ、しぼうかんさん、「大長編」よみましたよん。

>入力された納品書データを部署付きの請求先社名での集計と
>売掛台帳用の部署名無しの社名での集計を可能にする為の
>得意先一覧の作り方が知りたいのです。

で、私ならこうするかもと云う、混乱の元（笑）をもうひとつ。

得意先マスターの構成は次のようにしてみる。（項目名等は仮称）

請code　請求先名　　得意先名　得意先名２
1201　　あ社総務課　　あ社　　　あ社
1202　　い社　　　　　　　　　　い社
1203　　あ社業務課　　あ社　　　あ社
1204　　あ社　　　　　　　　　　あ社
1205　　う社　　　　　　　　　　う社
1206　　あ社お支店　　あ社　　　あ社

項目[得意先名２]には次のような項目計算式が設定されているとか。
　　#条件選択([得意先名],[得意先名],1,[請求先名])

で、売上入力用の表には、項目として[請code][請求先名]の他に、
[得意先名]も設けておくとします。
[請求先名]の項目計算式は
　　#表引き([請code],=,"得意先.tbl",[請code],[請求先名],"請code順",1)
[得意先名]の項目計算式は
　　#表引き([請code],=,"得意先.tbl",[請code],[得意先名２],"請code順",1)

※これら項目は台帳表にも存在する必要があります。
　本当は入金入力表にもあった方がいいんですけどね。(^^;)

こうしておけば、このデータを台帳に転記した（読込みさせた）
アカツキには、台帳に存在する[得意先名]項目にも親階層の値が入っているからして、
後はこの値を悠々利用できるような気がします。
（但し、ワタシ的には変則的の感は免れませんが）

得意先名（親階層）に敢えてcodeを割り付けず、日本語そのままってとこが
いかにもワタシ的＝ド・シロート(^^;)って感じですが、
親階層codeを経由させると少し煩雑化してしまうし、この場合は
その必要性も薄そうなので、このように単純化させてみました。

なお、新規得意先登録における各項目値は、（上記の計算項目以外は）全て手動入力を想定しています。
無理に自動化しない方が簡単且つ確実な気がします。
──と考えれば、難しくないでしょ？
あ、私はcodeとしてカウンタ項目を利用する方法は試したことがないのでよく判りませんが、
カウンタ型でもいいでしょうし、
重複禁止を設定した他の型でもよいのだから、特にこだわる必要もないように思います。
19132 ありがとうございました。 しぼうかん 2003/02/28-20:46
記事番号19055へのコメント
悲しげさん、宮城さん、今村さん、ONojiさん、野良犬さん、ありがとうございました。
多くの方から助言を頂き、最初の質問内容以外の事もいろいろ勉強になりました。

皆さんに教えて頂いた知恵を使って、とりあえず下の方の"現実のシステム"でやってみようと思います。

出来れば"願望システム"の様な方法が"データベースっぽくてかっこいい"のですがちょっと無理でした。
が、私の説明不足で助言を頂いた方に無駄な時間を使わせてしまったのでとりあえず、
自分がやりたかった事を最後にもう一度説明してみます。

"願望システム"のデータベースっぽい所は"うう社"が"おお社"に社名変更した場合
このフォームのメインフォーム部の[得意先]を１ヶ所変更するだけで
サブフォームの"本店"と"支店"の[得意先]も同時に変更される。
"現実のシステム"の方法であれば得意先.TBLの[得意先]が変更になった時は
[得意先]が同じで[部署]の違うレコードを全て探し出して個別に[得意先]を変更しなければ成らない。


"願望システム"

得意先コードより左側はメインフォーム
部署より右側はサブフォームでグループ値リストは[得意先コード]
サブフォームの[得意先コード]は長整数項目で[部署名コード]はカウンタ項目
メインフォームの[得意先コード]はカウンタ項目


＞　　　　｜得意先｜　　｜部署名｜
＞　得意先｜コード｜部署｜コード｜住　所
＞　−−−−−−−−−−−−−−−−−−−−−−−−−−−−
＞　　　　｜　　　｜営業｜１　　｜東京都
＞　いい社｜１　　｜業務｜２　　｜北海道
＞　　　　｜　　　｜経理｜３　　｜鹿児島
＞　−−−−−−−−−−−−−−−−−−−−−−−−−−−−
＞　　　　｜　　　｜　　｜４　　｜東京都
＞　ああ社｜２　　｜　　｜　　　｜
＞　　　　｜　　　｜　　｜　　　｜
＞　−−−−−−−−−−−−−−−−−−−−−−−−−−−−
＞　　　　｜　　　｜本店｜５　　｜東京都
＞　うう社｜３　　｜支店｜６　　｜北海道
＞　　　　｜　　　｜　　｜　　　｜
＞　−−−−−−−−−−−−−−−−−−−−−−−−−−−−




"現実のシステム"


得意先.TBLは[得意先],[部署],[得意先部署コード],他…の項目を作り
[得意先部署コード]はカウンタ型，入力項目は[得意先],[部署],他…

納品書.TBLは[ふりがな2],[得意先],[部署],[得意先部署コード],[締年],[締月],[請求書番号],他…の項目を作ります。

納品書.WFM入力時にはまず[ふりがな２]を入力して、次に"表引き条件"を利用して[得意先部署コード]を入力する。

"表引き条件"には"[ふりがな２],"得意先.TBL","よみ（会社名）順",[表引き用項目],[得意先部署コード]"と書いて置きます。

そして[得意先部署コード]のソース値更新イベントで[得意先]と[部署]を表引き入力する。

請求書は[得意先部署コード],[締年],[締月]などから自動的に入力される[請求書番号]によって集計する。

売掛台帳へ転記の為の集計時には[得意先]で集計する。

※１．[ふりがな２]は[得意先]の"ふりがな"のうち最初の２文字を入力する
項目
※２．[表引き用項目]は得意先.TBLに作った、#部分列([ふりがな],1,2)＋
[得意先部署コード]＋[得意先]＋[部署]の項目計算式を書いた項目
19133 Re:ありがとうございました。 悲しげ 2003/02/28-22:46
記事番号19132へのコメント
どもっ、１点だけ。

>"願望システム"のデータベースっぽい所は"うう社"が"おお社"に社名変更し
>た場合このフォームのメインフォーム部の[得意先]を１ヶ所変更するだけで
>サブフォームの"本店"と"支店"の[得意先]も同時に変更される。
>"現実のシステム"の方法であれば得意先.TBLの[得意先]が変更になった時は
>[得意先]が同じで[部署]の違うレコードを全て探し出して個別に[得意先]を
>変更しなければ成らない。

ここで云う"願望システム"の方がいいかどうかは一概には云えないこともままあります。
特に近年の場合、単なる社名変更はあまりなく、
合併（あるいは吸収）とかの方が多いように思えます。
特に合併前の両方に取引があったような場合とかは、既存のコード／データはそのままに残存させて、
新たにコードを新設した方がいいかもしれません。残高などは振り替えて繰り越せばいいでしょうし。
確かに"願望システム"の方が楽チンなところ有りますから、実は私も似たようなことやってたりしますが(^^;)、
これは多分に手抜きでして、一般的には履歴をキチンと残す方が無難だろうとの認識はあります。
社長兼小使いって感じで、一人で全部こなしているようなところでなければ、
自分以外の者が見ても経緯が判りやすいことも重要かと。

以上、老婆心ながら。
19134 老婆心感謝です。 しぼうかん 2003/02/28-23:10
記事番号19133へのコメント

なるほどっ、確かに"現実"の会社業務では履歴というのは重要な要素ですね。
いつも"楽に"とか"簡単に"が良いばかりじゃないということは、
事件が発生しないと気が付かない事がよくありますからね。

＞自分以外の者が見ても経緯が判りやすいことも重要かと。

この点はいつも意識して作っているつもりなんですが、のめり込むと、
つい意識から蒸発してしまいがちです。

桐のシステムといっても現実のシステムの意味をよく知っていないと良い物は作れないということですね。
さすがです！

よくわかりました＆恐れ入りました。<(_ _)>

19135 Re:ありがとうございました。 今村　誠 2003/02/28-23:45
記事番号19132へのコメント
しぼうかんさんこんにちは
>※２．[表引き用項目]は得意先.TBLに作った、#部分列([ふりがな],1,2)＋
>[得意先部署コード]＋[得意先]＋[部署]の項目計算式を書いた項目

せっかく計算項目を作ったのであれば、グループ表示の区切り文字
　　　　　　　　　　　　　　　　　　　　　　↓
　　　　#部分列([ふりがな],1,2)＋[得意先]+":"＋[部署]
のようにしたほうが先々使いでがあるのではないでしょうか、
部署コードと部署の両方を計算式に持つ意味は何でしょうか。
部署コードを先に表示することにどんな利点があるのでしょうか
入金と請求をまとめて残高を確認するための質問ではなかったのですか。
結論としては、全て入力し直して集計するということですか。

19136 是非頑張ってください。 ONnoji 2003/03/01-00:09
記事番号19132へのコメント
しぼうかんさん
>悲しげさん、宮城さん、今村さん、ONojiさん、野良犬さん、ありがとうござ
>いました。
>多くの方から助言を頂き、最初の質問内容以外の事もいろいろ勉強になりま
>した。

ご丁寧なリプライありがとうございます。m(__)m

最初から完璧を期すのは困難です…、しかし試行錯誤は成功への確実な歩みだと信じます。(^^v

しぼうかんさん、是非頑張ってください。(@^^)/~~~
19137 質問の答えになっているのか不安ですが・・・ しぼうかん 2003/03/01-02:13
記事番号19135へのコメント
いつもお返事有り難うございます。

まだ運用を開始してないので抜けていたり、余分だったり細かいミスがあったみたいです。
あとは大きな問題が起きない事を祈るだけです。(^^;)


>せっかく計算項目を作ったのであれば、グループ
>　　　　　　　　　　　　　　　　　表示の区切り文字
>　　　　　　　　　　　　　　　　　　　　　↓
>　　　　#部分列([ふりがな],1,2)＋[得意先]+":"＋[部署]


すいません、そうです。直しておきます。


＞部署コードと部署の両方を計算式に持つ意味は何でしょうか。
＞部署コードを先に表示することにどんな利点があるのでしょうか


［得意先部署コード]を表引きするのだからと余り考えずに表引き計算式に入れてしまったのですが、
確かに[得意先部署コード]は手入力する訳ではないので
[得意先部署コード]は表引き計算式に使って表示させる必要はないですね。
これも削除して直して置きます。


＞入金と請求をまとめて残高を確認するための質問ではなかったのですか。
＞結論としては、全て入力し直して集計するということですか。


すいません、この質問は私のどの説明部分からそう思われたのでしょうか。
ちょっと質問内容がつかみきれないのですが
説明ベタで何か誤解を生じる様な説明をどこかでしていたのかもしれません。

この投稿の最初の質問は、請求書は部署別に発行される場合があり、入金と売上台帳は
[部署]を含まない[得意先]別で管理されるので、納品書.wfmと得意先一覧.tblと
[コード](この時点ではコードの内容についてはあいまいなイメージしかありませんでした)を使って、
請求書発行の為の納品書データの集計と売上台帳に自動転記する時の
[得意先]別集計の両方を簡単に自動化出来ないでしょうか？という意味だったのです。

また今現在考えている得意先.tblでの入力項目は[得意先]、[ふりがな]、[部署]、他です。
[得意先部署コード］はカウンタ項目を予定しているので手入力はしません。

また納品書.wfmの手入力方法はまず［ふりがな２]を手入力し、[得意先部署コード」を表引き入力し、
この項目のソース値更新イベントで[得意先]と[部署]の
データを得意先.tblから持ってきて自動入力する、後は納品年など順々に入力していく。
という風に考えています。この当たりはまだ考えただけで実際にテストをした訳でないので
どこかにおかしな説明があるかもしれませんが、どうでしょう。
この返答では的をはずしていますか？
19138 Re:試行錯誤も大事です 今村　誠 2003/03/01-08:14
記事番号19137へのコメント
完成図はこうなると思っていました。部署コードに意味はないと思いました。
得意先名ごとに売上と入金の流れがつかめて請求番号が解れば請求納品で即座に検索できるので
会計の摘要欄には請codeは欠かせないと思いました。
請求書.tbl（変換作業.tbl）
請求日　　請code　表引き請求先名　得意先code　請求金額
03:01:21　1201　　あ社:総務課　　　　1234　　　　　234
03:01:22　1202　　い社:　　　　　　　　　4567　　　　　123
03:01:23　1203　　あ社:業務課　　　　　9098　　　　　345
03:01:24　1205　　う社:　　　　　　　　　3456　　　　　678
03:01:25　1206　　あ社:お支店　　　　　2345　　　　　324
会計.tbl　仕訳フォーム
　日付　　表引き請求先名　得意先code　科目　摘要　売上　入金
03:01:21　あ社:総務課　　　　1234　　　　売上　1201　234
03:01:22　い社:　　　　　　　　　4567　　　　売上　1202　123
03:01:23　あ社:業務課　　　　9098　　　　売上　1203　345
03:01:24　う社:　　　　　　　　　3456　　　　売上　1205　678
03:01:25　あ社:お支店　　　　2345　　　　売上　1206　324
03:02:13　あ社:業務課　　　　9098　　　　売上　1302　10500
03:02:20　あ社:支払課　　　　9932　　　　入金　１月分　　　903
会計.tbl　売掛帳フォーム
表引き請求先名　あ社:　　　売上　11403　入金　903
　日付　部署計算式　得意先code　摘要　　売上　入金　残高
03:01:21　総務課　　　1234　　　　1201　　234　　　　　234
03:01:23　業務課　　　9098　　　　1203　　345　　　　　579
03:01:25　お支店　　　2345　　　　1206　　324　　　　　903
03:02:13　業務課　　　9098　　　　1302　10500　　　　11403
03:02:20　支払課　　　9932　　　　１月分　　　　903　10500

しぼうかんさんのシステムですので押しつける気持ちはありません
このようなフォームも有りではないかと思っています。
19140 Re:試行錯誤も大事です 悲しげ 2003/03/01-12:04
記事番号19138へのコメント
今村さん、
ぢつは私もしぼうかんさんの構想の全体はつかめてはいないのですが(^^;)、
（第三者が「通訳」した方が判りいいことも有り得るので書きます）

#19137
>＞入金と請求をまとめて残高を確認するための質問ではなかったのですか。

と云うことでは無い模様です。少なくとも「残高」はしぼうかんさんが
所属する部署では全くノータッチのようですから。
つーか、「残高」を含む「台帳」を管理する部署は別なようでして、
しぼうかんさんの方から「台帳」の具体的イメージは、この間一度も出されてはいなかったと思います。
想像するに、それらは未定なのだと思います。
確かに、変則的かつ中途半端なのが隔靴掻痒状態ですけどね。(^^;)

それと#19138
>得意先名ごとに売上と入金の流れがつかめて請求番号が解れば
>請求納品で即座に検索できるので会計の摘要欄には請codeは
>欠かせないと思いました。

え〜、字句の意味するところ（言葉の定義の問題）ですが──
まず「請code」なる語を使ったのは私ですが、階層の親に相当するのが「得意先code」で、
この語はその下位階層に属する所謂「部署」に相当させる意味で用いました
（「請求先code」の短縮形です、請求書を「部署」毎に出すための）。
今村さんが上記で書かれているのは「請求番号」（いわゆる伝票番号）
としての「請code」だと思います。
発行した請求伝票を検索するために
何らかのデータ保存表の「摘要」欄に伝票番号も付記しておく、ってことですね。
う〜ん、いずれはそのような仕掛けも必要なことは有りえますが、
今回はそこまで手を広げてしまうとますます混乱の度が・・・(^^;)。

>部署コードに意味はないと思いました。

いえ、この間の一貫した論点（しぼうかんさんの問題意識の中心）がこの点、
即ち「得意先コードの階層管理」の問題だった筈です（伝番管理の問題ではなく）。


余談
「仕事に合わせたシステムを作る」vs「システムに仕事を合わせる」
──前者は往々にして、仕事の（ごく一部だけ）PCを当てるだけとなり、
結局手間としては微減程度（あるいはさほど変わらないか、極端な場合
キーボード操作の関係で逆に手間激増）なんてこともあったりします。
19141 もうちょっと教えて頂きたいのですが しぼうかん 2003/03/01-17:47
記事番号19138へのコメント
今村さん、"百聞は一見にしかず"、で具体例を挙げての内容は言葉だけの説明よりもわかりやすいで助かります。

しかしそれでも私の理解力ではいくつかわからない所がありまして、少し疑問と質問があります。

＞部署コードに意味はないと思いました。

これはもしかして"得意先部署コード"の言葉の意味の取り方が食い違っている様な気がします。

質問１.
私が考えていた[得意先部署コード]の意味は"請求先"が[得意先]と[部署]から成るとすると
[得意先コード]は[得意先]１つに１つ割り当てられる物で、
[得意先部署コード]とは[得意先]+[部署]を１体の物と考えてこの１体の物１つに
[得意先部署コード]１つを割り当てる様に考えています。
ですから[部署]のみに割り当てる"コード"ではありません。
この答えは的をはずしていますでしょうか？


[請code]とは[請求書番号]の事でしょうか、それでしたら今村さんに長い間教えて頂いて出来ています。

質問２.
また、請求書.tblに当たるTBLファイルは作っていません。
納品書.tblを[請求書番号]で集計して請求書を発行しています。
それとは別に請求書.tblを作った方がいいのでしょうか？

質問３.
書いて頂いた[得意先code]は連番にはなってなくてバラバラのようですが
この[得意先code]はどのファイルでどうやって付けるのか(例えば自動的に付けるのか、
手入力なのか)ちょっと想像が付かないのですが？

"仕訳フォーム"の使用方法に関して
経理の台帳に関する知識は無いのですが、たぶん入金と売上の日時処理を行う台帳だと思いますが、
実は悲しげさんへの"大長編ですが・・・"にも書いたのですが、
入金の日時処理は経理部でやっていて私の方の業務と別に処理されています。
私がやっている業務は納品書と請求書の発行、売掛台帳の記帳、月ごとの売上実績表の作成です。
この内の入金に関しては月の最初に経理部が発行した入金伝票の綴りを借りて
売掛台帳への一括しての記帳だけです。入金時ごとの入金処理など他の部分は経理部でやっています。
そこで"売上"の日時処理(伝票発行や台帳記入）に関しては可能なのですが、
入金の随時処理は現在は出来ません。(将来はわかりませんが)
そこで入金処理は入金台帳の様なファイルを作って、売掛台帳フォームへ納品書フォームの
データと結合させて自動的に作成出来ないかなと思っています。

質問４.以上の今村さん紹介の仕訳フォームの意味に関する私の認識はあっていますか？

売掛台帳は汎用品を使っているので、ほぼ私が考えている通りです。
最初の質問はこの様なフォームを納品書&請求書フォームでのデータと入金伝票フォームの
データと得意先一覧フォームを使ってボタン操作だけで印刷まで出来ないかと思って質問したのです。

いつも説明不足でご迷惑をお掛けしているのでかなり不完全でまたご迷惑をお掛けするかもしれないのですが
途中のシステムを補完ＢＢＳにシステムを添付したいと思います。
以前にお送りしたシステムからほとんどかわっていないのですが、
納品書フォームや得意先一覧フォームの形をみて頂いた方が
私のヘタな説明よりいいのじゃないかと思います。

なお最初は納品書入力.wfmより入ります。
では、よろしくおねがいします。

19142 またご迷惑をおかけしました。 しぼうかん 2003/03/01-17:52
記事番号19140へのコメント
悲しげさんには私のの説明不足でまたご迷惑をかけてしまったみたいです。m(_ _)m

＞入金と請求をまとめて残高を確認するための質問ではなかったのですか

実はそうなんです（売掛台帳では入金も請求も残高も必要なので）つまり、
私の説明ベタで悲しげさんに誤解を与えているみたいです。

「台帳」の具体的イメージは、この間一度も出されてはいなかったと思います。
想像するに、それらは未定なのだと思います。

売掛台帳は汎用品を使っているので
"日付"、"品名"、"数量"、"単価"、"売上金額"、"入金"、"備考"の項目があります。

具体的イメージを出していないのは私の説明不足です。
ただその売掛台帳フォームは納品書＆請求書フォームと入金伝票フォームの
データから自動的に作りたいなと思っているので、
まず元となる納品書データの形式とさらにその納品書データの管理の元となる得意先一覧の
作り方を最初にしっかり決めて置かなければ売掛台帳作成時に破綻してしまうと思って、
説明をその部分に集中してきました。

いつもいつも説明不足で本当に申し訳ないです。
それで百聞は１見にしかずということでシステムを補完ＢＢＳに添付したいと思いますので、
よかったらダウンロードしてみて下さい。
まだテストなのでいろいろおかしな所が有るかもしれないのですが、
私のつたない説明よりはマシかと思います。
なお売掛台帳フォームはまだ作っていません。
なお最初は納品書入力.wfmより入ります。

19145 Re:もうちょっと教えて頂きたいのですが 今村　誠 2003/03/01-20:12
記事番号19141へのコメント
しぼうかんさんこんにちは
>質問１.
>私が考えていた[得意先部署コード]の意味は"請求先"が[得意先]と[部署]か
>ら成るとすると[得意先コード]は[得意先]１つに１つ割り当てられる物で、
>[得意先部署コード]とは[得意先]+[部署]を１体の物と考えてこの１体の物１
>つに[得意先部署コード]１つを割り当てる様に考えています。ですから[部
>署]のみに割り当てる"コード"ではありません。
>この答えは的をはずしていますでしょうか？

特定できるコードを二つ持つ必要はないと思います。
得意先部署コードが重複しない値でその得意先部署コードがあれば得意先コードは必要ないと思います。
　ただ私が運用するわけではないので、しぼうかんさんが何かに使用されるのであればあってもいいと思います。

>質問２.
>また、請求書.tblに当たるTBLファイルは作っていません。納品書.tblを[請
>求書番号]で集計して請求書を発行しています。
>それとは別に請求書.tblを作った方がいいのでしょうか？

売掛帳に記入するときに、納品書の明細をすべて記載するのか
請求書のヘッダだけを取り出して記帳するかの違いだと思います。
納品書の明細すべてを記帳するのであれば、私なら他の方法をとると思います。
私がコメントしたのは、請求書番号毎の記載例を示しました。
納品番号毎ではないです。

>質問３.
>書いて頂いた[得意先code]は連番にはなってなくてバラバラのようですがこ
>の[得意先code]はどのファイルでどうやって付けるのか(例えば自動的に付け
>るのか、手入力なのか)ちょっと想像が付かないのですが？

私は得意先一覧.tblでのカウンターを想定しています。

>そこで入金処理は入金台帳の様なファイルを作って、売掛台帳フォームへ納
>品書フォームのデータと結合させて自動的に作成出来ないかなと思っていま
>す。

私は結合は得意ではないので、納品書メイン.tblから売掛帳に必要なまとめの部分だけを抜き出して、
会計.tblに自動で転記して入金をそこに入力したらいいのかなと思っていました。
　しぼうかんさんが結合が得意であれば、納品書サブと納品書メインと得意先と
入金明細を結合して売掛帳の伝票フォームを作成すると、その伝票フォームを開くだけで、
残高などもできるとは思いますが、したことのない操作ですので、
わたしには？？です。
あまりのも長大なスレッドになったようなので、また質問があるときは、
別のを立てられてはいかがでしょうか。

19152 了解しました。 しぼうかん 2003/03/02-19:49
記事番号19145へのコメント
今村さん、長い間お世話になりました。

＞私は結合は得意ではないので、納品書メイン.tblから売掛帳に必要なまとめの部分
だけを抜き出して、

桐の機能の"結合"では無くてデータの結合（合成？）という意味だったんですが、(^^;
このスレッドは最初から最後まで、私の説明不足による"補足説明"の為のツリーが長大なスレッドの原因でした。

次回はこの点、十分に気をつけてスレッドを立てたいと思います。

一つ気が付いたのは最初の投稿で長文を恐れずに出来るだけ詳しく書くと言う事ですね。
19291 ひっそりと追加報告です。 しぼうかん 2003/03/10-21:04
記事番号19055へのコメント

もう誰も見ていないと思いますが、少し改善があったので、過去ログを見られる方の為に追加報告したいと思います。

イベントで表引きする方法がわかったので、[得意先コード]を入力してから
[得意先]と[請求部署]を表引き入力する方法はやめました。

得意先一覧を編集対象表とする表引き用のフォームを作成し、
[得意先]オブジェクトの入力前イベントで[ふりがな２]項目を照合項目にして、
表引き用に作成したフォームをフォーム呼び出しコマンドで呼び出して[得意先]と
[請求部署]を同時に表引きして入力する方法にしました。
これで[得意先コード]を入力するのは止め、得意先一覧に#部分列([ふりがな]、1,2)+[得意先]+[請求部署]といった項目を
持つ必要も無くなりました。


表引き用ファイルのイベント

手続き定義開始　フォーム::キーダウン(長整数　&仮想キーコード，長整数　&スキャンコード，長整数　&フラグ，参照　長整数　&処理中止)
ケース開始
ケース(&仮想キーコード=13)　/*リターンキーを押した時に"得意先表引"の[得意先]を変数(&得意先)にとりたい*/
メソッド呼び出し　@得意先.ソース値取得(&得意先,0)
メソッド呼び出し　@請求部署.ソース値取得(&請求部署,0)
メソッド呼び出し　@終了.実行()　/*フォームを閉じるコマンドボタンを作った*/
ケース終了
手続き定義終了


手続き定義開始　フォーム::フォーム開始(長整数　&表番号)
検索　[ふりがな]{&ふりがな２*}
手続き定義終了


納品書フォームのイベント

手続き定義開始　得意先::入力前(参照　文字列　&編集文字列)
メソッド呼び出し　@フォーム.更新モード取得(&ok)
メソッド呼び出し　@ふりがな２.ソース値取得(&ふりがな２,0)
フォーム呼び出し　"得意先表引",許可作業=*,ボタン=&表引き,編集表=しな
い
メソッド呼び出し　@フォーム.更新モード設定(&ok)
項目値代入　[請求部署]=&請求部署
&編集文字列=&得意先
手続き定義終了

19296 Re:ひっそりと追加報告です。 悲しげ 2003/03/10-23:54
記事番号19291へのコメント
どもっ、しぼうかんさん

>表引き用ファイルのイベント
>
>手続き定義開始　フォーム::キーダウン(長整数　&仮想キーコード，・・・
>ケース開始
>ケース(&仮想キーコード=13)
>メソッド呼び出し　@得意先.ソース値取得(&得意先,0)
>メソッド呼び出し　@請求部署.ソース値取得(&請求部署,0)
>メソッド呼び出し　@終了.実行()
>ケース終了
>手続き定義終了

ここなんかは、普通はメソッド呼び出しするまでもなく、単に

ケース(&仮想キーコード=13)
　&得意先=[得意先],&請求部署=[請求部署],&処理中止=1
　メソッド呼び出し　@終了.実行()
ケース終了

だけでもよいのでは？＠添削モード(^^;)
あ、ソース値取得メソッドを使った方が、より細かく制御できる場合もあるから、
いいんですけどね。でも、一寸意外でした。

ちなみに、&処理中止=1を入れておかないと、Enterキー押下で、
表を閉じる直前にカーソルが進んでしまいます。別に気にならないかもしれませんが。
19321 最終報告です。 しぼうかん 2003/03/12-21:07
記事番号19296へのコメント
悲しげさん、こんばんわ。

こんな後ろのツリーを見られる事もあるんですね。

>ケース(&仮想キーコード=13)
>　&得意先=[得意先],&請求部署=[請求部署],&処理中止=1
>　メソッド呼び出し　@終了.実行()
>ケース終了
>
>だけでもよいのでは？＠添削モード(^^;)
>あ、ソース値取得メソッドを使った方が、より細かく制御できる
>場合もあるから、いいんですけどね。でも、一寸意外でした。
>
>ちなみに、&処理中止=1を入れておかないと、Enterキー押下で、
>表を閉じる直前にカーソルが進んでしまいます。別に気にならな
>いかもしれませんが。


まだまだ知らない事ばかりなので
教えて頂いた細かなテクニックは早速使わせてもらいます。
ありがとうございました。
しかしこんな巨大なツリーはもしかしてこの掲示板のギネス物？

幅田さんご迷惑をお掛けしました。

戻る