過去の桐井戸端ＢＢＳ　（桐ver.９）
29938 合計された入金額の振分けを各請求分に併合転記したい わが 2005/05/15-15:49
請求した未入金の把握の為に
例えば、Ａ社からの１度の入金は、他の受注の分まで合計されて入金されるので、
まず入金振分明細ＴＢＬを作って、合計入金額を、各請求分にわけてわかるよーにしました
それを受注一覧ＴＢＬの該当請求分に転記したいと思ったのです

受注一覧ＴＢＬに、伝票番号で照合して、分割入金を複写して、現未入金額を把握できるよーにしたいのです

振分名明細ＴＢＬから転記するのに、この併合して転記のやり方を教えて貰いたいです
よろしくお願いいたします

29953 入金額の振分けの転記と消込処理 佐田　守弘 2005/05/16-23:50
記事番号29938へのコメント
わがさん
この質問は、「１件の受注で請求書と入金が分割になる場合はどうすればいいのでしょうか-わが(5/13-01:10)No.29902」
と関連しているようなので、前スレッドも参考にしながらコメントします。

●分割請求の実態の確認
今回のコメントで
　>例えば、Ａ社からの１度の入金は、他の受注の分まで合計されて入金されるので、
　>まず入金振分明細ＴＢＬを作って、合計入金額を、各請求分にわけてわかるよーに
　>しました
と書かれているので、当月請求額通りに支払われていると言う前提で良いでしょうか。

もう少し詳しく言うなら、
(A)顧客の中には分割支払を要求して来る顧客がいるが、当月分として請求した額通りに毎月支払われている。
(B)ほとんどの顧客は上記(A)の通りであるが、中には例外的に請求額と異なる金額で支払って来るケースがある。
上記のケース(A)：「例外なしに請求書通りに振り込まれる」であれば構いませんが、
(B)の例外があると、その例外をどの様に処理するのかが、別の課題になります。
ここではケース(A)の前提で話を進めます。

●分割支払の請求書の表
前スレッドで吉川さんのコメントの中に、
　>表の構造は親を「注文書.tbl」子供を「注文明細.tbl」としております。
があります。
おそらく１件の注文で内容が複数件あると思うので、注文番号単位での受注情報を
注文書.tblで、その明細書を注文明細.tblとする必要があると思います。
これと同じで、請求についても１件の注文の請求を数箇月に分割請求するのだとしたら、
売上が立った段階で、請求も分割しておく必要があります。
つまり、「請求明細.tbl」を作り、注文番号と対応させて、何月にはいくらを請求するか
といった内容を記載した表を作っておきます。
そして、請求明細.tblに基づいて請求書を発行します。

●入金確認と消込処理
ここが今回質問のポイントです）
経理情報の上でどの様な処理をするかは、桐の問題ではなく、それぞれの会社の経理処理規定で定めるべき課題です。
桐でどの様の処理するかは、処理規定に基づいて処理プログラムを組むだけなので、
多分この質問にはコメントの付け様がないのかと思います。

わがさんの会社がどの様な規定になっているかどうかは分りませんので、
ここでは一般論的なケースでコメントします。

質問の冒頭の
　>まず入金振分明細ＴＢＬを作って、合計入金額を、各請求分にわけてわかるよーに
　>しました
から、合計入金額と請求明細の対応を手作業で取っている様なので、入金振分明細には、
請求明細番号が記入できていると思います。

であれば、請求明細番号を照合項目として、併合できます。
併合の仕方は、どの様な経理処理をするのかによって違います。単に入金済みマークを付けるなら、
併合で選択し、[入金済み]の項目に、済マークを付ければよいでしょう。
入金金額と入金日を記入するなら、それぞれの項目に金額と数字を置換で転記すればできます。
そして一般的には、入金確認をした請求明細データは、入金済み記録の表に
記入(追加書き出しないしは読み込み)した後、請求明細の表から抹消します。
（これもどういう経理処理をするかによって、決まる事です。）

●本当に併合が必要なのか
私はここに疑問をもっています。
入金振分明細.tblを作る段階で、入金額と請求明細を手作業で照合しながら、確認をしているのだろうと思います。
（このあたりはどうされているかは、私には見えません）
桐の上の処理で言えば、顧客名ないし番号と月度を入力して、当月度請求額を表示させる事は、さほど面倒ではありません。
表示された請求額と入金額が一致するなら、その請求に対する入金とみなして、その場で消込処理をする方が、
簡単な様な気がします。

佐田守弘(KS-00119)
29958 Re:入金額の振分けの転記と消込処理 わが 2005/05/17-01:22
記事番号29953へのコメント
佐田さん、こんばんは、ありがとーございます
下のスレッドとダブってしまったよーな感じになってごめんなさい

Ｂの例外のお客さんがいます（この１社だけなのですが、この１社が１番受注がくるのです

>「請求明細.tbl」を作り、注文番号と対応させて、何月にはいくらを請求するか
>といった内容を記載した表を作っておきます。
>そして、請求明細.tblに基づいて請求書を発行します。

注文明細と請求明細を一緒になって考えてました
小さな会社なので、内容は同じになると思うので、一緒に考えてもだいじょーぶかなって思ってますが、
まだ入ったばかりなので、その辺がよくわかってないので、すみません

>入金金額と入金日を記入するなら、それぞれの項目に金額と数字を置換で転記すれ
>ばできます。

入金振分けＴＢＬは、入力用と、転記してデータ保存用のマスターに分けてます
振分けＴＢＬのフォーム画面から転記用のコマンドボタンをつけて
受注ＴＢＬに自動転記が出来るよーにしたかったのです（同時に、振分けマスターにも転記）
それには、各伝票番号を同じにしてありますので、それを参照して金額や入金日を複写したかったのですが、
併合しながらの転記ができなかったのです
書き出しや読みこみの登録を併合でもするのでしょーか？？（どこでするのか見つかりませんでした

>●本当に併合が必要なのか
>私はここに疑問をもっています。

受注ＴＢＬに転記させ、親工事の各請求分の入金状況、未入金額の把握する一覧表を作れればなって思ったのです
振分けの明細の管理をしていないよーなので（走り書きみたいに相手から送られてくる支払明細に書いてあるだけなのです、
統一された伝票番号もないのです。。）
請求額との照合にその都度、支払明細を見なおしてって感じなので、分割入金があるとややこしくなってしまって。。
エクセルに入力して管理するなら、桐でいれておいたほーが、後々受注に関連つけられれば、
役にたつかなって思ったのですが

その工事に対しての請求状況、入金状況を知りたい人がいるのです
入ったばかりで、今回、１年分のを全部手作業でして大変だったので（愚痴です、すみません）
桐でもっとちゃんとできないかなって漠然と思っちゃったのです
29964 請求通りにし払われない例外 佐田　守弘 2005/05/17-23:07
記事番号29958へのコメント
わがさん
　>Ｂの例外のお客さんがいます（この１社だけなのですが、この１社が１番受注がくるのです
この例外があったら、前回書いたコメントは成り立ちません。
根本からの考え直しです。

ではどう考え直すのかですが、それは残念ながら私には分りません。
というのは、これは桐でどの様の処理するかといった桐の技術的な問題ではなくて、
その様なケースの場合、御社でどの様な処理をするかといった御社の内部の問題です。

そもそも請求額と支払額が一致しなければ、一体どの請求に対して支払われたかが分らないのではないでしょうか。
つまり例でいえば、
〔請求明細〕
　　工事Aの５月度分　　\34,000
　　工事Bの５月度分　　\68,000
　　工事Cの５月度分　　\25,000
　　合計請求額　　　　 \93,000
に対して、支払額が、\60,000だったとします。これはどの請求に対する支払として処理するのでしょうか。
おそらく支払側も、「請求は\90,000だけど、とりあえず\60,000で勘弁」という意識であって、
総額に対してそのうちの一部を支払っているのであって、
どの工事に対して支払っているかの意識がないだろうと思います。
ですから、請求と対応しての消込処理のしようがありません。

だから、御社ではどういう扱いとするのかが分らないと、桐でどの様にするかのコメントをする事ができません。
思いつき的には、どんぶり勘定方式とでもいうか、その場しのぎの処理方法はいくつか考えられます。
しかし仮にその様な事を考えてアドバイスしても、「それはうちのやり方に合わない」という結果になる事は目に見えております。

●桐でできる事
　>桐でもっとちゃんとできないかなって漠然と思っちゃったのです
桐でできる事は、処理方法が決まっている事です。処理方法が決まってない例外処理は、
人間系でその都度考えて処理しないと処理のしようがありません。
もちろん例外でも例外処理の方法が分れば、処理は可能です。残念ながら今までの質問文には
そう言った事が書いてないので、私にはそれ以上たち入れません。

●桐で考える以前に必要な業務分析
この種の質問には以前から、SE業務の前にSA(システム分析)が必要であるという事を述べて来ました。これと同じ意味です。
現在の業務のしかたがどのようになっていて、どこかに問題がないか、それを徹底的に洗い出し、改善すべきは改善します。
いろいろな考えはあるでしょうが、例外処理は可能な限り除外する。その上でどうしても避けられない例外処理は
どの様に処理すべきかの業務フローを構築する。
これがあって初めて、桐で処理方法を作れます。
おそらくそういったものはあるのかと思いますが、そういった処理の全体像が見える業務フローの把握なしには、
桐でどの様に処理するかといった技術アドバイスは難しいと思います。

佐田守弘(KS-00119)

29968 Re:請求通りにし払われない例外 わが 2005/05/18-00:37
記事番号29964へのコメント
こんばんはー　

Ａ工事請求合計額３００円に対して、
　　Ａ①請求１００円、Ａ②請求１５０円、Ａ③請求５０円

Ｂ工事請求合計額２００円に対して、
　　　Ｂ①請求８０円、Ｂ②請求９０円、Ｂ③請求３０円　とした場合

入金が　Ａ＋Ｂ＝１８０円（Ａ①とＢ①分）だとします
　　　　　　　（どの工事の分かは、支払明細がくるので大体はわかるのです

入金振分明細ＴＢＬで、入金日2/2 入金額１８０　　Ａ①１００　　Ｂ①８０　とします

そして 　　　　　工事名　請求番号　入金額　入金日
大元になる受注ＴＢＬに　Ａ工事　　Ａ①　　　１００　2/2
　　　　　　　　　　　　Ｂ工事　　Ｂ①　　　　８０　2/2 　と併合して転記したいのです

請求を３回にわけて請求するので、その請求書を発行するのに、べつに請求明細ＴＢＬも作りました
請求明細ＴＢＬからその内容を受注ＴＢＬに転記します

伝票番号（請求番号）統一してあります

できないのは、入金振分明細ＴＢＬから受注ＴＢＬに、
伝票番号で照合して必要な項目を各工事別の項目に転記したいのですが、

コマンドボタンで併合して転記をしたいのですが、可能でしょーか？？

29988 Re:自分だったらこうするかな？ 宮城 2005/05/19-08:11
記事番号29938へのコメント
わがさん、こんぬつは。

これって、佐田さんも指摘していますが、「併合して転記」すればすむ問題ではなくて、業務設計そのものですよ。
「併合して転記」ってどんなイメージもってますか？

自分ならこんな具合に処理するところです。

構えるファイルは三つ。

「入金」：必須項目（以下同様）[伝票番号][入金額][入金年月日]
「入金残」：[請求金額][入金済み額][今回入金額][入金年月日][入金残]
　　　　　　[入金完了フラグ]
「入金済み」：入金残に同じ。

[入金残]には項目計算式に[請求金額]-[入金済み額]-[今回入金額]と設定。
[入金完了フラグ]には
#条件選択（[入金残]=0，"完了"，[入金残]<0，"こらえてくれ"，1，""）

入金時、たぶんデータじゃなくって伝票がきて、入金データは手打ちですね。
このとき、「大体はわかる」とかじゃなくて（「だいたい」ではシステムにはならんのです。）、
しっかり請求伝票単位に割り振って入力してもらわないといけません。

それでもって入金データを1件ずつあるだけ以下のように処理。

「入金残」と[伝票番号]照合で併合絞り込み。1件絞り込み以外処理即中止。

ここでお待ちかね[伝票番号]照合で[入金額]を[今回入金額]に併合複写。
（私の趣味では）「入金済み」に書き出すんじゃなくて編集表切り替えて
「読み込み」。「入金残」に戻って[入金完了フラグ]="完了"なら当該レコード削除。"こらえてくれ"なら処理即中止。""ならそのまま。

ここまで中止にならずにこれたら「入金残」絞り込み解除。「入金」データに戻って当該レコード削除、次のレコードへ。

たいしたステップ数じゃないでしょうが、kevでもcmdでも、表操作で一連を完璧に処理できなければ無理です。

条件判定が入っていますので、「履歴」だけではできません。

# 個人的見解ですが、公開の場でまじめな議論をしたいときに大の大人が「こんぬつは」みたいなことを書いちゃ人格が疑われますぞ。

29991 Re:自分だったらこうするかな？ 宮城 2005/05/19-13:29
記事番号29988へのコメント
>ここまで中止にならずにこれたら「入金残」絞り込み解除。「入金」データに
>戻って当該レコード削除、次のレコードへ。

「入金」データレコード削除はちと乱暴。フラグ項目追加して"振当済"フラグたてて、
この処理入る前に"振当済"でないものに絞って処理ってとこでしょう。

29993 分割支払の具体的内容と意味 佐田　守弘 2005/05/19-22:07
記事番号29968へのコメント
わがさん
いろいろと例示的に書かれておられますが、表題にも書いた分割支払の具体的な意味と、
その内容について、今以て完全には理解できておりません。というか、私が最も知りたい点について
はっきりと書かれていないという意味です。
その最も知りたいという点は、どの様に仕分処理をするかの設計の根幹に関わる部分です。

私が確認している意図が伝わっていない様にも思えるので、より具体的にお尋ねします。
1)全ての取り引きが分割支払なのでしょうか。一括支払もあるとしたら、どちらが多いのでしょうか。
2)分割支払の場合ですが、予めその振分けが決まってるのでしょうか。
どうやら工事代金に関わる請求の様ですが、工事の場合、着工時1/3、中間時1/3、そして検修時に残金といった支払をするケースを聞いています。
分割支払と言っても、支払計画があって、計画通りに支払われるなら、請求明細の中で、
予め計画通りに１件の受注を３つに分けておけば、通常の入金と消込処理でできる話です。
3)問題のケースは請求額と異なる入金なのでしょうか。
#29964で、
　>Ｂの例外のお客さんがいます
と書かれていますが、このお客は請求額と異なる額で勝手に振り込んで来るのでしょうか。

この点が分らないとどうしても前に進めません。

佐田守弘(KS-00119)
29994 １つの方法として 佐田　守弘 2005/05/19-22:38
記事番号29991へのコメント
宮城さん

実は私も、最終的な手段としてほぼ同様のイメージを構築しておりました。
名付けて「どんぶり勘定方式」です。いえ、このどんぶり勘定とは世間で言ういい加減な勘定と言う意味ではなくて、
丁度、天丼やうな丼の様に、何もかも１つにまとめてあると言う意味です。
（語源かもしれないけど）

●私のどんぶり勘定方式
宮城さんの方法と少しだけ違う点として言えば、受注マスタに請求額とは別に
残額の項目を作ります。そしてこの受注マスタで入金状態を管理するわけです。
残額の初期値は請求額と同じです。

この方式の場合、減算の併合で残額を計算する事はできるでしょうけど、
何か二重手間をしている様な気がします。
支払は顧客別にまとめられて入金される事から考えると、顧客でグループ化した
メイン&サブフォームに、未入金の受注一覧(工事件名毎の残額と総額を表示)と、
入金額の両方を表示し、どの請求に振分けるかを見ながら、コマンドボタンを使って、
振分けと入金処理をして行けば目視確認しながらの振分けができ、
結果として工事別の入金リストや、入金後の残金リストも自動で作れる様な気がしているのですが。

但し、イベントを使わないとできないので、その点が面倒なのかも知れませんね。

●同感
　># 個人的見解ですが、公開の場でまじめな議論をしたいときに大の大人が「こ
　># んぬつは」みたいなことを書いちゃ人格が疑われますぞ。

実社会でも言葉づかいは、人格を見る貴重な判断材料です。
ましてはここは、言葉だけで論議するBBSの世界ですね。判断材料は書かれている文章しかありません。
言葉づかいや言い回し、いかに問題点を的確に表現して質問しているか。
また、こちらの確認の意図をどれだけ分っているのかといった積み重ねで、
どんな人なのかといった判断をせざるを得ませんでしょうね。

佐田守弘(KS-00119)
29996 Re:自分だったらこうするかな？ 宮城 2005/05/20-21:11
記事番号29991へのコメント
一部処理抜けてたので書き直しておきます。

＊＊＊＊＊＊＊＊＊＊＊＊ここから*＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

構えるファイルは三つ。

「入金」：必須項目（以下同様）[伝票番号][入金額][入金年月日][振り当
　　　　　　　　　　　　　　　て完了フラグ]
「入金残」：[請求金額][入金済み額][今回入金額][入金年月日][入金残]
　　　　　　[入金完了フラグ]
「入金済み」：入金残に同じ。

[入金残]には項目計算式に[請求金額]-[入金済み額]-[今回入金額]と設定。
[入金完了フラグ]には
#条件選択（[入金残]=0，"完了"，[入金残]<0，"こらえてくれ"，1，""）

入金時、たぶんデータじゃなくって伝票がきて、入金データは手打ちですね。
しっかり請求伝票単位に割り振って入力してもらわないといけません。

それでもって入金データを[振り当て完了フラグ]＝""で絞り込み、1件ずつあるだけ以下のように処理。

「入金残」と[伝票番号]照合で併合絞り込み。1件絞り込み以外処理即中止。

ここでお待ちかね[伝票番号]照合で[入金額]を[今回入金額]に併合複写。
（私の趣味では）「入金済み」に書き出すんじゃなくて編集表切り替えて「読み込み」。
「入金残」に戻って[入金済み額]に[今回入金額]を加算し
その後[今回入金額]0置換。[入金完了フラグ]の値により、"完了"なら当該
レコード削除。"こらえてくれ"なら処理即中止。""ならそのまま。

ここまで中止にならずにこれたら「入金残」絞り込み解除。「入金」データに戻って[振り当て完了フラグ]＝"振当済"更新。次のレコードへ。

＊＊＊＊＊＊＊＊＊＊＊＊ここまで*＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

さらにこういうことやってると「つきもの」がありまして、済み分にさかのぼ
る数量変更処理。そこまで戻して処理をやり直すしかありません。

# ほどよい甘みのよくできた親子丼をもって最上。おなかすきました。(^^;;


29998 Re:１つの方法として わが 2005/05/20-21:52
記事番号29994へのコメント
佐田さん、こんばんはー
どーもありがとーございます
イベントとメイン＆サブフォームをまだやった事がないので
お返事を参考にしながらいじくってみます

私の書き方がわかりにくくて、何度もご迷惑おかけしました
まだ体験版なので、マニュアルがないのです
来週には届くとおもうので、それ見てやってみます
　
またよろしくです
29999 Re:自分だったらこうするかな？ わが 2005/05/20-22:00
記事番号29996へのコメント
とっても丁寧に教えてくれて、ありがとーです

教えてもらったファイル３つで作ってみます
佐田さんにも教えてもらったのも参考にしながら、メインサブフォームとイベント勉強してからまた来ます

併合複写のやり方がわからなくて、
これって、コマンドで指示できないでしょーか？？

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

私の書き方変でした？？
真面目に書いたつもりだったのですが、不快におもったらごめんなさい

今日のご飯は、うちも丼でした（天玉子丼でっす）
玉子多めで、タマネギが重要な脇役で、ちょっと甘めがおいしーですよね（≧∇≦）


30000 Re:分割支払の具体的内容と意味 わが 2005/05/21-00:14
記事番号29993へのコメント
>　>Ｂの例外のお客さんがいます
>と書かれていますが、このお客は請求額と異なる額で勝手に振り込んで来るのでしょうか。

すみません、見逃してました
このお客さんは、他の工事代金と合算して振り込んできます
相殺が有る時は相殺もしてきます
請求額は相殺の分は計上しないで請求してますので、請求額と違ってきます

上司は、振りこまれた額が、どれとどれの請求分か、相殺はどの相殺がどの工事分か
把握しておきたいので、入金状況の経過等がわかるよーな一覧表を作成したいのです
30005 Re:分割支払の具体的内容と意味 佐田　守弘 2005/05/22-10:54
記事番号30000へのコメント
わがさん
　>このお客さんは、他の工事代金と合算して振り込んできます
　>相殺が有る時は相殺もしてきます
　>請求額は相殺の分は計上しないで請求してますので、請求額と違ってきますという事は、
他のお客さんは注文通りに請求して、請求通りに支払って来るのに対して、
このお客さんのみが、通常とは異なる請求と支払になっているという事ですね。

ご希望はこの消込処理を併合の処理で行う方法とし、併合の実行をコマンドボタンで行いたいとの事ですが、

①コマンドボタンでの併合操作
コマンドボタンで併合操作を行う事は原則的に可能です。併合条件を登録しておき、
機能名に併合、パラメータに併合条件を指定すれば可能なはずです。

②どの様に併合するのか
冒頭に書いた様に全く異なる処理を一緒に行うわけですから、併合で一気に消込が行えるのかどうか、その点が大変に不明です。
私としてはこの様なケースで併合で処理できるのかどうかが、そもそも不明です。
具体的にどの様に併合するのかとか、結果が期待通りにならない原因は何かと聞かれても、それ以上答えようがありません。

もしどうしても行うなら、
　「１つの方法として-佐田　守弘(5/19-22:38)No.29994」
に書いた方法を参考にして下さい。
この方法は、請求額の他に請求残額の項目を設けて、請求残額に対して支払表に
作った入金額を減算する併合を行う事になります。多分この方法しかないでしょう。

しかしながらそもそもこの処理は、思い付き的なアイデアであって、桐の処理としては成り立つ方法であっても、
わがサンのケースで果たして使えるのかどうかが分りません。このため、直接的なコメントとして書くのを控えておりました。

なお、この場合、一般のお客さんも冒頭の「このお客さん」と同様に、請求とは異なる支払をして来るという前提での処理になります。

●支払状況の報告書
　>上司は、振りこまれた額が、どれとどれの請求分か、相殺はどの相殺がどの工事分か
　>把握しておきたいので、入金状況の経過等がわかるよーな一覧表を作成したいのです
前から書いている様に、メイン&サブフォーム上で支払表と請求明細表を表示しながら
確認ボタンを押して行く、あるいは一部支払の金額を入れて行くといった方法こそがこの目的に合致する方法だと思います。
そしてその操作に応じて、支払結果を別表に書き出して行けば、入金状況の経過等の一覧表を作れます。
もちろんイベントを使う必要がありますが、むしろこの方法で考えるのが適切なのではと考えています。

佐田守弘(KS-00119)
30007 宮城さん、佐田さん わが 2005/05/22-12:37
記事番号29938へのコメント
どーもありがとーございました
コマンドで併合のやり方わかりました　やってみます

宮城さんと佐田さんや、下のスレッドの吉川さんやしぼうかんさんのこれまでの教えを、
「わが桐お勉強用」に移して、会社でそれ読みながらじっくり作ってみます

おかげさまで初挑戦のレポートは克服しましたー

イベント・結合表・メインサブ等、すべて初挑戦のがまだ残っていますので、
簡単なフォームと表だけの知識しかない私には、ちょっと時間がかかりそーです
でも、一通りチャレンジしてきます

また、ちょこまか質問すると思いますが（何を聞きたいのかもっとわかりやすく気をつけます）その時はまたどーぞよろしくお願いいたします

戻る