View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009361 | Taler | mechant backend | public | 2024-11-27 16:33 | 2024-12-07 23:14 |
| Reporter | Damian Pilka | Assigned To | Damian Pilka | ||
| Priority | high | Severity | feature | Reproducibility | have not tried |
| Status | feedback | Resolution | open | ||
| Target Version | 1.1 | ||||
| Summary | 0009361: transaction overviews for the merchants / Abrechnung für die Händler*innen | ||||
| Description | Hello 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 | ||||
| Tags | No tags attached. | ||||
|
|
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). |
|
|
Damian: please confirm my analysis, then we should assign to sebastian. |
|
|
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 |
|
|
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. |
|
|
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. |
| 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 | |
| 2024-12-07 23:14 | Christian Grothoff | Target Version | => 1.1 |
