I am extending the default price level selection in a Dynamics 365 Sales implementation. For that I need to register a custom plugin to the sdk message GetDefaultPriceLevel. This message gets executed everytime an Order, Quote or Opportunity is created so the custom code returns the default price level. I created the plugin and I registed the plugin to the correct message and it is being properly executed. The issue is that as part of the plugin context I don't receive the entity id. I need the entity id to retrieve the account (customer) and subsequently the price level tied to that account so the opportunity price level gets assigned with that value. Is there a way to pass this value?
Related
I have work order product entity which have product, status and quantity field in MS CRM online. When user tries to create a new record of work order product entity, quantity of existing work order product record with same product should be increased instead of creating new work order product record (without letting user know). Can anyone explain how to achieve this requirement ? This should work for creating record by form or by data import/export.
You must write a plugin in the creation event (post operation) of the order product. In this plugin you need to check if you have another ordering product with the same product.
If so, you must increase the quantity of your existing product order and delete the new one.
If you want to have a good user experience, you can send an alert to your user to inform them of this logic when creating a new order product with the same product as that of an old one.
I am looking into event sourcing and I have a few thoughts that I need to get my head round.
Take for example an online shop -
The customer adds an item to the basket and saves their order.
The command handler could create an order on the customer aggregate root and add an OrderCreated event which contained the customer id, order id, item id, quantity and unit price. All pretty straight forward but what if the aggregate needed to check to see if that item was on special offer?
If this was for example a basket service would it subscribe to events from the catalog service and store it's own projections of the catalog service which it could then use, so then the basket service would comprise an event store and also some form of projection of the catalog service?
Or if in the example I've just described, if the basket and catalog functionality were part of the same application and they only held event data, then when a customer creates an order the handler would pull all ordered items from the event store via a repository, apply all events to them and then return them to the handler in order to check if the item was on special offer.
what if the aggregate needed to check to see if that item was on special offer?
It needs to execute a query to get the information it needs.
From the aggregate point of view those data are external, so it (or the handler sending the command to it) needs a query to access that information.
How the query work is up to you (there are pros and cons for each way), the query handler can:
Call a repository that loads an aggregate and check for the special offer (you can also think to have event sourcing in just one part of your system and having this part using another way to store dara, or not)
Make a remote call to the Catalog Service API to check for the special offer
Do a query to a local db, that is populated reading events emitted by the catalog service and stored "locally" to the basket service
I have a business requirement that execs are really wanting to see. In our lead and email templates we have a few of our products listed. The products themselves are pretty stable but the prices are of course subject to change.
I'm OK with hard coding the product name into email but I was hoping the price could be a slug that get's resolved.
We only have one price list so nothing to worry about there.
I see no way to get access to the product and or price list entities through the data field values dialog.
So my thought was to create the 2-4 fields in the lead and opportunity entities. Then create a background workflow that takes the price from the price list and sets those fields.
Then when an email is generated I can access those hidden fields as they will be available through the lead or opportunity entity.
Any thoughts, concerns, better approaches?
Unfortunately CRM's email template system is not capable of what you describe out of the box. As you have discovered it will only permit you to insert placeholders from, or assocated with, the primary entity. It won't let you insert fields from other entities. What you suggest as a workaround is possible but it's not an ideal solution as you'll have these 2-4 redundant fields on each record type that contain duplicated data from the price list.
If you have any experience with creating custom workflow activities using the SDK then the best solution here is to create a custom activity that accepts either an draft Email or Email template as a input parameter, instantiates the email if required, loads the price list data, and performs your own custom placeholder replacements.
I've done this on a few projects in order to pass multiple entity records into the template, or to insert complex tables into emails by loading data from relationships. See the screenshots below for an example of how I've configured the email template and dialog process to pass both an 'Account' and 'User' record into the email template.
I have a workflow that will fire once a form field changes. The workflow checks the value and then sends an email if one particular value is selected. That much I've managed to figure out.
Now I need to pull a field value from a separate entity to populate the "to" field of the email. We have a Configuration entity that stores the value of a distribution list - we want to pull this into the email that the workflow generates.
I've created an N<>1 relationship between the primary entity and the Configuration entity, however I only see the Entity and not the entity's Fields in the email form assistant. Any idea how I can pull that data onto the email form?
If you see the entity populated under "Look for" and then in the drop down under that you see no values? I'm guessing in your configuration entity your email address you want to use for the email recipient is a text field. In order for the form assistant to populate the second drop down, the field types must match up - or in this case for a field to show up as useable for the "To" field, it needs to be an Account, Contact, User, etc... values you can send an email to.
My suggestion is create a Contact record that has the proper email address and either relate that to your base entity in place of your configuration entity (if possible) or relate your configuration entity to Contact and populate the new lookup on the configuration entity accordingly.
I've never set a store up to use Price Alerts before, and now that I've gone through and gotten it to work, it appears as though the alert is only triggered when a product's 'Price' attribute changes.
This is nice, but what about tiered pricing? Looking through the ProductAlert core module, I am not sure where this attribute is being filtered.
I'm guessing that an additional model, say 'productalert/tierprice' will need to be created, followed by a new method in Observer.php, likely _processTierprice(). Just not sure if this concept is correct... could use a little guidance.
Thanks!
This shouldn't be too difficult; lots of options (it's Magento, after all)!
I'd add new methods to deal with tier price alerts. For products with tier pricing, you'd need to capture the relevant tier data along with the final price (either in a new table or in new columns on the existing product alert table). The alerts are sent out via scheduled job. So, in a nutshell (overrides where necessary):
Alter the product alert schema as necessary, and amend the frontend form fields to suit
In the overridden Mage_ProductAlert_AddController add a tierPriceAction() method to process the alert subscription, or adjust its existing priceAction() to handle the data being posted in / tier condition
Override Mage_ProductAlert_Model_Observer as needed; I'd include a _processesTierPrice method() similar to _processPrice().
Add a resource model method to get the tier-related prices
Add a tier price email block and template (reference Mage_ProductAlert_Block_Email_Abstract)
Profit!
As a reference for your price logic, see Mage_Catalog_Model_Product_Type_Price.