Felaktiga datum
https://bricknode.atlassian.net/browse/TRAFM-162
Sold to ISK account (“Avyttrad till investeringssparkonto” (fält 573))
https://bricknode.atlassian.net/browse/TRAFM-164
When a sell has been made to an Investment savings account (ISK) it should be reported to SKV.
This is supported in the use of internal transfers in BFS and the tax Tax application fetches these technical sells and adds the Sold to ISK value to the reports KU32 and KU40, both in the Excel and the XML file.
First, you need to add To get this working in the Tax application, we have added the transaction type for the technical sell used in BFS, normally Default_Trade_Sell_Technical, to the Transaction type section of the export to Excel popup. This transaction type is called: “Default_Trade_Sell_Technical”.
...
Then you need to add We have also set up which ISK account types you have in your BFS instance. This is made in the Account “Account types for the ISK ISK” section of the export to Excel popup.
...
In When you export the Excel file, the value is populated in column F, called “ReportSoldToISK”“BfsSoldToISK”. TRUE is reported if this sell in question was made to an ISK account and FALSE if not.
...
In the XML file, the value is populated will end up in field number 573, called “Avyttrad till investeringssparkonto”“AvyttradTillISK”.
...
TIN number and country code TIN
https://bricknode.atlassian.net/browse/TRAFM-172
...
Since the release 2.38 you can enter TINs for end customers in BFS. To do this you go to the details Details page of a customer and edit the TIN section.
...
If there is a TIN value for the customer in BFS, the tax Tax application will fetch it and use it in the KU reports. These values (TIN number and country code TIN) are added to all KU reports, except the KU30 report.
In the excel Excel file, the values are populated in the two columns called “ReportTIN” and “ReportCountryCodeTIN”.
...
When you extract the XML file the values will end up in the fields with numbers 252 (TIN“TIN”) and 076 (LandskodTIN“LandskodTIN”).
...
https://bricknodewww.atlassian.net/browse/TRAFM-170oecd.org/tax/automatic-exchange/crs-implementation-and-assistance/tax-identification-numbers/#d.en.347759
Warning when standard income (Schablonintäkt) in KU30 is negative
If the standard income (Schablonintäkt“Schablonintäkt”) is negative when exporting the excel Excel file for the KU30, you will get a warning and information about which account it is. At this point, you can download the file and fix the issue in the excel Excel file before you upload it again to create the XML file, or you can cancel and go to BFS and correct the situation on the account and then after that export a new Excel again.
...
Rounding of Loss value in KU40 (profit/loss)
The rounding of profits and loss should be made in different ways so that it is benificial always the most beneficial for the end customer (not pay too much tax). Before the tax Tax application rounded profits and loss in the same way but this is now fixed changed according to SKV regulations (loss is rounded up and profits down).https://bricknode.atlassian.net/browse/TRAFM-163
ISIN
...
no longer a required field in KU31
Since the ISIN field is not required in the KU31 report according to SKV regulation, the tax Tax application now removes that field if there is no ISIN on the instrument in questionBFS.
Before the app required this and you had to make a lot of manual work to get it out in the excel Excel and then you had to remove it from XML . If an ISIN doesnt exist on the instrument anyway since SKV does not approve an empty ISIN value.
So if the instrument does not have an ISIN, there will be no ISIN filed filled in the xml XML file that is uploaded to SKV.https://bricknode.atlassian.net/browse/TRAFM-157
Field type for
...
“Schablonintäkt” of KU30 changed
The value of “schablonintäkt” “Schablonintäkt” has now the correct field type according to the schema for the tax reported to SKV regulations. Before it was incorrectly a 12 digit large field, this is now changed to a 10 digit field. https://bricknode.atlassian.net/browse/TRAFM-169
Timespan issue fixed
We have had an issue with the period of the Excel exports. If you had taxable events in BFS on the first of January or the last of December these would not be included in the reports if you selected these dates. This is now fixed and the Tax application includes the same period as you enter in the application.
New schema for 2021
The app now supports the XML schema for 2021 tax reporting.