The below sections provide an overview of the components of the Retail localization solution for Norway included in Retail SDK. You can modify these components to customize or extend the localization functionality.
Enterprise POS
The solution consists of two new projects, the new interfaces and the new service. Besides that, several existing interfaces are extended with new methods.
- The new interface of ITaxOverrideTrigger is part of the Contracts assembly.
- The NorwayTriggers project is located in the Retail SDK\POS Plug-ins\Triggers folder and is part of the Triggers solution.
- The ReceiptTransactionTypeService project is located in the Retail SDK\POS Plug-ins\Services folder and is part of the Services solutions.
- The existing interface of IBatchOperationTrigger is extended with three new methods:
- PreSaveCloseBatch is called before closed batch saving;
- PreBuildReport is called before build daily report;
- PostBuildReport is called after build daily report with possibility to extend it.
- The existing interface of IItemTrigger is extended with new method:
- PostPriceCheck is called after checking the item price.
Tax override trigger
The new TaxOverride trigger is added to enable the customization of the tax override process. This trigger works the same way as other triggers and is loaded by MEF. It provides four methods of PreOverrideTaxLine, PostOverrideTaxLine, PreOverrideTaxTransaction and PostOverrideTaxTransaction, which are called before and after overriding tax for sales line and sales transaction, respectively.
The new ITaxOverrideTrigger interface was added to the Contracts library. This interface describes the PreOverrideTaxLine, PostOverrideTaxLine, PreOverrideTaxTransaction and PostOverrideTaxTransaction methods.
The PreOverrideTaxLine and PreOverrideTaxTransaction methods can interrupt the tax overriding process and show messages via the standard PreTriggerResult object. To use the TaxOverride trigger, a new class needs to be created. This class should implement the ITaxOverrideTrigger interface. In this case, MEF will load the class during the application startup.
Receipt transaction type service
The new ReceiptTransactionTypeService service is added to enable the customization of logic determining the type of receipt transaction from POS transaction. This service works the same way as other services and is loaded by MEF. It provides the GetReceiptTransType method, which could be called from localization triggers to determine the type of receipt transaction from POS transaction, for example in order to resolve receipt title field.
Norway triggers
The NorwayTriggers project contains standard POS triggers that are loaded if the ISO code field of the functionality profile of POS is set to NO.
- The NorwayApplicationTrigger implements the IApplicationTrigger interface and overrides the ApplicationStart method. The method initializes the registration state of the RegistrationManager by calling the ActualizeRegistrationState method.
- The NorwayBatchOperationTrigger implements the IBatchOperationTrigger interface and overrides the SaveCloseBatch, PreSaveCloseBatch and PreBuildReport methods.
- The SaveCloseBatch method update shift grand total counters;
- The PreSaveCloseBatch method calculates Norway specific shift date and saves in order to transmit it to HQ;
- The PreBuildReport method overrides X and Z reports build logic.
- The NorwayPrintingTrigger implements the IPrintingTrigger interface and overrides the GetReceiptFieldInfo method. The method receives the IReceiptField and the IReceiptPrintingContext objects and calculates the value of the receipt field being printed.
- The NorwayTransactionTrigger implements the ITransactionTrigger and overrides the PreEndTransaction and SaveTransaction methods.
- The PreEndTransaction method receives the IPosTransaction object and performs registration of the retail transaction.
- The SaveTransaction method receives the IPosTransaction object and finalizes the registration of the retail transaction by saving the fiscal registration information.
Registration process
The RegistrableEventRetailTransactionAdapter is adapter class implementing the IRegistrableEvent interface for registrable sales transaction object type in the NorwayTriggers project:
The adapter is responsible for extracting and serializing the information used for registration from the registrable objects. An adapter of the appropriate type is created inside PreEndTransaction trigger method. Registration is performed by the RegistrationManager class located in the NorwayTriggers project. The RegistrationManager uses the DefaultFiscalRegistrationService service which implements the IFiscalRegister interface and is loaded by MEF.
DefaultFiscalRegistrationService creates and sets an instance of IFiscalRegisterDriver. It uses the FiscalRegisterFactory class to create an appropriate instance of IFiscalRegisterDriver and produce an instance of the DigitalSignatureFiscalRegister class under the Norway country/region context. Serialized fiscal registration data is stored in the JSON format in the RetailTransactionFiscalTransaction database table.
Retail Server
A new Retail Server InsertAuditEvent request was added to support the Retail localization for Norway. The request used to insert audit events. Corresponding method could be found in the StoreOperationsManager retail proxy adapters in Retail SDK\Proxies\RetailProxy\Adapters.
Commerce Run-time
The Commerce Run-time localization consists of SDK.FiscalRegisterServiceNorway project, a new request and handlers.
The SDK.FiscalRegisterServiceNorway project contains FiscalRegistrationService which handles a number of new requests:
- GetFiscalRegistrationSequenceTypeServiceRequest is a request to determine the fiscal sequence type from a sales transaction type.
- GetLastRegisteredFiscalDataServiceRequest is a request to retrieve the last saved fiscal data for a specified fiscal sequence type.
- GetFiscalRegistrationSequenceServiceRequest is a request to retrieve the current sequential number for a specific store, terminal and sequence type.
- GetSalesOrderFiscalRegistrationInfoRequest is a request to retrieve fiscal data from a sales order.
- ParseFiscalRegisterDataRequest is a request to parse a serialized register response in the JSON format to an object.
- SaveSalesTransactionDataRequest is an overridden request that performs the registration of sales transaction and then calls the original request handler to save the transaction.
Modern POS
Localization of Modern POS includes changes in several views and view models located in Retail SDK\POS Clients\Framework.
Registration process
The registration of sales transactions is managed by the FiscalRegistrationManagerNorway class implementing the IFiscalRegistrationManager interface. The FiscalRegistrationManagerFactory class is responsible for the creation of the appropriate implementation of IFiscalRegistrationManager and creates FiscalRegistrationManagerNorway under the Norway country/region context. The registration of sales transactions starts in the CartViewModel class in the checkOutCart method. CartViewModel uses FiscalRegistrationManagerNorway to execute registration logic before and after the checkout.
The pre-checkout logic extracts the registration information (register response) for the last registered sales transaction from the local storage (if it exists) or requests it from Retail Server using the GetLastRegisteredFiscalData request. The last register response passed as extension properties of the Cart object to the checkout. The extension property storing the last register response is then extracted while handling SaveSalesTransactionDataRequest in Commerce Run-time and is used to produce the digital signature of the current transaction. The post checkout logic saves the current register response to the local storage to be used in future requests.
The registration of audit events is managed by the AuditEventManager and AuditEventManagerNorway classes and is initiated from various points:
- The registration of the Logon audit event is initiated from LoginViewModel after a successful operator logon.
- The registration of the Logoff audit event is initiated from LogoffOperationHandler.
- The registration of the Purge audit event is initiated from the BlindCloseShiftOperationHandler and CloseShiftOperationHandler classes.
- The registration of the events of starting and ending of the offline mode is initiated from the ChainedRequestFactory class.
- The registration of the Quantity correction audit event is initiated from CartView class and SetQuantityDialog class for clear quantity operation and set quantity operation, respectively.
- The registration of the Price check audit event is initiated from PriceCheckOperationHandler.
- The registration of TaxOverride audit event is initiated from the OverrideLineProductTaxOperationHandler and OverrideTransactionTaxOperationHandler classes.
- The registration of the event of printing of a copy of a receipt is initiated from ReceiptViewModel.
Modern POS registers audit events by sending the InsertAuditEvent request to Retail Server.