یکپارچهسازی فاکتور الکترونیکی ترکیه با نرم‌افزار ERP
برای فعالیت در ترکیه، نرم‌افزار ERP معمولاً باید e-Fatura و e-Arşiv — و در برخی صنایع e-İrsaliye — را از طریق اداره درآمد (GİB) و معمولاً با یک یکپارچهساز خصوصی پشتیبانی کند. ERP سند را با ساختار UBL-TR می‌سازد، فروشنده آن را با مهر مالی امضا میکند، یکپارچهساز آن را با GİB تسویه میکند و مسئولیت نگهداری سند تا آخر بر عهده مودی مالیاتی میماند.
نرم‌افزار ERP چه چیزی برای فعالیت در ترکیه باید پشتیبانی کند؟
ترکیه صدور فاکتور الکترونیک را بهصورت سامانه تسویه (Clearance) اجرا میکند: سند را فروشنده می‌سازد، از طریق مجاز کانال ارسال میشود، اداره درآمد آن را تأیید میکند و تازه پس از آن اثر قانونی دارد. برای کسب‌وکاری که عملیاتش را روی ERP می‌چرخاند، این در چهار نقطه سامانه پیامد دارد:
- ایجاد سند. ERP — یا یک موتور متصل — باید فاکتورها را با ساختار لازم UBL-TR تولید کند، با کدها، شناسه‌های طرفین و داده‌های سطح ردیفی که طرحواره می‌خواهد، نه چیدمان چاپی که به XML تبدیل شده باشد.
- امضای دیجیتال. اسناد با مهر مالی صادرشده برای مودی امضا میشوند؛ گام امضا باید داخل جریان کار بنشیند و مدیریت کلیدها با ترتیب نگهداری مهر هم‌خوان باشد.
- مبادله دوسویه. در رژیم e-Fatura، وضعیت ثبت طرف مقابل نوع سند را تعیین میکند و اسناد وارده — فاکتورهای دریافتی، پاسخ‌ها، ابطال‌هایی که مجاز است — باید با شناسه‌های اصلی‌شان به ERP برگردند، وگرنه حسابداری پیوند میان سامانه و سند رسمی را از دست میدهد.
- بایگانی و بازیابی. اسناد صادر و دریافت‌شده باید در مدت مقرر نگهداری قابل بازیابی باشند؛ اینکه یکپارچهساز نگه دارد، ERP نگه دارد یا هر دو، تصمیمی است که باید پیش از راهاندازی گرفته شود، نه بعد از یک درخواست ممیزی.
یک نکته ساختاری که تیم‌های تازه‌کار با سامانه تسویه را شگفت‌زده میکند: فاکتور وقتی ERP آن را چاپ میکند تمام نشده است. تمام میشود وقتی مبادله کامل و پاسخ‌ها بازگردد؛ یعنی تصور ERP از وضعیت فاکتور باید فراتر از «ایجادشده» و «ارسال‌شده» برود و پذیرفته‌شده، ردشده و اصلاح‌شده را هم در بر بگیرد. کسب‌وکارهایی که این را رد کنند، آخر ماه دو نسخه از حقیقت — دفتر خودشان و سند رسمی — را دستی با هم تطبیق می‌دهند، و دقیقاً همان کاری است که فاکتور الکترونیک قرار بود حذف کند.
نکته دیگر به زمان‌بندی مربوط میشود. اسناد در یک سامانه تسویه، ناهمگام به شیوه پیوست ایمیل نیستند: ردشدن سند درست وقتی می‌رسد که تیم هنوز کار میکند و اصلاحی که می‌خواهد معمولاً داده پایه را می‌زند، نه خود سند را. جریان را طوری بسازید که کسی که میتواند ریشه را درست کند همان لحظه خبردار شود، نه اینکه در گزارش ماهانه کشف کند؛ این تفاوت میان سامانه‌ای است که کار میکند و سامانه‌ای که باید مراقبش بود.
e-Fatura، e-Arşiv و e-İrsaliye چه هستند؟
| سند | کاربرد | محرک معمول | نکته |
|---|---|---|---|
| e-Fatura | فاکتورهای B2B و کسب‌وکار-به-دولت میان مودیان ثبتشده این رژیم | هر دو طرف برای e-Fatura ثبت شده‌اند | سند ساختاریافته‌ای که میان طرفین ثبتشده مبادله میشود؛ وضعیت طرف مقابل مسیر را تعیین میکند |
| e-Arşiv | فاکتورهایی که خریدار برای e-Fatura ثبت نیست — خردهفروشی و B2C و برخی B2B | فروشنده در دامنه است؛ خریدار خارج از رژیم e-Fatura | برای خریدار بهصورت PDF تولید میشود، اما از همان زنجیره رسمی ساخته و اعلام میشود |
| e-İrsaliye | بارنامه الکترونیک برای صنایع و معاملات تعیین‌شده در قواعد | حمل کالا در گردش‌کارهای پوشش‌داده‌شده | با فاکتور جفت میشود: بارنامه و فاکتور به هم ارجاع می‌دهند |
| e-Defter | دفاتر و سوابق — دفتر کل و دفتر روزنامه — که الکترونیک اعلام میشوند | مودیان مشمول، طبق قواعد قابل اجرا | تعهدی جدا از فاکتور الکترونیک، اما معمولاً در همان پروژه برنامه‌ریزی میشود |
اینکه چه کسی مشمول کدام تعهد میشود را قواعد و بیانیه‌های GİB تعریف میکنند که عوض میشوند؛ آستانه‌ها و تعیین صنایع را مقامات می‌گذارند و همراه خودشان تغییر میکنند. بیان درست برای یک خریدار، بیانی رویه‌ای است: وضعیت ثبت خود را با حسابدار یا مشاور مالیاتی در برابر قواعد فعلی بررسی کنید، پیش از طراحی یکپارچهسازی — نه در برابر یک مقاله، از جمله همین مقاله.
گزینه‌های یکپارچهسازی
| گزینه | انطباق | تلاش در ERP | نکات پیش‌گیرانه |
|---|---|---|---|
| پورتال GİB | حجم بسیار کم، صدور دستی | هیچ | دستی، کند، هدف طراحی برای کسب‌وکار دارای ERP نیست؛ فقط بهعنوان جایگزین نگه دارید |
| یکپارچهساز خصوصی (özel entegratör) | مسیر رایج برای بیشتر کسبوکارها | اتصال به API یا قالب یکپارچهساز، به‌علاوه نگاشت | مقایسه یکپارچه‌سازها بر اساس پشتیبانی و کیفیت API مهم‌تر از لوگوست؛ بپرسید چه کسی به‌روزرسانی‌های طرحواره را نگهداری میکند |
| دسترسی مستقیم GİB | عملیات بزرگ‌تری که کنترل کامل می‌خواهند | زیاد: مسئولیت فنی و عملیاتی کانال را خودتان به عهده می‌گیرید | کسب و راهاندازی آن پیچیده‌تر است؛ در عمل نادر توصیف میشود — آن را استثنایی بدانید که باید توجیه کنید، نه پیش‌فرض |
مدل یکپارچهساز به یک شفاف‌سازی نیاز دارد، چون اغلب بد فهمیده میشود: استفاده از یکپارچهساز خصوصی تعهدات مودی را منتقل نمی‌کند. یکپارچهساز کانال فنی، انتقال و خدمت نگهداری را فراهم میکند؛ مسئولیت قانونی اسناد — درستی‌شان، صدورشان و نگهداری‌شان طبق قانون آیین دادرسی مالیاتی — بر عهده مودی میماند. وقتی صفحه فروش یکپارچه‌ای طوری به نظر می‌رسد که مسئله انطباق را دارد برایتان حل میکند، آن جمله را دوباره بخوانید.
در عمل این تفکیک به شیوه‌های کوچک و مشخص خودش را نشان میدهد. اگر سندی رد شد چون شناسه مالیاتی مشتری در داده پایه شما غلط بود، سامانه یکپارچهساز بی‌عیب کار کرده و خطا را شما باید درست کنید. اگر فاکتوری با کد مالیاتی غلط صادر شده باشد، هیچ کانالی نجاتتان نمی‌دهد. یکپارچهساز زیرساخت است؛ کیفیت داده‌ای که از آن جاری میشود انضباط داخلی است و ERP جایی است که این انضباط یا در آن تعبیه میشود یا به عادت سپرده. خریدارانی که یکپارچه‌سازها را مقایسه میکنند پس باید زمان کمتری را صرف فهرست قابلیت‌ها و بیشتر را صرف پرسش‌هایی کنند که آشکار میکند وقتی چیزی خطا می‌رود چه کسی چه میکند: چه کسی چه کسی را با چه قالبی خبر میکند و سند اصلاح‌شده چقدر سریع میتواند دوباره ارسال شود.
مراحل استقرار و آزمون
ترتیب کاربردی برای یکپارچهسازی سمت ERP:
- تعیین دامنه تعهدات. کدام اسناد برای کسب‌وکار مصداق دارند — e-Fatura، e-Arşiv، e-İrsaliye، e-Defter — که با حسابدار شرکت در برابر قواعد فعلی تأیید شود.
- انتخاب کانال. بیشتر کسبوکارها یکپارچهساز خصوصی انتخاب میکنند؛ پرسش‌های انتخاب — کیفیت API، در دسترس‌بودن sandbox، زبان و ساعات پشتیبانی، نحوه مدیریت بهروزرسانی طرحواره، مراجع — خودشان یک تمرین فهرست کوتاه می‌خواهند.
- نگاشت داده پایه. مشتریان و شناسه‌های مالیاتی‌شان، اقلام، واحدها، ارزها و کدهای مالیاتی باید با انتظارات طرحواره نگاشت شوند؛ عدم تطبیق اینجا بزرگ‌ترین منبع واحد خطاهای بعدی است.
- طراحی جریان سند. چه کسی چه چیزی را می‌سازد، مهر کِی زده میشود، در خطا چه اتفاقی می‌افتد، اسناد رونده و وارده چگونه با سابقه ERP تطبیق می‌یابند و اصلاحات چگونه صادر میشوند.
- استفاده از محیط آزمایشی. هر دو طرف محیط آزمایشی دارند؛ پیش از راهاندازی هر نوع سند، هر مسیر خطا و هر سناریوی اصلاح را از آن رد کنید، با همان نگاشتی که در محیط عملیاتی به کار می‌رود.
- مدیریت خطا به‌مثابه فرایند. ردشدن‌ها پس از ارسال می‌آیند؛ کسی باید آن‌ها را ببیند، علت را بفهمد و داده زیرین را اصلاح کند — صندوق اعلان بدون مالک همان چیزی است که با آن کسب‌وکار دیرهنگام سند صادر میکند.
- برنامه‌ریزی بایگانی و دسترسی. اسناد کجا نگهداری میشوند، چه کسی میتواند آن‌ها را بازیابی کند، و درخواست ممیز چگونه در مدت نگهداری پاسخ داده میشود.
نکات مالک خارجی و غیرمقیم که باید از مشاور بپرسید
برای شرکتی با مالک خارجی، یا شرکتی که بدون تیم مالی کامل محلی وارد ترکیه میشود، چند پرسش جای مشاور مالیاتی دارد نه پروژه IT — پاسخ‌ها طراحی را تعیین میکنند، پس پیش از شروع یکپارچهسازی بپرسید، نه بعد از آن:
- مسیر ثبت. شرکت چگونه مشمول تعهدات میشود، چه کسی درخواست‌ها را امضا میکند و کدام نماینده پذیرفته میشود — پرسش‌های ثبت مالیاتی، نه نرم‌افزار.
- ترتیب مهر. مهر مالی چگونه برای شرکت گرفته میشود و نگهداری آن وقتی امضاکنندگان خارج از ترکیه‌اند چگونه سازمان می‌یابد.
- نمایندگان و امضاها. چه کسی مجاز است کدام اسناد را امضا کند و ERP باید درباره امضاکننده چه چیزی برای ردپای ممیزی ثبت کند.
- وضعیت شرکت فرعی خارجی. آیا الزامات اضافه‌ای برای شرکت‌هایی با مالکیت غیرمقیم اعمال میشود و فاکتورگذاری درون‌گروهی چگونه رفتار میشود.
همچنین ارزش دارد تصمیم بگیرید مالک رابطه با مشاور چه کسی است. در شرکت‌هایی که مالی و IT هر دو فرض میکنند طرف دیگر پرسیده، این نکات دیر به یکپارچهسازی می‌رسند — معمولاً در هفته‌های پیش از راهاندازی، وقتی جریان سند از قبل ثابت شده. یک مالک مشخص در هر طرف و یک جلسه مشترک پیش از گام 3 استقرار، بخش بزرگی از این‌ها را پیشگیری میکند.
مشکلات رایج
شکست‌هایی که در این دسته پروژه بیش از همه دیده میشوند و هرکدام معمولاً به چه چیزی اشاره میکنند:
- ردشدن در راستی‌آزمایی. تقریباً همیشه مشکل نگاشت: کد مالیاتی، قالب شناسه یا فیلد سطح ردیفی که با انتظار طرحواره نمی‌خواند. داده پایه را درست کنید، نه منطق تلاش مجدد را.
- شماره‌گذاری تکراری. توالی‌های شماره تولیدشده از بیش از یک سامانه، یا تولیددوباره پس از خطا؛ شماره‌گذاری باید دقیقاً یک مالک و قاعده بازیابی مستند داشته باشد.
- خطای وضعیت طرف مقابل. صدور نوع سند غلط چون وضعیت ثبت مشتری کش یا فرض شده؛ وضعیت را طبق قواعد یکپارچهساز بگیرید، نه طبق حافظه.
- گم‌شدن اسناد وارده. اسنادی که دریافت شده اما هرگز در ERP ثبت نشده‌اند، پس حساب‌های پرداختنی از صفحه جدا کار میکنند؛ جهت مبادله بخشی از یکپارچهسازی است، نه افزودنی اختیاری.
- جاماندن از بهروزرسانی طرحواره. ساختار در طول زمان عوض میشود؛ هر کسی مسئول است باید بداند کِی عوض شد و تغییر چه کرد بر نگاشت.
- زیر فشار موعد ردکردن آزمون. هر مشکل بالا در محیط آزمایشی ارزان‌تر است؛ فشار راهاندازی جایی است که به رخداد تبدیل میشوند.
پرسش‌های متداول
تفاوت e-Fatura و e-Arşiv چیست؟
e-Fatura فاکتورهایی را پوشش میدهد که میان مودیان ثبتشده در همین رژیم مبادله میشوند، بهصورت اسناد ساختاریافته میان طرفین ثبتشده؛ e-Arşiv فاکتورهایی را پوشش میدهد که خریدار خارج از آن رژیم است — خردهفروشی و B2C و برخی B2B — که خریدار معمولاً آن را بهصورت PDF دریافت میکند که از همان زنجیره رسمی تولید شده. اینکه کدام برای یک فاکتور مشخص مصداق دارد از وضعیت ثبت طرف مقابل میآید، و به همین دلیل یکپارچهسازی آن را بررسی میکند، نه فرض.
آیا به یکپارچهساز خصوصی نیاز دارم؟
برای بیشتر کسبوکارها بله — این مسیر رایج است و کانال مستقیم پیچیده و نادر توصیف میشود. یکپارچهساز خصوصی کانال فنی به GİB و خدمت نگهداری فراهم میکند؛ تعهدات شما بهعنوان مودی همچنان خودتان است. انتخاب آن یک تمرین تدارکات است: کیفیت API، sandbox، پشتیبانی و مدیریت بهروزرسانی طرحواره، تجربه روزمره را بیش از برند تعیین میکنند.
مهر مالی (mali mühür) چیست؟
اعتبار امضای دیجیتال مودی است که برای امضای اسناد الکترونیک پیش از ارسال به کار می‌رود؛ نگهداری آن و اینکه چه کسی میتواند استفاده کند، پرسش‌های عملی‌ای هستند که باید داخل شرکت حل شوند. برای تیم‌هایی که امضاکنندگانشان خارج از ترکیه‌اند، ترتیب اینکه چه کسی مهر را نگه می‌دارد و اعمال میکند از اولین نکاتی است که باید پیش مشاور مالیاتی بگذارید.
آیا هر نرم‌افزار ERPای میتواند فاکتور الکترونیکی ترکیه صادر کند؟
خیر. ERP باید ساختار UBL-TR لازم را با داده پایه درست تولید کند، یا به موتور یا یکپارچهسازی وصل باشد که این کار را بکند؛ چیدمان فاکتور استاندارد کافی نیست. بیشتر کسبوکارها پس به‌جای بازسازی وصل میکنند — پرسشی که باید از فروشنده بپرسید این است که کانکتورش کدام یکپارچه‌سازها را پشتیبانی میکند، چه چیزی را نگاشت میکند و مستنداتش کجاست.
پیش از راهاندازی چطور آزمایش کنم؟
از محیطهای آزمایشی ارائهشده در طرف یکپارچهساز و طرف رسمی، با همان نگاشت داده پایه محیط عملیاتی: هر نوع سند، هر مسیر ردشدن، هر اصلاح و هر سند وارده را که باید در ERP ثبت شود. آزمون را تمرین فرایند خطا هم بدانید — کسی باید ردشدن را دریافت، تشخیص و درست کند، نه فقط تیک سبز را ببیند.
فاکتورها را چه کسی نگهداری میکند؟
مودی طبق قانون آیین دادرسی مالیاتی مسئول نگهداری میماند؛ یکپارچهساز معمولاً نگهداری فنی را فراهم میکند و بسیاری از کسبوکارها اسناد را برای کار روزمره در ERP خودشان هم نگه میدارند. آنچه مهم است تصمیمگیری درباره این ترتیب پیش از راهاندازی، دانستن اینکه چه کسی میتواند کدام سند را در مدت نگهداری تحویل دهد، و آزمایش بازیابی پیش از آنکه ممیز درخواست کند است.
منابع و استانداردها
- GİB — اداره کل درآمد — اداره درآمد قواعد، بیانیه‌ها و مستندات فنی e-Fatura، e-Arşiv، e-İrsaliye و e-Defter را منتشر میکند؛ نسخه‌های فعلی آنجا هرچه را در این صفحه خلاصه شده ناقص میکند.
- وضعیت ثبت، آستانه‌ها، تعیین صنایع و مهلت‌ها را مقامات می‌گذارند و تغییر میکنند؛ با حسابدار یا مشاور مالیاتی خود در برابر قواعد فعلی تأیید کنید. هیچ‌چیز در این صفحه مشاوره مالیاتی نیست و برای WorldwideTradeX هیچ رابطه یکپارچهساز، شراکت یا گواهی‌ای ادعا نشده است.
صفحات مرتبط
توسعه نرم‌افزار · Odoo ERP برای شرکت‌های تجاری · ERP سفارشی در برابر بسته‌ای · ممیزی و مشاوره IT · درخواست قیمت