[14.0][ADD] datev_export_dtvf

[hbrunn]

No description provided.

[marylla]

@hbrunn I tried testing this but I didn't get an export of the account move lines.

1. Why is it needed to create fiscal years in Odoo just for this export? Is this really necessary?

2. When creating an export I get 2 csv files: "EXTF_DebKred_Stamm.csv" and "EXTF_Kontenbeschriftungen.csv". What do I need to configure to get the usual accounting line export from my invoices?

3. Can you explain what I need to do with automatic accounts? I know there is a boolean in account settings to suppress the automatic calculation. For example, the income account 8400 (skr03) or 4400 (skr04) is an automatic account in Datev - what happens when I set the suppress-boolean to True and what happens when it is False? (I could have checked it during testing but I don't get the correct file as described in point 2, so maybe you can explain it with an example?!).

4. In order to merge this, it would be good to have "datev_export" as a dependency (which was merged recently) so that we don't have the company datev setting in all the different datev export modules.

[hbrunn]

thanks @marylla

1. the format itself wants the dates 'Start of business year' (field 13) and start/end of the reporting period (fields 15, 16), so I figured that's the most convenient way for users to fill in the dates/periods, assuming most will have account_fiscal_year installed anyways
2. did you select a period and does this period have accounting items?
3. here I'd like to call on @tv-openbig for the explanation - could you maybe provide a more elaborate help text?
4. completely agreed, was just waiting for the merge. done.

[tv-openbig]

@hbrunn Does it make sense to update the PR from here:
https://github.com/hbrunn/l10n-germany/tree/14.0-l10n_de_dtvf-init_hook

This would generate the right settings on "Suppress Automatic" already without demanding this to be configured by a user.

In general i also would propose to move the following to a level above in the module datev_export.
https://github.com/hbrunn/l10n-germany/blob/14.0-l10n_de_dtvf/datev_export_dtvf/models/account_account.py

The datev_export_xml module could use this setting too. It is not implemented yet, but it would make a lot of sense to integrate it in datev_export_xml as well, as we currently we export invoice lines with this accounts with a entry in "Bu-Schlüssel". This leads to warnings in DATEV (no errors), but we could easily prevent these warning if we would suppress the BU Schlüssel export for all invoice lines with these accounts.

I we would leave it as is, we only would have benefit from this boolean field in the module datev_export_dtvf.

What do you think @fkantelberg ? @hbrunn ?

[hbrunn]

sounds good to me

[fkantelberg]

Moving the flag to datev_export and using it in both follow up modules? Did I read it right? If yes I would agree.

[tv-openbig]

@fkantelberg @hbrunn Yes the flag will be usefull ("nachor") for the next dev iteration of datev_export_xml.
It should be easy to extend datev_export_xml for the target field "BU-Code" (export).

-> Write into BU-Code only if the accout of the line doesn't have activated "Suppress BU-Code"

[tv-openbig]

@hbrunn Do you have an idea why the runbot is pending ?

[hbrunn]

@tv-openbig no idea, reopening the PR helps sometimes

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[fkantelberg]

@hbrunn
We noticed some problem with the combination coupons where the numbers in the export doesn't fit the journal items. The following example is a coupon with 10% on the entire order->invoice. This also seems to happend if you have a credit note and some negative amounts (e.g. -5€ for a late retour).

I guess the problem is in the combination of the move lines in _get_data_transaction. I get the following output (below is the CSV) for the above invoice which doesn't add up.

>>> list(exp._get_data_transaction(inv))
[{'Umsatz (ohne Soll/Haben-Kz)': '4000,00',
  'Soll/Haben-Kennzeichen': 'S',
  'Konto': '8400',
  'Gegenkonto (ohne BU-Schlüssel)': '8400',
  'BU-Schlüssel': '',
  'Buchungstext': 'Discount: 10% Discount - On product with following taxes: ',
  'Belegdatum': '3008',
  'Belegfeld 1': 'INV/2024/08/0002',
  'Belegfeld 2': '[FURN_6741] Large Meeting Table\nConference room table',
  'KOST1 - Kostenstelle': False,
  'KOST-Datum': '30082024',
  'WKZ Umsatz': 'EUR',
  'Kurs': '1,000000',
  'Basis-Umsatz': '4000,00',
  'WKZ Basis-Umsatz': 'EUR'},
 {'Umsatz (ohne Soll/Haben-Kz)': '36000,00',
  'Soll/Haben-Kennzeichen': 'S',
  'Konto': '10001',
  'Gegenkonto (ohne BU-Schlüssel)': '8400',
  'BU-Schlüssel': '',
  'Buchungstext': 'INV/2024/08/0002',
  'Belegdatum': '3008',
  'Belegfeld 1': 'INV/2024/08/0002',
  'Belegfeld 2': '[FURN_6741] Large Meeting Table\nConference room table',
  'KOST1 - Kostenstelle': False,
  'KOST-Datum': '30082024',
  'WKZ Umsatz': 'EUR',
  'Kurs': '1,000000',
  'Basis-Umsatz': '36000,00',
  'WKZ Basis-Umsatz': 'EUR'}]

EXTF_Buchungsstapel_20240101.csv

Also does the Belegdatum need to be just day + month or would it be feasable to add the year too?

[tv-openbig]

@hbrunn @fkantelberg Belegdatum should not be changed. It is compatible date for DATEV as DATEV reads the year from first line in the csv.
@fkantelberg Please read the modules description, to my opinion you have not configured it properly. For the account 8400 i would expect a setting which would lead to the "BU-Schlüssel" = "40". If that will be in your export file the result in the DATEV .csv is correct. Please take into account the described limitations of that module (No monthly VAT reporting). Most important is the proper setting of the "Suppress DATEV Automatic" in the accounts.

[fkantelberg]

Yes ok he BU-Schlüssel isn't set up in my instance but the numbers are still weird and it looks like the discount is subtracted twice. The credit in the first journal item is 40k but in the export it's 36k. A customer isn't able to comprehend what it what because the Buchungstext and Belegfeld 2 are confusing if you if you combine multiple lines. Additional the Gegenkonto isn't visible in Odoo.

This is a really easy examples. I got some with still multiple lines were it gets harder and harder to determine which is calculated against which other line.

[tv-openbig]

@fkantelberg The numbers are not weird. Overall the account receivable amount is 36.000 € (40.000 - 4.000). The income is grouped (subtracted) also 36.000 €. There was obviously no tax in the invoice lines, so everything is fine as only the line 2 is relevant. Line 1 is account against itself so "0,00 €" and the line 2 is totally OK.

[fkantelberg]

@tv-openbig
The numbers are kinda weird or atleast not fully comprehendable. As far as I can see the income isn't grouped. There are always 2 account.move.line set together (1st is Buchungstext and 2nd is Belegfeld 2). If the booking happens on the same accounts the lines are combined. I can see that the numbers are correct but it's hard to grasp and explain to a customer what is happening if the customer wants to audit the export. Here is an example with 1 line more than above. (I have to explain invoices with even more lines than those simple examples)

1. Line 1 is 750 credit to 8400 which corresponds to the FURN_0096
2. Line 2 is 3325 debit to 8400 which corresponds to discount - FURN_0096
3. Line 3 is 36675 credit to 10001 which corresponds to the last line in the screenshot. But what is the Belegfeld 2 doing there? (why only FURN_6741?)

I hope this helps otherwise we can switch to a meeting or somehing else.

[{'Umsatz (ohne Soll/Haben-Kz)': '750,00',
  'Soll/Haben-Kennzeichen': 'S',
  'Konto': '8400',
  'Gegenkonto (ohne BU-Schlüssel)': '8400',
  'BU-Schlüssel': '40',
  'Buchungstext': 'Discount: 10% Discount - On product with following taxes: ',
  'Belegdatum': '3008',
  'Belegfeld 1': 'INV/2024/08/0003',
  'Belegfeld 2': '[FURN_0096] Customizable Desk (CONFIG) (Steel, White)\n160x80cm, with large legs.',
  'KOST1 - Kostenstelle': False,
  'KOST-Datum': '30082024',
  'WKZ Umsatz': 'EUR',
  'Kurs': '1,000000',
  'Basis-Umsatz': '750,00',
  'WKZ Basis-Umsatz': 'EUR'},
 {'Umsatz (ohne Soll/Haben-Kz)': '3325,00',
  'Soll/Haben-Kennzeichen': 'H',
  'Konto': '8400',
  'Gegenkonto (ohne BU-Schlüssel)': '8400',
  'BU-Schlüssel': '40',
  'Buchungstext': '[FURN_6741] Large Meeting Table\nConference room table',
  'Belegdatum': '3008',
  'Belegfeld 1': 'INV/2024/08/0003',
  'Belegfeld 2': 'Discount: 10% Discount - On product with following taxes: ',
  'KOST1 - Kostenstelle': False,
  'KOST-Datum': '30082024',
  'WKZ Umsatz': 'EUR',
  'Kurs': '1,000000',
  'Basis-Umsatz': '3325,00',
  'WKZ Basis-Umsatz': 'EUR'},
 {'Umsatz (ohne Soll/Haben-Kz)': '36675,00',
  'Soll/Haben-Kennzeichen': 'S',
  'Konto': '10001',
  'Gegenkonto (ohne BU-Schlüssel)': '8400',
  'BU-Schlüssel': '40',
  'Buchungstext': 'INV/2024/08/0003',
  'Belegdatum': '3008',
  'Belegfeld 1': 'INV/2024/08/0003',
  'Belegfeld 2': '[FURN_6741] Large Meeting Table\nConference room table',
  'KOST1 - Kostenstelle': False,
  'KOST-Datum': '30082024',
  'WKZ Umsatz': 'EUR',
  'Kurs': '1,000000',
  'Basis-Umsatz': '36675,00',
  'WKZ Basis-Umsatz': 'EUR'}]

[fkantelberg]

if account_number == offset_account_number:
    continue

We checked the data again and the lines we could not validate where bookings between the same accounts. Because nothing changes with these we don't need these lines in the CSV.