• Toll-free  888-665-8637
  • International  +1 717-220-0012
Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

CorneliuTusnea
#1 Posted : Friday, September 7, 2007 10:09:43 AM(UTC)
CorneliuTusnea

Rank: Member

Joined: 8/17/2006(UTC)
Posts: 681

I have an old order that I try to edit (e.g. Fix the address) and as soon as I save it it applies the new promotional offers on products that don't require a code that are part of the order.
Eg. Product 1 was added to the order with price $50.

Then I create a special offer on the product with 20% discount.

Then I edit the order and when I save it the new promotional offer is automatically applied but IT SHOULDN'T. Now my order is in Overpaid mode which is wrong as it was correct at the time of entry.



Is there any quick fix?

Thanks,

Corneliu.
http://www.bestgames.com.au
http://www.bestchess.com.au



BV Product Links, Details and Signatures: Improve your customer experience:

http://www.acorns.com.au/projects/bv/quicklink/

jetheredge
#2 Posted : Friday, September 7, 2007 10:26:48 AM(UTC)
jetheredge

Rank: Member

Joined: 3/1/2006(UTC)
Posts: 1,142

There is no quick fix for this, we use the same pipeline for processing product prices everywhere. The problem is that when you add a product to an order we don't know what your intention is, and currently we cannot tell the difference between an item that was just added or an item that was already on the order. We recalculate the whole order at once in order to figure out totals.

If anyone has any cunning ideas on how this could be address without adding a lot of complexity to the way in which we calculate the discounts please make suggestions.

Without putting a lot of thought into it, it looks like we would have to
a) Store on the line item when it was added to the order (potentially for each quantity, since we could adjust the quantity of a line item)
b) Check the start and stop date of all sales and discounts in order to check that each line item falls within these dates

I guess another option would be to mark line items as "paid" when an order is paid, then we could ignore those line item quantities when calculating the discounts.

Both of these options would still have issues with the product pricing workflow, since the context for this workflow doesn't have any knowledge of line items or orders.

Anyone have any thoughts?
Justin Etheredge
Senior Software Engineer
BVSoftware
bvuser
#3 Posted : Friday, September 7, 2007 2:04:47 PM(UTC)
bvuser

Rank: Member

Joined: 4/10/2006(UTC)
Posts: 462

This behavior is the same reason I don't want anything changing once an order is marked as "Is Placed" (Referencing your post here, http://forums.bvcommerce...lt.aspx?f=88&m=49858).

Personally, I think once an order is marked "Is Placed" the best/only way to handle it, is that any product added is added at the "Site Price" and any product already on the order keeps the price that was already assigned when the order was marked placed.

This allows the admin to establish whatever price he wants for the order and the lineitem. When manually editing an order, a human is involved interacting witht he customer, leave the computers and automation out of it and let the rep handle the pricing.
Netriplex Corporation<br />
birdsafe
#4 Posted : Friday, September 7, 2007 2:05:08 PM(UTC)
birdsafe

Rank: Member

Joined: 2/21/2007(UTC)
Posts: 1,113

Not being a developer, it seems to me though that if there was an "archive order" function, where only the items are listed and amounts but no calculations are done, then it should not affect the current pricing/discount flow. This sort of scheme would also take care of the problem of deleted items not showing on past orders.
bvuser
#5 Posted : Friday, September 7, 2007 2:30:11 PM(UTC)
bvuser

Rank: Member

Joined: 4/10/2006(UTC)
Posts: 462

My problem and I think corneliu's problem is not necessarily with "archived" orders (I'm assuming your referring older orders). This problems comes to light for any site where promotions/price changes occur often and/or on the day of promo ending/beginning.

For example, you run a promotion in sept for 10% off everything. Someone places an order sept 30 receives the 10% off. Now for some reason you need to go into the order to change something, maybe even add something to the order on Oct 1. Once you click "Edit Order" the 10% discount is removed from that customers order.

From a developer's standpoint and from having reviewing the code a bit for the editorder page, if there is no way for the product pricing pipeline to not run for some reason, I think that on the first load of editorder, the "AdminPrice" property should be updated with the pricing of the product when the order was placed to hold the price from changing. Then to make everyone happy, a button could be added next to the lineitem, that could retrieve the current pricing for that user is a customer service rep wanted. This way the rep is still in total control and the price is frozen unless the rep specifically changes it either by retrieving the current "pipeline calculated" price or by entering their own price.
Netriplex Corporation<br />
jetheredge
#6 Posted : Friday, September 7, 2007 2:38:03 PM(UTC)
jetheredge

Rank: Member

Joined: 3/1/2006(UTC)
Posts: 1,142

I like the idea of using the AdminPrice property, the only issue is on order discounts. When you go to this page we will still recalculate order discounts. This would create some weird situations, such as...

Someone purchases 1 item for $300.00 and they purchase it 1 day before a 20% order total discount goes into effect. They then call the next day realizing that they forgot a $10 accessory they needed to purchase. The order is now $310.00 and they have paid 300.00, but if we want to apply the 20% discount we will have to figure out what is new and what is old. This will add a layer of complexity that we would love to avoid.
Justin Etheredge
Senior Software Engineer
BVSoftware
bvuser
#7 Posted : Monday, September 10, 2007 8:53:39 AM(UTC)
bvuser

Rank: Member

Joined: 4/10/2006(UTC)
Posts: 462

Hi Justin,

I really don't think it is that hard to get around that issue. All that needs to be done, is the workflow tasks that calculate order discounts simply need to check the "IsPlaced" property. If the order "IsPlaced" the task should do no work and there should be an easy method on the editorder page to retain the previous value for "OrderDiscounts" to make sure they stay applied at the end of the pipeline processing.

Again, if the rep needs to add of remove discounts, the functionality is there by either changing the lineitem price directly or using the "Admin Discounts" field.

I guess my whole thing is that the automation is nice for the web facing side of the store, however, it is not "nice" or needed when a human rep is there to process everything. All the computer does is cause frustration as the rep doesn't know exactly why/what the computer is doing. On one screen they see Order Discount $10, think everything is fine, click save order, and suddenly the order discount is $11. Now they need to go readjust the order again.

The whole theme of my ideas is that once an order "IsPlaced" the only thing that should be able to change ANYTHING able the order is direct human overrides. Then, give the human the choice to get the computer involved with buttons that can request the current pricing or the current discounts that are available as I am sure there are situation where this information is actually needed/wanted.
Netriplex Corporation<br />
CorneliuTusnea
#8 Posted : Monday, September 10, 2007 8:53:59 AM(UTC)
CorneliuTusnea

Rank: Member

Joined: 8/17/2006(UTC)
Posts: 681

Justin,
I think the idea a. would the be right one and not extremly hard to implement.
When the order would be saved as IsPlaced you would have to save with each LineItem the bvin's of the offers that were applied to the order. Then on any calculate you would only apply these offers. I'm not sure if this would cover all scenarios though.
Also, please do another small change. Please make the calculate of the GlobalTotal as part of a workflow. That would allow us to very easily change the Tax to be applied as GST not as VAT so the Global Total would equal the SubTotal and the tax would be extracted out of it as it is applied in Europe and Australia.
Thanks,
Corneliu.
http://www.bestgames.com.au
http://www.bestchess.com.au



BV Product Links, Details and Signatures: Improve your customer experience:

http://www.acorns.com.au/projects/bv/quicklink/

CorneliuTusnea
#9 Posted : Monday, September 10, 2007 8:54:06 AM(UTC)
CorneliuTusnea

Rank: Member

Joined: 8/17/2006(UTC)
Posts: 681

Justin,
1. I had the feeling I replied to this post but I don't see my post. It would not be the first time I have this feeling. Can you please check that? :)
2. Your weird situation is more of a management situation than a technical one. As long as the software allows me to run my business better I'm happier.
ATM I can't run the business properly because the software does not allow me too.
Regarding the “20% off starting the next day”, believe me, if a customer calls the next day asking to add a new product to the order and kindly asking me to give him the 20% off that was just applied I will, as it keeps me the customer and he will come back to me.
Regards,
Corneliu.
http://www.bestgames.com.au
http://www.bestchess.com.au



BV Product Links, Details and Signatures: Improve your customer experience:

http://www.acorns.com.au/projects/bv/quicklink/

scott.mech
#10 Posted : Wednesday, October 3, 2007 4:28:13 PM(UTC)
scott.mech

Rank: Member

Joined: 4/4/2004(UTC)
Posts: 670

I posted a lengthy response a few weeks back, but it must not have made it through moderation.

Once an order is submitted by the user, it should be persisted and the data should not change unless a change is explicitily requested.
Changes to the catalog, marketing, promos, coupons, discounts, or anything else should have zero impact on an submitted order.

I would not expect a user to expect or anticipate any behavior that violates either of the two above statements. I would consider any variation in regards to this to be a defect.

Scott Mech
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

©2025 Develisys. All rights reserved.
  • Toll-free  888-665-8637
  • International  +1 717-220-0012