ERP-RO01-5.9.0.0

Entersoft Business Suite^®

New features and extensions

Liquidity

Planning of payments

In this version a significant extension was made to the Planning of Payments feature. Planning of Payments is an extremely useful process for managing the company’s cash flow and is used to easily and quickly carry out mass payments to suppliers and creditors. The relevant screen shows, grouped by supplier/creditor, the all of the company liabilities to them, in order for the amounts to be paid partially (or fully). Planning of payments facilitates the user, since it includes a multitude of features, such as the proposal of the agreed method of payment for each trade account (cash, fund transfer, company check or customer receivable check), mass payment of all outstanding balances, payment with new checks or checks from the company’s portfolio, the display of additional information such as the company's bank account from which the withdrawal will be made, or the bank account of the trade account to which the deposit will be made. In fact, it's possible to pay out a specific balance (invoice), as well as an amount for a set of documents, starting from the oldest ones.

This version's new implementation makes it possible to add an deposit for Orders meant for suppliers/creditors, through the Planning of payments screen. Very often, agreements made between the counter parties (company and supplier/creditor) stipulate the payment of an amount upon making the order. It's therefore essential to make the deposit through an environment such as Planning of payments, which deals with overall balance management.

Thus, through the Planning of payments screen, it is possible to view, using the relevant criterion, the invoices (confirmed forecasts) and orders (scheduled outflows) that have been made and have not yet been paid (have not been converted into invoices).

The new criterion is displayed in the parameter group “All” and is called “Entry type”. The available values are:

• Confirmed forecasts the supplier/creditor invoices (default value)
• Planned outflows supplier/creditor orders
• All

For every trade account, 2 lines appear - as long as there’s documents belonging to both cases - where each line compiles all the documents of each case. In the 1^st row and column “Amount due”, you can see the total outstanding invoices and in the 2^nd row, the total open orders. The order line will be displayed in a distinct green color.

At the 2^nd level - just as with open invoices - you can see the orders with their open amount in detail, the sum of which appears cumulatively at the 1^st level under "Amount due".

For the “Planned outflows” and “Total paid amount” lines, the user enters the amount of the deposit and this is allocated to the orders, starting from the oldest (based on the forecast expiration date). Alternatively, the user can choose a specific order from the 2^nd level and add the deposit they wish specifically for it.

After the deposit has been added to the relevant document, the related order is displayed. The same goes for the transitions screen.

The payment document to be created for the order deposit through the Planning of payments cannot belong to the same type as the payment documents created for open invoices. This is determined by a new company parameter in the Workflows/Processes category titled: “Payment plan process =>16. Doc type for automatic creation of deposits”. If the parameter is left blank, a relevant prohibition message appears at the start of the process and the parameter must be configured to proceed.

Attention: we suggest that you create a different document type for order deposits (planned outflows) from standard invoice payments (confirmed forecasts). The reason is that different configuration is required in the document type for each case. For example, take Auto matching of document type: in order deposits we do not want the payment document to be matched with a random outstanding invoice, but with the invoice that will result from the order that concerns the deposit. Whereas, in invoice payments auto matching with the invoice is required.

Note: This document must belong to the category of Transaction documents (e.g. CPS) and not the Adjustment category (e.g. BPC).

Cash Flow Monitoring

The new feature added to the Planning of payments facilitates the monitoring of the company cash flow, since financial indicators such as Planned Inflows and Outflows are reflected in a more integrated way. In essence, deposit amounts are now covered, concerning deposits added for orders, i.e. non-value official documents.

In general, the indicators of the cash flow monitored through the application are as follows:

Liquidity		Confirmed forecasts		Planned
Inflows	Outflows	Inflows	Outflows	Inflows	Outflows

• The Liquidity concerns actual receipts/payments.
• The Confirmed forecasts are derived from the sales & purchase invoices and show the amounts agreed to enter or leave the company, since the relevant value documents exist.
• Planned liquidity displays amounts that are to be released in the (immediate) future as available to the company and concern orders (sales orders/purchase orders).

The Confirmed forecasts, amounts related to invoices, are ones that change as receipts/payments added are matched to them and “settle” them. Planned liquidity (order-related amounts) also changes, as receipts/payments that are added and are associated with them leave them with a balance until their invoicing.

It is very important to understand that while the deposit is initially given for an order, in order to validate the agreement of the future sale/purchase, other documents may then follow within the system that illustrate the course of this order, such as its confirmation, loading etc. In this case, the deposit (partially or fully) no longer relates to the initial order, but to the ensuing documents. Thus, we end up with sales/purchase order documents consisting of many consecutive steps. We can monitor the deposit that corresponds to each of them, after the part of the deposit that corresponds to them is transferred.

Let’s look at an example of configuration of the cash flow indicators, based on the above scenario, in order to understand this better.

Let’s say that there are the following documents in October:

• Purchase invoice 100€
• Purchase order 100€

	Confirmed forecasts		Planned
	Inflows	Outflows	Inflows	Outflows
October		100€		100€

And then:

• Payment for invoice 80€
• Order deposit 30€

	Confirmed forecasts		Planned
	Inflows	Outflows	Inflows	Outflows
October		20€		70€
Analysis:		Invoice 20€		Order 70€

• Order confirmation 80€

	Confirmed forecasts		Planned
	Inflows	Outflows	Inflows	Outflows
October		20€		70€
Analysis:		Invoice 20€		Order 14€
				Confirm 56€

• Order loading 80€

	Confirmed forecasts		Planned
	Inflows	Outflows	Inflows	Outflows
October		20€		70€
Analysis:		Invoice 20€		Order 14€
				Loading 56€

• Invoicing for the loading 80€

	Confirmed forecasts		Planned
	Inflows	Outflows	Inflows	Outflows
October		70€		14€
Analysis:		Invoice 20€		Order 14€
		Invoice 50€

In general, in every new document that is made and is a continuation of the initial document that created the planned inflow/outflow:

• a forecast is created
• the inputs/outputs are updated
• the previous inflow/outflow is undone

Configuration

1. In company parameter “Payment plan process =>16. Doc type for automatic creation of deposits”, in parameter category “Workflows/Processes”, the user can specify the payments document type that will be used to generate deposits through the Planning of payments screen. This document must belong to the Payments document category.
2. All document types that positively inform the planned inflows/outflows must include in field: “Planned inflows/outflows” value Inflows, if they relate to the Sales sub-system and Outflows if they relate to the Purchases sub-system. All document types that negatively inform the planned inflows/outflows must include in field: “Planned inflows/outflows” value Undo inflows, if they relate to the Sales sub-system and Undo outflows if they relate to the Purchases sub-system. Additionally, the “Auto forecast” field must be selected. In the above example in the Sales sub-system, the Order, the Order confirmation and the Order loading must have value Outflows, while the Purchase invoice, the Order rejection and the Payment receipt must have value Undo outflows.
3. In all transition rules used to illustrate the "chain" of evolution of the initial order until its invoicing, the "Undo planned inflows/outflows" field must be selected.
4. If there are custom document types that undo outflows (see 2), another line must be added to them in the document update profile, such as line 81 in the product Document update profile 11000.

Prints

Suitable prints are available in the Business Intelligence menu, to check planned inflows and outflows. These are:

• Cash Flow based on all forecasts
• Cash Flow based on planned flows
• Justification of planned inflows
• Justification of planned outflows

Miscellaneous improvements

• Increased the number of KeyOnSave characters to 255 characters from 100.
• Improved the screen layout, to add the possibility to create a new trade account through the document. There is an option for a customer/debtor in the sales documents or for a supplier/creditor in the purchase documents.

• An improvement was made so that when saving company parameters, if there are incorrect values, the names of these parameters are indicated with a message, for the user to correct them.
• Added a new company parameter for customer search in Retail. The parameter is called “Max number of entries when searching for retail customer", belongs to the "Document management" category and determines the maximum number of customers that will appear during the search. This was deemed necessary for cases of databases with a large number of customers, in order to avoid delays.
• If the parameter has value 0, the search brings all customers.
• Improvements were made to cubes “Expenses per cost center” and “Expenses by period”, so that all available expense types (22 in total) are displayed in the “Expense type” criterion.
• The Tax Offices list has been updated. The existing Tax Offices were updated with their new addresses, new Tax Offices were added or those that were removed became inactive.
• The check of change to closed import folders was improved, in order to cover more cases. More specifically, the process checks additional fields such as item, quantity, alternative quantity, weight, net value, VAT value and the total value in base currency.
• In the “Warehouse balance without intercompany transactions” bit, the “Intercompany transactions” parameter was added (default value “No”). That way, if the user wishes to have a Balance Report with only intercompany transactions, all they have to do is select value “Yes” in the new parameter.
• From within the document and during the preview of the trader account register, an improvement was made to show both the code and the trade account name in the print title.
• Improvements were made to the Data Type History Log scroller:
• the default value in the "Create" parameter changed from “Any” to "Current week"
• A new "Data type title” parameter was added

Horizontal functionality

This version supports a network connection with Microsoft EntraId, for users to log in to EBS, beyond the existing functionality of LDAP login for companies with on-premises servers.

For this reason, two optional fields were added in CSConfig\ESClientConnect.xml: the AzureClientId and the AzureTenantId. Therefore:

• in case a user is logged in with EntraId, at least the AzureClientID must be specified with the application ID created in the Azure domain.
• in case of a multi-tenant installation, the AzureTenantID must be specified so that users of only one specific organization can log in. If there is no such need, the field can be left empty.

Additionally, in the Azure domain the installation admin must specify the following:

• User.Read
• User.Read.all
• CrossTenantInformation.ReadBasic.All

the last two require admin consent for them to be available to users.

Of course, as in the network connection with LDAP, the EntraId account that needs to be able to log in must be selected in the user's communication profile.

PDF Version