آلمان

حسابداری

دفتر حساب‌ها

هر دو chart of accounts ـ SKR03 و SKR04 در Odoo پشتیبانی می‌شوند. هنگامی که یک پایگاه داده Odoo Online جدید ایجاد می‌کنید، SKR03 به‌طور پیش‌فرض نصب می‌شود.

با رفتن به Accounting ↤ Configuration ↤ Settings و بررسی فیلد Package در بخش Fiscal Localization، بررسی کنید کدام نصب شده است.

هشدار

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

گزارش‌ها

گزارش‌های مخصوص آلمان زیر در Odoo Enterprise در دسترس هستند:

• ترازنامه

• سود و زیان

• گزارش مالیات (Umsatzsteuervoranmeldung)

• EC Sales List

• اینتراستات

خروجی گرفتن اسناد از Odoo به DATEV

به شرطی که یکی از بسته‌های بومی‌سازی مالیاتی آلمانی نصب شده باشد، می‌توانید اسناد حسابداری خود را از Odoo به DATEV از general ledger خروجی بگیرید.

دو نوع خروجی لازم است: ابتدا خروجی DATEV ATCH، سپس خروجی DATEV DATA.

توجه

هر دو در مراحل مختلف برای انتقال صحیح داده‌ها به DATEV مورد نیاز هستند، زیرا DATEV با دو رابط کار می‌کند، یکی برای مشتریان (DUO - DATEV Unternehmen Online) و یکی برای مشاوران مالیاتی (DATEV Rechnungswesen).

1. DATEV ATCH

به Accounting ↤ Reporting ↤ General Ledger بروید، دکمه (Actions) را کلیک کنید و Datev ATCH (zip) را انتخاب کنید.

فایل ZIP دانلودشده را از طریق نرم‌افزار DATEV Belegtransfer آپلود کنید.

اگر نرم‌افزار DATEV Belegtransfer روی کامپیوتر شما نصب نیست، از مشاور مالیاتی خود بخواهید در این کار به شما کمک کند.

هشدار

فایل DATEV ATCH ZIP شامل فایل‌ها (گزارش‌ها) مرتبط با یک فاکتور یا صورتحساب Odoo است. برای فاکتورهای مشتری، فایل باید با استفاده از دکمه Send تولید شده باشد. برای صورتحساب‌های فروشنده، فایل باید از طریق یک email alias دریافت شده باشد یا با استفاده از دکمه Upload آپلود شده باشد.

فایل DATEV ATCH ZIP

فایل ZIP شامل دو نوع فایل است:

• فایل‌های منفرد فاکتور/صورتحساب (PDF، JPEG و غیره) برای دوره انتخاب‌شده در general ledger، و

• یک فایل document.xml که برای تولید یک شناسه منحصربه‌فرد (GUID) برای هر فایل استفاده می‌شود.

این شناسه‌های منحصربه‌فرد ضروری هستند زیرا به DATEV اجازه می‌دهند فایل‌ها را به‌طور خودکار به اقلام منفرد ژورنال پیوند دهد، که با فایل DATEV DATA در گام بعدی وارد می‌شوند.

2. DATEV DATA

به Accounting ↤ Reporting ↤ General Ledger بروید، دکمه (Actions) را کلیک کنید و Datev DATA (zip) را انتخاب کنید.

فایل ZIP دانلودشده را به مشاور مالیاتی خود منتقل کنید. آن‌ها باید فایل ZIP را به DATEV Rechnungswesen وارد کنند.

با مشاور مالیاتی خود بررسی کنید که چند وقت یک‌بار به این فایل‌ها نیاز دارد.

فایل DATEV ATCH ZIP

فایل ZIP شامل سه فایل CSV است:

• فایل EXTF_customer_accounts.csv که شامل همه اطلاعات مرتبط با مشتریان شما است،

• فایل EXTF_vendor_accounts.csv که شامل همه اطلاعات مرتبط با فروشندگان شما است، و

• فایل EXTF_accounting_entries.csv که شامل همه اقلام ژورنال برای دوره تعریف‌شده در general ledger و همچنین شناسه‌های منحصربه‌فرد (GUID) است تا اقلام ژورنال بتوانند به فایل‌های داخل فایل DATEV ATCH ZIP پیوند داده شوند.

انطباق GoBD

GoBD مخفف Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff است. به‌طور خلاصه، این یک راهنما برای مدیریت و ذخیره‌سازی صحیح کتاب‌ها، سوابق و اسناد به‌صورت الکترونیکی و همچنین دسترسی به داده‌ها است که با مقام مالیاتی آلمان، اظهارنامه مالیاتی و balance sheet مرتبط است.

این اصول توسط وزارت دارایی فدرال (BMF) در نوامبر ۲۰۱۴ نوشته و منتشر شده‌اند. از ژانویه ۲۰۱۵، آن‌ها به یک هنجار تبدیل شده‌اند و جایگزین رویه‌های پذیرفته‌شده قبلی مرتبط با حسابداری مبتنی بر کامپیوتر شده‌اند. چندین تغییر توسط BMF در ۲۰۱۹ و ژانویه ۲۰۲۰ برای مشخص کردن برخی از محتویات به دلیل توسعه راه‌حل‌های دیجیتال (cloud hosting، شرکت‌های بدون کاغذ و غیره) انجام شده است.

مهم

Odoo به‌عنوان GoBD-compliant گواهی شده است.

فهم GoBD در ارتباط با نرم‌افزار حسابداری

GoBD برای شرکت‌هایی که باید حساب‌ها را به مقامات مالی ارائه دهند الزام‌آور است، که شامل SMEs، freelancers و entrepreneurs می‌شود. به این ترتیب، خود مودی مالیاتی تنها مسئول نگهداری کامل و جامع داده‌های مرتبط با مالیات (داده‌های مالی و مرتبط ذکرشده در بالا) است.

علاوه بر الزامات نرم‌افزاری، کاربر ملزم است سیستم‌های کنترل داخلی را تضمین کند (مطابق با بخش ۱۴۶ Fiscal Code):

• کنترل حقوق دسترسی؛

• تفکیک وظایف، جدایی عملکردی؛

• کنترل‌های ورودی (اعلان‌های خطا، plausibility checks)؛

• بررسی‌های تطبیق در زمان ورود داده‌ها؛

• کنترل‌های پردازش؛ و

• اقداماتی برای جلوگیری از دستکاری عمدی یا غیرعمدی نرم‌افزار، داده‌ها یا اسناد.

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

امنیت داده‌ها

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

هنگامی که bookings نهایی ثبت شدند، دیگر نمی‌توانند از طریق اپلیکیشن تغییر یا حذف شوند.

• اگر Odoo در cloud استفاده می‌شود، پشتیبان‌گیری منظم بخشی از سرویس Odoo Online است. علاوه بر این، پشتیبان‌گیری‌های منظم می‌توانند دانلود و در سیستم‌های خارجی پشتیبان‌گیری شوند.

  همچنین ببینید

  Odoo Cloud Hosting - Service Level Agreement

• اگر سرور به‌صورت محلی اداره می‌شود، کاربر مسئول ایجاد زیرساخت پشتیبان‌گیری لازم است.

مهم

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

مسئولیت ویرایش‌گر نرم‌افزار

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

تضمین انطباق از طریق Odoo

کلمات کلیدی هنگامی که صحبت از GoBD می‌شود عبارتند از: قابل ردیابی، قابل تأیید، صحیح، روشن و پیوسته. به‌طور خلاصه، شما باید آرشیو audit-proof در محل داشته باشید و Odoo ابزار رسیدن به همه این اهداف را در اختیار شما قرار می‌دهد:

1. قابلیت ردیابی و تأیید

   هر رکورد در Odoo با ایجادکننده سند، تاریخ ایجاد، تاریخ اصلاح و کسی که آن را اصلاح کرده است stamp می‌شود. علاوه بر این، فیلدهای مرتبط ردیابی می‌شوند. بنابراین، می‌توان دید چه مقداری توسط چه کسی در چتر آبجکت مربوطه تغییر کرده است.
2. کامل بودن

   همه داده‌های مالی باید در سیستم ثبت شوند و نمی‌توان شکافی داشت. Odoo تضمین می‌کند که هیچ شکافی در شماره‌گذاری تراکنش‌های مالی وجود ندارد. این مسئولیت کاربر است که همه داده‌های مالی را در سیستم ثبت کند. از آنجا که بیشتر داده‌های مالی در Odoo به‌طور خودکار تولید می‌شوند، مسئولیت ثبت کامل همه صورتحساب‌های فروشنده و عملیات متفرقه بر عهده کاربر باقی می‌ماند.
3. صحت

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

   از آنجا که بیشتر داده‌های مالی در Odoo توسط آبجکت‌های تراکنشی تولید می‌شوند (به‌عنوان مثال، فاکتور در زمان تأیید ثبت می‌شود)، Odoo نگهداری به‌موقع سوابق را به‌صورت آماده تضمین می‌کند. این مسئولیت کاربر است که همه صورتحساب‌های فروشنده ورودی را به‌موقع، همچنین عملیات متفرقه را ثبت کند.
5. ترتیب

   داده‌های مالی ذخیره‌شده در Odoo، طبق تعریف، مرتب هستند و می‌توانند بر اساس بیشتر فیلدهای موجود در مدل دوباره مرتب شوند. ترتیب خاصی توسط GoBD اجباری نیست، اما سیستم باید تضمین کند که یک تراکنش مالی معین می‌تواند به‌سرعت توسط یک کارشناس شخص ثالث یافت شود. Odoo این را به‌صورت آماده تضمین می‌کند.
6. Inalterability

   با بومی‌سازی آلمانی Odoo، Odoo به‌صورت استاندارد به گونه‌ای پیکربندی شده است که بند inalterability می‌تواند بدون هیچ سفارشی‌سازی بیشتری رعایت شود.

خروجی GoBD

در مورد کنترل مالیاتی، مقام مالیاتی می‌تواند سه سطح دسترسی به سیستم حسابداری (Z1، Z2، Z3) درخواست کند. این سطوح از دسترسی مستقیم به رابط تا تحویل داده‌های مالی روی یک دستگاه ذخیره‌سازی متفاوت هستند.

در مورد تحویل داده‌های مالی به یک دستگاه ذخیره‌سازی، GoBD قالب را اجباری نمی‌کند. می‌تواند، به‌عنوان مثال، در XLS، CSV، XML، Lotus 123، SAP-format، AS/400-format یا چیز دیگری باشد. Odoo از خروجی CSV و XLS داده‌های مالی به‌صورت آماده پشتیبانی می‌کند. GoBD خروجی را در یک قالب GoBD مبتنی بر XML خاص توصیه می‌کند (نگاه کنید به "Ergänzende Informationen zur Datenträgerüberlassung" §3)، اما الزام‌آور نیست.

عدم انطباق

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

صندوق فروش

سیستم امنیت فنی

Kassensicherungsverordnung (قانون حفاظت در برابر دستکاری سوابق دیجیتال) ایجاب می‌کند که سیستم‌های نگهداری سوابق الکترونیکی - شامل سیستم‌های صندوق فروش - باید به یک سیستم امنیت فنی (که TSS یا TSE نیز نامیده می‌شود) مجهز باشند.

Odoo سرویسی را ارائه می‌دهد که با کمک fiskaly، یک راه‌حل cloud-based، منطبق است.

مهم

از آنجا که این راه‌حل cloud-based است، یک اتصال اینترنتی فعال مورد نیاز است.

توجه

تنها نرخ‌های VAT مجاز توسط fiskaly داده می‌شوند. می‌توانید این نرخ‌ها را با مراجعه به fiskaly DSFinV-K API: VAT Definition بررسی کنید.

پیکربندی

ماژول‌های Germany - Certification for Point of Sale (l10n_de_pos_cert) و Germany - Certification for Point of Sale of type restaurant (l10n_de_pos_res_cert) را نصب کنید.

نکته

اگر این ماژول‌ها فهرست نشده‌اند، فهرست اپلیکیشن‌ها را به‌روزرسانی کنید.

ثبت شرکت در مقام مالی

برای ثبت شرکت خود، اپلیکیشن Settings را باز کنید، روی Update Info در بخش Companies کلیک کنید و فیلدهای زیر را پر کنید:

• نام شرکت

• Address

• VAT

• St.-Nr. (Steuernummer) این شماره توسط اداره مالیات به هر شخص حقیقی یا حقوقی مشمول مالیات اختصاص داده می‌شود (مثلاً 2893081508152).

• W-IdNr. (Wirtschafts-Identifikationsnummer) این شماره به‌عنوان شناسه دائمی برای اشخاص فعال اقتصادی استفاده می‌شود.

سپس می‌توانید شرکت خود را از طریق fiskaly ثبت کنید با باز کردن تب Fiskaly و کلیک روی دکمه Fiskaly Registration.

نکته

اگر دکمه Fiskaly Registration را نمی‌بینید، اطمینان حاصل کنید که جزئیات شرکت خود را ذخیره کرده‌اید و دیگر در editing mode نیستید.

پس از نهایی شدن ثبت، فیلدهای جدیدی ظاهر می‌شوند:

• Fiskaly Organization ID به شناسه شرکت شما در سمت fiskaly اشاره دارد.

• Fiskaly API Key و Fiskaly API Secret اعتبارنامه‌هایی هستند که سیستم برای دسترسی به سرویس‌های ارائه‌شده توسط fiskaly از آن‌ها استفاده می‌کند.

توجه

اگر مشکلی با اعتبارنامه‌های فعلی وجود دارد، می‌توان با کلیک روی دکمه New keys اعتبارنامه‌های جدید درخواست کرد.

ایجاد یک سیستم امنیت فنی و پیوند آن به یک POS

برای استفاده از یک صندوق فروش در آلمان، ابتدا یک TSS ایجاد کنید با رفتن به Point of Sale ↤ Configuration ↤ Point of Sale، انتخاب Point of Sale برای ویرایش، سپس تیک زدن چک‌باکس Create TSS در بخش Fiskaly API.

پس از موفقیت‌آمیز بودن ایجاد TSS، می‌توانید موارد زیر را بیابید:

• TSS ID، که به شناسه TSS شما در سمت fiskaly اشاره دارد، و

• Fiskaly Client ID، که به POS شما در سمت fiskaly اشاره دارد.

خروجی DSFinV-K

هرگاه POS register را می‌بندید، جزئیات سفارش‌ها به سرویس DSFinV-K از fiskaly ارسال می‌شوند.

در صورت audit، می‌توانید داده‌های ارسال‌شده به DSFinV-K را با رفتن به Point of Sale ↤ Orders ↤ DSFinV-K Exports ↤ New خروجی بگیرید.

این فیلدها الزامی هستند:

• Start Datetime: داده‌ها با تاریخ‌های بزرگ‌تر یا مساوی با تاریخ شروع داده‌شده را خروجی بگیرید

• End Datetime: داده‌ها با تاریخ‌های کوچک‌تر یا مساوی با تاریخ پایان داده‌شده را خروجی بگیرید

فیلد Point of Sale را خالی بگذارید تا داده‌های همه صندوق‌های فروش خود را خروجی بگیرید؛ اگر می‌خواهید فقط داده‌های این POS خاص را خروجی بگیرید، یکی را مشخص کنید.

وقتی یک خروجی با موفقیت آغاز می‌شود و در حال پردازش است، فیلد State باید Pending را ذکر کند. روی Refresh State کلیک کنید تا بررسی کنید آیا آماده است.