Rokh Management Consulting

دستورالعمل فنی نحوه اتصال به سامانه مودیان

  • شناسه یکتای حافظه مالیاتی: شناسه‌ای است یکتا دارای مقداری ثابت و منحصر به‌فرد که به هر حافظه مالیاتی در سطح کشور اختصاص داده می‌شود، این شناسه از مولفه‌های تشکیل دهنده شماره منحصر به فرد مالیاتی است که پس از درخواست مودی در کارپوشه تولید و در اختیار وی قرار خواهد گرفت.
  •  شماره منحصر به‌فرد مالیاتی: شماره‌ای است یکتا در سامانه مودیان که به ازای هر صورتحساب تولید شده و به‌صورت منحصر به‌فرد به آن صورتحساب تخصیص داده می‌شود. این شماره دارای بخش‌های اطلاعاتی خاص بوده که جزئیات آن در سند «قالب شناسه یکتای حافظه مالیاتی و شماره منحصر به فرد مالیاتی» ذکر شده است.
  • صورتحساب الکترونیکی: صورتحسابی است دارای شماره منحصر به فرد مالیاتی که اطلاعات مندرج در آن، در حافظه مالیاتی فروشنده ذخیره می‌شود. مشخصات و اقلام اطلاعاتی صورتحساب الکترونیکی، متناسب با نوع کسب و کار توسط سازمان تعیین و اعلام شده است. در مواردی که از دستگاه کارتخوان بانکی یا درگاه پرداخت الکترونیکی به عنوان پایانه فروشگاهی استفاده شود، رسید یا گزارش الکترونیکی پرداخت خرید صادره در حکم صورتحساب الکترونیکی است.
  • حافظه مالیاتی: نوعی حافظه الکترونیکی است که برای ثبت و نگهداری اطلاعات مندرج در صورتحساب‌های الکترونیکی و انتقال آن به سامانه مودیان مورد استفاده قرار می‌گیرد. حافظه مالیاتی می‌تواند به شکل سخت‌افزاری یا نرم‌افزاری باشد. حافظه مالیاتی، توسط مودی برای ثبت صورتحساب الکترونیکی مورد استفاده قرار می‌گیرد. هر حافظه مالیاتی باید دارای شماره شناسه یکتا باشد. شناسه یکتای حافظه مالیاتی توسط سازمان اختصاص داده می‌شود.
  • پایانه فروشگاهی: رایانه، دستگاه کارتخوان بانکی، درگاه پرداخت الکترونیکی یا هر وسیله دیگری که امکان اتصال به شبکه‌های الکترونیکی پرداخت رسمی کشور و سامانه مودیان را داشته و از قابلیت صدور صورتحساب الکترونیکی برخوردار باشد)بند ب ماده 1 قانون.)
  •  شرکت‌های معتمد ارائه کننده خدمات مالیاتی: اشخاص حقوقی دارای پروانه هستند که حسب ضوابط و دستورالعمل‌های ابلاغی سازمان، نسبت به ارائه مشاوره و آموزش‌ٰهای لازم به مودیان، نصب و پشتیبانی تجهیزات مورد نیاز برای ارائه خدمات مالیاتی از قبیل خدمات مربوط به صدور صورتحساب و سایر امور غیرحاکمیتی با سازمان همکاری می‌کند (بند چ ماده 1).
  •  زیرسامانه جمع‌آوری و پردازش اطلاعات صورتحساب:زیرسامانه‌ای است که داده‌های ارسالی از پایانه‌های فروشگاهی-حافظه مالیاتی یا شرکت‌های معتمد ارائه کننده خدمات مالیاتی نوع اول را از طریق واسط‌های نرم‌افزاری دریافت می‌کند.
  •  حد مجاز فروش: جمع صورتحساب‌های الکترونیکی صادره توسط هر مودی در هر دوره مالیاتی نمی‌تواند بیشتر از سه برابر فروش اظهار شده وی در دوره مشابه سال قبل، که مالیات آن به سازمان پرداخت شده یا ترتیب پرداخت آن داده شده است، باشد. جمع صورتحساب‌های الکترونیکی صادر شده در هر دوره مالیاتی برای واحدهای جدیدالتاسیس یا واحدهای فاقد سابقه مالیاتی نمی‌تواند بیش از سه برابر معافیت سالانه موضوع ماده 101 قانون مالیات‌های مستقیم باشد (ماده 6 قانون پایانه‌های فروشگاهی و سامانه مودیان.)
  • شناسه یکتای ارسال صورتحساب: شناسه ای یکتا که هنگام ارسال صورتحساب توسط ارسال کننده به صورتحساب جهت رهگیری آن اختصاص داده میشود. این شناسه با فرمت uuid3 به صورت رمز نشده ارسال میگردد.
  • رسید یکتای دریافت صورتحساب:4 هنگام دریافت صورتحساب در زیرسامانه جمع‌آوری و پردازش اطلاعات، یک شناسه رسید یکتا با فرمت uuid به هر صورتحساب توسط این زیرسامانه اختصاص داده میشود.
  • لیست صورتحساب‌ها: مجموع‌های از صورتحسابهای صادر شده توسط پایانه فروشگاهی-حافظه مالیاتی که در قالب یک مجموعه به سامانه مودیان ارسال می‌شود.
  • کالینت: ارسال کننده درخواست به API زیرسامانه جمع‌آوری و پردازش اطلاعات که می‌تواند مودی یا شرکت معتمد ارائه کننده خدمات مالیاتی باشد.
  • سرور: سرور سامانه مودیان
  • زوج کلید عمومی و خصوصی : در این سند هرگاه برای انکارناپذیری از کلید عمومی یا خصوصی استفاده می‌شود منظور کلیدی است که توسط یک مرکز میانی معتبر برای هر یک از ذینفعان سامانه مودیان گواهی شده باشد.
  • مرکز میانی معتبر: هر مرکز میانی که از شورای سیاست گذاری گواهی الکترونیکی کشور مجوز گرفته باشد (موضوع ماده 32 قانون تجارت الکترونیکی.) لیست این مراکز از طریق سایت www.rca.gov.ir بخش مراکز میانی، قابل دسترسی است.

تعاریف

پیکربندی پایانه فروشگاهی-حافظه مالیاتی

دریافت شناسه یکتای حافظه مالیاتی

  •  مودی جهت صدور و ارسال صورتحساب الکترونیکی نیاز به دریافت شناسه یکتا حافظه مالیاتی دارد. بنابراین می‌بایست به بخش عضویت و ثبت نام کارپوشه خود مراجعه نموده و مراحل زیر را طی نماید:

۱. به ازای هر شناسه یکتا حافظه مالیاتی، یکی از سه حالت ارسال اطلاعات صورتحساب را به شرح ذیل انتخاب کند:

  •  توسط خود مودی (به روش مستقیم)
  •  ارسال اطلاعات صورتحساب توسط شرکت معتمد ارائه کننده خدمات مالیاتی (به روش غیرمستقیم)
  •  ارسال اطلاعات صورتحساب توسط شرکت معتمد ارائه کننده خدمات مالیاتی (به روش غیرمستقیم و با استفاده از زیرساخت‌های اختصاصی)

۲.  کلید عمومی RSA دریافتی از مراکز میانی معتبر با طول کلید 2048 بیت را بارگذاری نماید.

نکته: در صورتی‌که ارسال غیرمستقیم باشد و شرکت معتمد ارائه کننده خدمات مالیاتی صدور، رمزگذاری و ارسال صورتحساب را به عهده داشته باشد، بارگذاری کلید عمومی توسط مودی ضرورتی ندارد. در این حالت شرکت معتمد ارائه کننده خدمات مالیاتی باید از طریق کارپوشه خود، کلید عمومی مربوط را به سازمان معرفی نماید.

۳. ارتباط شناسه یکتای حافظه مالیاتی درخواستی با کدپستی(های) محل فعالیت تعیین گردد.

 پیکربندی و ثبت مشخصات

مودی برای راه‌اندازی پایانه فروشگاهی-حافظه مالیاتی خود باید از طریق فراخوانی متدهای “دریافت اطلاعات سرور” و “دریافت اطلاعات حافظه مالیاتی”، شماره اقتصادی، نام تجاری، ساعت و تاریخ، کلید عمومی سازمان و شناسه یکتای حافظه مالیاتی را از سرور دریافت کند. جزئیات اقالم اطلاعاتی الزم در جدول 10 توضیح داده شده است.

امنیت اطلاعات

 مکانیزم‌های امنیتی جهت ارسال صورتحساب مطابق با نمودار ارائه شده در شکل 1 است.

مکانیزم‌های امنیتی جهت ارسال صورتحساب

توکن

با هدف احراز هویت و تعیین سطح دسترسی ارسال کننده اطلاعات، از مکانیزم تخصیص توکن5JWT استفاده شده است. لازم است توکن تخصیص داده شده به مودی یا شرکت معتمد ارائه کننده خدمات مالیاتی نوع اول در Header تمامی درخواست‌های ارسال شده مودی به API های زیرسامانه جمع‌آوری و پردازش اطلاعات قرار گیرد.

امضا

با هدف حفظ قابلیت انکارناپذیری، یکپارچگی و احراز هویت، بر روی تمامی درخواست‌ها به API های زیرسامانه جمع‌آوری و پردازش اطلاعات مکانیزم امضا در نظر گرفته شده است.‌

نرمال سازی درخواست

برای یکسان کردن ساختار تمامی درخواست‌ها به API های زیرسامانه جمع‌آوری اطلاعات، برای تمامی بسته‌های ارسالی شامل همگام و غیرهمگام امضا بر روی درخواست صورت می‌پذیرد. برای امضا می‌بایست ابتدا Header و Body درخواست ادغام و JSON واحد تولید گردد. ضروری است JSON تولید شده مطابق شکل 2 به رشته تبدیل، سپس امضا و ارسال شود.

نرمال سازی درخواست

فرآیند تبدیل JSON به رشته، مطابق گام‌های جدول  1 است:

–  شی به فرمت کلید-مقدار تبدیل شده به طوری که کلید، عمق جایگاه مقدار را مشخص می‌نماید.

–  کلیدها بر اساس حروف الفبا مرتب شوند.

–  سپس مقدارها به ترتیب با هم ادغام شوند:

  • از کاراکتر# به عنوان جداکننده مقادیر(اقلام اطلاعاتی) استفاده شود.
  • در صورتی که کاراکتر# در متن وجود داشته باشد، با ## مشخص می‌گردد.
  • در صورتی که مقدار فیلدی در رشته، null یا “” باشد؛ با ### مشخص می‌گردد.

–  در آخر آرایه‌ای از روی این رشته ایجاد می‌شود.

گام 1 {

“k2”: “v1”,

“k4”: “v2”, “k3”: { “k1”: “v4”,

“k5”: “v5” }

}

“k2”: “v1”

“k4”: “v2”

“k3.k1”: “v4”

“k3.K5”: “v5”

گام 2 “k2”: “v1”

“k3.k1”: “v4”

“k3.K5”: “v5”

“k4”: “v2”

گام 3 v1#v4#v5#v2

نکات:

  • در صورتی که داخل JSON آرایه وجود داشته باشد، ترتیب عناصر آرایه دستکاری نشده و با همان ترتیب در نظر گرفته می‌شود.
  • در صورتی که ریشه JSON آرایه باشد، داخل فیلد packets قرارگرفته و تبدیل به شی می‌شود.

روش پیاده‌سازی نرمال سازی JSON در پیوست‌های 1-1 و 2-1 ارائه شده است.

فرآیند امضای صورتحساب

برای امضا صورتحساب باید اطلاعات JSON صورتحساب به روشی که برای نرمالسازی بیان شد نرمال شوند. به عنوان مثال اطلاعات JSON صورتحساب زیر را در نظر بگیرید:

{ “header” : { “taxid”: “AA56CD0E0620002F2B4E78”, “indatim”: “1655620821274”, “indati2m”: “1655620821274”, “inty”: 2, “inno” : “0002F2B4E7”, “irtaxid” : null, “inp”: 1, “ins” : 1, “tins” : “32652362589632”, “tob” : 1, “bid” : null, “tinb” : null, “sbc” : null, “bpc” : null, “bbc” : null, “ft” : null, “bpn” : null, “scln” : null, “scc” : null, “crn” : null, “billid” : null, “tprdis” : 1000000, “tdis” : 0, “tadis” : 1000000, “tvam” : 90000, “todam” : 0, “tbill” : 1090000, “setm” : 1, “cap” : 90000, “insp” : 0, “tvop” : 90000, “dpvb” : null, “tax17” : null } “body” : [ { “sstid” : 2153265989636, “,پاستیل میوه ای شیبابا” : “sstt” 96, : “mu” “am” : 1, “fee” : 1000000, “cfee” :null, “cut” : null, “exr” : null, “prdis” : 1000000, “dis” : 0, “adis” : 1000000, “vra” : 0.09, “vam” : 90000, “odt” : null, “odr” : null, “odam” : null, “olt” : null, “olr” : null, “olam” : null, “consfee” : null, “spro” : null, “bros” : null, “tcpbs” : null, “cop” : 90000, “vop” : 90000, “bsrn” : null, “tsstam” : 1090000 } ], “payments” : [ { “iinn” : 5646556, “acn” : 5656565, “trmn” : 54554224, “trn” : 544542424, “pcn” : “6037-9972-9856-9865”, “pid” : null, “pdt” : 1655620821274, } ], “extension”: [ { “key” : null, “value” : null }

تمام اطلاعات پر شده در JSON غیر واقعی و تستی است.

بعد از نرمال سازی JSON صورتحساب مورد نظر، رشته نرمال شده به صورت زیر بدست می‌آید:‌

بلوک کد بلوک کد جی سون

رشته تولید شده در مراحل باال به وسیله کلید خصوصی (مودی/شرکت معتمد) با الگوریتم RSA2048-SHA256 هش و امضا می‌شود و خروجی آن در فیلد dataSignature در شی packet قرار می‌گیرد.

 کد روش امضا در پیوست شماره 3-1 ارائه شده است.

نحوه رمزگذاری صورتحساب

برای رمزگذاری صورتحساب می‌بایست یک کلید متقارن (به روش) AES/GCM/NoPADDING با طول 256 بیت تولید شود. برای رمزگذاری از طریق AES/GCM نیاز به یک کلید دیگر به نام IV به طول 128 بیت است که این کلید به صورت تصادفی تولید می‌گردد. بعد از تولید کلیدهای مورد نیاز، JSON صورتحساب را ابتدا با کلید متقارن XOR کرده و سپس به روش AES/GCM رمزگذاری می‌گردد.

جزئیات XOR به این شکل است که باید متنی که می‌خواهیم XOR کنیم (در اینجا JSON صورتحساب) باید به بالک‌های 256 بیتی تبدیل شود و هر بالک با کلید متقارن که 256 بیت است XOR شود. با این روش ممکن است که بالک آخر تعداد بیت کمتر از 256 داشته باشد که با همان تعداد از کلید متقارن XOR انجام می‌شود.

برای صورتحساب تستی بخش قبل کلید متقارن رمز شده و IV به صورت hex در زیر نمایش داده شده است:

بلوک کد بلوک کد جی سون

نمونه صورتحساب رمز شده به شکل زیر است :

بلوک کد بلوک کد جی سون

کد روش رمزگذاری به روش متقارن AES/GCM در پیوست 4-1 ارائه شده است.

پس از رمزگذاری صورتحساب، از طریق الگوریتم AES/GCM، باید کلید متقارن رمز شده و IV در کنارصورتحساب رمزشده قرار گیرد. برای رمزگذاری کلید متقارن باید از روش نامتـــــــقارن RSA-OAEP-SHA256 استفاده شود که برای این منظور از کلید/های عمومی سازمان با طول 4096 بیت اخذ شده از یک مرکز  میانی معتبر استفاده می‌شود. کلید عمومی سازمان با  استفاده  از  متد GET_SERVER_INFORMATION به دست می‌آید.

کد روش رمزگذاری به روش نامتقارن RSA-OAEP-SHA256 در پیوست 5-1 ارائه شده است.

فراخوانی متدهای API جمع‌آوری اطلاعات سامانه مودیان

آدرس API ها

آدرس APIهای زیرسامانه جمع‌آوری و پردازش اطلاعات به صورت زیر است که پیشوند تمام آدرس‌ها قرار میگیرد.

https://tp.tax.gov.ir/req/

آدرس‌هایی که با tsp شروع می‌شوند برای شرکت‌های معتمد ارائه کننده خدمات مالیاتی در نظر گرفته شده و آدرس‌هایی که با self-tsp شروع می‌شوند برای مودیانی که قصد دارند خودشان صورتحساب ارسال کنند در نظر گرفته شده است.

دو مکانیزم برای درخواست‌های با اولویت عادی و درخواست‌های با اولویت بالا وجود دارد. آدرس normal-enqueue برای درخواست‌های معمولی و fast-enqueue برای درخواست‌های با اولویت بالا در نظر گرفته شده است.

متدها همراه با آدرس API در جدول 2 ارائه شده‌اند.

آدرس متد اسم متد ردیف
…/api/self-tsp/async/normal-enqueue/

…/api/self-tsp/async/fast-enqueue/

…/api/tsp/async/normal-enqueue/

…/api/tsp/async/fast-enqueue/

ارسال صورتحساب الکترونیکی 1
…/api/self-tsp/sync/ GET_TOKEN/

…/api/tsp/sync/ GET_TOKEN/

متد دریافت توکن 2
…/api/self-tsp/sync/ GET_FISCAL_INFORMATION/

…/api/tsp/sync/ GET_FISCAL_INFORMATION/

استعالم اطلاعات حافظه مالیاتی

مودی و حد مجاز فروش مودی

3
…/api/self-tsp/sync/ INQUIRY_BY_UID /

…/api/tsp/sync/ INQUIRY_BY_UID /

استعالم با شناسه یکتای ارسال

صورتحساب

4
…/api/self-tsp/sync/INQUIRY_BY_REFERENCE_NUMBER /

…/api/tsp/sync/INQUIRY_BY_REFERENCE_NUMBER /

استعالم با رسید یکتای دریافت

صورتحساب

5
…/api/self-tsp/sync/INQUIRY_BY_TIME/

…/api/tsp/sync/INQUIRY_BY_TIME /

دریافت خطاهای بستههای ارسالی

غیرهمگام با استفاده از زمان

6
…/api/self-tsp/sync/ INQUIRY_BY_TIME_RANGE /

…/api/tsp/sync/ INQUIRY_BY_TIME_RANGE /

دریافت خطاهای بستههای ارسالی

غیرهمگام با استفاده از بازه زمانی

7
…/api/self-tsp/sync/ GET_SERVER_INFORMATION /

…/api/tsp/sync/ GET_SERVER_INFORMATION /

دریافت اطلاعات سرور 8
…/api/self-tsp/sync/ GET_SERVICE_STUFF_LIST /

…/api/tsp/sync/ GET_SERVICE_STUFF_LIST /

دریافت لیست کامل شناسه

کاال/خدمات و نرخ مالیاتی

9
…/api/self-tsp/sync/GET_ECONOMIC_CODE_INFORMATION /

…/api/tsp/sync/GET_ECONOMIC_CODE_INFORMATION /

استعالم اطلاعات شماره اقتصادی 10

ساختار درخواست‌ها

در این بخش ساختار درخواست‌ها به API شرح داده شده است. در جدول 3 ساختار کلی درخواست ارائه شده است.

ساختار کلی سرویس همگام مشابه با سرویس غیرهمگام بوده و تفاوت آن در فیلد packet است. بطوریکه در حالت همگام به جای آرایه‌ای از درخواست، فقط یک درخواست می‌توان ارسال نمود (packet). در درخواست غیرهمگام می‌توان مجموعه‌ای از بسته‌ها (packets) را ارسال نمود.

جدول .3ساختار کلی درخواستها

مقدار عنوان
POST HTTP متد
Authorization: “string”

requestTraceId: “string” timestamp: “Long”

فیلدهای Header
{

“packets”: Packet[], “signature”: “string”, “signatureKeyId”: “string”

}

فیلدهای Body
{

“timestamp”: “Long”, “result”: AsyncResponse[], “signature” : “string”, “signatureKeyId” : “string”

}

فیلدهای خروجی
{

“timestamp”: “Long”, “errors”: ErrorResponse[], “signature” : “string”, “signatureKeyId” : “string”

}

خروجی سرویس در صورت رخداد خطای کلی

فیلد signatureKeyId اختیاری بوده و مقدار پیش فرض آن برابر با null خواهد بود.

اطلاعات تکمیلی فیلدها در جدول 4 آورده شده است:

جدول .4 توضیحات مربوط به فیلدهای درخواست

توضیحات نام فیلد
توکن با این سرآیند )Header( ارسال میشود، در صورتیکه فراخوانی یک متد نیاز به احراز هویت

نداشته باشد، این فیلد اختیاری خواهد شد. این سرآیند در API های غیرهمگام و برخی از API های همگام اجباری است.

Authorization
هر درخواستی باید دارای یک UUID باشد که در سرآیند ارسال میشود. از این شناسه برای

تشخیص درخواستهای تکراری استفاده میشود.

requestTraceId
زمان ارسال بسته از کالینت که در سرآیند ارسال میشود. یکی از کاربردهای این فیلد، رد کردن

بستههای قدیمی است.

timestamp
لیست بستههای ارسالی. packets
امضای روی درخواست. signature
شناسه کلید عمومی ارسال کننده، برای بررسی امضا.

این فیلد اختیاری بوده و مقدار پیش فرض آن برابر با Null خواهد بود.

signatureKeyId

زمانی که کالینت پاسخ این سرویس را دریافت می‌کند، الزاماً رسیدگی به بسته‌های اطلاعاتی پایان نیافته است، بلکه تنها در صف رسیدگی قرار گرفته‌اند. تایید رسیدگی و نتیجه اعمال موفق یا ناموفق بسته‌های اطلاعاتی از طریق استعلام به اطلاع کالینت خواهد رسید.

در صورتی که کالینت نتیجه رسیدگی به یک بسته را failed دریافت نماید، لازم است پس از اطمینان از عدم وجود خطاها در بسته ارسالی، آن را مجدداً ارسال نماید. در ارسال مجدد باید مقدار فیلد retry برابر true باشد تا سرویس غیرهمگام در جریان ارسال مجدد درخواست باشد.

ساختار بسته‌های ارسالی به سرور و فیلدهای مربوط به ترتیب مطابق جداول 5 و 6 است.

ساختار بسته‌های ارسالی به سرور

سرویس‌های جمع‌آوری و پردازش اطلاعات

درخواست همگام و غیرهمگام دو سرویس اصلی زیر سامانه جمع‌آوری و پردازش اطلاعات است:

متد غیرهمگام

سرویس درخواست غیرهمگام (ارسال صورتحساب)

ارسال صورتحساب به صورت غیرهمگام انجام می‌شود و جهت ارسال به احراز هویت و امضا دیجیتال صورتحساب و کل لیست ارسالی و همچنین رمزگذاری نیاز است.

برای اینکه ساختار مناسبی برای رهگیری تغییرات بسته‌ها وجود داشته باشد، نوع بسته (PacketType) درصورتحساب به دو بخش تقسیم بندی می‌شود:

نوع بسته (PacketType) درصورتحساب

برای مثال اگر صورتحسابی با نسخه بسته 01 داشته باشیم، نوع بسته به صورت زیر خواهد بود:

INVOICE.V01

فرآیند ارسال صورتحساب مطابق شکل (3) و به شرح ذیل است:

۱. مودی یا TSP با ارسال درخواست توکن به سرور جمعآوری فرآیند ارسال صورتحساب را شروع می‌کند.

۲. توکن دریافت شده در سرآیند درخواست قرار میگیرد و صورتحساب ارسال می‌شود.

۳. مودی یا TSP رسید یکتای دریافت صورتحساب درخواست خود را از سامانه مودیان دریافت می‌کند.

۴. مودی یا TSP می‌تواند به وسیله فراخوانی متدهای استعلام از وضعیت ارسال صورتحساب خود با خبر شود.

فرآیند ارسال صورتحساب

در صورتی که وضعیت درخواست به صورت “PENDING” باشد به این معنی است که هنوز درخواست پردازش نشده است.

نمونه CURL درخواست در پیوست 1-2 ارائه شده است.

ساختار بسته صورتحساب

شناسنامه همه اقلام اطلاعاتی که در انواع و الگوهای صورتحساب وجود دارند به شرح جدول 7 است:

شناسنامه همه اقلام اطلاعاتی
شناسنامه همه اقلام اطلاعاتی
شناسنامه همه اقلام اطلاعاتی

نکته قابل توجه در ارسال اطلاعات صورتحساب این است که در صورتی که پارامتری فاقد مقدار باشد، باید به صورت پیشفرض با مقدار null
ارسال شود یا کال پارامتر ارسال نگردد.

پاسخ درخواست غیرهمگام

پس از دریافت درخواست توسط سرور و بررسی مربوط به الیه انتقال پاسخ مناسب مطابق جداول 8 و 9 به کالینت ارائه می‌شود.

پاسخ درخواست غیرهمگام
پاسخ درخواست غیرهمگام

متدهای همگام

سرویس درخواست‌های همگام

در جدول 10 جزئیات ورودی و خروجی بسته‌های همگام بیان شده است.

شایان ذکر است در متدهای همگام امضای درخواست ارسالی نیاز است و داده‌ها به رمزگذاری نیاز ندارند.

متدهای همگام
متدهای همگام
پاسخ درخواست‌های همگام
پاسخ درخواست‌های همگام
متد دریافت توکن

کالینت‌ها با استفاده از این متد، توکن JWT دریافت می‌کنند. با توجه به اینکه در این سرویس امضای درخواست کننده اجباری است، احراز هویت از طریق آن صورت می‌پذیرد. در صورتی که نام کاربری اعالم شده و امضای آن تطابق داشته باشد، توکن JWT برای کالینت ارسال می‌شود. این توکن طول عمر مشخصی دارد، با منقضی شدن آن، کالینت اقدام به دریافت توکن جدید می‌نمایند. با استفاده از این توکن در سرآیند درخواست‌ها می‌توان از این API ها استفاده کرد.

برای ارسال توکن ابتدا عبارت Bearer اضافه شده سپس توکن ارسال می‌شود. نمونه CURL درخواست در پیوست 2-2 ارائه شده است.

متد استعلام اطلاعات حافظه مالیاتی مودی و حد مجاز فروش مودی

با استفاده از این متد می‌توان اطلاعات حافظه مالیاتی مودی را دریافت نمود.این متد نیاز به احراز هویت نمونه CURL دارد.

درخواست در پیوست 3-2 ارائه شده است.

متد استعلام بسته‌های ارسالی غیرهمگام

برای استعلام وضعیت صورتحساب‌های ارسال شده می‌توان از متدهای ذیل استفاده کرد: این متدها به احراز هویت نیاز دارند.

  • Inquiry_by_uid: کالینت می‌تواند با آرایه ای از UID ها، صورتحساب‌های مورد نظر خود را استعلام نماید. در پاسخ وضعیت آنها باز گردانده می‌شود.نمونه CURL درخواست در پیوست 1-4-2 ارائه شده است.

نکته: وجود fiscalId در ورودی درخواست کنار هر uid ضروری است.

  • Inquiry_by_reference_number: در  این  متد کالینت می‌تواند با آرایه‌ای  از reference_number ها، صورتحساب‌های مورد نظر خود را استعلام نماید. در پاسخ وضعیت آنها باز گردانده می‌شود.

نمونه CURL درخواست در پیوست 2-4-2 ارائه شده است.

  • Inquiry_by_time: با این متد صورتحساب‌های دارای خطا از یک زمان مشخص تا زمان حال مشخص می‌شوند.

نمونه CURL درخواست در پیوست 3-4-2 ارائه شده است.

  • Inquiry_by_time_range: با این متد صورتحساب‌های دارای خطا در یک بازه زمانی مشخص می‌شوند.

نمونه CURL درخواست در پیوست 4-4-2 ارائه شده است.

نکته: فیلد “time” ، تاریخ شمسی با فرمت YYYYMMDD است و دقت شود فقط در خروجی این درخواست بسته‌هایی که وضعیت FAILED دارند برگشت داده می‌شوند.

متد دریافت اطلاعات سرور

این متد برای دریافت اطلاعات عمومی سرور شامل کلیدهای عمومی سازمان، شناسه کلید عمومی که از یک مرکز میانی معتبر اخذ شده است و تاریخ و زمان سرور، مورد استفاده قرار میگیرد. این متد به احراز هویت نیاز ندارد.

نمونه CURL درخواست در پیوست 5-2 ارائه شده است.

متد دریافت لیست کامل شناسه کالا/خدمات و نرخ مالیاتی

این متد برای دریافت لیست شناسه استاندارد کالا‌ها و خدمت‌ها که توسط وزارت صمت ابلاغ شده است مورد استفاده قرار می‌گیرد. با توجه به اینکه حجم نتیجه خروجی این متد ممکن است زیاد باشد، امکان دریافت اطلاعات به صورت صفحه‌بندی شده نیز در نظر گرفته شده است. این متد نیاز به احراز هویت ندارد.

نمونه CURL درخواست در پیوست 6-2 ارائه شده است.

ارسال فیلد فیلتر و مرتب‌سازی در ورودی اختیاری است. شماره صفحه از یک شروع می‌شود. برای مثال اگر 10 رکورد اول را بخواهیم دریافت کنیم ورودی به صورت زیر خواهد بود:

ارسال فیلد فیلتر و مرتب‌سازی
متد استعلام اطلاعات شماره اقتصادی

این متد برای استعلام شماره اقتصادی مورد استفاده قرار می‌گیرد. این متد نیاز به احراز هویت ندارد.

نمونه CURL درخواست در پیوست 7-2 ارائه شده است.

لیست خطاها

مدل داده خطاها

لیست خطاها

لیست خطاهای اولیه انتقال

لیست خطاهای اولیه
لیست خطاهای اولیه

پیوست‌ها

کد نرمال‌سازی JSON به زبان java

منبع: راهرخ

برای دریافت سورس کد نمونه و مشاوره لطفا با شماره ۷۷۹۵۸۲۱۳-۰۲۱ تماس بگیرید.

ابزارها

نوشته‌های تازه

آخرین دیدگاه‌ها

دسته‌ها

تازه ها

YektanetPublisher

انتشار در شبکه‌های اجتماعی!

5 دیدگاه

  1. mah 2023-05-01 در 15:17 - پاسخ

    سلام
    وقتتون بخیر. میشه در نورد فیلد signature توی دریافت توکن توضیح بدید . ممنون میشم

    • رخ شطرنج 2023-05-05 در 09:38 - پاسخ

      ضمن عرض سلام
      signature امضای روی درخواست هست و signatureKeyId هم شناسه کلید عمومی ارسال کننده برای بررسی امضا هست.
      موافق باشید

  2. mostafa aliei 2023-05-13 در 16:39 - پاسخ

    مشکل این متد رو دارمPacketsWrapper

    • مصطفی عزیز
      ضمن عرض سلام، لطفا جهت دریافت مشاوره و نمونه کد با شماره 77958213-021 تماس حاصل فرمایید.

  3. mostafa aliei 2023-05-13 در 16:49 - پاسخ

    signature همون praivet key هست ؟

دیدگاه خود را بنویسید

رفتن به بالا