Німеччина¶
Бухоблік¶
План рахунків¶
В Odoo підтримуються обидва плани рахунків SKR03 та SKR04. Коли ви створюєте нову базу даних Odoo Online, SKR03 встановлюється за замовчуванням.
Перевірте, який встановлено, перейшовши до та перевіривши поле Пакет у розділі Фіскальна локалізація.
Попередження
Вибір іншого пакета можливий лише за умови, що ви не створили бухгалтерський запис. Якщо запис було проведено, для вибору іншого пакета необхідно налаштувати нову компанію або базу даних. Крім того, всі бухгалтерські записи потрібно буде створити знову.
Звіти¶
Наступні специфічні для Німеччини звіти доступні в Odoo Enterprise:
Бухгалтерський баланс
Доходи та витрати
Податковий звіт (Umsatzsteuervoranmeldung)
Список продажів EC
Intrastat
Експорт записів з Odoo до DATEV¶
За умови, що встановлено один із німецьких пакетів фіскальної локалізації, ви можете експортувати свої бухгалтерські записи з Odoo до DATEV з головної книги.
Необхідні два типи експорту: спочатку експорт DATEV ATCH, потім експорт DATEV DATA.
Примітка
Обидва потрібні на різних етапах для правильної передачі даних до DATEV, оскільки DATEV працює з двома інтерфейсами: одним для клієнтів (DUO - DATEV Unternehmen Online) і одним для податкових консультантів (DATEV Rechnungswesen).
1. DATEV ATCH¶
Перейдіть до , натисніть кнопку (Дії) і виберіть Datev ATCH (zip).
Завантажте завантажений ZIP-файл через програмне забезпечення DATEV Belegtransfer.
Примітка
Якщо у вас не встановлено програмне забезпечення DATEV Belegtransfer на вашому комп’ютері, попросіть вашого податкового консультанта допомогти вам з цим.
Попередження
ZIP-файл DATEV ATCH містить файли (звіти), пов’язані з рахунком-фактурою або рахунком Odoo. Для рахунків-фактур клієнтів файл має бути створений за допомогою кнопки Надіслати. Для рахунків постачальників файл має бути отриманий через псевдонім електронної пошти або завантажений за допомогою кнопки Завантажити.
ZIP-файл DATEV ATCH
ZIP-файл містить два типи файлів:
окремі файли рахунків-фактур/рахунків (PDF, JPEG тощо) за обраний період у головній книзі, та
файл
document.xml, що використовується для генерації унікального ID (GUID) для кожного файлу.
Ці унікальні ID є важливими, оскільки вони дозволяють DATEV автоматично пов’язувати файли з окремими записами журналу, які будуть імпортовані разом із файлом DATEV DATA на наступному кроці.
2. DATEV DATA¶
Перейдіть до , натисніть кнопку (Дії) і виберіть Datev DATA (zip).
Передайте завантажений ZIP-файл своєму податковому консультанту. Він повинен імпортувати ZIP-файл у DATEV Rechnungswesen.
Уточніть у свого податкового консультанта, як часто йому потрібні ці файли.
ZIP-файл DATEV ATCH
ZIP-файл містить три CSV-файли:
файл
EXTF_customer_accounts.csv, що містить всю інформацію, пов’язану з вашими клієнтами,файл
EXTF_vendor_accounts.csv, що містить всю інформацію, пов’язану з вашими постачальниками, тафайл
EXTF_accounting_entries.csv, що містить усі записи журналу за період, визначений у головній книзі, а також унікальні ID (GUID), щоб записи журналу можна було пов’язати з файлами в ZIP-файлі DATEV ATCH.
Відповідність GoBD¶
GoBD означає Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff. Коротко кажучи, це керівництво щодо належного управління та зберігання книг, записів і документів в електронній формі, а також доступу до даних, яке є актуальним для німецької податкової служби, податкової декларації та балансу.
Ці принципи були написані та опубліковані Федеральним міністерством фінансів (BMF) у листопаді 2014 року. З січня 2015 року вони стали нормою і замінили раніше прийняті практики, пов’язані з комп’ютеризованим обліком. BMF внесло кілька змін у 2019 та січні 2020 року, щоб уточнити частину змісту через розвиток цифрових рішень (хмарне зберігання, безпаперові компанії тощо).
Важливо
Odoo сертифіковано як сумісне з GoBD.
Розуміння GoBD стосовно бухгалтерського програмного забезпечення¶
GoBD є обов’язковим для компаній, які повинні подавати звітність, що включає МСП, фрілансерів та підприємців, до фінансових органів. Таким чином, сам платник податків несе повну відповідальність за повне та вичерпне ведення фіскально-релевантних даних (вищезгаданих фінансових та пов’язаних даних).
Окрім вимог до програмного забезпечення, від користувача вимагається забезпечити системи внутрішнього контролю (відповідно до розділу 146 Податкового кодексу):
контроль прав доступу;
розподіл обов’язків, функціональне розділення;
контроль введення (повідомлення про помилки, перевірки достовірності);
звіркові перевірки під час введення даних;
контроль обробки; та
заходи для запобігання навмисному або ненавмисному маніпулюванню програмним забезпеченням, даними або документами.
Користувач повинен розподіляти завдання в межах своєї організації на відповідні посади (контроль) і перевіряти, що завдання виконуються належним чином і повністю (нагляд). Результат цих перевірок має бути задокументований (документація), і якщо під час цих перевірок виявлено помилки, слід вжити відповідних заходів для виправлення ситуації (запобігання).
Безпека даних¶
Платник податків повинен захистити систему від будь-якої втрати даних через видалення, вилучення або крадіжку будь-яких даних. Якщо записи недостатньо захищені, бухгалтерський облік вважатиметься таким, що не відповідає рекомендаціям GoBD.
Після остаточного проведення записів їх більше неможливо змінити або видалити через програму.
Якщо Odoo використовується в хмарі, регулярні резервні копії є частиною сервісу Odoo Online. Крім того, регулярні резервні копії можна завантажити та зберегти на зовнішніх системах.
Якщо сервер працює локально, користувач несе відповідальність за створення необхідної інфраструктури резервного копіювання.
Важливо
У деяких випадках дані повинні зберігатися протягом десяти років або довше, тому завжди робіть резервні копії. Це ще важливіше, якщо ви вирішите змінити постачальника програмного забезпечення.
Відповідальність редактора програмного забезпечення¶
Враховуючи, що GoBD застосовується лише до платника податків, розробник програмного забезпечення жодним чином не може нести відповідальність за точну та сумісну документацію фінансових транзакційних даних своїх користувачів. Він може лише надати необхідні інструменти для дотримання користувачем рекомендацій щодо програмного забезпечення, описаних у GoBD.
Забезпечення відповідності через Odoo¶
Ключовими словами, коли йдеться про GoBD, є: відстежуваний, перевіряємий, правдивий, чіткий та безперервний. Коротше кажучи, вам потрібно мати архівування, стійке до аудиту, і Odoo надає вам засоби для досягнення всіх цих цілей:
- Простежуваність і можливість перевіркиКожен запис в Odoo позначається автором документа, датою створення, датою зміни та тим, хто його змінив. Крім того, відстежуються відповідні поля. Таким чином, можна побачити, яке значення було змінено ким у обговоренні відповідного об’єкта.
- ПовнотаУсі фінансові дані повинні бути записані в системі, і не може бути прогалин. Odoo гарантує відсутність прогалин у нумерації фінансових транзакцій. Користувач несе відповідальність за кодування всіх фінансових даних у системі. Оскільки більшість фінансових даних в Odoo генерується автоматично, користувач несе відповідальність за повне кодування всіх рахунків постачальників та різноманітних операцій.
- ТочністьOdoo гарантує, що при правильній конфігурації використовуються правильні рахунки. Крім того, механізми контролю між замовленнями на купівлю та замовленнями на продаж і відповідними рахунками-фактурами відображають реальність бізнесу. Користувач несе відповідальність за сканування та прикріплення паперового рахунку постачальника до відповідного запису в Odoo. Odoo Documents допомагає автоматизувати це завдання.
- Своєчасне бухгалтерське проведення та ведення облікуОскільки більшість фінансових даних в Odoo генерується транзакційними об’єктами (наприклад, рахунок проводиться при підтвердженні), Odoo забезпечує своєчасне ведення обліку «з коробки». За користувачем залишається відповідальність за своєчасне введення всіх вхідних рахунків постачальників, а також різних операцій.
- ПорядокФінансові дані, що зберігаються в Odoo, за визначенням упорядковані і можуть бути переупорядковані відповідно до більшості полів, присутніх у моделі. Конкретний порядок не вимагається GoBD, але система повинна забезпечити швидкий пошук певної фінансової операції стороннім експертом. Odoo забезпечує це з коробки.
- НезмінністьЗ німецькою локалізацією Odoo, Odoo в стандартній конфігурації налаштовано таким чином, що можна дотримуватися умови незмінності без будь-яких додаткових налаштувань.
Експорт GoBD¶
У випадку фіскальної перевірки, фіскальний орган може вимагати три рівні доступу до системи бухгалтерського обліку (Z1, Z2, Z3). Ці рівні варіюються від прямого доступу до інтерфейсу до передачі фінансових даних на носії інформації.
У випадку передачі фінансових даних на носій GoBD не вимагає конкретного формату. Це може бути, наприклад, XLS, CSV, XML, Lotus 123, SAP-формат, AS/400-формат або інший. Odoo підтримує експорт фінансових даних у форматах CSV і XLS з коробки. GoBD рекомендує експорт у спеціальному XML-форматі GoBD (див. «Ergänzende Informationen zur Datenträgerüberlassung» §3), але це не є обов’язковим.
Невідповідність вимогам¶
У разі порушення ви можете очікувати штрафу та судового наказу, який вимагає впровадження конкретних заходів.
Точка продажу¶
Технічна система безпеки¶
Kassensicherungsverordnung (Закон про захист від маніпулювання цифровими записами) вимагає, щоб електронні системи обліку, включаючи системи точок продажу, були обладнані технічною системою безпеки (також називається TSS або TSE).
Odoo пропонує сумісний сервіс за допомогою fiskaly, хмарного рішення.
Важливо
Оскільки це рішення є хмарним, потрібне робоче підключення до Інтернету.
Примітка
Дозволені лише ставки ПДВ, надані 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).
Порада
Якщо ці модулі не відображаються, оновіть список додатків.
Створення технічної системи безпеки та прив’язка її до точки продажу¶
Щоб використовувати точку продажу в Німеччині, спочатку створіть TSS, перейшовши до , вибравши Точку продажу для редагування, а потім встановивши прапорець Створити TSS у розділі Fiskaly API.
Після успішного створення TSS ви можете знайти:
TSS ID, який відноситься до ID вашої TSS на стороні fiskaly, та
Fiskaly Client ID, який відноситься до вашої точки продажу на стороні fiskaly.
Експорт DSFinV-K¶
Щоразу, коли ви закриваєте касу Точки продажу, деталі замовлень надсилаються до служби DSFinV-K fiskaly.
У разі аудиту ви можете експортувати дані, надіслані до DSFinV-K, перейшовши до .
Ці поля є обов’язковими:
Дата і час початку: експорт даних з датами, що дорівнюють або перевищують задану дату початку
Дата і час завершення: експорт даних з датами, що дорівнюють або менші за задану дату завершення
Залишіть поле Точка продажу порожнім, щоб експортувати дані всіх ваших точок продажу; вкажіть одну, якщо ви хочете експортувати дані лише для цієї конкретної точки продажу.
Коли експорт успішно запущено і обробляється, у полі Стан має бути вказано Очікування. Натисніть Оновити стан, щоб перевірити, чи він готовий.