One problem I see is that you are apparently trying to sort the keys of %bighash, even though their ordering is not relevant to your task. Besides, you are doing this for each of the desired stores, when what you should be doing is sorting the stores according to the data you have for them (i.e. not iterating over them).

Here's a not-particularly-clever-but-serviceable way to do it:

# first get rid of the nuisance "set" keys (i.e. the primary keys of %
+bighash);
# they add nothing to the solution and just get in the way.
my %flatten;
for my $h ( values %bighash ) {
  @flatten{ keys %$h } = values %$h;
}

# now pull out the desired data from %flatten, pack it in records
# whose first element is the name of the store, and sort these records
# in ascending numerical order according to the [ 1 ][ 0 ]-th element
# of each record (which corresponds to the earnings).
my @sorted_data =
  sort { $b->[ 1 ][ 0 ] <=> $a->[ 1 ][ 0 ] }
  map [ $_, $flatten{ $_ } ], @st;

# now it's just a matter of printing the sorted records.
for my $record ( @sorted_data ) {
  print "STORE: $record->[ 0 ] EARNING:$record->[ 1 ][ 0 ]\n";
  for my $i ( 1 .. $#{ $record->[ 1 ] } ) {
    print join( ',', @{ $record->[ 1 ][ $i ] } ), "\n";
  }
  print "\n";
}
[download]

This is a pretty naive solution that makes no attempt at optimization. E.g. it may be unacceptably wasteful to flatten %bighash just to more easily access a few records.

On the other hand, the problem doesn't look well-posed to me, so a more efficient solution at this stage may be premature. What I mean by not being well-posed is that it is not clear that, in general, records corresponding to the same store won't appear in different sets.