View Issue Details

IDProjectCategoryView StatusLast Update
0009361Talermechant backendpublic2024-12-03 10:00
ReporterDamian Pilka Assigned ToDamian Pilka  
PriorityhighSeverityfeatureReproducibilityhave not tried
Status feedbackResolutionopen 
Summary0009361: transaction overviews for the merchants / Abrechnung für die Händler*innen
DescriptionHello everyone,

We finally got a feedback from the lawyers regarding the Transaction overviews for the merchants. They advise against aggregated billing. The supply of a transaction overview (in an unchangeable form) in the merchant backend is the preferred solution. The report/overview must include all individual transactions paid out to the merchant on its reference account, including returns and refunds, as well as all fees owed by the merchant to GLS for the use of Taler and which GLS has offset against the paid out amount. The merchant must be informed promptly when the (quarterly) report is made available on the Taler backend. The following information must be provided: “This statement of account shall be deemed approved unless you object in writing within four weeks of receipt of this statement of account. Sending the objection is sufficient to meet the deadline”.

This means that the customer must be regularly informed in the merchant backend (or in another verifiable way) that an overview of the billing statement exists.

best regards

Damian

Hallo Zusammen,

wir haben nun eine Rückmeldung von den Rechtsanwälten für die Abrechnung erhalten. Es wird von einer aggregierten Abrechnung abgeraten. Die Bereitstellung einer Transaktionsübersicht (in einer unveränderbaren Form) im Merchant Backend ist die präferierte Lösung. Der Bericht/die Übersicht soll alle einzelnen, an den Händler auf sein Referenzkonto ausgezahlten Transaktionen einschließlich Retouren und Rückerstattungen sowie sämtliche Gebühren, die der Händler GLS für die Nutzung von Taler schuldete und die GLS mit Guthaben verrechnet hat. Der Händler wird zeitnah auf die Bereitstellung des Quartalsberichts im Händler-Portal von Taler hingewiesen. Zudem wird der Hinweis gegeben: "Der vorliegende Rechnungsabschluss gilt als genehmigt, sofern Sie nicht innerhalb von vier Wochen nach Zugang dieses Rechnungsabschlusses schriftlich Widerspruch erheben. Für die Fristeinhaltung genügt die Absendung des Widerspruches".

D.h. konkret der Kunde muss im Händler Backend (oder andersweitig, nachweissbar) regelmäßig darauf hingewiesen werden, dass eine Übersicht der Abrechnung existiert
TagsNo tags attached.

Activities

Christian Grothoff

2024-11-28 20:02

manager   ~0023771

Ok, so what I read from this is:

1) no summary export and submission separately via random channel to the merchant
2) expand the functionality of the merchant backend, for example it currently doesn't show the GLS fees (it just *checks* them, but does not *render* them);
3) ensure the screen is super-visible. I propose that once it is improved we can simply make this the *default* screen the merchant always sees after logging in. That way, we can avoid showing a hint that the screen exists, as you cannot exactly say you never saw the primary page after logging in.

Note that the report would primarily be in real-time, but we can of course make a screen that renders the historic data quarterly/monthly.

I propose we do the usual thing:

0) DESIGN: I think the above is already a pretty good spec on what data to show. I propose we do something where the user can set the timeframe (daily, weekly, monthly, quarterly, yearly) and we then render all information for that period *or* the current period ("live").

1) The information we render is on top totals: total amount sold, total refunded, total fees paid, total income received, total taxes owed to the government by tax category (Q: how to deal with refunds here?); below we have a 2-tiered table, 1st tier has the incoming wire transfers from the exchange (or "pending wire transfer" for all unsettled orders), 2nd tier then has the list of all transactions settled by the respective wire transfer with the total amount of the transaction, applicable fees and effective contribution to the wire transfer). The 2-tired table is paginated and users can "drill down" into the data which is loaded only on-demand.

1) SPECIFICATION: We now write a REST API spec that would allow the SPA to easily render this data.

2) IMPLEMENTATION: Implement new endpoints, possibly update/improve DB schema with aggregate data to be able to return certain bits quickly without full table scans.

3) SPA: Add new page(s) to the SPA, test, UI-review, deploy.

Sebastian: can you do (1) and (3)? I'll review (1) when I do (2). I'd like to see this as a high-priority item *after* the work for the Swiss launch, so 1.1 (backend) and 1.2 (SPA).

Christian Grothoff

2024-11-28 20:03

manager   ~0023772

Damian: please confirm my analysis, then we should assign to sebastian.

Damian Pilka

2024-12-02 17:38

developer   ~0023778

Dear Christian,

my comments/suggestions to the steps 0-3:

0: From GLS perspective, it is an add on that the costumer can set the time frame. If this option would create a lot of work on your side, we can set a time frame (at least with the MVP).

1. From GLS SIde the tax information is not needed for the purpose of the report.

We need to inform the merchant about new reports. If the set the time frame, we can automatically send an e-mail into his “VR -NET KEY” account. This would do from a legal side. Alternatively, we can also send this information within the longest period the costumer can chose. This would be an easy to implement process from GLS side.

By the way, how long is the data available?


Best regards

Damian

Christian Grothoff

2024-12-03 09:57

manager   ~0023779

Well, I guess the easiest and pretty sane option is to do the page only on a monthly basis, then you can put a monthly message into VR-NET-KEY for the merchant to check. We can *later* make additional pages with quarterly or yearly statements, and I doubt more is strictly required anyway.

As for how long the data is available: (1) the merchant has to run a command with an option we didn't even yet implement to delete: "taler-merchant-dbinit -g" to delete "old" data; (2) that future command is expected to delete data that is older than 10 years (tax record period). However, the 10 years would be configurable (10 years is just the default), so in theory the merchant could set it longer or shorter, the idea being to adjust for domestic laws.

But most importantly, they might not necessarily run it at all, as they may care about keeping the data and they control it.

Christian Grothoff

2024-12-03 10:00

manager   ~0023780

So we change:

0) DESIGN: I think the above is already a pretty good spec on what data to show. I propose we do something where the user can set the time period (selecting a month, quarter, or year) and we then render all information for that period *or* the current period ("live"). The database only keeps *monthly* aggregate data, as we can afford to select() over 3-12 months for the quarterly or yearly statements.

As for taxes, I know they are desired by merchants, so I think it'd be good if we did them at this time as well.

Issue History

Date Modified Username Field Change
2024-11-27 16:33 Damian Pilka New Issue
2024-11-27 16:33 Damian Pilka Status new => assigned
2024-11-27 16:33 Damian Pilka Assigned To => Christian Grothoff
2024-11-28 20:02 Christian Grothoff Note Added: 0023771
2024-11-28 20:03 Christian Grothoff Note Added: 0023772
2024-11-28 20:03 Christian Grothoff Assigned To Christian Grothoff => Damian Pilka
2024-11-28 20:03 Christian Grothoff Status assigned => feedback
2024-12-02 17:38 Damian Pilka Note Added: 0023778
2024-12-03 09:57 Christian Grothoff Note Added: 0023779
2024-12-03 10:00 Christian Grothoff Note Added: 0023780