RO | EN

1. Liquidity

Payment orders preparation

The Payment orders preparation process has been enriched. Now, using it the user can also manage advance payments for orders. The same way as in the Planning of payments process – where this feature was offered in version 5.9.0.0 – starting from this version onwards, in the 3 steps of Payment orders preparation process the user can also view the Supplier/creditor orders, depending on the value of the criterion “Entry type”.

The user is thus able to add advance payments for those which must first be approved and then, in the last step, it must result in the appropriate transaction document (payment document).

• Initially, through the 1st  step of the Payment orders preparation screen, it is possible to view, using the “Entry type” criterion, the invoices (confirmed forecasts) and the 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 there are 2 rows - as long as there’s documents in both the invoice and order categories - and each row compiles all the documents of each case. In the 1st row and column “Amount due”, the user can view the total outstanding invoices and in the 2nd row, the total open orders.
  The order line will be displayed in a distinct green color.

  • At the 2nd 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 1st level under "Amount due".

  • After the payment amount has been entered and with the use of the Next, Payment order documents are created (type PSD)

• In the 2nd step, “Payment orders approval”, by using criterion "Entry type" again, the user can view the PSDs that have resulted from invoices and/or orders. Selecting them and completion the action signals their approval.

• Finally, in the 3rd step, Approved payment orders are converted into Transaction documents. In this case too, as in the Planning of payments, for the documents that will result from the payment orders, the document type is specified in company parameter “Payment planning process” = 16 (Doc type for automatic creation of “deposits”).

2. Miscellaneous improvements

• On the “Documents” page in the Trade account contracts, an improvement was made so that the user can view the sales-expense documents for the cases of supplier contracts.

• In the "Data type history log" view, for better management of data packets, parameter "Consumption” was added, with available values: All, No, Yes.

• In the customer search, in Retail, the customer's mobile number has been added to the results.

• The 2-CARD property plan has been augmented. Fixed an issue that would restore the line type of the liquidity account to value Actual, when the liquidity account is not related to a card transaction.

• Improved the search time when searching for a customer by their phone number, in the “Select customer” action of retail.

• Support for saving relevant documents in vouchers.

3. Horizontal functionality

Image export

In the export view or the Excel Bit, it's now possible to properly export photos. For this reason, in the “Advanced data export” dialog that appears on the views and Bits toolbar, the "Export images” flag was added, which is the default only in the case of export into Excel. If, for example, in product view: “Item catalogue with photos”, the user selects export of the item photos, the result will be as follows: 

In the case of a large volume of photo data, it is recommended to de-select the flag, to avoid long delays and a time burden in exporting to excel.

Improved the "Advanced data export" screen used in views and Bits to export results in various formats (xls, xml, ascii, etc.), to give it the look & feel of series 5.

Email delivery

In this version, the necessary implementation was made to support email delivery via Gmail through the application, after changes made by Google in the certification method. 

In particular, the classic authentication by username and password has ceased to operate and now, following modern certification methods, a dialog with multi-factor authentication (MFA) is displayed.

More specifically, the following changes have been made:

1. Added company parameter ES_MAIL_CLIENT_info_FILE

2. In the Communication Profile ClientInfoFile field has been added

3. In the options of field Delivery method (Send_Mail_Service) of the Communication Profile, such as with Office 365, two new delivery methods have been added, via Gmail (Server) and Gmail (Client).
   
   

Gmail (Server)

A new email delivery method via Gmail. It utilizes the open-source MimeKit and Google.Api libraries that run on .NET Framework 4.8. The email is sent directly via the Gmail API. It is mainly used for server-side deliveries where UI usage and thus dialog automation is not permitted. However, it may also be used in deliveries via client. Implemented 2-legged OAuth flow (2LA) for server-to-server communication.

Google’s requirements to support this flow are as follows:

1. Google Workspace 

2. App with access to Gmail API

3. Service account with domain-wide access for the app

4. Client secret for the app

The app can send emails as a service. The user used for the delivery is the sender of the email. This means that an adapter can send with any user, as long as the appropriate permissions have been given to the app by the admin.

Be cautious when using client-side. The app has the permission to send via any user, which raises security issues. It should be used only in server-side or highly controlled environments.

Gmail (Client)

A new email delivery method via Gmail. It utilizes the open-source MimeKit and Google.Apis libraries that run on .NET Framework 4.8. The email is sent directly via the Gmail API. It is only used for deliveries from clients that allow the use of UI and thus the display of an authorization dialog. Using it in the EAS with an exception and an appropriate deterrent message is not allowed. However, the caller should make sure they can display UI.

Implemented 3-legged OAuth flow (3LA) for client-to-server communication. Requires a specified tenant id and client id. The certification process will display an Oauth2/MFA dialog to the user to, log into their company account. 

Google’s requirements to support this flow are as follows:

1. Google Workspace 

2. App with access to Gmail API

3. Client secret for the app

The app sends emails on behalf of the logged-in user, who is also the sender of the email.

App - Create

Assuming that there is already an active Google Workspace: 

Go to Google Cloud Console and select or create a new Project. 

Create a new Application (app) and set up the consent screen / branding. Pay attention to the Audience type. You will be asked to select the accounts your app is addressing. 

• If you select External, then the app must pass a review from Google, as it addresses a wide audience and accounts beyond the company Workspace. 

• If you select Internal, then you do not need a review, as it addresses accounts that belong to the company Workspace. It’s you who takes responsibility for security. (default).
  
  

If you do not have a workspace and would like to use only the client-side delivery, then you can specify audience type “External” and publish status “Testing”. In this way, the app is in testing mode and does not need review. However, there are some limitations. For example, you have to indicate which users will use the app. In addition, there is a limit to the number of emails sent. 

Then, you need to activate the Gmail API for the app, in order to give access to gmail services. In addition, you need to set the scope “gmail.send” and “gmail.readonly” for the app (data access). 

App – Settings for client-side delivery

Create an “OAuth 2.0 Client ID” for the app and select application type “Desktop App.” The process will create the Client ID and Client Secret needed to implement 3LA. 

At this point, you can choose to save the elements to a json file. Place this file in a EBS directory synchronized to the terminals. Then, enter the relative path in the ClientInfoFile field of the communication profile, or in the corresponding company parameter, e.g. CSConfig\GmailClientInfo.json. 

Alternatively, you can copy/paste the client id and secret in the corresponding fields of the communication profile, or in the respective company parameters. 

App – Settings for server-side delivery

Create a Service Account. Write down the OAuth Client ID generated from the process, as you will need it below.

Then, create a Key for the Service Account. Save the Service Account client information to a json file. Then, enter the relative path in the ClientInfoFile field of the communication profile, or in the corresponding company parameter, e.g. ESNoSync\GmailServiceAccountInfo.json. 

Using the Google Admin Console, set up the “Domain-wide Access Delegation” for the app. Use the OAuth Client ID provided to you when creating the Service account. Finally, authorize score https://mail.google.com/.

Attention: Due to the domain-wide access deletion, the service account has permission to send emails via any account. Be very careful to avoid downloading the info json when synchronizing terminals. Make sure that you place it in a server folder that is not synchronized, like ESNoSync.

4. Specific improvements for the Romanian version

Closure of income and expenditure

A new scroller, accessible from the Accounting > Period-end closing processes > Income and expenses closing menu, has been realized to improve the procedure of closing income and expenses. 

A new journal code - CLVC - will be defined in the menu Tools & Configuration > Customize... > Accounting > Journals.

The accounts will be set as asset, liability or bifunctional (Gross) on all accounting account cards in the "Nature" field.

The scroller will consider the following:

• If an account is active or is bifunctional and has only debit turnover: it will close on credit

• If an account is passive or bifunctional and has only credit turnover: it will be closed on debit

• If an account is bifunctional and has both debit and credit turnover: it will close on balance.

The automation has a 121* account as a parameter to cover the existence of different analytics in different years or for other reasons.

The generated accounting notes will be generated with the last day of the selected period.

Additional instructions for data maintenance

The Licensing, Upgrades, Hotfixes procedure has been completed with a Data Maintenance chapter which recommends that backup and database optimization plans be established from the installation.

Submitting invoices issued to individuals in RO to e-Factura

From 01.01.2025 it is mandatory to send to ANAF in the e-Factura system the invoices issued to individuals in Romania, which implies the specific filling in the xml structure of the invoices issued, of two fields - BT-47 (Identifier for a legally registered Buyer) and BT-48 (Buyer Tax Identifier) - by which they are identified.

EBS-RO, improving documentation and translations

For more info, browse this site.
We constantly update it with instructions and documentation in Romanian.

We also constantly update and correct all translation or localization errors, so that the application will better serve the Romanian users.

Commercial management 

Documents

• Various problems encountered with documents that have the SAVE_WITHOUT_DELTADS attribute where fixed. In detail, these were manifested:

  • When changing the progression step, the step on the table of the Document Catalogue did not change.

  • When the evolution step was significantly changed, the movements of the documents were deleted.

  • When changing the quantity in a line of the document and moving to the next line and when using custom automation that changes fields in the lines, the document movements were deleted.

• Fixed a problem when creating a new batch on the line of the document when the Batch Code field is filled before the item is defined on the line.
  Specifically, an error occurs when saving the document. If the item had been declared first and then the batch, it would work just fine.

• Fixed a problem that occurred when triggering certain trade policy conditions and when there are concurrent conditions looking at different things.

• Fixed an issue in the entry of LMS documents - accounting transfer of fixed assets.
  The problem occurred when the depreciable acquisition of the fixed asset was in a closed financial year. The correction concerns the 4-LMG property plan.

• It fixed an issue that appeared after the Cash Flow management was changed in version 5.9.0.0. A problem occurred with changing the Cash Flow transaction documents that are involved in its update. Specifically, if there is an advance (AEP/APM) on a Sales/Purchase order respectively and this Order was moved on to a subsequent confirmation/shipment/receipt type document then the advance document was not allowed to be changed. This prohibition was deemed critical in the case of the document values - to maintain the correctness of the cash flow - but for the other document fields it was too strict. For this reason, from this version onwards, their modification is allowed except for the values.

Reports

• In the Analytical Ledger tab within the Accounting Account, the titles of the Progressive Debit and Progressive Credit columns have been updated.

• In OLAP "Profitability by Item Category - Group" a correction was made to the cost of goods sold calculation where there were different rows in the item journals updating turnover and cost of goods sold.

• A delay problem in the 'Comparison of document quantities' view has been resolved.

• Fixed an error when opening the 'Means of transport' view.

• An error was corrected when opening the 'Checking the sufficiency of materials for the execution of orders' view.

• In the "360 image" dashboard within the trader's page the information in "Open Value Analysis" will be displayed in English.

• Improved the speed of execution of the "Uncounted items in ASD with balance" view.

• Improved the speed of execution of the official movement tab view in the customs warehouse circuit when a tax code of the item is defined.

Procedures

• A change was made when creating the payment file for Eurobank so that the file starts with the SWIFT prefix as dictated by the bank itself.

• Fixed an issue in the calculation of the balance on Physical Inventory Forms which either result from registration or are created by the count finalization process when the item has an alternative service unit of measure.

• Fixed an issue in the interface with the Eurobank API.

• In the payment file export process to banks, a check was added to ensure that beneficiary accounts have a complete Swift code (BIC).

Miscellaneous

• When searching for a person in Task, only active customers are now displayed.

• Renamed the "Delivery Plans" tab to "Visit Plans" in Sales > Transaction > Distribution Details to be the same as the corresponding Addresses to Customer page.

• Fixed an error in the Alternate Vendors of an inventory item where on New with copy and when the item had several Alternate Vendors and one of them as the base it created an additional record with that vendor without item coding.

• Since this release, the "Taxable" field in the transactor is managed more correctly. Specifically, it was added to the supplier and creditor forms since it already existed in the customer and debtor forms. The field is activated for new traders who are legal entities, have filled in the VAT number, have VAT Status = Normal or Reduced and have CIFO Status = Accountable.

Related cases:
ΥΠΘ_SUP-199533, PS-107943, PS-108045, PS-107781, ΥΠΘ_SUP-199230, PS-75685, PS-77092, ΥΠΘ_SUP-132385, PS-96864, ΥΠΘ_SUP-196095, PS-74832, PS-88084, PS-96856, PS-105898, PS-106308, PS-106308, PS-106485, PS-107485, PS-58485, PS-58488, PS-58484, PS-588446, PS-69310, ΥΠΘ_SUP-120052, PS-82555, PS-107213, ΥΠΘ_SUP-123650, ΥΠΘ_SUP-161531, ΥΠΘ_SUP-194785, ΥΠΘ_SUP-194369, PS-99617, PS-104440, PS-105328, ΥΠΘ_SUP-168075, ΥΠΘ_SUP-193713, PS-106100, ΥΠΘ_SUP-199767, PS-108419, PS-107877, QA-09280, PS-101908

Bug fixes specific to the Romanian version

• Corrected a couple of untranslated labels in the fixed assets module.

• Solved a conversion error on non-deductible depreciation.

Related cases:

#1094236, #1095812