Ax 2012 R3. I’ve created a new table to hold group data (let’s call it AgencyTable); I’ve created a RefRecId that references AgencyTable and extends RefRecId (lets call it AgencyTableRefRecId).
I’ve created another new table called RatingsTable, to which I’ve added the AgencyTableRefRecId. The RatingsTable has a relation to the AgencyTable on the AgencyTableRefRecId (Cardinality = OneMore; RelatedTableCardinality = ExactlyOne; RelationshipType = Association).
I’ve also added a reference in RatingsTable to the BankAccountTable and created a relation on the BankAccountId.
I have an AgencyTable record. When I create a record in the RatingsTable, and click the field that references the AgencyTable, I get a dropdown and can see the AgencyTable record, but when I select the record I get error: “The value is not within the range. Acceptable values are in the range -9223372036854775808 - 9223372036854775808” (the max and min of int64).
This is such a simple relation and common way of relating data. I’ve checked my edt; I’ve checked the relation and can’t find what is causing the problem. (The relation to BankAccount works fine).
The datadictionary has been sync’ed. The AOS was recently restarted.
What is causing the issue?
It is important the relation to AgencyTable is created as as ForeignKey relation to the primary key.
If the relation to extended data type is created correctly you will be prompted to create the relation when you drag and drop it to the RatingsTable field node.
If you answer Yes, it will be created correctly.
Also the form control should be of type "Reference group" to work as expected, this is not the case if you use the table browser.
Related
Dears,
I'm using Microsoft Dynamics AX2012 R3
The Case: I want to make a custom lookup in Inventory Management ==> Journals ==> Item Transactions ==> Movement ==> Lines
I want to relate the Item Id to show all lines in the SalesLines Table in order to get the ItemId and It's dimensions (Config/Size/Color/Style) and when I select it I want to move the selection to the movement line.
My Solution:
Step1: I've made a custom view (viewCustomItemId) that shows all SalesLines tables and related to InventDim to show the dimensions.
Step2: I've made a custom form (frmCustomItemId) and added the view (viewCustomItemId) as a datasource and added all fields to a grid
Step3: In the form (InventJournalMovement) I've overrided the lookup method and added below code
Args args = new Args();
viewCustomItemId _viewCustomItemId;
args.name(formstr(frmCustomItemId));
args.caller(element);
newPopup = classFactory.formRunClass(args);
this.performFormLookup(newPopup);
newPopup.init();
newPopup.wait();
if (newPopup.closedOk())
{
_viewCustomItemId = newPopup.docCursor();
InventJournalTrans.ItemId = _viewCustomItemId.ItemId;
InventDim.configId = _viewCustomItemId.configId;
InventDim.InventSizeId = _viewCustomItemId.InventSizeId;
InventDim.InventColorId = _viewCustomItemId.InventColorId;
InventDim.InventStyleId = _viewCustomItemId.InventStyleId;
InventJournalTrans_DS.research();
}
Problem: When the lookup form is closed all fields are set to the movement line but I get warning message (Field 'Item number' must be filled in.) and the line number in the database are set to be minus for this line and also the default site and warehouse for this Item is not automatically set.
Question: Looks like I've retrieved the values but didn't pass it correctly to the lookup of the field, I don't understand what exactly I missed to make it work normally.
Thanks in advance.
I'm surprised I missed this at first glance.
This line is your problem:
InventJournalTrans_DS.research();
You're researching before you've updated/written the data. I'm not sure why you're researching in the first place, but you have to do one or the other. Write/Update, then research or don't research. The research is where you're losing the ItemId you've input.
In FSCM I am looking to modify the Search view on Add/Update PO page (Main Menu--> Purchasing--> Purchase Orders--> Add/Update POs) to display the Requisition ID associated with the PO in the search results page. The only table I have found that has both PO_ID and REQ_ID is PS_PO_LINE_DISTRIB however unless I use a SELECT DISTINCT clause I will get multiple PO_ID rows when there are more than 1 line on a PO.
Within Purchase Order Inquiry you can see the related Requisition ID's related to a PO by clicking on Document Status link inside the Purchase Order inquiry details page.
I started looking at the PeopleCode within the the Purchase Order Inquiry to see how they are linking the PO to a Requisition and it appears to use work tables with related PeopleCode function libraries, but I wasn't able to figure our how they get linked. I am hoping someone else may know the answer to this. Thank you.
I'm on an old version of PeopleSoft (SCM 8.80, Tools 8.51), so your mileage may vary. I'm assuming you're familiar with App Designer. If not, comment below and I'll add some details about what I'm clicking on.
Find the name of the Add/Update PO component.
Open the PURCHASE_ORDER component in App Designer. Now let's find the name of the search record. Note that there is a different record for the Add Search Record, so if you want to change that too, do all of this for that record as well.
Open the PO_SRCH record, and add the REQ_ID field to it. Make sure you mark the field as a key. You should consider saving your modified PO_SRCH under a new name in case you want to be able to revert to vanilla PeopleSoft. If you do, change the Search Record in the component to your new record name.
We can see that PO_SRCH is a view. So let's modify the view to pull in REQ_ID from PO_LINE_DISTRIB. As you mentioned above, there doesn't appear to be another table with both PO_ID and REQ_ID, so you'll have to do a SELECT DISTINCT.
We should do a LEFT OUTER JOIN instead of a standard join because if you do a standard join and you enter a purchase order with no lines and save it, then you'll never be able to retrieve that purchase order in this window. Since REQ_ID is a key field, we can't have a null, so we have to do the CASE.
One odd thing that I ran into here was building the view now gave me an error about selecting fewer columns in the SQL than I had in my record definition. I solved it by modifying the view for SQL Server. I've never had to do that before and I don't know why I had to do it for this specific record. But anyway, I entered the same SQL under the record's "Microsoft SQL Server" definition.
In the properties of PO_SRCH, we can see that it has a related language record. If you're only using one language, you can probably get away without changing this, but I'll do it for completeness. Open PO_SRCHLN. Now add REQ_ID to it (mark it as a key field like you did above), and save it as PO_SRCHLN2 (I'm saving it under a new name so I don't break anything else that may be using PO_SRCHLN).
Edit the SQL the same was as you did above. Note: I didn't have to also change the Microsoft SQL Server definition like I did above. I have no idea why.
Now build PO_SRCHLN2.
Go back to PO_SRCH and change its related language record to PO_SRCHLN2.
Now build PO_SRCH.
Hopefully you didn't get any errors and your search page has the requisition ID in it now. My system doesn't use requisitions so they're all blank in the example below, but the new field is there.
I have added a new field into the IN_VND_ITM_XLS component interface, (BU_PRICE_STATUS), which is in a SQL View already part of the delivered template, ITM_VND_UMP_CVW. I modified the view (Record definition) in App Designer to pull in the BU_PRICE_STATUS field and then modified the component interface and added this field.
When I regenerate the template in Excel, it populates the additional field fine, I select it as an input cell (along with the others I originally had) and I submit the data and return back the green OK status.
When I look online in PeopleSoft I see that the vendor data was created for the item, however the BU_PRICE_STATUS field is populated with a different value than what I specified on the upload. The default value listed on the field definition in app designer was what was populated, instead of the value I had entered for the upload.
Is there something else I did to modify for this to work? I know that when you run the Item Loader process, it uses a Message definition (IN_MST_ITM_XLS) so I wasn't sure if the message needed to be updated to? Thanks in advance.
2/27 EDIT:
I've found that the Component (for this component interface) - IN_MST_ITM_XLS uses a function called PRCSITEM within a Function library record - FUNCLIB_INEIP and this populates data in a staging table called PS_ITM_VND_UMPR_EC. I see that this table does not contain the field BU_PRICE_STATUS (which I didn't believe it would) so I'm thinking if the code/table can be updated to capture this field it would work. Hoping someone can suggest if I'm in the right area and what would need to be changed.
I am (still) working with Vaadin 7.6.4 and im trying to write my own custom FieldGroup.CommitHandler
I am trying to retrieve the currently added item (grid row) from the the commitEvent itself.
While debugging I can see that all the Data is available in a property called itemId if I use the following trainwreck: commitEvent.getFieldBinder().getItemDataSource() inside the Debug-Inspector, however it is private.
The itemId is the exact bean-entity i want to access. I only managed to access single fields of the entity with the following trainwreck: commitEvent.getFieldBinder().getField(propertyId).getValue(). However this is cumbersome and does not give me the entity as a whole (and to be precise does not retrieve the information from the entity, but rather from the displaying elements of the grid).
Is there a way to access the currently edited entity (which is the datasource for the edited grid row), without declaring the entire grid as a global field and call the grid.getSelected()-method?
Also, is there a data-wise difference between post- and preCommit?
Since you are apparently using BeanItemContainer based on your comment of itemId, You could try something like the following:
BeanItem item = (BeanItem) commitEvent.getFieldBinder().getItemDataSource();
MyBean bean = (MyBean) item.getBean();
getBean() in this case returns itemId.
When opening the query SalesTableListPage from the AOT, you can choose the field MatchingAgreement (shown as "Agreement Header record ID (Record-ID)") in the field lookup. The same is not possible for query SalesUpdate, field MatchingAgreement and several others (which seem to be related to relation fields where the relation is built with a RecId) are not shown in the lookup.
After some research I found out that the reason seems to be the FetchMode property on the joined SalesLine data source. If it is 1:n, the fields are not shown in the lookup. If it is 1:1, the fields are shown in the lookup.
I have not tested this with other tables, but I suspect the same behavior. I also have only tested this with AX 2012 R2 and R3, but I suspect the same behavior in other 2012 versions.
Why does the FetchMode of a joined data source remove some fields from the parent data source in the query dialog?
TL;DR Field lookups in the query dialog do not always work for relation fields that define relations to tables where the AutoIdentification field group's property AutoPopulate is set to No. One case where they not work is when a data source is joined with FetchMode 1:n.
While Alex K's answer has some interesting suggestions, in my case the culprit is the AutoPopulate property on the AutoIdentification field group of table AgreementHeader. In sys layer, this property is set to No and the group contains the fields that are shown in the query dialog field lookup if the relation in the query is 1:1. If this property is switched is to Yes the lookup will show field Agreement header record ID (Record-ID) (and only this field, no matter how the FetchMode of the query relation is defined).
Basically, AX will use the information from the AutoIdentification field group to determine the information shown in the gui in case of surrogate key references/relations. If the AutoPopulate property of the field group is Yes, AX will use the alternate key of the table to determine the fields to use. If no alternate key exists (which is the case for table AgreementHeader), AX uses the relation field. If AutoPopulate is No, the fields defined in the group are used. But as described this option does not work if the relation in the query is not 1:1 (and unfortunately no fallback option like using the relation field seem to have been implemented).
FetchMode AutoPopulate Lookup
1:1 Yes AlternateKey (or Relation) fields
1:1 No AutoIdentification fields
1:n Yes AlternateKey (or Relation) fields
1:n No Nothing
Update:
I came upon this problem again, but with field SalesTaker this time. Turns out that the AutoPopulate property is only part of the story, because it did not solve the problem when set to Yes on table HcmWorker. This table (unlike table AgreementHeader) also has the property ReplacementKey set, which AX uses to populate the AutoIdentification field group. Only after I removed the ReplacementKey no fields appeared anymore in AutoIdentification and the lookup now showed "Sales taker (Record ID)". So bottom line is that the AutoIdentification field group must not contain any fields.
If the dynamic property of both query fields is set to yes, then I'd suspect it has something to do with the properties of one of these relations:
\Data Dictionary\Tables\SalesTable\Relations\Agreement
\Data Dictionary\Tables\SalesLine\Relations\SalesTable
Maybe try adjusting those, refreshing your cache (AOT changes to be picked up), clearing usage data (packed queries can cause problems), and updating XRef (Advanced querying uses XRef, so may not be necessary for standard query functionality)