< | >

If then構文、効率的な仕分けモデルを描く
  • (2011-11-30 05:29:55)


vbaで条件分岐する際、if then構文は必須。よく使うのに分岐条件が複雑になると、自分の場合、混乱してくる。

複雑な条件分岐



きょう書いた条件文はこれ。配送方法と決済方法によってプレゼント対象になるかどうかのチェックプログラム:

第1条件のパラメータ(配送方法):

・宅急便

・コレクト

・メール便

・メール便送達

第2条件のパラメータ(支払い方法):

・カード決済

・銀行振込

・コンビニ決済

・代引き

第3条件のパラメータ(プレゼント希望の有無):

・希望

・不要

第1条件それぞれに対して第2条件・第3条件が分岐するので、理論的には32種類の条件がある。

elseifを使い、ベタにすべての条件式を書く



単純には「32種類の条件文」を書く。きょうは32種類で済んだので、まだ書けないことはないが、やがて首が回らなくなるモデル。

・3種類のパラメータは条件組み合わせは「And」でつなぐ。

・if thenは平階層で、elseifでつなげていく。

if thenの入れ子で、階層化する



プレゼント不要の方は何のチェックも必要ないので、第1階層に「プレゼント有無」を当てることで、条件分岐は16種類に減る。

支払い方法と配送方法は同じ結果になるものをグループ化するとそれぞれ3種類と2種類。3x2=6種類の条件分岐となる。

これらもif thenの入れ子で多重に階層化すると現実的なプログラムになった。

効率的な仕分けモデルを頭の中で描けるか



if thenの使い方というより、その前に複雑な条件をいかにグループ分けして、わかりやすい階層化を頭の中で作るかが今日の反省。

簡単で単純な分岐、たとえばYES/NOの条件で全体に影響を及ぼす(今日のプログラムではプレゼント有無)大きなパラメータの分岐から階層化していくことが原則か。

最後のElseを忘れない



自分のような未熟なプログラムマがよくやる失敗はElseifでつないできた条件文の最後で「Else」を落とさないこと。

常に記述された条件に合わない「何か」がプログラムには起こるリスクがある。

プログラムから見れば「想定外の条件」となる。想定外の条件が来たときの挙動を決めておかないと大事なところでビジネスが破綻する。

「想定外の条件」をコードに落とすクセが自分にはまだ身についていない。






< | >

携帯電話へHTMLメールを送るテスト
  • (2011-11-29 04:29:00)

携帯電話へのHTMLメールは時期尚早?



同報DMはテキストからHTMLメールへではHTMLメールの時代かな?という気持ちを書いた。

しかし、相手が携帯電話となるとどうだろうか?ここでは自分のケータイ(Panasonic 840P/SoftBank)、もしくは知人のケータイでテストした狭い範囲のテスト結果を書く。

ケータイに画像を送る発想の是非



パケット従量制のユーザも多いので、画像をむらみやたら送りつけたり、画像リンクを付けるのは御法度(自分のケータイでは画像のリモートリンクは無視される)。

従量制ユーザはそもそも携帯電話での画像表示は「画像off」に設定している人も少なくない。画像を見させようとする発想自体、ケータイ文化とはソリが合わない。

それとも、定量制のユーザが、今は普通なのだろうか?悩ましい。

携帯のHTMLメールはレイアウトや色使いのために使用



テスト不足で断言はできないが、自分が持っている機種ではHTMLメールを表示できる。

現在、携帯電話は多くの機種でHTMLメールを基本的に表示できるようだ。

しかし、もしHTMLメールを送るなら、考え方として、画像は使わずに「レイアウトや色使いを組むためのHTMLメール」と考える方がよいかもしれない。

HTMLメールの画像の取扱



自分のケータイでは画像を送ると「添付ファイル」となりメール画面では別表示される。画像事に個別に開いていく方式になっている。

また、リモートリンクの画像はリンクが落とされてリアルタイムに画像を読み出すことはできない。

携帯電話への一斉同報はリーチ率が低い



携帯メールは携帯電話キャリア以外のドメインからのメールをデフォルトでフィルタリングされる傾向にある。

よって、携帯電話では一斉同報メールのリーチ率は低い。しかも、現状ドコモ以外、フィルタリングされたことを送信者に通知(エラーメッセージの返信)さえしてくれない。

携帯電話はメールに含まれるリンクでもフィルタリング



携帯電話会社によってはリンク(<a href="・・・></a>)があるメールはデフォルトでフィルタリングしているため、PCに比較するとユーザへのリーチ率はかなり落ちると思われる。

携帯電話へのメールの注意点



・画像サイズ:画像を送るなら、携帯電話画面サイズがQVGA320x240が多いことを配慮して、240ピクセル以内がよい。

・1行の文字数:昔は「全角8字」という時代もあった。今は全角16字くらいが多いか。ユーザの設定によって細かいフォントで見る人もいるし、巨大フォントを好む人もいるので、なんとも一般化しにくいが、改行が多いとかなり読みにくく醜い。文節が終わるまで改行なしにし、改行する際は1行開ける。ハイフンの連続や横線は全角16字以内に納める。

スマートフォンへのHTMLメール



使用したことがないので、不明。いつの日か。






< | >

同報DMはテキストからHTMLメールへ? 作り方と送信方法
  • (2011-11-27 13:07:57)
DMメールを送る際、プレインテキストかビジュアル的にインパクトがあるHTMLか、未だ悩ました(2011/11/27 小平探検隊)

HTMLメールの普及度



HTMLメールは一斉同報DM、おしらせやメルマガの主流になりつつあるのか?

自分のメールアカウントにやってくるこの種のメールはHTMLメールが主流になりつつある印象を受ける。

海外ベンダーは概ね、HTMLメールに移行した感がある。

海外ベンダーのHTMLメール事例



Googleアラートは画像なしのHTMLメール。

Facebookも画像なしのHTMLメールか、「『いいね!』と言っています」メールはいいね!の本人のプロフィール写真を添付(正確にはリンク画像)したHTMLメール

(プロフィールに個人写真をアップしている人は自分の写真がFacebookによって世界中に拡散されているので嫌な人は気をつけたい)。

Amazonは広告用にはHTMLメールを主体とし、注文明細などはプレインなテキストメールになているが、ときどき変化しているようだ。試行錯誤中らしい。

GodaddyやNetworkSolutionsなどは完全にHTMLメール。PayPalもHTMLメール。

日本企業のHTMLメール事例



一方日本のベンダー。日本で、HTMLメールを昔から流しているのは楽天。ド派手なHTMLメールはドンキ風。悪趣味なデザインが際立っている。

最近、もらったJNBやmixiからのメールはHTMLメールだった。以前はプレインテキストだったように記憶しているので方針変換したのだろう。

しかし、2011年暮れ現在、日本のメールDMはまだまだテキストメールが圧倒的に主流だ。

HTMLメール採用の判断



日本でのHTMLメール普及度はおそらく消費者のHTMLメールに対するイメージの影響も大きい。ネット・リテラシーの高いユーザは昔から、HTMLメールを嫌う傾向にあるし、そういう文化がインターネットにはまだ根強い。

しかし、一般に公開されているアンケート結果を見るとテキストメールが好ましいと感じるユーザは25%程度で、あとはHTMLメールでもよいか、少なくとも毛嫌いしている人々ではない。

またそのテキスト派25%の中でも「毛嫌い」してHTMLメールに悪い印象を抱く層となると、その10%もいないだろうから、25%の10%で、全ユーザーの2.5%程度の人には「HTMLメールを送って逆効果」ということになるのではなかろうか。

HTMLメールがもたらすビジュアル的なインパクトと、企業イメージを損失する比率を計量すると、HTMLメールDMに移行する企業は今後増加傾向に向かうだろう。

HTMLメールの作成の基本



通常のHTMLページ制作と同じながら、ユーザ側のメールソフトの多様性を考慮して、ごく基本的なHTMLにすること(たとえば、レイアウトは<table>タグだけで作る)。

シンプルなHTMLを作成するためにHTML作成ソフトなどはむしろ有害。試しにホームページビルダーを使用してみたが、ベンツで近所のコンビニに買い物に行く感じだった。

また、このHTMLページを公開するために、HTMLメールとは微妙に内容を変えたHTMLページも必要になる。文字コードの問題や、リンク先のhttp://・・の明示的な表示など。

HTMLメールのもっとも簡単な作成方法は自分宛にきた秀逸なHTMLメールを参考に改編すればすよい。

海外の一斉同報ソフトには優れたHTMLメールテンプレートがてんこ盛りされているので、これらを改変すると案外簡単に作成できる(かもしれない。試していない)。

HTMLメールの作り方、5つの方法



(1) HTMLメールで使用するHTMLタグはごくわずか。HTML作成ソフトなど使わず、手書きで書く。

(2) meta部分はキャラクター設定の文字コード指定をISO-2022-JPにする

   ※注意:(Web公開用はShift-JISやUTF-8に。ISO-2022-JPで作成したテキストファイルをwebにアップしてもファイル自体JISとなりエラーとなった。Shift-JISならファイル自体もShift-JISにする)。

(HTMLページ例)

<HTML>

<head>

<meta http-equiv="Content-Type" content="text/HTML; charset=ISO-2022-JP">

<meta http-equiv="content-style-type" content="text/css">

<title>おしらせ</title>

<style type="text/css">

<!--

.txt10 { font-size: 10px; color:#333333; line-height: 1.3; }

.txt11 { font-size: 11px; color:#cccccc; line-height: 1.6; }

-->

</style>

</head>

(3) CSSは外部ファイルでなく、すべて埋め込み。複雑なCSSは使用しない。

(4) レイアウトの基本は<table>タグのみ。

(5) 画像は外部サーバに置き、フルパス指定(送信するときも画像は添付しないこと)。サイズ指定(<width><height>)もした方が安全。

(番外) よけいなコードは書かない。よけいなコードは仮にエスケープやコメントアウトしていてもメールソフトによって誤作動のモトになる。

HTMLメール、メールソフトと設定による挙動の違い



これだけシンプルに作成しても、HTMLメールは受け取る人のメールソフトやその環境・設定によって表示のされ方がかなり違う。表示されないソフトもあるし、表示されないよう設定している人も多い。

・Outlook Express:デフォルトで表示(ただし、画像は表示せず)。「画像がブロックされています。ここをクリック」で表示

・Thunderbird:デフォルトで表示せず。「リモートコンテンツを表示」で表示

・Becky! デフォルトで表示せず。設定(「全般的な設定」-「メール表示」-「HTMLメールの表示」)で表示

・Yahooメール:デフォルトで表示(ただし、若干レイアウト崩れ、背景色の飛び)

・gmail:デフォルトで画像表示せず(画像表示ボタンがあるが押しても表示せず)

・Windows Live メール:Outlook Expressと同じ。

・秀丸メール:デフォルトで表示せず。自動表示の設定もなく添付ファイルをダブルクリックでブラウザによって表示。

メールソフトによるHTMLメールの作成&送信方法



送信用ソフトは試したものはOutlookとThunderbird。

Outlook、HTMLメール作成&送信方法



正確には「Outlook Express」。HTMLページを作成して、そのコードをコピー&ペイストする方法とテンプレートとして取り込む方法がある。

●テンプレートの取り込みとしてHTMLメール作成:

あらかじめHTMLページを準備しておく。

・「メールの作成」-「ひな形の選択」テンプレートとしてHTMLメールファイルを選択

●新規にHTMLメール作成:

・「メールの作成」-「書式」-「リッチテキスト(html)」-本文の下に「編集」「ソース」「プレビュー」のタブが出るので、「ソース」を選びペイスト

※画像を添付せずに送る方法:

・「書式」-「メッセージに画像を添付」のチェックをはずす。

※送信はHTMLとテキストのマルチパート方式。テキストはHTMLメールのソースからタグをそぎ落として生成している模様。

Thunderbird、HTMLメール作成&送信方法



・「作成」-本文で「挿入」-「HTML」-HTMLメールの内容をペイスト-「オプション」-「送信形式」-「HTMLとテキスト」

※画像を添付せずに送る方法:

画像を個別に選んで「挿入」-「画像」-「この画像をメッセージに添付する」のチェックをはずす。画像を添付せずに送る方法が面倒だ。

※送信は「HTMLのみ」or「テキスト」or「HTMLとテキスト」選択できる。

一斉同報ソフトによるHTMLメール送信「同報@メール5」



検索すると数社の同報メールソフトがでてくるが、HTMLメールに対応しているものもその性能はいろいろ。

有料ソフトでも、とても使い物にならないレベルの製品もあった。嘆いても仕方ない。個人は優秀なのにソフト開発会社の製品は目を覆いたくなるような製品が多いのは日本の社会的な問題だ。

下記は「HTMLメールの作成・編集・送信」部分のみの評価。ユーザーリストの作成やメンテナンス性、自動登録・自動削除などの機能性は不問。

【国内の同報メールソフト】

・同報@メール5:HTMLメールの編集も送信もしやすい。※編集は「HTMLパート」「テキストパート」と別れており「HTMLとテキスト」両方を送りたいか「HTMLだけ」かを選択できる点がよい。

・Mail Distributor:フリーソフトながら、一斉同報ソフトとして個人的に最も高い評価をしているソフトだが、残念ながらHTMLメールには対応していない。

一斉同報ソフトによるHTMLメール送信 海外の製品



【海外の同報メールソフト】

そもそも「同報メール」を英語で何というか知らないので検索は苦しかった。クリクリやっているうちに出てきた下記の「email Marketing」ソフトあたりがそれだろうか。

http://www.mobilserver.com/email-marketing/email-marketing-reviews.sHTML

試行錯誤の結果、次のようなワードをキーワードとして検索するとゾロゾロでてくることがわかった。

・bulk mailer

・mass mailer

・personalised email

・mailing list

・newsletter publishing

・subscription manager

今日は下記のソフトをトライアルしてみた:

一斉同報ソフトによるHTMLメール送信「KMailer」



非常に多機能。SMTPサーバをいくらでも設定できるところを見ると相当凄いバルクメールの発行を想定している模様。製品説明も文字通り「Bulk Email Software」。

ユーザリストの作成はデータベースとのダイレクトな連携(ODBC?)も想定されている。

HTMLメールは編集しやすく送信しやすい。こなれたソフト。HTMLメールのテンプレートが充実。エンタープライズ版でも2万円弱でお値打ちだが、残念、日本語が文字化けを起こす。

一斉同報ソフトによるHTMLメール送信「1st Mass Mailer」



KMailerよりライトなソフト。非常に使いやすく、送信用メールのタイトルが文字化けする(Fromパートに日本語が使えないなど)が、日本語でも基本的にOK。

HTMLメールは編集しやすく送信しやすい。送信速度も速い。69ドル。今回これを購入。

※HTMLメール作成・送信機能あり。

※送信は「HTMLのみ」か「テキストのみ」。「HTMLとテキスト」は選択できない。

※残念ながら送信ログが残らない。

※アドレス帳などのデータや設定は\My Document\1st Mass Mailer に生成される。

HTMLメール、無駄なコードは書かない:Thunderbirdの場合



HTMLメールを制作の際、HTMLページとしても活用するため、<head>部分を下記のようなコードにしていた。

<!-- <meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS"> -->

<meta http-equiv="Content-Type" content="text/html; charset=ISO-2022-JP">

当然、受信用のメールソフトはShift_JISはエスケープしてISO-2022-JPをエンコードの文字コードとして採用されると考えていたが、Thunderbirdはコメントアウトの<!-- -->が効かないらしい。受信メールが文字化けになる。

他のテストしたメールソフトはすべて効いていたが、こういうこともあるので、無駄なコードはHTMLメール中に残さない方が無難である。

HTMLメールとテキストメールの同時送信(マルチパート)



HTMLメール作成可能なメールソフトはHTMLメールを作成するとテキストメールを自動的に生成してマルチパート化して送信するソフトが多い。

生成方法はHTMLタグをすべてそぎ落としテキストパートとして出力しHTMLメールと一緒に送信しているようだ。Outlook Expressがそれで、Thunderbirdは選択できる。

さらに同報@5は自動生成にプラスして個別にテキストパートを編集して送信する機能が付いている。HTMLパートとテキストパートを別々にしたい送信者には重宝だろう。

1st Mass Mailerはマルチパートタイプでない。HTMLメール or テキストメール。

送信オプションは「HTMLのみ」か?or「HTMLとテキスト」か?



HTMLメールを読めないメールソフトを使用しているユーザを考慮すれば、「HTMLとテキスト」がよいと思われがち。

しかし、考えてみれば、携帯電話を除けば(現状、ケータイも表示可能な機種が大半)、今時、HTMLメールを表示できないメールは見たことがない。

表示しない設定にしている人はいるが、その気になれば、ワンクリックで見ることができるメールソフトがほとんど。

圧倒的なユーザ数のOutlookやgmail・yahooなども画像がデフォルトで出ないにしても基本的にレイアウトはHTML出力でHTMLメールを表示する。

また、Beckyは「HTMLとテキスト」の場合、デフォルトではテキスト優先で表示するが、もし「HTMLのみ」のメールを受信したら、Beckyも最初からHTMLメールを表示する。

中途半端なテキストがくるより・・・か?



「HTMLとテキスト」送信で、最初にテキストパートが表示されるとき、クライアント側ではどうしても中途半端なテキストになる。

つまり、「中途半端な読めないことはないメール」が来ることになる。

どちらがいいか?

海外の人々はバッサリと「HTMLのみ」の人も多い。送信者のポリシーの問題。

大企業さんの場合、テキストパートとHTMLパートを個別に編集して、テキストパートに「HTML形式のメールです。正しく表示しない方はこちら」といった感じのところも多い。

しかし、相当のメリットやロイヤルティの高い場合を除き、数ある広告メールの中で、わざわざURLをクリックするユーザはいない。

私はそろそろ「HTMLのみ」でいいのではないかと感じている。

「HTMLのみ」で仮に読めない場合でも、顧客が自ら崩れた文章に残されたURLをクリックしたくなるくらい顧客にとって価値あるメールを毎回流すべきだし、クリックしたくなるほどロイヤルティを感じる企業に自ら成長することの方がはるかに重要だ。






< | >

秀丸マクロ 選択範囲内での検索 inselect
  • (2011-11-20 06:13:05)


「三菱東京UFJ Bizステーション取引明細の弥生会計インポート整形用マクロ」を作成している。今日覚えたマクロは「選択範囲内だけの検索」。

1行の中にある文字列があるかどうかの判定に使用した。

gofiletop;

selectline;

searchdown "カ)",inselect;

if (result==yes) { ・・・

といった感じ。






< | >

銀行明細データを弥生会計にインポートするプログラム
  • (2011-11-20 05:50:25)
2011/11/20

ムダに消耗する消込


銀行の取引明細は誰からの、そして、何の取引の振り込みか、ときとしてわからない。推量するしかない状況であり非効率的。多くの企業で「消込」は経理部スタッフの体力と労力をムダに消耗させる作業。

原因は銀行間送金データのフォーマットだろう。これだけ情報技術が進化しても銀行間送金データのフォーマットは半世紀前から進化できずにいる。

誰もが不満ながら、誰も動かせない。技術的な問題はではなく政治の話。メガバンクの経営者といえども権限不足のようだ。誰に権限があるのかな、誰も何もできない。これも日本の現状。


銀行取引明細を最小限労力で弥生会計にインポート


明細データをCSV形式でダウンロードし、整形して、そのまま弥生会計にインポートするプログラムを秀丸マクロで書いている。


弥生会計のインポートフォーマット



【弥生会計インポート項目】(「*印」は必須)

01 A * 識別フラッグ(伝票以外は2000)
2111 → 1行の伝票データ
2110 → 複数行の伝票データ(1行目)
2100 → (行間)
2101 → (最終行)

02 B 伝票No

03 C 決算(通常仕訳-"空白" 決算-"本決")

04 D * 取引日時

05 E * 借方勘定科目

06 F 借方補助科目

07 G 借方部門

08 H * 借方税区分

09 I * 借方金額

10 J 借方税金額

11 K * 貸方勘定科目

12 L 貸方補助科目

13 M 貸方部門

14 N * 貸方税区分

15 O * 貸方金額

16 P 貸方税金額

17 Q * 摘要

18 R 番号

19 S 期日

20 T * タイプ(仕訳データ-"0")

21 U 生成元

22 V 仕訳メモ

23 W 付箋1

24 X 付箋2

25 Y * 調整("NO")


【弥生会計】(インポート結果の例)
"2100",2,"","2011/11/01","仕入高","","","借方税区分",100000,0,"普通預金","三菱東京UFJ","","貸方税区分",100000,0,"大企業さんからの仕入れ","","",3,"","","0","0","no"

"2110",2,"","2011/11/01","売掛金","","","借方税区分",1000,0,"売上高1","","","貸方税区分",1000,0,"ネット通販売上","","",3,"","","0","0","no"


三菱東京UFJ Bizステーションの取引明細フォーマット


【銀行明細】(三菱東京UFJの取引明細の例)

"2","2011.10.20","振込MB1","ヤマダ タロウ","0","1000","8888888"

"2","2011.10.21","振込BZ2","カ)ダイキギョウ","100000","0","8888889"


切って貼ってのダムコードで!


弥生会計のインポート項目は25種類、必須(*印)のものでも11個。

一方、銀行明細には日付と金額及びメモ程度のデータしかないので、仕分けデータなども付け足して整形する必要がある。

まあ、並べ替えて切ったり貼ったりするベタベタのマクロでよいのではないか。私のコードはプログラミングの美しさのカケラもないが、とりあえず動けば、社内から感謝される。悪い気はしない。


プログラム例


プログラマさんによる「三菱東京UFJ Bizステーション取引明細の弥生会計インポート整形用マクロ」のようなものが公開されていればうれしいが、ないようなので公開。

まだ書きかけであり、動作検証はしていない。しかし、完成してもけっきょく弥生以外の業務システムからデータを取り込む場合はある程度画一的なデータでインポートするしかない。

借方税区分や貸方税区分、消費税の取引別の税区分、税金額、仕分けタイプなどは会社さんや利用者ごとに違うし、最終的には適切なデータを手作業で入れ込む必要がある。

なお、弥生会計は「弥生会計11」を使用。



//-------------------------------
//BizStationから弥生へ入金明細取込
//-------------------------------
//-------------------------------
//最初の1行、最後の2行は不必要なので削除
//-------------------------------
gofiletop;
deleteline;
gofileend;
up 2;
deleteline;
deleteline;

//-------------------------------
//余分なスペースなど削除
//-------------------------------
replaceall "\"","";
replaceall "^2,","",regular;
replaceall ".","/";
replaceall " ","";
replaceall " ","";
replaceall "\n\n","\n",regular;

//-------------------------------
//各行の最後の余分な数字文字列を削除
//-------------------------------
gofiletop;

while(1){
golineend;
left;
deletewordall;
backspace;
down;
golineend;
if(code == eof){break;}
}

//-------------------------------
//各行の「摘要」<->「金額」の入れ替え
//-------------------------------
gofiletop;

while(1){
searchdown ",";
searchdown ",";
replacedown ",","/";
golinetop;
searchdown ",";
beginsel;
searchdown ",";
cut;
golineend;
paste;
right;
if(code == eof ){break;}
golinetop;
}

//-------------------------------
//1行ごとに「入金」か「支払い」か判断(Incoming and Outgoing Payment)
//-------------------------------
gofiletop;
$figure ="";

//-------------------------------
IncomingOrOutgoingPayment:
//-------------------------------
while(1){
golineend;
if (code == eof){goto NEXT;}
golinetop;
searchdown ",";
beginsel;
searchdown ",";
copy;
beginclipboardread;
$figure =getclipboard;
if ($figure == ",0"){
replaceup ",0",",";
goto IncomingPayment;
}else{
goto OutgoingPayment;
}
}

//-------------------------------
IncomingPayment:
//-------------------------------
//入金元の記録を行う。ただし、個人からの入金は煩雑なので省略。
//会社などからの入金は「カ)」などが含まれるので、その行に関しては入金元を記録。

selectline;
searchdown "カ)",inselect;
if (result==yes){
golinetop;
searchdown ",";
right;
insert "普通預金,三菱東京UFJ,\"\",対象外";
beginsel;
searchdown ",";
copy;
insert ",0,売掛金,\"\",\"\",対象外";
paste;
right;
beginsel;
searchdown "\n",regular;
cut;
golineend;
insert "0,ネット販売@";
paste;
insert ",\"\",\"\",3,\"\",\"\",0,0,no";
} else {
golinetop;
searchdown ",";
right;
insert "普通預金,三菱東京UFJ,\"\",対象外";
beginsel;
searchdown ",";
copy;
insert ",0,売掛金,\"\",\"\",対象外";
paste;
right;
beginsel;
searchdown "\n",regular;
delete;
insert "0,ネット販売";
golineend;
insert ",\"\",\"\",3,\"\",\"\",0,0,no";
}
down;
goto IncomingOrOutgoingPayment;

//-------------------------------
OutgoingPayment:
//-------------------------------
golinetop;
searchdown ",";
right;
insert "支払手数料,\"\",\"\",課対仕入込,";
beginsel;
searchdown ",";
right;
copy;
insert "0,普通預金,三菱東京UFJ,\"\",対象外,";
paste;
golineend;
insert ",\"\",\"\",3,\"\",\"\",0,0,no";
down;
goto IncomingOrOutgoingPayment;

//-------------------------------
NEXT:
//-------------------------------
//行頭に「2100」を入れる
replaceall "^","2100,\"\",\"\",",regular;

//-------------------------------
//日付ごとに改行
//-------------------------------
$s1 = "";
$s2 = "";
gofiletop;
golinetop;
right 11;
beginsel;
right 10;
copy;
beginclipboardread;
$s1 = getclipboard;
//message $s1;
down;

while(1){
golinetop;
right 11;
beginsel;
right 10;
copy;
beginclipboardread;
$s2 = getclipboard;
//message $s2;
if ($s1 != $s2){
golinetop;
insert "\n";
replaceup "2100|2110","2101",regular;
replacedown "2100","2110";
}
down;
golineend;
if (code == eof){break;}
$s1 = $s2;
}

//-------------------------------
//日付ごとに分けた後の調整(ファイルトップの2100->2110 ファイルエンドの2100->2101)
//-------------------------------
moveto 0,0;
deletewordall;
insert "2110";
gofileend;
replaceup "2100|2110","2101",regular;

//-------------------------------
//日付ごとに分けた後の調整(1日に1件の伝票の入力番号を2111に変更)
//-------------------------------
gofiletop;
while(1){
searchdown "\n\n2101",regular;
if (result == yes) { replacedown "2101","2111"; right; } else { break; }
}
endmacro;




search
layout
admin

[▲page top]