|
|
|
[
Permlink
| « Hide
]
Lex Neva added a comment - 14/Dec/07 09:54 AM
Might also be neat if the object's position and region were reported for llGiveMoney() transactions, which would help in tracking down rogue objects that have been granted money permission.
It would also be nice if it displayed the object's owner either as a name or UUID if the owner and the payee or payer, depending on whether transaction is incoming or outgoing from you, if different than the owner though that may be technically unfeasible.
—
Change to somthing like: Date: 2007-12-28 04:03:48 This would be hughe imporvement not only in keeping track of your business, but although in security ! thanks ! I made the description more focused on the situation I am trying to address.
Lex: fine idea - I think there is another issue open for it, though. Gordon: I believe the resident field (in the XML, for instance) already provides that information - indeed, that is really the problem I'm trying to address here - that only the account information is provided, not the object's information. The most useful bit of information here would be to fill out the description field with the object name. I'm looking at my logs and I can not make heads or tails out of what object paid whom and why.
Any transaction where an object pays an avatar is blank. This is painful, because I can't build a query that can identify if I am being debited for money tree payments, picks, billboards, stats collections, commission payments, returned sales, high score rewards, or ... anything! The key of the paying or payed object would be most useful for our system.
We have several dedicated servers who's only purpose in life is to run a complex search and matching algorithm that attempts to match up thousands of in-world transactions with corresponding payment reports from the object scripts themselves. The code involved has also taken many many person-hours in development time. With all that, it is still not possible to reliably match in-world transactions with the event reports from object scripts with 100% accuracy. LL adding the object key - a seemingly simple feature - would save us thousands of US$/year and would have saved us much more if it had been present already. Of equal value would be if llGiveMoney() returned a unique transaction key which was then present in the logs if the payment actually succeeded (or posted to the object as a 'transaction success' dataserver event). That is the topic of a different feature request - SVC-177 It sounds like a good idea. But you know it is going to break all the existing code out there that is currently reading the transaction history pages. Reading html pages to get usefull data is very tricky and breaks too easily!
I honestly think it would be better if there was a dedicated TEXT interface with comprehensive transaction details that can be read from llHTTPRequest within SL. Access from outside LL can be blocked, and the username/password can be passed in the URL itself. As the information never leaves the LL server network it should be secure enough. A dataserver event that returns all these details after a llGiveMoney event is triggered would be helpfull. ...or better still, object to object payments! If the vending machine could rename itself to the customers UUID and directly pay the delivery server the money event in the delivery server will contain the payment amount and the person to deliver to =) Darling Brody Comments above duplicate some of the feature requests in SVC-177
@darling This jira entry is very specifically intended to apply to xml and xls formats, not html, and are intended to address the needs of external tools. Halfway decent XML parsers certainly shouldn't break with the addition of new elements. I would presume that most XLS users would be similarly uneffected. However, see WEB-449 for a suggestion that XML formats should validate against published XML Schemas.
as it is now, i am violating several EU regulations, not to mention tax regulations here in my own country, because i need to verify what the money i am declaring comes from, wich cant be done because there is no easy way of telling what payout was done by which object. the problem in detail is that i need to declare different financial statements, one for each category.. money donated to me, shall not be taxed. money from sales, must be, as an example.
The workaround is that i declare all to be sales, wich means i have to pay taxes even on those transactions that i shouldnt be liable for. And i do that by declaring the sale of L$ as the main merchandise. Though if i was able to tell what objects that paid out, i could have the backing on where the money comes from, and hence lower my taxation. The sale of L$ would then be a mere currency exchange. another problem is to not be able to easily find out the payout rates of every object in an easy way, wich means that every object doing credits/debets have to do that part through scripting, wich do add to lag.. easy explained, with topping the limits on the number of transactions in a sim at the same time, with several tens of thousands of transactions daily, i would preffer to us ethe transaction history directly to check upon my money objects. o, and just for the fun of it, we were able to sniff out the transaction history with the old setup, now with the new transaction history thats not possible anymore.. irritating.. though i do like the look of the new one compared to the old one, its getting better, just not perfect |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Transaction History : Account Transactions should include more details for "object pays" transactions
