I need certain custom entity fields to calculate and display values based on operations on the data in the system.
For example an a booking system implementation with contacts and custom entity: tickets. There is a one-many relationship between contact and tickets.I would like to create a field that calculates and displays in the contact form:
frequent flyers: more than 10 tickets bought.
a field that displays yes or no based on whether a first class ticket has ever been purchased. Ticket ref would start with say, FCxxx
If this isn't possible perhaps someone could suggest an alt method for displaying this info?
This is possible and you have some ways to do that: Workflow or Plug-in.
If you make a lot of calculations i think the best way is doing a plug-in. You can register in post create event of tickets entity and there you can make all this calculations and update the custom fields of contact entity.
You can check some tutorials about developing a plug-in:
http://mscrmshop.blogspot.pt/2010/10/crm-2011-plugin-tutorial.html
http://msdn.microsoft.com/en-us/library/gg695782.aspx
http://crmconsultancy.wordpress.com/2010/10/25/plugins-in-crm-2011/
Specific information about registering a plug-in:
http://msdn.microsoft.com/en-us/library/hh237515.aspx
In SDK you can find more examples.
As far I'm aware, it's not possible to achieve without coding. So, if you're looking for a way to customize it by mousing, you might be just out of luck.
If you wish to display that information upon retrieval of the a customer, it's probably fastest to get it using JavaScript. You can add a custom script to onload event. However, that means that you'll have to write JavaScript so if you're not into coding you'll have problems.
If you do know how to code, perhaps creating a plugin with C# is the most preferred way (that's what I'd do at least). The advantage of that lies in extensibility, should you realize that you wish to perform more operations.
Also, if you wish to store the computed values, you'll have to go with a plugin. Otherwise, only GUI operations will perform the computations. If a program will enter/retrieve data in the background, you can't rely that the values will be computed, unless you listen to the messages of Retrieve, Create etc.
Related
I understand that Acumatica treats Customers and Vendors differently, and if you require a customer to also be a Vendor (which is often the case for us) and vice a versa, then you have convert the the Customer to a Vendor (or Vendor to a Customer). We often use the convert to vendor code on git (https://github.com/Acumatica/Acumatica-ExtendToCustomerVendorDuringImport). But my question is, is there any harm or reason not to just convert all vendors to customers and vice a versa to save our users the headache of doing this for each one later on?
There's a general answer to those types of questions. If the operation can be done in the UI by a user then it's assumed there's no harm in doing so. When an operation can't be done in UI due to a validation error it's assumed that making that change would corrupt the data.
Once the operation is confirmed to be working in the UI you can work on an automation script. These can be done with a Customization Plugin that runs when the customization project is published.
You should always do the operation using the PXGraph classes of Acumatica. For example, if you need to confirm shipments in a script you create the SOShipmentEntry graph, set the current document of the graph and invoke the confirm shipment action.
Regarding the GitHub project, I don't think it's officially maintained so you'll need to test it. One possible issue you might encounter with conversion is that you can't re-convert the vendor back to a customer once he has started making sales transactions.
I have 2 custom entities ex: Building and Business in CRM on-premise. Building has multiple Units/Suite #'s and each Unit/Suite# is occupied by a Business. If a Building Unit/Suite is under renovation, then the Business has to be temporarily closed.
How can i automatically update Business Open/Close when Building Unit/Suite status changes? The update does not need to happen instantly. I need search around 20000 records to update the correct Business entity. Also there are fields in Business like start and end date which is retrieved from Building and Closure duration is updated with end(minus)start date.
Is Plugins the only way and how can i achieve it using plugins! How difficult would it be, impact on server and i am mid level C# dev. Please provide any links in the right direction. The env is 2011 on-prem
Thank you very much !!!
A straightforward solution can be built with a plugin. A synchronous plugin can update the status changes to the Business entity immediately and (in the PreOperation or PostOperation stage of the Update message) even within the same database transaction.
Generally speaking, with plugins you can build the most efficient and seamlessly integrated business logic possible.
However, often you can actually achieve pretty much the same using a workflow. Some advantages of building workflows:
Does not require a skilled software developer to build;
Workflows can be modified ('configured') quickly.
Execution of workflows can be postponed (e.g. until a condition is met or a date has passed).
Some downsides of workflows are:
In CRM 2011 your code always runs asynchronously, outside of the original database transaction;
Some time may pass until the action takes place; the user does not get immediate feedback;
Querying and selecting related data is limited to n:1 relationships (from the n-side to the 1-side, not vice versa);
Execution of workflows requires more resources than plugins;
Extensive use of workflows can easily lead to spaghetti systems that are really hard to maintain and perform bad.
In your scenario it looks like the requirements for selecting the appropriate Business record are too complex to handle in a workflow. In a workflow you basically can only navigate from one record to the other by following lookup references on the record at hand. This means you can only get from one record to the other when there is a n:1 relationship and when you navigate from the n-side to the 1-side.
In plugins you do not have this limitation; there you can write a QueryExpression or Linq-query to get the records you need. So, in your case a plugin seems to be the right choice to me.
I have a requirement to add fields onto a form based on data from another set of entities. Is this possible using an event script or does it require a plugin?
Given that I understand your assignment correctly, it can be done using JavaScript as well as a plugin. There is a significant difference that you need to take into consideration.
Is the change to the other entities to be made only when an actual user loads a form? If so, JS is the right way.
Or perhaps you need to ensure that those values are written even if a console client or system process retrieves the value of the primary entity? In that case, C# is your only option.
EDIT:
Simply accessing the values from any entity in the onload event can be done using a call to oData. I believe someone else asked a similar question recently. The basic format will look like this.
http://Server:Port/Organization
/XrmServices/2011/OrganizationData.svc
/TheEntityLogicalNameOfYoursSet()?$filter=FieldName eq 'ValueOfIt'
Some extra remarks.
If you're targeting on-line installation, the syntax will differ, of course, because the Schema-Server-Port-Organization are provided in a different pattern (https, orgName.crm4.something.something.com etc.). You can look it up on Settings.
Perhaps it should go without saying and I'm sure you realize it but for completeness' sake, TheEntityLogicalNameOfYours needs to be substituted for the actual name (unless that is your actual name, in which case I'll be worried, haha).
If you're new to this whole oData thingy, keep asking. I got the impression that the info I'm giving you is appreciated but not really producing "aha!" experience for you. You might want to ask separate questions, though. Some examples right off the top of my head.
a. "How do I perform oData call in JavaScript?"
b. "How do I access the fetched data?"
c. "How do I add/remove/hide a field programmatically on a form?"
d. "How do I combine data from...?"
I am trying to create a N:1 relationship off another entity to Order Product. It is not an option in the pick list. I then tried to go to Order Product and create a 1:N relationship and it also does not allow it.
I am sure this is by design from Microsoft, but is there a way to achive this? I perfer not to to a 1:N or N:N as a work around since it will create grids on the form (and that does not make much sense from a UI perspective when there will only be one record).
Thank for the help!!!!
I am going to add a single line of text field and format it as a url. Then link it to the related entity by dynamically populating a URL to the entity. It is a work around but of all the possible scenarios its the best for my situation
We faced the same problem during building a solution for a client. It was a heavy restriction so in the end we just created our own order product entity and linked it via a one to many to order.
This gave us complete control over it and could add relationships as we wish.
This came at a cost unfortunately as you lose the auto calculation on order for example. This wasn't an issue however as we didn't need it or any of the price list functionality.
If this is an option for you I'd recommend doing it this way.
I think that everybody had to face the same problem in his CRM life.
For CRM, the entities, salesorderproduct... are entities used only to enumerate the products of the entity related in its name, and you can not do almost nothing, that's another problem with a workaround, that I'll try to explain, just to see if this could be the solution to creating relations with them, but I don't think so.
The problem is that you can not use the assign functionality as in other relations to copy data from one entityproduct to the lower-level entityproduct when you create custom fields, and you want to copy throught the entire workflow of sales section. In this case, there is no option to enter the "Assign" window (I use Assign because I have always worked in Spanish) and create the field mappings between them.
This could be done by searching the GUID of the "Assign" window, and copyign into any of the URLs of the "Assign" window, the window showed up, and you could do your custom mappings.
I hope this could help, although this question is too old, so I hope other that arrive here, could see more opinions :)
See you
One of the basic tenets of CQRS, as I understand it, is that commands should be behaviour-centric, and have a value in the business or the UL, and not data-centric, ie., CRUD. Instead of focusing on updating a customer, we have commands like CustomerHasMoved. What if you have CRUD screens which are there to correct certain data. For example, we need to change the name of a customer which is misspelled. This doesn't really have much value in the business. Should this just be under the umbrella of an UpdateCustomer command?
I just want to put a comment on this quickly as it popped up.
It is important to note that some objects are actually CRUD and thats ok. I may not really care why a name is changing in my domain where I ship products to people and only need that data to print mailing labels. The trick is in making behavior the default and THEN reverting to a CRUD interface once you are sure you really don't care about the reasons as opposed to vice versa.
Greg
Actually, there could be various reasons to update the name of a customer. As you were saying, it could be misspelled or... you could get married and change your name to your husband's.
If you had only an UpdateCustomer command, you would loose the original intent and you would not be able to have different behaviours for each of them. If the name was misselled it could be as simple as updating the database, whereas if your customer got married you might need to notify the marketing departement so tthat they can offer a discount.
In the case that your entity is purely CRUD, that is there is no intent that you can associate with modifying the properties, then it's OK to have an UpdateEntityCommand. You can then transition slowly to something more task based
CustomerHasMoved is the event that is fired after you have updated the customers location. This event updates the read databases/cache databases. The command from the gui should be MoveCustomer or something like that. I think I would put the update of the customer name in a command like UpdateCustomer.