[ADD] l10n_de_datev #105
[ADD] l10n_de_datev #105
Conversation
|
@hbrunn Hi Holger, During handling of the above exception, another exception occurred: Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): |
|
thanks for the interest, but please wait until this isn't a draft |
Hi, There is furthermore a upstream of a datev_base module provided by I can say that i am very interested to provide it under OCA umbrella (at least datev_export). Today i have also a discussion with elego, maybe they will also decide to collaborate with If you are interested to access the repository i mentioned please drop a mail here: |
|
Great there's so much interest with this module. But why would you invite going somewhere else while we can just collaborate here? |
|
@hbrunn DATEV provides so many format options to import accounting data. You also can see that there is a ASCII import one menu entry above "Stapelverarbeitung" (which allows upload of DATEV Format). This format seems to be more flexible and probably easier to develop as the tax advisors may do some mapping in advance and obviously it is out of the stratosphere of the interface to be sure that both sides have the same accounts. So basically the datev_base module as well as our datev_export modules doesn't support exchange of master data, as it is to my opinion not a mandatory requirement. Why ? In Odoo we do not need a single account per single customer / supplier. It is easy to have the same debitor and creditor accounts on both sides. Also it is required to exchange the income / expense accounts and accounts for the balance sheet touched in odoo. I assume this "design" solution might reduce complexity a lot. Finally it is also a business decision that Odoo will be the leading system, DATEV is "just" required to do the year end closing, electronical balance sheet and income statement and things like that from DATEV Kanzlei Rechnungswesen as tax advisors wants to use their own "Datev tool" for that purpose. If i am correct also Odoo EE decided to just create a ASCII file with account move lines. |
what is documented in https://developer.datev.de/portal/en/dtvf/formate
what I have now nearly works for my customer, so I don't plan any big changes here. In the end, everyone can decide themselves if they want to import only transactions or any of the other files the code currently generates and puts into the zip file - my customer uses a bunch of custom accounts, those you don't want to create manually in DATEV. As you describe, DATEV is here only used for the accountant's year closing, all actual accounting happens in Odoo |
It seems we might support several formats in the future. You are working on DATEV Format, we are working on publishing the DATEV formats ASCII and xml (DATEV Unternehmen Online). Our target is OCA 14.0. Last week we have exchanged the current status. We have discussed also naming of the modules. We are thinking about datev_export_ascii and datev_export_xml. Would it make sense to adopt your modules name to datev_export_dtvf in order to avoid naming confusion (at least since 14.0) ? If you are interested you might request access to our meeting protocol: https://docs.google.com/document/d/1qO8j5RPKhybzM7YPbY8ZDucZtIp56ctX5dYCwOuOrGE/edit |
|
I'll be happy to rename this to For the private code and discussions, I'd rather abstain, thanks for the invitation though. This is now very close to being ready for review, I just need to get around to write proper tests and fix some details, but if you want to test, go ahead please. And nitpick: It's very probable what your |
|
Hello Markus, is it ok for you, if we don't insist on the l10n_de_ prefix for the DATEV modules under l10n-germany repo ?
@marylla Do you understand this advise about the naming of the modules ? |
|
If I may explain myself about the ascii thing: This is the name of a specific text encoding that can only represent a very small range of characters, but for historic reasons some people tend to call anything plain text like 'ascii', but technically that's usually not correct because most modern systems don't use the historical ascii for their text encoding |
|
|
@hbrunn I have just installed your latest revision on my database and i get this odoo server error: |
|
do you have account_fiscal_year installed and does the date range type this module adds exist? you might have to update this module if it's already installed |
hbrunn
force-pushed
the
12.0-l10n_de_datev
branch
2 times, most recently
from
4252f9a
to
20a22b9
Compare
hbrunn
force-pushed
the
12.0-l10n_de_datev
branch
from
20a22b9
to
47b27f3
Compare
|
@hbrunn Sorry for my late review. Reason was that i couldn't fix the issue on my existing database. However on a clean database i could create datev export for my example period:
Do you have in the meantime a feedback from your customers tax advisor if (real) import in DATEV was successfull. Yesterday we have discussed if we should cooperate with a tax advisor to be able to issue end-to-end testing. |
|
yes, testing this with real datev is a problem, and I didn't yet hear back from my customer's accountant, so no external verification yet. Cooperation with a tax advisor surely is desirable, but I wouldn't know how to fund it |
We have discussed that yesterday in our meeting about further ongoing with the modules "datev_export" (.xml) and datev_base (ascii) targeted to integrate it for 14.0 in l10n-germany. Eventually we may test that together with the tax advisor of one of our german companies or customers. I cannot promise that, but it may happen (@OSevangelist). Here is something i have found: |
I did some testing with the tool with the data from my test database (with l10n_de_skr03).
Finally the remark in this protocol still might lead to issues, as it indeed points to the fact that it could check just the format nothing more (right accounts, taxes and so on). Nevertheless i think it is enough to merge this pull request. What do you think @hbrunn from your experience ? |
|
during development, this tool happily passed files that failed when importing this into MonKey office which the intermediary I work with uses. So I don't really trust it |
Do i understand correct, that the tax advisor uses Monkey Office in order to import from Odoo -> Monkey Office account moves in datev format (as a import source inside of monkey office) ? |
|
no, that was just the only software available at the moment to test something at all at the intermediary, the actual tax advisor uses the datev software, but hasn't yet verified it works for them |
|
@hbrunn In fact i should add that there was one issue in my first (uncorrected) export example. wrong export file (line 7): corrected file (line 7 removed by tax removal of 0,02 € payment difference): I assume those 0,00 € line cases could lead in general to errors. |
|
@hbrunn This is probably interesting for you: odoo/odoo#99426 |
|
thank you @tv-openbig it seems a struggle. I'm here patiently waiting for my customer's accountant to give notice when they have delivered the files generated with this code. Seems to take time. |
|
@hbrunn I am definitely also interested in this feedback. Actually in our module "datev_export_ascii" we follow the approach to put everything into one move line (the tax line would be calculated in DATEV itself either by a automatic account, f.e. income account 8400 exported with 119 € in DATEV automatic splitted into 2 lines income account 8400 100 € and 1776 tax account 19 € or by non-automatic account 8410 119€ with an entry "81" in "Buchungsschlüssel" leading also to 8410 100 € and 1776 19 €. Finally DATEV also takes the information from the exported line out of the field "counterpart account" in order to autoamtically create the 3rd move line regarded from Odoo logic directly in DATEV). This one line approach might be error prone, especially if we configure the taxes in Odoo (accidently) with a different account as DATEV automatic logic or "Buchungsschlüssel" logic would calculate inside DATEV. Another potential error might be the possibility to edit the taxes in Odoo in case of cent-differences (Odoo sum-up of invoice lines to TOTAL differs to the TOTAL calculation of your supplier which requires to edit the tax in order to pay exactly the TOTAL of the suppliers invoice). Therefore i would be really glad to get a feedback from your customer, as this appoach to send all move lines exactly as it is in Odoo to DATEV definetly wouldn't be so error prone as in our approach. If i can help with that don't hesitate to ask me. |
|
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. |
github-actions
bot
added
the
stale
|
@hbrunn This export could be interesting if all lines would have BU-Schlüssel 40. Therefore this module could help if is would be used just once a year in order to push 1:1 all account moves out of Odoo to DATEV. This makes sense if the tax advisor provides just end-of-year accounting in order to prepare the balance sheet and the P&L. The monthly vat declarations would come out of odoo for example with the module l10n_de_tax_statement. I assume we have this case very often. i still see sense in your module, especially if there would be the option to use this "40" instead the values out of the field l10n_de_datev_code (account.tax). |
tv-openbig
removed
the
stale
I'll be happy to implement this, would that be an option on the export wizard? This btw is exactly the workflow my customer uses, and they imported the file to https://www.monkey-office.de - so the original datev applications might indeed need this code. |
|
@hbrunn @Cedric-Pigeon We have exactly that demand now for a ACSone customer, where we would be able to test that together with the tax advisor. Unfortunately they have v14. However it would be for sure a good chance for a real end-to-end test (Odoo -> Tax Advisor). Furthermore i would be able to document this use case in the readme folder, if you want. |
|
sounds good! |
|
still i am checking if entry "40" in the field "Bu-Schlüssel" would help to import many lines into DATEV. As i don't have DATEV by myself to do end-to-end test i have created an export now in order to let it check by someone with a DATEV software installed. I am expecting very soon a feedback. In the meantime i have checked a complex account move with many account move accounts and many account move counterpart accounts lines. The results should be the same in DATEV as in Odoo. I have checked that in a excel sheet and the values are the same. So this complex account move also fits. Therefore it seems your account / counterpart account logic seems to be ok for the use case to do a bulk export of everything from a fiscal year. Still i think there are some rough edges especially as it is not possible to select an existing fiscal year. The selection field is empty even if you have already fiscal years. I could fix that by deleting at first all fiscal years, then i used your module to re-create the fiscal years again. Furthermore there is no way to set a exported year back to draft in order to re-create a export or to select a different choice of fiscal periods on the lines (for example in order to export just a month from one fiscal year). If i delete a fiscal year there is no way to create it again for the same fiscal year.
This problem is tied to my opinion to the empty selection field i mentioned already. If i would then try to create the year form by "create and edit" in the field "fiscalyear_id" then i get the message "Fiscal year already exists ...". Finally i have to delete the fiscal year before i can re-create it again in your field "fiscalyear_id" by entering for example "2021" and then clicking on "create and edit". It seems there are no negative side effects to delete a fiscal year from the past in order to re-create it again, but at least it is very confusing. I am afraid normal users will be lost especially if they have already existing fiscal years. Finally i would like to ask you if you would be open-minded to re-name the module to "datev_export_dtvf" for a PR towards 14.0 branch. I promise to do further testing based on v14 and documentation, which explains what to do in Odoo, what to do in DATEV and explaining the use case for this module in comparison to the modules datev_export_xml and datev_export_ascii. |
sure, agreed with the rename. I think you can just take this for the v14 version and then I'll close this PR, as I won't be developing this further in v12. I'll keep the PR open until the v14 one arrives |
|
superseded by #118 |
To configure this module, you need to:
DATEVtabUsage
To use this module, you need to:
Invoicing/Reporting/DATEV exportGenerate