Page 1 of 1

transaction history reports

Posted: Tue Sep 25, 2012 9:39 pm
by juanaguas
Is there any way to extract transaction history reports for the entire system? I.e. a log comprising (per line) at least::
- date : payer : payee : currency (account) : amount

I had imagined that such information would be easily extractable via the REST, but I can't find anything in the documentation. Indeed, as far as I can see, both the SOAP and REST interfaces are orientated entirely towards action on individual accounts. Am I missing something obvious?

At this point the only way I can see to map transaction paths, emerging member connectivity, transaction clustering, currency circulation rate, etc., relies upon trapping email alerts. Surely there must be a cleaner and more efficient way of collecting such information. Any help would be greatly appreciated,

(NB I have no access either to the DBMS or to SQL dumps from the server, so that rather obvious solution has to be ruled out.)

Re: transaction history reports

Posted: Thu Sep 27, 2012 7:32 am
by simonjwoolf
If you go to reports > member reports, you can generate a report like this, and download it as a CSV file

Re: transaction history reports

Posted: Thu Sep 27, 2012 9:14 am
by juanaguas
Thanks Simon, but that requires human intervention which is what I'm trying to minimize. Upon re-reading my post, I realize that I didn't make that very obvious.

What I'm looking for is a simple way for software hosted externally to extract transaction histories (across all accounts). I have several requirements for such information including (but certainly not limited to) the tracking of payment flows, the mapping of emergent connectivity and analysis of account behaviour - and this needs to be done regularly, consistently and quickly. This is not something for which a machine is ideally suited and for which humans are not.

I've found a few messy ways around this (constructing the history incrementally from queries applied by a privileged user to individual accounts) but I would prefer a relatively clean solution that can be implemented entirely via REST or SOAP without hammering the Cyclos host with a large number of individual queries (which I do not imagine would be welcomed at all).

At this point the cleanest solution appears to be (following the suggestion in the Cyclos help system) to develop a simple custom Java class to be triggered by payment actions, alerting the "tracking server" to these events and feeding a minimal record to update its history, but I can't take it for granted that our Cyclos host would agree to install anything not included in a standard Cyclos installation. Therefore I would prefer to make use of an existing built-in solution. I haven't managed to find anything in the documentation, but I was hoping that someone might be able to point out something I've missed.

John (:

Re: transaction history reports

Posted: Thu Sep 27, 2012 9:58 am
by simonjwoolf
OK, I see your problem.

It's hard to see a solution, unless Stro develop an additional webservice that allows a group, rather than just an individual member, to be queried.

One thought I had was whether you can get anything useful from querying a system account. This largely depends on how many of your transactions hit a system account (for example, if you have some kind of transaction or processing fee, then typically this hits a system account, so you could derive the parent transactions from that)

S.

Re: transaction history reports

Posted: Thu Sep 27, 2012 10:33 am
by juanaguas
Thanks Simon, your second suggestion may well take me closer to what I need, i.e.

> One thought I had was whether you can get anything useful from
> querying a system account. This largely depends on how many of
> your transactions hit a system account (for example, if you have
> some kind of transaction or processing fee, then typically this hits
> a system account, so you could derive the parent transactions
> from that)

That might simplify matters if
(a) such an event can be triggered by a zero transaction charge (and this sounds plausible since I know from an earlier posting, on a very different topic, that a 100% charge can be applied); and if
(b) the record associated with that fee includes the value of the transaction on which it is applied; and if
(c) that record also identifies currency, payer, payee and date/time (which I imagine would be the case).
I'd better stick my head back in the documentation.

You also wrote:
> It's hard to see a solution, unless Stro develop an additional
> webservice that allows a group, rather than just an individual
> member, to be queried.

That's an interesting alternative approach and might reduce bandwidth requirements. However, the custom class I had in mind would push data to the tracking server rather than simply allowing the latter to query Cyclos. Either way, there is a requirement to alert the tracking server to an event so pushing data at the same time seems like a natural step to take.

Anyway, I need to go back and read some more. Thanks again.

John (: