過去の桐井戸端ＢＢＳ　（桐ver.８）
19553 請求書番号の付け方について、どういうのが普通なのでしょうか しぼうかん 2003/03/22-00:45
またお世話にならせて下さい。

まず言葉の意味について説明したいと思います。
以下の説明で使う[請求書番号]とは入力済みのレコードと[社名]＋[締月]を比較して、
同じ[社名]＋[締月]を持つレコードが無かった場合は、
入力済みの[請求書番号]の最大値に＋１を加えた数字を、
または同じレコードが合った場合は、そのレコードに付いている[請求書番号]を
現在入力中の[請求書番号]に自動的に(イベントで)割り付けている番号です。
今はこの[請求書番号]は印刷用には使っていません。

例えば下記の表Ａ−１と入力後、締月が４月では無くて３月の間違いであった事に気が付き
表Ａ−２の様に変更した場合、請求書番号１００２は消えてしまいます。

質問内容は、この方法は果たして"普通"なのでしょうか、
それとも表Ａ−３の様に変更前のレコードは履歴として残したまま金額を０にして
請求書番号１００４としてレコードを新規作成した方が"普通"なのでしょうか？と言うことです。


表Ａ−１
請求書番号｜社名｜締月｜金額｜備考｜
　　　１００１｜ああ｜３月｜１０｜　　｜
　　　１００２｜ああ｜４月｜２０｜　　｜
　　　１００３｜いい｜４月｜３０｜　　｜

　　　　↓

表Ａ−２
請求書番号｜社名｜締月｜金額｜備考｜
　　　１００１｜ああ｜３月｜１０｜　　｜
　　　１００１｜ああ｜３月｜２０｜　　｜
　　　１００３｜いい｜４月｜３０｜　　｜

それとも

表Ａ−３
請求書番号｜社名｜締月｜金額｜備考｜
　　　１００１｜ああ｜３月｜１０｜　　｜
　　　１００２｜ああ｜４月｜　０｜取消｜
　　　１００３｜いい｜４月｜３０｜　　｜
　　　１００４｜ああ｜３月｜２０｜　　｜

19554 Re:請求書番号の付け方 悲しげ 2003/03/22-02:26
記事番号19553へのコメント
当店の仕入伝票では

伝番　社名　　金額　　備考
1001　ああ　　１０
1002　ああ　−１０　取消(原伝1001)
1003　いい　　３０
1004　ああ　　２０　訂正(原伝1001)

なんてのがあって、これが一番厳密かなと感じています。
私が以前に書いたのは、このパターンです。
（ちなみに、訂正伝票の類で月をまたいだものは殆ど見ることはありません）
しかしこれが"普通"なのかどうかは全く判りません。

それと、しぼうかんさんが定義する「請求書番号」にこれが該当するのかどうかも
よく読解できてはおりませんが、
しかしながら、より詳しい説明を求めているのではありませんので、
この部分へのコメントは不要です。

余談ながら、私は、伝番は単なる伝番であって、
番号自体にさほどの意味を求めてはいない＝求めるものはアイデンティティのみなので、
欠番が発生しても全く気にしていません。
19555 Re:請求書番号の付け方 悲しげ 2003/03/22-02:33
記事番号19554へのコメント
あ、

伝番　社名　　金額　　備考
1001　ああ　　１０　　　　　＊
1001　ああ　−１０　　取消　＊
1003　いい　　３０
1001　ああ　　２０　　訂正

なんてところもあるみたい。
それと、一般に「＊」印の行は、月締めの明細一覧には出力しないところが多いようです
（そのまんま出力するところもあるがマイナー）。
19558 Re:請求書番号の付け方 悲しげ 2003/03/22-09:56
記事番号19554へのコメント
こんな伝票もあります。

伝番　社名　　金額　　備考
1001　ああ　　１０
1002　ああ　＋１０　訂正(原伝1001)　←差額※
1003　いい　　３０

※伝票の明細は次のようになっている
日付　　　品名　　数量　単価　　金額
某月先日　品名Ａ　−２　　５　−１０　原伝1001
某月今日　品名Ａ　　２　１０　　２０　単価訂正
　計　　　　　　　　　　　　　　１０

しぼうかんさんとこでも「仕入伝票」の類があるでしょうから
色々調べてみたらいかがでしょう。
少なくともここで色々な例をリクエストするより遥かに効率的に違いありません。
「これが"普通"だ！」と主張する人が出てくれる可能性はかなり薄いと想像します、
それこそ"普通"は。(^^;)

つー訳で、挙げればキリが無いほど色々ありましょうが、
結論としては、どの方式かを決めるのは、先方（特にメジャーな？）の意向と、
当方の都合（使い易さ）だと思います。
両者を足して２で割るっつーか。

19560 「請求書番号」とは云わないのでは？ 悲しげ 2003/03/22-10:20
記事番号19553へのコメント
#19553を改めて読んでみると

「請求書番号」とは、その呼称とはウラハラに、
要するに
[社名]＋[締月]のフラグ値のことのようですね。う〜ん、
これでは国語の答案(^^;)としてはまたまた落第です。
私なら、他者に説明する場合には例えば「社名締月フラグ」
などのように云い替えると思います。だってそうしないと
無用な混乱を招きそうだから。(^^;)

つー訳で、

>質問内容は、この方法は果たして"普通"なのでしょうか、

そもそもが"普通"じゃないような気がしないでもありませんが(^^;)、
「請求書番号」＝[社名]＋[締月]のフラグ値だと
するならば、これは訂正等で明細部等が変更になろうとも、
このまんまとしておくしかないのではないでしょうか？

先の私のコメントは、「社名締月フラグ」ではなく、"普通"の
「伝票番号」についてですから、撤回します。

19561 看板に偽り有りでした。本当は"社名締月フラグ"の付け方 しぼうかん 2003/03/22-10:41
記事番号19560へのコメント
悲しげさん、おはようございます。

毎度毎度お世話になっています。

また国語の点数で赤点をとってしまった落第生です。(^_^;)
ですが、おかげさまで、今回はすぐに結論が出ました。

※ちなみにこの請求書番号の変更は全て印刷後に請求書を先方へ送付する前のチェックで
ミスに気が付いて変更した場合を想定していました。

それで、いくつかのパターンを紹介して頂きましたが、"余談"のパターンを採用させて頂きます。

>余談ながら、私は、伝番は単なる伝番であって、番号自体
>にさほどの意味を求めてはいない＝求めるものはアイデン
>ティティのみなので、欠番が発生しても全く気にしていま
>せん。

つまり最初に考えていた表Ａ−２です。
請求書を識別するために付けた番号なのでかってに"請求書番号"と呼んでいましたが、
どうも"普通"の呼び名ではなかったみたいです。

ありがとうございました。
19562 Re:請求書番号の付け方 ONnoji 2003/03/22-11:22
記事番号19553へのコメント


>まず言葉の意味について説明したいと思います。
>以下の説明で使う[請求書番号]とは入力済みのレコードと[社名]＋[締月]を
>比較して、同じ[社名]＋[締月]を持つレコードが無かった場合は、入力済み
>の[請求書番号]の最大値に＋１を加えた数字を、または同じレコードが合っ
>た場合は、そのレコードに付いている[請求書番号]を現在入力中の[請求書番
>号]に自動的に(イベントで)割り付けている番号です。
>今はこの[請求書番号]は印刷用には使っていません。

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

納品（履歴）マスターファイル → 当月請求（作業）ファイル を起こすのだと思いますが…

これは
(1)納品（履歴）ファイルから該当分を絞り込んで行集計してもいいし、
(2)取引先マスターから当月請求（作業）ファイルを起こして、
納品（履歴）ファイル → 当月請求（作業）ファイル で併合や置換などをする
の二通り考えられますが、

(2)の方法が無難なように思います。

この時、当月請求データファイルにＩＤが必要か否かという問題のように思いますが…
これは不用ではないでしょうか、

もしも、どうしても当月請求データファイルのデータにＩＤが必要ならば、
今回限りの使い捨てのＩＤを振るか、
請求（履歴）ファイルの最終ＩＤから連続したＩＤを振るような気がします。

しかし、そもそも、請求（履歴）ファイルにＩＤが本当に必要か疑わしいです。

というのも、客先コードと請求月でレコードは一意に決定できるのでしょうから、
［客先コード］と［請求月］をキーを考えれば済みそうな気がします。

もっとも、［客先コード］またはその代用を放棄しているのなら話は別になってしまいますが…

>例えば下記の表Ａ−１と入力後、締月が４月では無くて３月の間違いであっ
>た事に気が付き表Ａ−２の様に変更した場合、請求書番号１００２は消えて
>しまいます。
>
>質問内容は、この方法は果たして"普通"なのでしょうか、それとも表Ａ−３
>の様に変更前のレコードは履歴として
>残したまま金額を０にして請求書番号１００４としてレコードを新規作成し
>た方が"普通"なのでしょうか？と言うことです。

納品（履歴）ファイルのレコードに入力誤りが生じて、請求額が誤っていた場合には、
当月請求（作業）ファイルをいったん破棄して、
納品（履歴）ファイルのレコードの値を訂正し、
もう一度、納品（履歴）ファイルを生成するのが正しい筋道ではないかと思います。

※誤った入力をそのままにして、作業を続行するのは感心できません。

＜追伸＞

例によって、また噛み合わないことを書いてしまったような…(^^ゞ

当方は次のようなイメージを考えています。
なお、図は簡略化しており、月次処理で繰越伝票が発生するケースなどは省略しています。

＜入力処理＞

当日入力（作業）ファイル
　　├─────────────┐
　　↓　　　　　　　　　　　　　↓
　保存　　　　　　　　　　　　破棄
　　↓
当月入力（作業）ファイル
　　↓
　保存
　　↓
納品（履歴）ファイル


＜月次処理＞

月次処理開始
　　↓
　Yes
　　↓
取引先マスター　　納品（履歴）ファイル
　　↓　　　　　　　　　↓
（全取引先）　　　　　（当月分の金額）
　　↓　　　　　　　　　↓
　　└────┬────┘
　　　　　　　↓
　　当月請求（作業）ファイル
　　↓　　　　　　　　　↓
請求書発行　　　　　　破棄（入力誤りなどでやり直し）
　　↓
　保存
　　↓
　　├─────────────┐
　　↓　　　　　　　　　　　　　↓
請求（履歴）ファイル　　納品（履歴）ファイルの請求済みフラグを立てる

19564 請求書ＩＤはもしかして不要？ しぼうかん 2003/03/22-13:28
記事番号19562へのコメント
毎度、お返事ありがとうございます。
またおかしな説明や解釈で混乱させてしまうかもしれませんが、ご勘弁ください。


＞(1)納品（履歴）ファイルから該当分を絞り込んで行集計してもいいし、


現在は納品書レコードを請求書IDでグループ化しているのでこの(1)に近い方式になっていますが、
作業表から転記した売掛台帳テーブルを対象表として印刷する方式に変えようと思っています。


＞この時、当月請求データファイルにＩＤが必要か否かという問題のように思いますが…
＞これは不用ではないでしょうか、
＞しかし、そもそも、請求（履歴）ファイルにＩＤが本当に必要か疑わしいです。
＞というのも、客先コードと請求月でレコードは一意に決定できるのでしょうから、
＞［客先コード］と［請求月］をキーを考えれば済みそうな気がします。


おっしゃるとおり請求書IDの必要性に疑問が生じてしまいましたので、
請求書ＩＤを無くして[客先コード]と[請求月]と[分割請求](※1)で代用して
うまくいくか月曜に会社でチェックしてみたいと思います。
(手元に現物が無く想像するしかないので)

※1(これは最初の質問に関係がないと思い省略したのですが、
同一の客の同一の請求月に複数の請求書を発行する場合がある為、
それぞれに別の請求書ＩＤを割り付ける為に作った項目です)


＞納品（履歴）ファイルのレコードに入力誤りが生じて、請求額が誤っていた場合には、
＞当月請求（作業）ファイルをいったん破棄して、
＞納品（履歴）ファイルのレコードの値を訂正し、
＞もう一度、納品（履歴）ファイルを生成するのが正しい筋道ではないかと思います。
＞※誤った入力をそのままにして、作業を続行するのは感心できません。


これは表Ａ−３の方式についてだと思いますが、悲しげさんのヒントを参考にして
表Ａ−２の方式でいこうと思っていました。
が、請求書ＩＤの必要性そのものに疑問が生じたのでチェックしてみる事にしました。


<追伸>

流れ図はシステム作りに関してのエッセンスがつまっていて参考になりそうなので、
お聞きしたい事があるのですが、このツリーの最初の質問からはずれてしまいそうなので、
別ツリーを立てて質問したいと思います。
その節はまたよろしくお願いします。



19568 入金管理のための請求書なのか？私には謎が深まるばかりです。 ONnoji 2003/03/22-14:07
記事番号19564へのコメント
>毎度、お返事ありがとうございます。
>またおかしな説明や解釈で混乱させてしまうかもしれませんが、ご勘弁ください。

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

また横槍をいれてスイマセンでした。(^^ゞ

>＞納品（履歴）ファイルのレコードに入力誤りが生じて、請求額が誤っていた場合には、
>＞当月請求（作業）ファイルをいったん破棄して、
>＞納品（履歴）ファイルのレコードの値を訂正し、
>＞もう一度、納品（履歴）ファイルを生成するのが正しい筋道ではないかと思います。
>＞※誤った入力をそのままにして、作業を続行するのは感心できません。
>これは表Ａ−３の方式についてだと思いますが、悲しげさんのヒントを参考にして表Ａ−２の方
>式でいこうと思っていました。
>が、請求書ＩＤの必要性そのものに疑問が生じたのでチェックしてみる事にしました。

表Ａ−３の方式といえばそうかもしれませんが、

>表Ａ−３
>請求書番号｜社名｜締月｜金額｜備考｜
>　１００１｜ああ｜３月｜１０｜　　｜
>　１００２｜ああ｜４月｜　０｜取消｜
>　１００３｜いい｜４月｜３０｜　　｜
>　１００４｜ああ｜３月｜２０｜　　｜

表Ａ−３の方式かどうかは良く理解できませんが、
取り消し伝票を作成して、新しく伝票を起こすということのようですね。
もちろん「取り消し」「新規」のペアでもいいですし。
納品（履歴）ファイルを訂正してもＯＫだと思います。

しかし、入力ミスをチェックするのが請求書を印字した後というのは…
私ならば、当月納品（作業）ファイルを「入力チェック一覧表」を印字するか、
画面上で確認するか、
あるいは両方出来るようにします。
そして、

私( ONnoji )は…
入力が正しいことを確認して、初めて次の作業に進めることができることを原則とする。
これが、しぼうかんさんのお好きな「普通のやり方」だと思っています。

流し読みしているわけではありませんが、あまりにも難解なので…やっぱり判らない。

しかし、
入金管理のための請求書なのか？
単に、＜納品・請求書＞ なのか？

私には謎が深まるばかりです。

＜入力処理＞

当日入力（作業）ファイル
　　├─────────────┐
　　↓　　　　　　　　　　　　　↓
　保存　　　　　　　　　　　　破棄
　　↓
当月入力（作業）ファイル
　　↓
入力が正しいかチェック（一覧表 と 画面 ）→印字結果をファイリングする
　　↓
　保存
　　↓
納品（履歴）ファイル
　　↓
納品・請求書 発行？？？？


19571 Re:看板に偽り有りでした。本当は"社名締月フラグ"の付け方 悲しげ 2003/03/22-16:03
記事番号19561へのコメント
>それで、いくつかのパターンを紹介して頂きましたが、"余談"のパターンを
>採用させて頂きます。
>
>>余談ながら、私は、伝番は単なる伝番であって、番号自体
>>にさほどの意味を求めてはいない＝求めるものはアイデン
>>ティティのみなので、欠番が発生しても全く気にしていま
>>せん。
>
>つまり最初に考えていた表Ａ−２です。

この余談からどうして表Ａ−２の採用となるのかが、実はよく理解できません。
実は、読み返してみると表Ａ−２の意味するところも判っていなかったことに気づきました。
だから私としては表Ａ−２の採用に（反対はしませんが）同意もしません。(^^;)

ただ、別稿で「請求書番号」＝「請求書ＩＤ」＝「社名締月フラグ」を無くするようなコメントがありますので、
そのことには賛成です。
実は、当初から「請求書番号」＝「請求書ＩＤ」には疑問があったのですが、
その中味が[社名]＋[締月]であったことには驚きました。
遥か前の話では、ひとつの得意先について階層下の複数部署毎に請求書を
別束ねとすることだったのではないかと記憶しています。
とすれば（締め対象月の期間でもってデータを絞り込んでいることを前提としますが）、
フラグの構成要素は
　　[得意先コード]＋[部署名]　　　　/*部署名は空も有りうる*/
となる筈だと思っていたからです。
それも恒常的なコードとするまでもなく、請求作業時の一時的取得でも構わない、と。
少なくとも[社名]＋[締月]に意味があるとは思えません。

19572 謎が謎をよぶ難事件・・・にするつもりはないのですが。 しぼうかん 2003/03/22-17:14
記事番号19568へのコメント
横槍大歓迎です。

しかし、まずいですね〜(^_^;)
また、私のせいでまた混乱に拍車を掛けているみたいです。


＞しかし、入力ミスをチェックするのが請求書を印字した後というのは…
＞私ならば、当月納品（作業）ファイルを「入力チェック一覧表」を印字するか、画面上で確認する>
＞か、あるいは両方出来るようにします。


たしかにおっしゃる通り画面上でチェックはしますが、最終チェックは印刷した請求書を担当営業がします。
その時（担当営業チェック時）になってから、
例えば２０日締めで納品日が３月２０日に納品された売上商品の請求書を、
４月２０日の締めにしてほしい、とか困った事をいって来る場合があるのです。
これはデータベースのシステムというより、会社のシステム上の問題なのですが、
諸般の事情によりこれに合わせるしかありません。

ONnojiさんが書いて下さった流れ図でいうと"納品・請求書 発行？？？？"からもう一度"当日入力
（作業）ファイル"へ戻るという処理が有り得るのです。


＞入金管理のための請求書なのか？
＞単に、＜納品・請求書＞ なのか？
＞私には謎が深まるばかりです。


入金管理のための請求書と＜納品・請求書＞の説明が少し理解出来ないのですが、
もし前のツリーで私が述べていた入金欄や残高欄がある一般的な請求書が"入金管理のための請求書"であり、
月ごとの売上請求額のみが印刷してある請求書が"単に＜納品・請求書＞"を指しているならば、
いまのシステムはまだ後者の方ですが、将来的に前者の方へ移行したいと思っているので、
前者を前提に考えて頂ければ助かります。

それともこの解釈もまた混乱に拍車を掛けて、もう迷宮入りしたりして・・・
自信なしです(*_*)


19573 混乱作成人とＨＮを変えるべきでしょうか？ しぼうかん 2003/03/22-18:24
記事番号19571へのコメント
＞その中味が[社名]＋[締月]であったことには驚きました。
＞遥か前の話では、ひとつの得意先について階層下の複数部署毎に請
＞求書を別束ねとすることだったのではないかと記憶しています。


すいません、また説明不足でした。
実際は[社名]＋[締月]では無くて［得意先コード］＋［締年］＋［締月］＋［分割請求](※
1)です。

※１(同一の得意先で同一月に複数の請求書を発行する場合に対応して請求書ＩＤを区別して
発行するための項目です。今回の質問に関係無いなと思って省略してました。)


＞その中味が[社名]＋[締月]であったことには驚きました。
＞遥か前の話では、ひとつの得意先について階層下の複数部署毎に請求書を別束ねとするこ
＞とだったのではないかと記憶しています。


遙か前のツリーを見返して見ましたが自分でも何がなんだかわからない様になってますね。
悲しげさんがおっしゃっていたツリーの"質"が悪いとはこういうことなんでしょう。

そして読み返した結果No19132の"現実システム"で述べている［得意先］＋［請求部署］に対して
［得意先部署コード］をつけるといってますが基本的にはこのコード（ＩＤ）の付け方は現在も基本的に変わっていません。

で、混乱を起こさせた原因は私の表現が変わってしまった事ですね。
今回［得意先コード］といっているのは前回でいう所の［得意先部署コード］で［得意先］＋［請求部署］に対して付けられます。
ですから、

＞フラグの構成要素は
＞　　[得意先コード]＋[部署名]　　　/*部署名は空も有りうる*

と言うところはその説明で意味はあっていると思います。

そしてこれを売掛台帳に［得意先］ごとにまとめる時は［得意先］の項目その物でまとめるか、
［得意先］ごとにユニークな本当の意味の［得意先コード］を作るかしてその項目でまとめようと思っていました。

が、ONnojiさんがおっしゃった通りＩＤに意味があるのかどうかを実際のデータを前に検証して見たいと思っています。

19576 アプリの本当の目的はなんでしょうか？困ってごわす。 ONnoji 2003/03/22-23:07
記事番号19572へのコメント
しぼうかんさん、こんばんは。名探偵 ONnoji です（ウソです）。

>しかし、まずいですね〜(^_^;)
>また、私のせいでまた混乱に拍車を掛けているみたいです。
>たしかにおっしゃる通り画面上でチェックはしますが、最終チェックは印刷した請求書を担当営業が
>します。

ということは…
入力時の原票（またはなり資料）はだれが作成したのですか？

担当営業？それとも？？誰？？？

>その時（担当営業チェック時）になってから、例えば２０日締めで納品日が３月２０日に納品された
>売上商品の請求書を、４月２０日の締めにしてほしい、とか困った事をいって来る場合があるので
>す。
>これはデータベースのシステムというより、会社のシステム上の問題なのですが、諸般の事情により
>これに合わせるしかありません。

これって、データの修正ですね。
しかも、担当営業様様が納品明細を確認してですね。

こういう時は、まず請求書原案を提出して、それを担当営業様様に朱記訂正してもらって、請求書原案をいったん破棄してから、
再度、請求書原案を作成して、担当営業様様に確認してもらうという作業を繰り返すしかないのではありませんか？

>ONnojiさんが書いて下さった流れ図でいうと"納品・請求書 発行？？？？"からもう一度"当日入力
>（作業）ファイル"へ戻るという処理が有り得るのです。

流れ図と言われる物は、ただのポンチ絵みたいな簡略なものです。
（また、私は○×△管理システムという大げさな名称は好みませんので、）
単に、スケッチとでも呼んでいただければ嬉しいのですが。(^^ゞ

>＞入金管理のための請求書なのか？
>＞単に、＜納品・請求書＞ なのか？
>＞私には謎が深まるばかりです。
>入金管理のための請求書と＜納品・請求書＞の説明が少し理解出来ないのですが、
>もし前のツリーで私が述べていた入金欄や残高欄がある一般的な請求書が"入金管理のための請求
>書"であり、月ごとの売上請求額のみが印刷してある請求書が"単に＜納品・請求書＞"を指しているな
>らば、いまのシステムはまだ後者の方ですが、将来的に前者の方へ移行したいと思っているので、前
>者を前提に考えて頂ければ助かります。

私( ONnoji )の勝手な想像では…
もれなく請求するということが趣旨のようですね。
そうなると、未入金が発生すると、繰り越し請求などが発生するかもしれませんが大丈夫でですか？
当アプリで繰り越し請求はしなくても、その辺を経理担当者が上手く処理してくれるとかしますか？

なお、＜納品・請求書＞とは納品書兼請求明細書という意味です。
※客先が請求書（または請求明細書）と照合するためのものだと思います。

請求書には、請求明細書を添付する場合もあるでしょうけれど、
当月ご請求金額をキッパリと印字したものを請求書と呼ぶと思います。

>それともこの解釈もまた混乱に拍車を掛けて、もう迷宮入りしたりして・・・
>自信なしです(*_*)

しぼうかんさんは、何度も各論をご説明されているように思いますが…
ディテールを詳細に説明されるより、
（私はシステムという言葉が大げさで嫌いですから）
アプリの目的を明確にしていただきたいと思います。

ボトムアップ手法が有効なのは、目的が明確な場合です。
しこうして…
しぼうかんさん、アプリの本当の目的はなんでしょうか？？？？？？

実はこれが判りませんから困ってごわす。m(__)m

19583 目的はひとを混乱させる事ではなくて・・・ しぼうかん 2003/03/23-15:38
記事番号19576へのコメント
ONnojiさん、どうもご迷惑を掛けまくっているしぼうかんです。

>ということは…
>入力時の原票（またはなり資料）はだれが作成したのですか？
>担当営業？それとも？？誰？？？


担当営業です。が、いい加減な営業がおりまして、
原票の内容に変更があった場合は速やかに変更してもらいたいのですが
変更せずに印刷後にいって来たり、最初から原票の内容が間違っていたり
(営業担当しかわからない間違い)するのです。
しかもたいがいこういう事をする人ほど、これに対応出来ないと、"うちにはパソコンのシステムは向かない"とかいったりして困り者です。


>こういう時は、まず請求書原案を提出して、それを担当営業様様に朱>記訂正してもらって、
>請求書原案をいったん破棄してから、
>再度、請求書原案を作成して、担当営業様様に確認してもらうという>作業を繰り返すしかないのではありませんか？


我が社にはお金が沢山余っているので(もちろんウソです。)納品書や請求書を印刷した現物で校正して、
違っていたら納品書や請求書ごと破棄します。

ですから場合によっては"普通"は"そういう異常な処理に対応するシステムは作りません"という助言であっても"普通"のシステムを知る上では大変参考になります。


>そうなると、未入金が発生すると、繰り越し請求などが発生するかもしれませんが大丈夫でですか？


あれ？、なんか私は読み飛ばしたりしてかなり前から誤解していたのかもしれません。
今現在は月ごとの売上を請求しているので、繰り越し請求は起こりませんが、
請求書に入金欄や残高欄がある請求書では当然繰り越し請求は発生する物だと思っていました。
さらにこの入金欄や残高欄を請求書に印刷する為には売掛台帳との連携が必須だと思っていました。

でも"・・・大丈夫ですか？"の？マークから推理すると(ヘボ探偵ですが)ONnojiさんが考えるまたは
使っているシステムでは繰り越し請求が発生しないのでしょうか？


>請求書には、請求明細書を添付する場合もあるでしょうけれど、
>当月ご請求金額をキッパリと印字したものを請求書と呼ぶと思います。


請求書には請求金額がキッパリと印刷されていますが、これと同時に複写の納品書を印刷したときに
同時に複写印刷される"請求明細書"を請求書に組み合わせホッチキスで止めて送付する形になっています。
(まあ請求書用紙は鏡用紙をイメージしてもらえば近いと思います)

また各論に走ってしまいましたが、説明ベタとしては何でも説明しないとうまく意志を伝える自信がないのです。

アプリの目的は納品書と請求書と売掛台帳の印刷です。
そして共通するデータを印刷する場合に食い違って印刷される事が無いように同じデータは
二重に入力することなく共用できるように入力して印刷する。

そして現在はいろいろ特殊な部分を作らなければならないかもしれないですが、"普通"のシステムを
部分的にでも少しづつ取り入れて、最終的には少しでも普通のシステムに近づけたいと思っています。

※繰り返しになりますが"普通"にこだわるのは将来の修正や追加などへの対応能力が"普通"のシステムの方が
大きいと思っているからです。
またたとえばこのような掲示板で助けて頂く場合でも普通の方法をとっていた方が助けて頂く手の数も多くなるように思います。

どうでしょうか。これで目的は伝わりましたでしょうか？
19586 「何とかで作る販売管理」と題した書籍を参考にされたらいかがでしょうか？ ONnoji 2003/03/23-21:36
記事番号19583へのコメント
しぼうかんさんは No.19583「目的はひとを混乱させる事ではなくて・・・」で書きました。
>>入力時の原票（またはなり資料）はだれが作成したのですか？
>担当営業です。

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

例によってポンチ絵を少し書いて見ますね。(^^ゞ

＜伝票入力＞

入力原票
　↓
フォームを使い変数へ入力
　↓
Yes,保存
　↓
当月入力（作業）ファイルに行追加　→　納品書発行？？
　↓
おわり

＜当月伝票転記作業＞

当月伝票転記
　↓
Yes,転記作業
　↓
納品（履歴）ファイル　←　当月入力（作業）ファイル
　↓
納品（履歴）ファイルの転記完了
　↓
おわり

>>こういう時は、まず請求書原案を提出して、それを担当営業様様に朱記訂正してもらって、
>>請求書原案をいったん破棄してから、
>>再度、請求書原案を作成して、担当営業様様に確認してもらうという作業を繰り返すしかないのではありませんか？
>納品書や請求書を印刷した現物で校正して、違っていたら納品書や請求書ごと破棄します。

そうですか…チェックシートを印刷して、
それを営業担当者に朱記訂正してもらって、
動かぬ証拠を握ってから、データを訂正すればいいのではないかと思いますが…

＜月次処理＞

月次処理
　↓
Yes,月次処理
　↓
　↓
取引先マスター　　納品（履歴）ファイル
　　↓　　　　　　　　　↓
（取引先）　　　　　（当月分の金額）
　　↓　　　　　　　　　↓
　　└────┬────┘
　　　　　　　↓
　　当月請求（作業）ファイル
　　↓
請求明細一覧チェックシート
　　↓
担当営業がチェック
　　├───────┐
　　↓　　　　　　　↓
Yes,請求書発行　　No,請求書発行
　　↓　　　　　　　↓
請求書発行　　　　破棄（担当営業のわがままでやり直し）
　　↓　　　　　　　↓
　保存　　　　　　※納品（履歴）ファイルの訂正作業が必要
　　↓
　　├─────────────┐
　　↓　　　　　　　　　　　　　↓
請求（履歴）ファイル　　納品（履歴）ファイルの請求済みフラグを立てる

チェックシートで動かぬ証拠を手に入れることが、正確な処理を進めるために良いと思います。


>>そうなると、未入金が発生すると、繰り越し請求などが発生するかもしれませんが大丈夫でですか？

私は立派なことを書いているように思われたかもしれませんが、
実は請求のアプリケーションは、製作を依頼されたことがないので作ったことがありません。

しかし、支払いのアプリケーションは製作を依頼されてので作っており、
これは桐のアプリではありませんが、現在まで１０年以上稼働しております。

支払いの場合には、過払いが生じたりするために支払いを調整することがあります。
といっても、依頼主にルールを聞いて仕様を決定したのはずいぶん昔ですので、細かいことは忘れてしまいました。
支払いが翌月へ繰り越す場合がありますが、この場合には仕入（履歴）ファイルに繰り越し伝票データを転記する必要があります。

したがって、請求の繰越云々に関してはワカリマセン。m(__)m

>アプリの目的は納品書と請求書と売掛台帳の印刷です。

それならば、「何とかで作る販売管理」と題した書籍を参考にされたらいかがでしょうか？
桐関係の書籍で無くとも、参考になるのではありませんか？
税理士さんや、システムハウスの人が書いた書籍が手にはいるのではないでしょうか？
全体の構成がわかれば十分ではないでしょうか。

これこそ、「普通の…」だとおもいますが…(^^ゞ


19606 問題が消滅しました。 しぼうかん 2003/03/24-19:15
記事番号19553へのコメント
まだ一部うまくいかない所がありますが、たぶん最初の投稿時の問題は解決しそうな気がします。
というか、最初の質問で問題にしていた[請求書番号]自体が無くなりそうです。

実はこの[請求書番号]をイベントで正しく入力する為にかなり時間と労力を掛けて計算式を考えたのですが、
ONnojiさんに指摘されるまで、まさか必要のない物だとは今の今まで気がつかなかったです。

どうしてこんな事に気がつかなかったのか、たぶん何か錯覚して「請求書は請求書番号で管理しなければならない」
みたいに思いこんでいたみたいです。

うまくいかないところはもう少しがんばってみます。

ONnojiさん、悲しげさん下手な説明へのお付き合いありがとうございました。

19679 問題が復活しました。 しぼうかん 2003/03/29-22:10
記事番号19606へのコメント

残念ながら[請求書番号]を無くす方法は無理だったみたいです。

もちろん教えていただいた事に問題があった訳ではなくて、私も気が付かなかったのですが、
請求書フォーム上ではグループ項目である[請求書番号]には納品書データをグループ化して
表示した請求書データを納品書データの並びと同じように並べ替える主キーの様な役割があったみたいです。

そこでグループ化されたフォームをグループ項目を使わないで納品書テーブルとほぼ同じ並びで
整列する方法を考えていましたが、桐の機能上の制限でグループ化されたフォームでは
グループ項目での並べ替え以外は無理みたいなので、
とりあえず[請求書番号]を使って表Ａ−２の方式でやることにしました。

19681 Re:問題が復活しました。 悲しげ 2003/03/29-23:30
記事番号19679へのコメント
どもっ、しぼうかんさん

>すが、請求書フォーム上ではグループ項目である[請求書番号]には納品書データをグル
>ープ化して表示した請求書データを納品書データの並びと同じように並べ替える主キー
>の様な役割があったみたいです。

と云うか、そもそもその役割のために[請求書番号]なるものを設けたのだと
私は想像していました。つーか、それ以外の目的は殆ど無かったと。

[請求書番号]の復活に賛成はしませんが、強烈に反対する気力もありませんので、
以下ちょいと参考になるかもしれないことを書きます。

[請求書番号]とは、正式な中味は忘れましたが、呼称にも関わらず、要するに

　　　[項目Ａ]＋[項目Ｂ]＋[項目Ｃ]＋[項目Ｄ]

のような感じだったと思います。
とすれば、これら数項目を（しかるべき順番で）フォームのヘッダ部にグループ項目として配置すれば、
[請求書番号]ひとつをグループ項目とした場合と全く同等の結果を得ることができると思います。
で、このようなフォームと一般的な（？）フォームとの２種類を用意して、
適材適所で使い分けるなんてのが、私としてはむしろ好みだったりします。

以上、私なりに理解した範囲で[請求書番号]を使わないで済ます一例です。
「表Ａ−２の方式」が何だったかも既に覚えてはおりませんが(^^;)。
19683 正しく意志を伝えるのは本当に難しいです。 しぼうかん 2003/03/30-18:29
記事番号19681へのコメント
悲しげさん、おそくまでご苦労様です。m(_ _)m


>[請求書番号]とは、正式な中味は忘れましたが、呼称にも関わらず、要するに
>
>　　　[項目Ａ]＋[項目Ｂ]＋[項目Ｃ]＋[項目Ｄ]
>
>のような感じだったと思います。


あれれ？また何かすれ違いがあるみたいです。

[請求書番号]とは[項目Ａ]＋[項目Ｂ]の様な物では無く、
最初のツリーのNO19553の表Ａ−１や下の表Ａ−４に有るように数値型の項目で他のどの項目の値も含みません。
ですから下記の表Ａ−４のように"あい社"のレコードの追加があった場合にグループ化された
請求書入力フォームに[請求書番号]のグループ項目が無いと[社名]や[締月]のグループ項目を
どう配置しても表Ａ−４の様には並びません。

※実際は１画面に１グループしか表示しないので画面上に"いい社"のレコードが表示されていて
フォームに作ってある"次のグループへ"というボタンをおしても"あい社"のグループへは移動しないという事です。

具体的にいうと[請求書番号]を作らずにグループ項目を[社名]優先で[社名]と[締月]を配置すると
並びがああ社３月→あい社３月→いい社４月の順になり、[締月]を優先にするとああ社３月→あい社３月→いい社４月の順になりますが、
本当は表Ａ−４の様な入力順にああ社３月→いい社４月→あい社３月の順に並んでほしいわけです。


表Ａ−４
請求書番号｜社名｜締月｜金額｜備考｜納品書番号｜
　　　１００１｜ああ｜３月｜１０｜　　｜１００１　｜
　　　１００１｜ああ｜３月｜２０｜　　｜１００２　｜
　　　１００３｜いい｜４月｜３０｜　　｜１００３　｜
　　　１００４｜あい｜３月｜１０｜　　｜１００４　｜

　　↑
この項目が[請求書番号]です


このツリーを見直して見るとNO19560の


＞「請求書番号」とは、その呼称とはウラハラに、要するに
＞[社名]＋[締月]のフラグ値のことのようですね。


この説明を自分の考えている[社名]＋[締月]によって一意に決まる値についての説明の事だと解釈して、
意志が通じているつもりになっていたのかもしれません。

自分の意志を正しく伝えたり、相手の言葉を正しく理解するのは本当にむずかしいです。

ただこの問題は今現在は納品書テーブルをグループ化した請求書フォームから請求書の印刷をしているために
納品書フォームと請求書フォームの並びが同じ様になる事が必要なのですが、
請求書の印刷を売掛台帳テーブルと対象表とする売掛台帳フォームから印刷するように
なれば消滅する問題だと思うので、あまり気にしないで行こうかなと思っています。

19685 読解を断念しました 悲しげ 2003/03/30-23:44
記事番号19683へのコメント
どもっ、しぼうかんさん

>[請求書番号]とは[項目Ａ]＋[項目Ｂ]の様な物では無く、

ちょっと書き方が不足してました。
[請求書番号]とは[項目Ａ]＋……＋[階層下の部署]＋……の＃フラグ値＃である、
と云い替えようと思います。
　※　だから、私のイメージでは、グループ項目は
　　　　[得意先コード]　[階層下部署名(またはコード)]　[締月]
　　　のような感じだったのです。
が、この間の私の読みが一貫して外れていたのなら、しぼうかんさんの仰る[請求書番号]は、
ついに理解不能な難解な概念であった（一種のブラックボックス）と
＃過去形＃で語ることにします。(^^;)

19687 手段が目標や目的とすり替えられてしまったような ONnoji 2003/03/31-12:50
記事番号19683へのコメント
しぼうかんさんは No.19679「問題が復活しました。」で書きました。
>残念ながら[請求書番号]を無くす方法は無理だったみたいです。
>
>もちろん教えていただいた事に問題があった訳ではなくて、私も気が付かなかったので
>すが、請求書フォーム上ではグループ項目である[請求書番号]には納品書データをグル
>ープ化して表示した請求書データを納品書データの並びと同じように並べ替えるキー
>の様な役割があったみたいです。

しぼうかんさんは No.19683「正しく意志を伝えるのは本当に難しいです。」で書きました。
>ただこの問題は今現在は納品書テーブルをグループ化した請求書フォームから請求書の印刷
>をしているために納品書フォームと請求書フォームの並びが同じ様になる事が必要なのです
>が、請求書の印刷を売掛台帳テーブルと対象表とする売掛台帳フォームから印刷するように
>なれば消滅する問題だと思うので、あまり気にしないで行こうかなと思っています。

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

アレ！、まだ続いていたのですか。

すれ違いの原因は…
現行の処理のために必要だったというわけですね。
しかし、将来は処理形態を変更するので、不用になるということなのでしょうね。(^^ゞ

グループ化フォームのための手段が目標や目的とすり替えられてしまったようですね。
将来的には現行の手段を変更するほうが望ましいと思いますです。

私には今までの経緯がやっと理解できたようです。

それでは、失礼します。…(@^^)/~~~
19688 悲しげさん、ONnojiさんどうもお世話になりました。 しぼうかん 2003/03/31-20:00
記事番号19683へのコメント
悲しげさん、ONnojiさんどうもお世話になりました。

今回せっかく何度も返答頂いたにもかかわらず、[請求書番号]についてうまく説明出来ず申し訳ありませんでした。


戻る