EXP-RO01-4.10.8.0

EXPERT Business Suite^®

New features and functionality

Summary

A brief description of major extensions in this version is provided. New functionalities & improvements are thoroughly presented along with the necessary user guidelines and examples.

Entersoft ERP

• Customization of environment and functionality of payment planning.
• Payment exemption functionality in payment planning process.

Entersoft ERP

Payment planning

New features for customizing the environment and functionality

This version has been enriched with a series of significant changes and improvements in payment planning processes. These changes and improvements aim to make the process to be extensively customizable, which was virtually absent. Changes concern all four payment planning processes:

• Payment planning
• Payment planning process: pending approval
• Payment orders approval
• Payment receipts for approved Orders

Briefly, the new customization options provided are the following:

• Feature for showing additional customized information on the editing forms in order to help the user to make decisions.
• Feature for intervening in the DB query, which forms the results shown on the payment editing forms.
• Feature for changing investigation parameters used in every form.
• Feature for intervening in the result grouping method shown by the processes, even using custom fields.
• Feature for embedding custom checks and updates when selecting and inserting values in the fields of the form.
• The process of creation of payment documents can be customized and changed.

Detailed information on how to customize the above features can found in the Appendix at the end of the document.

Payment exemption

Payment planning processes have been enriched and hereafter specific debts can be indefinitely exempted (postponed). The exemption concerns the whole of an open debt and not part of it. For instance, the payment of a supplier’s invoice could be postponed for any reason and this will stop appearing in the debts to be paid. Of course, it could be gotten back and paid.

Customization

The above feature is based on the insertion of the exempted debt in a document in a specific step which code will be declared in the new company parameter:

Payment planning process => 14.Payment exemption order step

with default value POSTPONED.

Exemption process

This feature is provided in the following two planning and approval processes that display outstanding receivables:

• Payment planning
• Payment orders approval

On the forms above, opening the 2^nd level next to any outstanding or approved debt, the Exception field is shown. For those debts that are selected in the field, when the Continue button is clicked, these debts will be included in a document of the type declared in the parameter:

Payment planning process =>03.Document type for automatic creation of payment orders

in step as defined in the related parameter for exempting debts.

For more effective management of the exempted debts on the above forms:

• Show exemptions criterion has been added. It should be selected in order to include the exempted debts in the results.
• The exemption value, ie the total value of the exempted debts is shown on separate column at the 1^st level. This value is not counted in the Amount due column.

To be able to reset a debt from the exempted to the “normal”, simply display them, deselect the Exempt field next to the debt field and click the Continue button.

Then the debts will again be available for payment.

Cash payment

The feature of cash payment was already available in payment planning processes, but shared the same method of functionality and customization with the remittance. Hence, it has been separated from remittance by allowing the creation of a different payment document type, but also the use of an account that is not related to a bank.

The document type customization to be used for cash payment, is defined in the new company parameter

Payment planning process =>04. Document type for creating automatically cash payment documents

Cheque default expiry date

The Cheque expiry date generated by the payment planning process, hence, uses the date of issuance of the payment document instead of the system date as the base date for calculating the expiration date of the cheques.

Fixed Assets

Depreciation calculation process

The process has been improved so that it is not interrupted due to errors. Hence, it is ensured the time required to execute the process. Since it is not necessary to re-calculate all the fixed assets but only those excluded from the calculation, after of course the needed corrections.

Το αρχείο συμβάντων της διαδικασίας εμπλουτίστηκε αναγράφοντας το πάγιο/αποσβεστεά κτήση ώστε να είναι πιο εύκολος ο εντοπισμός των προβληματικών περιπτώσεων.

The log file of process was enriched by recording the fixed / depreciated acquisition to make it easier to locate problematic cases.

Fixed Asset Accounting Transfer

In version 4.10.6.0, the method of calculating depreciation for the cases of fixed assets credited through accounting transfer using the TCM - Transfer contabil mijloc fixdocument was improved.

In such cases, depreciations carried over from one fixed asset to another is the accumulated depreciations until the time of registration of the transport document (СТА). While in the case of partial transferring, the transferred value is the proportionate part of the value based on the quantity transferred. Following the Year-to-Date method, the depreciation calculation process takes into account only the part of the value for the current year, excluding the transferred carry-over value. This method allows the calculation of the "actual depreciation value" of the period to avoid calculating write-offs.

In order to facilitate the control of results, in this version, this information is stored in the depreciation document, in the "Comment 2" field of the line, available in the column extraction.

To make the above functionality more comprehensible:

Suppose we have a fixed 10 pieces, with an acquisition cost of 1,200 €.

For the fiscal year 2018 an annual depreciation of 120 € has been executed.

While depreciation from 1/1 to 15/3 is worth € 24.84 for the fiscal year 2019.

There is an accounting transfer of part of the fixed asset into new depreciable acquisitions for the 5 pieces:

Cost: 600€ – Depreciations: 72,42€

The result of the credited fixed asset is as follows. A part of the depreciation value transferred (€ 60) relates to the previous year and must be ignored by the YTD calculation of the current year, while the remaining (12,42 €) relates to the current fiscal year, ie 1/1 - 15/3 and must be taken into account by the calculation procedure. In the next calculation of depreciation, let's say for the period up to 31/3, the amount to be deducted from the a part of the quantity (5 pieces). For the remaining quantity the total depreciation up to 31/3 is 15 €. The process will take into account the portion of the depreciation carried over (€ 12.42) and accounts for the remaining part of 2.58.

Item hierarchy sales analytic report

This analytic report has been enhanced to provide two levels of drill down analysis for customers and items. Drill down is provided for any selected hierarchy. Using the drill down icon the following drill down reports are provided:

• 1^st level provides on the fly ABC movement analysis based on the turnover achieved for the selected period and the comparative period. In this context, 3 classes are calculated based on the following ABC tiers:
  • A: 70% - Customers with cumulative turnover equal to 70% of the total turnover
  • B: 90% - Customers with the next 20% cumulative turnover - up to 90% of the total turnover
  • C: The remaining 10% of the total turnover

In this context the following classes are provided:

Previous period class	Selected period class	Description
A	A	The most important customers
A	B
A	C
A
B	A
B	B
B	C
B
C	A
C	B
C	C
C
	A	New or returning customer
	B	New or returning customer
	C	New or returning customer

• 2^nd level provides customer/item analysis based on the selected ABC movement class. In this context, you may compare customer performance based on sales key figures.

Appendix

Payment planning – Customization guide

The basic change made to the payment planning and allowed us to give all these features to customize the functioning and updating method is the creation of the new entity

Payment planning - ESFIPaymentPlanning

This entity represents, with a master-detail logic, how the results are displayed on the four payment editing forms. The 1^st level is the master entity and the 2^nd level is the detail. The four payment editing forms are based on this joint entity (ESFIPaymentPlanning) and, depending on the menu option, different results, display layout, and execution parameters are loaded.

As an entity, it can support functions similar to those of other entities, most notably by creating rules for check execution and assignment both during registration and saving. On the other hand, this means that the grid of results, although it looks like, it is not a scroller but an entity with predefined fields. Therefore, it is not possible to retrieve additional as only the fields known to the entity are supported. However, there are many user defined fields available that can be used as explained below to provide additional information.

Because of the fact that all the editing forms use the same entity, the Step (context) field is provided. Based on its value, we can see how the entity operates, for example, in a rule. Field values are:

1. – Payment planning

2. – Payment planning process: pending approval

3. – Payment orders approval

4. – Payment receipts for approved Orders

Changing the query

Henceforth, the query that retrieves the data set at the 1^st step of each editing form is supported. This feature is based on changing the query of specific scrollers, different for each function. The scrollers are saved in the Suppliers area (ESFISupplier):

• ESFISourceEntriesForPaymentPlanning – Payment planning
• ESFISourceEntriesForApprovalStep1 – Payment planning process: pending approval
• ESFISourceEntriesForApprovalStep2 – Payment orders approval
• ESFISourceEntriesForApprovalStep3 – Payment receipts for approved Orders

It is very important to understand the type of data that each query retrieves, since the mandatory data set for each form must be:

• In Payment planning – Liquidity Account Entries - ESFILiquidityAccountEntry
• In Payment planning process: pending approval – Liquidity Account Entries - ESFILiquidityAccountEntry
• In Payment orders approval – Liquidity account lines and notes (using union)
• In Payment receipts for approved Orders – Liquidity account lines and notes (using union)

From the above it is understood that eventually the query of each scroller does not correspond to either of the two levels displayed on editing form, as the records and the method they are grouped and displayed at each level are determined by a code script that uses it as the primary data which the scroller retrieves. If the scroller does not have a line, this entry will never be available for editing. Therefore, it is suggested that the change in the scroller query is used to add parameters and display more information about the records.

Change where

The where statement of the scroller could be changed and become queried whatever fields we want.

Change investigation parameters

The params panel shown in each mode is what is customized on the scroller of each different editing form. So you can add or delete as many parameters as you wish. Parameters that eventually appear include some parameters that cannot be removed/ modified.

Change grouping

It is possible to group the results displayed at the 1^st level using any combination of fields of the entity. For this purpose, in the params panel of each scroller there is a parameter with a group list. This is an Enum list which options are descriptions of the fields involved in the grouping as they are shown on the scroller.

For instance, let us say we want to support grouping with combinations of the Branch, Business unit, Transaction User Defined Field 2 and some other UDF field of the ESFIPaymenPlanning entity that u have chosen to call Priority.

The fields to be declared in the parameter must be in the scroller query with a description exactly as it appears in the Enum list. For example the Business Unit field, in the select list is shown as follows:

And the Priority field:

During execution and when selecting fields for grouping, the 1^st level records will be grouped by the group by logic, and multiple lines will be displayed based on the grouping. Though, in order for the user to understand the result and justify the appearance of multiple rows at the 1^st level, you must also ensure that the columns are displayed with the fields involved in the grouping.

Apart from the grouping that is selected through the criterion, the results are always grouped by both the Trade account and the Company.

Update documents

Hereafter, intervention in the process of document creation by payment planning and Payment receipts for approved Orders is supported.

Updating is accomplished through the use of two (form) automations found in the area ESFormCommands\ESFIPaymentPlanningWizard

• CreateDocuments, for payment planning
• CreateDocuments_IssueStep, for payment receipts for approved Orders

Each automation is invoked when the “Continue” button is clicked on the editing form. The invocation is made consequently for each record of the 1^st level selected for payment. The structure of the automation is consistent with that of the entity and captures all different methods of payment. Depending on the payment method, the entity details that the automation used as a source for the updated are also updated. Automations create, based on customization, Cash transaction documents or Adjustment Documents. The insertion of the lines is based on the payment method using the appropriate detail each time.

Especially for the actions

• Payment planning process: pending approval
• Payment orders approval

the use of automation for updating is not supported because the documents created by these processes are intended to record the approval steps and, particularly, to use the code script. However, it is possible to write rules (BR) when saving the above logs to intervene in their saving. The recognition of these documents in a rule is done by checking two special extended properties bearing these documents and deciding whether they came from the 1^st or 2^nd step respectively of the approval process. You can find examples of such rules that control the above properties in system rules:

• Payment planning Step 1
• Payment planning Step 2

in the cash transaction and adjustment documents.

Release Document for EXP-RO01-4.10.8.0