セルビアのeOtpremnica:2027年10月1日までにERP、WMS、TMSを接続する

2027年10月1日から、セルビアのVAT登録をしている民間企業2社の間で物品が動くたびに、電子納品書eOtpremnicaが必要になります。これは物品が出発する前に、財務省のシステムを通じて送らなければなりません。物品を受け取る会社は数日以内に同じシステムで受領を確認しなければならず、運送業者は検査の際に納品書を提示できなければなりません。
対象は、販売の納品、返品、自社の倉庫間の移動です。納品書は、ERPが印刷する帳票ではなくなります。国のAPIを通り、識別子とQRコードを付けて戻ってきて、その後は双方の側でステータスのワークフローを進んでいくUBLファイルになります。
この記事を読むべき人
Minimax、BizniSoft、Pantheonで請求と出荷を行っているなら、ベンダーはすでにeOtpremnicaへの対応を提供しています。件数が少なく、財務省の無料のWebポータルやモバイルアプリに納品書を手入力できるなら、それでも構いません。受領の期限についての節を読み、荷受け場の担当者を教育すれば、ほぼ終わりです。
この記事は、もう一方のグループのためのものです。出荷と入荷を自社のERP、カスタマイズしたWMS、TMS、あるいはB2Bの注文を計上するECサイトのバックエンドで処理している卸売業者、製造業者、商社、運送業者です。アップデートを届けてくれる人はいません。連携は自分で構築しなければなりません。
すでに適用されていること、これから変わること
電子納品書法(Zakon o elektronskim otpremnicama)は2024年に制定され、その後2回改正されています。2026年8月31日にSlužbeni glasnik 80/2026で公布された最新の改正法は、2027年10月の日付を維持しました。財務省のFAQと統合版の条文が、段階を示しています。
2026年1月1日から:
- 民間企業は、物品税の対象となる物品(たばこ、ニコチン製品、コーヒー、アルコール飲料、石油製品)についてeOtpremnicaを送受信する。
- 民間企業は、公的部門の機関に納品するすべての物品について送信し、公的部門の機関は自らの物品の移動について送信する。
- 運送業者は、これらの移動について納品書を提示する。
本番システムは2025年12月30日から稼働しています。社内ソフトウェアのテストを目的としたデモ環境は、2025年3月5日から利用できます。
2027年10月1日から:
- 送り手と受け手がどちらも民間部門の事業者で、物品が物品税の対象でない場合の送信義務。
- すべての民間部門の事業者の受信義務。
- 運送業者が、これらの移動について納品書を提示する義務。
見落とされやすい細部がいくつかあります。同じ工場の敷地内にある2つの倉庫間の移動でも、物品の住所が変わり、公道を使うなら、社内納品書(XMLでは種別Int)が必要です。輸入では、処分権を取得した場所から、場合によっては税関から、自社の倉庫までの社内納品書が必要です。輸出では通常、フォワーダーが引き継ぐ地点までの社内納品書が必要です。フィスカル化法に基づく小売販売は対象外なので、フィスカルレシートを発行して販売するECサイトは、その注文については対象外です。ただし卸売の部分は対象です。
8月の改正は、2027年1月1日までは、送信した納品書と受領書のデータの誤りを監督当局が考慮しないことも定めています。これは物品税対象品や公的部門向けの送り手には助けになりますが、2027年10月については何も変わりません。
日付は動くでしょうか。法律は2年足らずで2回改正されているので、さらなる変更はありえます。しかし、成立したばかりの改正は日付を維持しました。この日付を前提に計画してください。
期限があるのは受領の側
送信は簡単なほうの半分です。統合版の法律は、厳しい期限を受け手の側に課しています。
- 物品が動く前に、送り手が納品書を送ります。受け手が物理的な受領を確認するまでは、送り手は理由を示して取り消すことができます。
- 物理的な受領は、物品を引き取った日に、遅くとも受領を始めてから3営業日以内に確認しなければなりません。
- その確認から 8日以内に、受け手はePrijemnica(電子受領書)を送って、納品の全部または一部を受け入れるか拒否します。
- 民間部門の受け手が8日以内に何も送らなければ、納品の全部を拒否したものとみなされます。 公的部門の受け手の場合は逆で、何もしなければ受け入れたものとみなされます。
- 一部を受け入れた場合、送り手は電子受領書が届いてから30日以内に差異に同意しなければなりません。同意しなければ、電子受領書の全部を拒否したものとして扱われます。
- 物理的な受領の確認がない納品書は、移動の開始から30日で無効になります。
双方が合意すると、文書はUsaglašeno(APIではFulfilled)のステータスになり、それ以降は何も変更できません。
物理的な受領の期限を守らないことは、列挙された違反行為です。会社には20万ディナールから200万ディナール、責任者には5万ディナールから15万ディナールの罰金が科されます。納品書をまったく送らなかった場合も、同じ範囲の罰金です。
実務上の結論は、物理的な受領の確認は荷受け場で、物品を入庫計上するその瞬間にWMSで行うべきだということです。月末に誰かが照合するのを待っていたら、期限はとうに過ぎています。
財務省のAPIに対して構築するもの
技術文書は、UBL 2.1のXMLをやり取りするREST APIを説明しています。eOtpremnicaはDespatchAdvice、ePrijemnicaはReceiptAdviceで、それ以外のすべての手順(取消し、輸送の開始、車両の変更、物理的な受領、電子受領書の受け入れや拒否)は、数値コードを持つApplicationResponseです。財務省は2025年12月5日に、文書の種別、XMLの拡張、送信、WebhookについてIT業界向けのワークショップを開催しました。
送信
すべての文書は、自社で決めた一意のリクエストIDを付けて、1つのエンドポイントPOST /public/documents/requestsに送ります。処理は非同期です。結果は後から、Webhookか、/public/documents/requests/changesのポーリングで届きます。後者は各リクエストを処理中、成功、失敗のいずれかとして、業務エラーを添えて報告します。
したがって、ERPには送信キュー(アウトボックス)が必要です。納品書ごとのレコード、状態遷移、そして重複を作らない再送の経路です。システムは自社ですでに使われている文書番号を拒否するので助けにはなりますが、それは再送しても番号が変わらない場合に限られます。
財務省のAPI利用者向けFAQにあるエラーの一覧を見ると、データの作業がどこにあるかが分かります。
- 発行日はセルビア時間で当日でなければなりません。日付をさかのぼることも、前日の納品書を一晩キューにためておくこともできません。
- すべての住所(自社、顧客、運送業者、積込地点と荷下ろし地点)に、通りと市町村が必要です。
- 自社輸送、運送業者による輸送、受け手側による輸送のいずれでも、運送業者、車両の登録番号、輸送手段が必須です。自社輸送の場合は、自社の運送業者ステータスを有効にする必要もあります。
- 数量には単位コードが付きます。明細行には1から番号を振ります。GTINを記載する場合は数字のみです。
- 受け手は登録済みで有効でなければなりません。
GET /public/companies/statusを使えば、送る前にPIBを確認できます。
通常、XMLよりもマスタデータのほうが大きな仕事です。送信前に文書をテストできる検証用のエンドポイントがあり、これはテストスイートに組み込むべきものです。
受信と倉庫
受け取る納品書は、/public/documents/customers/changesを日付ごとに1ページ1,000件の変更でポーリングするか、Webhookで届きます。Webhookの購読は1日単位で、/public/webhook-notifications/subscribeを呼び出すと翌日分が対象になります。これを定期実行のジョブにし、失敗したらアラートを出し、取得用のエンドポイントを毎晩の照合に使い続けてください。そうすれば、プッシュの取りこぼしが期限の取りこぼしにつながりません。
届いた納品書は、仕入先の品目コードを自社のコードに対応づけたうえで、入荷予定としてWMSに取り込みます。物品を入庫計上したら、WMSが物理的な受領のアクションを送ります。数量と品質の検査の後にはePrijemnicaを送ります。明細行ごとに、到着した数量と、拒否して同じ車両で返送した数量を記載します。システムは、受領した数量を超える拒否数量を受け付けません。
財務省自身のロールモデルは、よいひな形になります。倉庫ロールは、受信した納品書の一覧表示とダウンロード、物理的な受領の確認ができます。WMSの権限も、この形にするのが適切です。
送り手としても、相手側の電子受領書を受け取り、受け入れるか拒否しなければなりません。30日の合意期間は、誰かの受信箱ではなくERPで管理してください。
SEFの電子インボイスとの紐づけ
納品書をSEFの電子インボイスと紐づけるのは任意です。納品書を送り、実際の発送時刻を過ぎていれば、SEFは1つまたは複数の納品書を1通の電子インボイスに紐づけることができ、請求書は受領のワークフローが終わるのを待つ必要がありません。注文、納品、請求書の三点照合をすでにERPで行っているなら、この紐づけによって顧客の買掛金担当者も同じ証拠を得られます。SEFの側は、当社の電子インボイス連携の仕事で扱っています。
運送業者と道路上
運転手は、財務省の運送業者向けアプリで納品書を提示できます。運送業者がシステムの利用者でない場合は、送り手が納品書を印刷し、運送業者が出発前に署名し、送り手が物品の移動前に署名済みの写しをアップロードします。8月の改正以降、システムを使えない運送業者は、代わりに納品書を送ったときに生成されたQRコードを提示することもでき、その場合は送り手が出発前に印刷用の表示を添付します。TMSは、運送業者が使うこれらの方法のいずれにも対応して出力できる必要があり、APIはラベル用にQRコードを単体で返します。
システム障害時には、紙による代替手段があります。セルビア国立銀行のトプチデル造幣局が発行するセキュリティホログラムのシールを貼った印刷物を3部作り、翌営業日までにシステムに登録します。シールは必要になる前に購入しておいてください。
APIキーの仕組み
会社の登録は法定代理人が行い、国のeIDポータルからサインインします。キーはその後、Webインターフェース(設定、API設定、管理モジュール、APIキー)で作成します。デモ環境と本番環境は別なので、両方のキーを用意する前提で計画してください。
キーは会社を識別します。API利用者向けFAQははっきり書いています。他社の代わりに文書を送ることはできず、システムは提示されたAPIキーによって会社を認識します。実務上は次のようになります。
- 5つの法人を持つグループには、5つのキーと、PIBによって正しいキーを選ぶルーターが必要です。
- シェアードサービスセンターやソフトウェア会社が、すべての顧客を1つのキーで送ることはできません。
- キーはERPサーバーの設定ファイルではなく、管理者とローテーションの手順を決めたうえでシークレットストアに置きます。
12か月計画
いまは2026年10月です。2027年10月1日から逆算します。
2026年10月から12月:棚卸しとアクセス。
- すべての移動の種類を洗い出します。販売、返品、倉庫間の移動、輸入、輸出、自社の車両、外部の運送業者、顧客による引き取りです。
- 本番環境で会社を登録し、デモ環境のAPIキーを取得します。
- マスタデータの整備を始めます。住所、取引先のPIBと登録番号、運送業者、車両、単位です。
2027年1月から3月:送信の経路。
- 出荷データからDespatchAdviceを生成し、送信キュー、非同期のステータス追跡、エラー処理を整えます。
- 毎日のWebhook購読ジョブと、取得による照合を用意します。
- デモ環境に対する検証をCIで実行します。
2027年4月から6月:受信と受領。
- 受け取った納品書を、入荷予定としてWMSに取り込みます。
- 荷受け場での物理的な受領、検査後のePrijemnica、3日の期限の2日目と8日の期限の6日目のアラートを用意します。
- 送り手として受け取る電子受領書の受け入れと拒否を処理します。必要ならSEFとの紐づけも行います。
2027年7月から9月:道路とパイロット。
- 運送業者の流れ、印刷とQR、シールを現場に置いたオフライン手順を整えます。
- 登録済みの取引先と、本番環境で実際の納品書を運用します。民間企業はすでに任意でシステムを使えます。
- 倉庫の担当者と運転手を教育します。9月は変更を凍結します。
データが整った1つの法人なら、12か月は余裕のある期間です。複数の法人、複数の倉庫を持ち、マスタデータに何年も誰も手を付けていないグループにとっては、ぎりぎりです。
ご相談先
C9 Groupはノヴィ・サドに拠点を持っており、セルビアのルールは当社にとって地元の話です。当社は連携そのものを構築します。UBLの生成、APIクライアント、Webhookの処理、そして既存のERP、WMS、ECサイトのバックエンドの中での倉庫の受領ワークフローです。ERPモダナイゼーションのサービスをご覧いただくか、office@c9group.devまでご連絡ください。