KAZENAKAZENA
記事一覧へ

「Disimpan」と出た日

2026年9月1日 · Taro(KAZENA代表)

画面に「Disimpan」と出ました。保存しました、という意味のインドネシア語です。8月14日の午後、Coretaxが、KAZENA Booksの書き出したファイルを初めて受け取りました。2か月かけた作業が終わった合図は、私たちが1文字も書いていない、この1語でした。

何をしていたのかを書きます。KAZENA Booksは源泉徴収の控えを作れます。ただ、そこから先は、画面の数字を見ながら、人が役所の側に打ち直していました。相手の番号、支払額、税率、対象の期間。1件ずつ、同じことをもう一度入力する。これをやめたい、というだけの話です。書式の仕様は公開されていますから、それに合わせたファイルを作ればいい。それらしいXMLができたのは3日目でした。

それらしいファイルは、受け取ってもらえません。最初のファイルから「Disimpan」までに、27回はねられています。どこで落ちたのかを、順に書きます。あとから見れば、どれもこちらの落ち度です。

最初は番号でした。相手先のNPWPが存在しない、と返ってきます。私たちの試験用データは、それらしい形をした番号でした。桁数も区切りも合っています。ただ、受け取る側はその番号を台帳に照らします。台帳に無い番号は、形が整っていても通りません。これは正しい動きです。ここで分かったのは、自分たちで作った番号では、この経路は一生通らないということでした。自分の会社の番号と、ジャカルタの会計士のVが自分の事務所の分として使ってよいと言ってくれた番号で試すまで、先に進めていません。彼女は自分の事務所の実データでKAZENA Booksを20回以上試してくれていて、このときも、どの番号なら試してよいかをその場で切り分けてくれました。この記事に出てくる番号は、すべて説明のための作り物です。

次は桁でした。NPWPは16桁に揃っていく途中で、私たちは15桁のまま、しかも点と横棒で区切って送っていました。画面に見せるための形を、そのままファイルに書いていたわけです。区切りを外して16桁で送る。それだけのことに2日かかりました。表示用の整形と、送信用のデータが、同じ1つの関数から出ていたからです。片方を直すと、もう片方の見た目が崩れました。

細かい落ち方も並べておきます。対象の期間で落ちたのが3回。支払った日の月を、そのまま申告の対象期間に入れていました。金額で落ちたのが2回。ルピアに小数はないのに、1,500,000.00と書いて送っていました。会計の処理で使っている型が、小数2桁を付ける既定のままだったからです。税率も、2%を0.02と書いていて、これも違いました。記号で落ちたのが1回。取引先の名前に&が入っていて、XMLではこの記号をそのまま置けません。エスケープの処理を、名前の欄にだけ書き忘れていました。

いちばん時間がかかったのは、理由の書いていない1件です。返ってきたのは、この文書は処理できません、という短い文だけでした。行番号も、項目名もありません。4日かかりました。中身の話ではなく、要素の並び順でした。仕様は順番まで決めていて、私たちのファイルは項目名のアルファベット順に並んでいます。人が読む分には、どちらでも同じ内容です。受け取る側にとっては、同じではありませんでした。

通った順も書いておきます。8月14日にBPA1が通り、17日にBPMP、20日にBPPUが通りました。3つとも同じ仕組みで作っているのに、最初と最後で6日離れています。様式ごとに、必須の項目も並び順も少しずつ違うからです。1つ通れば残りも通る、と思っていたのは、私の見込み違いでした。

「Disimpan」の意味も、あとから直しました。仲間のEに聞いたときに、これは保存であって、提出でも受理でもない、と言われています。彼はジャカルタから少し離れた町にいて、現地の言葉で出る文面をいつも見直してくれます。私は画面に「提出が完了しました」と出すつもりでいました。役所の側が言っているのは、下書きとして保存したところまでです。そのあとに提出の操作があり、受理の確認があります。1語の意味を広げて訳すと、使う人は、終わっていない手続きを終わったと思って画面を閉じます。

直したことを書きます。送る前に、こちらで分かる範囲だけ確認します。番号が16桁になっているか、金額が整数か、並び順が仕様どおりか。そして、はねられたときは、返ってきた文をそのまま画面に出して、その下に私たちの訳と、どの様式のどの項目かを添えます。私たちの言葉で言い換えた1行だけを出すのは、やめました。訳したときに意味が変わってしまう語が、確かにあるからです。

設計として学んだことは、はっきりしています。自分たちで書いた試験は、自分たちの理解を試しているだけで、受け取る側の規則を試してはいません。27回のうち、こちらの試験が先に見つけられたのは4回でした。残りの23回は、外に出して、はねられて、初めて分かっています。仕様書を読んで作ったものが仕様どおりかどうかは、仕様を持っている側に渡すまで決まりません。

念のため書いておきます。私は税理士ではありません。様式も手続きも変わっていきますし、どの様式が要るのかは取引の形で違います。ここに書いた番号は説明のための作り物で、日付と回数だけが私たちの作業の記録です。実際の提出については、必ず専門家に確認していただくようお願いします。

お願いがあります。提出がはねられたときの文で、私たちがまだ訳せていないものがあれば、その文をそのまま送ってください。長い説明よりも、返ってきた短い1文のほうが助かります。私たちが27回かけて覚えたのは、そういう短い文の読み方でした。

あなたの声を聞かせてください

KAZENAのアプリを使った感想、直してほしいところ、「こんな機能が欲しい」という提案——インドネシアやフィリピンの中小企業オーナーさん、フリーランスの方の声こそ、私たちが一番聞きたいものです。インドネシア語・英語のメッセージには、現地を知り尽くした仲間が応えます。また、KAZENA Booksはフィリピンとインドネシアでの展開がすでに決まっています。それ以外の国で一緒に展開してくださるパートナー企業様、システムのご購入をご検討の企業様も、お気軽にご連絡ください。新しいシステム開発のご相談もお受けしています。少人数のチームのため、すぐの着手をお約束できないこともありますが——日本品質(メイド・イン・ジャパン)のものづくりで、現地の商売に寄り添う開発を、一件ずつ丁寧に。

お問い合わせへ

他の記事もどうぞ