Base on JournalId on LedgerJournalTable you can use code below for posting into transactions

//Contract class
public LedgerJournalId parmJournalNum(LedgerJournalId _journalId = gJournalId)
    gJournalId = _journalId;

    return gJournalId;

//Processing class
public void process(MAV_PostCustPaymentJourContract _contract)
    LedgerJournalTable      ledgerJournalTable;
    LedgerJournalCheckPost  postCustPaymentJournal;

    ledgerJournalTable = LedgerJournalTable::find(_contract.parmJournalNum());
    if (ledgerJournalTable)
        postCustPaymentJournal = LedgerJournalCheckPost::newLedgerJournalTable(ledgerJournalTable, NoYes::Yes);;

The Microsoft Dynamics AX runtime manages the storage of value type data on the call stack and reference type objects on the memory heap.

The call stack is the memory structure that holds data about the active methods called during program execution. The memory heap is the memory area that allocates storage for objects that are destroyed automatically by the Microsoft Dynamics AX run-time.

Value types

Value types include the built-in primitive types, extended data types, enumeration types, and built-in collection types.

  • The primitive types are boolean, int, int64, real, date, utcDateTime, timeofday, str, and guid.
  • The extended data types are specialized primitive types and specialized base enumerations.
  • The enumeration types are base enumerations and extended data types.
  • The collection types are the built-in array and container types.

By default, variables declared as value types are assigned their zero value by the Microsoft Dynamics AX runtime. These variables can’t be set to null. Variable values are copied when variables are used to invoke methods and when they are used in assignment statements. Therefore, two value type variables can’t reference the same value.


Reference types

Reference types include the record types, class types, and interface types.

  • The record types are table, map, and view. User-defined record types are dynamically composed from application model layers. Microsoft Dynamics AX runtime record types are exposed in the system application programming interface (API). Although the methods are not visible in the AOT, all record types implement the methods that are members of the system xRecord type, a Microsoft Dynamics AX runtime class type.
  • User-defined class types are dynamically composed from application model layers and Microsoft Dynamics AX runtime class types exposed in the system API.
  • Interface types are type specifications and can’t be instantiated in the Microsoft Dynamics AX runtime. Class types can, however, implement interfaces. Variables declared as reference types contain references to objects that the Microsoft Dynamics AX runtime instantiates from dynamically composed types defined in the application model layering system and from types exposed in the system API. The Microsoft Dynamics AX runtime also performs memory deallocation (garbage collection) for these objects when they are no longer referenced.

Reference variables declared as record types reference objects that the Microsoft Dynamics AX runtime instantiates automatically. Class type objects are programmatically instantiated using the new operator. Copies of object references are passed as reference parameters in method calls and are assigned to reference variables, so two variables can reference the same object.

Thank you for reading!

Document services

Document services use documents to represent business objects such as purchase and sales orders, customers, vendors, and so on.

A document service is composed of the following components:

  • Document query : This is a query that is created in the Application Object Tree (AOT) and contains all the tables that are related to the business object that you want to expose. Based on this query, the Document Service Generation Wizard can be used to generate the other artifacts that make up the document service.
  • Table AxBC classes : An AxBC class is a wrapper for a table and contains business logic that is needed for Create, Read, Update, Delete (CRUD) operations.
  • Document class : The purpose of the document class is to contain business logic that is associated with the creation and modification of the business entity itself. For example, the AxdCustomer class could contain logic to handle party information of a customer.
  • Document service class : This is the actual service implementation class and extends the AifDocumentService class. This class implements the service operations that are published through the service contract.

When creating document services, developers need to make sure that the business object is mapped correctly to the document query. The document services framework will handle all other things such as the serialization and deserialization of XML, date effectiveness, and so on.

Document services can be deployed using the integration ports and all available adapters can be used.

Continute reading