Broadleaf Commerce Discussion Forums

Hi,

I'm investigating discount system of broadleaf framework. I have a couple of questions here.

1. I've created general discount offer on order. Rule is simple: any order that exceeds 50EUR,
will be given 25% off. This is created/defined using BO.
What I noticed in process of debuging is that with this kind of offer, Order will be affected
in a way that if offer is present, List<OrderAdjustment> will have at least one item, the item
that I defined in BO.

On the other hand:
2. I've created one more offer that should be promoCode offer. I've provided input field for entering promoCode on checkout page (similar to DemoApplication) and added functionality so that entering promoCode will result in triggering method "addPromo" of BroadleafCartController.
What differs here is that not same Objects are affected by this change. Again in debug mode I can see that Order has been changed so that List<OfferCode> will now be populated instead of List<OrderAdjustment>.

Is this a way that these offerring system should work?

If this is the case I can imagine that I will need to rework my custom pricing activity (e.g. named CustomTotalActivity) that is responsible for calculating total price. Since now these entities (from List<OfferCode>) is not part of calculation and therefore my total price is not substracted for amount of money in custom promoCode offer.

Thank You

Both cases above should generate a list of order adjustments for your order. This is done by the "org.broadleafcommerce.core.pricing.service.workflow.OfferActivity" which is the first step in the Pricing Workflow.
The OfferActivity calls "buildOfferListForOrder(Order order)" which: "Creates a list of offers that applies to this order. All offers that are assigned to the customer, entered during checkout (via a promo code), or has a delivery type of automatic are added to the list. The same offer cannot appear more than once in the list."

This offer list is then evaluated against the state of the cart to make sure it still applies and then creates the appropriate OrderAdjustments that are necessary. If this is not the case, then something else may be a factor in it not working that way.

Hi,

I noticed one strange thing that might be the problem here.
In BO admin > Offer, if I have promoCode offer (e.g. Customer Qualification - Shared Code and applicable to all customers) no matter what you choose for Description > Type it will always be set to "Order Item".
Even I changed this manually to "Order", buttons at the top "Save" and "Restore" will be enabled for a while but again will be disabled. If I refresh search and look again my promoCode offer, Description > Type will be OLD value of "Order Item".


Can this be the case? I want to apply promoCode offer to WHOLE order not order item?

I've done more debugging and introspection and here are some interesting points:

1. I want to thank @elbertbautista for pointing me out that OfferActivity of Pricing Workflow.

2. If I take a look into OfferActivity what is most interesting is folowing lines:



In List<Offer> I have all offers that I've prepared in BO. Then come the call offerService.applyOffersToOrder.



I would expect that, after promoCode is applied, and call itemOfferProcessor.filterOffers is called, that least one of those two Lists, either qualifiedOrderOffers or qualifiedItemOffers are populated but both of them are empty.


Can someone give me more insight in this ?


Thank You

In addition to previous posts,

as I explained, it is not possible to define promoCode offer to be "Description" > "Type" - "Order". Whatever I do this stays the OrderItem.

Therefore following code


as part of OfferServiceImpl.applyOffersToOrder method will result in a call to ItemOfferProcessor.
Method that should be executed is filterItemLevelOffer.

There you can find that flags: itemLevelQualification and offerCreated are set to false, and later they will change value if there are some rules satisfied. But in my case


will result in empty resultSet and therefore itemLevelQualification will always be FALSE.
As a side-effect following condition will never be satisfied:

After more & more introspection,

as I can see, getDiscountableDiscreteOrderItems method of PromotableOrderItem depends on DISCOUNT_FLAG of Sku.
In my DB, we never set this flag to any of SKU's. Can this be the reason?

I can imagine the business logic, that Product Provider will have to have mechanism in order to ENABLE/DISABLE on which product promoCode could be applied and on which can't.

Am I getting "warmer" here ?

Thank You