The transaction drop has a date method which returns the booking date of the transaction. Is there however a way to access the date of when the transaction actually happened? If not, is it possible to add this? I assume it must be available in the back end since it must be used to assign a transaction to the right period.
Use case: calculation of supplier and customer credit
Kind regards
Sam
Fintrax
Hello @Fintrax ,
this is currently not yet available. Can I ask for your specific usecase where you would want to use this date?
Thank you,
Michiel
Hi Michiel
As mentioned in the previous post: the calculation of supplier and customer credit.
Kind regards
Hi @Fintrax ,
We will assess this internally, will check if the date is available and keep you posted of the outcome.
Best regards and enjoy the year end holidays.
Michiel
Hi
Is there any update on this?
Thanks!
Kind regards
Sam
Hi @Fintrax
We have submitted your use case to our product team and it has been added as a feature request.
However, this is data that we do not currently have and will require an upgrade to all of our syncs. Right now we do not have a set date for when this will happen so it is difficult to give you a timeframe other than it won’t be in the immediate future.
That being said, as soon as the upgrades have been completed and we have implemented the feature request you will be the first to know.
Feel free to check back again for an update further down the line and be sure to let us know if there is anything else we can help with.
All the best
Tom
Hi Tom
Thanks for the information. A follow up question though. If that information is not available, then how do you convert yearly files to quarterly or monthly files?
Kind regards
Sam
Hi Sam,
The booking date is the date the transaction occurred according to accounting principles. This will normally be the date that the transaction occurred but may be different if accounting principles require it to be e.g. in the case of services provided over a long period of time. This may differ from the date the accountant entered the date into the bookkeeping system lets call this the entry date which we don’t bring in from the bookkeeping systems.
We use the bookkeeping date to split the periods as its the relevant date for accountants.
To calculate customer credit you would normally need the invoice dates (date the invoice was sent to the customer) which will be different again from the booking date, date of transaction and entry date. We don’t keep invoice details in the database so this data is also not available automatically.
Hope that helps clarify.
Kind regards
Tom W
Thanks for that clear explanation Tom!
Kind regards
Sam
Hi Tom
Sorry to bother you again but I really want to understand this clearly.
What date exactly is saved from the bookkeeping system in the transaction.date drop?
Is is right that this is NOT the same date that is used to assign the transaction to the right period? If not, are you sure this value is not saved in Silverfin somewhere?
Sorry to bother again but it’s quite important to us.
Kind regards
Sam
Hi Sam,
No worries. The date stored in the transactions.date is the accounting date/booking date. This is the date when the entry occurred according to accounting principles followed by the company (cash accounting or accrual accounting).
This (transactions.date) is also the date that is used to assign transactions to periods as it’s the correct date for this purpose.
Hope this helps,
Kind regards
Tom W
Hi Tom
That’s strange though because I made 2 separate files that use the same EOL sync. One is a yearly file and the other one is a monthly file.
If I go to 06/2020 in the monthly file and I have a look at the total of all 6 accounts I get a value of 2355726.45 => See Silverfin
If I go to the yearly file and take the sum of all transactions with a date that is equal or lower than 30/06/2020, I get a total value of 2447181.59 => See Silverfin
I don’t understand how these values can be different 
Do you have an idea?
Thanks a lot!
Kind regards
Sam
I added another document where I also take the start date of the year into account and I even get another result…
https://live.getsilverfin.com/f/14120/1262757/permanent_texts/59919545?current_ledger_id=26419391
I’m really confused now 
Thanks in advance
Sam
Any update on this by any chance? Thanks! 
Kind regards
Sam
Hi Sam,
It seems that some of the transactions have dates before the start of the period. I’m not sure how this can have happened. I will pass this over to the engineers to investigate further.
Kind regards
Tom W
Hi Sam,
Our engineers have investigated this and the logic for assigning transactions to periods is a little bit more complicated when a sync is used. In the bookkeeping system, each transaction has a ‘financial_year’
and a ‘financial_period’ which define which period the transaction is assigned to. This is in addition to the booking date.
As an example from your file, for the line from that account entry with document number “22600065”:
This shows that although the booking date is in the period 2021 the ‘financial_year’ is 2022 so the transaction is included in 2022 period 1, not 2021.
unfortunately, the ‘financial_year’ and ‘financial_period’ data are not kept once the sync has finished assigning transactions to periods so they are not accessible in liquid.
If the transactions are in the wrong period the users would need to go to the bookkeeping system and adjust the ‘financial_year’ and ‘financial_period’ to move them to the correct period.
Kind regards
Tom W
Hey Tom
Thanks a lot for investigate this for us. Would I be possible to saved and add the financial_year and financial_period? I guess Silverfin itself would also benefit from it. This way you don’t have to resync everything when a customer switches to another type of file?
Kind regards
Sam
Hi Sam
I have added this as a feature request. However, this is data that we do not currently have and will require an upgrade to all of our syncs. Due to the limited capacity in our syncs team, we don’t have a set date for when this will happen so it is difficult to give you a timeframe other than it won’t be in the immediate future.
That being said, as soon as the upgrades have been completed and we have implemented the feature request you will be the first to know.
Feel free to check back again for an update further down the line and be sure to let us know if there is anything else we can help with.
All the best
Tom