BC AL Journey #5

In our previous step (#4) of the journey, we enriched the Item table and page with additional details. Extending Purchase and Sales documents follows a similar process, but there’s an extra factor to consider. These records have a specific flow that adds some complexity, yet AL has a method to handle it.

The challenge with Purchase and Sales documents lies in their transition across tables during the normal accounting process. Initially, many of these documents share common header and line tables. However, when they reach the posting stage, they transform into distinct documents.

Let’s break it down by document type:

  • Sales Header (36) and Sales Line (37) Tables: These serve Sales Quote, Sales Order, Blanket Sales Order, and Sales Invoice.
  • Purchase Header (38) and Purchase Line (39) Tables: These correspond to Purchase Quote, Purchase Order, Blanket Purchase Order, Purchase Invoice, Purchase Credit Memo, and Purchase Return Order.

The advantage here is that you only need to edit the relevant table once to add a field applicable to all document types. While you’ll need to update each page and list where the field should display, the consistency ensures that data seamlessly flows from Quote to Order to Invoice without any additional code.

Now, what about Posted documents? Excellent query, hypothetical reader! AL has a method to handle this, and it’s mostly automatic if we configure our fields thoughtfully.

By matching the signatures of fields (Id, Name, and Type) between the Sales Header and the table for posted invoices, Sales Invoice Header, we indicate that we want these values to flow from one table to the other. As a result, the system automatically transfers data when creating new records. Let’s put this to the test!

As is the case with all things, we start with a definition of the task:

Use Case

User would like to track the Warranty Expiration Date on the Sales Documents.

Implementation

  • Extend the Sales Header with the Warranty Expiration Date.
  • Extend the Sales Invoice Header with the Warranty Expiration Date.
  • Extend the Sales Order Page with the Warranty Expiration Date.
  • Extend the Sales Quote Page with the Warranty Expiration Date.
  • Extend the Posted Sales Invoice Page with the Warranty Expiration Date.

Test Plan

  • Enter the Warranty Expiration Date on the Sales Quote Page.
  • Promote the Sales Quote to a Sales Order and verify the date.
  • Post the Sales Order to a Sales Invoice and verify the date.

First, let’s extend the Sales Header (36) table. This is the same process as we did when extending the Item table previously. In this case, let’s add a field to track the Warranty Expiration Date.

I created file ARDSalesHeader.TableExt.AL with the code:

namespace AardvarkLabs;
using Microsoft.Sales.Document;

tableextension 50001 ARDSalesHeader extends "Sales Header"
{
    fields
    {
        field(50000; ARD_WarrantyExpDate; Date)
        {
            Caption = 'Warranty Exp Date';
            ToolTip = 'Warranty Expiration Date';
            DataClassification = CustomerContent;
        }
    }
}

Next is the table for the Posted Sales Invoices. I added the file ARDSalesInvoiceHeader.TableExt.AL and entered the following code:

namespace AardvarkLabs;
using Microsoft.Sales.History;

tableextension 50002 ARDSalesInvoiceHeader extends "Sales Invoice Header"
{
    fields
    {
        field(50000; ARD_WarrantyExpDate; Date)
        {
            Caption = 'Warranty Exp Date';
            ToolTip = 'Warranty Expiration Date';
            DataClassification = CustomerContent;
        }
    }
}

There are few changes to note that make this all work:

  1. The fields are exactly the same. I cut and pasted them to be sure.
  2. The “using” statements are different, the Sales Invoice Header table is in the Sales History, while the Sales Header is in the Sales Documents name spaces respectively.

You can add all the field you like, just ensure that their signatures match.

There may be a case where you don’t want the values to flow through the posting or shipping routines. If they don’t have a match, they won’t flow, but it can cause confusion. I prefer the create a numbering gap that allows me to add values that I don’t intend to flow through at a higher Id number range than the ones that do. For example, all non-flow through values start at 50500. Also, I break them up in the code, so I can see which values flow, and which don’t.

Wrapping up the customizations by adding the new field to the Sales Quote, Sales Order, and Posted Sales Invoice pages.

Sales Order Page updated with ARDSalesOrder.PageExt.al

namespace AardvarkLabs;
using Microsoft.Sales.Document;

pageextension 50001 ARDSalesOrder extends "Sales Order"
{
    layout
    {
        addafter("Document Date")
        {
            field(ARD_WarrantyExpDate; Rec.ARD_WarrantyExpDate)
            {
                ApplicationArea = All;
            }
        }
    }
}

Sales Quote Page updated with ARDSalesQuote.PageExt.al

namespace AardvarkLabs;
using Microsoft.Sales.Document;

pageextension 50002 ARDSalesQuote extends "Sales Quote"
{
    layout
    {
        addafter("Document Date")
        {
            field(ARD_WarrantyExpDate; Rec.ARD_WarrantyExpDate)
            {
                ApplicationArea = All;
            }
        }
    }
}

Posted Sales Invoice updated with ARDPostedSalesInvoice.PageExt.al

namespace AardvarkLabs;
using Microsoft.Sales.History;

pageextension 50003 ARDPostedSalesInvoice extends "Posted Sales Invoice"
{
    layout
    {
        addafter("Document Date")
        {
            field(ARD_WarrantyExpDate; Rec.ARD_WarrantyExpDate)
            {
                ApplicationArea = All;
            }
        }
    }
}

Here are the screen shots as we move the data through the system. Per the testing we start on the Quote.

We click the “Make Order” button:

Last, we Post and create a Sales Invoice:

The data flowed from document to document exactly as we designed. This works equally as well for Purchase documents and the sales and purchase line records. This was a lot to cover, but it one of the most useful tools for customizations.

All code is available in the GitHub page: https://github.com/AardvarkMan/BC-Journey

One response to “Updating Sales and Purchase Documents”

  1. […] we have done a lot with data inside Business Central. We have covered data storage in tables and table extensions. We have accessed that data in Pages, APIs and most recently Queries. All of this bring us to one […]

    Like

Leave a comment

Trending