Kentico - Adding multiple discounts - kentico

I'm using Kentico version 8.2, and am trying to allow a user to enter multiple coupons. In the ECommerceContext.CurrentShoppingCart object you have a ShoppingCartCouponCode that you can set. This then adds this coupon to the Discounts collection on that object.
If I change the ShoppingCartCouponCode to something else, then the Discount collection gets recreated with a single item of the new discount again, and loses the old discount.
If I store a copy of the discount collection, then apply the new coupon entered, and then append the copied collection to the new generated Discount collection then that works for only a couple of discounts. I am concerned that doing it this way will cause issues elsewhere.
So has anyone implemented this functionality before and how did/would you go about it?


EDIT: Although it seems like Product Coupons should allow you to do this, they don't work quite the way you would think. When a Product Coupon is applied to the cart, the ShoppingCartDiscountCouponID field for that cart's record in COM_ShoppingCart is updated to include a foreign key reference to the ID of discount coupon in COM_DiscountCoupon. So there can definitely be only one Product Coupon applied to the cart at any one time.
So instead of being a discount on a particular product, they seem to be more like flags that allow you to apply discounts to the entire cart if a particular product is in the cart and the correct coupon code is entered.
However, that doesn't mean we can't do some customization to achieve this affect ourselves. Our first step will be to change the ShoppingCartContent control in CMSModules > Ecommerce > Controls > ShoppingCart to allow multiple coupon codes to be entered. That's the easy part.
The second part is to change how discounts and carts are associated. This could require modifying Kentico's system tables, so do so at your own risk. You'll basically want to decouple foreign key reference from the COM_ShoppignCart table and create a many-to-many relationship between carts and discounts. Personally, I would leave the system tables and API alone and just create another custom table that mapped CartIDs to DiscountIDs (you will probably have to do the same with Orders, too since cart data is applied to order data when an order is created).
The last part is changing how discounts are actually calculated.
Earlier I suggested creating a custom DiscountCouponInfoProvider. Turns out, what you actually want to do is create a custom ShoppingCartInfoProvider and override one of the following methods:
CalculateOrderDiscount()
CalculateItemsDiscount()
I apologize if this isn't descriptive enough, but this will be a significant modification to how Kentico handles Product Coupons, so I don't have a lot of time to get into specifics. However, I would estimate that it would take a least a few weeks to accomplish.
old answer
Hmm, you could create discounts that represent combinations of two or more discounts and apply those if a user selects the right combination.
Or, what I would prefer if I had the time to build it, would be to create a custom DiscountCouponInfoProvider that changes how discounts are applied.M

Related

Netsuite Sales orders suddenly have an additional step (complete) when done through CSV import

I am updating my company's system so that it supports dropshipping items. Ever since I switched to this type of item it asks me to complete the order after I approved it. what is it that I am missing so that I can skip this step altogether, is it even possible to skip the step, or to complete multiple orders at the same time (like how you can approve multiple orders)?
It bears mentioning the Company operates in Mexico.
the steps I take are as follow:
I create and save a sales order, that is, I put in the client, the document and reference number, and the item, as well as a couple of custom fields
the next screen asks me to approve the order, I do it and it creates the matching purchase order
then instead of being able to invoice, I first have to "complete" which takes me to an order fulfillment form
I save that and the order can be invoiced.
Ideally, after approval, I would just be able to invoice

Generally a sales order is not invoicable until it's been fulfilled.
You can override that at a whole account level by going to
Setup -> Accounting -> Accounting Preferences
Order Management tab
scroll to Invoicing
check 'Invoice in Advance of Fulfillment'
Be aware this is a system level setting and if you used to be able to invoice before fulfillment someone else in your company may have unchecked this setting in the recent past.
Alternatively at the individual item level you can use the 'Can be fulfilled/received' checkbox to allow invoicing without fulfilling. Note that 'Can be fulfilled/received' may not be changed after an item has been ordered.
Normally (US/Canada) an order should not be invoiced until it is shipped. Customer Deposits on Sales Orders are the preferred way to handle pre-payment for GAAP etc reasons.

Is is possible to check the lot number in Netsuite Inventory Detail against a value defined at the work order level?

We are having an issue with our team members entering completions for the wrong lot number. Does anyone know of a way to have the inventory detail sub-menu check against a lot number value assigned when creating the work order?
Lot number does not seem to be a native field when generating work orders, so I created a custom field for it, which seems to work okay and will propagate through the rest of the document chain, however, I do not have a guess at how to check inventory detail values against this field.

In Acumatica, using #me inside Relations Section of Generic Inquiry

We want to have a sales order dashboard where we only show orders for certain sales people based on the logged in user. For example, we have sales people BB and CR who share an assistant TP. BB can see his orders on the dashboard. CR can see his orders on the dashboard. TP can see orders for both of them on his dashboard. We also have people outside of sales who need to see all orders. We want to do all of this without having to create a bunch of custom dashboards. We wanted to maintain 2 dashboards - one filtered one for sales people and one unfiltered one for everyone else.
We have gotten close to solution by using a generic inquiry. We created custom fields on the salesperson that point back to a logged in user (UserID1 and UserID2). Multiple custom fields were used because a single sales person could be visible to 2 people. We then joined SOOrder to SalesPerson inside our GI. We then wanted to join the Users table on (SalesPerson.UserID1 = Users.PKID AND SalesPerson.UserID1 = #me) OR (SalesPerson.UserID2 = Users.PKID AND SalesPerson.UserID2 = #me). That would allow us to create a filter where Users.PKID is not null to limit the view for sales people and then not use any filter on the non-sales dashboard.
The problem is that #me is not available on the Relations section. It is only available on the conditions section. We tried to just have the join of SalesPerson.UserID1 = Users.PKID or SalesPerson.UserID2 = Users.PKID and then creating the condition for the #me portion. The issue there is that it only shows records with a match. That won't work for non-sales people.
Is there some way to include #me or an equivalent on the relations tab? Any better way to accomplish this?

Built-in variables like '#me' aren't well documented which raises questions about support of this feature.
Try this instead:
In generic inquiry TABLES tab, add table 'PX.Data.AccessInfo'.
In PARAMETERS tab, add a new parameter (ex: 'P1') and set the Schema Field value to 'Accessinfo.UserID' (use 'Accessinfo' or the alias for that table declared in TABLES tab).
In the RELATIONS tab in the join condition Child Field you can reference the '[P1]' variable.
Accessinfo DAC contains current record of the logged in user and reflects the information you see when you click your profile in the top right of Acumatica pages. If the solution doesn't work right away you can debug it with the Request Profiler page to look up the generated SQL query for the GI.

How to manage number of left items in an ecommerce website for items with limited quantity?

I am developing an e-commerce site in node, We have an item with limited quantity, so as soon as the user selects I made it so that number of items he asked for is checked and if okay those items will be decremented from database, but then if the user does not complete the payment, it will be a mess. So if you guys could advice a better strategy it'll be cool example project or code will be even more cooler!

Cache the description along with the price of the product, so when each request comes for the item it will return the Product description and price if quantity is more than one. On every purchase(payment in your case) of the product, reduce the quantity of particular item in the database. When product stock reaches to zero, remove it from the cache or show it to customer as out of show. It's normal way ecommerce works.

Sharepoint: Integrity of lookup fields after a list import

I got a question about the behavior of lookup fields when importing data. I wonder how the lookup fields behave when the list they point to is being replaced/imported. To explain the issue, I will provide a quick example below:
As example, assume we have these two sharepoint lists:
Product Types
-------------
+ Type Name
+ Code Nr
+ etc
Products
--------
+ Product Name
+ Product Type (Lookup field to list "Product Types")
+ etc
In my scenario, the Products List contains production data on the production Sharepoint platform. It is filled with data by the business users.
However the Product Types list contains rather static data and is maintained by the developer.
Now after a development cycle, the developer wants to deploy his new webparts and his new data (product types list). The developer performs the following procedure:
On the dev machine: Export "product type" list using stsadm
On the production machine: Delete all items in the "product type" list
On the production machine: Import the "product type" list using stsadm
This means we basically replace the "product type" list on the production server while keeping the "product" list as it is.
Now the question:
Is this safe? Will the lookup references break under certain circumstances?
Any downside of this import/export procedure?
What happens if someone accesses a "product" during the import? Will the (now invalid) reference clear its own content (become a null value).
What happens if the schema of the "product type" list changes (new column)? Will this cause any troubles?
Thanks for all feedback and suggestions!
Update 1
The imported "product type" items have the same IDs as previously deleted ones.
Update 2
Started a bounty to get some more feedback/opinions.

We have had this exact same scenario before. This is a little tricky, depending upon how you will approach it.
1) Delete and Recreate Product Type list through UI
If you delete and recreate the lookup List(Product Type in your case) through UI, then you will lose the connections because the List's id GUID will change upon recreation. So do not go that route.
2) Delete and Recreate Product Type through a Feature
If you had created the Product Type list through a feature.xml file using the <ListInstance> element, then if you delete that list and then recreate it using the same feature (basically Id attribute of ListInstance remains the same, number of list items, i.e. the number of <Row> elements, may change), the association would be maintained. So if you were adding 5 more product types, then if you had created the list using a feature, you could just delete the list and provision the new one using the same feature with extra info for new items and everything would just work!
As a side note, this is the better approach because if you have to do the upgrade on a lot of servers, then rather than doing list export import via stsadm, feature deactivation and activation is a much more recommended solution. This is how we did it.
3)Deleting all list items from Product Type and adding new ones (list is never deleted)
If you are linking the lookup field (in Product List) to the ID field of the lookup list(Product Type), you have to remember that ID is auto-incrementing, so if you delete all items and then add new ones, then their ID's would be different. Say you had 5 items with ID's (ID field is not shown in UI while editing in Datasheet view) 1-5 in the list. If you delete them and add new items, their ID's would start from 6 and not 1 again. So if your lookup field had link to the item with ID 1 in it, then this method is not going to work because there is no item with ID 1 in the Product Type list anymore. So you might want to really try this out before going to production with this method.
4) Editing the list in place
If the list is not extraordinarily huge, and you only have to make this change to one or two instances, could you not just edit the list directly in the datasheet view on the prod server? When editing in datasheet view, do not delete the item, but just overwrite the values of its columns. And you can add more items if you want. This will make sure your ID's are valid.
I have mostly talked about adding new items to the list. Now if you were deleting existing items, then your lookup fields will be affected because assuming you linked the field by ID, the ID is not present anymore since the item has been deleted. Basically, any method you use, maintaining your ID's is critical.
Now regarding your doubts/questions:
I am not too sure about stsadm export import for a list (never done it myself), but stsadm can be tricky as some operations will work on certain scopes only. So you better try out your exact scenario on a dev env.
What happens during an import is tricky again depending on the exact timing. I am sure SP has its own concurrency mechanisms, but you cannot have a definitive answer as it might probably be different based on the stage of the import. If possible, recommended approach is to do the import during a planned downtime.
Regarding changing schema of the list, a change in the schema of a list will not affect the existing list instances (for the most part). If you do this through UI, I believe SP makes changes to the content DB directly. I am not certain how you intend to do this, but if you were to add a column to an existing list using a feature, the way to do this is during feature activation by adding a new content type to the list and adding your new column to this content type. This way you add the column but do not affect the existing list items.
Good luck...

There are two components to a particular lookup: the field, and the field value. The field value only contains the ID of the item(s) it refers to, and the display field. This information is meaningless without the field, which specifies what list to look at and what field to use as the display field.
The primary reason that a Lookup will break occurs on the field scope: either the list it referred to no longer exists, or the list does not contain the required field. These would generally happen if you deleted and recreated the list, but you aren't doing that. If you do break a lookup's list reference, then the only thing you can do is re-create the lookup, because you cannot configure the list reference for a lookup field once it is created.
The downside of your import/export procedure is that you lose the validity of all currently existing lookup values. A lookup maintains its integrity based on the ID of the item it references. So when the display field changes, it still refers to the same item. If you delete the item, then the lookup no longer references it, even if you create a new item that has the same value for the display field. So you would have to reassign all of the products to the new product types.
It should be noted that if you were to revert the deletion of that item, it would return to being on the lookup! The reference to that ID is kept until the actual lookup value is updated (such as by editing the Product).
All of your now invalid references will be null for purposes of interaction. You won't see anything on display forms, and you won't have the options when you try to update the product. When you do update the product, you update it to what you just set it to, which since you can't set the non-existent IDs, means that there are no more references to those IDs.
Any changes to the Product Type list's schema that do not affect the display field specified for the lookup will not have any effect on the lookup integrity. If you do change the display field in any fashion, and of course if you delete it, then it will break in the same fashion as with the list reference. However, you can set the display field, both in the UI and in the object model, so it is easy to fix this.

Resources