|
|
| | Author: | misbi | Posted: | Aug 3, 2015 11:14 | Subject: | 'PAID' order status causing workflow problem | Viewed: | 164 times | Topic: | Suggestions | Status: | Open | Vote: | [Yes|No] | |
|
| Orders paid for onsite now cause the order status to be set to PAID automatically.
Please either move the new PAID status to the Payment Status column (where logically,
it should be), or if it must appear under the Order Status for technical reasons,
at least allow the PROCESSING order status to be selected after PAID status has
been set.
For discussion of the problem, see threads
http://www.bricklink.com/message.asp?ID=933149
http://www.bricklink.com/message.asp?ID=931965
|
|
| | | | | |
| | | | Author: | bb296687 | Posted: | Aug 3, 2015 11:16 | Subject: | Re: 'PAID' order status causing workflow problem | Viewed: | 37 times | Topic: | Suggestions | |
|
| This might be over simplifying, but why not treat processing and paid as the
same when viewing or preparing an order? As long as you change to ready or packed
after the order is pulled.
|
|
| | | | | | | | | |
| | | | | | Author: | misbi | Posted: | Aug 3, 2015 11:31 | Subject: | Re: 'PAID' order status causing workflow problem | Viewed: | 34 times | Topic: | Suggestions | |
|
| In Suggestions, Dr3wBurg writes:
| This might be over simplifying, but why not treat processing and paid as the
same when viewing or preparing an order? As long as you change to ready or packed
after the order is pulled.
|
Where there are multiple people picking orders there needs to be a processing
status so that two different people don't pick the same order.
The ready status isn't accessible either BTW.
|
|
| | | | | |
| | | | Author: | atrbricks | Posted: | Aug 3, 2015 11:34 | Subject: | Re: 'PAID' order status causing workflow problem | Viewed: | 32 times | Topic: | Suggestions | |
|
| In Suggestions, brickcounter writes:
| Orders paid for onsite now cause the order status to be set to PAID automatically.
Please either move the new PAID status to the Payment Status column (where logically,
it should be), or if it must appear under the Order Status for technical reasons,
at least allow the PROCESSING order status to be selected after PAID status has
been set.
For discussion of the problem, see threads
http://www.bricklink.com/message.asp?ID=933149
http://www.bricklink.com/message.asp?ID=931965
|
Agree and voted yes.
Most of my orders I set to ready before they are invoiced and packed after they
are paid.
On low feedback buyers I often pull orders after they are paid, I set these orders
to processing. The word processing tells me that the order is not yet pulled.
Now with the status changing automatically I have marked a couple orders packed
without realizing that they were in fact not yet pulled.
Not a huge deal, but I can't set the status back, and I like the status to
accurately reflect what is going on. I am not one of those sellers who marks
orders shipped when they are in fact still sitting on my desk.
Anyway, processing is a long word and it gets my attention
Thanks,
Katie
|
|
|
| | | | | |
| | | | Author: | dlaw1_lego | Posted: | Aug 3, 2015 11:38 | Subject: | Re: 'PAID' order status causing workflow problem | Viewed: | 35 times | Topic: | Suggestions | |
|
| In Suggestions, brickcounter writes:
| Orders paid for onsite now cause the order status to be set to PAID automatically.
Please either move the new PAID status to the Payment Status column (where logically,
it should be), or if it must appear under the Order Status for technical reasons,
at least allow the PROCESSING order status to be selected after PAID status has
been set.
For discussion of the problem, see threads
http://www.bricklink.com/message.asp?ID=933149
http://www.bricklink.com/message.asp?ID=931965
|
+1 even my refunded payments are still showing as 'paid' and I cant change
the status
|
|
| | | | | |
| | | | Author: | steekstra | Posted: | Aug 3, 2015 11:55 | Subject: | (Cancelled) | Viewed: | 52 times | Topic: | Suggestions | |
|
| (Cancelled) |
|
| | | | | |
| | | | Author: | RobErNat | Posted: | Aug 3, 2015 13:05 | Subject: | Re: 'PAID' order status causing workflow problem | Viewed: | 37 times | Topic: | Suggestions | |
|
| In Suggestions, brickcounter writes:
| Orders paid for onsite now cause the order status to be set to PAID automatically.
Please either move the new PAID status to the Payment Status column (where logically,
it should be), or if it must appear under the Order Status for technical reasons,
at least allow the PROCESSING order status to be selected after PAID status has
been set.
For discussion of the problem, see threads
http://www.bricklink.com/message.asp?ID=933149
http://www.bricklink.com/message.asp?ID=931965
|
I'm quite puzzeld by your request...
For starters I agree there should be an extra option in the order status options,
something like 'picking', before it can set to 'packed', as it
would be conveniant for larger stores who have more then one person to process
orders, so they know if the picking lists have been 'handed out'.
But...
If a store has multiple people to do the picking, then I assume they have set
up a system which allows them to know who is doing what... I do assume these
'compagnies' have persons who communicate with eachother, organised by
the shop owner, no? I don't so 'why' suddenly this has become a problem,
because from a technical point of view, if the shopowner used to check received
payments, he/she would set the order in 'paid' status, and after all,
it always came 'after' the processing status... So nothing has changed,
the only thing that is happening now, is that 'now' the shopowner doesn't
need to set the status to 'paid' as it is done automaticly.
I notice from your FB list, that for the past year you have received about 410
feedbacks.
Some of them are for you as a buyer (I did not check how many), and assuming
about 20-25% of people do not leave feedback, it means you had about 500 Orders
on BL the past 12 months. That's less then 1.5 orders per day, yet you're
not able to manage the 'status' of orders or to 'know' which
'picker' is doing what Granted, I do not know whether you also sell
on other sites like Fleebay, Amazon, Brickowl and other websites, but an average
of 1.5 orders per day on Briclink seems quite managable IMHO... When I look at
my received orders for the past 12 months, I notice I had 226 on Bricklink (and
closed over 2 months) and 542 on Brickowl, totalling +765 orders, and did it
all by myself 'after' my dayjob... I never had an issues to 'know'
which order had to be picked, as at all times, an order in 'paid' status
would go at the back of the pile, first in first out (in most cases), with an
average processing time of less then 48 hours (=order shipped)
Now don't get me wrong, it's not a critisism as I have no idea what else
you're running, but from your amount of processed order on BL, it would say
the only thing that is missing in you store is 'comms' between the people
who 'manage' your store and maybe a bit of lack or organisation.... Maybe
you should reduce that to just 1 person, as handling 1.5 orders per day, is IMHO
quite manageable for just 1 person
cheers, Eric
|
|
|
| | | | | | | | | |
| | | | | | Author: | misbi | Posted: | Aug 3, 2015 14:11 | Subject: | Re: 'PAID' order status causing workflow problem | Viewed: | 32 times | Topic: | Suggestions | |
|
| In Suggestions, RobErNat writes:
| In Suggestions, brickcounter writes:
| Orders paid for onsite now cause the order status to be set to PAID automatically.
Please either move the new PAID status to the Payment Status column (where logically,
it should be), or if it must appear under the Order Status for technical reasons,
at least allow the PROCESSING order status to be selected after PAID status has
been set.
For discussion of the problem, see threads
http://www.bricklink.com/message.asp?ID=933149
http://www.bricklink.com/message.asp?ID=931965
|
I'm quite puzzeld by your request...
For starters I agree there should be an extra option in the order status options,
something like 'picking', before it can set to 'packed', as it
would be conveniant for larger stores who have more then one person to process
orders, so they know if the picking lists have been 'handed out'.
But...
If a store has multiple people to do the picking, then I assume they have set
up a system which allows them to know who is doing what... I do assume these
'compagnies' have persons who communicate with eachother, organised by
the shop owner, no? I don't so 'why' suddenly this has become a problem,
because from a technical point of view, if the shopowner used to check received
payments, he/she would set the order in 'paid' status, and after all,
it always came 'after' the processing status... So nothing has changed,
the only thing that is happening now, is that 'now' the shopowner doesn't
need to set the status to 'paid' as it is done automaticly.
I notice from your FB list, that for the past year you have received about 410
feedbacks.
Some of them are for you as a buyer (I did not check how many), and assuming
about 20-25% of people do not leave feedback, it means you had about 500 Orders
on BL the past 12 months. That's less then 1.5 orders per day, yet you're
not able to manage the 'status' of orders or to 'know' which
'picker' is doing what Granted, I do not know whether you also sell
on other sites like Fleebay, Amazon, Brickowl and other websites, but an average
of 1.5 orders per day on Briclink seems quite managable IMHO... When I look at
my received orders for the past 12 months, I notice I had 226 on Bricklink (and
closed over 2 months) and 542 on Brickowl, totalling +765 orders, and did it
all by myself 'after' my dayjob... I never had an issues to 'know'
which order had to be picked, as at all times, an order in 'paid' status
would go at the back of the pile, first in first out (in most cases), with an
average processing time of less then 48 hours (=order shipped)
Now don't get me wrong, it's not a critisism as I have no idea what else
you're running, but from your amount of processed order on BL, it would say
the only thing that is missing in you store is 'comms' between the people
who 'manage' your store and maybe a bit of lack or organisation.... Maybe
you should reduce that to just 1 person, as handling 1.5 orders per day, is IMHO
quite manageable for just 1 person
cheers, Eric
|
Suffice to say that your analysis and conclusion are flawed, but a fun read all
the same, so time well spent
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | Author: | RobErNat | Posted: | Aug 3, 2015 14:41 | Subject: | Re: 'PAID' order status causing workflow problem | Viewed: | 38 times | Topic: | Suggestions | |
|
| In Suggestions, brickcounter writes:
| Suffice to say that your analysis and conclusion are flawed, but a fun read all
the same, so time well spent
|
Why would my analysis and conclusions be flawed
If you run 'full time' (with several people) a business, of which 'BL'
is only part, with the amount of orders on BL, 1 person could do the 'BL'
processing, while others process orders from other venues. I do understand that
your method is a typical 'BO' method, because indeed the BO system allows
an intermediate step: 'processing', before an order is set 'processed'
(I oftenly skip the intermediate step) and it allows you to know 'someone'
is handling a certain order. Granted, right now BL doesn't allow such, but
if you have 1 person focussing on BL and 'filling' in on BO (and/or other
venues), then your problem is solved
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | Author: | misbi | Posted: | Aug 3, 2015 15:06 | Subject: | Re: 'PAID' order status causing workflow problem | Viewed: | 39 times | Topic: | Suggestions | |
|
| In Suggestions, RobErNat writes:
| In Suggestions, brickcounter writes:
| Suffice to say that your analysis and conclusion are flawed, but a fun read all
the same, so time well spent
|
Why would my analysis and conclusions be flawed
If you run 'full time' (with several people) a business, of which 'BL'
is only part, with the amount of orders on BL, 1 person could do the 'BL'
processing, while others process orders from other venues. I do understand that
your method is a typical 'BO' method, because indeed the BO system allows
an intermediate step: 'processing', before an order is set 'processed'
(I oftenly skip the intermediate step) and it allows you to know 'someone'
is handling a certain order. Granted, right now BL doesn't allow such, but
if you have 1 person focussing on BL and 'filling' in on BO (and/or other
venues), then your problem is solved
|
Also, if Bricklink fixes it, my problem is solved
|
|
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | Author: | RobErNat | Posted: | Aug 3, 2015 15:16 | Subject: | Re: 'PAID' order status causing workflow problem | Viewed: | 30 times | Topic: | Suggestions | |
|
| In Suggestions, brickcounter writes:
| Also, if Bricklink fixes it, my problem is solved
|
Now what has changed that would require a 'fixing'?
A lot of sellers prepare their order, then send an invoice, buyers pays, order
is set to packed.
Others prepare after being paid, so if the seller followed the procedure (aka
setting the order 'paid', when indeed payment got in), and now the system
does it, then nothing has changed either...
|
|
| | | | | |
| | | | Author: | QCBricks | Posted: | Aug 3, 2015 17:34 | Subject: | Re: 'PAID' order status causing workflow problem | Viewed: | 34 times | Topic: | Suggestions | |
|
| In Suggestions, brickcounter writes:
| Orders paid for onsite now cause the order status to be set to PAID automatically.
Please either move the new PAID status to the Payment Status column (where logically,
it should be), or if it must appear under the Order Status for technical reasons,
at least allow the PROCESSING order status to be selected after PAID status has
been set.
For discussion of the problem, see threads
http://www.bricklink.com/message.asp?ID=933149
http://www.bricklink.com/message.asp?ID=931965
|
The real killer with this is that you cannot changed the status if there is an
issue. If the buyer makes a mistake with PayPal and the payment is refunded,
it just stays in Paid status on BL. No way to change it to Ready or any other
status "before" Paid. This can be terribly confusing to a buyer and can also
cause all sorts of problems for sellers when multiple people are involved in
the processing. If one does not notice or remember that there has been an issue,
the order can easily be shipped even after a payment has been refunded because
the status cannot be changed from Paid.
In addition, what some other people do not understand is that stores use the
Paid status in a number of ways. One potential way is as a double check for
the number of payments received. When BL just randomly inserts another "Paid"
order into the mix that is probably something that is quite confusing.
This is a simple fix. Change onsite payments to have a status like "Paid(Onsite)"
in the actual Order Status dropdown and this will likely be enough of a signal
for stores using this feature. They can then each decide how to react to that
Order Status. (Change it to paid, or any other status)
Scott
|
|
|
| | | | | | | | | |
| | | | | | Author: | QCBricks | Posted: | Aug 3, 2015 18:29 | Subject: | Re: 'PAID' order status causing workflow problem | Viewed: | 44 times | Topic: | Suggestions | |
|
| In Suggestions, QCBricks writes:
| In Suggestions, brickcounter writes:
| Orders paid for onsite now cause the order status to be set to PAID automatically.
Please either move the new PAID status to the Payment Status column (where logically,
it should be), or if it must appear under the Order Status for technical reasons,
at least allow the PROCESSING order status to be selected after PAID status has
been set.
For discussion of the problem, see threads
http://www.bricklink.com/message.asp?ID=933149
http://www.bricklink.com/message.asp?ID=931965
|
The real killer with this is that you cannot changed the status if there is an
issue. If the buyer makes a mistake with PayPal and the payment is refunded,
it just stays in Paid status on BL. No way to change it to Ready or any other
status "before" Paid. This can be terribly confusing to a buyer and can also
cause all sorts of problems for sellers when multiple people are involved in
the processing. If one does not notice or remember that there has been an issue,
the order can easily be shipped even after a payment has been refunded because
the status cannot be changed from Paid.
In addition, what some other people do not understand is that stores use the
Paid status in a number of ways. One potential way is as a double check for
the number of payments received. When BL just randomly inserts another "Paid"
order into the mix that is probably something that is quite confusing.
This is a simple fix. Change onsite payments to have a status like "Paid(Onsite)"
in the actual Order Status dropdown and this will likely be enough of a signal
for stores using this feature. They can then each decide how to react to that
Order Status. (Change it to paid, or any other status)
Scott
|
Just a real world example from today for the doubters.
We like to keep a pdf copy of every invoice due to the circa-1999 6 month purge.
Today, in the process of shipping orders, a buyer used PayPal (Onsite) on BL.
Our staff member was going through shipping packages. There is nothing that
let her know that a new Paid order slipped into the list when the buyer paid.
She processed it and printed the label. It was packed and set to that status
without us ever printing our pdf copy of the order.
There is nothing in the current workflow that helps a store overcome those issues.
The payment that comes in on that situation looks no different than any other
payment. It leaves it all up to someone catching the issue along the way or
introducing a long, time consuming process where our staff must "true-up" every
payment with every order.
Scott
|
|
|
| | | | | | | | | |
| | | | | | Author: | DadsAFOL | Posted: | Aug 3, 2015 21:00 | Subject: | Re: 'PAID' order status causing workflow problem | Viewed: | 52 times | Topic: | Suggestions | |
|
| In Suggestions, QCBricks writes:
| In Suggestions, brickcounter writes:
| Orders paid for onsite now cause the order status to be set to PAID automatically.
Please either move the new PAID status to the Payment Status column (where logically,
it should be), or if it must appear under the Order Status for technical reasons,
at least allow the PROCESSING order status to be selected after PAID status has
been set.
For discussion of the problem, see threads
http://www.bricklink.com/message.asp?ID=933149
http://www.bricklink.com/message.asp?ID=931965
|
The real killer with this is that you cannot changed the status if there is an
issue. If the buyer makes a mistake with PayPal and the payment is refunded,
it just stays in Paid status on BL. No way to change it to Ready or any other
status "before" Paid. This can be terribly confusing to a buyer and can also
cause all sorts of problems for sellers when multiple people are involved in
the processing. If one does not notice or remember that there has been an issue,
the order can easily be shipped even after a payment has been refunded because
the status cannot be changed from Paid.
In addition, what some other people do not understand is that stores use the
Paid status in a number of ways. One potential way is as a double check for
the number of payments received. When BL just randomly inserts another "Paid"
order into the mix that is probably something that is quite confusing.
This is a simple fix. Change onsite payments to have a status like "Paid(Onsite)"
in the actual Order Status dropdown and this will likely be enough of a signal
for stores using this feature. They can then each decide how to react to that
Order Status. (Change it to paid, or any other status)
Scott
|
I second Scott that the recent changes aren't optimal for business sellers.
There is a problem/bug - unable to ever mark an order unpaid after paid (failed
payment, sent incorrectly, bounced echeck, whatever). There are many scenarios
and this needs to be fixed.
There is a separate issue with how stores use some of the statuses differently
than others. This is more of an enhancement request, not really a bug. We used
to use "ready" to reflect "picked, waiting for packing/postage". With the recent
changes, "ready" is disabled on paid orders. We had to quick-code a side status
so we can tell the difference between "paid" and "picked". This is only visible
to us, not to our customers. Options to meet this need:
1. change the code that locks "ready" so that it can be used after paid.
2. create a new status for "picked"
3. create seller preference settings to enable statuses, define what sequence
the seller uses them in, and whether a status represents paid/order locked.
I did comment in a separate thread that there is one benefit from this change
- the occasional issue of buyers adding to paid/packed orders is resolved. If
its paid, you can no longer add a batch.
|
|
|
|
|
|