Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 81 Next »

Description

You may subscribe to posting events in the Business Central base App to process collected values, or when events offered by Extension API does not fit your exact need.

MOB Events

Handling collected values from the Mobile Device is done by subscribing events like  OnHandleRegistrationFor[...] or OnBeforePosting[...]

For example:

The PostReceiveOrder events for Warehouse Receipts handles registrations collected for each individual order line, as well as data from Header steps.


A common way to post collected data, is to "stage" the collected values, then have standard posting routines pick up the staged values during the actual posting.

You may subscribe to standard events in order to:

  • Move "staged" data to the final destination during posting.

  • Process a workflow during posting that requires your data to be rolled back on error.

  • Process a workflow on after posting that is not required to be a part of same database transaction or is not sensitive to not being fully executed in case of error (ie. printing labels).


Commit

Database transactions in OnHandleRegistrationFor[...] and OnBeforePosting[...] events are committed prior to calling the standard posting functions.

  • This requires your code to be structured to take into account that your database transaction will not be rolled back on error during standard posting.


Preferably your code should be organized to "stage" collected values in a manner that will allow standard posting events to access the collected values, yet takes into account that posting may never complete or data may change prior to next posting. 

  • "OnBeforePost[...]" and "OnHandleRegistrationFor[...]" events are the recommended way of "staging" data prior to posting


When subscribing to standard events

Carefully choose which standard BC events you subscribe to, and give ample consideration to how Commits in standard posting codeunits will affect your code and data being rolled back correctly.

  • Preferably your code should be organized to "stage" collected values in a manner that will allow standard posting events to access the collected values, yet takes into account that posting may never complete or data may change prior to next posting. 
  • Subscribing to MOB events "OnBeforePost[...]" and "OnHandleRegistrationFor[...]" is the recommended way of "staging" data prior to posting

You have two clients to consider

  • Remember, your Events are fired both when posting from the Mobile Device, the Mobile Document Queue, but also when posting from Web Client.
    • So your code must allow execution both when triggered from Mobile WMS, and when triggered from Web Client.

  • The document header field "MOB Posting MessageId" is populated when posting a document from Mobile or Queue but not when posting from Web Client.
  • When document header field "MOB Posting MessageId" is empty the Mobile Message cannot be accessed from your posting context and only "staged" collected values from a previous try can be accessed. 
  • Re-trying from the Web Client will not populate "MOB Posting MessageId".
  • However, "staged" data that is committed will be available/visible when posting re-trying from Web Client.


Event flow order

In the 3rd step you need to decide whether to subscribe to standard posting events.


Step 1: Define Steps

Define which Steps to collect

Events:

 

Step 2: Handle collected Step values

Stage collected date in custom tables/fields

Events:

 

Step 3: Standard posting is triggered

Post and Clean-up staged data from 2nd step

Event:

  • Codeunit::"Whse.-Post Receipt", 'OnBeforePostSourceDocument'

Example

TODO  Verify sample code

[EventSubscriber(ObjectType::CodeunitCodeunit::"Sales-Post", 'OnRunOnBeforeFinalizePosting''', false, false)]
 local procedure OnPostingSalesReturnOrder_OnRunOnBeforeFinalizePosting(var SalesHeader: Record "Sales Header"; var SalesShipmentHeader: Record "Sales Shipment Header"; var SalesInvoiceHeader: Record "Sales Invoice Header"; var SalesCrMemoHeader: Record "Sales Cr.Memo Header"; var ReturnReceiptHeader: Record "Return Receipt Header"; var GenJnlPostLine: Codeunit "Gen. Jnl.-Post Line"; CommitIsSuppressed: Boolean)
 var
     OrderValues: Record "MOB Common Element" temporary;
     MobRequestMgt: Codeunit "MOB NS Request Management";
     HeaderRecRef: RecordRef;
 begin
     if IsNullGuid(SalesHeader."MOB Posting MessageId"then
         exit;     // not Mobile WMS posting or retry from Web Client
     if (SalesHeader."Document Type" = SalesHeader."Document Type"::"Return Order") and (ReturnReceiptHeader."No." <> ''then begin
         HeaderRecRef.GetTable(SalesHeader);
         MobRequestMgt.GetOrderValues(SalesHeader."MOB Posting MessageId", OrderValues);
         MyOnPostReceiveOrder_OnPostingSalesReturnOrder(OrderValues, SalesHeader, ReturnReceiptHeader);
     end;
 end;

  • No labels