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
Related
I'm creating a contract API solution to keep items in sync between multiple tenants. Is there any way to track the changes to InventoryCD? In this case one Franchiser would like to update items in their 6 franchisees. It's easy for me to find the records that changed, but harder to know when the CD has changed (importantly what it chagned FROM). Certainly I could write customization to do it, but I thought maybe Acumatica has some option inbuilt.
Ideally I'd like to have a log of the changes with old and new CD. It's hosted so I don't think I can make it happen with DB Triggers (which is how pre-Acumatica me would have handled id)
Thanks in advance.
It depends on the Acumatica version. But have you tried looking at Business Events? I believe there is the ability to access the old and previous values.
Also look at Acumatica's Audit history capabilities but be careful to only turn on the fields you need to track as the DB can grow very large if you turn on all fields on the Stock Item screen or for any screen.
I've resolved this problem in a complicated way and now I'd be delighted to see if there's a simpler solution.
Suppose that we have two custom entities, Alpha and Beta, each of which has a custom field called reference. If I place two lookups on a form, one for each of the custom entities, all's dandy as long as I don't require the lookup processes to depend on each other.
Now, what if I pick Alpha instance (call it a) first and then only want to see those Beta instances in the search box that share their owner with the selected a? That's easy, right? You just customize the filtration of the field.
But what if I want the selection of Beta instance to be predicated on the custom reference field?
Do I really have to declare a dynamical view to cheat myself around this part? It's so inconvenient and cumbersome...
You've done it the only way I was aware it could be done.
We can only hope it might be different in CRM 2013 i guess.
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.
I'm creating a Book store in Magento and am having trouble figuring out the best way to handle the Authors of a Book (which would be the product).
What I currently have is an Attribute called "authors" which is multi-select and a thousand [test] values. It's still manageable but does get a little slow when editing a product. Also, when adding an option/value to the authors attribute itself, a huge list is rendered in the HTML making this an inefficient solution.
Is there another approach I should take?
Is it possible to create an Author object (entity type?) which is associated to a product through a join table? If yes, can someone give me an explanation about how that is done or point me to some good documentation?
If I'd take the Author object approach, could that still be used in the layered navigation?
How would I show the list of all books for a single author?
Thanks in advance!
PS: I am aware of extensions like Improved Navigation but AFAIK it adds something like attributes to attributes themselves which is not what I'm looking for.
For Googlers: The same would apply for Artists of a music site or manufacturers.
If you create an author entity type, you'll just increase your work trying to add it to layered navigation, and I don't see a reason why it would be faster.
Your approach seems the best fit to the problem, given the way Magento is set up. How are you going to display 1,000 (which presumably pales in comparison to the actual list) authors in layered navigation?
Depending on the requirements, you could go the route of denormalizing the field and accepting text for it. That would still allow you to display it, search based on it, etc, but would eliminate the need to render every possible artist to manipulate the list. You could add a little code around selecting the proper artist (basically add an AJAX autocomplete to the backend field) to minimize typos as well.
Alternatively, you could write a simple utility to add a new artist to the system without some of the overhead of Magento's loading the list. To be honest, though, it seems that the lag that this has the potential to create on the frontend will probably outweigh the backend trouble.
Hope that helps!
Thanks,
Joe
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.