Get company Address using x++

 

Get company Address using x++

For this write the two lines of code as shown in the below figure.

When you execute the class, you will get the company address of the logged company on the screen as shown in the figure.

 

Enjoy 😊

Why we use ttsbegin() & ttscommit() using x++ in d365fo

 Why we use ttsbegin() & ttscommit() using x++ in d365fo

If someone is trying to deleting the same record from the Table at the same point of time, and we also doing some operation on the particular record. 

So, two operations will not do on the same point on same record that is really Deadlocking Process.

So, once the transaction has begin if any other user trying to deleting that record, that operation will be in pending mode in Queue.

Once the operation is committed with ttsbegin() and ttscommit() , the only system will allow the next operation to the next user.

So, at a time two operation will not perform on same record, so that is the reason we are locking the record temporarily. Once the operation has done, system will release the record for further operation. It is the reason always we need to write ttsbegin() & ttscommit().

For update and delete method we need to write ttsbegin() & ttscommit(). But for insertion process we don't need to write.

Enjoy 😊

Form Opening in D365 fo

Data Flow of  Form are Opening in D365 FO

 What the means of super() using x++ in d365fo

It is the core functionality will call the Kernel Level method of the current (update)method.

For ex: 

Public void update()

{

super();

}

Once the super has called, 

• The actual functionality will execute.
• Execute the core process of current methods.
• It is constructor (call main functionality of method).

If we have written something below the super, then after updating the record our code will execute.

If we have written something above the super, then before updating the record our code will execute.

                  Table Methods in D365 FO

Whenever records are changed ,  inserted or deleted from a table , various default method are executed .

Create A table (CustomerTable ) with some fields :

• CustId
• CustomerName
• Description
• FromDate
• ToDate
• Qty
• Status 
• UnitPrice
• TotalAmount

1.    initvalue() : * If we create a new record from the table browser or a form , the table method initvalue()                         is   executed.

                    *  It is also used to set a default value for fields.

Example: 

 let's override initvalue for CustomerTable(tablename) and set default value for CustId(fieldname)

                public void initvalue()

            {

                super();

                this.CustId = "10";

            }

after adding this method , open table CustomerTable through Open table Browser and press Ctrl+N to create new record, field CustId  will have default value 10.

   2. modifiedField() : value of field is changed.

Example :  override modifiedField method for CustomerTable (tablename) and target to set Description  to null when CustId is modified 

            public void modifiedField(fieldId _fieldId)

            {

                    switch(_fieldId)

                {        

                    case fieldnum(CustomerTable, CustId):

                               this.Description = "";

                                break;

                            super(_fieldId);

                    }

                }

 modifiedField() receives field number of active field (as parameter) , switch statement is used to check which field is active.

if none of checked field are active super() calls is executed instead.

3. validateField():   * used for validation only and will return true and false.

Example :

 let's override for CustomerTable to verify the condition that CustomerName must be more than 3 characters.

 public boolean validateField (fieldId  _fieldIdToCheck)

{

boolean ret;

ret = super(_fieldIdToCheck);

if(ret)

  {

    switch(_fieldIdToCheck)

      {

      case fieldNum(CustomerTable, CustomerName):

            if(strlen(this.CustomerName)<=3)

            {

                ret = checkfailed("Customer Name should be more than 3 character");

             }

        }

       return ret;

    }

If we try to enter less than 3 character of CustomerName Field , AX will throw warning message.

4. validatewrite() :

 when a record is written to db, before the date change is committed in db.

Example :  

The ToDate always be larger than StartDate.

   public boolean validatewrite()

{

    boolean ret;

    ret = super;

    if (this.ToDate < this.FromDate)

        {

           ret = ret && checkfailed("ToDate should be greater")   ;

          }

        return ret;

 }

   

5. validateDelete():

       executed when record is deleted.

Example: 

 public boolean validateDelete()

{

    boolean ret;

     ret = super();

    info(this.Description);

    return ret;

}

6. find() :

All tables should have atleast one find method that select and return one record from table.

It uses select statement to retreive the data ,  but it requires parameter to search , if that exist  , it will be search otherwise , it skips.

It accepts one more parameter i.e. boolean update which is false by default , if true , record should be select for update.

Example :

 

static CustomerTable find(CustId _custId , boolean update = false)

{

    CustomerTable CustomerTable;

    CustomerTable.Selectforupdate(update);

            if(CustId)

                {

            select firstonly CustomerTable

            index hint PrimaryIdx

            where CustomerTable.CustId == CustId;

                }

            return CustomerTable;

}

7. Exists() 

As with find method , there should also exists method, 

same as find method , except that it just returns true if a record with unique index specified by input parameter is found.

Example :  

static boolean exist(CustId CustId)

{

  return CustId && (select RecId from CustomerTable index hint PrimaryIdx 

where CustomerTable.CustId == CustId).RecId ! = 0;

}

Enjoy 😊

  

Relation in Table

    Table Relations Normal Related Field Fixed Field Fixed

In D365 FO

Table Relations (Normal, Related Field Fixed , Field Fixed)

 

Normal Relation: where the table1 relate to table2 with primary id 

Related  Field Fixed Relation: this relation defines where the field is not available and we have to related it from another table where the field is available

Field Fixed Relation: this relation defines where the field is available

We use Field Fixed relation when we have 1:N relation. On certain condition one of the relation become active & other will remain deactivate. Let me use the same theme as MSDN - Clothing.

        Let’s say you have 4 tables

1. ChildernClothesTable

2. MenClothesTable

3. WomenClothesTable

4. ClothesOrdersTable

Create BaseEnum CollectionTypeId with the following elements:

0 - Men

1 - Women

2 - Children

Create Extended DataType CollectionTypeEDT of BaseEnum CollectionTypeId. Now use this EDT in your ClothesTable.  

 

ClothesOrdersTable has the following fields:

1. ClotheId,

2. ClotheName ,

3. CollectionTypeId

4. Qty

 

ChildernClothesTable, MenClothesTable and WomenClothesTable has the following fields:

1. ClotheId,

2. Name

 Example 1:

Related  Field Fixed Relation: 

Case 1: 

On MenClothesOrder we create a new relation to ClothesOrdersTable and specify the following two:

1. Normal Relation:  ClotheId to ClotheId (Best practice to specify this on the EDT)  

2. Related Fixed Field Relation:  0 = ClothesOrdersTable.CollecTionTypeId.

* This shows that the lookup to the clothes table should show only clothes with the same ClotheId AND clothes that are of type Men

* because the table deals with order for mens' clothes.

We use 0 because Men is element 0 in the Enum. 

Case 2:

            On WomenClothesOrder we create a new relation to ClothesOrdersTable and specify the following two:

1. Normal Relation:  ClotheId to ClotheId (Best practice to specify this on the EDT)  

2. Related Fixed Field Relation:  1 = ClothesOrdersTable.CollecTionTypeId.

* This shows that the lookup to the clothes table should show only clothes with the same ClotheId AND clothes that are of type Women

* because the table deals with order for womens' clothes.

We use 1 because Women is element 1 in the Enum. 

Case 3:

            On ChildrenClothesOrder we create a new relation to ClothesOrdersTable and specify the following two:

1. Normal Relation:  ClotheId to ClotheId (Best practice to specify this on the EDT)  

2. Related Fixed Field Relation:  2 = ClothesOrdersTable.CollecTionTypeId.

* This shows that the lookup to the clothes table should show only clothes with the same ClotheId AND clothes that are of type Children

* because the table deals with order for children's clothes.

We use 2 because Children is element 2 in the Enum. 

Example 2:

 Field Fixed Relation:

This kind works the other way round:

Imagine you have a ClothesOrdersTable (generic) and you have seperate tables for MenClothesTable, WomenClothesTable and ChildrenClothesTable. Fixed field says that the specified normal relation (on ClotheId) to MenClothesTable only works if the CollectionTypeId of the current record is set to 0 (Men) else the relation is disabled.

Case 1:

On ClothesOrdersTable we create a new relation to MenClothesTable and specify the following two relations:
1. Normal Relation: ClotheId to ClotheId and
2.  Field Fixed Relation: ClothesOrdersTable.CollecTionTypeId = 0 

and SourceEDT = CollectionTypeEDT

This shows that the lookup to the MenClothesTable should show all clothes with the same ClotheId (Define in Normal Relation) AND clotheId will only bring from MenClothesTable as we are using type Men (Define in Field Fixed Relation) because we want to activate relationship for mens' clothes.

We use 0 because Men is element 0 in the Enum. 

Case 2:

On ClothesOrdersTable we create a new relation to WomenClothesTable and specify the following two relations:
1. Normal Relation: ClotheId to ClotheId and
2.  Field Fixed Relation: ClothesOrdersTable.CollecTionTypeId = 1 

and SourceEDT = CollectionTypeEDT

This shows that the lookup to the WomenClothesTable should show all clothes with the same ClotheId (Define in Normal Relation) AND clotheId will only bring from WomenClothesTable as we are using type Women (Define in Field Fixed Relation) because we want to activate relationship for Womens' clothes. 

We use 1 because Women is element 1 in the Enum. 

Case 3:

On ClothesOrdersTable we create a new relation to ChildernClothesTable and specify the follwing two relations:
1. Normal Relation: ClotheId to ClotheId and
2.  Field Fixed Relation: ClothesOrdersTable.CollecTionTypeId = 2

 and SourceEDT = CollectionTypeEDT
This shows that the lookup to the ChildernClothesTable should show all clothes with the same ClotheId (Define in Normal Relation) AND clotheId will only bring from ChildernClothesTable as we are using type Childern (Define in Field Fixed Relation) because we want to activate relationship for Childern clothes.

We use 2 because Childern is element 2 in the Enum.

 

 Create  three forms and Display Menu Item for display the form in UI and fill the details first in Parent Table (ClothesOrdersTable) and then according the CollectionTypeId the ID shown automatically in the child table.

       As I created here four tables , you can do this with two tables like :

                 ClothesTable & ClothesOrder

            ClothesTable has the following fields:  ClotheId, Name and CollectionTypeId

            ClothesOrder has the following fields:  OrderId, ClotheId, Qty 

                * OrderId could be a number sequence and Qty entered manually by the user.

                CollectionTypeId has the following elements( Base Enum Type)
                    0 - Men
                    1 - Women
                    2 - Children 

                 Example 1: Related Field Fixed

                On ClothesOrder we create a new relation to ClothesTable and specify the following two:

                    1. Normal Relation : ClotheId to ClotheId (Best practice to specify this on the EDT) 

                    2. Related  Field Fixed :  0 = ClothesTable.CollecTionTypeId.

             This shows that the lookup to the clothes table should show only clothes with the same ClotheId                    * Clothes that are of type Men 

          * because the table deals with order for mens' clothes. 

                    We use 0 because Men is element 0 in the Enum.

            Similarly we do this for rest enum 

     

           Related  Field Fixed :  1 = ClothesTable.CollecTionTypeId.(for women)

            Related  Field Fixed :  0 = ClothesTable.CollecTionTypeId (for children)

                  Example 2:  Field Fixed

           On  ClothesTable  we create a new relation to ClothesOrder and specify the following two:

                    1. Normal Relation : ClotheId to ClotheId (Best practice to specify this on the EDT) 

                    2. Field Fixed :  ClothesTable.CollecTionTypeId = 0 (for men)

                Similarly we do this for rest enum

                        Field Fixed :  ClothesTable.CollecTionTypeId = 1 (for women)

                         Field Fixed :  ClothesTable.CollecTionTypeId = 2 (for children)