Jump to content

Undelivered- was delivered- customer got it and I have no pay


Dhyana Writer
 Share

You are about to reply to a thread that has been inactive for 4429 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts


Arwen Serpente wrote:

I was thinking to do the same thing, but the thought of touching/revising almost 400 items gave me chills. I don't want to touch anything I have currently listed because I am afraid it will set off some kind of wierd bug (like the scrambled listings).

Arwen? The "corruption" happened because 10,000 Merchants all tried to update their entire inventory of listings at the same time. Now that the conversion load is back to "normal", you should not run into the corruption again .. except at the same rate as it was happening before DD was launched (meaning "once in a blue moon.")

Link to comment
Share on other sites

  • Replies 54
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic


Flea Yatsenko wrote:

No, this has gone on for far longer than the introduction of Direct Delivery. The only thing is that people are finally starting to realize it now. One of the motivations behind Direct Delivery was to avoid this from happening. Magic Boxes depend on llEmail to communicate. This means that when it communicates with anything, it stops the script for 20 seconds. If any events are given to the script in that time, they get thrown on an event queue. When the queue fills up, events just disappear.

I realized it in Semptember, and I've been playing with magic boxes between then and the release of DD. The month before DD came out, I finally figured out how to manipulate and re set magic boxes so that they could run at full potential, and I made nearly twice as much in that month as I normally did.

 

DD then came out the next month and I made the almost same amount as I did the month before that (granted the Grid and MP had issues, so it's to be expected it was lower). I still made far more than I ever did with Magic Boxes, and I changed very little about my store since september.

Even with the troubles SL has had these last few weeks, I'm still set for record sales this month on DD. I advise anyone who still uses magic boxes to make the switch as fast as possible.

Magic Boxes aren't as good as DD. The difference between a Magic Box and DD is that DD tells you when a sale fails and Magic Box just gives your product away for free and doesn't say anything to you.

Because DD actually tells you your transaction had issues and MBs don't. People saw all these errors in DD and thought DD was failing more than Magic Boxes, when DD was just reporting errors Magic Boxes didn't even tell you about and they were failing at the same rate.

 

I completely agree, Flea.

For some reason, and I've been checking every single day, my sales have completely stopped now.  I've had not one in the past 3 days (at end of business today, it will be 4 days).  The first six days of this month were great for me so I have no explination for the sudden sales halt.  None are reported as "expired" or "failed"...there's just nothing. 

I'm wondering now if I'm not having the same issues that others are having in this thread.  Sales are being made and delivered, but no record of them is being sent to me and no funds are being transferred.  If so, I'm gonna be one upset individual!  

Like Toy (and others), I'm thinking the best thing is to put an on-rez script into all my products (starting with my best sellers) so I will know if this is happening.  I hope it's not.  But I want to know if it is!

Link to comment
Share on other sites

In case anyone does not know how to do this, here is a script that will send you an email the first time an object is rezzed and then delete itself.  There are loopholes - notably, if you send something with copy perms its a copy that will be rezzed, every time, so a new copy of the script will be rezzed too and you'll be told about every single time something is rezzed.  Could be a LOT of messages!

 

default{	on_rez(integer StartParam){		llEmail("***your email address here***", "Object Rezzed Report", "Your object '" + llGetObjectName() + "' has been rezzed by " + llKey2Name(llGetOwner()));		llRemoveInventory(llGetScriptName());	}}

 

Link to comment
Share on other sites

Yes replace the asterisks too so that first part looks like llEmail("email.account@hostname.com", ...

Or whatever.  You don't NEED to change anything else but can if you want to.  The format of the whole function is llEmail("email address", "subject", "message"); where "subject" is the subject-line text and "message" is the actual email text.

http://wiki.secondlife.com/wiki/LlEmail

Link to comment
Share on other sites


Darrius Gothly wrote:


Arwen Serpente wrote:

I was thinking to do the same thing, but the thought of touching/revising almost 400 items gave me chills. I don't want to touch anything I have currently listed because I am afraid it will set off some kind of wierd bug (like the scrambled listings).

Arwen? The "corruption" happened because 10,000 Merchants all tried to update their entire inventory of listings at the same time. Now that the conversion load is back to "normal", you should not run into the corruption again .. except at the same rate as it was happening before DD was launched (meaning "once in a blue moon.")

 

 

 

 

Thank you Darrius, I may try a couple of them to at least learn the proper way to do it because eventually I will have to update something out of necessity rather than preference.

Link to comment
Share on other sites


PeterCanessa Oh wrote:

In case anyone does not know how to do this, here is a script that will send you an email the first time an object is rezzed and then delete itself.  There are loopholes - notably, if you send something with copy perms its a copy that will be rezzed, every time, so a new copy of the script will be rezzed too and you'll be told about every single time something is rezzed.  Could be a LOT of messages!

 
default{	on_rez(integer StartParam){		llEmail("***your email address here***", "Object Rezzed Report", "Your object '" + llGetObjectName() + "' has been rezzed by " + llKey2Name(llGetOwner()));		llRemoveInventory(llGetScriptName());	}}

 

LOL Too funny.   So I havent written a LSL script in about 1.5 years so last night I was rusty but after about 3 - 4 hours of figuring out some basics of what I wanted the script to do and coding different ways of doing it and debugging the syntax, I finally got it working!

and although mine is a little bit more structured and does a couple more things (like get the details of the ITEM's owner and Creator and how many invoentory items are in the boxs that was rezzed), Peter's few lines does pretty much EXACTLY what mine does - even used the same concepts and functions.  It works great.  I guess I should have just waited 24hrs to let Peter tell me how to do it.

But now the next bit of an issue as Peter mentioned.  Since the fully perms builders prim box is basically pulled out of inventory whenever my customer wants to build with my landscape sculpties.... deleting the script has no value since the next rezzed builders box will have the script again.  It wont be a one-timer.  This may not be a HUGE problem as this script could become a EULA monitoring tool as I can see if the owner of the rezzed pack has ever bought my pack.  If not - it has been given to him outside of EULA agreement by a customer of mine - directly or indirectly. 

BUT the related problem is that once the several of my items with this script gets out there - there is no easy way to stop them.  I would have to hunt them all down and ask the customer to use a new nonn-script box.

The other issue which we all knew already but it a limitation to this only sales validation script is that it only triggers when the customer actually rezzes the box.  He might buy my builders box and not rez it for days or weeks. Unfortunately - there is no time closer to the actual untrusted LL MP sale transaction where a Merchant can insert monitoring / trigger of the execution of a sale that happened in MP.  Unlike an inworld sale where we could place a script in the vendor and we are actually in full control of the initiation of the sale, in MP we have no direct TRUSTED control.  When LL's MP sales transaction system screws up and we seem to be getting screwed by flawed MP sales systems, we simply have to use limited methods like ONREZ to show evidence that a sale has happened.

 

The worst part of this is that LL closed a related JIRA to this very serious problem and LL is not saynig a word how their MP sales transaction system is proving to be stealing sales $ from us merrchants.  This is serious LL.

Link to comment
Share on other sites

If people are complaining and creating tickets about magic box issues, the answer is DD. Yeah, I know some people are having issues with it, but it doesn't make sense to keep using a system that has obvious flaws. Yes, DD has issues also, but why would LL spend even another minute on Magic Boxes? Personally, I don't give a crap about Magic Boxes. If you have an issue, then change over, period. That's probably all LL's gonna tell you.

I thought about putting scripts in the products that message me when rezzed and then delete, but I sell like over 200 items a day and It's not like I need more emails. Plus, the majority of the items that I do sell are mod copy, and I watch my sales all day. If there is or was a failed delivery, I'd know it.

@Pamela - I notice this a long time ago, that people do get the vast majority of deliveries, it is just the inexperience of the user, and an automatic responce from customers to blame the MP. It was never an issue for me as most of my products are copiable. Now, hopefully with DD, we'll never get IM and especially Notecards about failed deliveries from the MP. It does say something about the service when so many just assume the product was not delivered. Let's all hope attitudes change when people know they are always going to get what they order.

Link to comment
Share on other sites

Dhyana, I just received word from Support regarding my order payment. The transaction does appear, but on May 7th. It's rather disjointed because the Order was dated November 6, 2011 (when the shopper put the item in their cart), the email confirmation came through on May 10.  There is no record of this order at all when I look at Reports->Orders even though it is now complete.

I hope that you will hear from Support soon and they will be able to help you.

Link to comment
Share on other sites


Arwen Serpente wrote:

Dhyana, I just received word from Support regarding my order payment. The transaction does appear, but on May 7th. It's rather disjointed because the Order was dated November 6, 2011 (when the shopper put the item in their cart), the email confirmation came through on May 10.  There is no record of this order at all when I look at Reports->Orders even though it is now complete.

I hope that you will hear from Support soon and they will be able to help you.

Well, I guess that answers the" cart clean-up routine and when is it run" question in my mind. ;) If it was placed in the cart in November, as an "old form" [pre-DD] product, and then was deliverd as a DD product [although I see most of your items are still boxed and not folder w/drill down items] could that have affected the order?

Link to comment
Share on other sites


Spica Inventor wrote:

The last three days I had average sales pretty much. I had a spike the 1st of May but I attribute that to peeps getting their paychecks. ;-) Slow sales on the 5th 6th and 7th of this month.

Interestingly, my sales have started up again today.  I don't know...it's just strange I guess.  All of a sudden, sales stop, a few days go by and then they start up again.  Thanks for posting, Spica!

Link to comment
Share on other sites

Hi Sassy, everything is DD in my store except one item out of 396. This was a DD item. I do not unbox them, but did convert to DD back at the beginning.

I've gotten used to the shopping cart syndrome (placed in cart one day and completed at another time), so I knew to search for that info. What is very odd is that the transaction does not appear in the Reports->Orders area at all. I keep the CSV since the start of the MP and it's not there.

Edited to add: Support did direct me to a JIRA for the disjointed reporting here:

https://jira.secondlife.com/browse/WEB-2873

Link to comment
Share on other sites

It's really an odd one, Argus. The order is marked "Delivery Expired" and then in the details "Delivered" and "Paid".  The whole stale shopping cart has been with us since the beginning.  What I've never noticed before is that the Reports->Orders report that we can download CSV should include the transaction somewhere, but it doesn't - no where.

Link to comment
Share on other sites

I'd be inclined to suggest that that's an unrelated JIRA, that's from September 2010 so can't relate to direct delivery.  It's my belief that any issue with DD should be a brand new JIRA as there's so much that has changed that it is not feasible to try to link old issues.

This is all down to poor architecture and lack of proper transactions. 

A bank (think "proper transactions") would never have a cash machine withdrawal performed on one day and days later have that shown on a statement on a totally different day and the funds moved from the account on a different day, it's really not the way it's done and although I understand there was no intention to change this, it is a situation that has been architected by LL and we must live with it.

My JIRA on this was closed as "Expected behaviour".  Poor achitecture is expected, deal with it and move on.

Link to comment
Share on other sites

I had thought to create a new JIRA for this issue, but since Support directed me to that old one, I think the only result would be a waste of my time - they'll merge the two as has been done with so many others. I saw they closed your JIRA as "expected" which is a shame. I suppose it would have to be a new feature and we know that's just way down the road if ever.

Not much else to do but move forward, so I agree with you there.  It's a constant game of cat and mouse and who's hiding the cheese.

Link to comment
Share on other sites

Sassy, you are in tune with LL's flawed sales transaction system and how DD works in MP.  AND you are a smart programmer too. 

As such, is there a better alternative to a scripted on a REZZED prim for us to consider where we Merchants can tap into and place a triggered control point?  Remembering that the alternative would have to take into account that it should be independant to LL's flawed disjointed MP sales transaction / delivery architecture as well as their screw-ups in development that would make this weak architecture impact us.

What ideas might you have?

Link to comment
Share on other sites

I should clarify by "better alternative".  I mean an alternative where we can tap in closer to the initiation of a purchase and where we could control the monitoring. 

A scripted prim that emails me is a brute force method with a bunch of flaws - as mentioned in previous posts.  Something more elegant, relevent, and flexible (ability to deploy, enable and disable).

Link to comment
Share on other sites

Not really Toy.

At least with Direct Delivery, the ANS is supposed to trigger after the payment has been made which is all i'm concerned with, at that point it's easy enough to log that data for your own reference.  Once i've got payment, I can do whatever is required to remedy anything that goes wrong. (I would do it anyway, I just prefer to be paid for it first!)

I'll take my data logs as a frame of reference any day over LL's.

What we do for our more premium products is on rez, log a licensing record which shows when it was first logged, subsequent rezzing doesn't do anything because it's already licensed.  It's a step up from what Peter provided which was sending an email but it's all down to whatever complexity you want and what skills and resources are available.

If you know someone a bit handy with php and mysql then the same is no more than an hour of effort so definitely worth paying for in my view.  No need to look at emails then, just look at the database any time there's a need to check.

Having said that, it's not hard to put on an email filter that sends all emails to a folder and they can be safely ignored until you need to query.

It's a big shame that DD wasn't taken as an opportunity to correctly handle transactions but what's done is done and we're left with loosely coupled processes.  *shrugs*

 

Link to comment
Share on other sites

I don't know about waiting; you should have asked!

You won't find any point before rezzing when any solution will be able to start.  Scripts simply don't exist in-world until then so they can't do anything at all. Except: It is possible that a third-party viewer could scan its user's inventory looking for new things as soon as they arrive.  You'd be dependent on your particular customer using that particular TPV for that to do anything though.

So assuming you're dealing with in-world events and marketplace you have two information points: ANS and item-rez.  With a server, in-world or internet-based you could capture and marry those two sets of data to see a) known sales, known rez (hooray!  they bought it and it was delivered), b) known sales, no delivery ('normal' delivery failure, the customer is lieing or they just can't find it), c) no sale, known rez (where's my money!), d) no sales, no rez (never heard of it/you).  Another advantage of such a system is that duplicate rez reports don't matter, the server will simply filter them out for you.

[Yes, I could make that and yes, it could be for everyone to use.  Yes, I would require some payment, probably some sort of subscription to use the server.  (So this would be a good one for nero to jump in on fast, lol)]

ETA:  What Sassy said, although it'd be a bit more than an hour ^^

Link to comment
Share on other sites

So ANS is as blind to flaws and bugs within the triggered sales transaction as any thing else we could potentially use to validate if LL's MP is honest and working properly or gone rogue and arbitrarily stealing sales from us merchants?  Since ANS is not triggered until after payment is received by the Merchant... the situations we are seeing here where the sale happened, the customer got his content... LL collect the $L for the sale... and LL does not pay the 95% to the Merchant would could still happen in DD without ANS's knowledge.

The benefit with MB over DD is that at least with MB (which my top listings are still using) LL had a Product Delivery Notication component within the sales transaction.  I believe this notification whas spawned by the script in the MB (independent from the backend sales proecessing).  As such, when someone buys one of my landscape packs, i still get both a SALE TRANSACTION email and a PRODUCT WAS DELIVERED email. 

With DD, LL in their wisdom decided us Merchants didnt need this Delivery Notice.  Now this may not have been any value anyway for DD (unlike MB) since the DD function is part of the backend LL systems and as such the delivery notice would be of limited value when LL screws up the sales transaction.

GAWD.... i wish LL would simple leave both DD and MB in place permanently (like Brooke promised the TPV developer las year). 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4429 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share


×
×
  • Create New...