EXP-RO01-4.0.26.1
Entersoft Expert®
Περιεχόμενα
- 1 New Features & Functionality (Outline)
- 2 Entersoft ERP
- 3 Entersoft framework
- 4 Appendix
New Features & Functionality (Outline)
This document aims to report the new features and extensions of Expert Version 4.0.26.1. First, the newly added functionality and features are briefly listed and, then, a detailed presentation follows. User guidelines and examples are provided where necessary.
Entersoft ERP
- New functionality and features have been added to Shipping Plans
- New functionality for calculating Commissions based on Collections
- Supplier and Customer down-payments
- Intrastat returns
Entersoft Framework
- New actions in automations for saving data to ASCII and Excel files.
Entersoft ERP
Invoicing policy
Shipping plans
A series of improvements and extensions have been included in the Shipping Plans functionality to maximize the flexibility when designing scenarios for calculating the shipping costs.
A fundamental change is that many different calculation scenarios can be included into the same Shipping Plan. Each calculation scenario is to be selected based on the values of a series of document fields. For example, the same Shipping Plan may include different calculation scenarios depending on the combination of the transporter – recipient, or any other combination of available attributes. In any case, it is required to define the Delivery Geo zone.
In order to support the above described change, the UI Form of Shipping Plans has been adjusted. The grid where the scales are defined henceforth includes a new hierarchical level where the user may define the attribute values that denote the scale defined on the second level. The definition of the attributes is optional.
The attributes that can be used for defining the calculation scales are:
- GZ Group
- GZ Category
- Transporter
- Recipient
- Recipient Group
- Recipient Category
- Sender
- Sender Group
- Sender Category
- Delivery address type
When using a Shipping Plan that includes many alternative calculation scenarios, then the scenario that will be selected is, evidently, the one that has the same first level attributes with the document. If more than one alternatives are selectable then the system will choose to use the one that is most relevant (i.e. has the most attributes in common).
| In order to facilitate the registration of the various calculation scenarios in the context of a shipping plan, it is recommended that you use the “COPY” tool, which is available on the toolbar. |
New fields
- The check box Fixed charges has been added to the Shipping Plan lines (i.e. to the scale). When activated, then the shipping costs on the line will be accounted, as it was the case until now. When deactivated, then the value on the scale line is accounted as the value per unit and the calculation of shipping costs depends on the quantity multiplied by the value on the scale line. This way, the system will cover cases when shipping costs depend e.g. on the weight of the package and are calculated per shipment kilogram rather than the entire shipment weight.
- The check box Progressive scale has been added to the Shipping Plan header. When activated then the calculation of the shipping costs takes into account not only the scale line that corresponds to the shipment quantity, but all of the scale lines previous to that and, therefore, the calculation of the shipping cost is gradual/progressive.
Example: Let’s assume the following scale:
| From quantity | Value | Fixed charges |
|---|---|---|
| 7 | yes | |
| 25 | 2 | no |
| 30 | 1 | no |
| 100 | 0,5 | no |
|
7 5*2 + 50*1 |
|---|
| 67 € |
And the shipment weight is 50. Then the shipment cost would be =
Additionally…
Up to the previous EBS versions, the application would determine which shipping plan is to be applied simply through the corresponding field on the shipping method. Henceforth, the shipping plan is also available in Pricelists and Document Headers. This means that when a pricelist is selected on a document’s header or a shipping method that contains a shipping plan, then this plan will be the default shipping plan on the new, corresponding field of the document.
Retroactive discounts profiles
It is henceforth possible to use lists of stock items instead of criteria in retroactive discounts profiles for calculating the returns. In order to activate this alternative, you need first to make the column visible (use the: “Add/remove columns”). Next, select the desired list of stock items. If a list of items is selected, then it is not possible to define criteria too.
Additionally, it is now possible to schedule the calculation of retroactive discounts. The functionality is available under the scheduled tasks functionality (menu: Tools and Configuration / Schedule / Scheduled Tasks) and the view / automation that need to be selected is displayed in the image that follows:
Invoicing policies
- The invoicing policy actions for assigning a price to a document now include functionality for assigning a value to the fields Pricelist and Shipping plan.
- The available info for defining an invoicing policy henceforth includes all the User Defined Fields (UDFs) of all types (string, check boxes, dates, tables, and numeric).
- The invoicing policy UI Form is henceforth customizable; use the UI Form Designer to adjust it to specific implementation requirements.
- New template conditions have been added.
- Based on a Person’s grouping characteristic. This allows you to select as a condition the value of the category or the group of the selected Person on a Document
- Based on the Measurement Unit of the Item Line
- Based on the Measurement Unit and a quantity field of the Item line
- The address type has been added to the template conditions of Delivery address and Loading address
Readjustment of Prices
The fields that can be used as a base for the readjustment of a price henceforth include price markup 1, 2 and 3
Pricelists
The pricelist lines have been enriched with the following two: Delivery address type and Loading address type.
Commissions based on Collections
A new report that is available on the menu: ‘Sales / Check results και ‘Financials / Collections and Payments’. The report provides information on the following:
- Do salesmen collect accurately and in-time? Which invoices?
- And, moreover, how much accurately? What is the excess?
- Which customers can be pursued in order to attain timely payments (payments their commission depends on)?
- What are the commission amounts that must be paid to salesmen based on the accurately collected amounts?
The results of the report are actually matching entries based on which the application calculates the collected amount and the level of accuracy compared to the aging of the claim. Double mouse click opens the invoice. Any matching to credit notes or corrective entries other than collections is not accounted. Besides collections, the report takes into account any collections that took place in the context of the sales transactions e.g. in case of Retail Receipts or Invoices paid in cash. Whether claims that have been paid in full are to be listed too or not (chiefly for informative purposes), depends on the value of the criterion: “Settled”.
Commissions can be calculated per Salesman (of each invoice) or per Collector (of each settlement document). This depends on the criterion Commission based on. In order to calculate the commission based on collectors, it is required to register for each collector (defined on a collection document) a Salesperson entry and to define the commission %.
The ‘final amount based on return calculation’ and, therefore, the ‘commission to be returned’ are equalt to zero only when no excess has occurred. The excess days are calculated according to the due dates of the sales and the collection (to be paid until and available on) and if excess occurs then the color indicates it, while the commission becomes equal to zero.
The functionality of the reports assumes that:
- Commissions are calculated as percentages % (defined on the Salesperson register, field: % base commission ") and Commission profiles (used for the automatic calculation of the commission in relation to the turnover of sales invoices, depending on customers and stock items) are not accounted.
- The salesperson of each sales document is only one – it does not handle cases of other sales person per document line.
- The automation Return Commission, available on the report, issues an Estimated Expenses document (of type CPR) defined in the corresponding company parameter, using the expense of the other company parameter.
The Trade Account is the Creditor of each Sales Person (i.e. the Creditor that is associated with the same Person as the Sales Person). This way the commission payments can be efficiently reviewed through the item register and, if desired, standard expense receipts can be issued (that will be posted to accounting, update the liabilities etc.), having of coursed cancelled this internal note before.
Document management
- The dialogue for editing the dimension analysis lines now includes totals per column additionally to totals per lines.
- The automatic synchronization of the due date of liquidity accounts with the date an Adjustment document was issued on, has been activated, when the document date changes.
- Control Policies for Stock items henceforth include additional balance checks for:
- Actual stock minus frozen stock
- Available stock minus frozen stock
- Actual stock minus confirmed orders minus frozen stock
- Available stock minus confirmed orders minus frozen stock
Budgeting
- The UI form of Budget Sheets is now dynamic and can be customized to meet specific implementation requirements.
- Saving the layout of the dynamic cube that presents the Budget Results now applies to all budget sheets of the same budget sheet profile and not to each sheet separately.
- The UI form of Budget Sheets now includes functionality for registering and editing comments and notes.
- It is now possible to Schedule the creation of Budget Forecasts through the corresponding button (i.e. Scheduling) on the UI Form of budget forecasts creation.
Financial
Suppliers’ down-payments
The workflow of the down-payments for the suppliers is now available. That flow differs from the customers’ flow significantly. In the customers’ case, any advance payment (money collection) leads to collection of VAT, therefore the company must issue an Advanced Payment Invoice so that the State to collect the prorated VAT amount. On the contrary, in the suppliers’ case, there is no need for issuing of an Advanced Payments Invoice, since the VAT it is not subject of collection for the State. However, the flow is subject of different accounting postings than a regular purchase transaction. In an indicative flow the following entries may exists:
- Money payment. The advance payment document updates the accounting in specialized trade account ledgers.
| Transaction | Account | Title | Debit | Credit |
|---|---|---|---|---|
|
Bank Statement or Cash payment |
5121 5311 |
Bank account Cash account |
Total value | |
|
4091 4092 |
Payable advance payment of Inventory Payable advance payment of Expenses |
Total value |
- Purchase/expense invoice.
The purchase or expense invoice associated to an advance payment no differs to any other invoice.
| Transaction | Account | Title | Debit | Credit |
|---|---|---|---|---|
| Purchase invoice | 401 | Supplier account | Total value | |
| 301 | Goods | Net Value | ||
| 4426 | VAT | VAT value |
- Trade account’s adjustment entry. Once the purchase invoice exists, the advance payment entry must be reversed. The clearance entry aims the transferring of the value which had be charged to the special trade account’s ledger (4091 or 4092) to the main supplier account’s ledger (401 or 404).
| Transaction | Account | Title | Debit | Credit |
|---|---|---|---|---|
| Clearance entry |
4091 4092 |
Payable advance payment of Inventory Payable advance payment of Expenses |
Total value | |
| 401 | Supplier account | Total value |
Money payment
For the money payment is used the new document type APF- Plată în avans (de la furnizori). By using the button “Advance payment type” the user selects the “reason” for the payment. It highlighted that the type of payment (goods/services) determinates the posting to the accounting.
Closing the down-payments
As soon as the supplier delivers the goods or provides the services, the advance payment entry must be reversed. Through the automation “Settle advance payment” the user may create the trade account’s adjustment entry using the new document type AFA - Inchidere avansuri. Once the user issues the purchase document, the automation is available.
The list displays the open payment documents, indicating the type of each payment:
The automation dialogue displays the following information:
- Documents. The payments documents selected in the previous step
- Date. As default date is proposed the issue date of the purchase invoice
- Show document. By activating this option, the target document will open for review or further editing.
Is highlighted that, if the value of the down-payment document is greater than the value of the purchase document then the down-payment document will be reduced partially, up to the amount of the purchase invoice. In addition, if the user selects more than one down-payment documents the application will reduce them consecutively, up to the value of the purchase document.
The document:
The accounting entry:
The trade account’s adjustment entry is associated to the Down-payment document and to the Purchase document as well.
| The document type which will be used is the type defined in the general parameter “ADVANCE PAYMENTS: Document type for advance payments clearance. |
Advance payment control list
In order to monitor the invoiced down-payments, the view “Advance payment - check list” is now available at Purchases and Procurement\Pick-ups receiving and Purchase invoices. The view presents the open (partially or fully) invoiced down-payments in selected period of time. The second level of the report presents the corresponding Purchase Documents, if the down-payment has been associated to one.
Customers’ down-payments
In the customers’ case, any advance payment (money collection) leads to collection of VAT, therefore the company must issue an Advanced Payment Invoice so that the State to collect the prorated VAT amount. After advance payment invoice there are two methods of handling. In the current version, the “Customers’ down-payments” work-flow has been enhanced so that combines both methods of workflow’s handling. Specifically:
The 1st method
In the first method, the sale invoice includes entire the amount of the sales agreement since the cancellation of the down-payment invoice has been preceded.
The 2nd method
In the second method, the down-payment invoice remains as part of the sales agreement. Consequently, the sales invoice includes negatively the amount of the down-payment invoice in order to meet the remaining amount of the agreement.
The workflow has been adjusted as follows:
Money collection
For the money collection is used the known document type IPB- Incasare plată în avans (de la clienti). In accordance to the supplier flow, by using the button “Advance payment type” the user selects the “reason” for the payment. It highlighted that the type of payment (goods/services) determinates the posting to the accounting.
Invoicing of down-payments
Through the menu option: Sales\Order routing-Invoicing\Not invoiced advance payments you may monitor the amounts that have not been invoiced at the end of each month. Bear in mind that the “open amount” could be smaller than the amount that has been collected initially. The reasons for that could be:
a. The customer had open balance therefore; part of the collected amount has been correlated to this.
b. Part of the order for which the advance payment has been given, was met into the same month and therefore
The automation “Advance payment invoicing”, available into the view (scroller) may proceed to the amounts invoicing.
The application will create for the selected rows separated invoices. The open amount will be split in net and VAT value. For that aim a general item-service will be used.
- Document type. The document type which will be used is the type defined in the general parameter “ADVANCE PAYMENTS: Document type for invoicing Customer advance payments”, the proposed type is FZA - Faktura za avans.
- Document date. The current date is proposed.
- Doc Series. The first series of the document type which is related to the login branch is proposed.
- Item-Down payment. The application displays one or two fields based on the payment type of the selected entries.
- In the field Item – Goods advance payment is proposed the generic item which is linked to the Accounting category that is related to the general parameter: ADVANCE PAYMENTS: Accounting category for Customer advance payments.
- In the field Item – Services advance payment is proposed the generic item which is linked to the Accounting category that is related to the general parameter: ADVANCE PAYMENTS: Accounting category for Customer advance payments regarding provided services.
- Show document. This option is available only in case the selected rows belong to one customer and therefore one invoice will be created. By selecting that option, the new document will be presented for additional editing by the user.
Up to this step the handling of the workflow is similar to both methods.
Cancelling of down-payments & Advance payment clearance
In accordance to the first method, once the company is ready to proceed to the delivery of the goods or services and before sales invoice issuing, the cancellation of the down-payment document must take place. At the same time a clearance entry between the trade account’s ledgers should also take place. That entry aims the transferring of the down-payment’s amount from trade account’s advance payment ledger (e.g. 4190) to the main trade account’s ledger (e.g. 4111).
Both actions are made through the automation “Settle Advance Payment” which is now available in the document type FPA.
The UI form presents the following.
- Document types. As highlighted, the application will produce two documents.
- The document type which will be used for the cancellation is the type defined in the general parameter “ADVANCE PAYMENTS: Document type for cancellation of Customer advance payments”, the proposed type is NCP - Nota de credit (Plată în avans).
- The document type which will be used for the trade account’s clearance entry is the type defined in the general parameter “ADVANCE PAYMENTS: Document type for advance payments clearance”, the proposed type is AFA - AFA - Nota de credit (Plată în avans).
Doc Series. The first series of the document type which is related to the login branch is proposed.
Document date. The current date is proposed.
Show document. By selecting that option, the new document will be presented for additional editing by the user. After saving, the second document will be presented as well.
An indicative workflow is displayed bellow.
The documents:
The accounting entries:
After the abovementioned actions, the user may proceed to the issuing of the regular invoice.
Order’s invoicing & Advance payment clearance
In accordance to the second method, once the company is ready to proceed to the delivery of the goods or services issues the regular sales invoice. At the time of an order’s invoicing related to an advance payment invoice, the user should correlate them. That action can be done through the automation “Settle advance payments” which is available into the Sales documents.
The UI form presents all the fully or partially open advance invoices. After user’s selection, the Generic-Down payment item will be added into the new document as “reverse line”. Bear in mind that in case the actual sales amount is smaller than the selected advance then the user should adjust their value based on the actual sales. In case the actual sale is bigger or even equals to the advance payment, no additional action is required. This action has resulted in the reduction of the invoice total amount up to the amount of the advance.
An indicative workflow is displayed bellow.
The documents:
The accounting entries:
Advance payment control list
We remind that, in order to monitor the invoiced down-payments, the view “Advance payment - check list” is available at Sales\Order routing –Ivnoicing\. The view presents the open (partially or fully) invoiced down-payments in selected period of time. The second level of the report presents the corresponding Sales Documents, if the down-payment has been associated to one.
Generic items
As above-mentioned, the flows use the sub-system of generic items to charges the down-payments and monitor the separated values Net & VAT value. Each one of them must be linked to the relevant accounting category.
| For advance payments associated to Goods | |
|---|---|
| For advance payments associated to Services |
Customization elements
In order to activate the above-presented implementation is essential to proceed to the following actions:
- Re-insert from the ESMasterConfig the document types IPB & FPA by selecting the two lasts options.
Insert from the ESMasterConfing the new document types and the associated field property profiles
Restore the default values of the accounting groups ES.2.TA.0050 & ES.2.TA.0052
General parameters
The following company parameters are related to the Down-payment flows.
Others
- The “Expense provisions” work-flow has been enhanced so that is combined to the Expense Cost Allocation sub-system. Specifically, the “Expense provisions” view (scrollers) now includes entries which have been allocated to cost centers, while the new column “Entry with allocation” indicates that information.
When the generic item that has be used as Provision account closes and the Actual expense is charged, through the automation “Close expense provision”, the user may choose the cost allocation method for the new entry.
As far as the provision account, is highlighted that it will be credited having the exact same data of the initial entry. If the original entry was allocated to the cost centers, then the new entry will be allocated to the same ones.
Concerning the (actual) expense account, the user may or may not choose the direct allocation using the new criterion “Replace profile”.
- When is not selected, the expense entry will follow the default configuration of the generic item.
- When is selected the application will apply the allocation of the original entry on the new entry regardless the default configuration of the generic item.
- The new document attribute FUTURE_EXP_REV has been added. That attribute is associated to the automation “Create Expense Provision” so that the automation will be available from all document types which are linked to it.
- The new document type "ICA -Initializare cheltuieli in avans" has been added. That document must be used exclusively on the data migration process from previous system. The expense provisions must be registered analytically supplier, document and the issue date.
- The new document type BFC - Bon Fiscal has been added. It is used for the fiscal receipts / small expenses. It affects accounting. Updates the VAT Journal. Does not update the Statement D394. Covers the payment and updates the cash flow.
Ιntrastat Returns
New Intrastat processes that supports the submission of all types of statements.
- New. The declaration for a specific month and flow that has not been submitted (is to be transmitted first time for a given reference month and flow)
- Revised. Implies that the economic operator wants to change/correct/add/delete some of the entries of an existing declaration, already sent to INS (this is not necessarily the last declaration, it can be an older declaration)
- Nil. Implies that the economic operator does not have any intra-community exchange during the reference period but it submits a nil declaration so as not to be considered as non-response and receive a fine. That declaration confirms that the economic operator has not forgotten to submit the declaration.
Intrastat info
The information that is included in the Intrastat statement is based on the guidelines by the National Statistical Authority (INS). The process is available under the menu: Financials / End of Period Processes / Intrastat & VIES.
The Intrastat records are originated from:
- Sales/Purchase documents or these can be…
- Manually inserted by the user.
Intrastat records from documents
Invoices, Returns, and Debit/Credit documents that affect values (in case of wrong prices) generate Intrastat records as long as:
- The document type participates in the Intrastat processes.
- The Trade Account VAT Regime is “in EU”
- The Intrastat code of the Inventory Items is defined
| The document types have already been updated, automatically by special application procedures. For further details, go to the Appendix: “Intrastat documents”, at the end of the document. |
Use the menu entry: Update Intrastat from documents in order to create the Intrastat records of the selected period; make sure that you select the apposite Statement Type.
- New (i.e. regular): The process will create records for all documents in the selected fiscal period.
- Revised: The process will re-create records for all documents in the selected fiscal period based on the current data, designated as Revised. In order to proceed to the creation of a revised statement, a regular statement must be found in the same fiscal period.
There are two options for a Revised Statement:
Review: The process will delete the records of the regular statement and will create new revised data
Review without Deleting: The process will create the new “revised” records. At the same time the regular entries will remain untouchable as “historical data”.
Ni: In case of non-existing intercommunity transactions, no intrastat entry will be created by the process. However, the nil statement (file) can be submitted (see section: Computerized INTRASTAT files).
Generating existing Intrastat entries anew
In case of inaccurate/incorrect records, found before the submission of the statement, it is recommended that you delete the entries and create them again (e.g. in case of missing info on the Inventory Item master data, such as the Intrastat Code, or in case of missing info on the documents such as the transportation or the shipping method etc.). This is the safest method that can be applied and it ensures the accuracy of the Intrastat statement.
Manually inserted Intrastat records
The system also supports the manual insertion of original Intrastat records by the user. In this case, the field “Origin” is automatically filled-in with the value “Typing”.
Such entries can be necessary when:
- Errors in system configuration exist and these have been identified after having finalized the fiscal year entries.
- It is required to incorporate information that is originated from sources outside of the Application (e.g. information in a previous fiscal year or in an independent S/W application or in an Excel Spreadsheet. Such info can be imported or typed in the form of cumulative entries (grouped by Trade Account and Intrastat Code)
In order to manually register Intrastat entries, go to the menu Financials / End of Period Processes / Intrastat & VIES / New entry... The UI Form includes fields for all information that needs to be defined in order to ensure the validity and accuracy of such an entry.
Auditing
The statement entries can be audited from the view (scroller) “Summary checklist” where all the necessary information is presented. Entries with missing info are displayed with an indicative color on the corresponding column, in order to facilitate the user in proceeding with the necessary corrections.
The system allows the user to access directly the Intrastat entry and the associated invoice for the user to provide any additional info required. Nevertheless, as highlighted before, the invoice changes do not directly affect the Intrastat entries. In case of changes, make sure the update process is re-executed.
Computerized INTRASTAT files
From the INTRASTAT Delivery & Arrival views, and by selecting the action: “Create Intrastat File” you can proceed with the creation of the computerized files.
There you need to define the desirable directory for the files.
It is underlined that the application will produce the appropriate file based on the statement type and flow. In case of a nil statement, the view (scroller) is displayed with an indicative color in order to emphasize the fact to the user.
The following company parameters associated to the Intrastat files must be filled in.
- Contact person: In that parameter is defined the code of the person who is responsible of the intrastat and the Authorities may contact if needed. It is one of the company’s contacts. It is underlined that the intrastat views (scrollers) do not present data in case the parameter of contact person has not been filled in.
- Intrastat code version: These parameters include information provided by INS. They must reviewed by the user before files creation.
Special cases
Rebate documents
The rebate documents that are not related to goods transfer are not subject of Intrastat exchanges as separated Intrastat entries. Nevertheless, such documents do affect the value of the actual trading by reducing their invoiced and statistical value. Consequently, the rebate documents participate to the fiscal period of the source invoices regardless their issue dates.
In order to ensure that the system takes into account this effect, the following conditions must be in valid.
- It is required to associate such documents to the original trade invoice through the field “Source Document” that is available on the layout of documents of these Types.
- In the Credit note, the stock item is the exact the same stock item which was charged in the source invoice.
Alternatively,
- In the Credit note, the generic item for discount purpose must be associated to the exact same intrastat code as the stock item which was charged in the source invoice. The particular implementation requires creating so many generic items for discount purpose as many distinct Intrastat codes.
Subcontracting
The contribution of Operations with a view a processing under contract (Nature of transaction: code 41-43) and Operations following processing under contracts (Nature of transaction: code 51-53) has now been incorporated. Delivery-Receipt Notes with the abovementioned natures are included in the Intrastat transactions. The Net value is typed-in by the user directly on the Delivery-Receipt Notes. The Statistical value calculation is based on the sum of the Net Value and the Expenses (up to the borders). It is not required to close the Import Folders.
Specifically, the Deliveries Intrastat includes:
- Suppliers’ transactions (Nature of transaction: code 41-43)
- Customers’ transactions (Nature of transaction: code 51-53)
Whereas, the Arrivals Intrastat includes:
- Suppliers’ transactions (Nature of transaction: code 51-53)
- Customers’ transactions (Nature of transaction: code 41-43)
Update Intrastat codes
The Combined Nomenclature (CN8) is subject of change every year. From the menu option Update intrastat codes you may update the intrastat codes based on the current list of INS. The process will insert the new entries and update the existing codes, if need. Concerning the codes which are not valid any more (not included into the current INS’s list), the process will not delete them but it will add in theirs description the prefix “Inactive”. In that way the user may examine them and massively delete them, if desired (menu: Customization/Inventory items/Intrastat codes).
In addition, is highlighted that the process will create the missing measurement units which are associated to the Intrastat codes, using the proposed MU value as code, description & alternative code. It is suggested to visit the measurement units afterwards processing.
Accounting
- Sales VAT Journal & VAT cases - Exempted domestic transactions. In the current version, the Sales VAT Journal has been improved so that displays the exempted sales transactions under art 141,144 and under art 160 in distinct columns in the column set Other Transactions.
For that purpose, the VAT Case table has been enriched as follows:
- the known vat case 3- Scutit (Exempted) is now reformed as 3- Scutit - Art 141,144 (Exempted - Art 141,144)
- the new vat case 9- Scutit - Taxare inversa in conditiile art. 160 has been added
- Statement 394. The statement has been enriched so that includes the domestic reverse transactions under art. 160.
Reports
- The reports Trial Balance and Register by dimension now include the criterion: Item code type.
- The crystal report of Account Statements now includes info about the Ledger Account and the selected date range.
- The Expense Payment menu item (under Collections and Payments) is now obsolete and, henceforth, instead you may use the report Payment Documents (under Collections and Payments too). This report provides a criterion for the Trade Account Type (Suppliers, Creditors, All) and this way by selecting “Creditors” only, the report will list only the expense documents.
- The selection dialogue of Specific tariff on the UI Form of Stock Items now includes the Alternative Description too.
- The new report “Trade accounts with incomplete info” is now available under the menu Financials/Accounting Processes. The report lists any Trade Account missing basic demographic information.
Miscellaneous
Company Parameters
- Company Parameters have been reorganized (have been grouped and renamed more clearly) in order to facilitate the user when searching.
Trade account info
- The new field Mediator has been added to the Customer’s info. The Customer’s mediator will be the default mediator on any customer’s document.
- The new field “Area Description” has been added (as available) to the ZIP Codes file.
Ledger Account Administration
- The Ledger Account UI Form is now dynamic and it can be customized to specific implementation requirements.
Fixed asset administration
- The error messages that may be displayed while executing the Depreciation process have been significantly improved and, now, the fixed asset and the acquisition (for which the issue has occurred) are also listed. For this improvement to be applied you need to import the field property profile ΕS-4-DepreciationItemPositiveValue from Entersoft XML.
Fiscal Year closing
- Fiscal Year closing is now a privilege item.
Additional properties
- Property set lines can now be inactive (new checkbox); when inactive a property set line will not be available to the users for editing.
- The description of Additional properties has been extended and it is now 200 characters longer than before.
- Property set lines have been enriched with the fields: Photo and Not applicable (Yes / No).
Reapply grid filters
A new setting (flag on automations / business rules) for reapplying grid filters is now available; this can be used in Self applied map profiles when, conditionally, new lines are generated. Until now the new lines were listed in the item lines grid (until saving and refreshing the UI Form), without taking into account the layout filter (e.g. the type of the document line). Using this new setting, the visually misplaced lines will be listed where they should.
UI Form Designer and Documents
It is now possible to define which section is (not) visible on document UI forms based on the value of one of the 5 check boxes of the document header.
For example, for an implementation it has been required that the 1st check box of the document’s header is activated based on the conditions that are checked and applied by a Business Rule, or a field property profile. According to the implementation requirement, when the 1st check box is activated then some additional fields need to be displayed for the user to edit. This could mean that all of the additional fields would have to be grouped in a distinct form section and by clicking the
button in the RuleSet property of the section the RuleSet composer would be accessed.
On the left, the existing rule sets are listed and on the right the configuration elements of the selected rule set.
Use the button
, that is available on the Action list of a rule set, to define the condition based on which one of the system actions is to be executed.
Inventory items administration
- New User Defined Fields have been added to the following classification tables of items: Family, Group, Category, and Subcategory. These are: Number 1, 2; Date 1, 2; Comment 1, 2; Flag 1, 2; Table 1, 2.
- The length of the following field has been extended.
- Stock items:
- Description, up to 255 characters
- Alternative description, up to 500 characters
- Detailed description, up to 500 characters
- Catalogue items:
- Description, up to 100 characters
- Alternative description, up to 100 characters
- Stock items:
Entersoft framework
Paste from clipboard
It is now possible to bulk insert records from clipboard to:
- Static data lists. The insert is based on the list entity.
- Visit plans. Based on the person and the account.
Automations
Save to ASCII file
It is now possible to create an ASCII text file using automations. This can be achieved using the new Value Type: multiple text formatting. This allows you to construct a simple template that constitutes of many sections. Each section is based on a table and it can produce some text. When incorporating a detail table, the text will be repeated as many times as the number of the details for which the condition(s) is true.
The result can be stored to Blob variable (e.g. the BlobData in ES00RelatedDocuments) using the new conversion type string to bytes (UTF8).
Finally, the new action save text file can be used to save the text to a text file using the desired codification.
Save to Excel file
A new action is available: Create attached excel and/or save. This action exports the records listed in a view (scroller) to a an excel file.
User privileges
It is henceforth feasible to set any application field as Security item in order to define view/access privileges. When a field is characterized as a Security Item, then it will be listed in the User Privilege Definition system, under the node: “ALL privilege items”. Go to: System administration – DB / Change field behaviour to activate the corresponding check box.
Backup copy of application files
The process Application backup files (customization files) now includes the customization files of Data interchange.
Shortcuts
It is now feasible to save to a file only one selected Group of Shortcuts instead of the entire shortcut list. The contents of the file can be used either to replace an entire shortcut list (Read from file…) or append it to an existing shortcut list (Add from file…).
Appendix
Specifically, the document types that participate in the Intrastat Return are:
| Code | Description |
|---|---|
| FRV | Factura unei vanzari cu amanuntul |
| FRV1 | Chitanta de incasare a unei vanzari cu amanuntul |
| NCR | Nota de credit a unei vanzari cu amanuntul |
| NCR1 | Nota de credit vanzare cu amanuntul |
| AES | Aviz de expeditie - Prestare Servicii |
| AFV | Aviz de expeditie (Fara valoare) |
| FAV | Factura de vanzare (cantitate si valoare) |
| FAV1 | Factura - Aviz de expeditie a marfii |
| FDV | Factura generata de comanda de vanzare |
| NCV | Nota de credit de discount |
| NDA | Discounturi acordate clientitor |
| NDC | Nota de credit generata de comanda de vanzare |
| NDV | Nota de debit (valorica) |
| NKV | Nota de credit (cantitate si valoare) |
| RFV | Nota de intrare si receptie (fara valoare) |
| ART | Aviz de retur (fara asteptarea notei de credit) |
| FAC | Factura de achizitie (cantitativ si valoric) |
| FAI | Factura de achizitie (cantitativ si valoric) |
| FAM | Factura de achizitie Mijloace Fixe (cantitativ si valoric) |
| FIM | Factura de achizitie Mijloace Fixe (cantitativ si valoric) |
| MNC | Nota de credit Mijloace Fixe |
| NAC | Nota de credit generata de un aviz de expeditie |
| NAM | Nota de credit generata de un aviz de expeditie Mijloace Fixe |
| NCA | Nota de credit |
| NCC | Nota de credit (cantitativ si valoric) |
| NCM | Nota de credit Mijloace Fixe (cantitativ si valoric) |
| NFT | Nota de intrare - receptie (fara taxe) |
| NIR | Nota de intrare si receptie |
| NVD | Nota de debit - valoric |