EBS - User Guide EN
EBS Daily processes and Use Cases
- 1 Company Structure
- 2 Basic Entities
- 2.1 Customer
- 2.2 Salesperson
- 2.3 Supplier
- 2.4 Creditor
- 2.5 Debtor
- 2.6 Expenses
- 2.7 Service
- 2.8 Inventory Item
- 2.8.1 Identity
- 2.8.2 Administration
- 2.8.3 Storage
- 2.8.4 Related Items
- 2.8.5 Item prices per variation
- 2.8.6 Control and information data
- 2.8.7 Define Warehouses
- 2.8.8 Update Suppliers
- 2.8.9 Assign Measurement Unit
- 2.8.10 Update Cost Prices
- 2.9 Fixed Assets
- 2.10 Cash & Bank accounts
- 3 Opening balances
- 3.1 Trade accounts opening balances
- 3.2 Warehouse inventory
- 3.3 Fixed assets inventory
- 3.4 Liquidity accounts opening balance
- 3.5 Notes inventory
- 3.6 Accounting opening balances
- 4 Purchases
- 4.1 Suppliers Offers
- 4.2 Order to supplier
- 4.3 Goods Receipt from supplier
- 4.4 Supplier Invoice
- 4.5 Send goods to supplier
- 4.6 Credit Note
- 4.7 Credit discount Notes
- 4.8 Purchases on consignment & clearance
- 4.9 Changes in market prices
- 4.10 Purchases of special categories items
- 4.11 Commercial agreements & claim of rebates
- 5 Expenses
- 5.1 Expense receipt
- 5.2 Services Invoice
- 5.3 Services Credit Note
- 5.4 Self-Dispenses
- 5.5 Rentals
- 5.6 Cars’ expenses
- 5.7 Freelancers’ payments
- 5.8 Expenses with company’s Credit Card
- 5.9 Banking Interest expenses
- 5.10 Payroll
- 5.11 Expenses advanced payments & clearance
- 5.12 Expenses per cost center
- 6 Costing of Imports
- 7 Payments
- 7.1 Cash payment
- 7.2 Remittances to suppliers
- 7.3 Payment with company’s cheque
- 7.4 Transfer of a customer’s cheque to supplier
- 7.5 Replacement of a cheque/note
- 7.6 Expiration of payable Notes
- 7.7 Payment of dividends to shareholders
- 7.8 Payment of taxes & withholdings
- 7.9 Planning of payments
- 8 Sales
- 8.1 Offer to a customer
- 8.2 Sale Order
- 8.2.1 Basic functionality
- 8.2.2 Stock availability
- 8.2.3 Alternative, compatible & accessories
- 8.2.4 Selling combinations of items
- 8.2.5 Discount functionality
- 8.2.6 Gross profit margin – On line cost
- 8.2.7 Corporate dimensions
- 8.2.8 Information during Ordering
- 8.2.9 Mass replacement items in Orders
- 8.3 Stock reservation for customers
- 8.4 Shipping to a customer
- 8.5 Invoicing customers
- 8.6 Customer order of high priority
- 8.7 Sale Order cancellation
- 8.8 Customer sale return
- 8.9 Credit Note
- 8.10 Receipt of a destroyed item from a customer
- 8.11 Returning defective item to the supplier
- 8.12 Selling items of special categories
- 8.13 Cancellation Note
- 8.14 Factoring
- 8.15 Pricelist customization
- 8.15.1 Basic prices
- 8.15.2 Discounts on the basic prices
- 8.15.3 Application of pricelists during sale processes
- 8.16 Global processing of selling prices
- 8.17 Invoicing Policy
- 8.17.1 Infrastructure - model
- 8.17.2 Configuration
- 8.17.3 Examples
- 220.127.116.11 Discounts based on quantity and Item category
- 18.104.22.168 Additional discount due to payment method
- 22.214.171.124 Providing gift due to order quantity
- 126.96.36.199 Charging installation services of particular items
- 188.8.131.52 Charging insurance fees to sales abroad
- 184.108.40.206 Discounts by combining quantity scale of many categories
- 8.18 Sales discounts controlling
- 8.19 Sales and distribution performance indicators
- 9 Retail sale points
- 9.1 Simple retail Sale (intensive)
- 9.2 Retail sale to a particular customer
- 9.3 Payment methods
- 9.4 Goods return and buy options
- 9.5 Electronic signature per receipt
- 9.6 Retail posting process
- 9.7 Cash counting
- 9.8 Store statistics
- 10 Providing Services
- 11 Collection management
- 11.1 Collecting cash
- 11.2 Cash Invoice
- 11.3 Collecting by credit card
- 11.4 Customer deposit in our bank account
- 11.5 Collecting by a customer’s cheque
- 11.6 Collecting by a 3rd party cheque
- 11.7 Transferring Cheques to the bank for guarantee
- 11.8 Repayment of cheques/notes receivable
- 11.9 Replacing a customer’s cheque
- 11.10 Customer’s advance payment
- 11.11 Collection management processes
- 12 Contracts
- 13 Open items monitoring
- 13.1 Forecast of inflows & outflows
- 13.2 Settlement with customers
- 13.2.1 Credit days
- 13.2.2 Matching methods
- 13.2.3 Matching rule
- 13.2.4 Payment method
- 13.2.5 Payment methods per item category
- 13.2.6 Use of dimensions to payment methods
- 13.2.7 Definition of payment method for credit cards
- 13.2.8 Common payment methods for many cash desks
- 13.2.9 Examples of payment methods design
- 13.3 Matching processes
- 13.4 Open balances control
- 14 Credit Control
- 15 Transfers and Inventory Corrections
- 15.1 Physical inventory
- 15.1.1 Register of stock counting in warehouses
- 15.1.2 Corrections and differences recalculation
- 15.1.3 Update of shortages-surpluses
- 15.1.4 Special cases
- 15.2 In-house transfers
- 15.3 Third parties warehouses
- 15.4 Stock replenishment based on shortages
- 15.1 Physical inventory
- 16 Production & Assembly
- 16.1 Bill of material
- 16.2 Assemblage
- 16.3 Production Order
- 16.4 Material adequacy control
- 16.5 Ordering & receiving raw materials
- 16.6 Production – Consumptions update
- 16.7 Production expenses
- 16.8 Outsourcing production
- 16.9 Production through dissolution
- 16.10 Production in Progress
- 16.11 Special production issues
- 16.12 Production costing configuration
- 16.13 Production costing process scenarios
- 16.14 Cost determination process & output
- 16.15 Posting to cost accounting
- 16.16 Production process Indicators
- 17 Stock Valuation
- 17.1 Definitions
- 17.2 Assumptions
- 17.3 Transactions to be taken into consideration
- 17.4 Transactions to be ignored
- 17.5 Stock Valuation Process
- 17.6 Control and results
- 17.7 Management information
- 18 Fixed Assets Life Cycle
- 18.1 Fixed asset receiving
- 18.2 Fixed Asset Invoice
- 18.3 Fixed asset from abroad
- 18.4 Stock asset capitalization
- 18.5 Fixed asset return to supplier
- 18.6 Credit Invoice
- 18.7 Fixed asset cost center alteration
- 18.8 Fixed asset sale
- 18.9 Return of fixed asset sale
- 18.10 Fixed assets depreciations
- 19 Accounting Tasks
- 19.1 Accounting customization
- 19.2 Chart of accounts
- 19.3 Accounting documents
- 19.4 Accounting document Template
- 19.5 Corrective transactions of trade accounts
- 19.6 Accounts of taxes & withholdings
- 19.7 Documents posting
- 19.8 Ledger entries finalization
- 19.9 Fiscal Year Closing
- 19.9.1 Preparation actions
- 19.9.2 General information for the process
- 19.9.3 Α’ Phase of closing
- 19.9.4 B’ Phase of closing
- 19.9.5 Calculation of current balances
- 19.9.6 Official reports
- 19.10 Balance Sheet & results statement
- 19.11 Consolidated reporting
- 19.12 Purging of fiscal years
- 20 Management information tools
The management of system companies is achieved through the main menu:
From the companies list we have access to the company’s management screen. The completion of the company’s necessary identity data, is accomplished in the 1st page:
For each company, is automatically entered a separate “person”.
Attention must be given to the «VAT Regime» field, as it is influenced the Invoicing and Purchases VAT as well as the management of the gross (final) sales prices. If the company has deducted VAT regime, we alter the default value “standard” of the field.
New branch – new warehouse
In the “Addresses” tab-page, we must define:
- The Head office of the company
- The Branches
- The Warehouses
Especially the warehouses (Warehouses) are the «logical» warehouses, even if, from the same «physical» warehouses are served more than one companies or branches. Also, if the company:
- is responsible for repairs of devices-machines
- sends goods or fixed assets for repair to suppliers
- sends goods to exhibitions-demos or sampling
- undertakes transfers for others account
- takes responsibility for the storage of third parties items until their delivery to customers
…probably has the need to monitor Inventory PER THIRD PARTY (person-supplier, customer). For this purpose, it may be defined “logical” warehouses BY Third parties or TO Third parties without being necessary to be opened per position or destination, separate warehouses.
In the “Addresses” tab-page, these registers must be defined, with their data:
|Site identity||The identifier code, the type (grouping field), the description, the address into 2 fields, the postal code, the City, the Area, the District the Telephones and Fax consist the branch or warehouse identity. After the branch new opening, documents series must be opened for this.|
|Status||If a branch becomes “inactive” and the related transactions have been completed, the related documents series will also need to become inactive.|
|Supervisor name||Selection between persons defined as company managers (in ‘Persons/Associates’ tab-page).|
|Branch||Is activated when it is branch|
|VAT Regime||It is suggested the regime of the company, however, a branch may be located to a reduced regime area.|
|Independent||It is activated when it exports independent accounting result (prints and keeps BOOKS to the same branch) and only then. This flag influences the stock valuation process, which ‘runs’ separately for this branch.|
|Accounting Segment||To the parameterization system of the “Accounting post”, this is the method where documents are sent to Accounting, it is used to many «connection accounts» the segment (account grade) «Branch». In this case, the content of this field (from the branch register) will be taken into account.|
|Warehouse||It is activated when it is a warehouse. The main warehouse of a branch is not need to be separately opened but, the address-branch will be also characterized AS a “branch” AND as a “warehouse”. The other warehouses will be separately defined and will be characterized as “warehouses” and the next field will be completed in compulsory.|
|Belongs to the Branch||Selection from all the addresses, characterized as “branches”. The field must be completed to all the independent warehouses (that are in different address) but also to all these that are NOT main warehouses of the main address or of a branch.|
|W.H. from/to third parties||It is activated in the cases mentioned before, in order to define that will be monitored per THIRD PARTY. The inventory (in every fiscal year beginning) for these sites must be defined PER THIRD PARTY. The transits from and to them must be declared with (especially for this reason designed) documents (with “third parties” indication).|
|Not to be valuated||It is activated in warehouses that concern storage for third parties, where the items are NOT in our ownership, such as, a service area. On the other hand, when our goods are found to third parties installations such as, an exhibition area, this field must be inactivated because the items found to this area PARTICIPATE to the stock valuation of the company’s inventories.|
|Automatic activation||If it is activated, during the opening of a new item, this warehouse will be automatically added as an area where the item CAN BE placed.|
|Send priority||It is a priority number, which is used in In-house transfer automatic suggestion (branches and warehouses stock replacement) included to the Inventory sub-system. The areas with higher send priority will be “preferred” for stock items send to other areas having deficiencies.|
|Receipt priority||It works similarly to the previous field. The areas with the higher receipt priority and in the case where inventories are not enough to cover all the deficiencies, will be “preferred” for the coverage of the deficiencies.|
|Default Retail Customer||It is used in Retail receipts, in case we want to differentiate behavior per branch e.g. VAT regime, pricelist etc.|
|Default Expenses Creditor||It is used in Expenses invoices as the default creditor that gives values to fields like usual payment method, bank account by branch area for deposits to the Public Services etc.|
|User defined fields||Numeric fields, code lists, characterizations for free use e.g. categorizations in case of large number of branches.|
One of these addresses is the Main address of the company. This must be completed to the “master address” area, in the 1st page:
The main functional site is the main company installation where stock kept and in most cases, it is identical to the Master address. It is not identical, when the formal master address found to independent site, where there never take place inventory transactions.
Why is this definition necessary? The Stock Valuation process generates some costing transactions (internal accounting notes, necessary for cost reconciliation) in “main functional site”. Thus, if in the above case the costing transactions were created in “Master address”, these would be the only Inventory transactions to this site. This will result to the Master address (which is inactive as to the Inventory) to compulsory appear in the official Inventory trial balance for take total costs and profit/loss. This would be at least paradoxical, whereas with this explicit definition, is avoided.
Alterations to sites
Any alteration after using the branches and warehouses (transactions found) demands much attention.
1st scenario: Usage alteration from Warehouse to Branch
A new “logical” site should be defined, which will be characterized as Branch (and Warehouse) with the same address data.
New document series for the new Site should be created
In-house transfer of the stock must occur from the old to the new site, with the proper reasoning (change of use)
The previous address («warehouse») must become inactive
2nd scenario: Warehouse Transfer
If the transfer concerns the same building or when a Delivery Note is not required, we just may change the Address data on the same register.
If the transfer demands issue of Delivery Note or/and when the warehouse is transferred to a different Branch authority, a new Address must be opened and as with the 1st scenario, all inventories must be transferred and the previous address to become inactive.
3rd scenario: Warehouse inactivation – replacement by another warehouse
The stock must be transferred to the new warehouse
The warehouse must become «inactive»
In documents series where this Warehouse was the “default warehouse”, a replacement must occur with the new warehouse.
Opening fiscal year
In company management screen, in Fiscal Year tab-page can be achieved the opening of a new Fiscal year. The login with a day that does not belong to any of the already defined Fiscal years, is NOT allowed.
In this screen, for each line –Fiscal Year in the middle, are found the data available for control/modification and to the bottom part, there are the Fiscal Periods in which every Fiscal Year is divided.
|Identity||Name, start-date and end-date of the Fiscal Year.|
|Number of periods||It is the number of fiscal periods, where the financial data will kept and must be per 2 greater than the number of “standard” periods (months of the Year). The reason is that the year-beginning transactions as much as year-closing transactions must be kept as separate financial “measures” for many accounting processes.|
|Balance sheet limit||Informative day field e.g. for S.A. companies with 31/12 fiscal year ending, the limit for publish results is 30/04 of the next fiscal year.|
|Basic currency||For the case of transition in different currency (as happened in Greece in 2001)|
|Exchange rate formula||From the basic currency (by default for installations in countries with strong currency, where bank exchange differences are expressed as «1 basic currency = N foreign» as it happens with the Euro) or in basic currency (by default for installations in countries with not a strong currency, where bank exchange differences are expressed as «1 foreign = N basic currencies»|
|Exchange rate differences valuation per period||The system, besides the automatic closing of exchange differences (for all the paid transactions in foreign currencies), provides automatic valuation process of the OPEN claims and liabilities in foreign currency at the END of the FISCAL YEAR for balance sheet reasons. The companies that want this process to be executed also for the END of PERIODS, must activate this setting.|
|Official stock book keeping & Stock cost determination period||In case of an audited Inventory, is defined the number of periods (months) which consist a COSTING PERIOD, that is the WEIGHTING period for which every time the stock valuation process is executed, it will take into consideration analytically the transactions. If you have ANNUAL average weighted stock valuation price, define 12 if you have 12months fiscal year period, that is 14 fiscal periods). The costing period is a CLOSED FISCAL “year” for Inventory costing and it features an ‘audited’ inventory. The definition of this period is not necessarily identical to the time where results are PRINTED, but it depends on the period in which the stock cost and profit are supposed to be DEFINIT. In case of a non-audited inventory, define the number of standard fiscal year periods e.g. 12|
|Fiscal year type||Under-definition||It is the not-yet-activated Fiscal Year. This is the initial value of the field during fiscal year opening. Login to the system is not allowed for a date belonging to an “Under-definition” fiscal year.|
|Open||It is the Fiscal Year in progress, meaning that financial transactions can be inserted and modified within its limits. At least ONE “open” Fiscal Year must always exist in a company’s definition.|
|Closed||It is the Fiscal Year whose the financial facts have been completed and no modifications are allowed to them. The Fiscal Years turn to “closed” automatically by the fiscal year closing process.|
|Historical||It is the Fiscal year with historical data, kept for comparison reasons, and does not have full financial data e.g. it contains only entries and ‘periodics’ (table of monthly totals) or just ‘periodics’, without original “documents”. This data comes up either from a migration of previous system or from the «transfer a fiscal year to historical» process, which possibly occurred for disk space reasons or/and system performance reasons.|
|Company rates||The ‘Pro-Rata rate’, the ‘I.R.R. rate’ (Internal Rate of Return) and the ‘Income Tax Rate’ are informative fields and they are used in reports.|
On this list, for operating Fiscal years, we may see if period closure occurred per sub-system (Accounting, Sales, Purchases, Stock, etc.).
Now, we must change the Fiscal year type into “Open”.
When for instance, the company scheme is changed and one company must get into “clearance”, it is necessary to create Balance Sheet up to a specific date and, for the rest period, to occur a new autonomous Fiscal Year.
If after the limit date there no transactions, the reduction of the fiscal year length is free, the same applies for the increase. The current operation in needed when there are transactions occurred AFTER this limit date.
The functionality is only available for the last Fiscal Year and creates (based on the new ending date) a new Fiscal year having as a start the next day and as an ending the ending of the current Fiscal Year (which can modified later). It is called through the icon and through a confirmation dialog, the redefinition of periods – periodic data is executed.
You must also change the length of the “stock cost determination period”.
New job position
When a new position is created, it may consist a new unit for different sub-systems so, some further actions must occur.
- Opening of a person
- User creation and connection with the person
- Addition of this person to company’s contacts.
- Incorporation to users group or creation of new users group (“job position”). In the 2nd case, the privileges allocation must occur from the beginning and the access to documents series, allowed transitions, task types or further tasks, reports etc, to be controlled. If the position belongs to Accounting Department, the privileges in accounting Journals must be updated. Finally, if there are classified documents, then the access functionality must be examined.
- Opening of resource (for use in CRM tasks) and integration to « communication profile»
- Possible opening of a new Cash liquidity account (if it concerns cash)
- Possible opening new document series (if the terminal-client is new with separate printer). Be aware for matching with the suitable users group and a new Cash account as “automatic payment account” (if it is about a new transaction position with customers).
- In the case of a Retail shop and if the salesperson concept is identical with the one of the Cashier, the user must be opened as a salesperson, too. The same “Person” must be connected to both the salesperson and the user.
- If it is about a salesperson, it will possibly need to be assigned some customers groups, to be defined as their “salesperson” (through global modification).
- If it takes responsibility of receipts, some customers groups may need to be assigned for receipts communication and organization and in this case, it will need to be added to the Collectors and to be defined as customers “Collector” through global modification.
The management screen of the entity (SITE) opens immediately, we complete the necessary data, we save and complete.
Another way is through the «Insert» command (or the Insert button) from a list illustrating this kind of entities e.g. Customers, Items etc
Customer is a company trade account, to whom we provide (or we intend to provide) products or services and should be opened even before obtaining “accounting” register, if we want to create, for example, an order of him.
The application is automatically opens for him a «person» where, actually kept all of his “demographic” data (in this unique place). If for instance, a customer becomes customer of another of our companies (to the same system, to the same database), it will be connected with the same “person”, or if he becomes a supplier, his “demographic” data will be the same.
If a customer has many branches, we simply define his branches in the same form. If, however, for each customer branch, the “agreement” is different e.g. the pricelist, the payment method, or if, each branch has different accounting department, different credit limit and so on, we probably need a new, full, different register. In these cases, the best solution is to open a new separate customer for each branch (and with a different “person” so, the main Address will be different).
|General data & Master Address||
These are the customers’ identification data. By completing the Zip Code, data fields as City, Area etc. are automatically completed. If the “mapping services” have been activated, then by typing the “Add/s 1” the position is detected and fields like PC, City, Area, District, Geographical zone are completed (it also appears the icon through which is accomplished the navigation and projection of the particular geographical place through Google maps. Based on the Address data of the current user, options are given for the route projection from the home address/business address to the customer address as well as the projection of the necessary guidelines.
In order the functionality to be activated, in the general parameters, in “mapping services” category, must be defined the “true” value in the «mapping services», «Google» in mapping services server type and an access key to be given which can be easily be provided through the http://code.google.com/apis/maps/signup.html webpage.
By completing the data of the main Address, this Address is added to the “Addresses” sub-page, where, from the presented list, we can add other customer sites. In this area, there are additional available fields e.g. the “VAT regime” can be differentiated per site.
|Card no.||It is given, when a “bonus” card is issued for the customer (loyalty card). It is used for identify the customer during sale.|
|Template||The template is an easy way of ready default values to several data fields, depending on customer category. The templates are designed, through the Parameterization table (Tools).|
|Photo||Through the icon, we can save () a photo (e.g. logo) and through the icon we recall it. We can also display it, in customer lists.|
|Additional information of a physical person||
If the customer is a physical person (the person type is determined by the field next to the code), then, there are additional fields available such as the name and full name separation, the nationality, the sex, the mobile, the calendar etc.
At the same time, next to photo, is found a group of available fields for the “correspondence”, where the «slopes» of the name are automatically generated if already existed to the names table or are inserted by the user and, from this moment, are available for next use.
|VAT Regime||Selection between the values ‘Standard’, ‘Reduced’, ‘In EU’, ‘Outside EU’, ‘Exemption’. It influences the VAT calculation in sales documents.|
|Branch||If it is defined a particular (company) branch to the customer, during customer search, to all documents of this branch, will be sorted to the top whereas in documents of other branches, during search, will be sorted to the bottom. There is not a prohibition for using series of other branches and if required, an additional control must be customized.|
|Properties Set||The properties set enables the presence and management of an additional “sub-page” of additional properties that may be designed through Tools/Customization/Company Parameters/Properties and, even by customer (per customers category) to be DIFFERENT through this “properties” field. Alternatively, one common property-set can be defined for all customers, in company’s parameters in “Additional properties” category.|
|Profession||By selecting profession, to the «Business activity» field is suggested the profession description and it can be differentiated with a more detailed text (which is not formalized through professions code list).|
|Groupings||The group and the category are in reality “person’s” groupings whereas the family is exclusively of the particular customer. This means that if the same person is connected with a supplier, the group and the category will be the same.|
|Salesperson||The salesperson to which the customer is “assigned” will be now suggested to the sales documents, where he can be differentiated per document or/and sold item line.|
|Recommended||The person introduced the customer. By giving part of the name and F3 or Shift-F3 search is accomplished. From the icon we can, through the pop up «internal» menu, insert new person or to see the current.|
It is a multiple choice field with the persons’«interests»:
Which is based on a general parameter for persons management:
Which is selected among different “categories” that have been parametrically defined:
|Reminder||To the text field through the icon we can define a comment that will appear through the customer selection at any trade or cash transaction.|
In this sub-page there are data of accounting nature or related to the internal Accounting department processes (credit control, collection management).
|Opening date||It is automatically completed|
|State reporting group||It is used in Customers Summary Status creation processes.|
|VAT regime||It is the same field also defined to «Identity»|
|Accounting category||It must be selected from the default categories in order the posting of any document to be later feasible. The«Ledger Account» is not used by the default parameterization (the accounting category is used instead) but it can be completed if the posting parameterization is modified and uses it.|
|Currency||If a foreign currency is given, which is the «usual» for a foreign customer, this will be proposed at any transaction. Through reports per currency, we can check the customer balances for any currency.|
|Budget group||It is used to budget sheets as a special grouping element, through which the customers budget can be monitored.|
||It is a «profile» which enables the design of the applications behavior depending on the customer solvency degree. It allows controls and prohibitions of different levels in order to protect the company from bad depts. The concepts, the customization methodology and the functionality are described in a specific chapter of this manual.|
The upper credit limits that we give to the customer. The balance limit is the accounting balance (debit-credit). The trade balance limit is the accounting balance limit plus the unpaid notes permitted value. The balance limit plus own notes is the accounting balance limit plus the unpaid notes permitted value, where it only takes into account the notes that the customer himself issued (and not a third party, e.g. a customer of his). When one of these limits is overcome from the customer and thus we have «credit margin excess», to the documents having the credit control option activated to the document type, the application, if there is a «credit policy reacts according to the settings whereas if it is NOT exist, it reacts depending on the value found to the general parameter (Tools/Customization/General/ Company parameters) in “credit control” category:
||Based on the days of payment delay and based on this interest rate profile (which is customized to Tools/Customization/Financials) which is defined to the customer, the «Interests based on payment delays» report is received and if necessary, a relative debit note is being issued.|
|Credit Days||Give the days of settlement eg. 60 for 2 months payment aggrement. This element is informative, but also used in credit control processes. Additionally, the system generates customer invoices payment forecasts, based on this agreement (after N from issue date) except if there is a specific “payment method” designed and it is applied during Invoicing.|
|Collector||The person responsible for money collection from the customer, is selected between the persons defined as collectors to the Tools/Customization/Finacials. It is used in receivables planning processes.|
Day in month
|In these informative fields, we can define possible restrictions forced by customers’ accounting department for week days or hours appropriate for payments or contacts for the balances agreement.|
The usual matching method of receivables-payments (for the correct update of the «balance aging») is “on account”, that means Fifo by date (each receipt pays the older invoice).
An other option is “based on rule” for special payment processes eg. per project, where the rule is defined to the next field.
With any of the 2 above mentioned options, the matching is automatically occurs on-line while documents are entered.
Finally, we can exlude the matching process in order to only occur by user selection or not at all.
The automatic matching is a default process in order some of the most important system reports to be taken.
||The matching rule allows the method of AUTOMATIC “opening” and “closing” entries connection with different functionalities which allow the user intervention to be avoided or restricted, in order to define which documents are paid from each receipt. The matching rules are defined to the Customization (Tools/Customization/Finacials).|
There are the detail data of customer’s (person) bank accounts. In some cases it may be needed a (returning) amount to be deposited. Then, the definition of the «related company bank account» (from which we transfer money) is usefull.
The «Bank» and the «Account number» are compulsory fields. The banks are defined into Customization (Tools/Customization/Finacials).
In this sub-page we define the trade transaction data with the customer, for example the invoicing and discount policy, possible additional charges, the delivery parameters etc.
|Price range||For the cases of simple prices policy, we can define at inventory items 5 sales prices (wholesale, retail and three other of free use) and a «price range» at customers, that points the one of the 5 item prices that the customers takes. This is taken into account during Sale for the sale price proposal, if there is not a pricelist or other pricing method.|
|Price list||Select a particular pricelist for the customer. See the specific chapter of this manual about setup of pricelists.|
|Pricing group||It is used for customers grouping, where a common pricelist is in force (to which the Pricing group is defined). In this case, during invoicing or sales orders , the proposal of pricelist is based on customer pricing group (if no particular pricelist is defined). If there are more than one pricelists for the customer pricing group, the selection will occur by the user.|
||In invoicing policy we can describe the conditions for providing discounts, offers, gifts, mutually exclusive discounts and offers, conditions of additional charges or bonus points for loyalty cards. See the specific chapter of this manual for configure invoicing policy.|
|% discount||Input the discount percentage, if the customer takes a particular – agreed discount.|
|Payment method||The payment method describes the settlement with the customer (when he pays, in how many installments, when the VAT is paid etc). See the specific chapter for information about setting up payment methods. Some of them may be excluded as options for the particular customer, through Credit control policy customization.|
|Special accounts groups||
When special charges are used, transport, additional taxes or default witholdings eg. in Public sector customers, we can setup special accounts for automatic calculations during invoicing.
Informative field for cases, where there is a default supplier for the items supply ordered by this customer.
|Commission level||It is a customers categorization that participates to the salespersons commissions calculation method. Details as to this customization are found to the specific chapter.|
|Orders priority||Informative field which is used for prioritization of customers, when the stock is not adecuate for the fullfilment of all pending sales orders.|
|Shipping method||It is the default shipping method to the customer. The shipping methods are configured through Customization/ Transaction parameters, where we also define the « Transport type » for the Intrastat report (if exports to the European Union occur).|
|Documents grouping||We define if it will occur «packing» of the documents, i.e. on many delivery notes if the invoicing will be suggested to generate ONE or MANY (one-to-one) documents.|
|Shipper||Selection between the persons that have been defined as “shippers” for the goods delivery to the customer.|
In cases that we do transportations through our own means, we define here the route where we usually incorporate the deliveries of the particular customer. Each route is defined in Customization/ Transaction parameters and it determines the Vehicles, the time, the duration etc.
|Trade delivery data per Site||
For each customer site (address) and each our own Branch (where the transit document is issued) and Bussiness Unit, we can define a particular shipping method, route, shipper, shipper address etc. Additionally, it can be defined a specific salesperson and a collector (as a default).
Finally, ONE from all the customer addresses can be defined as being the default invoicing address and ONE as the default delivery address. These data are inputed in document forms but through this definition of default values, the need for the user intervention can be eliminated.
|Global dimensions||If for the customer are defined particular dimensions values, these will be suggested to the header of all of his documents.|
||In this list, we can define a specific salesperson by Business Unit. If Business Unit is set by ITEMS, then, the default salesperson of each document line (item) is based on this definition, according to the Business Unit of Item line (instead of the proposal of the customer’s salesperson).|
In this sub-page, we define the persons (individuals) that we know in the customer business and the persons (companies) connected with the customer in any way.
- With the icon, the layout switches from a “card” to a “list”
- With the icon, is achieved a new person insertion and a “contact” at the same time, connected to the customer (in “relations’ list” to the bottom part).
- With the icon is achieved the selection from the current persons as a “contact” to the customer.
- With the icon it appears the persons’ management screen of the contact.
To the rest of the contacts’ fields are defined a number of data such as, the position, the relation type with the customer, department etc. One person may constitute a “Contact” for different customers, with separate role each time.
User defined fields
If we need more fields, are provided more static fields of various types (dates, comments, numbers,flags, tables) for free use and customers grouping/print, the name of which is defined in Customization.
It is a number of dynamic fields (this is, not stable in number and not the same for all customers) and they are activated by the field “User preferences set“.
The method of documents management and incorporation is described in the EBS-Intro (Introduction manual).
Control and information data
To the left part of the screen, through the “contents” hierarchical tree, a large number of information connected to the customer, is available (from the time that transactions are taking place). This information provides an overview (360ο view) for the customer (documents, balances, suspensions, opportunities, problems occurred due to the relation etc.:
The statement is the “accounting” statement of the customer’s transactions in various formats.
The unsettled receivables show which invoices in particular, are constitute his open balance whereas the balance justification shows the matching of entries (the way every claim was paid)
The related accounts are the trade accounts related to this customer (e.g. customers of the same group of companies, registers of the customer to other companies). The list shows the basic financial figures. If the customer is ALSO a supplier, it shows his “merged” balance.
The data per period shows his balance progress per month.
In sales data, information is provided that concerns to all trade activities: items/categories that were purchased, items that he has NOT purchased yet, sales prices that are enforced for him, per item or category, and the offers that have been given to him.
In the transactions analysis, we can check his pending orders, his not invoiced yet delivery notes and the unpaid notes.
The Budget vs Actual shows a comparative picture of budgeted and actual turnover per month (in case we have separate budget for this customer).
Other related information are the Projects, the Contracts with the customer, the open tasks , the telephone calls to and from the customer, the sales opportunities and other sales activities (appointments, presentations etc).
In case we provide support services, the information of the customers’ open cases is available, as well as the related tasks and the complaints that we have received from him, also.
The salesperson is an employee of the company or the external associate who undertakes, forwards, manages a part of the company’s sales. The sales are “credited” to salespersons and for each transaction is being estimated, with various methods, a sales commission value, independently to the way, the conditions and the time is attributed to them.
Through the «Link to person» setting, the application automatically opens for him one “person” where actually kept all of his “demographic” data. If for instance, the salesperson is external associate and we open him as creditor in order to accept Service Provision Notes from him, the linked “person” will be the same. The same thing will happen if the salesperson is our representative, thus, in order to issue an invoice (suppose that he invoices the final customers) we will also open him as a customer and we will connect him with the same “person”. The salesperson can be also a system user. We make sure that everywhere the SAME PERSON corresponds.
|% base commission & commission profile||The base commission is expressed in % on the (net) turnover and the commission profile (which is configured in Tools/Customization/Salesperson) determines which amount of the base commission will be calculated for each item-customer combination.|
|Incorporation & jurisdiction data||We define the branch and the Commercial unit that he belongs as well as the business sector, activity etc. if he exclusively occupies with some of these.|
||Depending on the identification to the customers “salespersons per business unit”, here, the same information is defined, from the salespersons side. By activating the “replacement of original salespersons” the customers are updated at the same time.|
User defined fields
If we need more fields, are provided static fields of various types (dates, comments, numbers, tables) for free use, the name of which is defined to the Customization.
The supplier is a trade account of the company, from whom we are supplied goods, fixed assets, row materials or any “incorporated” items and he must be opened even before obtaining accounting status (accounting “register”) if we want to insert e.g. an order to him.
His data management, the fields and entities meaning which are available to his management screen, are common or respective to these of the customer. Here we examine the parts, where management is differentiated.
- Anytime we refer to supplier «balance» e.g. to credit limits or to “positive” balance to the statements, as the usual sign, is always consider to be the credit (in contrary to the customer, where is consider to be the debit). Thus, when we purchase, the supplier is credited and when he has a credit balance, it is regarded as a “positive” (expected sign) balance. The debit balance is regarded as negative (when he owes to us).
- The supplier’s bank accounts per bank and the “related company bank accounts” from which we deposit to, are of great significance, as they are used to the “Planning of payments” and automated Payment orders which are sent to the banks. It is very useful to activate this functionality, in order to save time and to minimize the errors.
- Some information are only presented to the suppliers’ management screen:
|Usual settlement||We choose note, bank transfer or cash. This information is used for the payment method proposal to the Planning of payments.|
|Supervisor||The supervisor of the supplier account monitoring (procurements supervisor).|
|Purchases in consignment||We define whether we purchase with the consignment regime from the particular supplier. This process is supported by some dispatch documents and for those goods that will be sold, it occurs “clearance” per period and payment to the supplier based on this “clearance”. The process is described at the specific chapter of this manual.|
The creditor is a trade account of the company who provides us services or any other products we monitor to the Accounting as “expenses” e.g. consumables, fixed assets spare parts, advertising material, packages materials etc. Actually, creditors are all the payable accounts, but in this sub-ledger monitored all the other payables accounts (except suppliers) e.g. company’s personnel, external associates, owners of rent buildings etc.
The meaning and handling of fields and entities available to the creditor’s management screen, are common or respective to those of the supplier. You may be informed from that chapter.
The screen differs, as the person “existence” is not compulsory to the system, thus the sub-pages are differently constructed.
If the creditor does not participate to the “State Summary Agency Report“, you may not open a “person.”
The suggested value to the “Link to person” field is YES and this is a strong recommendation for the following reasons:
- The services that he provides may will be incorporated to the Summary Statements in the future and then, the creditor’s identity data (required for the report) will not exist. As is already known, the ONLY part of the system keeping identity information, addresses, etc. is the Persons.
- It is possible to activate expenses payments through Bank Accounts and then, data that only kept to the Persons will be required, in order the payment orders to occur electronically.
It is recommended to be separately opened and not as Suppliers for accounting agreement reasons, but also for making entries easiest e.g. in a goods receipt Note or in a Purchase invoice, all the numerous creditors will not be appeared during searching. In accounting, it is correct to be monitored to summary accounts (“Other creditors”).
Debtors are generally all the borrowers of the company, the “receivable” accounts. To the particular sub-ledger monitored all the other debtors, except customers. Debtors are the banks (debited interests), the shareholders (for the processes of capital payment), tenants own property etc.
The meaning of fields and entities available to the debtor’s management screen, are common or respective to those of the creditor. You may be informed from the previous chapter.
They are used in various documents for issue revenues. It is recommended to be separated from the customers for reasons of accounting agreements. In accounting, it is correct to be monitored to summary accounts (“Other debtors”).
Expenses are all the intangible “accounting” items (with value monitoring) that the company needs in order to operate and to create revenues.
The systems’ invitation for the separate opening of the expenses and in the same time the parallel monitoring into Accounting, offers a number of advantages:
- It helps to organize back-office. Each process is designed and illustrated with the appropriate way into the system , in contrary to the “freedom” during issue an Accounting transaction.
- It makes easier the entries from NOT specialized users and restricts the ERRORS, due to strict documents organization , of the predesigned «Post» and application checks It prevents problems in reconciliation, due to primary entries in Accounting.
- It allows expenses monitoring «on credit» where are presented all the real dates of the debts.
- It allows the payment with notes, the issue of computerized checks and a 360 view of Bank Accounts based on valeur.
- It allows automatic calculations e.g. in deposits, interest rates, taxes, issue of royalties, withholding, VAT etc.,
- It allows informative costing and creation of results statement per Project, Sector, Service, Activity
- There are some cases where this is NECESSARY, by abolishing the line between Sub-ledgers and General Ledger, e.g. Costing Folders
- If the Accounting department is external, the Management department takes early information, for the expenses evolution, without delay.
In the pre-configured Data Base, all the expenses that may be used are already opened and the relative configuration of Accounting Posting is ready. Despite these, could select between the three following methodologies for monitoring the expenses in relation to the Chart of accounts:
1st method One by one for all the expenses (except the depreciations)
2nd method Analysis of the expenses and maintaining in Accounting only the compulsory e.g. some of these can be opened per VAT, the training expenses can be opened per category or per site or per training cycle, the rental expenses could be opened per building, floor etc. and the same time, in Chart of Accounts we only open one account per expense type.
3rd method The expenses summarized to items and, during invoicing, input by the user of the specific General Ledger Account every time. You could also make visible the column “comment 5” where the default setup of expense documents places the title of the account.
The expenses monitoring is directly connected with the creditors monitoring. Suggested to open:
- One «general» creditor that will be useful in many cases of expenses in cash or “indifferent” as to the creditor data, who will need to be placed as default in Expenses Receipts.
- One creditor “Wages and salaries” in order to enter the payroll entry (and special –autonomous withholding accounts) in order the Payroll entry to be correctly produced and posted.
- Use of a horizontal dimension for the employees as cost positions through which we will be able to manage various expenses or money deposits per person. Alternatively, each employee could be opened as a creditor.
- Opening of the debit interests as “expenses” and the credit interests as “services” and for each Bank, a creditor for issuing debit interests and a debtor for issuing the credit interests.
User defined fields
If we need more fields, are provided some static fields of various types (dates, comments, numbers, flags, tables) for free use and grouping/print of the expenses, the name of which is defined to the Customizations.
The method of documents management and incorporation has been described in the EBS-Intro (Introduction manual).
The services (training, maintenance, health, legal, consulting etc.) are provided from the company to customers, creating revenues. In services are opened any other revenue sources such as rent of property, credit interests, extraordinary revenues. As “intangibles” they only have value monitoring. Particularly in Sales, the information of quantity sold is available for specific service types.
|Service profile||The profile is an easy way to give ready default values to fields, depending on services type. The profiles are designed in Customization table (Tools). It is preferable to be created and selected in this field, in order to ensure that e.g. the accounting category, the measurement unit, the groupings will be correctly inputted.|
|Control profile||Through the control profile, documents behavior can be easily parameterized for this type of Services, for instance, the application check for the upper limit of discount permitted during issuing an order or an invoice. The existence of a “% maximum discount” (see below) does not activate any process because the method of using and the “meaning” of documents and thus, the suitability of each application check per case, concern the implementation of each installation. So, in order to define that in sales, a check of the % maximum discount must be active, insert a control profile (code, description etc) and, into it, create a new line with the “Sales” attribute (the attributes are freely designed and, at each document type, one or more attributes are matched), activate the option of maximum discount and finally, select this profile to this field.|
|NPF code||For those having Revenues-Expenses Journals, here is selected the compulsory category of the Unique Ratio of Net Profit for the Revenues journal.|
|Grouping||The family, group, category, sub-category are groupings enabling to take summary information.|
|Wholesale price||When we do not keep pricelists values of the services, we define the sale price and also whether it includes VAT or not. Continuing, to the documents that have been appropriately parameterized (e.g. Services Invoices) in order to present by default the “wholesale price”, this price will be suggested to the user.|
|Retail price||We define the retail sale price and whether it includes VAT or not. Continuing, to the documents that have been appropriately parameterized (e.g. Services Receipt) in order to present by default the “retail price”, this price will be suggested to the user.|
|% discount||If for this service a fixed discount to the initial price is provided, we give it here. When we keep the discount pricelists (per customer), this discount is not possibly used during invoicing. Details concerning the design of pricelists, see to the specific chapter of this manual.|
|Maximum discount permitted||If the users, during invoicing have access to values and discounts, through this field (and with parallel use of “control profile”) we can restrict the discount that can be given, up to a maximum amount (either through value or price reduction or through discount definition from the user).|
|Pricing group||It is useful in pricelists design. Each service can be inserted into a pricelist either DISCRETE or through the “pricing group”. Thus, in a “prices” pricelist we usually insert all services with their sale prices whereas in a “discounts” pricelist, we usually insert the discount for a service category e.g. consulting. Details concerning the design of pricelists, see to the specific chapter of this manual.|
|Standard cost||Since there is not a direct cost allocation to service “items” (they are not “purchased”), we could view sales statistics for the estimated gross profit, if we give at this field the hour (for instance) average standard cost price.|
|Special accounts groups||
When the service «sweeps» a special tax or charge or withholding for public sector etc.:
|Budget group & Calendarization Template||Both used in Budgeting. The budget group is a special grouping, through which the revenues of services monitored to budget. The calendarization template (Tools/Customization/Budgets) allows to split a yearly forecasted amount by month for example. To generate percentages per month in the template, can use the “update from actual data” function e.g. convert last year sales to percentages.|
|Commission level||It is a services categorization that participates to the calculation method of salespersons commissions out of sales. For details concerning this parameterization see the specific chapter.|
|VAT category||For the automatic calculation of the VAT, it is compulsory to select the respective “category”. The services have always standard (23%) VAT and this can take default value through the “profile”.|
|General Ledger Account or Category||To the default parameterization of services posting, the “Accounting category” is used, but the General Ledger Account may also be filled and then, the parameterization could be altered.|
|Measurement unit||Despite the fact that services are intangibles, the measurement unit is necessary for pricing policy to be functional, e.g. price per “hour” for consulting or per “piece” for studies, seminars etc.|
|Relates to state reporting||It is activated if the current service will participate to the values calculation of the Summarized Customers Invoices Statements.|
|Horizontal dimensions||If for the item, will be defined particular dimensions values, these will appear to documents lines as the default and thus will update the related trial balances and statements in order to easier take statistics such as Services per Business Unit, per Activity etc.|
User defined fields
If we need more fields, are provided static fields of various types (dates, comments, numbers, tables) for free use, the name of which is defined to the Customization.
The method of documents management and incorporation is described in the EBS-Intro (Introduction manual).
Inventory items are all the goods (merchandises, products, raw materials etc.) which are purchased or produced and are sold or consumed, for which a full quantitative and value monitoring (register) is required. The items codification to separate codes-registers is usually an accounting subject.
|Basic data||They are the unique determination data of the item. As far as the code is concerned, it can be later changed from the “system administrator” and the system will automatically keep the previous code to the “Multiple codes” (see the “Storage” sub-page), in order to be feasible the search process through any of its codes. It can be defined a particular code format using of grouping data in the item’s code (but also to description) with an automatic produced segment etc. There are 3 fields for the description as well as one main “Barcode” (if a scanner is used). In “storage” sub-page there is a place-holder for define multiple barcodes e.g. for packages reasons, multiple suppliers etc.|
|Basic item||For the NOT “basic” items, it must be defined another “basic” item to which are belong. This enables the mass management of the daily prices based on the changes to basic only (“parent”) items. Details for this functionality, see to the Pricelist chapter.|
|Item profile||The profile is an easy way to give ready default values to fields, depending on items categorization. The profiles are designed in Customization table (Tools). It is preferable to be created and selected in this field, in order to ensure that e.g. the accounting category, the measurement unit, the groupings will be correctly inputted.|
|Type||It is a fixed “accounting” categorization of the items. The type is the default grouping of the items to all the official Inventory Reports to help to the accounting reconciliation. It must not be confused with the field “accounting category” (see below) which is used for the “accounting posting” despite the fact that, as a concept, is usually identical. For the system, the type is a simple grouping field (with fixed values), whereas the accounting category is freely defined and used in Posting process for the ledger accounts detection that need to be updated.|
|Groupings||The family, group, category, and sub-category are items groupings enabling to take summary information. The statistics are usually based on the categorizations and not per item.|
|Instead of filling the 4 previous fields, using this action button, we can select the items’ grouping from a hierarchical tree maximum of 4 levels as many as the basic groupings of the item. The definition of this hierarchy is achieved through the Code lists “group”, “category”, “sub-category”, to which may be defined the ”family”, “group”, “category” where they correspondingly belong (Tools/Customization/Inventory items). The groupings may be independent to each other e.g. the “white kitchen devices” category may be bound to the “Refrigerators”, “Washers” etc. whereas the “fitted kitchen devices” can be independent.|
|Manufacturer||Selection from legal «persons» who have been characterized as «manufacturers»|
|Catalogue item||The application opens automatically (based on the parameterization*) one «catalogue item» for each item (with the code and description of the inventory item), where kept all the relations with other items which may have not been opened yet as “inventory items” or may not be sold by the company e.g. competitive, compatible. The catalogue items are common for all the companies in the system.|
|Season||If the item belongs to particular season, such as, the clothes, shoes models etc. The season is a selection criterion of items in many official statements and statistics. Through the definition of the «Item control profile» (see “Administration” sub-page), it can be checked to the transactions (orders, customers returns etc) in order items of a season different of the current, not to be accepted.|
Single, set, produced.
In sales documents, the contents of the set items are automatically “developed”, are analytically stated a documents “lines”. In contrary, for produced items, during invoicing, their contents are not visible or available. They are produced through an independent procedure, which is not necessarily the same, stable and repetitive. Many times, the raw materials (codes and quantities) are defined by the user, exceeding the components defined in bill of materials. Thus, during sale, the only thing that is defined is the produced item.
It must be defined for the “sets” and for the “produced” items. As far as the produced items are concerned, details for bill of materials see to the specific chapter about Production Process. As far as the “set BOMs” are concerned, after the item is saved, we can insert the related BOM through the main menu (Entities/Inventory/Bill of materials) or through the Customization table (Tools):
|VAT category||For the automatic calculation of the VAT we compulsory select the “category” where the item belongs (standard, reduced, low). In sales, the VAT rate is defined from the combination of the “VAT category” of the item and the customer “VAT Regime” whereas to the purchases, is the “VAT regime” of the company site (branch) that it is taken into account (the VAT value can be given by the user, according to the supplier’s original copy.|
|Ledger account or accounting category||To the default parameterization of Items posting, the “Accounting category” is used, but the General Ledger Account may also be filled and then, the parameterization could be altered.|
|Measurement unit||Here is defined the basic measurement unit of the item in which the stock kept. In “storage” sub-page are defined all the other measurement units or/and item packages. The basic measurement unit is required, in order the item to be functional.|
|Supplier||The main supplier of this Item. Searching may occur through code or name. In “administration" sub-page can be defined additional data as well as other alternative suppliers of the item. If we want during purchases, to compulsory be used the suppliers defined to the item and not any supplier, we activate this check through the “Item control profile”.|
|Codification||It is the item code, in accordance with the supplier codification. In documents, item search can be based on this code.|
This purchase price, is updated from the purchase invoices automatically with the last purchase price (if this option has been activated in the “Item control profile”).
|Wholesale price||It is the basic wholesale sales price of the Item. We define whether it contains VAT or not as well as the %markup (on the cost price). The % markup can be used in various adjustment processes of the sales prices, starting from the cost prices. To the documents (e.g. Offers, Invoices, Credit notes) that have been parameterized as to suggest the “wholesale price”, this price will be suggested to the user, except if the application of a specific pricelist (the customer’s pricelist) leads to another default price.|
|Retail price||We define the sales retail price and whether it includes VAT or not, as well as the retail sale %markup (on the cost price). To the documents (e.g. Retail receipts) that have been parameterized as to suggest the “retail price”, this price will be suggested to the user, except if the application of a specific pricelist leads to another default price.|
They are additional sales prices. If we have a simple scheme of pricing policy, where the customers’ prices zone leads to particular sales prices of the items (one of these 5 prices) then, the 5 prices are defined for all items and, during Invoicing, as soon as the customer is given, the appropriate price zone (1 .. 5) for all item lines is activated. The prerequisite is to select a “sale” price (retail or wholesale) as proposed price in the document type.
The name of these fields can be altered (Customization/General/User defined fields).
|Pricing group||It is useful in pricelists design. Each item can be inserted into a pricelist either DISCRETE or through the “pricing group”. Thus, in a “prices” pricelist we usually insert all items with their sale prices whereas in a “discounts” pricelist, we usually insert the discount for an item category e.g. “items on removal”. See the specific chapter of this manual for details concerning the design of pricelists.|
|% discount||Give here the fixed % discount that provided to the initial price, if there is one. When there are discount pricelists (per customer), this discount is not possibly used during invoicing. See the specific chapter of this manual for details concerning the design of pricelists.|
|Discounts group||Some discounts may be configured through items and customers “categorization” to “special discount accounts”, which can be incorporated to the items for the final value calculation (exclusively to the “Discount 4” field of the lines) or for autonomous lines that do not influence the inventory (cost, turnover), but only the payable amount and the trade account (supplier, customer) turnover. At this field, select this categorization (discount group). See the specific chapter of this manual for details about design discount policy.|
|Maximum discount permitted||If the users, during invoicing, have access to values and discounts, through this field (and parallel use “Item control profile”) we can restrict the given discount up to an upper limit (either through value or price reduction or through discount definition from the user). The 0% cannot be regarded as upper limit, is ignored.|
|Minimum gross profit %||
During sales process, a temporary Cost of goods sold is available, based on which the on-line gross profit is calculated. If the sales value or the discounts lead to limited or negative gross profit, this may be checked and restricted, based on the threshold defined here. The way, the type of transactions and whether or not it will be checked, can be defined into the “item control profile”.
|Commission level||It is a categorization of the items, that participates to the calculation method of the salespersons commissions out of sales. See the specific chapter for details concerning this parameterization.|
|Text field for notes, comments in relation to the item.|
Text field for the typing of a reminder message that we want to be presented to the users after the selection of the particular item. This will occur to those documents that defined to the related setting of the “item control profile”.
|Characteristics||There is a multiple choices button (through the icon) with item characteristics which is supported to a general parameter for items management (respectively with the “preferences” field of the customer), which is selected between various user definable “categories”.|
In this list, are defined the relations with other items. The information kept to the related catalogue items (and not to “stock items”). Consequently, it is available to the other companies if the same items are used and, on the other hand, relations may be defined to items that are not yet stock items e.g. compatible equipment, competitive equivalent items etc. The “Relation types” are defined in Customization/Inventory items/Catalogue items.
The quantity relation is useful in cases where the alternative items are asked during Sales orders or Invoicing INSTEAD of an item that is initially entered but it is in lack. Then, besides the substitution of the item with its alternative item code, it will be also applied the equivalence between quantities e.g. instead of 100ml Item Α 150ml Item Β (relation 1.5).
The price relation is used to the price automatic adjustment of NOT “basic” items when we readjust the prices of the corresponding BASIC (parent) item to which the NOT basic items belong.
The specific relation between the basic and not basic items that belong to them, there is no need to be defined by user every time. It is enough to be correctly defined to the general parameters:
...and thus, will be automatically created.
With the button, the user may make copy of these relations to other (similar) items. In the dialog that appears, he selects the items TO which the relations will be copied and defines which relations (just the marked or all) will be copied.
Item prices per variation
Obviously, it is NOT necessary to insert lines for all dimensions, monitored by the specific item, but ONLY for these dimensions, where the price differentiated. For instance, in an item monitored both in color and size but the value is differentiated ONLY by the size, there are created as many lines as the sizes are (independently to the color).
The “prices per dimension” is an easy way of defining a “pricelist” as the sales prices defined at the 1st items’ sub-page. If you use pricelists, this parameterization is ignored and the pricelist (in which the prices can also be defined per color, size etc) prevails.
User defined fields
If we need more fields, static fields of various types (dates, comments, numbers, and tables) are available for free use, the name of which is defined to the Customization.
The method of documents management and incorporation is described in the EBS Introduction manual.
If the “User preference set” is defined to the administration sub-page (or a general set has been defined for all the items in the general parameters) then, in this page, all supplementary fields/properties of the item are displayed and can be entered.
With the proper parameterization, they can be used in views, cubes or other reports.
Control and information data
To the left section of the item management screen, through the hierarchical tree menu, a wide range of information is available for the current item (movements, costs, pending orders, availability issues, delivery delays etc.:
The Audit view gives the most important information for the item AT A GLANCE: availability, sales & cost prices and the most important 2 years sales data. In 2nd level ()views of pending orders, open offers, delayed deliveries etc.
The Register (in 3 layouts) shows the Item transactions with all supplies and grants, per quantity and value.
The “sales analysis” shows detailed sales data per salesperson, customer, and branch for the selected date range.
In “check cost views” are displayed the items’ Valuation results
In “pending”, check which customers’ orders are not delivered yet, and which suppliers’ orders are expected. There are choices for check items’ returns (from customers, to suppliers). When dimensions monitored, a number of choices allow review the sales data, the various transactions & balances per dimension. If the item is produced, its BOMs are available.
The Budget vs Actual shows a comparative view of budgeted and actual turnover per month (in case we have specific budget entries for this item).
The fixed assets are part of the company assets. This sub-ledger allows the monitoring of fixed assets Registry, their cost, the Depreciations with various methods and any types of cost modifications as well as a large number of informative data, related to the fixed assets.
As fixed assets are considered:
- All the distinct fixed assets
- Additions and extensions to existing fixed assets
Addition or extension is a separate fixed asset, which becomes a “part” of the basic fixed asset, and monitored “under” that, to the same account (fixed assets Registry “line”).
Each Fixed asset becomes active from the time it obtains “Depreciable acquisitions”. Depreciable acquisition is each value (to be depreciated) fixed asset entry e.g. Purchase, Transfer from other fixed asset. Each purchase invoice for instance, is automatically creating a separate Depreciable acquisition. The acquisition costs and the depreciations monitored in Depreciable acquisition level.
|Administrative data||The Supplier, the Country of origination and other informative fields to this section, are of similar use and functionality with those of the inventory item.|
|Allocation profile||Used to distribute depreciations to cost centers, within depreciation documents.|
|Management of serial numbers||We can activate the monitoring of Serial Numbers for fixed assets, in order to know at any moment the position and the history of the transfers of every distinct element. If activated, serial numbers must be determined during transactions, and in order to avoid mistakes, we must define serial numbers as compulsory, through the Control Profile.|
|Accounting data||Define the accounting categories for the basic fixed asset type, the depreciation and depreciated assets, for correct posting. Only the 1st is in use by default parameterization.|
|Other depreciation rules||Besides the basic depreciation rule which concerns to the calculation of accounting (taxable) depreciations, there can be defined additional depreciation rules: an alternative (administrative) depreciations scenario to be monitored independently to the accounting one, and on the other hand, an additional (informative) depreciation rule, which supports variation of the taxable result, according to alternative accounting standards. Through this field, are supported the depreciations based on the International Accounting Standards (IAS).|
|Not in use||Informative field, which is used in various views as a fixed assets selection criterion.|
The user definable fields and the functionality of incorporating documents are working in the way, previously described for the Inventory items.
In the hierarchical list «Contents» on the left, since a Fixed asset is activated and obtains Acquisitions, Transactions etc. the user may view a number of information such as Contracts, Serial numbers list, Transactions register, Data of calculated depreciations, possible inactivation etc.
Cash & Bank accounts
Liquidity accounts are all the accounts of Available Liquidity (Cash Accounts of Head Office and Branches and Company Bank Accounts) as well as the Cash flow forecast accounts, e.g. for Loans, Overdrafts, Credit cards payment installments (for those doing Retail sale) etc. Through these accounts (which consist a separate full sub-ledger) are accomplished the receipts, payments and Cash Flow entries to the system.
For the cash, we must create as many accounts as the different physical and “logic” Cash registers, for which we want to monitor the BALANCE. For instance, if for the same Cash register, there are two removable “drawers” for each user that are separately counted and monitored, two liquidity accounts must be created. If in a branch, part of the daily cash periodically delivered to the branch Supervisor, then, for the “logic” Cash register of the Supervisor, we must create also a separate liquidity account.
For each bank account, we must create a separate Liquidity account, even if these are already analytically opened in Chart of General Ledger Accounts. The reason is that the sub-ledger of Liquidity Accounts provides procedures of notes issue, payment order to banks, deposits by cash transfer with automatic calculation of bank expenses, reconciliation process for Bank statements and future balance forecasts, functionalities out of accounting context.
Finally, it could be opened a specific forecast account for use during Invoicing or other processes that may influence the cash flow, even though it is not required, since the actual balances are differentiated into the system from the forecasted balances. Such an action is possibly enables the conceptual organization of Liquidity Accounts.
An example of Liquidity accounts development from the system parameterization:
Some cash accounts are used by particular branches and other are “common” for all branches. In the application, there is NOT a particular reason of branch determination, since balances kept PER branch, anyway. There are probably other reasons, accounting or organizational, that would lead to the opening of particular accounts per branch. Especially for the Cash accounts, it usually kept a separate register-code per branch.
If a branch defined then, in the documents, and depending on the series branch, the liquidity account of the particular branch appears by default.
|Nature of account||A grouping of the accounts (Code list)|
|Currency||It is suggested the basic currency and is modified when the account is in foreign currency. The balances of the liquidity accounts kept PER currency. This means that we can use the same account for all transactions in any currency, but if the currency is explicit, it is defined here.|
It determines if the currency (defined to the “Currency” field) is compulsory to all transactions. If deactivated, then, the account can be used in transactions of any other currency.
The balances keeping is achieved per “entry” currency and this way (such as in the case of separate accounts per branch) the opening of separate accounts per currency is not compulsory (as far as the system is concerned).
|Balance threshold||Used for define in Cash Registers a minimum balance for current needs, and to set limits to Bank accounts for automatic payments.|
|Ledger account & Accounting category||It is used for posting of cash transactions. In the default parameterization, the “Ledger account” is only used, but the accounting category may also be entered and the parameterization may be altered.|
Since activated, the system will automatically suggest this account during issuing receipts. If we define ONE account of automatic payment per branch (with a particular branch defined) then the automatic system suggestion will depend on the document series (which always belong to a branch).
It can be defined only ONE account as “automatic payment” for the same currency and branch.
Since activated, during issuing forecast entries (such as these that are automatically produced during Invoicing either from the system, or through payment methods application) the particular liquidity account is suggested (which could be the SAME with the one of “automatic payment”). It not allowed defining more than ONE account as “automatic forecast” for the same branch and for the same currency.
For those having transactions in various currencies, there are two alternative methods as far as the keeping of “automatic forecast” liquidity account is concerned:
No forecast entry allowed to be registered in different currency from the one of the transaction (“invoicing”), in order the (correct) calculation of exchange rate differences, to be feasible.
|Issuance of notes||
If selected, will be suggested in all cases of payable notes (cheques) issue, as the “payment account”. It means that is the usual bank account, through which we issue cheques. Of course, during create cheques or other notes, the account may be changed. Only ONE such account can exist for each branch and each currency.
Respectively, during the receipt of receivable cheques/notes, the (liquidity) payment account suggested, is the “Automatic payment” (usually the cash account). The usual process is to transfer them to a Bank, and thus, an overdraft bank account is used.
|Bank data||If it is a bank account, the Bank must be defined (opened in Customization/Liquidity/Banks and each of them consists a “Person” for keep identity data). It must be defined also a Bank Account Number, the bank branch where it has been opened and the special branch code (informative). If available, we fill also the IBAN and SWIFT codes of the account.|
|Valeur days||We define the number of days within which an amount becomes available to the Bank account. As a result, in EACH deposit that occurs to the account, as well as in notes/cheques acquittance to this account, the Cash Flow will be updated by this number of days after the registration date. In cash accounts, it must be zero.|
|User defined fields||If we need more fields, a number of static fields of various types are provided (dates, comments, numbers, flags, tables) for free use, the name of which is defined in Customization.|
Credit cards configuration data
If we accept receipts with credit cards and if to this account, occur deposits of credit cards installments from the Bank (that makes the “clearing”), we must fill the following data:
|Relates to card||
It must be activated in order the receipts processes to be recognized by the system as a special payment method. For instance, in receivables lists there are 3 columns “Cash & Deposits”, “Checks/Notes”, “Credit cards”.
|Max No. of installments||It is defined in order a not acceptable number of installments, not to be typed by mistake during the payment with “credit card” payment method.|
|Cash claims account||It must be defined a “Debtor” to whom the claim will monitored (since the customer that pays with credit card has no balance (open item) as he had paid with cash but, for the company, such a payment is just a “forecast inflow” like the one of postponed cheque). The debtor account (defined here) is updated with the amount of the receivable, in order to occur an accounting reconciliation of the accounts receivables.|
|Credit card rate profile||It must be selected a profile where the withholding calculation method by the bank has parameterized (Customization/Liquidity). The system calculates on-line the withholding value and this amount deducts the amount expected to be deposited by the (clearing) Bank, during the cash flow forecast system update.|
|Credit cards types||
We can monitor the credit cards per “card type” (e.g. Visa, AMEX, MasterCard etc.) and to configure these types so the entry of the payment become easier.
This parameterization is accomplished to Customization table (Liquidity-Credit cards-Card types).
Each credit card type is defined to the following screen:
The option “selectable”, the “position selection” and the “icon” (that is selected from the applications’ icon library or other file), determine the cards’ presentation to the credit card special selection dialog to Retail screens (POS) such as to the scheme:
In the list of the card type definition screen, we define these Banks (to facilitate the user in selecting) and the Bank (liquidity) account (possibly of a different) Bank for “clearing” where transactions will occur (we only open liquidity accounts for the banks that we cooperate and undertake clearing, by defining our account to them, where the installments are deposited).
We also define:
To complete the configuration of credit cards, it should be built suitable payment methods.
Cheques numeration data & cheques print
When payable cheques are issued from the current bank account, we may monitor their numbers and to properly parameterized the system in order to issue & print computerized cheques.
The start period balances in the beginning, when the system is setting up, usually occur by migration process from the prior system, so there is no need for user data-entry.
On the other hand, each Fiscal Year closing process automatically transfers the starting balances to the next fiscal year and thus there would be no need for intervention.
In the following, is described the method of issuing start period balances for each sub-ledger, for cases that it may need intervention or in cases that it will not occur migration, and the initial data are typed manually, based on reports.
Views και Reports of Progressive balance
The starting balances, taken into consideration (to all sub-ledgers reports) are those of the older OPEN fiscal year, in order to take the correct temporary results before Fiscal Year closing, as long as a parallel operation in two sequential fiscal years occurs.
Into Trial balances and Statements, there is the functionality of defining the Fiscal Year from which the starting balances will be taken, because in case of OFFICIAL printing BEFORE the closing, it must be taken into consideration the (possibility of ZERO) starting balances of the specific fiscal year, which the report concerns to.
During Fiscal Year Closing we may inactivate the automatic opening transactions (balances carried forward) for a sub-ledger, indicating so, that it will be created in another way, by user’s responsibility.
If such transactions are created on an open Fiscal while the previous one is still open, this data will NOT be visible to the current balances (e.g. stock availability checks, reports etc) until definite closing occurs. As far as Trial balances, statements etc. are concerned, we must make sure that we select this Fiscal Year (from which the starting balances will be taken) otherwise the starting balances of the older open Fiscal Year will automatically be used.
There are two methods to create year opening transactions:
|If the related document types are more than one, a selection dialog appears, where you can select the appropriate.|
Trade accounts opening balances
Customers & Debtors
Appropriate document type: SOD (Opening receivables (debit balances))
Use this type in the majority of the cases when the opening balance is debit.
If it is a credit balance, use the SOC document (Opening receivables (credit balances)).
Suppliers & Creditors
Appropriate document type: POC (Opening payables (credit balances))
Use this type in the majority of the cases when the opening balance is credit.
If it is a debit balance, use the POD document (Opening payables (debit balances))
The user guidelines and the columns meaning are the same with those for the customers’ opening balances.
We NEVER use the SFD, SFC, PFC, PFD documents. These exclusively used by the Fiscal Year Closing. Their difference is that they do NOT update the Ageing of Accounts Receivable/Payable (open balances) as these are “temporal” data, from the time the system functionality starts so, they are not “copied” as start open balances through years. On the other hand, when the system starts, during first registration of trade accounts balances, these data MUST be updated.
Appropriate document type: IOP (Stock Opening Entry)
Use this type for the initial inventory of the items per value and quantity. Alternatively, it can be used the IOQ (quantity) document to be followed by IOV (value) which must contain exact the SAME quantities. Use of different documents per Warehouse recommended.
The date is not necessarily the Fiscal Year’s start date, but it must belong to the Fiscal year, on which the Inventory concern.
If the inventory concerns Third Parties Warehouses or TO Third Parties then, it is necessary to occur per trade account. Consequently, for the same item, there must be as many lines as the trade accounts on whose behalf (or installations of which) stock found. If this will not happen, the stock PER trade account (the reason to define a Warehouse to concern Third Parties) will be incorrect.
If system commence occurs in the middle of the Fiscal year, then, it must be used the document type:
IIP (Update Inventory based on Trial balance for interim period),
Through this, we can avoid transferring all the Fiscal year transactions up to this time, by just transferring the data (quantities and values of all types) from the last Inventory Trial Balance. The date of this document must be the end of period, and after the results are checked, must CLOSE the fiscal period. Stock valuation process can NOT and must NOT be executed for this or prior period.
It does NOT cover the case of alternative unit monitoring either of warehouse dimensions (color-size etc). In such cases, you must analytically transfer all the transactions history.
Fixed assets inventory
Appropriate document type: FAO (Fixed assets opening acquisition entry)
For the needs of the Fixed assets registry, must be inserted all the Fixed Assets with their Quantity and Purchase Cost. Recommended the use of different documents PER branch.
The data Acquisition document (original acquisition document code) and Date of Acquisition document (actual acquisition date) must be definitely entered, as these are reported to the fixed assets registry and define the original data of the Fixed Asset creation, whenever it occurred. If they are empty, to the Fixed Assets registry, will appear the data of the current accounting note.
During typing, the «Depreciable acquisition» column is not accessible from the user, as the system automatically creates acquisition record (based on the «Depreciable acquisition link» setting of the document type, which MUST have the value “AUTOMATIC”). In an already saved document, this column displays the “acquisition document” as content.
The “depreciable acquisition” data are accessible for define supplementary fields e.g. the exact installation place or grant data (amount, source, related law). If the total cost must be depreciated within the fiscal year, activate the “Depreciation in fiscal year” field. The Depreciations start date has taken value by the system (based on the acquisition date) according to the company parameter value “Default Depreciations Start Date”. For instance, if the parameter defined as “alternative document start of the month date”, for a purchase on 23/1, the depreciations starting date proposed at 1/1). This date is editable by the user.
If the fixed asset purchased again, each time, a new “depreciable acquisition” created. All the acquisitions of a fixed asset displayed in sub-page “acquisitions list” to the same segment of the screen:
Appropriate document type: FAP (Fixed assets opening depreciation entry)
FAE (Alternative depreciations opening entry)
Based on the Fixed Assets registry data of the previous Fiscal year, you must AFTER inserting the acquisitions opening entry (in order “depreciable acquisitions” to be created for each asset), to also insert the prior periods progressive depreciation value (the depreciations total of the previous fiscal years).
In each fixed asset line, the acquisition is automatically selected if it is only one, otherwise it is expected from the user to select one. The “depreciable acquisition” column is necessary to be completed (based on the setting “Depreciable acquisition link” of the document type that MUST have the value “OBLIGATORY”).
In case alternative (administrative) depreciations were monitoring in the previous system, these total depreciation values must be also registered through the appropriate document type.
All the prior period depreciation documents appear to the homonymous list from the «Transactions/Fixed Assets» option of the main menu:
The “difference” value is the asset cost to be depreciated.
Liquidity accounts opening balance
Appropriate document type: BCO (Liquidity Accounts Opening)
You must enter the start debit balances of all Liquidity Accounts that concern to Cash and Bank accounts.
If Loans accounts opened, the start credit balances of these Liquidity Accounts are accomplished through the document type: OLC (Liquidity accounts opening balances (credit)).
Receivable Notes in Portfolio
Appropriate document type: NIP (Notes Receivable Inventory in Portfolio)
We select the branch series of which the portfolio will be registered. Through this document, the “body” of cheques/notes created for the first time. In order the notes to be entered as a “line”, at this point, the data of the note must be defined through the button (within a dialog). Selecting “Accept”, the note appears, with its main data, as a line of the document. Information concerning the various notes’ fields found to the chapter where the note receipt from customer is described.
The issue date in all other cases of receipt note creation coincides with the document date. In the case of the inventory it must be typed the actual “issue” date, this is the “receipt” in previous fiscal years.
With the completion of this process, the notes file is correctly updated (Book, expiration list etc.) and are also updated the “trade” customer balances from inventory, with the addition of the not expired (open) notes in the inventory, of their «accounting» balance.
Receivable Notes to Banks
Appropriate document type: NIB (Opening of receivable notes at Bank)
In the header of the document it is compulsory to enter the Bank Account over which the notes where transferred to the bank. This is the notes “payment” liquidity account on their expiration date. For each line, to the specific note dialog () the full data must be defined.
Receivable Notes transferred to Supplier
Appropriate document type: NIS (Notes receivable inventory to Supplier)
This document needs to be used for alll the receivable notes found in Third parties in order to properly update the “trade” balances for BOTH customers and suppliers. For each line, to the note dialog () the full data must be defined. As Assigner, will be placed the customer that has given it to us, and as Beneficiary the third party to whom we have transferred it.
Appropriate document type: NPI (Notes payable inventory)
In this document we will take into inventory all the payable notes that were issued from one or more Bank accounts to our suppliers. For each line, to the note dialog () the full data must be defined. The supplier that was paid with each of these, will be placed as beneficiary.
Accounting opening balances
Appropriate document type: AEO-GL (Accounting Opening Journal Entry)
This document must have been set as follows …
It must determine the opening period type, and the special Journal of Opening & Balance sheet entries.
As the entry date, it can be placed any Fiscal year date until the limit date for Balance Sheet closing of the previous fiscal year.
For organizational reasons you may insert more than one accounting documents per group of accounts by using the opening Balance sheet account and by positively or negatively reversing it at the end. Use F11 button for automatic entry balancing to the current line account
The entry result may be checked by the Balance with analysis of progressive totals
..or from the Opening and Balance Sheet Closing Book or from the Opening entries journal.
After checking and reconciliation of Accounts Opening Balances with the Closing Balances of the previous Fiscal Year, must run finalization of this Accounting Journal.
In this chapter will be examined the purchases scenarios for all stages of supply process from the offer and purchase order up to the goods receipt, the check of deliveries, the Invoices issuing and the monitoring of cost prices variances. Furthermore, it will be examined the purchases monitoring processes under Consignment regime as well as, Financial goals agreements with the suppliers, producing the appropriate claims (for credit notes).
The following guidelines and examples are mainly based on the default product parameterization, as far as the documents are concerned, the transitions, the screens format and the reporting components.
To enter a purchases document use one of the following methods:
The reason of offers recording sent by suppliers is:
- In order to be compared to the final prices & discounts taken
- In order to compare offers by different suppliers for the same goods and select the most appropriate
Offer from a particular supplier
Appropriate document type: POF (Purchase Offer)
|Type & Document series||
|Other General Data||
If additional data needed, e.g. comments, delivery date, project, contract etc., we may “open” the header through the “maximization” icon to the right, and thus more information will appear to more “sub-pages”:
In the items list, we detect the items by any of the available searching methods (with code, description, supplier code etc.) and so the related “items lines” are inserted. If it about items that do not exist, have not been re-ordered, there is access to the Item form for create new items, from the “internal menu” presented using right click.
In lines data, must enter at least the quantity and price. If the item has been purchased from the supplier, the last purchase price is suggested. If a pricelist monitored to the supplier, price and expected discounts proposal is based on the pricelist.
If offers of the same item issued from many potential suppliers, you may check «Compare offers» (called from the menu):
Offer from multiple suppliers
An alternative process for issuing purchases offers is multiple entry to the same screen (for instance, during a phone research of market prices).
Appropriate document type: PPS (Supply preparation)
In this data entry screen, the following functionality is available:
- Each item selection causes the automatic fill of the side columns of the main supplier, his telephone number, last purchase’s price, and the date of possible delivery based on the “lead-time” (defined to the “item-supplier” list of the Item management form).
- In order to select items to be ordered, instead of searching through items list, it could be used the Re-order review, (through Shift-F3), where choosing “accept”, the selected items will be transferred to the current screen with their requested quantities (ready through the re-order proposal).
- In the “Supplier” column, is achieved selection between the alternative Suppliers defined to each item.
- By completing the requested quantity, the “quantity offer” column takes the same default value (it is possible to be different, smaller if the supplier has no availability or greater if e.g. a better price achieved.
- There is a column to define until which date this offer is valid.
- For the same item, we can take different offers from many suppliers. For making this process easier, use the “copy” functionality (from the current line to another), through the “Αlt-V” buttons combination. To the new line, select new supplier and fill the related data.
- By evaluating the offers per item and deciding the better supplier, activate the “preference” column in order to define that these lines will end up to an order. The basic data of these lines will appear with bold font.
After save, the transition process of this document to order can be executed, which will create as many Orders as the suppliers of the selected lines are (marked at the “preference” column) with the particular contents of the offer.
Order to supplier
Appropriate document type: POR (Purchase Order)
|Type and Document Series||
|Transfer data||In the “Transfer” sub-page can be enter data concerning the delivery (to which Warehouse, from which supplier’s site, the shipping method) as well as the agreed arrival date.|
In the items list, we detect the items by any of the available searching methods (with code, description, supplier code or “multiple” code that contains all the bar codes etc.) and so the related “items lines” are inserted. If it about items that do not exist, have not been re-ordered, there is access to the Item form for create new items, from the “internal menu” presented using right click.
In lines data, must enter at least the quantity and price. If the supplier belongs to item’s suppliers, the measurement unit (or package), and the purchase price proposed accordingly to that definition. If the measurement unit modified, the suggested value will be converted (through the relation between units) to the particular measurement unit. If a pricelist monitored to the supplier, price and expected discounts proposal is based on the pricelist.
The expected delivery date suggested, is based on the supplier’s lead-time (days) defined to each item. If the supplier does not belong to the item’s suppliers, then, the delivery date is copied from the Order header (Transfer data) and can be modified by the user.
More analytical information as to the functionalities provided to the order, found to the chapter concerning sales order, where the needs for automation and information are more frequent.
Information during Ordering
While focused in item lines, through the “Previous Item Entries” command from the vertical toolbar or through Ctrl-F11 may directly view all the transactions with the particular supplier for the particular item, the quantity, the price, and the discounts taken.
For the item: availability for all and for the current warehouse, average cost price, latest purchase price, and sales values.
For the item and supplier combination: quantity, purchases turnover and average cost price for previous and this year, latest order and invoice data).
|An interesting functionality here is that both the item and supplier, are visible filters by the user, so, he could enter any supplier or/and item and see the results. Therefore, during ordering, we can search e.g.in which price another supplier sells the same item.|
Based on an Offer
If an already registered Offer is the final Order to the supplier, a transition must be executed to produce the Order.
Appropriate transition: 473. POF=>POR (Order to Supplier from an Offer)
A confirmation will follow
An order will be created and
The order will be displayed to the screen.
The user could modify any field of the order (e.g. arrival date or quantities) and print or send it by mail
If a selection of items must occur (i.e. some only items of the Offer will be ordered) then, in the dialog of the transition, you must choose “Set of lines” to the “Selection level” criterion, so, before confirmation, the items selection step will appear.
At Items List appeared at this step, there is the possibility to select the line as it is to proceed (for the initial quantity) by activating the 1st column ( ) or to type the desired quantity (part of the initial quantity).
Similar functionality is provided at case of “Set of analysis lines” which is used when we have goods with color-size or lot monitoring.
Based on Offers evaluation
If purchases orders must be produced by an already registered offer from multiple suppliers (PPS- Supply Preparation), where the definite choices made by activating the “Preference” column, then, the orders generation is achieved through a transition of this document:
Appropriate transition: 472. PPS => POR (Supply Preparation to Orders to Suppliers)
The transition is properly configured in order to select automatically the lines having the “preference” column activated, and to group them per supplier, in order to produce a separate Order document for each one.
If then, from the 1st stage document (PPS) asked “Show transitions”, can see in detail the generated orders and the items/quantities of each one of these.
Finally, we must transfer the orders to the suppliers by fax or by mail/e-mail.
Based on Customer Order
When we want to generate orders to suppliers based on the sales orders, we can use the available transitions:
129. SOR=>POR Purchase order from customer Order (to items main supplier)
105. SOR=>POR Purchase order from customer Order (to the «related» customer supplier)
In the 1st case the user may change the supplier to whom the order of each item will occur, to the “supplier” column of the transition dialog, where the main supplier of each item is suggested:
The result is to be produced as many purchase orders as the different suppliers are (defined to the Items section).
In the 2nd case, the orders occur to the Related supplier who is defined to each customer (if there is such a process, to define the “preferable” supplier on a customer’s level).
In both cases, the customer order is NOT protected from double transition to purchase order, which means that the pending “quantities” are not kept. After the goods receipt from Suppliers, the initial customers orders POR must generate Delivery Notes (or Sales Invoices-Delivery Notes) through one of the processes checking the stock adequacy (e.g. “Check stock availability” view.
When we want to make an order to a supplier on behalf of specific customer, then, must use a special document type (SCO Sales Order with automatic stock reservation), where, the existing quantities are reserved for this customer (and they can directly be converted to Deliveries) whereas the items and quantities not available can be converted to purchase orders. The orders occur to the main supplier of each item.
Appropriate document type: PSC (Purchase Order for specific Customers)
Appropriate transition: 174. SCO=>PSC (Order to Supplier for specific Customers)
The appropriate selection method of this transition is:
- If it is about a particular customer order, through the (SCO) order,
- If it is about mass process of customers’ orders for items to lack, from the sales orders list, by isolating the particular orders (document type SCO).
This process will produce as many purchase orders as the different main suppliers (of items to lack) are. In these documents, the supplier defined to the header and, for each line item, the customer for whom the order put.
Based on this information, can monitor which goods expected and which already been received for particular customers, from the “Customers’ Orders Status Review” scroller.
In this scenario, the workflow is the following:
Through the Stock replenishment process
Orders to suppliers generated by mass processes aiming to stock replenishment up to the desired levels. These processes are depending on many factors such as:
- Type of goods and stock turnover rate
- Algorithms calculating the optimal stock, partly to serve the sales within a reasonable time, and also inventories of large scale and high cost to not maintain
- Suppliers leads times
- Frequency of cost prices changes
In the Stock replenishment chapter are described ordering methods as well as stock distribution methods to the various Warehouses-Branches of the company.
How do we see the results of issuing Purchases Orders?
List of registered purchases orders
||Pending orders||The orders that have not been yet received or have been partially received|
||Pending orders per Item||Items and quantities of not yet received orders by (expected) arrival date|
||Delayed goods arrivals||
Orders that have not been received, whereas the agreed arrival date has elapsed
||Stock transactions history||
Items detailed records, where the orders also appear (and not only these concerning on the Official Inventory Books).
This view is not easily readable in 1024x768 screen analysis due to columns number
||Stock quantitative control||
Cube for check items’ quantities per item, branch, and WH.
||Current stock availability||
The current stock status per Warehouse with information for the expected, orders to be delivered and the future stock.
Information for Order Customization
- In order to change the layout of the Order screen, you may use a dynamic form, defined to the document type. In addition, you can change the grids layouts (add or remove columns) and save them.
- If Items must not be accepted if the particular supplier does not belong to the “Item’s suppliers” (in cases of strict processes with supervisor, evaluation criteria, approval and final ordering to “approved” suppliers), activate the relevant option of the document type.
Goods Receipt from supplier
Pending receipt of Invoice
Issue during goods receipt, in order the Warehouse to be quantitative updated.
It is very important to be used the correct document type for the appropriate quantitative transfers, since some documents influence the Costing of the Inventory (the cost prices etc.) and others do not.
Here, we examine the document accompanying goods received. The Supplier has issued this document as a “Delivery Note” to our company.
Appropriate document type: PLN (Goods receipt Note)
Based on Order
When the goods receipt concerns a prior Supplier Order, it could be produced by transition of Order:
Appropriate transition: 101. POR =>PLN (Purchases Orders Goods Receipt)
When the Order to the supplier has occurred on behalf of specific customer through the PSC document type, then:
Appropriate transition: 478. PSC =>PLN (Arrival of purchases Order for customers)
In both cases, the order retains the transition information and it properly updates the available stock.
Thus, in any scroller where we had “expected” quantities, we will have REDUCTION of the expected, and INCREASE of the PURCHASES quantity (and of the actual stock balance).
Due to replacement
When we receive (with ‘PLN’) a defective item or with a lack or differentiation of the expected item and we return it to the Supplier (with ‘PRN’), then, if a Credit Invoice is not issued by the Supplier, the item will be probably replaced. In this case,
- in order to have correct cancellation of the expected values (pending invoicing) and these documents to be ignored from the Stock valuation
- in order to “lock” the Delivery Note through which we returned the item (in order to prohibit transfer to Credit Note, by mistake) and the Goods Receipt Note of replacement (in order to prohibit transfer to Invoice, by mistake)
the correct approach is to use the transition configured for this purpose exactly:
Appropriate transition: 124. PRN => PLN (Goods Receipt Note from Return Note to Supplier)
When we send an item for repair to the supplier (using the document type ‘SPC’ which does not create expected invoicing/credit value) then, the item’s receipt note from the supplier must be respectively issued using the special Goods Receipt document which does not create pending values (either manually or by transition).
Appropriate document type: PNS (Goods Receipt note (No charge))
Appropriate transition: 144. SPC =>PNS (Goods Receipt from Delivery note (without value))
In cases of repairs, Serial Numbers are probably monitored. In order to have correct information, in this case, (which is the position of serial number), it must be defined both to the Goods Delivery Note and the Goods Receipt Note. The default items lines grid layout includes the serial number:
Details for serial numbers handling found to the specific chapter “Purchases of Special Categories Items”.
In order to check if the actual quantity arrived is identical with the «theoretical» one that is reported to the supplier’s accompanying document, we could give in a document of temporary use (a copy of the ”Offer” for instance) the actual quantities and to select ”Compare documents” (menu «Transactions»):
If differences occur, we must issue either a Goods Return Note in case of deficit goods receipt or a new Goods Receipt Note (issued by the supplier) for any surplus items, after contacting the supplier.
In the 1st case, the Return Note will be generated through the 123. PLN => PRN transition (Goods Return Note from Purchases Receipt Note) selecting from “Set of lines” only the items and the quantities that were NOT received.
How do we see the results of issuing Goods receipt Notes?
||Purchases/Arrivals||List of all Purchases documents concerning quantities or values|
||Quantitative Purchase Documents not Invoiced||Goods Receipt or Delivery Notes that have not been “connected” to invoices. Therefore, we expect the relevant invoices to be issued by suppliers.|
It presents all the stock quantitative and value transactions. The Goods Receipts update the columns of “Import quantities” (depending to each format):
The same update (summarized) also occurs to the Monthly Statement of Stock Book and to the Inventory Costing Balance.
||Stock quantitative control||
Cube for check Items’ quantities per item, branch, and W.H.:
||Journal of Quantitative Stock Entries||
List of Items’ transactions PER date and Warehouse, with double qty columns to both main and alternative unit:
||Current stock availability||The current Inventory status per Warehouse with information for the expected quantities, the orders to be delivered and the future stock. The quantitative goods receipts do positive update of the “stock” column.|
For a Goods receipt Note
When the received invoice refers to one or more prior Goods Receipt Notes, the document can be produced through a transition from the list of the “Quantitative Purchase Documents not invoiced”.
Appropriate document type: PIV (Invoice for Goods Receipt Note)
Appropriate transition: 102. PLN => PIV (Invoicing Of Goods Receipt Notes)
The suggested format of the Purchase Invoice is the following:
After the Invoice generated from the source one or more relevant Goods Receipt Notes, we must open the screen of the new document and check or fill a number of fields, according to the original document.
If for any reason the (value) Invoice is NOT created through transition, but it is manually typed, then, BEFORE the Stock valuation process executed, it must occur “automatic quantities matching” in order to be connected to the related Goods Receipt Note(s), so “pending values” not to exist. Such values would create wrong “forecasting” cost entries and differentiate the items’ cost value. The “automatic quantities matching” described to the chapter about Invoices received BEFORE goods arrival, where, this process is unavoidable.
How do we see the results of issuing Purchase Invoices?
||Purchases/Arrivals||List of all Purchases documents concerning quantities or values|
||Purchases & Expenses Journal per VAT rate||
It presents all the stock quantitative and value transactions. The Invoices update the columns of “Import costs” (depending to each format):
The Supplier’s statement (of accounting nature) with detailed transactions and progressive balances.
The same update (summarised) also occurs to the Suppliers’ Trial balance.
An accounting entry is created to the Suppliers, Purchases and VAT accounts and it updates the Accounting journals, the Account Statements, the Trial Balances etc.
Invoice – Goods receipt Note
When the Invoice received is simultaneously a Goods accompanying document, then the following document type must be used. If an Order to Supplier has already registered, the Invoice can produced by transition through the orders list.
Appropriate Document Type: PNV (Purchase invoice – Goods Receipt Note)
The default format of a Purchase Invoice is exactly the same as the one of the value invoice (PIV).
|Type and Document Series||
|Alt. document date||
Information during Invoicing
While focused in item lines, through the “Previous Item Entries” command from the vertical toolbar or through Ctrl-F11 may directly view all the transactions with the particular supplier for the particular item, the quantity, the price, and the discounts taken.
Access to a full view of Inventory for the current item and data related to current supplier with the “Item summary view” command from the vertical toolbar that displays information:
- For the item: availability for all and for the current w/h, average cost price, latest purchase price, sales values.
- For the item and supplier combination: quantity, purchases turnover and average cost price for previous and this year, latest order and invoice data).
As far to the area where the results of an Invoice-Goods Receipt Note issue are visible, see to the previous section as to the way that the two documents (of which the combination consist the current), affect the system (Invoice, and Goods Receipt Note).
The Trial balance and the Inventory Records are updated both by quantities and values:
Information about setup of Purchase Invoices
To the document type, in “Lines” sub-page, check the following parameters:
Default item price. From the available options, the following 4 are appropriate for purchase documents and the 1st of these, is set to the predefined document configuration:
Supplier purchase price: If the supplier is among the “Item’s suppliers” the purchase price is proposed from this table. This price updated during each purchase (based on an option of Item’s Control Profile). It is the latest item’s purchase price from the particular supplier.
Supplier purchase price net: It functions as the previous, but any discounts of the latest purchase have been deducted. Thus, if in the latest purchase from the particular supplier, the price was e.g. €100.00, and the discount 10%, with the previous option, it will be proposed €100.00, whereas with this selection “net”, it will be proposed €90.00. In case of activation of discount proposal (either from the supplier or from the pricelist) it must NOT be selected the “net” price, as the system will suggest double discount.
For both the previous and this option, the functionality is bound to the suppliers’ list of items. This means that if for an item of the document, the current supplier does NOT belong to the Item’s suppliers, no price will be proposed.
Last acquisition price: As acquisition defined any primary cost entry that concerns particular quantity e.g. stock opening entry (inventory), purchase, import cost entry. The proposed price comes from the latest acquisition, even if that was not an invoice not even this supplier’s invoice.
Last acquisition price net: It functions as the previous, but the calculation accomplished with deduction of any discounts.
- Default price per trade acct.: The field is accessible only if in the “Default item price” option has been selected the 3rd or the 4th from the above options (Last acquisition price). In this case, may define that this “last” price to be searched ONLY from transactions with the supplier of the document and then there are two options:
- Copy only the price from this last transaction
- Copy both the price and the discounts to the line
Selecting this option, in reality, we have the same result that we would have if monitored alternative suppliers to the items and Item Control Profile for the item Purchase Price update. If however Item’s suppliers monitored, there is the advantage of keeping always updated and saved to a table (available for any use) the latest purchases prices per item and supplier.
- Calculate VAT on totals. Even though the VAT calculation per line is legal, and lawful, it is possible that the accountant will consider as more appropriate the VAT calculation on the total per VAT regime and also the computerized systems to approach this logic. In this case, and in order to avoid interfere to the values, can activate this setting. To understand the difference between the 2 computation methods, see example:
- VAT calculation per line
Suppose that all items have VAT 19%. We notice that to the final totals, the VAT value is not EXACTLY the 19% of the total net value (118,50*0,19=22.52), whereas in contrary, the VAT value of each line is EXACTLY calculated based on the percentage.
VAT calculation on totals
In the same example, we notice that to the final totals, the VAT value is EXACTLY the 19% of the total net price whereas in the 3rd line is 0.01 increased, compared to the EXACT result that would give the product to the 19%. This will be noticed to the totals per VAT rate (depending on the number of the different VAT rates appearing to the same document). If a difference from the calculation occurs (usually 1 cent of the euro), is assigned to the item line (of this rate) with the greater value.
- The VAT calculation on document totals is active only during issuing (and not when modify). Also, even during insert, if the user types the VAT value of any line, this functionality becomes inactive.
Invoice – Goods receipt Note based on Order
If the Invoice - Goods Receipt Note based on a previously registered Order, it can be produced by the order transition:
Appropriate transition: 128. POR => PNV (Invoice for Purchases Orders)
If the order to the Supplier occurred on behalf of particular customer (through the PSC document), then:
Appropriate transition: 479. PSC => PNV (Arrival of Purchase Invoice from Order for specific customers)
In both cases, the order keeps the transition information and it appropriately updates the available stock.
Invoice of additional charges
If the Supplier issued an Invoice of additional value (e.g. because of a prior mistaken invoicing), it must represented to the system with the following document type and NOT the one, used for invoicing Goods Receipt Note (PIV) as then, it will be caused a wrong Stock Valuation.
Appropriate document type: PDV (Debit note)
The Inventory Record only updated to the Purchases value column and the Total acquisition cost will be influenced (increase of the average cost price). In Accounting, a debit will occur to the Stock account and a credit to the Suppliers account.
If the mistake occurred to the Initial Invoice requires a reduction of the invoiced value, then the Supplier will issue a Credit Invoice and, in the system, it will represented as a Credit Discount Note (using the document type PCV).
Invoice anterior of Goods receipt Note
When we have a Purchases Invoice, whereas the goods receipt has not occurred yet e.g. because the invoice sent electronically or by mail, whereas the cargo is in route, it should:
- Issue the (PIV) invoice
- When the goods arrive, issue the PLN (by “copy” from the Invoice or manually) and
- From the Purchases documents list, having “marked” the (PIV) invoice, ask from the “Actions” menu the «Automatic quantity matching» (the simple option or the «Criteria-based” one), in order to be “connected” to the Goods Receipt Note, to have the correct history and to correctly updated the “pending” quantities. If pending quantities remain, then, the generation of a new Invoice from the Goods Receipt Note (by mistake) would be allowed. Moreover, during the next Stock valuation process execution, “forecasting entries” would be produced, whereas no pending values or quantities exist.
In order the “Automatic quantity matching” to be functional, it must be typed the “102. PLN=>PIV” transition code to the “Origin Transition Rules” field in “behavior” sub-page, of the “PIV” document type screen. The “Origin Transition Rules” field defines the transitions through which the current document can produced (comma-separated list per priority, which does not apply to “PIV” as it cannot produced from another document type, than the Goods Receipt note). So, during “automatic quantity matching”, a searching process will occur to the correct documents (sources), in order the “connections” generated to be EXACTLY those as it would have happened through a transition.
If before the Stock valuation process execution it has NOT been received a Goods Receipt Note, an automatic costing entry would appear which will cancel the Invoice value, since it does NOT correspond to existing Stock. In next period, this difference will be eliminated, due to Goods Receipt Note presence and its connection to the Invoice (in retrospect).
If this happens to the End Of The Fiscal Year (this means that there is still no Goods Receipt):
During Fiscal Year Closing will need to be accomplished accounting settlement of the Difference, which will occur through the Stock valuation process (handling of Purchases under reception). This is the purchases value suspended.
In the Inventory of the new Fiscal Year, this value will NOT be included.
In the new Fiscal Year, when we receive the goods, the Goods Receipt Note must be issued as an Invoice – Goods Receipt Note with zero value. This is achieved if we copy the “PNV” document type to another with “Goods Receipt Note” title or by creating new SERIES of the “PVN” with “Goods Receipt Note” title, and we will make sure that the lines value will be zero. With this action, the last purchase price at Item’s Suppliers data will be (temporarily) zero.
To the Inventory sub-ledger, this difference (of the last stock valuation) must be issued with the IPC (Stock purchases corrective – value) document type. It may also be produced through transition (or lines copy) from the “PIV” document. To the header, you will need to give the “Purchases under reception” General Ledger Account. Thus, the value will be transferred to the Purchases Account. At the same time, the effect of the value will be restricted to the Inventory as to the Supplier (his statement) and our liabilities (open items) have already been updated from the Invoice of the previous Fiscal Year.
Send goods to supplier
Pending receipt of Credit Note
It is about Delivery Notes that we issue as goods accompanying documents when we return goods to Suppliers.
Appropriate document type: PRN (Goods Return Note)
This document used even if we do not know if the Supplier will send a Credit Invoice or new replacement items. It has already been described the goods receipt case due to replacement from the Supplier.
To the Alternative document field (which, in Purchases documents issued by the supplier, used for the original document code), it can be entered the code of the Goods Receipt Note or the Invoice for which this Return occurs. There is a searching functionality with F3 to this field (header and lines).
The searching functionality based on two company parameters, where defined (in a “comma” separated list) documents’ attributes displayed (in F3 dialog), and documents’ attributes where this search is in force:
Without Credit Note pending
Used in case of Delivery to suppliers for control and repair or delivery from a Third Party Warehouse (e.g. Service) where the value is not taken out (since the goods does not “belong” to us). It is also used for goods returns that we obtained for various purposes (test, presentation, check etc.) with a “PNS”, for which a Credit Note will not be issued, It can also be generated through transition from the Goods Receipt Note.
Appropriate document type: SPC (Goods Return Note (without pending Credit Note)
Appropriate transition: 125. PNS => SPC (Goods Return Note (without value) from Goods Receipt)
In cases of repairs, Serial Numbers are probably monitored. In order to have correct information, in this case, (which is the position of serial number), it must be defined both to the Goods Delivery Note and the Goods Receipt Note. The default items lines grid layout includes the serial number:
Details for serial numbers handling found to the specific chapter “Purchases of Special Categories Items”.
Issued from Suppliers for our Delivery Notes (Purchases Goods Return Notes) in order to cancel the value charged by a prior Invoice (only of course, if a related Invoice already issued).
Appropriate document type: PCN (Credit Note for a Delivery Note)
Appropriate transition: 106. PRN => PCN (Credit Note for Goods Return to Supplier)
This document always concerns a particular stock quantity and it cannot be used for value correction only. We never make the quantity zero to it.
As with the Purchases Invoices case, the values (net, VAT, total) must be exactly the same with these of the original document.
For the number of the original document, we use the “alternative document” field.
If the credit note refers to a particular or many particular Invoices, with which it must be “correlated” in order to have a correct update of “Ageing balances”, we may define these documents to the “Status” sub-page to the “reference document” field using the icon:
In order not to remain “pending quantities” and influence wrongly the Stock Valuation Process, the Credit Note must either produced by transition or created annually, and to be later connected with the Goods Return Note.
This may happen as follows:
From the Purchases documents list, having “marked” the (PCN) credit note, ask from the “Actions” menu the «Automatic quantity matching» (the simple option or the «Criteria-based” one). Prerequisite for this process to be functional is that to have been entered the “106. PRN=>PCN” transition code to the “Origin Transition Rules” field in “behavior” sub-page, of the “PCN” document type screen.
So, during “automatic quantity matching”, a searching process will occur to the correct documents (sources), in order the “connections” generated to be EXACTLY those as it would have happened through a transition.
How do we see the results of issuing the Purchases Credit Notes?
||Purchases/Arrivals||In the purchases documents list the credit notes are negatively update the columns “Gross Turnover” and “Net Turnover”.|
||Purchases & Expenses Journal per VAT rate||Auxiliary Journal for reconciliation VAT Inflows, where for each VAT rate, net and VAT values reported per accounting category.|
||Inventory records||It presents all the stock quantitative and value transactions. Depending on its format, it displays the Credit Notes values negatively to the Purchases columns or generally to Imports columns. The same update (summarized) also occurs to the Monthly Statement of Stock Book and to the Inventory Costing Balance.|
In the Supplier’s statement (of accounting nature) with detailed transactions and progressive balances, the Credit Notes are updating the Debit, except if the “trade accounts update from "reversed" transactions with NEGATIVE entry of the same sign (D/C)” company parameter is activated (set to “true”) and thus, will appear as negative in Credit. The same update (but summarized) also occurs to Suppliers Trial Balance.
The Supplies statements and Trial Balances “with turnover separation”, at the same time, give the information of the net and gross turnover information where the credit notes act negatively, as expected:
An accounting entry is created to the Suppliers, Purchases and VAT accounts and it updates the Accounting journals, the Account Statements, the Trial Balances etc.
Credit discount Notes
It is issued from Suppliers either to correct a wrong charge or (mainly) due to Agreement (e.g. for turnover goals) which, if achieved, must result in providing credit. It can be issued for a particular Purchase Invoice (if it is paid according to the settlement for instance), either at the end of the month, 3 months period, year etc, or whenever our purchases have met an agreed target.
Appropriate document type: PCV (Purchases Discount Note)
The use of credit discounts documents can be checked from the Discounts justification statement (from the Business Snapshot/Cost Analysis menu) which analyzes the purchases discounts and contains a special set of columns for “retrospective discounts”:
Issue of the supplier’s original document
In this document, quantities are not visible, as they do not affect the system.
If we do not know the items that the discount is concerned, and we insert the Credit document using a generic item or as an Expense Credit Document, then, the Purchases cost (turnover) will not affect the Inventory (stock costing process, average cost price etc.).
- The analysis into items of which we take the discount is strongly recommended even if they are not separately reported to the original (in order to have a correct COST to the INVENTORY).
The effect of the credit discount documents to the system is corresponding with the one of the Goods Return Credit Notes. In Accounting, they may update a different purchases account, depending on the chart of accounts.
Discount for a particular Invoice
If the Credit Note refers to particular Invoice, in order the items not to be typed again, we can use the related transitions:
Appropriate Transitions: 109. PNV=>PCV (Discount Credit note from Invoice - Receipt note (with zero value))
103. PIV=>PCV (Discount Credit note from Purchase Invoice (with zero value))
After document created, we must open and enter the values of the original supplier’s document.
Rebate claims from suppliers
When the expected from the Supplier discounts, concern an agreement of turnover goals, the system provides a process for calculate and automatically create the claims for discounts taking (see chapter “Commercial Agreements”). Their entry into the system, has the following advantages:
- Smoothing of inventory cost modifications and on time information, in comparison to taking information for the actual stock cost (after discounts) only once per year, as it usually happens.
- Monitoring of possible discounts differences, according to the agreed (compare claims to actual rebates).
Appropriate document type: PCF (Purchases Rebate Claim)
These “forecast” entries can update specific for this purpose General Ledger Accounts, in order to obtain reconciliation between Accounting and Inventory sub-ledger:
When the Credit Notes issued by Suppliers (“PCV”), all the prior forecast entries (PCF) must reversed:
Appropriate document type: PCR (Reversal of Rebate Claim)
Appropriate transition: 136. PCF=>PCR (Suppliers’ Claim reversal)
The Stock cost variation, at the month when the Credit Note issued, will be ONLY the DIFFERENCE, compared to the forecast entry and NOT the total credited value.
For the related information (forecasts comparisons with actual discounts attributions) see the Compare Suppliers’ rebate claims to actual report (Entities/Accounts payable/Information):
The report presents the Purchases turnover (before the reductions of the Credit Discounts document PCV), the corresponding claims for rebates (from the not reversed claims PCF), the issued rebates (PCV), the claim that these rebates correspond (reversed by PCR), the possible difference, and the remaining amount (forecasted).
Discounts expected in the next fiscal year
If the company is entitled to purchases discount that is not issued yet by the supplier, whereas the fiscal year must close, then, we would enter an Inventory transaction for reduce cost and a reversed document to the new fiscal year when a (PCV) credit note sent from the supplier/s.
Appropriate document type: IPC (Stock purchases corrective - value)
These entries are monitored to the “Fiscal year Purchases Discounts under settlement” General Ledger Account, which is given to the header. To the lines, give the discount amounts and the accounts to be credit. In the next fiscal year, it must occur symmetrical entry with negative amounts (cancelling process or issue the same data to the “reversal entries” sub-page.
Purchases on consignment & clearance
Some suppliers provide the items for sale and they paid later, based on sold items clearance, for the period “discharged” (and not based on the balance resulting from Invoicing or Goods remaining to our site). To accommodate these processes, the purchases must be “connected” with the sales in order to get as a result, the amount payable to Suppliers, ONLY for the items sold.
At this point, the specificity covered by the system is that the “purchase” and “sale”, are attributes given to the various documents in an independent way from the one monitored to the Inventory and the rest sub-ledgers. This allows the implementation of the Consignment process through any transaction, use of Third parties warehouses, Quantitative Notes or/and through typical Purchase and Sales Invoices.
The tasks needed are available to the Periodic Processes/ Consignment processes menu. At the end of this chapter described all information about the requested customization.
The displayed dialog contains two lists (Sales - Purchases) and allows determining which Purchases come from what Sales:
In order the matching information to be saved (or the deletions etc.) the SAVE button must be selected.
Matching of purchases returns
To the upper part are displayed the returns and to the bottom part the purchases. In order to match lines, use the same tools as with the Purchases-Sales Clearance. The result will be the net purchase quantity, to be “connected” to SALES. The mass matching process selects lines of Returns and Purchases of SAME items and SAME suppliers, sorted by date.
Matching of sales returns
To the upper part are displayed the returns and to the bottom part the sales. In order to match lines, use the same tools, as previously. The result will be the net sales quantity, to be “connected” to PURCHASES. The mass matching process selects lines of Returns and Sales of SAME items INDEPENDENTLY of the customer (“mass (FiFo) matching per item”) or of SAMES items AND the SAME customer (“mass (FiFo) matching per customer”), sorted by date.
It is a view of all the Purchases-Sales clearance entries for selectable date range in order to finalize the entries (which means that the entries will not be able to be deleted or modified), and to calculate the amount of reconciliation (payable amount), owned to the consignment suppliers.
This view has grouping and TOTALS per SUPPLIER and (sales) branch, while it displays the quantities and values based on the Clearance. The values are proportionally calculated on the total cost (of the connected Purchase), based on the quantity sold.
Using the “Finalization” button, the entries obtain the appropriate attribute (in order to be “locked” for modification/deletion) and they can become accessible again through the “Undo finalization” button. These actions are functioning for the SELECTED lines (in the 1st column, activated with the “select”, “deselect” buttons, also) and affect the LAST COLUMN which shows the status of each entry (finalized or not).
- Within this view, may connect the appropriate report format using Crystal Reports or with a layout (and print preview) or/and an automation for produce automatically the suppliers’ payment documents (receipts or payment orders).
Preparation of matching
This process allows the mass matchings accomplishment between returns and initial invoices in sales and purchases but also sales matching to purchases, for a definable date range. After that, the user can process the results and make corrections, if needed.
The “clearance” date is stored to the produced matching entries. This is the ending date of the period given to the criterion.
Information of Consignment processes customization
To all the suppliers with whom we work in this way, the “Purchases in consignment” field (in “Commercial terms” sub-page) must be activated.
Each item line of documents, of which the TYPE defines any consignment type (except the “does not refer to consignment”)» and at the same time the document SERIES defines that it CONCERNS consignments, is stored woth the “Refers to consignment” line field activated (this means that it can participate to the matching processes).
NO item line which participates to consignment matchings can be deleted or modified in quantity in such a way that it would cancel its reconciled quantity (increase of the quantity allowed, recrease allowed up to the threshold of the matched quantity).
The matching processes operate with lines quantities to the MAIN measurement unit.
The lists used to matching processes can be differentiated per installation, since are Views (scrollers):
- Area “Suppliers”
- Area “Purchases Documents”
Purchases Returns Lines
Purchases Lines for Returns matching
- Area “Sales Documents”
Sales Returns Lines
Sales Lines for Returns matching
Changes in market prices
The monitoring of the purchase/cost values in a company is a critical process, which must execute at regular time intervals in a structured method and it should be followed, if necessary, by the respective actions of sales prices adjustments.
How to monitor changes in prices
The system provides tools for prices modifications monitoring which can be used depending on the invoicing policy method, applied to each installation.
Inside the items’ management screen the alternative suppliers of the item are defined and at this point, is monitored the price and the date of the last purchase. In order for this update to automatically occur, it must be properly defined to the items’ Item control profile.
- If despite these, the prices at this point are used INSTEAD of a pricelist (in order the agreed prices with the suppliers to be recorded through typing or another way), the Item Control Profile should NOT be customized in order to be automatically update the purchase prices.
If we want a history log for modifications of these fields, the history keeping functionality must be activated through the “Change Field Behaviour”.
Information for all prices’ modifications is available to the “Purchase prices log” list (where the user can ask only a particular number of the last changes to be reported):
Another useful check of over time changes of cost prices based on the registered suppliers’ documents. The “Purchase prices variance based on transactions” list presents the last and the preceding net purchase price (deducting possible discounts), with the percentage modulation criterion, (that is comparison of the two sequential modifications exceeding a given % of difference).
Apart from purchase prices issue, and depending on the stock valuation method, it is useful to check the actual cost prices and their variance justification. This implies the frequent and correct execution of the Stock valuation process. In particular, we recommend the use of the Entities/Inventory/Stock value control menu reports:
Official cost prices per period: It presents for each item, the calculated cost prices per month. Recommended, in order to check the cost price evolution.
Compare official cost prices: It presents the items by supplier, with their cost prices calculated for the selected month AND the previous one, with their percentage variance. Ideal for monitoring significant changes in cost prices.
How to verify compliance with the agreed prices
A first-level check users can do, when the default purchase price (based on the agreed prices) is NOT the same with the one of the original documents. Though, it is desirable to have an independent control mechanism which will make information available to us at any time and from the appropriate people that will examine the difference between the “appropriate” and the “actual” prices. This mechanism is supported by the “Item prices log templates”.
The “templates” supply a purchase agreed prices calculation on a daily or another periodical basis, which, no matter how the prices declared into the system (e.g. in items’ suppliers list, in purchase pricelists, in specific contracts etc.) detects and stores the agreed purchase prices, in order to be available for cross checking. This is achieved through invoicing process simulation.
To define “Item prices log templates” (Tools/Customization/invoicing policy), must choose the parameters that must be taken into consideration e.g. specific pricelist or items or branches or colors/sizes for which the prices file will be calculated and stored.
It must be given a typical trade account for whom the calculation will occur (just like an invoice by him were entered).
It must be either defined a branch or a series. If a branch is defined, then, this will be illustrated to the history log as a “dimension”, if series defined, then, may monitor the prices for the whole company without the branch dimension.
From the “Actions” menu of the templates list, the calculation and deletion functions of price history log are available.
As far as prices calculation is concerned, a dialog will open to define the template/s (based on which the calculation will occur), as well as the reference date.
The process can be time scheduled and daily executed.
From the time this process executed, the view “Item prices log” (through the “Entities/Inventory/Information” menu) is available.
It displays the items’ current prices for the selected date to the date criterion. To the “Actions” of the scroller toolbar, the calculation processes and price file deletion are also available.
In the same location, it is also available the “Compliance of purchase prices to Suppliers’ pricelists” view, which displays the purchases found with different values than the current, for a selected time range.
How to adjust selling prices when purchase prices change
Depending on the company nature and the invoicing policy, can be used different methods to adjust selling prices.
- Through Purchases Documents
In purchases documents, the “Readjustment of Sales Prices” automation is available (through the horizontal toolbar), which will function for the selected items only:
The items’ selling prices (Wholesale, retail etc.) for modification
The method used for the re-adjustment. The final price can be increased based on:
The % markup of the price that will be updated (only available for the wholesale price and the retail price)
The percentage that will be given by the user to the numeric dialog field.
Finally, the user can directly enter the desirable price. In this case, the unit price of the purchase document is not taken into account.
Through Imports Folder
To the import folder, in “Costing” page, the “items’ retail and wholesale price update” automation is available. This automation adjusts the selling prices (wholesale and retail) to the item, in the way that these are calculated through this particular view.
From The Readjustment of Prices process
This process, described in detail to the related chapter, allows the mass modification of selling prices, as much to the items (current base prices) as to the sale pricelists, even in the level of dimensions (prices per color-size). It is based on purchase prices (or other options for starting price), gives the possibility to use the items’ mark up or other specific %, gives some rounding method options etc.
It is the most complete and suitable procedure for changing prices.
Purchases of special categories items
The purchases orders are usually occur through the sampling procedure, listing the quantities of each combination Item-color-size and then the order entered. The user can enter one line per item with simultaneous quantities definition to a matrix, per dimensions combination, through the F12 () button on the item line:
As for the display method of the colors-sizes values, two general parameters are used. The 1st parameter concern the sorting method, horizontally and vertically (“stock variation set field based on which the colors-sizes sorting will occur to F12”). The 2nd parameter indicates the dimension which is used for the vertical and the horizontal axis (“Priority matrix (F12) appearance dimensions”).
A functionality that combines the ease of management to a matrix and the completeness of information that the development of colors-sizes per line offers, is the use of “Stock dimensions enter in matrix, maintaining of line level management” command, with Alt-F12:
By typing data to this dialog, the information of colors-sizes analysis is placed to different lines (so many lines as the not-zero “cells” of the matrix):
Even if lines of the same item created by the user, using this command afterwards, these lines are recognized after grouping of all their basic fields, and they are ALL displayed together, within the same dialog.
As the usual reason behind discrete lines development is the different PRICE, the dialog appears with DOUBLE COLUMNS for each color-size combination (quantity and price). To the bottom of this dialog, a setting deactivates the “price” columns in order to “fit” more size columns (size is usually the horizontal axis).
Finally, through the Shift-F12 buttons combination to an item line monitoring colors-sizes, the color-size values are copied from the previous line (either if the line had one or more dimension lines connected).
It is necessary to pay attention to the correct definition of the Item control profile for the items monitoring dimensions. It must be defined compulsory input of these fields, in order to ensure the correct update of Stock.
In case where, during goods arrival, there are modifications in colors-sizes level compared to the initial (of the order), there are two cases:
- If the goods receipt note produced by transition, it is sufficient to correct the colors and sizes to the document lines and so, the “pending quantities” (created by the order) will be correctly updated (decreased).
- If the goods receipt note was manually typed and we later want to connect it to the order through the automatic quantitative matching process, the “Automatic quantity matching with strict dimension control” parameter must be FALSE, in order to try firstly match lines by dimension (color-size) and item and if not found, to try match by item only. If the parameter is TRUE then, the matching will strictly occur for SAME combinations of color-size.
The lots are either created through the Lots List (Entities/Inventory/Lots) or through the items’ management screen (Contents/Dimensions/Lots) or/and automatically, during their insertion to Inventory (through a document) as we later see.
Basic fields of the Lot are the Production Date and the Expiry date. These fields are also useful for the automatic lot selection during sales or grants in general.
Using the above functionality, the user may define more than one Lots to ONE item line the quantities of which consist the total quantity of the item line.
Alternatively, the lot can be defined PER LINE, if we have made the “lot” column visible at the lines grid or/and the “lot code” column (through which is accomplished automatic lot creation, by entering a not existing lot code).
Finally, it is possible to configure the automatic lots’ generation, in order the various lot’s fields to take default values based on the document data (the document through which lots are created).
We can create a field properties profile, by defining
To the “Relates to” field -> Lot
To the «Provided it is valid» field, the expression
NOT _dr.Table.Dataset.ExtendedProperties("CTX_DOC_LINE") Is Nothing
To the “Field”, that field to which we want to give default value
To the “Value type” field -> Expression
Update of the lot expiration date from “date 5” of the item line with the following expression:
Update of the lot Shipment date from the document issue date with the following expression:
With Serial Numbers
The serial numbers are either created through the Serial number List (Entities/Inventory) or through the items’ management screen (Contents/Dimensions) or/and automatically, during their insertion to Inventory (through a document) as we later see.
Basic fields of the Serial number are the Position, the Status, the Start date and Expiry date of warranty.
Through the abovementioned functionality, the user could define to ONE item line more than one serial numbers, depending on the quantity of the item line.
Alternatively, the Serial Number can be defined PER LINE, if we have made the “S/N” column visible at the lines grid (through which is achieved selection among existing serial numbers) or/and the “S/N code” column (through which is accomplished automatic serial number creation, by entering a not existing serial number code).
Finally, it is possible to configure the automatic serial numbers’ generation, in order the various serial number’s fields to take default values based on the document data (the document through which serial numbes are created).
We can create a field properties profile, by defining
To the “Relates to” field -> Serial Number
To the «Provided it is valid» field, the expression
NOT _dr.Table.Dataset.ExtendedProperties("CTX_DOC_LINE") Is Nothing
To the “Field”, that field to which we want to give default value
To the “Value type” field -> Expression
Update of the serial number warranty expiry date from the « Date 5» of the item line, with the expression:
Update of the serial number warranty starting date from the document issue date, with the expression:
Commercial agreements & claim of rebates
The commercial agreements, through which the turnover goals recorded and rebates (retroactive discounts documents) or rebate claims (forecast entries for expected rebates) are automatically produced based on the goals’ success, complete the Invoicing Policy functionality (prices, discounts, contracts), by clearly defining the context of the commercial co-operation between two companies (customer-supplier relation).
A thorough trade agreement generally states the contractors (Company, Supplier) and the time of effect. Usually, the time of effect for an agreement is one calendar year. The terms of the agreement define some of the following areas:
- Invoicing policy: Prices, Discounts or benefits applied during buying (e.g. 10 + 1 free)
- Benefits policy: Benefits related to the performance, awarded on a periodical basis (one year, 3 months period etc.)
- Credit control policy: Amount of credit limits, payment methods, discounts based on payment method etc.
- Shipping policy: Delivery terms, lead times, discounts based on these terms etc.
The benefits from an agreement term may be implemented either by Credit note for the retroactive discounts (Rebates) or by Service provision invoice from us to supplier.
The monitoring of the commercial agreements consists from three levels:
The definition of the agreements’ terms
The calculation of rebates
The necessary reports and statistics
Such agreements may relate to either customers or suppliers.
How to define a commercial agreement
The system defines the “commercial agreement” entity based on which the rebates calculation is achieved. An agreement may contain MANY Retroactive Discount Profiles (individual terms).
In this way, it is feasible to configure different discounts profiles for different calculations e.g. per brand, business unit etc. depending on the items’ grouping fields that the agreement is based on and to integrate them under the same “agreement with the trade account”. Thus, the profile could be “degenerated” to ONE scale description for COMMON values of the grouping fields e.g. one profile with N lines for item’s category A, containing the targets limits (scale) and the % of rebate, a second profile for item’s category B etc.
An Agreement contains data concerning trade accounts and detailed data of all the discount profiles. During moving between profiles in the list, the sub-page “discount profiles details” presents the data of the current (particular) profile:
The Screen of Agreement is a dynamic form, customizable in installation level.
Basic Data Of Agreement
Retroactive Discount Profiles – Basic Data
|Start-Expiry||The period for which the retrospective discounts will be calculated.|
|Results view||We define the scroller for presentation of calculation results. The results are stored to a particular table for calculation justify and for information purposes. Through its new calculation of the same profile for the same time range, the previous results automatically deleted.|
Retroactive Discount Profiles – Scales (goals setup)
Retroactive Discount Profiles – Scales (benefits setup)
How to see the results & update forecasts
In the dialog appeared, the user must select a specific agreement and one or more terms (discount profiles), provided to have a common produced document type). Then, he must define series for document generation and some comments, if needed.
The first sub-page “Results” shows the results of calculation (for the current discount profile), and the second sub-page “Documents” shows the documents that produced.
As a COMMON document is produced from many profiles for the same trade account, the discount profile in which each (item) line was based on, is transferred to the documents’ lines (at the “additional item line” table).
How to check the implementation of agreements
The available data (for filtering, grouping etc.) are the Trade Account, the Agreement, the Profile, the Item, etc. So, even without create documents, we take a full picture of expected discounts.
In this chapter will be examined the typical expenses scenarios and the data entry and monitoring method within the system. Additionally, will be examined the Cost Centers concept and the various methods to allocate expenses to them.
The guidelines and the examples are mainly based on the default product parameterization, as far as the documents are concerned, the transitions, the screens layout and the information tools.
In order an expense document to be created, the following ways are available:
For these expenses that are typical – repeatable, it is preferable that appropriate shortcuts to be created (e.g. Rentals, Electricity, Telephone, Subscription, Payroll etc.), where:
- Document type, creditor and the expense will be ready – already entered
- If the amount is fixed, it must have been also entered at the lines of this “document-template”, in order the user to put minimal effort
- The document series, preferable to be removed, just before is “sent” to the shortcuts.
Remind that the shortcut is created through the “Actions” menu of the document (at its horizontal toolbar). During create shortcut, the current DATA of the document stored as it is, ready for every future use.
- For petty expenses, when immediately paid and we do not wish the Creditor to be updated:
Appropriate document type: BXP (Expenses, interests and other bank payments)
When we want the creditor to be updated, even when he is immediately paid:
Appropriate document type: XPD (Debit note)
This document may be issued as “on credit”, i.e. the payment occurs later with a separate document. In general, this is not a common case. We usually have “on credit” at Invoices, and not at Receipts.
The default format of the Expenses document is the following:
|Type and Document Series||
Information for Expenses documents customization
As far as the default Payment Cash register is concerned, this is determined to the document series, to the Liquidity accounts list of the series:
In the general case, it has been opened ONE cash liquidity account per Branch and this is the default payment account to the documents in cash. Especially for the “automatic payment” account, could be defined on a series basis, IF:
- It is fixed (ONLY the specific account): Used when each job position corresponds to a separate cash register, where balance counting and monitoring is accomplished.
- It is not fixed, but it may be used any other account of the same Branch (ONLY acct. of the same branch). This is used when the separate cash registers to the same Branch can exchange money and the counting and control occurs in Branch level. Even when each cash register of the branch is separately monitored, the expense may be entered from one work position but the payment to occur with cash of another Cash register. Here, we enable the payment from the actual Cash register, without a “cash transfer” through a particular document to be necessary.
- There is no constraint. When we may need this? While the expenditure registration logically is made from document series of each branch (for correct statistics and cost control at branch level), but the actual payment may be obtained from the headquarters. In that case, the main cash register must defined as payment account to expense documents of other branches, thus we release here the cash account selection to the user, in order to get correct cash balances, without unnecessary cash transfers.
The same functionality is available for the FORECAST account that is used in transactions “on credit”. This influences the way obligations will appear (outstanding expenses) per branch.
How do we see the results of issuing Expenses?
||Expenses Documents||List of all expenses documents.|
||Trial balance of items-expenses||
Statements of accounting format with the expenses credit/debit of the selected period and progressive totals (with drill down to the detailed entries, available to “Account statement” reports too).
||Purchases & Expenses Journal per VAT rate||
||Creditors Trial balance||Accounting format balance and similar statement, with the detailed entries.|
||Purchases and Expenses per branch||
Cube analysis per branch, where all horizontal dimensions are also available.
As much, the horizontal dimensions as the PERIOD can be moved to the cube dimensions. The Stock and Fixed Assets purchases data may be removed from the layout (through the “data” option).
Appropriate document type: XPI (Invoice)
Technically, the only difference from the Debit Note (XPD) is that it updates the State Reporting. It may contain cash payment or not.
An example of the accounting entry generated when the invoice in “on credit”:
An example of the accounting entry generated when the invoice is “in cash”:
Services Credit Note
It is issued in cases of mistaken debit from the company’s creditors. It may contain cash receipt or not.
- When there is money return at the same time and we do not want the Creditor to be updated:
Appropriate document type: CNC (Credit note with payment)
When we want the Creditor to be updated, even if paid at the same time:
Appropriate document type: XPS (Credit note for expenses)
An example of the accounting entry generated:
If it is a receipt (does not update the State Reporting), we use the XPE document (Expense Credit Note (receipt))
If we want posted with negative values (just like a cancelling document), must use the document type:
Appropriate document type: XPC (Credit note)
An example of the accounting entry generated:
If it is a receipt (does not update the State Reporting), we use the XPR document (Credit note for expenses (reversal))
Such a dispense transaction occurs in cases where the materials (inventory items) are consumed from the enterprise itself. The “recipient” is an employee or a department of the company.
Appropriate document type: SDN (Self-dispense Note)
Data concerning the transfer (WH, Shipping method etc) can be entered to the “Transfer data” sub-page. It updates inventory quantity and cost of grants and at the same time the expenses (in accounting). It does not participate to Revenues reports or Expenses reports, but just to the Stock Book reports.
In Accounting, it equally updates revenues and expenses.
During the stock valuation process, if in the end it has been calculated a different cost from the one defined to this transaction, cost correction entries are generated (reverse of self-dispenses estimated cost and registration of the finalized cost, after stock valuation).
When such a transfer cancelled or a mistake occurred or the item returned to Stock for any reason, the following document must issued, which makes exact the same entries of a reversed sign:
Appropriate document type: SDR (Self-dispense Return Note)
In cases where the recipient is customer, see the documents and the workflows used to the related chapter concerning free grant (sale).
Self-dispense customization information
- If the VAT of the self-dispense will be calculated or not (on the cost value), it is determined at document type through the activation of the “Calculate VAT” setting:
- If a Delivery Note is issued, the same prefix with all other Delivery Notes, can be defined to the document (common numbering):
The rental payment entries issued into the system either by a simple debit note and then, separately the payment receipt or, at the time of payment, through a single document.
The documents that are used are these of the Receipts or Services invoices (XPI, BXP etc.) described at the previous chapter.
Rentals customization information
We recommend to create:
- The owners of the properties rent, as Creditors.
- The rental expenses to the expenses file either as one or separate codes per property.
As far as the rental stamp duty is concerned:
- It must be opened as a special account of “tax” type which is “depending on item” and is a “Stand alone” line
- To the expenses document types, this account must be added the “Charges/Withholding” sub-page
- The account must be incorporated to a special accounts group of “tax” type
- The group must be defined to the items-expenses “Rent” to the “Special taxes group” field.
Appropriate document type: ΧΡΙΤ (Expense Invoice (for transportation means))
This document differs to the other used for the expenses, only as to the layout:
Transportation means’ customization
The transportation means must opened to the vehicles table (Customization/Transaction parameters). To the related fixed asset (if it is monitored to a fixed asset) the vehicle can be filled to the homonymous field of the fixed asset register.
By completing the vehicle to the expenses lines, we can have a full cost overview at any time (insurance, service etc) from the “Fixed assets/Information/Vehicle expenses” choice:
- The actual expense column shows the net value except if it is about a non-deductible expense (e.g. leasing) so it shows the total value.
For register an Invoice issued by a freelancer, we usually use the XPI, XPD or BXP documents.
These transactions involve some withholding, such as Engineers payments subject to withholding tax of 20% (implemented as a "withholding” on the payment value). The relevant customization should be:
Opening of Special accounts “depending on trade account”
Opening of related group of special accounts of type “withholding”
Definition of the withholding group to the Creditors’ (freelancers) register
Definition of the special accounts to the expenses documents types to the “Charges/Withholding” sub-page.
Certificates for Services provided
From the “Accounts payable” reports, these Certificates are automatically issued, for any legal use.
The report printing occurs through mail-merge for the selected trade accounts after a template word text is selected.
The report uses two company parameters (to the “Self-employed persons certificates parameters” category):
To the 1st parameter it is entered a (comma separated) list of profession codes concerning the certifications issue and
To the 2nd parameter is entered a (comma separated) list with ledger accounts mask which is updated by the SPECIAL accounts that will participate to the report calculation (it is required that the “GL code” field to the related special accounts screen, is completed). This is required in order the particular amounts only (and not any transactions related to the trade account), to be taken into account.
Instruction,: When we want e.g. a particular withholding type that it is referred to a particular Civil Service, we just have to complete the “special accounts” criterion. The same handling needed, when we only want particular creditors. Both special accounts and trade accounts are available criteria to the filter.
Expenses with company’s Credit Card
The expenses documents paid through company’s credit cards, given to the Accounting department by the cards’ users. In order to have a full monitoring and control of these expenses:
- For each card, it must be opened a Liquidity Account to the name of the Beneficiary.
- The expenses registration must be in cash with the usual documents (XPI, XPD or BXP) which are used for the other expenses cases. There must be defined the “payment liquidity account” that corresponds to the card user.
You may open special payment methods, with the particular liquidity accounts being ready and just select the corresponding payment method (of the card’s user) to the header.
The payment of the card account will be inserted through the BCT (Cash deposit) document for the deposit of the amount due, from the Cash register or a Bank account to the Card account. To the header we insert the Liquidity account FROM which we pay and to the document line the Liquidity account of the card that we pay.
This entry will “close” the Cards’ liquidity account statement:
The deposit of any additional Bank charges will be issued through a expenses document in cash, to the creditor “Bank” (e.g. BXP), where liquidity accounts of company’s cards, are not involved. Into this, the additional charge will be inserted as an expense.
When we want to monitor a credit limit to these company’s cards, we could define it through CLC document (Corrective entry for liquidity account (Credit)) at the beginning of each year, so it would appear to the “Credit” column (in Balances & Statements) and cancel it at the end of each year.
In this case, to the Liquidity Accounts statements, to the credit column, we check for any credit limit excess. The balance of these accounts after each payment will not become zero, but equal to the credit limit.
Banking Interest expenses
Appropriate document type: BXP (Expenses, interests and other bank payments)
The result of this entry will be the update of Cash (credit) and the Expense (debit).
Bank interest expenses customization
- The banks must be opened as creditors.
- The charges from interests must be opened as Items-Expenses.
Obligations to the employees
Appropriate document type: XPD (Debit Note)
We use a creditor “Wages and Salaries” (Obligations to the employees) which has been opened for general use, for anything related to the company’s employees.
To the expenses, we open the related accounts of fees and contributions (with zero VAT.). To the expenses lines we insert all the debit amounts to these accounts.
To the special accounts, we open (“Stand alone”) withholding accounts (insurance funds, tax payments in advance etc.) and we connect these to the document types, in order to be selectable. We select them to the special accounts lines and we type all the credit amounts.
When the document is posted, it is produced a payroll entry for the period whereas at the same time the creditor (to the creditors sub-system) shows the amount is due and the expenses sub-system has been updated with the Payroll expenses of the period.
Appropriate document type: CPS (Cash payment (to suppliers))
When we deposit the payroll, we use the same creditor “Wages and Salaries payable” and to the lines, the Cash register or the Bank account from where the payments occur, and as amount, this creditor’s balance.
The result will be a debit to the creditor (balanced) and a credit to the Liquidity Account (Cash or Bank).
Payroll advance payment
Appropriate document type: CPS (Cash payment (to suppliers))
If an employee asks for an advance payment, we issue this receipt, where we use the general creditor (“Wages and Salaries payable”) to the header, and the Cash account (branch cash register) to the lines.
We may open the employees using a horizontal dimension (dimension 1 or 2) and to select the particular one to the header (sub-page “Administration”). Since the Payroll is inserted in summary, the update of the cost center with the amount of the advanced payment, will not give to not authorized users the information of the salary per employee, but just of the advanced payments.
Clearance of payroll advanced payments
After the Payroll entry of the period is registered with the total of the salaries due, and before the payment, we insert virtual cash return to the cash register from each employee that received an advanced payment:
Appropriate document type: CRS (Cash receipt (from creditor))
Appropriate transition: 203. CPS => CRS (Cash Receipt from Cash Payment)
The general creditor “Wages and Salaries payable” is used again.
After that, the payment occurs for the total payroll amount, whereas to the detailed report that we prepare with the deposited amounts per employee (usually for send to the bank) we exclude the amounts of these returns from their salary. We can view the advanced payments from the general creditor’s (“Wages & Salaries payable”) statement, by grouping per cost center (e.g. Dimension 1).
Expenses advanced payments & clearance
In this case, we advance money to an employee for a trip, for example, and then, based on the expenses list provided by him a clearance process occurs: either he refunds the remaining amount if he has spent less or the Accounting pays the difference, if he has spent more.
Expenses advance payment
Appropriate document type: CPS (Cash Payment)
The employee (e.g. a salesperson) will be opened as a creditor that must used at the receipt’s header. At the document’s lines, we use the cash liquidity account of the particular Branch and we enter the amount paid. To the creditors’ statement, is created a debit (negative) balance.
Receipt of expenses documents
When the employee brings the documents (invoices or debit notes), these will normally inserted into the system with XPI or XPD document types (caution! without payment). The result will be a new credit to occur for each of the creditors, i.e. they will obtain a credit balance.
In order the clearance to be feasible, these obligations must be transferred to the employee that had paid these).
Appropriate document type: TOC (Account credit balance offsets)
The creditor-employee is defined to the header and the suppliers or the creditors with the amounts of the received invoices, to the lines. The result will be the “balancing” of the various creditors of the expenses and the “Creditor-Employee” to present a balance through the following transactions:
- Debit due to advanced payment (MINUS)
- Credit due to expenses (PLUS)
The balance remaining represents the amount of CLEARANCE.
- If the amount of the advanced payment is greater (debit balance), it will occur a money return from the employee to the Cash register through the CRS document whereas
- If the amount of the advanced payment is smaller (credit balance), it will occur an extra money deposit to the employee through the CPS document.
The creditor-employee register will “balance” then (will become null for the Date of clearance).
Expenses per cost center
The expenses allocation processes to Cost Centers through Cost Accounting Ledger (using allocation sheets and allocation rules to draw up corporate results) are described to the related chapter, to the Accounting Tasks unit.
If Cost Accounting is not in use, the system’s “horizontal dimensions” could be used in a way that expense transactions would “split” into cost centers (represented by one dimension or a combination of dimensions) and then, review results through views, cubes, BITs and reports of Expenses sub-ledger or General Ledger, the majority of which is available BY dimension.
Allocation through rules assigned to Expenses
The allocation (to company’s dimensions) profiles defined through Tools/Customization/Organization parameters/Business dimensions/Allocation profiles:
An allocation profile contains:
Conditions. They consist by a validity date range and a set of values of system’s horizontal dimensions. During applying the profile, the condition must be checked by the system and if only fulfilled, the default allocation will be generated.
Allocations. An allocation is a set of lines for each “condition” that contain WEIGHTS or PERCENTAGES (to be applied to the expenses amounts, during issuing documents) and a set of values of dimensions that represent COST CENTERS. If “number” selected as a “weight type”, instead of % percentage (like at the above example where the number of employees is the allocation criterion), these numbers will be converted to % percentages (weighted as to their sum) during actual allocation.
To define a dynamic allocation rule, can create a view (into the folder Variable Allocation Views-> ESGLAllocationDynamic) for example “Revenues per business unit”, and declare it to the “Dynamic allocation view” column of the conditions part of this dialog (making it visible by “add/remove columns” functionality):
Into this view, the columns must have predefined names: Dimensions as Project, Business Unit, Activity, Dimension1, Dimension2, Site, Date period for compare to the date of source transaction as DateRange and Numeric column that gives the allocation ratio as Weight.
If a dynamic allocation view defined, allocation lines not allowed.
The allocation profiles may be assigned to the expenses, as a default.
Finally, to the Item’s control profile (that the expense belongs) must define “compulsory allocation” in order to requiring the user to define or check the allocation:
During issuing an expense receipt, the allocation will be generated automatically:
- On demand (using the command “allocation to cost centers” from the vertical toolbar to the expenses part)
- During saving document, if an allocation profile found to each expense included (otherwise, storing will fail)
Into the allocation dialog, the user might edit the allocation, add or delete lines, change dimensions, amounts or percentages. To the bottom part there calculated the totals in amount and percentage, as well as the remaining amounts “for allocation”. Cannot exit with an “accept”, without a 100% allocation of the line amount.
What will happen after posting the document is that, every transaction generated from lines to the Expense sub-ledger and to the Accounting, will have as “source” these allocation lines, so a document with ONE line, will be illustrated with MANY transactions as to the updates (provided that defined more than one cost centers).
If exiting this dialog, the allocation degenerated into ONE line of 100% (surcharge only ONE cost center), then, the dimensions will just be transferred to the parent line (expense line).
On the other hand, an expense line will ALWAYS have zero values to their dimensions fields, for those dimensions that defined to the allocations.
To the Transaction/Expenses menu, the process “Apply cost allocation profiles” could run in order to generate massively any missing allocations. This process needed:
- If the allocation profiles configured after registering Expenses
- If into the Item’s control profiles the “compulsory allocation” setting was deactivated, so documents allowed to be issued without declared cost centers
- If wish to overwrite existing allocations using a specific allocation profile
We can define various criteria for detecting the expenses to be allocated. If we wish to recalculate the allocations must activate the “deletion of existing allocation” setting. If to the “Use profile” field select “specific”, then, we must declare this specific profile to the next respective field.
Allocation through time sheets
If some expenses charge the cost centers based on labor hours or on machine hours, then could registered the time sheets through the following “internal notes”, that will lead to an “allocation rule”:
Appropriate document types: INW (Internal Note of work hours recording)
INM (Internal Note of machines hours recording)
These notes displayed from “Transactions/Other offset entries/Various internal notes” and entered through the main toolbar option “Internal Processes”.
For instance, it may be issued for a person (the persons here, opened as creditors, since in cases of external partners, it is compulsory anyway) the total working hours per project in detail or summarized per day or month, with tasks (service-items), filling the “employment” (quantity) column:
As much these data per cost center as the corresponding per machine (fixed asset), if needed, will be able to be used as allocation criteria of “not allocated” expenses.
From the main menu Transactions/Expenses/Allocation of expenses to cost centers, we take an expenses report with various criteria.
The “actual expense” column equals either to the net value (if VAT is deductible) or to the total value (if it is not deductible).
By selecting (“marking”) the lines to be allocated, may select one of the ready automations, which by taking into consideration the internal notes of hours recording, of the same time range with the one of the selected to the expenses list, make allocation of the amount of each line by converting the “employment hours” per cost center to % allocation to these.
Allocation to Cost Centers based on working hours (with replacement)
A dialog appears for the selection of the “horizontal dimension” (Project, Business Unit, Activity, Dimension 1, Dimension 2) which represents the cost center for which “employment hours” have been recorded and for which must produced the analysis of the selected expenses. By pressing “Accept” to this dialog, each “original expense line” will be replaced from as many lines are needed in order its value to be attributed per cost center. To use this automation, the login user must belong to “user group for cost allocation to CC” defined to the company parameters.
To the particular month, we insert the working hours per activity for employees of each department, occupied to activities, through an Internal Note, using an item-expense for each line (which ignored to the process):
Based on these data per department, some ALLOCATION PERCENTAGES occur:
|Cost Center||Persons||Calculation||% Percentage|
In the same month, suppose we want the Marketing expenses, to be allocated based on this allocation.
This invoice with an expense WITHOUT VALUE to the “Activity”
has been modified from this procedure by obtaining 4 lines (instead of one) with the particular allocation into “activities”:
This allocation is feasible if only the expenses documents does not correspond to finalized Ledger Entries.
After the allocation is completed, the allocated expense lines are NOT displayed anymore to this list for cost centers allocation. If the process needs to be repeated, the field “allocated line” of the related expenses lines, will need to be disabled (value=NO). You can use the functionality of global modification through a DOCUMENT LINES view or through the “Expenses list” by selecting lines from the 2nd level (lines).
Allocation to Cost Centers based on machine hours (with replacement)
The process is exactly the same with the one based on working hours, but by using the internal notes of machines hours recording (INM).
Allocation to Cost Centers based on working hours (with reversal)
When the expenses have participated to reports that is not feasible (or desired) to be altered , the cost centers update process can achieved through reversal of initial transactions and creation of new with cost centers allocation. This automation produces new documents (ANW - Expenses allocation based on work hours) that implement these updates.
Start with the list of expenses to be allocated to cost centers, select the lines and then, choose this allocation process from the “automations” menu. In the appearing dialog, some new options are available:
besides all the other horizontal dimensions, the “branch” is also available for re-allocation of expenses (during “replacement” of expense-lines in the original documents, the branch cannot be altered, it is always the branch of issuing from document series)
For internal control and reconciliation purposes, the issuing date must belong to the same month with the initial transactions (e.g. end of month). Even if the information is NOT posted to Accounting, it will be difficult (if not impossible) to obtain any control, if these re-allocations issued to a next month.
In this scenario, the initial Expenses documents are not influenced. In the new documents, the “reverse” lines are reversing all the update results of the initial lines (to the NULL or WRONG cost center) and update the new cost centers from the beginning, using the data occur from the recorded hours, through the “standard” lines.
In this example, the ACTIVITY is selected as ALLOCATION dimension, and reported totally 40 hours to “Production” activity, 24 hours to the “Services” activity and 16 hours to “Administration” activity (through various “INW” to various dates of the month, by various persons). These hours are producing for the 3 activities a distribution 50%-30%-20%, thus, the automation generated the ANW document with CANCELLATION of the initial entry with the NULL activity (5,000.00€) and insertion of NEW entries with ALLOCATION to the 3 activities (2,500.00€ - 50%, 1,500.00€ - 30% and 1,000.00€ - 20% respectively).
By executing the “Expenses to be allocated” again, these expenses will NOT be anymore included to the list, and “original” expenses’ lines which have been allocated, are not modified or deleted. Only if the allocation documents deleted, the process can be repeated or the initial lines (“unlocked” anymore) to be altered.
The “re-allocation” documents ANW displayed to the “ Expenses corrective documents“ list, through the Transactions/Expenses menu.
Allocation to Cost Centers based on machine Hours (with reversal)
The process is exactly the same with the previous one, based on working hours but in this case, are used the Internal Notes of machine hours recording. In this case, the generated documents belong to different type (ANM - Expenses allocation based on machines hours).
Information for customizing the Expenses’ allocation through timesheets
To allocation processes which REVERSE the initial transaction, we can post the produced documents also to Accounting, (by updating the Accounting Journal to the ANW, ANM document types), in order the “per dimension” reports (between Accounting and Expenses sub-system) to give the same results. In this case, the generated entries, are negative for the reversed entries and positive for the new entries. Especially for the expenses with not deductible VAT, the VAT amount is ALSO transferred and allocated. The accounting groups used for posting are:
ES.0.EX.1001 Expenses Acc/nt (Cost determination)
ES.0.EX.1002 Expenses Acc/nt Contra (Cost determination)
ES.0.VT.1006 Acc/nt of VAT Expenses not deductible (Cost determination)
ES.0.VT.1007 Acc/nt of VAT Expenses not deductible Contra (Cost determination).
The work or machine hours recording, can be also achieved with any other way (through a custom D.B. table, through a project task implemented to CRM etc.), provided that the automations would properly changed in order to search the “hours” (or any other criterion) from the correct SOURCE.
By using the Internal Notes of work hour recording INW and INM, you can properly update the views of dynamic allocations used in expenses’ allocation profiles or in cost center accounts’ allocation profiles (where the criteria are not statically described to the allocation models, but are dynamically occur through definable views).
Costing of Imports
Through this system can monitored all the processes of goods import to the Warehouse, consisting from STAGES during which the cost of imports gradually formed. This means that, when an import case does not actually completed with a Goods Receipt and an Invoice from Supplier, but there are mediators who charge additional costs or if there is a customs procedure etc. then, the “cost determination” process is necessary, as it will properly allocate (using various rules) all the additional costs to the imported goods.
For each Import, a “Costing folder” is created. The two main concepts of a Costing folder are:
- Costing units. They are the imported goods of purchases documents (FNV or FIV) with the initial supplier cost (invoiced amount). They are the “units” on which the various additional costs should be allocated.
- Cost elements. They are the additional costs (fare, insurance costs, customs and taxes) that will charge the imported goods (“costing units”).
Especially, as far as the Imports from Abroad are concerned, there are two exchange rates used to the documents:
- Exchange rate. The bank exchange rate on the day of items’ arrival, based on which values conversion is enhanced (for official books update).
- VAT exchange rate. The VAT exchange rate to intercommunity transactions is used for values calculation for Intrastat statement. In other cases (imports from third countries) this rate is identical to the Bank’s “exchange rate”.
In the following, two other concepts are used, associated with Imports from abroad:
- Converted value. The original invoiced amount converted in base currency, using VAT exchange rate.
- Statistical value. The converted value plus the additional costs up to the borders.
Order from abroad & Import Folder
For each import case, must create a new Imports Folder (Entries/Purchases-Imports/Import Folders).
By inserting the order to the supplier, we can fill the “import folder” to the “Administration” sub-page of the Order document.
The result will be that as much the Order as all the other documents that will follow e.g. Goods Receipt Note, Remittances to Supplier etc. will appear to the “Documents” folder sub-page:
Purchase Invoice from a foreign firm
To the documents containing costing units (FIV or FNV invoices), it must be defined the Folder, to the homonymous header field, as well as all the information concerning values calculation (Currency, Exchange rate, VAT exchange rate). The items are displayed to the “Cost units” page of the folder.
To these Invoice forms, the “sub-pages” of the usual Purchases documents have different layout in order to appear to the 1st sub-page, all data fields which participate to the related reports and calculations e.g. Exchange rates, Folder, Delivery terms and Trade nature.
The buttons to the bottom part of the screen lead to some of the most frequently used functionalities:
- Full supplier data, which leads to the supplier data administration screen
- Financial data of the supplier, which leads to a dialog of summary financial data (plafond, balance etc.)
- Supplier Detailed entries, which leads to the supplier statement report, with all his transactions.
- Accounting entries, which leads to the related ledger entry (if the document is already posted)
- Invoice history log, which leads to chart illustration of document’s progress (related documents).
The result of posting this Invoice to Accounting is the following:
|General Ledger||Supplier||ES.1.TA.0001||Total value|
|Current assets orders (Folder account)||ES.1.CF.0002||Total value|
In case of charging additional expenses by the supplier (in the same invoice), which are allocated to the goods received as additional cost, we can use one of the following methods of issuing:
- Either with a charge special account e.g. “CF-TRS”
- Either with an “expense” generic item (to the corresponding lines sub-page). In this case, in order it to be allocated to the items and to influence their final cost, the expense item must belong to the appropriate “cost element type”, that describes the cost allocation method, as explained at the end of this chapter.
The «VAT exchange rate.» (which is differentiated from the Bank exchange rate only in the case of Imports from the EU) is recommended depending on the VAT Exchange rates Table, defined to the Bank Exchange Rates Table which is further defined to all documents types and based on which, the “Exchange rate” is suggested to all of the same currency, transactions. The tables are defined to the Parameterization and the Daily Exchange Rates are imported through Internet from a special time-schedjuled task (Periodic processes/Currency exchange rates).
Besides the General Ledger update, the result of this Invoice entry is the update of suppliers’ statement and of our obligations to him.
The warehouse is not updated (by value). This will occur during the (temporary or definitive) closing process of the Costing (Imports) Folder, that will be later examined.
The receipt of the imported items when the Import procedures are completed and the Invoice is ALREADY received and registered to the system, thus will need to be inserted through a transition:
Appropriate document type: PLN (Goods receipt Note)
Appropriate transition: 110. FIV => PLN (Goods receipt Note from Invoice by a Foreign Firm)
The Goods Receipt Note appears to the “documents” sub-page of the Import Folder.
DO NOT “reverse” the documents actual order, trying to “fit” to the usual process of Domestic Purchases, as in some cases (e.g. Fixed assets Import from Abroad) can create problems or the need for additional documents’ customization (beyond the ready-system customization).
Issuing of import’s expenses
The expenses documents (XPI) which put additional value to the Import, are issued in the same way as all the other expenses cases, and the only difference is that the Import Folder must be defined to the document header (to the «Administration» sub-page). This information will be used as much to the document posting as to the Cost determination process.
The Folder is transferred to the expenses lines and can be differentiated per line, for cases of common expense invoices for many Folders:
Thus, a line of an expenses’ invoice can surcharge one import folder and another line another folder.
The expenses concerning each import, are displayed to the “Cost data” page of each folder.
The accounting result of issuing an Expenses’ Invoice referred to Import Folder/s is:
|General Ledger||Creditor/Supplier||ES.1.TA.0001||Total Value|
|Current assets orders (Folder account)||ES.1.CF.0001||Net Value|
|VAT of Import Folder Expenses||ES.1.VT.1007||VAT value|
Especially in case of Imports from Third Countries (outside EU), the Invoice of the agent and Customs declaration, must be registered:
Appropriate document type: CUD (Custom declaration from Third Countries)
- This document has special layout in order to enable (make easier) the entry of various value types (Statistic value, taxes, other custom expenses etc.) of goods customs clearance.
- The Creditor in this document is usually the Customs clearer
- The Folder must be defined to “Administration” sub-page.
- To the Custom Declaration are reported the total Statistical value and the VAT of this value paid to the Customs Office by the agent. Independently of any other calculations that may have occurred (by the folder’s processes) for cost’s defining, these values must be typed INTO THIS document, in order Accounting as well as our Obligations, to be properly updated. Use the appropriate item-expense for the Statistical value of the related VAT ratio (default items CF* -> Statistical value of imported Χ%).
If there are ALREADY issued Expenses Invoices that concern the Statistical value (participating to this value), BEFORE the Custom clearance entry, you must execute the “Calculate Distributions” task from the Folder “Actions”.
During the Statistical Value typing, is automatically achieved the calculation of the “Statistical value difference“ in order, only this value, to be allocated as an additional cost to the imported goods. This value is the difference between the calculated Statistical Value of the folder (which has been configured from the various Invoices) and the Statistical Value referred to the Custom Declaration of the customs office (defined exclusively at this point, in the “CUD” document).
To the SAME document, are reported the taxes and other customs expenses. For these expenses, (expenses list of customs clearer) of which the original data are attached, there are 2 cases, since paid to the agent (customs clearer):
To not concern the summarized State Reporting, thus, are inserted into the SAME document (CUD) without the information of each contracting partner, and then our obligation will ONLY concern the customs clearer (of the header) for the total expenses.
To concern the summarized State Reporting, thus, the expenses must be inserted with the usual expenses documents (XPI, BXP). In this case, an offset entry of the obligation TRANSFER from the other creditors to the customs clearer, must be inserted (TOC – Account credit balance offsets).
The accounting illustration of the Custom declaration document, is the following:
|General Ledger||Creditor/Supplier||ES.1.TA.0001||Total Value|
|Third Countries Expenses||ES.1.CF.1002||Expenses net value|
|Expenses VAT of Import Folder||ES.0.VT.0004||VAT value|
|Current assets orders (Folder)||ES.1.CF.0001||Net value|
|VAT Account of Customs declaration (Third Countries Folder)||ES.1.VT.1008||VAT value|
|Account of Statistical Value Difference||ES.1.CF.1001||Statistical value difference|
|Account of Third Countries Expenses||ES.1.CF.1002||Statistical value difference|
|Informative accounts||Arrivals Account (Customs clearance Value)||ES.0.CV.0003||Statistical value|
|Arrivals Account (Customs clearance Value)-Reverse||ES.0.CV.0004||Statistical value|
Since the Suppliers’ Invoice and the various Expenses documents have been “connected” to the Folder, the Cost determination process (the final cost determination of the imported goods through expenses allocation), is accomplished through folder closing. This process produces costing entries for the Inventory update. Before closing, the Inventory is NOT updated with the (initial) cost of the invoice from abroad.
There are two closing types (Temporary and Final), each of which can be cancelled and re-executed, in cases where parameterization has changed (the expenses allocation method) or if we received an additional expense document or if a mistake occurred. The difference between the Temporary and the Final closing is only the capability of using a different Purchases account (forecasted Purchases e.g. 2?.99*) instead of the standard accounts (2?.00*) and also the fact that through the Final Closing, the folder status becomes “closed” so, it is not allowed to connect new expenses to the folder. The activation of the closing process is achieved through the “Actions” folder menu. The result of the process is:
- Creation of “Import Costing” document which is presented to the “Documents” sub-page and to the “Imports costing documents” list for all folders through main menu (Entries/Purchases-Imports). This document creates a cost entry to the Inventory Records, which allows the execution of the Stock valuation process, providing correct results.
- Creation of cost elements analysis to the imported goods, which displayed on 2nd level, under each item line (per %VAT) to the “Cost units” folder sub-page.
Update of the “Costing” folder sub-page, which displays an estimation of Sales Prices re-adjustment based on the new definitive cost of each imported item.
The closing process creates two (2) Accounting entries, one (1) to the accounts of the General Ledger Chart and one (1) to the accounts of Informative Chart of Accounts, depending on the Folders’ Types configuration (see. Unit with parameterization information).
The accounting ledger entries can differentiate, depending of the origin country (European Union or Third Countries).
For an Intra-Community import, the entries are as follows:
|General Ledger - Purchases||Current assets orders (Folder)||ES.4.CF.0010||Total Value|
|Intra-community acquisitions||ES.4.CF.0001||Converted invoiced value|
|Expenses of Intra-community acquisitions||ES.4.CF.1000||Additional cost|
|General Ledger - Statistic VAT||Statistic purchases VAT||ES.4.CF.0001||VAT value|
|Statistic purchases Debt VAT||ES.4.CF.0002||VAT value|
|Informative accounts||Intra-community goods acquisitions VAT exempted||ES.0.CV.0001||*Statistical or Converted invoiced value|
|Intra-community goods acquisitions VAT exempted - reverse account||ES.0.CV.0002||* Statistical or Converted invoiced value|
*the type of values monitored to the Informative accounts, depends on the folder type customization.
For an Import from Third Countries, the entries are as follows:
|General Ledger - Purchases||Current assets orders (Folder)||ES.4.CF.0010||Total Value|
|Acquisitions from Third countries||ES.4.CF.0001||Converted invoiced value|
|Various Expenses of acquisitions||ES.4.CF.1000||Additional cost|
|Informative accounts||Arrivals Account (Converted invoiced value)||ES.0.CV.0001||Converted invoiced value|
|Arrivals Account (Converted invoiced value) – Reverse||ES.0.CV.0002||Converted invoiced value|
|Arrivals Account (Detailed expenses values)||ES.0.CV.0007||Expenses value|
|Arrivals Account (Detailed expenses values) – Reverse||ES.0.CV.0008||Expenses value|
Costing Folder configuration info
- Folder type
Each import folder “belongs” to a “TYPE”. The type is a required customization element which describes the way of update of Inventory and Accounting, by the Folder Costing.
|Units type For cost determination||
|Costing units document type||
|Statistical VAT update||
Through these settings decided WHEN and IF the VAT of statistical value will be updated
|Update Informative accounts||
It can be defined, either to the final or temporary closing or to both. If you do not activate any of these 2, then, the primary documents (FIV or CUD, XPI etc.) will create off-balance sheet entries depending on the next field value and provided that, the “Informative accounts Journal” in not null, otherwise, no entry will be created to these accounts.
WITH WHAT VALUE?
|Informative accounts Journal||In order the update to be accomplished, a check is preceded if the Journal field has been filled. If not, the application does NOT create entries to the Informative accounts.|
These are the transitions being executed during the final or temporary closing. The necessary transition rules are contained to the default parameterization and produce the following documents (depending the type of closing):
IFC Imports Costing (used by definitive closing)
ICF Imports Costing – Forecast (used by temporary closing)
IFR Imports Costing – Reversal (used by definitive closing cancel)
ICR Imports Costing – Reversal forecast (used by temporary closing cancel)
|With detailed costs||During closing, if this field is activated, the expenses are transferred (in detail) to the closing documents (as “reversed” lines). In order to use the provided parameterization, this field, must be selected! The implemented posting method, implies the existence of the detailed expenses lines to closing documents.|
|Carry source expenses||During closing, if this field is activated, the initial expenses are transferred to the closing documents (with the allocated net value and the related VAT, in order to be used in special customizations and to meet special requirements , when desired).|
If you have all cases combinations (Imports from EU and from Third countries AND either through a single document for Invoice and Goods receipt or – other times- through separate documents), then, 4 folder types are needed: two folders for the intra-community transactions (for FNV & FIV) and two folders for the Third countries transactions, respectively:
Obviously, the above folder properties are functional, only if used from the respective “update profiles”, otherwise they are just informative. The current system’s configuration uses these properties, but if you have a different customization, you need to undertake alterations, in order to take advantage of them.
Cost element type
Each expense (cost element) which can be “connected” to a folder, it belongs to a TYPE. The cost element type describes the way that the expenses (belonging to it), must be allocated to the costing units.
For the cost elements types list, see Customization/Cost Folders. The starting D.B. contains the most frequently used types with the suggested allocation method:
The cost element type management screen is shown below:
The starting DATABASE contains preconfigured cost elements (the generic items-expenses with a IF* code) belonging to the default cost element types. Please check them before use:
Costing of domestic purchases
When various additional costs concerning a purchase from a domestic supplier, are charged from someone else e.g. the shipper, a 3PL company etc., which issued through SEPARATE INVOICES, we can use the Imports Costing Folder, in order goods final cost to be calculated, taking into account all these additional expenses (through cost element types and application of the allocation process).
The functionality is similar to the one of the Import from Abroad.
- A folder type is opened for the Domestic Purchases.
- Since we receive the Purchase Invoice PIV (or a PNV – Purchase Invoice/Goods Receipt Note), the folder can be opened and the Invoice to be connected.
- To the Expenses Invoices, the Folder must be selected as it happens with the expenses, for Imports from Abroad.
- With “distribution” and (or only) folder “closing”, additional cost items’ entries are produced and at the same time, the expenses are reversed into the Expenses sub-system (since “transferred” to the Inventory cost value).
The differences from a Folder from Abroad are
- It is NOT used interim “folder” account,
- There is no (or sense) “Temporary closure” and mainly,
- The Inventory is updated from the beginning by the Supplier’s Invoice, whereas all the expenses are added during “cost determination” as Purchases corrective (additive) cost entries, as it could be done by a PDV – Additional Purchases Invoice).
In Accounting, the expenses when created, update an “Expenses Account” and the corresponding “Expenses VAT Account” (the use of special items IF* is not required) and, when folder closure occurs, these entries are reversed and transferred to the Purchases Account and the corresponding Purchases VAT Account.
|General Ledger||Purchases Account||ES.4.CF.1050||Net Value|
|Revenues VAT Account||ES.4.CF.1060||VAT value|
|Expenses Account||ES.0.EX.0001||- (Net value)|
|Expenses VAT Account||ES.1.VT.1007||- (VAT value)|
Costing Folder for Domestic Purchases Configuration info
- In folder type, must define the “Category” field as “Domestic purchase” and activate the “with detailed costs” field:
The documents used are:
PCD Purchase Costing
PCR Purchase Costing - Reversal
The transition rules used are:
For the case of a discrete Invoice and Goods Receipt Note
486. PIV => PCD
488. PCD => PCL
For the case of single Invoice-Goods Receipt Note
487. PNV => PCD
488. PCD => PCL
The expenses that will be used to this process, must be explicitly created and belong to specific ‘purchases” cost element types, in order to achieve the appropriate method of cost distribution.
Import and customs clearance of transit warehouse
For the temporary storage, must create specific warehouses which operate in the same way as the other regular warehouses, without any special property (field). The handling of Customs Clearing Reports per Storage Unit (Lot), is not achieved through the sub-system. Here, it is monitored the costing issue, exclusively.
When moving from such a warehouse to a regular warehouse (paying customs duties and receiving the goods “free” from any duty regime) some additional charges are charged and the “Transit folder costing” must be used in order the items to be inserted to the regular warehouse carrying their whole cost, with their additional charges.
For these transfers to a “regular” Warehouse, a specific document type must be used:
Appropriate document type: IDC (Stock transit with charges during export)
The items must be opened twice: One for the “transit” items and one for the “free” items. This is necessary as they have separate cost valuation process. Another method is to define as a branch with “independent” valuation this customs Warehouse (temporary storage).
- Open a folder type of units type “Transits”, where the “IDC” will be defined to the “document type for costing” field.
- Create cost element types for the clearing customs duties or other expenses that put additional costs. The cost element types must be filled to the appropriate item-expenses, to the homonymous field.
- The ”transit» items are imported to the “transit” warehouse through the Import (from abroad) process, and they take final acquisition cost, through Imports Costing Folder.
- Open a Transit Folder for each export occurred through this Warehouse, from the Entries/Warehouse/Transit Folders menu, and the export will be defined through the ”IDC“ document, which displayed at the ”Stock corrective documents” list. To this document header, must define the Folder and the “transit” Warehouse. In the 1st grid of items, declare the item codes that are imported to the “regular” warehouse (free from duty regime) and in the 2nd grid, declare the corresponding exported items (“transit”). The Branch and the WH of the series, are transferred by default to the exported items.
- For make the data entry process easier in case of double item codes, may create a “relation” of each of these items with the “symmetric” ones. Connect the items with this relation, and give the “code” of the relation to the “Relation for auto-generate reverse transfers” field of the “IDC” document type (behavior sub-page).
The result will be, by defining an imported item in the 1st grid, the corresponding line to the 2nd grid, to be automatically generated (during save or through the Ctrl-Shift-F9 buttons combination use).
To the Expenses documents that we want to be allocated within the Folder, we must define the “transit” folder code to the header (to the” Administration” page) or, alternatively, from the “Cost Data” sub-page of the Folder, to ask “connection” and select the lines of the expenses documents that will be participate to the Cost determination process.
After these actions, the Stock Valuation process will properly correct the cost of the exported items as well as the “acquisition” cost of the imported items, after allocation of any additional costs (“connected” to the folder) executed. The posting of the Transit documents “IDC” must occur AFTER the Stock Valuation is completed. The accounting entries balance to the “header” account.
If there are expenses which surcharge the items as long as they are under transit regime (before “transfer” becomes) e.g. storage fees, insurance fees etc, you must register them to the system, by using the particular inventory items and NOT the items-expenses. Consequently, it is the Inventory sub-ledger that will be updated and the not the expenses’ one.
Appropriate document type: PDV (Purchases Debit Note)
You may use a particular document series with the appropriate title.
In this chapter, will be examined the process of liabilities payments (to creditors, suppliers, employees, shareholders, social security funds, public organizations) through various methods (remittances, manual or computerized company’s cheques, cheques of our customers or cash), as well as the way of controlling and planning payments. Payments scenarios based on an approval process by authorized users, will be also examined.
The guidelines and the examples are mainly based on the default product parameterization, as far as the documents are concerned, the screens layout and the information tools.
In order a payment document to be created, the following ways are available:
With cash are usually paid …
- Petty cash. This entry occurs through the expenses documents (BXP - Expenses, interest and other bank payments) and not as “payment receipt”.
- Advanced payments to employees.
- Obligations of small value to creditors.
Appropriate document type: CPS (Cash payment)
|Document Type and Series||
How do we see the results of issuing payments?
||Payments’ documents list||List of payments (to suppliers and creditors) with amount separation to cash-deposits and notes columns.|
||Cash check statement||
Statement of receivables and payments per branch, user and payment method:
||Receivables - Payables||Similar to the previous information, with the format and the analysis functionality of CUBE.|
||Accounts Payable Trial Balance||The payments are displayed to the Debit of the Trial Balances and the corresponding Statements Reports with the detailed entries.|
Remittances to suppliers
Through the bank, occur most of the company payments such as, suppliers’ payment or advanced payments for purchases orders, Third parties’ payments such as telecoms, electricity, rents deposits, payroll deposit etc.
Appropriate document type: CPS (Cash payment)
The functionality and the operations are identical to those of the Cash payment with the only difference that, in payment lines, used Bank accounts (among liquidity accounts) and not Cash accounts.
The Banks are usually charge the Bank Charges which can be included to the same document, in order the Liquidities and the Payables sub-ledgers to be properly updated. These charges reduce the total amount of the deposit that will be transferred to the supplier’s register.
Suggesting a fund transfer to Supplier from our Bank account of 5.000,00€. The Bank charges 60,72€ for the transfer. We define to the deposit amount 5.060,72€ and a “Charge” of 60,72€. In order to define the additional expenses, we undertake “totals area maximize» to the bottom form part through the icon, and in this way the special accounts list becomes available:
The supplier will be updated with the difference:
The Bank Account will be updated with the actual outflow:
- There must have been opened “autonomous” Special Accounts of “charge” type with the % charge, if known, in order to be automatically calculated during the (CPS) deposit slip entry.
- The special accounts must be added in “Charges/Withholding” sub-page of document type, in order to be selectable.
Another method for funds transfer entry, is through a multiple remittances document from a Company’s Bank account to (many) suppliers with a common document for all of them, based on the Bank statement:
Appropriate document type: BSP (Remittances to Suppliers)
Such a document may be automatically generated after the processing of our liabilities to suppliers (and creditors) through the Payments scheduling process. Alternatively, can be manually issued.
To the header, give the Company’s Bank Liquidity account FROM which the deposits will occur and to the lines, give the particular Beneficiaries and the transferred amounts to each one.
Result of this entry will be the debit of the Trade Accounts and the credit of the Bank Accounts.
In this case, the transfer expenses will be separately entered with an expense document “in cash”:
Appropriate document type: BXP (Expenses, interest and other bank payments)
Payment with company’s cheque
Appropriate document type: NDT (Notes delivery Receipt)
The issue and delivery of the payable notes to suppliers is achieved through the (CPS) document type from the “notes” sub-page or through this special document type (NDT). Alternatively, it could be used the Payments scheduling process, which is appropriate for a mass handling of liabilities to be paid.
|Note type||The available types (with the appropriate information for posting) defined to “Customization”.|
|Code||In order to be able to issue computerized cheques, a code format in this field with automatic numbering, is recommended.|
The printed cheque’s number, useful to identify and to register a unique entry in Notes’ Book.
The number is automatically calculated during save, if, to the Liquidity account, is been activated the “Calculate cheque number” field and it has been given an appropriate “calculation type” to the “Cheque numeration data” sub-page.
|Issue date and Expiry (due) date||The Issue date is the documents’ registration date. The expiration (due) date indicates the exact time of cash outflows (from our Bank Account) and also updates the “Notes Expiration list”.|
|Payment Bank account||The account proposed is the Liquidity account of “Notes issue” (as the usual bank account from where we issue cheques) and causes the automatic completion of cheque’s “Issuing Bank” (next field). At payable notes the information is useless, but at receivable notes, the Issuing Bank could be different from the Bank of actual Payment (clearing).|
|Computerized||It is automatically activated, when the prerequisites for printing through the system (the process of print computerized payable cheques) are fulfilled. In a computerized cheque, Bank account modification, is not allowed.|
|Nominal Value||Since it is possible for a note to be in a foreign currency, the amount are available in both currencies as well as the exchange rate. The outstanding value (i.e. the value not paid yet) is updated (reduced) automatically, through the transactions.|
|Assignor||To the payable notes, it is not completed, it is our Company. To receivable notes, concerns the Trade Account from whom we take (receipt) the note.|
|Beneficiary||The headers’ trade account is automatically completed.|
|Issuer||It may be differentiated from the assignor only to receivable notes.|
|Guarantor||The possible guarantor existence is defined here, through the Persons’ file.|
The Status 1=Pending (i.e. not paid yet), is displayed as a default, based on customization.
|Holder/Position||The supplier is automatically placed.|
|Remarks & User defined fields||A number of reasoning fields, comments and of other types, are available for free use depending on the needs.|
By returning to the document line, the notes’ basic data are displayed. The system undertakes uniqueness control (based on customization) and warns or prohibits the entry, in cases where the same number is found to another note (of the same “type” and “nature”).
Also, it cannot be added a payable note of another beneficiary by mistake.
The functionality called “Print payable cheques” is available:
Information for customize Payable cheques Print
Through the same option, it is possible to export the template file for create a new print form.
How do we see the results of the payments entry through cheques?
||Records and Expiration list of notes payable||Statement of not expired yet notes-cheques, which have been issued and delivered to various suppliers (or, generally, to trade accounts).|
||Notes Payable Trial Balance||
Notes statement per supplier:
||Suppliers Trial Balance (commercial balance analysis)||
Trial balance with columns of notes debit and credit
Transfer of a customer’s cheque to supplier
Appropriate document type: NDS (Transfer of Receivable Notes to Supplier)
It is used for the suppliers or creditors payment through RECEIVABLE Notes on hand (issued by our customers or third parties). It can be also issued the CPS Cash payment, through the “Notes” sub-page.
In this document, instead of entering a new note, a selection must be done among the open receivable notes.
To the Beneficiary column, the supplier is automatically completed.
The result of this entry is the update of the cash OUTFLOW forecast with the same amount of the corresponding cash INFLOW forecast entry (from the customer’s note). The suppliers’ “accounting” balance is reduced, whereas the commercial balance remains the same:
The customers’ account (assignor of the cheque) will not be affected either as to the accounting or as to the commercial balance.
During the expiration date and the note final payment, and only then, it will be reduced the suppliers’ open notes (and his commercial balance) AND the customers’ open notes (and his commercial balance) at the same time.
Replacement of a cheque/note
The replacement of a payable note will need to be defined to the system with two separate documents, for the return of the initial and the delivery of the new:
Appropriate document types: RSN (Notes return by Supplier) (old cheques)
NDT (Notes delivery receipt) (new cheques)
If the replacement concerns a receivable note,
- If it is immediately returned to customer (assignor), then the workflow will be the following:
Appropriate document types: RSN (Notes return by Supplier) (old cheques)
NCR (Notes return to Customer) (old cheques)
NDT (Notes delivery receipt) (new cheques)
- If it is not returned to customer (assignor), but we intend to give the note to someone else, then the workflow will be the following:
Appropriate document types: RSN (Notes return by Supplier) (old cheques)
CTN (Cancel of transferring receivable notes) (old cheques)
NDT (Notes delivery receipt) (new cheques)
In all cases, we select the supplier to the document header.
The return (RSN) is negatively displayed to payments and to all the financial statements concerning notes:
To the suppliers’ Statement…
Is increased the “accounting” balance with a new credit, whereas the “trade” balance remains the same:
Especially, the Transfer cancellation is not displayed to the supplier’s statement, since it only updates the notes’ beneficiary (he is being abolished).
The liabilities that we paid by the note/s returned, are now displayed to the Unsettled (open) payables.
Thus, with the insertion (and return) of a cheque, the suppliers’ balance aging (DPO, Age analysis etc.) is not affected. Any new payment that will occur, will be “connected” (matched) with the liabilities that are now open.
- Actually, it occurs cancellation of the matching provoked by the note. This is based on the “refers to note cancellation” setting of the RSN document type.
We recommend that when various modifications happen, as the above, to use the “Note history log” functionality which is available to the Note screen as well as to any other Notes view e.g. List of Notes, Notes Book, Notes Expiration list etc. (“actions” to the horizontal toolbar):
Expiration of payable Notes
During payable notes expiration, the amounts necessary for their payment, are transferred to the related Bank account.
The monitoring of the liquidity needs is achieved through the Cash flow Review and from the Notes Expiration Lists.
If an account has NOT sufficient amount (“expected balance”),
then, we should transfer there, amounts from another account:
Appropriate document type: BCT (Cash Deposit)
To the header of this document, will be defined the account FROM whom we will transfer money (credit of liquidity account - cash OUTFLOW) and to the lines, will be selected the account TO whom the transfer will happen (debit of this liquidity account - cash INFLOW).
Based on the bank statement, it should be issued into the system all credit values of Bank Accounts to which the payable cheques correspond, at their expiration date, usually.
The transaction will occur through a “notes payment” document type, for update Liquidity accounts, Notes and Trade Accounts (for correct “commercial” balances of beneficiaries) sub-ledgers.
Appropriate document type: MPN (Mass payment of payable notes)
To the header, we select the bank account where the cheques belong.
To the lines, we select the particular cheques which are about to expire. The searching dialog displays those having the particular bank account as a “payment liquidity account”.
The result of this transaction to the Suppliers’ sub-ledger, will be the decrease of the “commercial balance”.
This means that only by the declarative payment of particular cheques, delivered to suppliers, their “commercial” balance will become equal to their “accounting” balance (on the day of payment-disbursement). For this reason, the payment must be achieved through THIS process and NOT through any other way provided by the system for debit or credit of Bank accounts.
The shareholders must be opened as Debtors. In Accounting it is NOT USEFUL to open accounts for shareholders in detail.
The payments can be inserted with a document allowing money payment (with fund transfer usually from a company’s Bank account) to many shareholders at the same time.
Appropriate document type: BCP (Remittances to Customers/Debtors)
To the header, we select the Bank account and to the lines, the Debtors with the amount of each one payment. The result will be the credit of the Liquidity (Bank) accounts the debit of the shareholders’ accounts.
In order to balance these accounts, we can be issue a transaction of type “credit note”:
Appropriate document type: SJC (Receivables credit note)
To the header, we select the debited General Ledger Account and to the lines, the Debtors with the corresponding amounts.
Payment of taxes & withholdings
The various taxes - withholding are illustrated as Special Accounts into the system. These are updated from the various trading documents and we either receive an amount (return) from the related Entities/Organizations (pension funds, tax office, other public institutions) or we pay (transfer) the relevant amounts to these Organizations.
Related entities (accounts) for clearing
Organizations or Agencies where we attribute taxes/withholding or from whom we receive money (taxes return etc.) e.g. Tax office, Social security, Prefecture, Municipality etc. must be opened as trade accounts and defined to Special Accounts that they concern (to the “Related organization” field).
When these organizations are monitored through account registers (debtor, creditor) with debit and credit transactions…
- Payments from/to them are issued through the usual cash transactions documents:
CPS Cash payment (to creditor) CPC Cash payment (to debtor)
CRS Cash receipt (from creditor) CRC Cash receipt (from debtor)
based on the related trial balances or the unsettled payables/receivables.
- The offset entry of balances closing for the related special accounts is achieved through separate documents (a kind of accounting notes):
ADB Special accounts debit note ACR Special accounts credit note
based on Special accounts Trial Balances for check the liabilities obtained by transactions, where they were included.
If the payment is accomplished by cheque, can be defined particular Ledger Accounts that each cheque “pays”. During posting, this “Account analysis” replaces the entries to be created to the creditor account, defined at document header.
Suggesting that for the Social security in Accounting, there are 2 accounts, one for the current obligations and one for the delayed obligations. The Social security will be opened as a creditor and at the payment cheque line, could be defined the “analysis of cheque amounts” to GL accounts to be posted, through F12 use. To the appearing dialog, define the accounts and the related amounts. In this way, we avoid opening eg. Creditors for each General Ledger account (when corresponds to the same Organization).
If these organizations are NOT monitored through account registers (creditor, debtor), the payment can be done through special documents for the financial settlement, which only update SPECIAL ACCOUNTS and LIQUIDITY ACCOUNTS (or cheques) …
If the Organization is a “Creditor” If the Organization is a “Debtor”
Appropriate document types: BRP (Tax payment) TDP (Tax payment)
BSD (Tax return) TRN (Tax return)
Since the trade account will not be updated, these document types undertake “Check payment of total amount”, which means that amounts of special accounts declared, to be exactly what the lines of cheques and liquidity accouns are summed (amount payable).
To the special accounts lines («Withholding/Expenses»), in order the user to be helped, the account balance is calculated and displayed (current and previous month). The searching displays those, from the permitted by the document type special accounts, having the headers’ trade account defined as “Related organization”.
To the cheques lines, can be created payable cheques and then, the header’s trade account is placed as their “Beneficiary”. In this case, a "commercial balance" is created to that trade account, until the cheque be paid.
For the receivables or payables control, there can be used the Trial Balance and Statement PER “Organization” (related organization) of the Special Accounts. In these reports, we see the way their balances were created.
To the above example, there was an opening credit balance, some credits of the special account of type “tax” through invoices and some debits through payments. One of these payments was made by cheque due 12/3, when paid (so the accounting balance equals to the commercial balance).
The full VAT monitoring achieved through Accounting. In order to monitor the company liquidity, concerning the reasoning of receipts and payments (through liquidity accounts sub-ledger), could…
- Open the VAT as a special account of “Tax” type, with “related organization” the corresponding Financial Service that will have been opened as a Creditor.
- At the end of each month, based on the Monthly VAT statement, derived from all the taxable inflows and outflows, to enter a credit transaction with the amount to be paid, or a debit transaction with the amount to be returned:
Appropriate document types: ACR (Special accounts credit)
ADB (Special accounts debit)
At the end, the financial settlement will be done using the documents for tax payment and/or tax return:
Appropriate document types: BRP (Tax payment)
BSD (Tax return)
Customization information as to the special accounts return/clearing
In order the documents for issuing payment/return of taxes and withholding (when there is no register for the related trade accounts) to function properly, i.e. BRP, BSD, TRN, TDP, these document types must have appropriate values to the following settings:
|Check payment of total amount||It must be activated, in order the total of the payment amount to be checked if it is equal to the amounts defined to special accounts lines. If the amounts are not the same, the document will fail during posting as the ledger entry will not be balanced (since, no debit or credit will occur to trade account).|
|Filter special accounts by related trade account||It must be activated, in order the selectable special accounts (among these which are allowed to the document) to be those having the headers’ trade account to the “Related Organization” field.|
|Calculate special accounts||For special accounts which are of “%” amount type, the calculation must be deactivated so, the amount to stay free for typing. The auto-calculation functionality is useful in other cases e.g. bank expenses.|
|Analysis of totals||To the “Totals options” in “Header” sub-page, the “analysis of totals” option must be deactivated in order the special accounts list to posses all the available space. This setting is ignored in case of a dynamic (user defined) form.|
Planning of payments
The organization and scheduling of payments recommended for a mass company’s debt management, leading to selection of those to be paid by various criteria, and the choice of how they will be paid, allowing the adoption of computerized cheques or transfers to bank accounts of creditors. These procedures include inter-company management (all debts of the group) and the possibility of interference approvals by authorized users before payments accomplishment.
The processes of mass management and payment of payables are activated from the Transactions/Cash-Notes/Planning of payments menu. The selection criteria are common:
Payments by computerized cheques
Through the “Create payments” the list of payables (liabilities) contains the following data and functionalities:
- The columns displayed are the code and name of the supplier, the total payable amount and the days of delay since the oldest open (unpaid) invoice.
- Using double click the suppliers’ screen will be displayed for further information
- In 2nd level (+), the analysis of unpaid debts is displayed with their detail data
- The user may configure the list and save the layout (). The list of available columns contains the date of the 1st and the last unpaid amount, the suppliers’ “Credit days” (for comparison with the days of delay) etc.
- The process can be transferred to the shortcuts, through the icon selection
- The list with its current data and layout can be printed through print preview icon selection.
It can be achieved determination of specific invoices to be paid through the 2nd level (“open items” analysis), instead of defining a total amount in the 1st level. This will affect the matching that will automatically occur. Otherwise (if amounts only given to the 1st level), the matching will be achieved in the usual way (FIFO by date).
The “for settlement” column at this point selects the line amount and summarizes it to the “payment amount” column of the 1st level. If you want to pay part of the amount of the particular invoice, simply alter the column “amount due”.
Continuously, the cheques’ desirable Expiry date must be completed, as well as the Bank account through which the payment will occur to the “From Bank account” column. The name of the Bank is automatically displayed (the Bank acct. number is also an available column through the “Edit formatting” action).
Under the list, must be defined the Issue date of the transactions as well as the document series.
Number of cheques
1st cheque expiration date
The expiration dates of the other cheques depends on the “Calculate upcoming expiries» field value:
Either at the end of each next month from the 1st cheque expiry date
Either at the same day (1st cheque expiry date) per month
Either “null” in order the user to complete the expiration dates to the created lines.
The amount that is selected to be paid, is (equally) distributed to the lines.
The user should modify the amounts of the individual cheques or to delete this analysis through “F12”.
By completing the selection of the payment data, select “Continue”, and thus the process begins and when finished, the results screen appears. If all the required data are correct, the cheques and the documents are created and are displayed to screen, in order to be printed…
We can activate these, for which cheques print is desired (to the “print” column) and to select the “Print Cheques” to the bottom part of the dialog. It will then follow the computerized cheques print process, after selecting the “printing device”, using the appropriate “printing form”, defined to the related bank account data. Instead one of the available printers, it can be selected the “Selected printer in bank account”.
Besides, the generated documents may be printed (to the form, defined at series) by using the button “Print documents“.
Any incomplete payments are presented with a “Failure message“ explaining the reason.
Payments by manual cheques
The process is similar to the previous one, with the difference that the cheques’ numbers are NOT produced by the system, but it must be given by the user. This occurs to the “cheque number” column (not visible to the default layouts, but selectable through right click-add/remove columns):
Mass payments through Bank
From the “Create payments” option, through the icon use for loading the alternative layout, we can also select payment by fund transfer via Bank. For this process, some supplementary columns are necessary. All the other features, described in the section of payments through cheques, are available.
|Payment method||Fund transfer or cheque. The default value depends on the suppliers’ “Usual settlement” field.|
|Withdrawal||Select between the Bank (liquidity) accounts of the company, the one FROM which the amount due, will be transferred.|
Select between the Bank accounts defined to the supplier TO which the amount due, will be transferred. It is suggested his “main” Bank account, and if the related company’s bank account is also defined there, this is suggested to the Withdrawal account (to the column “From Bank account). The suppliers’ bank accounts found to the suppliers’ management screen, to the “Financial data” sub-page:
To the “Reasoning for Depositor” field, and to the “Reasoning for Beneficiary”, it can be given the desired content for the transactions, for the Bank.
After the options are finalized, (amounts, accounts etc.) with the “Continue” button, the processing of the payments lines starts, the documents of payments (BPC) are created, and a dialog appears with the results:
At this point, it can be selected the “Export to file” button, which calls the “Mass payments from bank account” view (which is alternatively called from the Entities/Liquidity/ Information menu:
Payments approval process
- You initially prepare a “proposed” payments list,
- The payments are approved by authorized users and in the end,
- According to the selected options, the system produces documents, cheques or money transfers to Bank Accounts.
The functionalities are similar to these that provided to all the other payments planning processes, already examined to the previous chapters.
Preparation of payment Orders
To define the payable amounts of the proposal could use one of the following methods:
To the 1st level (“trade account line”) activate the “For settlement” column, thus the total amount due is proposed to the “Payment amount” column, which can be modified by the user. If a cheque would be used, the user can type a proposed expiration date for this. As far as “matching” is concerned, the liabilities will be automatically connected to payments by FIFO method (older balance).
To the 2nd level (“open items lines”) select particular liabilities to be paid by activating again the «For settlement» column, and the proposed payment amount can be always modified by the user. As far as “matching” is concerned, this will be done for the particular transactions (if approved).
By finalizing the payments processing and by completing the date and series for the payment orders for approval to be created, we select the “continue” button and the payment orders will be created with the initial “workflow step” (see the customization guidelines at the end of the unit). At the end, a dialog will appear with the results of this process.
The payments orders (PSD) presented to the “Payments to Suppliers” list (and respectively to the “Payments to creditors”), without having updated the system, at this point of time (cash statement, balances etc.).
Approval of payment Orders
In this step, the created payment orders will be APPROVED or REJECTED.
The approval will either occur for all the orders, on trade account basis with the “Approve all” or “Discard all” columns or separately for each liability through the “Approval” and “Discard” columns, to the 2nd level. The authorized user who approves the payments, may differentiate the “payments proposal” with:
MODIFICATION OF THE PAYMENT AMOUNTS
MODIFICATION of the payment method (with cheque or fund transfer)
MODIFICATION of the EXPIRY DATE (for cheques)
Through the “continue” button, the payment orders approved, will go over the “OK” (approved) step (see the customization guidelines at the end of the unit) preceded their individual data modification (e.g. approved amount, expiry date) and the deletion of the rejected.
Create payments based on approved orders
At this final step, for every approved order a payment document (CPS) is produced. The expiration date and the payment method of the particular liabilities proposed are based on the already defined data.
After you check the date and the series, selecting “Continue”, the documents (and the cheques, if defined) are created and the related payment orders are turned to “COMPLETE” (paid), based on customization of workflow steps.
The matching with the initial invoices will occur to this step, using the approvals’ detailed data (automatic or selective matching).
Customization Information for Payments Organization and Planning
- If processing is undertaken for many companies, the document types and series codes that will be used, must be exactly the same to all companies.
- For computerized cheques issuing:
- The expiry date and the Bank account must be defined to the selected lines.
- The “Notes numbering” data must have been defined within this Bank account
- The CODE of the cheques must have a Code format of automatic numbering WITHOUT prefix.
- To the company parameters, must define the document type and the type of the payable note that will be created
For funds transfer creation:
The Withdrawal and Deposit accounts must be defined to the selected lines.
To the company parameters, must define the parameters as to the document type (recommended BSP or BPC), as well as the transactions fields where the reasoning for the Bank payment order should be stored.
The Bank account must be defined
For the export file to other Banks, the necessary file-format alterations can be implemented, depending on the banks that the company co-operates. For this purpose, please contact the Entersoft’ Customer Service Department or a certified partner.
For the implementation of the approval process:
- The document type for the payment orders must be defined to the company parameters (the PSD – Payment Order is proposed) as well as the document fields, where the payment orders’ information will be stored for use to next steps (expiry date for the cheques and payment method):
- The “workflow steps” must be defined (initial step, approval and final):
In this chapter, sales scenarios will be examined for all the stages of the process from the offer and the ordering, up to the actual loading of the items, their shipping and Invoicing.
The instructions and the examples are mostly based on the recommended customization of the product, as far as the trade documents, the transitions, the screen layouts and the informative tools are concerned.
For a sales document to be entered, the following ways can be used:
Offer to a customer
Appropriate document type: SOF Quotation (offer)
The offer is made to an existing or a candidate customer and contains particular items as wells as services with the appropriate prices and discounts, while also the payment terms or other parts of the deal with the candidate customer. If there has been any monitoring of the sale process up to the time when the Offer is required, then the offer will be created automatically by the CRM workflows, thus eliminating the need for manually typing and entering the offer.
The Offered items might not have been entered as Inventory items so (based on customization that should have preceded this step) "general items" containing a free description can be used.
Also, in an offer, it is possible for certain alternative scenarios to be indicated. For example, two recommended solutions, each with its own total value.
The printout of the offer can be pre-designed by an appropriate layout or it could become available in a file, which could be attached to the document by the user. If the printing occurs by the system, it can be stored in a PDF file and to automatically be attached to the document, based on the customization of the document series.
Customizing Offer information
- The customization of line categories will take place through Tools Customization Transaction parameters. For every value in the “Item line categories” table, we can set if the line category is optional or not as well as a scenario.
As far as the Offer layout is concerned, it can be customized the lines layout (as can be seen in the Introductory manual about grids in entity “details”) as well as the display structure as a whole (as seen in the Technology Guide about data entry forms designer).
As far as the functionality of the recipient and the item are concerned, certain settings are required to the document type SOF:
Stating and customizing (through Ctrl+F12) of a header layout (proposed name: “Trade002”) if a dynamic form has not been designed.
Stating a line layout
Statement of the way that the trade accounts are defined, where the option to use a PERSON instead of a CUSTOMER is always open (through Recipient selection). In the “Define trade account from recipient” field, we can choose whether to use:
New Trade Account. If by completing the person in the recipient field, a Trade Account is located, he is placed automatically into the document. On the other hand though, if a Trade Account is not located when searched for, a dialog for creating of that Trade Account will be activated. In this dialog window, the template of the “default” Trade Account will be used so that the minimum entering will be asked for from the user.
Default Trade Account. If the Trade Account is not found for the selected Person, the “Default” one will be used, which might mean a “general use” Person. In this case, the Default trade account must have been entered in the previous field. Furthermore, the process must be organized in a way that if offer progresses, the customer is actually created before the transition to an order (or invoice). This can be done either by the classic handlings through the menu, or by using the quick adding dialog inside the particular Offer Document. Then, this customer must replaces the “default” trade account to the Offer’s header.
Definition of the way of Inventory Item detection, from the catalogue Item, if a catalogue Item is required to be used instead of an actual Inventory Item.
On the one hand the Search in Catalogue Items field is activated (the line layout for the Candidate Items will have to include the Catalogue Item column, like the SOF layout). In this case, the “Comment” line field will be used to store the description of the chosen Item, and an alphabetical search in Items (inventory and catalogue) is available in this field, to give to the user the ability to alter and store the proper description. This description will be active only in the particular document, as already mentioned.
On the other hand in the On autonomous catalogue Item field, when a linked Inventory Item is NOT found one of the following options will have to be chosen:
Create Item, which will activate the quick adding dialog for a new Inventory Item requiring the fewest possible data
Use template item, which will use the “template item” of the catalogue Item, while the actual entry (of the proper inventory item) and alteration of the document lines will be done in a later stage. In this case, an update process of the Catalogue Items must to be done for filling their “template item” with an Item connected to an actual Inventory Item, such as it will cover the necessary functions like VAT class or measurement unit.
Choosing this option, the system recognizes the fact that the catalogue Item is not the same as the Inventory Item, and proposes prices from the Catalogue Item and not from the “template”.
Appropriate document type: SOR (Sale order)
The sale order is entered for a particular customer and contains Inventory Items, additional charges and information for the settlement of payment. Based on the business processes activated and customized for the sale orders:
- A credit control check of the customer is executed
- The availability of every Item for the ordered quantities is checked.
- The foreseen by the trade policy prices, discounts, gifts or any other provisions are proposed and additional charges like Delivery cost, taxes etc are calculated in order to form the total value of the order.
The order can be produced by a previously entered offer (transition 471. SOF=>SOR). If a “general” customer or candidate items have been used, they will have to be defined and entered as an actual customer or actual Inventory Items, before the transition takes place (through modification of the Offer document). This is due to the fact that the order will set off a chain of reaction updating the particular ledgers.
Through the vertical toolbar or by pressing F11, the user can get analytical information on the stock availability of the Item, in each Warehouse and also, if the same Item (code) is used by other Companies of the system, displayed those stock quantities too (there’s a color indicator for stock in other companies).
The quantities displayed are the actual and available balance (not reserved), the expected (from other branches, suppliers or by Production and quantities already loaded/on the way), the sales orders in progress and orders issued by other branches, as well as the future stock after the possible delivery of all the above.
Based on that, the user is able to notify the customer about if and when the Item will be available, and in case that there is availability, the user can proceed to stock reservation or dispatch in-house from another branch.
Alternative, compatible & accessories
If an item is out of stock, the user is able to use the vertical toolbar to select the button called “Select based on relation” (CTRL+F9) and thus offer the customer a similar alternative, or technically equivalent item. For this to be an option, the relations between the Items must already have been set (to the Items mgt screen). In this case, a list comes up from which a choice can be made to replace the Item of the current line.
If we need to propose accessories or in cases where the accessories are actually asked for, we can use the F9 key or select “Select based on relation” from the vertical toolbar. For the new lines to be entered, all we need to do is press “Accept”.
In both cases, the “Quantitative relation” of each new Item applied to the Quantity of the current Item, with a possible repercussion to the proposed line quantity.
Another use of relations is when the customer asks for a specific Item with the condition that the Item will be compatible with another Item possessed by him already. In this case, the item (which will not be included in the order finally) is entered and using the vertical toolbar and “Select based on relation” we select the compatible items we need.
Selling combinations of items
In a few cases, some Items are sold along with others.
If an Item package is sold as a whole, an auxiliary Item of a “Set” type can be created. When inserting it in an Order line, the parts will be developed underneath displaying the Items it contains. The allowing or not of the user to have any access to edit the lines of the contained Items, depends on the type of BOM (Bill of materials). The “Static” BOM type, will allow the user to interact only with the set line while the “dynamic” type allows full control over the lines of the set. The set Item itself (displayed in the document as a secondary header in the lines, colored differently) will neither take part in the document totals nor it will update the various sub-ledgers, apart from the Sales Statistics. The “Static” set, in particular, can be used sometimes as an OFFER pack of certain items to a special price.
Special BOM (Macro)
If a special Item is not in our interest to create, a “Special Bill of materials” can be defined (Entities/Inventory/Bills of material). The special BOM is a type of macro through which we are able to enter a variety of Items in a document by using the “Add through auxiliary BOM” action, found in the Actions button in the vertical toolbar of the document, or just by pressing Alt-F9.
The dialog for the BOM search will be activated and after we locate and select it, we can set the quantity so that by pressing “Accept”, the proper item lines are created without the “header line” to exist, like the previous case. The auxiliary (special) BOMs can be used in a certain time frame, and then freely deleted, since no “trail” is left in the documents.
Gifts and offers
Item combinations can be provided through the Invoicing Policy, where by selling a particular Item or an Item that belongs to a specific category or a minimum quantity of an Item, other Items can be inserted automatically as gifts or to a special price.
As far as the discounts are concerned, “Discount 1” proposed from the header/customer, “Discount 2” comes from the Item, “Discount 3” is available for editing an additional discount or assigned by pricelists, invoicing policy etc, while the “Discount 4” is a sum of discounts deriving from the application of Special Discount Accounts. The first three discounts can all be applied to the starting value (quantity*price) or each one can be applied on top of the previously applied one. This can be set by a specific parameter in the customization:
All of those discounts take place on net values, while one more discount type, the gross discount will be applied to the final value (after applying the VAT charge). By using the Alt-F7, the discount on the sum, will be broken down to all the lines and can be given in three ways:
|Immediately as a discount amount||%Percentage||
Actually if a gross discount is used, it will be un-taxed and transferred in one of the 3 first discounts of every line based on a company customization parameter:
Gross profit margin – On line cost
In every document line, in the “Cost value” field, the cost is stored based on the online average item cost (calculated on all types of acquisitions) making the indicative cost and profit of the whole order available.
Moreover, the cube “Profitability per order” (Business snapshot/Profitability analysis) can be used providing this information. There, the user can compare gross profit between orders, customers, items and so on.
The horizontal dimensions (Project, Business activity, Business Unit, Dimension 1, Dimension 2) end up with a particular logic in the document lines from which the revenues and expenses will be updated and results BY dimension will be produced.
The following scheme displays the dimensions’ value setting priority of the item lines which is valid for the special accounts, services, fixed assets, liquidity accounts etc as well.
By choosing a document type, the horizontal dimensions receive the value set by the document type if they have been entered and when the series is chosen, the values will be overlapped. By choosing a customer, the same will occur in the dimension fields of the header, where the user is able to alter them while, other processes like choosing a particular contract, application of a business rule or a field property profile can provide new values to these fields.
From this point on, the dimension values of the header are transferred to the lines of all types, where every entity can redefine the dimension value. For example, in case a Business unit has been stated in an Item, that will finally be the recommended value of the item line and will update the transactions, statistics etc., no matter if all the “lesser priority” entities would define a different business unit.
Information during Ordering
Having defined the item in a line, the command “Previous Item entries” (accessible from the vertical toolbar or Ctrl+F11) will immediately display all transactions of the current customer in the past for the particular item, while the price and discounts at that time are also visible.
A full supervising review of the item’s relation to the customer can also be obtained by using the “Item Summary” command, from the vertical toolbar, which will display the following information dialog:
For the combination of the item and the trade account: quantity sold, turnover and average sale price last year and this year, last order and last sale data.
An interesting function here, is the fact that the Item as well as the customer are visible parameters by the user. So, could see the results by changing the customer or/and the Item. This way, during the customer order, we can look for the turnover the customer has made for other Items or sale price given to another (relevant) customer etc.
After entering the order, in order to keep track of its progress, the “Show Transitions” (Transition/Show Transitions) button is available (to the horizontal toolbar), analytically displaying the quantities, when and how the order was served.
Mass replacement items in Orders
Sometimes, after issuing orders, either by customer request or due to some commercial policy or an Item abolition, or inability to deliver or any other factor, some Items will have to be replaced and the items to be sent to the customers will be similar or items of a new collection etc.
In the “Pending orders (per Item)” view (Transactions/Sales/Revenues/Information) the user can do this action by using “Change Items” command, which will be applied to all the marked item lines.
We choose the item, which will replace the item used in the marked lines. Apart from the code, the ability to choose color and size is also provided. The process will REPLACE the data either of the whole line (regarding the Item) or even only the color and size. If the “Combination” setting is activated (“Yes”), then the changes will not take place for the color and size given to all lines, but only for the combination of the particular “from” color and the particular “from” size (to the same item line).
How we can see the results of Sales Orders issuing
Customizing Order information
- In order to change the Order layout, a dynamic form can be used which may be declared to the document type.
In grid layouts, the visible columns can be altered and sorted according to the needs as well as stored for future use.
- In order to accelerate the operation and if the available stock column is not required, the layout “ES-1-SALE-STOCKBAL” can be removed from the document type, by also removing the “Available stock” from the grid layout.
- For the user to be alerted when a shortage is in effect, an Item Control Profile can be used to Items. The property “Order” must be defined at a Profile line, to enforce the stock control check (i.e. actual stock or available stock not to be negative). Alternatively we can activate the feature of “Readjustment of quantity at new lines, based on stock“. The stock in this function is the one defined as to be checked (i.e. actual). It will be proposed then, the maximum possible
- If there is a need for searching only between Items existing in stock, we can activate that ability in the document type.
- NEVER attempt to use any of the additional development tools provided by the system, to give a value to the “%Discount 4” and “Discount 4 value” due to the fact that those fields come up by summarizing special discount accounts which are “distributed” to item lines.
- The Order can accept an advance payment as mentioned before. If we need to disallow that, and the payment receipt to always issued separately, then in the document type’s customization the payment options could be deactivated (only if a dynamic data entry form is not in use).
If however we need all the settlement information to be clearly visible, the above instruction is not recommended. A field property profile should be used to disallow the existence of liquidity accounts of type “Actual”:
- The Credit Control is activated through the field “Check credit limits” of the document type. If we need the credit limits check to only be a warning in the order but deny the invoicing (in case that credit control rules exceeded), we can activate the Credit Control Policy at customers’ data, defining this behavior BY document type (document property, actually).
- As far as the default price is concerned, the following parameters in the document type, in the “Lines” sub-page, should be checked:
Default price. Among the available options, the ones below are the appropriate ones for the sale documents and the 1st of them has been chosen to the pre-configured Order:
Wholesale price: If a price zone has been defined to the customer and the choice at this point is one of the related to the price zones (retail price, wholesale price, price 1, price, 2, price 3), the corresponding price of the item is proposed, no matter which of the 5 is declared to the document type. The same feature applies to the Retail price, Price 1, Price 2, Price 3.
Last sale price: It is proposed from the last dated sales transaction.
Last net sales price: Works like the one above, but any discounts subtracted from the last sale price. This way if the last sale price was 100.00€ and the discount was 10%, with the previous option the default price would be 100.00€, while according to this option, the default price will be 90.00€. If a default discount is active (either due to the customer or through a pricelist), the net price should not be used because the application will propose a double discount, in this case!
Default price per trade account. The field is accessible only if the “default price” has a value of “last sale price” or “last net sale price”. In this case, we can define here that this “last” price should be found ONLY in the transactions of the specific customer of the current document and then, two choices will become available:
Either the price of last transaction should be proposed to the line,
Or, the price AND discounts to be proposed.
- As far as the cost is concerned, that calculated and immediately provides the information of the gross profit on a line level, it is based on the setting “Default cost price” of the document type:
Spot cost price: This is calculated as an average price of all purchases since the last fiscal year closure, and is the quotient acquisition cost / acquisition quantity.
Official cost price: This is the official cost price calculated by the Stock Valuation process for the last fiscal period.
Standard cost price: This is the standard cost price, which defined to the “Cost prices” of each Item.
Last acquisition price: The “price” field from the last dating purchasing transaction.
Last net acquisition price: This is like the previous choice, but taking out the possible discounts taken place.
- In the “T.R.N.” field, the possibility for locating the trade account is strengthened by using not only the TRN to search, but also the ID number, phone numbers, card number (if it applies), through the “Trade Account Search method” field in the document type, where multiple choice permitted.
This statement will result in the user being able to supply any of the known data (or part of them) in the one and only “T.R.N.” field at the document form and the customer to be located by any of those. This way if the customer has a phone number of 210-8920201 and a club card with the number 3220190 and in the document, the «*201*» string is typed in, both of them will be displayed to choose from, if these two fields have been activated for search.
Stock reservation for customers
Reserving stock can be achieved in various ways:
Appropriate document type: SRC (Stock Reservation for Customer)
The available stock calculated and displayed for the current Warehouse and for all company’s Warehouses. The reservations only affect the Inventory sub-ledger and in particular DECREASE the AVAILABLE stock. They are presented in all views mentioned at the previous unit (about Orders) and affect all functions using the available stock (i.e. stock control).
Release of a reservation can only be enforced by the following transition, when the items are going to be sent to the customer, while a cancellation (when the goods will not to be sent at all) will produce the same result:
Appropriate transition: 137. SRC=>SLN (Goods delivery Note from Stock Reservation)
This transition designed for cases when a reservation entered primarily and no orders made beforehand.
In case the processes are intensive and for the system to be able to update immediately, before the entry of the items is completed, do save of the document by pressing (CRTL+S), and continue entering the rest of the items.
After approval of customer Order
When an Order registered, then approved, and the stock should be reserved until the routing of the order to be sent off to the customer, the following transition should be used:
Appropriate transition: 151. SOR=>SRC (Stock Reservation from Sales Order)
For sending the Items to the customer in this case, the following transition (designed for cases where the workflow begins with an Order) should be used:
Appropriate transition: 152. SRC=>SLN (Goods delivery Note from Stock Reservation)
During issuing an Order
Another process leading to reservation provided through the following document type, where, while ordering, all quantities currently available are reserved, while all the others remain “in order”.
Appropriate document type: SCO (Sale Order with automatic Reservation)
The ones depleted will be directly ordered to suppliers and as soon as they arrive, they will be sent to the customer. This workflow is described in a next chapter, about “customer order of high priority”.
In this case, NEVER must use fields “Amount4” and “Comment5” of item line, because are reserved by preset configuration.
Shipping to a customer
Goods delivery Note (Invoice pending)
The delivery note is issued to accompany the items we send off to customers. The invoice that charges the customer will follow and will most likely be regarding more than one delivery note. The reason that a single Invoice is not issued in the mediation of distribution companies for the actual sending.
Appropriate document type: SLN (Goods delivery Note)
The results of entering the Goods Delivery Note are…
It updates the Inventory by reducing the actual stock.
Customizing Delivery Note information
Check for no item that not allowed to the particular Warehouse to be accepted. This check can protect the users from typing the wrong item code or from using the wrong series. Since the allowed Warehouses are declared to Items (there is a mass procedure to implement this too), it must:
To be ensured that the setting “check Item W/H” is activated to the Items’ Control Profiles (to every line that concerns transfer of quantity), and, in the other hand,
Ability to filtering during search only items in stock (into the current warehouse). To the “Select only items in stock” field of the document type (to the “Lines” sub-page), may choose if this filter is active and to what line type (normal or reverse).
How do we see the results of issuing Delivery Notes?
||Sales/Revenues||List of all Sale documents concerning quantities or values|
||Pending customer invoicing||Delivery notes or Goods receipt by customers who have been linked to the corresponding Invoices.|
The Stock book with all transactions affecting quantities and/or values. Depending on the layout, it will be displaying the deliveries in the Sales column or the exports in general
Same updating, though more concentrated, see the Monthly Statement of Stock Book as well as the Inventory Costing Balance.
||Stock quantitative control||
Cube for check Items’ quantities per item, branch, and W.H.:
||Journal of Quantitative Stock Entries||
List of Items’ transactions PER date and Warehouse, with double qty columns to both main and alternative unit:
||Current Stock availability||The current Inventory status per Warehouse with information for the expected quantities, the orders to be delivered and the future stock. The quantitative Good Delivery Notes do negative update of the “stock” column.|
Goods delivery Note for an Order
When the delivery based on an Order, which entered beforehand, the document can be produced in an automatic way, through an Order transition.
Appropriate transition: 111. SOR=>SLN (Goods delivery Note from Sales Order)
When the customer Order made through the process of automatic stock reservation (SCO), then:
Appropriate transition: 176. SCO=>SLN1 (Goods delivery Note from Sales Order/Stock Reservation)
In both cases, the Delivery note will keep the transition information and will correctly update the Stock availability, reducing at the same time the ordered quantities.
This way in any view we have had the information of pending customer orders, we are also going to notice a reduction of the orders and the actual balance, as well as an increase in the sales quantity.
Selecting the transition, in the appearing dialog, we can provide the series and the date for the Delivery note with some additional capabilities (choice of lines or whole documents of orders and grouping to create a single Delivery note for the customer from more than one orders:
Choosing “Next”, ordered Items displayed to select those that will be delivered. In the criteria, the customer is included as well as the “workflow step” (in case that Orders approval process is in force).
Through the 1st choice column , the quantities of the Order document lines are selected automatically to become “Quantities to proceed”. Alternatively, the user could provide a smaller quantity directly in this column, thus selecting a partial delivery, tracking the quantity not to be sent to the “Remaining quantity” column. The actual and available stock at this moment is also visible to the next columns.
In this stage, if we have chosen “Documents set” in the selection level of 1st tab, in order to make whole orders be sent and to allow us to choose which ones, the next display will be different, displaying an orders overview and not lines:
In the next step, the choices we have made will be displayed for confirmation of the process:
After confirming, we can press “Run”. The process will create the Delivery Note/s, which will show up in the results page:
At this point, the user can move on to the printing of delivery Notes, through “Actions” of this results view.
If the result of the process is a single Delivery Note (which would happen in case of a transition from inside an Order form), then this document will automatically open (based on a setting of the transition profile).
Manual entry of Delivery & posterior connect to Order
The transitions, apart from the service that they provide for automatic document creation based on others of a previous workflow stage without the need to type, will also have some additional important results into the system: They update the pending quantities created by the source documents. This way, if an Order is not sent through a transition, it will appear as “Pending”, resulting to the possibility of re-transitioning by mistake. Furthermore, in all the availability lists, stock will appear as pending (to be sent) quantities which are not actually outstanding.
For the above reasons and even if typing is necessary to enter a document which belongs to a workflow of another, we will have to ensure that it will be connected to that document in order to close the cycle of the outstanding quantities.
If for example we are using Orders and Reservations which produce Delivery Notes, the first rule declared to the Delivery Note document type would be the one that uses Reservation as a source (that means that whatever is sent will firstly close the reservations). In this case, if the reserved quantities are not enough, meaning that the Delivery Note has a greater quantity, then it will be “closing” up the possible ending Order quantities as well (having declared it secondly in the transition rules of this field).
On the other hand, any document produced by transition (and based on the setting «Observe document history» and “Monitor pending quantities” of the transition profile) contains the list of all the related documents (with lines fulfilled by the current document’s lines).
- Automatic quantity matching. A dialog will appear for the execution of the process:
b. If no related documents have been declared, we are able to choose which data will be taken into consideration in this correlation process, in order to locate the proper source documents (Orders). If the “delivery address” has been selected for example, the delivery Note will be connected only to Orders with the same “delivery address”. Activating the “previous documents” field, ensure that no matching with Orders of a later date of the Delivery Note will take place.
The data input in this dialog will be taken into consideration during matching, anyway. If for example an Order document has been declared as a related document from a different branch than the one possibly declared in the dialog, this matching will NOT take place (though this is a very rare case scenario).
- Criteria based quantity matching. A different dialog will appear:
The process result will be to connect the chosen and the “source” documents while, this way, to update the system regarding the pending quantities just as if a transition had occurred in the first place.
In the Delivery Note it is possible for the Item Code to be changed in a line. This way the quantities matching of the line will remain intact and nothing will remain Outstanding.
The automatic quantity matching that we have seen previously occurs using criteria of 1) the customer, 2) the criteria possibly declared in the dialog of the automatic matching or the source documents which have been declared as related documents and 3) the items and their “dimensions”. If the choice of similar dimensions between source and target documents should be kept or not, will be set through the parameter “Automatic quantity matching with strict dimension control”
In dimensional items, it is possible that not the exact colors-sizes-lots ordered to be actually sent, due to several reasons and after communication with the customer. Most of the times, we want the “quantity matching” to occur, even if the dimensions are not identical and, not to keep a back order. If “no” is declared, the application will firstly check and match all lines with the same dimensions and for the rest quantity, this parameter is checked.
Handling of total quantity to be delivered (weighing)
In Delivery Notes with a variety of Items, in order for the right quantity totals to be printed, the confirmation of the quantities will take place sometimes by certain methods e.g. weighing. In this case, if the user knows the total quantity regarding a certain unit and it is not the one coming up from the lines of a Delivery note, he needs a way to declare it and the system to do proportional automatic updating of the document lines.
This can take place through “Allocate quantities”, which activated by pressing the Ctrl + Q key combination after the lines concerning the allocation are marked. The result will be the display of the dialog which allows just that:
We can see for the chosen Item lines, the sum of the quantities («Calculated»), provide with new («actual») and look at the difference between the two («Difference for distribution»). Choosing “Update”, the lines will be updated with the new quantities based on the starting value of the lines.
This function is useful only if the quantity declared here is about the One and only measurement unit of the chosen items. For example, if some lines with an alternative unit A and others with an alternative unit B, have been selected, this function will have no meaning due to the fact that only one quantity can be given.. The same applies to the weight, in case it is measured in “Kilos” in one line and “grams” on the next. In this dialog, the unit in which the quantities should be given , is displayed, using the “current line”. As many lines do not have this unit, will be ignored, while calculating totals as well as while distributing the possible differences.
Delivery with no charge
When the Delivery note should be issued to a customer for items, which will not be charged (meaning that an invoice will not follow), a certain type of document needs to be used. This usually takes place in cases where samples are sent for testing, checking etc. or sending back some items to the customer, which had been received for checking or servicing.
Appropriate document type: DWV Delivery Notes (Without Value)
If the sending to the customer concerns an already issued Receipt Note (without credit invoice pending), a transition can be used, so that the data will not have to be retyped:
Appropriate transition: 140. GRN=>DWV Delivery Note from Receipt Note (for testing, control)
This quantity updates the quantity of the “Other exports” in the Inventory Books.
In case the delivery is concerning an item of the customer which we have received for fixing and at the same time we are charging services, the types of documents we can use described at the specific chapter about providing services.
Delivery notes’ renumbering
In case before the printing, a numeration of the Delivery Notes of the day is needed, so that they will follow the queue in which the deliveries will be made, the specific for this purpose process “Document numeration” can be used (Tools/Maintenance tasks).
In the dialog displayed, for a day and a specific series or prefix and document type, we can see the documents meeting the conditions for the numeration:
• Not-cancelled or cancelling
• Using automatic series
• Using series with “sequential dates”
At the criteria area, the “Trade account”, “Document code”, “Transport means” and “Itinerary” can be used to limit the number of documents participating to the process.
For all the displayed documents, the «Update» key starts the process, which will apply to them a number by issuing date based on the sorting of this view.
Order routing process
In case we have some transport means executing certain routes, a “sharing” to them must occur for the goods to reach their destinations based on the delivery addresses, then, a summary list must to be prepared for each route and, after checking and producing the delivery notes, must print the appropriate list for the transporters. The following process recommended for this purpose:
For a delivery Note
Usually the invoice is sent by post, though there is the possibility of electronic posting without the need for printing.
For locating of the Delivery Notes, which must be invoiced, use the view “Pending customer invoicing”. From this list, the Invoices can automatically produced by transition:
Appropriate document type: SIV (Sales Invoice)
Appropriate transition: 113. SLN=>SIV (Sales Invoice from a Goods Delivery Note)
To the invoices generated by the process will need to check or correct the (proposed) prices and discounts, and also to check the settlement payment.
If for any reason the Invoice is not entered through the transition but is typed in, we must do automatic quantity matching before the process of stock valuation is executed. This way the Invoice will be “connected” to the Delivery note so that no value is left Outstanding. Such values would lead the Stock Valuation process to create wrong forecasted transactions for sales that either quantities or values missing.
How do we see the results of issuing Sale Invoices?
||Sales/Shipments||List of all Sales documents concerning quantities or values|
||Invoicing documents||A list of the documents creating Turnover per branch.|
||Revenues Journal per VAT rate||
It presents all the stock quantitative and value transactions. The Invoices update the columns of “Sales value” (depending to each format):
The Customer’s statement (of accounting nature) with detailed transactions and progressive balances.
The same update (summarised) also occurs to the Customers’ Trial balance.
An accounting entry is created to the Customers, Sales and VAT accounts and it updates the Accounting journals, the Account Statements, the Trial Balances etc.
Sale Invoice – Goods delivery Note
Invoicing usually works this way. It charges the customer and comprises of an accompanying document of the Items.
Appropriate document type: SNV (Sales invoice – Goods delivery Note)
The way the fields are completed and the possibilities existing for locating the customer, direct checking of his financial status, functionality of the payment method, transfer data, prices and discounts, customization are described extensively at the chapter about Sale Order.
In the same document, Services can be brought in, or/and Fixed assets, in the other line tabs.
A lot of care should be given into the way that the Payment method is managed. As far as the settlement is concerned in the order, the data is only informative (unless there is an advance payment). During invoicing though, those data affect the Aging of customer balance so, it is important to choose the right payment method and/or checking the forecast entries produced.
The user is able to interfere and define the actual dates and amounts for payment if there is a specific deal made.
If no payment method is defined and no data were entered here by the user for the payment forecast then, during saving of the document (for update outstanding receivables in the right way), the system will automatically create a forecast line visible in the “on credit” tab, along with the total amount to be paid. The due date of this automatic forecast entry will be set as many days after the issue date as defined by the “Credit days” in the customer.
As far as the visible results of a “Sales invoice” are concerned, in the previous chapters we have seen the way that the two documents, whose union composes the present sales document, affect the functionality and reporting.
Invoicing of Orders (with prices agreed in Order)
To be able to send and at the same time invoice customer orders, a transition will have to be used.
Appropriate document type: SNV (Sales invoice – Goods delivery Note)
Appropriate transition rule: 112. SOR=>SNV (Delivery Note - Invoice from Sales Order)
After the production of the invoices, we can check on the validity of the transfer data, prices and discounts etc and finally print them.
If the Sales invoice has been typed in, the automatic quantity matching will have to be used.
Invoicing of Orders (with new prices)
If the prices and discounts in the order are “indicative” and, during invoicing, we want to apply the new-current prices and discounts, then must use a different transition:
Appropriate document type: SNV (Sales invoice – Goods delivery Note)
Appropriate transition rule: 112. SOR=>SNV (Q) (Delivery Note - Invoice from Sales Order (with new prices))
The difference from the previous transition is that from the original order(s), only quantity and information data are copied, rather than prices and discounts, so be applied in the Invoice afresh the pricelists, contract results, invoicing policy or even simple loading items’ prices which in the meanwhile might have changed.
Invoicing additional charges
This document is used for charges, corrections or additional Invoicing to the customer, due to mistakes taken place during the starting entry regarding the item price or value, which now require additional charging.
Appropriate document type: SDV (Debit note)
It charges the customer and updates the turnover. If the mistake taken place was requiring customer credit, then a credit Discount document (SCV) will have to be used and NOT a negative value on the current.
According to the default settings in the customization, the same numbering and prefix applies as the «SIV».
No charge granting to a customer
The process is regarding the sending and invoicing of the customer with no charge. A simple Delivery note is not the appropriate document, since the no charge grant is equivalent (accounting wise) to a free invoicing (and not only delivery). In this case, the posting method is differentiated compared to a Sale invoice’s, matching rather the Self-dispenses (see chapter “Expenses”), but in this case the recipient is actually a customer and not an employee.
1st Scenario-> Unified document for quantity and cost
Appropriate document type: FGN (Free grant Note)
The document is updating the Inventory sub-ledger as to quantity and cost of “other exports” while at the same time it will update the expenses as well, regarding the accounting. The receivables sub-ledger is not updated. The transaction will take part neither to the Revenues nor to the Expenses reporting, but only to the Inventory and VAT Journals.
In accounting, the revenues and expenses updated with the same amount.
During the Stock evaluation, if finally a different cost has been calculated than the one declared in this transaction, corrective transactions will be produced, fixing the cost value
When a transport of this sort happens by mistake or the item is returned by the customer, the following document must issued, which produces the exact opposite result:
Appropriate document type: FGR (Return from free grant)
During the printing of those data, it would be best if two separate “print forms” would be used and simultaneously printed, using the ability of declaring multiple forms in the document series:
- One will have the layout of a “Delivery Note”, containing purely quantitative and informative data for the customer while
- The other one will have the layout of an “Accounting Note” with the same number and will contain the cost and VAT data, that refer to the General Ledger entry.
2nd Scenario -> Distinctive documents for quantity and cost
In case of issuing two documents, one Delivery Note and one separate cost element, there are two alternative scenarios:
Appropriate document type: SDQ (Self-Dispense Note - Quantity)
If there has been a reservation before the shipping, the following transition can be used:
Appropriate transition: 138. SRC=>SDQ (Self-Dispense Note from Stock Reservation note)
The Shipping note must be followed by the cost element (within the same Stock costing:
Appropriate document type: SDC (Self-Dispense Note - Cost Value)
Appropriate transition: 160. SDQ=>SDC (Self-Dispense Note from Delivery note)
The update matches the one done by the unified document, though in two stages.
If for some reason, an SLN (Goods Delivery Note – for sale) issued beforehand, then we must use a different document type regarding the cost and not “SDC”):
Either issuance of a regular Sale Invoice with zero value along with a negative result of the gross profit:
Appropriate transition: 126. SLN=>SIV (ZERO VALUE invoice from Sales Delivery note)
In this case, this transaction considered as a Sale, regarding the Stock Books.
Or issuance of a Free Grant Note from (after) Sales delivery note:
Appropriate document: FGS (Free Grant Note from (after) Sales Delivery note)
Appropriate transition: 148. SLN=>FGS (Free Grant note from Sales Delivery note)
This document will transport the sales quantity to the quantity of self-supplies (or other exports, depending on the layout of the Stock Book report), while at the same time the cost is being updated.
Regarding the accounting, it updates Revenues and Expenses at the same time, just like the other Free Grant Notes (SDC, FGN).
Invoicing of public sector’s customers
Sale to customer of type Public Sector can take place with any of the sale documents. The specificity in this case is that if we are aware of withholding taking place, we are able to configure the system to be able to calculate them automatically. This can occur by using special Withholding accounts, which after being set in a group of withholding, they will be set to the relative customers at “Withholding group” field, and stated in the proper document types.
Since this configuration done, the withholding amount REDUCES the total (payable) amount as well as the customer charge. This way the receivables will be updated correctly (with the amount remaining after the reduction of the withholding).
An alternative scenario would be invoicing without withholding and, during payment, to enter the withholding amount, based on the “State payment order” report, which usually given.
In this case, the withholding RAISES the payment amount, so the customer credited with the correct amount, resulting in balancing of the Invoice claim with the total amount.
Details about customizing Special Accounts see to the relevant chapter “Accounting tasks”.
Customer order of high priority
This is about a workflow during which the customer orders and, as many items have enough stock will be reserved that moment, while for those that are out of stock, an order/s is sending to the supplier/s on behalf of the customer. As soon as the Items arrive, and based on the appropriate information about the progress of the Order, the shipping and invoicing to the customer will proceed.
- In this flow, using the default documents types that described below and designed especially for this purpose, the fields “Amount4” and “Comment5” of the line items, have been reserved.
Order with direct reservation of available stock
Appropriate document type: SCO (Sale order-Stock reservation)
In the document lines, the following columns are available:
Available stock in current warehouse
Reservation, which activated by default if stock exists
The result is that the lines “to reserve”, will update the “RESERVED” stock to Inventory sub-ledger as soon as the document is saved (without any transition to occur), while the rest items will update the “ORDERED” at the same time.
Direct order to supplier on behalf of the customer
For all Items that are out of stock, the order is sent off to the suppliers, using a specific transition:
Appropriate document type: PSC (Order to supplier for customer)
Appropriate transition: 174. SCO=>PSC (Purchase Order for specific customer)
Selecting the transition, in the appearing list, the system displays the main supplier of each item (lines of order which have not activated the “reservation” field), and the user can select any items’ supplier instead.
The process will produce as many documents as the different suppliers are.
At this point of the procedure, the view “Customers’ Orders status review“ will display the Items with the proper indication in the “Ordered from supplier” column. The orders presented here are exclusively of this kind (and not all sale orders), that is Sale order of “high priority”:
Receiving goods by supplier
As soon as the Items arrived, the following transitions can be used:
Appropriate transitions: 478. PSC=>PLN (Goods receipt Note from Purchase Order for customers)
479. PSC=>PNV (Invoice – Goods Note from Purchase Order for customers)
The result will be the automatic reservation of new stock for each customer. The view “Customers’ Orders status review“ will display the Items with the proper indication in the “Sent by supplier” column.
Shipping and Invoicing of respective customer
The shipping to the customer can be implemented automatically by using one of the following transitions:
Appropriate transitions: 176. SCO=>SLN1 (Goods delivery Note from Sale Order with stock reservation)
175. SCO=>SNV1 (Sale Invoice-Goods delivery Note from Sale Order with stock reservation)
ONLY after this action will the stock reservations be released, due to the initial Sale orders.
The “Customers’ Orders status review” will display the items with indicator in the “Launched” column.
Sale Order cancellation
If an Order or part of an Order has not been delivered and it will not be delivered at all for various reasons, this must be declared into the system, for avoid to always shown up as a “pending” order.
- Wrong order
In this case, one of the following actions could be used:
1st method: Line deletion
2nd method: Quantity reduction
3rd method: Order deletion
Cancellation from the customer side
In this case, one of the following actions can be taken, allowing the updating of the “Lost Sales”
1st method: Transition to SRO (Sales Order Rejection)
2nd method: Quantity reduction with an, at the same time, updating of the “Lost sales quantity” column
Customer sale return
Pending issuance of a credit Note
This case is about documents accompanying returned goods that issued by customers (or by us on behalf of the customer), due to a defective Item or for change delivered Items, for which a Credit Invoice will be issued.
Appropriate document type: SRN (Goods receipt Note by customer)
It updates the stock quantities, negatively in the “Sales” column and creates a value abeyance, which will reset when a Credit Invoice issued.
After delivering items for check or test
This is regarding the cases of Items that have been shipped to customer (using a DWV – Delivery note without charge) and then returned by him, after having been checked, tested, presented etc. A Credit Invoice will not follow such a Delivery Note, but the Items expected to be returned by the customer. In this case, it must be use the appropriate transition:
Appropriate document type: GRN (Goods receipt Note (without value))
Appropriate transition: 139. DWV=>GRN (Goods receipt Note from Delivery note (without value))
It updates the stock quantities in the “Other exports” column.
Simple quantitative goods receiving
In some cases, we are not sure of the way we are going to handle the accounting part of the actual goods receipt.
Appropriate document type: GRN (Goods receipt Note (without value))
An ordinary case of quantity receiving is regarding checking, or servicing. For details on the type of documents issued when the repair process is finished, the relevant chapter on Service rendering will provide more information.
If we simply send back the Items to the customer, we use the Delivery Note without charge (‘DWV’), as described to a previous chapter. A transition is also available for this case:
Appropriate transition: 140. GRN=>DWV (Delivery note from Receipt note (without value))
Activating the Return policy in the Sale Return documents, you can apply business rules about if and when the return from a customer is allowed, for example like:
- Return check using a code change
- Definition of the maximum allowed number of days since buying for the changes to take place
- Support of special, customizable by the user scenarios of unacceptable returns, like for example the return of goods bought during a discount period
- Checking for returns in the same season of the initial buy
- Ability to overcome the above return checks for specific user groups.
If for some of the above an authority given to overcome the check, the process of authorization from the authorized users will have to be activated. This will take place if in the dialog coming up, an authorization request asked.
The (logged in) authorized user will be notified then and, after providing the system with his own authentication details, the approval will be accepted and saving of the document will become feasible, while an on screen message will inform the user about the approval (or rejection) status.
Customizing information on the return policy
- Which trade documents it can be activated in
In TRADE documents through the “Activate return policy” field, either the document type has “Forecasts sign” => CLOSING (meaning credit documents) so it takes into account the “normal” item lines, or the document type has “Forecasts sign” => OPENING (meaning invoices, debit notes) so it takes into account the “reverse” item lines.
Configuring control types
A series of general parameters in the category “Document administration” make that possible:
Checking of NON-accepting return of items after a specific period of time
Returns=>01- Acceptance authorization by 1st User Group (Number of days). The number of days since the initial buy for which the right to overcome the check is valid for the 1st group declared in the next parameter. Setting 0 will disable the check.
Returns =>02- Acceptance authorization by 1st User Group (Group name). We declare the user group/s, (separated by comma, if many) which have the right to overcome the date range check declared in the previous parameter.
Returns =>03- Acceptance authorization by 2nd User Group (Number of days). Like in the 1st parameter for the second user group – different number of days.
Returns =>04- Acceptance authorization by 2nd User Group (Group name). Like the second parameter for a different user group.
Checking for required input of “changing code”
Returns =>05 – Check completion of initial document in returns line. If defined YES, the “alternative document” field will always be checked not to be null in the line of the returned Item. If it is a credit document, the definition of the alternative document in the header will be enough.
Returns =>06- Acceptance authorization upon non-completion of initial document. (Group name) The user group/s with the right to approve the return in a line with an empty alternative code or a non-valid code (non existing or of another customer etc).
Checking for return from a period of DISCOUNTS or another discount reason
Returns =>07- Return check for discount reasons from line field. This is where a line item field is defined where, during sale in case of a discount provision the DISCOUNT REASON is coded and input. When entered, the prohibition of certain “reasons” of discounts can be facilitated.
Returns =>08- Discount reason field content on non-acceptable return We enter the value/s (separated by comma, if many) of the above field at the initial sale document line, with which the value of the filed (declared in the previous parameter) will be compared to and in case the same one is found, the return will be prohibited.
Checking of Seasonality
Returns =>09– Check return in same season. A “Yes” here will activate the checking of the season declared in the item to compare it with the returning season. The season taken into consideration for checking, if the item has dimension management, is the season declared in the dimension pallet or in case no season found there, is the season declared to the item register.
Returns =>10– Acceptance authorization upon return in different season (group name); the user group/s with the right to overcome the check for returns in the same season.
Automatic return approval
If the user belongs to any authorized user group (from the above ones) with the authority to approve returns, the dialog for the user authorization will not show up and the return is automatically approved (with YES in this parameter). The default behavior is to always display the approval dialog (“false”).
Returns =>11- Automatic return approval to users belonging to authorized users group.
Check application methods
The checks activated during the saving documents and they function in an intercompany level.
This will actually mean that in case the customer has bought something from a store and attempts to return it to another (which monitored in another system company and not another branch of the same company) and if the return policy is being circumvented, this will be recognized if only the Items have the SAME coding.
If Inventory dimensions have been entered, all of the checks will be made for the returning Item with the same dimensions as the ones on the line of the sale document.
It is issued to cancel out the value charged by a previous Invoice, in case it was issued first.
For a Goods receipt Note
Appropriate document type: SCN (Credit Note from (after) a Goods receipt Note)
Appropriate transition: 117. SRN=>SCN (Credit note from a Goods receipt note)
This particular document is regarding always a specific quantity of items and cannot be used only for correct invoiced values. We never zero the quantity in it. The system (based on the proper customization of the document), if the user attempts to set the quantity to zero, will warn him for a possible misuse of the document:
If the credit document refers to particular sale invoice/s with which it should be «matched» in order to maintain a proper “balance ageing”, we can declare the document/s in the “Status” sub-page as “related documents”, using the icon :
The ones chosen will be part of the automatic matching executed along with the document storing.
In order to not allow “outstanding quantities” left (so, not to affect the Stock Valuation process), the Credit Note must either generated by transition or entered by typing and linked to the Goods Receipt Note afterwards, through automatic quantities matching process. In order this to be executed correctly, the transition “117. SRN=>SCN” must be defined to the “Origin transition rules” field of the document type SCN.
Sales discount credit Note
Appropriate document type: SCV (Credit Note – discount value)
It is issued for the retrospective discount provision to the customers after an agreement for certain commercial goals has been fulfilled or for a specific invoice if the payment settlement was observed or rarely for fixing an Invoicing mistake (higher prices than what had to be given). If the Commercial agreement is monitored into the system, a mass generation of credit discount documents can be generated and issued to the customers. In the display of such a document, the column of the quantity will not be visible in the line grid layout since it has no effect on the system.
If we are not aware of the Items to which the discount is targeting and we enter the Credit document by using a general Item, then the Sales Turnover by Item will NOT be affected. Therefore, in order to have a correct Turnover per Item and Customer and Stock actual cost value, the discount credit invoices strongly recommended to contain the particular Items for which the discount is given.
Discount for a specific Invoice
If the Credit document refers to a specific Invoice, to save the Items from being typed in again we are able to use the foreseen transitions:
Appropriate transitions: 121. SNV=>SCV (Discount Credit note from Sale Invoice-Goods delivery Note)
122. SIV=>SCV (Discount Credit note from Sale Invoice)
In both cases, the Credit note is generated with a zero (0) value so that it will have to be recalled and the discount value will be entered.
Credit Note for VAT exemption
In case that after the issuing of a sale invoice, a certificate stating a VAT exemption is submitted by the customer, then, a specific credit invoice will have to be issued. In this, the invoiced document lines must be contained with their initial net value and VAT value as “normal” lines and also, all these lines must be contained a SECOND TIME with the same net value and a ZERO VAT value (through a specific for that purpose VAT category – zero) as “reverse” lines. This is necessary in order to update the correct General Ledger Accounts (when analyzed by VAT category). The customer credited with the difference value, due to the VAT.
Appropriate document type: SCN Credit Note of Exempted VAT (Sales)
For the automatic generation of the document, there is an automation available in the documents «SIV» and «SNV», as well as at “Sales/Revenues” list, which using as a source the Sale Invoice will generate the "Credit Note of Exempted VAT”:
After the series and issue date is entered to the appearing dialog,
...the document created and a credit of VAT amount produced to the customer:
How do we see the results of issuing Credit notes?
||Sales/Revenues||List of all Sales documents concerning quantities or values, where the credit documents will negatively update the columns «gross turnover» and «net turnover».|
||Revenues Journal per VAT rate||
It presents all the stock quantitative and value transactions. The Credit notes update the columns of “Sales” or “Exports” generally (depending to each format):
||Item’s return of sales||
The list of return transactions is available in each Items’ administration form:
In the Customer’s statement (of accounting nature) with detailed transactions and progressive balances, the Credit Notes are updating the Credit, except if the “trade accounts update from "reversed" transactions with NEGATIVE entry of the same sign (D/C)” company parameter is activated (set to “true”) and thus, will appear as negative in Dedit. The same update (but summarized) also occurs to Customers Trial Balance.
The Statements and Trial Balances “with turnover separation” give the information of the net and gross turnover information where the credit notes act negatively, as expected:
An accounting entry is created to the Customers, Sales and VAT accounts and it updates the Accounting journals, the Account Statements, the Trial Balances etc.
Receipt of a destroyed item from a customer
In case the customer returns a defective or destroyed item which normally bought (and INVOICED), we must issue a Quantity receipt document using the return sale document type:
Appropriate document type: SRN (Goods receipt Note by customer)
- In case we replace the Item, we are going to send it off with a Delivery note
Appropriate document type: SLN (Goods delivery Note)
Appropriate transition: 141. SRN=>SLN (Goods delivery Note from a Receipt Note)
- If no replacement is going to be taking place, a Credit note will have to be issued :
Appropriate document type: SCN (Credit Note for a Goods receipt Note)
Appropriate transition: 117. SRN=>SCN (Credit Note from Goods receipt Note)
In case our customer returns us a defective product which he delivered but NOT invoiced, then ONLY a quantitative return document will be necessary:
Appropriate document type: SRN (Goods receipt Note by customer)
Appropriate transition: 142. SLN=>SRN (Goods receipt Note from a Delivery Note)
In case our customer returns us a destroyed Item which he had received for checking/testing by a Delivery note without charge, then a Quantity Receipt document must be issued:
Appropriate document type: GRN (Goods receipt Note (without value))
Appropriate transition: 139. DWV=>GRN (Goods receipt Note from Delivery Note (without value)
Following that, we might have to replace the Item with a new Delivery Note with no charge:
Appropriate document type: DWV (Goods delivery Note (without value))
The above actions are concerning the transfer to the customer. As for the product delivered, there is the case back to the supplier or may not be possible to return or consumed by another method, so will follow the registration book memo “write-off” of the product:
Appropriate document type: IWO (Materials write-off)
The write off will update the stock quantity and cost in the “Exports” column. If a particular accounting account is entered at header, it will be posted with a credit of the Sales Account of the Item.
Returning defective item to the supplier
As soon as we receive defective items from the customers, we are able to return them to the supplier and receive replacements or a credit document:
Appropriate document type: PRN (Goods delivery Note to supplier)
Appropriate document type: PLN (Goods receipt Note from supplier)
Appropriate transition: 124. PRN=>PLN (Goods receipt Note from Delivery note to supplier)
Appropriate document type: PCN (Credit note for a Delivery Note)
Appropriate transition: 106. PRN=>PCN (Credit Note for Goods Return to Supplier)
Before deciding on the workflow to follow, it is recommended to be informed about the various types of Shipping to a supplier, by the corresponding Purchases Chapter.
Selling items of special categories
The item sets can be created for two distinguished purposes and different functionality during the invoicing process.
- Easy entering of many Items sold together (Dynamic set)
- Offer of many items in a “package” by special discount/price (Static set)
During entering a set Item in the lines of a document, the parts of the set will be displayed below the set line, which will be colored differently:
The set lines are not taking into account to the calculation of the document’s totals (payable amount) and they do not participate to Ledger posting. They are not actual Inventory registers whereas their parts are actual Items in stock. Especially during Sales, it will be produced sale transactions for them, to give turnover statistics. In most statistics they are not taken into consideration and a relevant criterion is not available. In a few reports only, like “Item sales per customer”, a specific criterion exists (visible only to “more criteria”) with a default value that does not include set items, since if they are included, a double turnover will be generated for the involved Items. However, the user could ask only for set items to be reported separately.
As to the behavior during issue a set-item to a document’s line:
If the set is dynamic, the user can alter the items contained in the set and not the set line fields (where the data of lines of their parts are “aggregated”) with an exemption for the Quantity (so that the user could declare the required number of sets). The system will propose prices and discounts in the lines composing the set, only. This way, if the set is taking part in a pricelist, this information will be completely ignored since its data calculated by the “child” rows of its parts.
If the set is static, the user can alter only the set and not any part of the set. In particular, the fields available for editing in the line “set” are the quantities, the price, the discounts and not directly the value. To the lines of the parts the values of set are “distributed” based on a participation ratio of each one to the set. The system will propose prices and discounts (apply pricelists etc) ONLY to the line of the set Item. This way, if the parts of the set belong to a particular pricelist, this information will be completely ignored, and the lines will obtain their values proportionally by the set line. In the static set, if any line (set or part) deleted, after a warning, all involved lines will be removed.
Color and Size
The color-size functionality during sales is quite alike the one valid in Purchases:
- Line handling with a quantity analysis of colors and sizes in a matrix using the F12 key
- Color and size handling on a line level using “color” and “size” columns
- Color and size handling through a matrix with quantities and prices, while at the same time keeping a distinguishing Item line for every color-size combination with Alt-F12
- Copying color-size from the previous line using Shift-F12
To activate the possibility to define prices per color/size, must set the relevant company parameter, otherwise, it will be used the prices of Item itself.
Lots and Serial Numbers
The Lot handling features as well as the serial numbers in the Sales, are alike the ones valid in the Purchases. In this section we are going to be looking at the feature of the automatic lot recommendations or serial numbers for sale (and generally export) based on criteria.
In the “Item control profile” (in the Sales lines), views can be defined (with the required sorting) and their automatic execution can be defined by checking the appropriate checkbox option, beside these fields. If not, the user will have to call on the automatic selection process manually (using F8 key).
If the lots participate to configuration of pricelists this must be declared here, to the “lots define pricing/discounts policy” option field. In a typical case, the re-apply of pricelist or invoice policy, just because Lots added, is useless. E.g. if a user has given a particular discount and the lots are automatically selected, the discount will be remain as it is, unless the setting has been activated, so it will be recalculated.
For the serial numbers, could activate the checks of the Item’s control profile, for compulsory use only of “available” S/N (field in the Serial number) and for verification of S/N’s “location” to be the current W/H from which the delivery is taking place. Also, could define to select only S/Ns of specific “status” (field of the Serial number).
During the sale of a serial number it is possible to activate the warranty for the customer. This will take place by using a specific document, which will also update the starting and ending dates of the warranty in the serial number, in order to enable checking for Service procedures:
Appropriate document type: WSN (Warranty note of serial numbers)
An example of bailment is the package containing goods that consist subject of the company’s trading process. In general, items that suppliers provide because they are necessary for carrying the goods, usually function as bailment. Such a case is the bottles used for drinks and soft drinks.
This kind of goods are returned to the suppliers and, on sale, sometimes are also returned by the customers, thus their value will not be paid but returned. This means that it is required to monitor the quantities and values which are “pending” towards the suppliers as well as the customers.
Those Items (bottles for example) must defined as of type “Bailment” and the sub-page “Related Items” can be used to define their relation to other stock Items that depend on them. This definition will allow to configure an automatic way to ensure that the transport of all “linked” items would become at the same time.
For example, the bailment item “Empty Bottle 330ml” will have its relation defined with 2 Beers with the corresponding codes and a quantitative relation 1. As a result, whenever a “Beer” of these two is entered, the item “Empty bottle 330ml” will come up as well.
By entering those two Items as relative to the “bailment” Item, the “reversed” relations are produced into those items, automatically:
At “binding relation type” field, must define the relation type code for which the automatic generation of bailment item codes is required.
If we need the amounts caused by bailment sale to be subtracted from the customer balance, during the Credit Control, then, in the Credit Control Policy used, we could use the “User defined limits”. The pre-configured Field Property Profile “ESBailmentBalance” calculates and stores to the “amount 1” header field the current claim from bailment. After activating this to the appropriate document types, at the “expression editor” dialog of Credit Control policy, could use: 1) the customer’s current accounting balance, 2) the current bailment balance through “amount 1”, 3) the current document’s payable amount, and 4) the current document’s bailment value in order to form the requested actual balance for checking.
Result of this customization
- During the sale:
As soon as the Item “Beer” typed in, the Item “Empty bottle 330ml” will be coming up in a quantity matching the quantity of the source Item.
If we add a new Item containing the same item of type “bailment”, the quantity of the bottle will be raised (and will not created a new line).
Monitoring the turnover and trade account balances
Special trial balances can be used as well as customer and supplier statements, in the corresponding menus, for example Entities/Accounts receivable/Account statements/With bailment analysis:
Also, in menu Entities/Inventory/Stock control see the “Bailment per trade account” report that provides information on the turnover as well as quantitative information by trade account and item:
Finally, the dialog with the financial review of trade account, displayed, either by selecting at the document’s header, or by “actions” menu at customer’s form, it could be configured to show additional data for bailment, if the company has such an activity:
This is activated by a company parameter in the customization, at Category: Document Management. The default value is NO, so the dialog does not contain this information part.
Items with a recycling tax
Certain items charged with a recycling tax, which included to the final retail price, while, during the wholesale the charge must mentioned separately by piece. For the specialized Recycling companies of electric and electronic equipment, there are specific Sales lists analyzing those data. For the automatic calculation to take place as well as the document printing and the sales listing, the customizations described below should be done:
- Special accounts
For every different Item category, the following should be created:
- A special account with the following data, to be used at Wholesale and Purchases:
|Calculation method||Stand alone line|
For the fields “Price” and “Value application quantity”, two cases are possible:
Α. If the withholding can be set directly for a quantity like the Weight, then:
Because the recycling fees are usually expressed into tons and the Item weight is usually expressed in kilos, the price would be expressed per kilo (with 6 decimal digits available).
Β. In case the withholding per piece is specific and calculated per item code and we are looking for a way to avoid the weight monitoring, then a user defined field can be used for this reason, for example “Number 1” followed by the required two actions:
- In the field property profile applied, a line should be added like the following:
This is how we can transfer to the Item line of the Item, the amount per unit (which is the “Amount 1” of the line, copying the “Number 1” of the Item).
In the special account form, define the following:
|Price||lineItem.Amount1 (through the key)|
|Application quantity||Packaging quantity (this means “the quantity in the measurement unit of the line”, for example the piece)|
This implementation will ensure that even if the setting in the Item is altered, in the documents there will be an explanation of the calculation of the recycling fee and thus, it can be recreated if necessary i.e. while modifications done.
Make sure that enough decimals have been set in the general parameter managing the decimals of the numeric fields (like user definable numeric fields).
A special account for use in the Retail sales with the following data:
|Calculation method||Incorporate into lines|
This way the calculated amounts of the recycling fee will be included into the item line value.
Alternatively, a “stand alone” special account can be used, in this case though, the retail printing forms (if used) must be altered in a way to display the recycling fee incorporated to the price of each item.
- A special account group, containing the above special accounts.
In any document the recycling fee is applied, the specific special accounts will have to be set as acceptable in the “Charges/Withholding” sub-page.
In all retail documents, we set all the ones “incorporated in lines”, while in the Wholesale documents, we set the “stand alone” ones (depending if they are sales or purchases oriented).
For the Items subjected to the recycling fee the following must be done:
- The Special accounts group must be selected in the field “Charges Group”. This can be done through the global modification functionality of views. For example, in all of the “Electric appliances”, the special account “Electric appliances charges” group can be updated, after its creation.
- If a charge per piece is in effect, in the numbering field used for the “Special account”, the price must be entered in the “Number 1” field.
- In case the recycling fee has been set as a particular price depending on weight, then in the Items of that particular category, the weight measurement unit must be set. Also must define the specific relation to the main unit, e.g. if 7 appliances weigh 1 ton and the amount of charge is set to the ton, then the relation will become 1MU = 7 MMU and MU=ton.
Document printing forms
In the wholesale, the Price per piece of the recycling fee must always presented as a separate line along with the net value, the VAT value and the total value. In the retail sales, the fee must be incorporated to the net value and the total value of the item (so, in the price too). That information can be added in the printing forms through the functions:
ESSAL (<special account type>, <account code-criteria>, <field>)
Returns the value of the field set in the 3rd parameter from the special account created by the current line item which belongs in the 1st parameter, its fee matches (like) the criteria of the 2nd parameter. For example:
ESSAL (10,” RECYCLEFEES*”,”Description”)
They return the code and the description of the special accounts correspondingly (actually the first of them, in case they are more than one) which have been created by the current line, which are charges (type = 10) and their code begins with RECYCLEFEES.
ESSALR (<special account type>, <account code criteria>, <field>)
Returns the value of the line of the special account given in the 3rd parameter, reduced as to the net value of the special account contributed by this line. This way, we are able to get the participation of the particular line Item in the net value, VAT value and total value of the corresponding special account line, like the following examples:
ESSALR (10,” RECYCLEFEES *”,”CurrencyVATValue”)
ESSALR (10,” RECYCLEFEES *”,”CurrencyTotalValue”)
Printing Customization of EEM Items
Prerequisites for those printouts, concerning “Electrical equipment” material, are:
Defining the relevant company’s parameters of category “Printing parameters of Items with recycling fee”:
In which Item’s field is the brand monitored.
In which Item’s field is the category monitored, based on which the Sales report is calculated.
How is the “weight per piece” monitored. We enter either one of the user definable numeric fields (number 1-10) or the weight unit or the alternative unit.
In the relevant criteria of both reports (available to menu “information” of Entities/Special accounts), the special charges account monitoring the Recycling fee should be entered
Those special accounts must be declared to be “depending on the Item” and at the same time, in the Items subjected to this fee, a relevant “Charges group” must be entered.
The EEM items should have the “piece” as main measurement unit.
Result of this customization
For each Item, the charge calculated based on the “Weight” field:
To the totals, the recycling fee is included to the Net value (calculated by item lines).
In the example, “net” prices have been used, which do not include any VAT charge, for comparison to the next example, though the same functionality will be valid in the usual case of prices including VAT.
For each Item, the charge is calculated, but not distributed to items:
From the menu path: Entities/Special accounts/Information can select the printouts, addressed to the Recycling companies and concern the particular items’ categories of the EEM.
The cancellation note is not based on a particular document type, but every time to the type of document getting cancelled.
This function found to the menu “Actions” of the horizontal toolbar of EVERY document:
After a confirmation, a new document is produced with the details and data of the one getting cancelled, reversing ALL of the results in the cancelled document. This way, if for example an invoice that contains cash payment cancelled, the sale entries of all sub-ledgers will be cancelled as well as the cash receipt entry declared into the same document.
In the document lists, the cancelled and cancellation documents are displayed with specific icons, while in the cancelations; the code of the canceled document is also displayed:
To the cancelled document form, a specific icon indicates this status:
The cancelation procedure is regarding:
- The official tax documents where the cancelation can be done under special circumstances, for example in the same day and if the recipient has not gone and take the printed document and the goods.
- The internal accounting Notes, the corrective entries as well as documents displaying process results, many of which do not affect official data (i.e. orders, reservations etc). The cancelation is available in all of the documents in order to allow the easy correction of any mistaken entry, without the need for new document types to be used and customized.
For every document type, the “prefix” of the cancellation series, as well as the numbering series with the “Cancellation” property, is defined.
In any Books, Statistics, Balances, Data analysis cubes, the cancelled document is applied, the effect of the cancellation document is exactly reversed (the same data with a reverse sign).
Especially as far as the matching processes are concerned (“quantitative” that affect the fulfillment level of Orders routing etc. as well as the matching between debits and credits of trade accounts that affect the balance aging), the cancellation documents are NOT taking into account. This way for example, if a Goods Delivery Note that produced by an Order would be cancelled, the Order will become automatically “pending” again. If a Cash Receipt Note connected (matched) to an Invoice would be cancelled, the Invoice will then again appear in the unsettled invoices (open items).
Finally, cancelled and cancellation transactions do not participate to the Stock Valuation process, therefore, documents dated in a prior “stock costing period” should NOT be cancelled. In other words, cancelled and cancelling documents must belong to the SAME “stock costing period”.
The factoring of invoices and whole contracts, by which we can receive as financial grant from the Banking factoring agency the value of those claims (by withholding certain fees), can implemented into the system by monitoring specific accounts and run specific processes, to be able to obtain a full overview of the claims and correct financial/cash balances.
Definition of a special accounting category «Debtors – claims in factoring» as well as declaration of this category to the relevant company’s parameter:
For every customer, claims from which we will transfer to the factoring banking agency, must open a new symmetric debit register with the same person as the customer and accounting category, the one specified to the above parameter. It should also be declared the proper G/L account, for example 30.80.
An easy way to do this is to create the new account with “New by copy” and choose () the same Person for the customer, otherwise a new Person will be created. The accounting category should be changed and afterwards, could select him in the Customer list, and change the field “Type” by global modification, to “Debtor”. From now on, this will be visible not in the customer list but in the debtor list.
In the TOC (Account credit balance offsets) document type, starting a new series titled “Transfer claims to factoring”
The factoring agency should be opened as a Creditor, with a G/L account of short term Obligations (e.g. 52.00).
Transfer of claims
From the sales document list, by choosing the documents to be transferred, even of different customers or just one or all invoices of a particular contract, and select from the horizontal toolbar, “Actions/Transition” one of the following transitions, configured for this case:
Appropriate document type: TOC (Account credit balance offsets)
Appropriate transitions: 149. SNV=>TOC (Transfer of customer’s receivables to factoring)
143. SIV=>TOC (Transfer of customer’s receivables to factoring)
The result will be the generation of as many documents as the customers. In each of them, in the header will be placed the credited trade account (customer) whose unsettled invoices will be “matched” (reset), while in the lines the corresponding factoring debtor will be charged by analytic lines for every invoice with the proper expiration dates (based on the receivable forecasts of each invoice).
During accounting posting, it will be created a credit to the customer and a debit to the factoring G/L account.
Funds receipt by bank factoring agency
By transferring the Invoices, the bank will supply the amount of grant:
Appropriate document type: CRS (Cash receipt (from suppliers))
In the document header, it will be entered the Creditor opened for the Bank, while at the lines of the document should be entered the company’s Bank account, where the funds were deposited. The customer register will not be affected, and neither will the debtor’s register. This document will be presented in the payments list as a “negative payment”. The available funds will be increased (to the Bank’s account), while the Factoring agency will have a new credit transaction. In the accounting the following entry will be posted:
Expenses charged by the factoring agency
The expenses or commissions charged by the bank will be issued by one of the expenses documents:
Appropriate document type: XPI (Expenses Invoice)
In the header, put the creditor (Bank) and to the lines the relevant expenses. To the same transaction may enter the payment for crediting the bank account (liquidity). The customers and the corresponding debtors are not involved in this process.
The accounting will be updated as follows:
Payment of transferred Invoices
The payment of invoices, since it is not our claim any more, at the same time as the debtors credited must debit the creditor “Bank factoring agency”.
Appropriate document type: TOD (Account debit balance offsets)
The results of this transaction are:
- In the Accounting, there will be credit of the debtors (“symmetric” to our customer registers) opened for monitor the claims in factoring and debit of the creditor account opened for the Bank:
The creditor’s (Bank factoring agency) statement will contain a debit, reducing the balance
The debtors’ statement will contain a credit, reducing the balance, whereas to the outstanding receivables, the particular invoices are now matched (settled).
How the matching of the customer payments will be correct?
In order to have an exact matching of invoices, could enter the Invoices’ numbers (one line per invoice) as to the TOC document (while transfer the claims) as to the TOD document (while close the claims and the payments declared in essence) to the “Alternative document” column. This element will be used by the automatic matching process (between open and close items) instead of “FIFO” method. Especially to the TOC document this information already exists due to the transition used (to produce it from the source invoices).
Another view that allow to control the unsettled claims, transferred in factoring, per month, is the Cube Balance Aging (Business Snapshot/Liquidity review/Ageing of accounts (receivable/payable)).
Payment by cheque of transferred Invoices
For the correct update of all of the subsystems in this case, three transactions must take place:
Receipt of cheques by: CRC (Cash receipt)
The debtor, the one with the transferred claims, entered to the header and to the lines entered the cheque/s. The result will be a credit of the debtor (balance of the account) and an open item produced for the payment of the cheque at the proper expiration date, so the “commercial” balance of the debtor will not be affected.
At cheques’ expiration: MRN (Mass receivable notes payment)
To the header the Bank (liquidity) account given and to the lines, the paid (expired) cheques selected. As a result, there will be a Credit-Debit balancing to the debtor’s “commercial balance” and a debit to the liquidity Bank Account. What must now follow is a payment of the factoring agency:
CPS (Cash payment)
With this entry, the cheques’ value will be transferred to the creditors’ billing. To the lines of this document must put the liquidity account set as the “payment account” in the cheque. That account will be credited.
All the above means that what will happen with a single document (TOD) in case of a bank payment, will take all these three entries to complete the process, when paying by cheque.
- Could have opened a liquidity account for the loaning and set it as a payment account in those cheques, so accounting-wise everything would be correct without the need for the last payment (CPS), in this case though the Factoring agency account would NOT have the right balance.
If the transfer of claims is about invoices of a prior fiscal year which do not exist in the system as documents (for the transition to make possible) rather just as opening balance entries, then, the opening balances could have been entered analytically by invoice and expiration date. Thus, we could during the “transfer of claims” step to type manually the lines based on that information (unsettled invoice numbers and due dates).
Cooperation with many Factors - claims monitoring per Factor
If we are working with more than one Factoring agencies (Banks), then more Debtors must to be opened per Factor.
Each one of them will have to belong to a different accounting category. This is not lead to different G/L Accounts, but must be done , in order to make possible the automation of transferring the claims through the preconfigured transitions for this purpose:
In the TOC document, instead of one document series, must open separate series for each factor. This document is an accounting note (and n a taxable document) and its series can be opened freely according to the needs.
Finally, to the two company’s parameters concerning the process will have to be declared, all the accounting categories (and not just one) of all factors, separated by comma, and all the corresponding document series, with the same order.
At the above example, the 1st accounting category concerns Alpha Bank for which the series “01” opened and the 2nd accounting category concerns Euro Bank for which the series “02” opened. These accounting categories have been declared to the “accounting category” field of the Debtors opened to monitor the factoring. If, some invoices of a customer transferred to one bank and some other invoices to another bank, the “symmetrical” debtors that should be created are TWO, one for each bank.
What is it we succeed through the above customization?
During the transition ”Transfer of customer’s receivables to factoring” creating the document TOC, the user selects the document series and through this, the system recognizes which debtor register will place to the document lines: the one with the corresponding to the series “accounting category” and the “person” of each invoice’s customer.
Following this, can view the transferred (unsettled) claims per FACTOR through e.g. the OLAP “Ageing of accounts receivable” using grouping by accounting category.
The needs for pricing and discounts proposal on sales are not standardized but are dependent on the size of the company, its organization, the type of market it acts in, the profit margins, the agreements and contracts made with the customers etc, and all these are factors which form the commercial policy of the company. The system provides the proper functionality to cover the wide variety of needs for every installation.
A simple pricing policy can be covered through static fields in the basic entities of the Item and the Customer, while more complex pricing policies require the use of the pricelists.
As to which of the five available prices will be proposed during sale, it is defined at the customization of the document type in the field “Default line price”.
Item prices per dimension
In case the sale price is defined not only by Item, but also for example by color, the new variety of values will have to be defined in the “Prices by dimension” sub-page of the Item. Using the icon «Dimensions Development», there are created all of the possible combinations of size and color based on corresponding “pallets”. The price/discount entered here will be proposed during invoicing, while for the combinations not found, the defaults come up from the item itself.
To activate this feature must set the company’s parameter “Activate "Prices per Dimension" in Items” of Category “Stock dimension functions”.
Prices per zone
In case of a simple pricing policy where the company has limited needs for monitoring different price per customer group, the pricing zone can be used. The pricing zone is defined in the customer’s administration screen at “commercial terms” sub-page and is a choice among the 5 available Item sale prices.
Assume that a company classifies customers into small, medium and large and diversify the sales price of the goods as categorization.
In this case, you need to use the 3 by 5 kinds of prices available, for example, the wholesale price for sales to large customers, the price 1 for sale in medium-sized customers and the price 2 for sale in small-sized customers. To each customer must determine the zone he belongs. This will be taken into account when billing for proposal of the appropriate price, regardless of the general proposal of the type of document.
VAT included in prices
In case the price includes VAT charge, like at retail prices, the option “With VAT” must be activated, beside the price field. The VAT part, calculated in the “gross” price is thought to have been based on the VAT category of the Item and of the company’s headquarters VAT regime. This way, in case this price used for a customer of a different VAT regime, a de-taxation take place, applying the new rate for result in the “proposed price”.
The basic pricelist contains the prices for all Items and Services. It can be used as a reference to create “discount” pricelists as we’ll be seeing in the following chapters.
The use of pricelists recommended for the pricing compliance (compared to the use of Item price fields), since the pricelists contain significant advantages like:
- Historical data
- Variety of price differentiation criteria
- Abilities for easy, mass re-adjustment
Defining and processing of pricelists will take place through the menu “Tools/Customization/Invoicing policy”
Discounts on the basic prices
As to the discounts, it may be in force either a simple or a more complex policy of the company. In this chapter, it will be examined some ordinary scenarios and the way they should be implemented.
There is the possibility to assign discounts on top of all base prices. This can be done on the basic entities of Items and customers.
In the customer’s administration form, can define a % discount thus, during invoicing, this discount will be proposed to the “%discount” field of document header. The % discount of the header, according to the pre-configured setup of document types, will be transferred to the % discount1 of the item lines.
Recommended (fixed) item discount
In the Item’s administration form, the «%discount» of the Item can be defined and transferred (according to the pre-configured setup of document types), to the % discount 2 of the Item’s line, during the sale.
The discounts given to these fields are proposed to be steady to all the trade transactions of the customer. As can be seen, something like that would be confining since it proposes a totally flat trade policy per customer without taking into consideration important trade factors like the sale quantity, differentiation of discount per Item category, seasoning etc. For this reason, we recommend the use of discount pricelists, through which commercial policies with more flexibility can be implemented.
Discounts based on quantity
The discount policy, which must give a percentage discount on the prices of basic pricelist, according to sale quantity, implemented through “discount pricelist” using quantity scales. Select ”Define Pricelists”, to create a new pricelist:
Assignment of discounts: This is where the field, on which the discount is applied, can be chosen. It can be applied directly on the price (the discount will reduce the unit price), or to be placed on one of the three discount fields (to be visible in a discrete field).
Reference Pricelist: Choose as a reference pricelist the basic pricelist (that determines prices). The pricelist will act successive with the discount pricelist.
In the «Pricelist Processing» as many lines will have to be created as the quantity scales. To the “from quantity” field the starting quantity is declared while the “up to” quantity is recognized from the starting quantity of the next line. During the invoicing, the % discount is automatically chosen with its maximum quantity compared to the sale quantity (equal or less).
In the area of the dimensions, apart from the pricelist and Item, so can the starting quantity of the scale be used.
The reference pricelists can be implemented in great depth meaning that, we can create quite a few successive pricelists, covering specialized cases of discount policies. In any case, the final discount pricelist will have to be linked with the customer (if it regards a certain customer). The process of prices/discounts rendering will continue up to the point where a pricelist will be in effect, declaring not a percentage on the basic price, but an actual price. On the other hand, in contrast to the price that only one pricelist will assign, the percentages of discounts will be applied in addition to the field in effect.
Discounts per item category
In several occasions, discounts provided for large Item categories. In this case, it is not required to create analytic pricelists containing all Items. Cumulative pricelists can be created per Item pricing group. To make this clear, we are going to examine certain scenarios:
Different % discount per Item category
In the Item’s administration form, the pricing group field must be defined.
A new discount pricelist is set and we create (“pricelist processing”) as many lines as the item pricing groups. During the invoicing, the discount percentage will be applied in all of the Items that belong to the chosen group.
If there is any pricelist line for the explicit item, THIS discount will be applied instead of the pricing group’s discount. So, the two functionalities (discount per item, discount per group) could coexist into the same pricelist.
Different % discount per item category and additional discount per customer category
In this case, we need an additional pricelist acting additionally to the previous one. This way we will not require maintaining the same information in every pricelist.
Assuming that we have set a pricelist containing the prices and discounts for the Customer pricing group “Store chains”. In this pricelist, we provide a 10% discount to all items belonging to the pricing group “Beer”:
The customers of another pricing group (“multi-store”) must receive an additional discount 5% only or the same items’ group/s and we do not wish to repeat the definition. Additionally we want, if the pricelist changes (e.g. for the previous customers’ group “store chain” the discount increases), the new discounts to be automatically valid for the customers of this group (“multi-store”) as well, without any additional user action. Therefore, the pricelist of the two customers’ pricing groups must be “connected”.
So, we must create a pricelist using the reference pricelist feature.
...and in that, we define only the additional discount:
The reference pricelist will act super imposingly in this case, meaning that it is examined => giving a result => If another pricelist is in effect it will also give a result => and this process is continued until the process stops when a pricelist of a PRICE type found. Τhe % discounts of all lines will be applied additionally in the field they affect. Τhis means that if all the superimposed pricelists assign the field “%” in “Discount1”, the final result will be the adding all percentages in that field (in the above result, the items of group “Beer” will have a 10% discount for customers of group “store chain” and a 15 discount for customers of group “multi store” (displayed to the “%discount 2” field of the document line).
If we were declared the “discount 3” field to the “Multi-store” pricelist, the “discount 2” field to the “Store-chain” pricelist and “directly to price” to the “general sales” pricelist (that contains the initial sale prices) then, during invoicing, we would have the following result:
Discount pricelists giving to the customers of a “vertical market” the MAXIMUM discount for the items of this market and REDUCED discounts for items beyond their objective.
For example, in any of the following “markets” there are three (3) pricing groups: retail, wholesale and super wholesale. In every customer or group of customers, a different combination of those prices can be made.
|Vertical market||Discount percentage over pricelist price|
In order not to define discounts for all the combination, the implementation of such a policy is achieved through the use of type “combination” pricelists. In particular:
Λεξικό - Προβολή λεπτομερούς λεξικού
- We use ONE pricing group X Y Z in every pricelist (Retail, wholesale, super wholesale):
Following this reasoning, we create nine (9) pricelists where the discounts analytically defined per Item or by only one line for every pricing group.
- The next step would be to create the pricelists combining some of the 9 discount pricelists. For example, to the customers with “Furniture” as their main activity, we sale furniture in Super-Wholesale prices, while for all the rest items we sell in “Wholesale” prices:
It regards a type of “Bill of material” pricelist, which does not have its own lines, where we enter all of the actual pricelists; those that we need to apply during the invoicing.
The same functionality obviously could be achieved if in every pricelist, we would define all discounts for every item group, but that would have a large maintenance cost, especially when we get:
Large number of items’ groups
Different discounts per branch or
Date discount limits or
Scaling discounts based on quantity
In such cases, we need a definition process of saving statements and minimizing the cost for maintenance and control of the prices/discounts.
Daily, weekly offers
In periods of offers, it is required to cancel all of the possible prices and discounts for a particular “offer package” to be in force. To achieve this, first we must insert a line to the pricelists for the particular validity days for the offer price (so, preferred by the system, compared to other lines that give a price effect over time), and secondly, in order to avoid additional discounts, we must insert to the “discount pricelists” a zero line (no price or discount), with the same validity period. As soon as the offer period expirs, the previously used invoicing and discount policy will be automatically activated.
Example: While for an item (or a category) there is a pricelist for assign prices (e.g. 280€) and a discount pricelist where a 20% off is provided, we want for a ten-day period 20/07 - 31/07 to disable this policy and to provide an offer price of 50€.
In the pricelist (for prices) we enter an additional line, dating 20/7- 31/7, with 50 € offer price.
In the discount pricelist we enter an additional line for the same period without filling out NEITHER a price NOR a discount. This line will act as a zero discount and the 20% discount will not be provided. The result in invoicing will be the offer price exclusively provided.
Providing the maximum discount to the customer
As seen before, the method of handing out discounts can be the result of a few different sources, which additionally provide discounts to the final customer. Quite a few times, it is required not to apply all of the discounts but, among all the valid discounts (item, customer, area etc) only the greater one to be applied.
This functionality can be achieved through the setting “Select maximum discount” in the pricelist processing.
This will lead to a simultaneous processing of all rows that match the line of the document (type, branch, quantity, date period etc) and choose the larger discount than those specified. On the other hand if this field is NOT activated, the system will choose ONE line of all valid pricelist lines with a certain priority: e.g. the item discount will overcome the item pricing group discount, while by activating the “maximum discount” setting, the largest discount will overrule even if it has no priority.
Customization information on the maximum discount
This function has the following conditions to provide with a clear and useful result:
It needs to be activated in the 1st (basic) pricelist applied every time. This means that if a reference pricelist exists, this setting ignored and only the “maximum discount” setting of the main pricelist (having the reference pricelist) will be taken into consideration.
It must be defined in pricelists assigning result percentage to one of the % discount fields of the line (1,2,3) and not to the price field.
No more than ONE percentage field of the line item can be used neither from the possibly overlapping pricelists nor by field property profiles or invoicing policy terms.
A “field property profile” should be customized, accordingly. The default field property profile «ES-1-SALE » will have to be replaced by «ES-1-SALE-MAXPRICE », which does not update both «%disc1» and «%disc2», but only «%disc1» with the larger of the Item and Customer discount. It is imperative to be used in case when the discounts handling made not only through pricelists, but also by using the fields of discounts in the basic data of items and customers.
Application of pricelists during sale processes
The application of prices and discounts during ordering/invoicing depends on the customization of the document type. The setting “Apply prices and discount rules” (at the “behavior” sub-page) must be activated.
Price choice priority
Prices (or/and discounts) can be defined in several parts of the system, like in the basic Item files, in pricelists and more rarely in the invoicing policy. All those sources of providing prices and discounts examined, made into hierarchies and applied. The source with the highest priority, which can use or cancel the results of previous sources is the Invoicing policy, since it will be applied in the end. The source with the immediately higher priority is the pricelist of the header and finally the basic entities (Item price, customer price zone etc).
Τhe system during the course of tracking a price in the pricelist, it will take into consideration a set of criteria coming from the item line and the document header, which used as a key of finding lines in the pricelist. These criteria are essentially the “dimensions” of the pricelist: Item, Item pricing group, package unit, currency etc. Any change in those fields will cause a recalculation of the price.
The criteria taken ALWAYS into consideration to confine a pricelist set of lines (which will flowingly be checked to find the price) is the item either the pricing group of the item and the date (lines with the closest validity period from and up to the document’s).
Among the pricelist lines “fitting” to the above criteria, the ones taken into consideration will be the ones of the following, that either have a value compatible with the documents’ data or they have NO value: ‘Branch, ‘Business unit’, ‘Measurement unit’, ‘Lot, ‘Color’, ‘Size’, ‘Dimension1’ and ‘Dimension2’.
This process will possibly track and locate a lot of valid lines in the pricelist but will only choose ONE, which will give out a default price or discount in the line. In case of using reference pricelists, one line will be chosen PER pricelist which will add up to the previous valid discounts, unless there is a setting of maximum discount.
This “choice process” will be based on the dimensions (fields) of the pricelist:
Item pricing group
Currency (if null, considered as the base currency and if the document has another currency, a conversion is made)
Measurement unit (if null, considered as the main MU and if the line has another MU, a conversion is made)
Controlled user access to prices/discounts
For all processes like pricelist or invoicing policy administration (creation, modification etc), for re-adjustment of prices, for access to the discount and prices fields of the basic entities (item, customer), the granting of access rights is done through the general access management system (tools/user privileges).
However, especially for the fields of prices and discounts of documents, the definition may need to be different per type of transactions (sales, purchases, ordering etc) or per branch.
For that reason, a special setting foreseen in the document series, where the access rights defined per user group to allow or disallow certain actions. One of those actions is the prices’ and discounts’ handling.
Global processing of selling prices
For a particular inventory item
From the Item’s administration “site”, in the area Pricelist of the context hierarchical tree, we can see all the pricelist lines concerning the Item. Through the actions menu, the ability to process these lines is available.
To all the above processes, in case of giving percentage, the result may have any number of decimals. The user can define the rounding method, by “number of decimals” and “fixed decimals segment” fields. See next chapter for this functionality.
Mass process of adjustment selling prices
Periodically there is the need to adjust the selling prices in the basic tables (Items and Item prices per dimension), while also in the pricelists. This task is made easy by the process “Readjustment of selling prices” (Periodic processes/Stock updating processes).
Auto-assignment of prices to associated items
When we have items sold to pieces as well as to packages (of multiple pieces), which are monitored in different item registers, then the need comes up of single and mass management of their prices. The main reason that might lead to open multiple Item registers in this case, instead to one single register with many package units is mainly the need to monitor the actual stock for every package unit. For example:
|1000||Soft drink 1lt||1,5|
|1000.01||Soft drink 1lt X 6||Unit price * 6|
|1000.02||Soft drink 1lt X 12||Unit price * 12|
In the item’s administration form (“site”) there is the “Basic Item” field. All items are “basic”, except otherwise defined. In all connected items (with a quantitative and pricing relation to basic items) this field must be de-activated, thus, the field “Belongs to Item” will be enabled, in order to select there the basic item, with which is connected.
In the “Related Items” sub-page, the pricing relation with other units can be defined (apart from the quantity relation). This data used by the process of adjusting selling prices, which assigns the appropriate prices to all linked Items too, taking into account this information (pricing relation).
In pricelist processing screen (Tools/Invoicing policy), with the action Adjust main item prices we can easily make direct assignment of prices or adjustment of previous prices as to “main” items” as to the linked to them items.
To the 1st part of this dialog, we can define criteria for displaying pricelist lines (items). After run this view (Accept), to the 2nd part of the screen, we can either assign a price for a validity period or adjust previous prices using a percentage. Also, we can define the way of rounding (like to all use cases of pricelists). After we select “Run” in order the new price to be transferred to all items and pricelists used, to the 3rd part of the screen, we can see:
(a) a first level of main items (b) for each of them, in a second level, the relevant pricelist lines, as well as the previous and the new price (c) for each line, the generated “child” lines with the related items after apply the “pricing relation”.
To store the calculation results and/or the changes made, must press the “Save changes” button.
Τhe invoicing policy provide the ability to fully control a trade document, to combine certain conditions and give as a result certain actions e.g. field’s value changes, new lines of all types, gifts and alternative offers etc.
The need for the Invoicing policy to be used results by the fact that the pricelists, through which the pricing and discount policies (by item, customer, group of items, group of customers, quantity scales, date period, business units etc.) are implemented mostly, are only aware of ONE item line at the moment of assignment prices or/and discounts. Thus, we cannot apply a policy based on the overall picture of an order or invoice (e.g. total value, item categories that ordered, total quantity etc.) or even financial data of the customer (line his overall turnover) independent from the particular transaction.
This chapter will examine various business scenarios like the above, as to their use and implementation.
Infrastructure - model
The invoicing policy consists of a number of entities combined to give the desired result for each customer, during ordering or invoicing. This concept will become clear through the following definitions:
|Invoicing policy||The invoicing policy contains all the terms through which the final result is produced, during invoicing.|
The invoicing policy is connected to the customer either directly to the field “invoicing policy” or through his pricing group (used at pricelists too).
|During the order/invoicing of the particular customer, the invoicing policy is applied, if only at the document type (at the “behavior” sub-page) the setting “Apply prices and discount rules” is activated.|
From Tools/Customization/Invoicing policy, we must configure the possible conditions and actions and using them, to “compose” the invoicing policies and connect them to customers.
In the “header” of the Invoicing policy, the following data defined:
|Type||Sales or Purchases|
|Validity period||Its completion is not mandatory. These dates copied to the “terms” lines.|
|Replacement pricelist||If completed, it will overrule as a proposed pricelist in documents (against the trade account’s pricelist).|
|Pricing group||If completed, it will be selectable for the trade accounts belonging to the particular group.|
|Auto run||Selection of document line types where we need automatic executon. Then, a dialog containing the terms will appear (depending on the display property of the terms), automatically as a pop-up, without any action from the user.|
In the area “Invoicing policy terms”, the combination of conditions and actions is defined and when, during ordering or invoicing, one or more of them become valid, then an action (or the actions foreseen) will be triggered.
An important clue of an invoicing policy is not only the achieved result, but also when applied or displayed. In its definition, in the terms area, the Application method as well as the timing of a term application are defined in order to produce the required result.
Discounts based on quantity and Item category
Assuming that the company decided to give an additional discount, depending on the total sale quantity of Items belonging to a particular Item category:
|Category 01||> = 5||3%|
|> = 10||5%|
|> = 20||7%|
For the implementation of this policy, we should follow these steps:
We create 3 conditions and 3 actions to cover the above scale:
Before creating the conditions, we have to create a condition template. From the library of the available templates, we choose the one containing the relevant fields (item category and quantity in our example).
The «Parameter preview» in the form of template is available only for informative reasons (how the parameters will look like) and not for specific values to be given. This will happen to the condition form.
We create 3 conditions that need to be true in the document, according to the above policy. For every condition, we enter a code and a description and in the condition clauses* we choose the condition template of the previous step and define to the “parameter definition” the data that must be checked:
The quantity field: we set “Quantity”
Value field: we enter « > = 5» meaning the checking value.
Calculate quantitative field: on all selected rows or per line. Here, “selected” means the lines of items belonging to the particular categories.
Categorization field: we set the field “Category” of the Items
Categories: we type or select (by F3) the particular values of field “category” (01 according to the example).
* Obviously, the condition clauses may be more than one, based on different condition templates, connected with AND, OR, etc. to create a logical expression but here we need only one.
Similarly we make 2 more conditions for «field value» > =10 and > =20 according to the example.
Correspondingly, we create 3 actions which we need as a result.
In every action, we type a code and a description, as well as we define the particular result that must produced, if the condition is met. In our example, the action will be “Assign to item lines”:
Next, we set the discount needed.
Field name: Assuming we want the field «%discount 2» of the line
Operation: We have the ability to either replace the field value by choosing Assign either to add to the existing discount percentage value (e.g. from pricelist), the present percentage by choosing Addition.
Numeric value: We set 3 for a 3% discount
Finally, in the same screen, the following are set:
- Apply only in the condition items: If activated, in the example, the discount will only applied to the Items of the category “01”, while if deactivated, the discount will applied to all the items in the document.
- Apply up to item’s maximum discount: The system checks in this case the maximum discount of every item (possibly configured to the item’s register) and it will place not necessarily the «3%» (IF that along with the existing line discounts goes higher than the Item’s maximum discount but the difference up to creating the maximum discount as a percentage (%).
- Apply only greater discounts: If the field set in the Invoicing policy (e.g. % disc2) already has a value, either from the Item, or from the header, or by typing, or by pricelist, then the Invoicing policy is applied only if the discount formed is equal or greater than the one already existing to this field.
We create an Invoicing policy where actions and terms are connected in the terms grid:
We match the Invoicing policy to the appropriate customers through the global modification functionality.
Result during invoicing
In the document, the invoicing policy is recommended and saved. Assuming that the document contains the following information:
Asking for apply invoicing policy by pressing ALT+ Q or next to the field, the invoicing policy will affect the lines 3 & 4 with items belonging to the category stated and not the lines 1 & 2 with items of a different category. The quantity checked (to be greater than 10 in this case) is the total quantity of the items of category “01”.
If however had declared “per line” to the conditions’ parameter field “calculate quantitative field” (instead of “all selected rows") then, the line #3 would take 0% discount and the line #4 would take 3% discount because its quantity is greater than 5 (the 1st condition would be true). So, the check
Additional discount due to payment method
Extending the first example, assuming that the company decides to offer a further 2% discount, as motivation to the customers who pay in cash. For the implementation of this policy, we will have to follow the steps below:
We create or choose a condition template “Based in payment method”:
We create a condition where the template and the parameters are set with the payment methods («00001- cash»).
We create an Action where as a type of action we choose “Assign to document” and in the header of the document will add a discount of 2%.
Finally, in the Invoicing policy we add one more term (with this condition and this action) and we define that it belongs to a different group.
If now we have taken care of the % discount of the header to be transferred e.g. in the «%discount 1» of the lines through a field property profile, we have achieved the required result.
Providing gift due to order quantity
Suppose that a minimum order of 3 boxes earns a gift of the Item coded 004.
|All||> = 3 boxes||1 piece of item 004|
For the implementation, we follow these steps:
Creation of a condition template where in the parameters we chose “Based on Quantities field line”
Creation of Condition where the condition template is chosen to the “condition clause” line. In the “parameter definition” in the Quantity field we choose «Quantity in alternative MU» and as value we set > = 3.
Creation of Action of type «Insert stock item» where we choose the item given as gift. We also define in the field Price, receiving the value «0» by assigning action.
We connect the condition with the action in an Invoicing policy term.
During the invoicing, if an item sold by 3 or more boxes, the result is the automatic addition of a gift item (with quantity 1 and price 0).
Charging installation services of particular items
Assuming that a company trading heating items, wishes the customer to be charged during sale by installation fee depending on the item category.
|Item category||Service item|
|Air Condition||Installing Air Condition|
For the implementation of the invoicing policy, we must the below customization:
Create a condition template with condition parameters “Based on Quantity field and Item category”.
If such a condition template already used by another Invoicing Policy, we use the same one.
Create two actions. As “action type” we chose «Insert Item» and in the field “Item” we choose the charged service.
We create the invoicing policy combining the conditions and actions based on the example table. We do not define group or priority because they are not “Mutually exclusive terms”. They all must be applied, since the conditions become true. This means that if the client buys an air conditioner and a radiator, it must be added automatically to the document, the both two services of installation.
Result - Application
As a result during Invoicing, if the customer buys Items of the category Radiator, he will be charged with “Radiator installation” while buying Air-Condition he will be charged with the “Air-conditioner installation service”.
Charging insurance fees to sales abroad
Let us assume that in every sale abroad, taking place in specific delivery terms, there is a charge of insurance of 100.00 euro.
In this case, we need automatic adding of a special account. We have to proceed to the following customization:
In the relevant document types (invoices, orders) we add this special account to the sub-page “Charges/Withholdings”.
Create a condition template choosing parameters “Based on delivery terms”.
Create a condition and in the parameters panel, we choose the delivery method for which applied the charge.
Create an action, where, as action type we choose “Insert special account”. This will activate the field of the special account where we pick the account we created.
Create a term in the Invoicing policies we are interested in, with the condition and action.
Result - Application
In trade documents with the particular delivery term and if the customer has this Invoicing policy, the charges account will automatically be added to the special accounts sub-page, increasing the total payable amount.
Discounts by combining quantity scale of many categories
Assume that the company is trying to sell products of a category for which there is a large stock. In order to promote their sale, it will activate an offer where if the client buys Items of this category combined with another category, an extra discount can be provided.
This is a scenario where the Invoicing policy needs to combine different quantities and categories in one condition. Implemented as follows:
Create a condition template with parameters “Based on quantity field and Item category”.
In the next line, we enter the second category of values for the same condition template.
We create 3 actions for the 3 discount percentages, based on the table of the example.
As in the previous examples, we connect the conditions to the actions in terms of invoicing policies. Exactly because the terms are mutually exclusive, we define that they belong into the same group and declare the priority of the terms in descending series. This will mean that the term we need applied first will be the one with the largest discount.
Result - Application
During sale, if the document items belong to these categories and the quantities of each category is in the particular range, we result in getting the corresponding discount.
Sales discounts controlling
A display that allows us to have a more global and complete knowledge of the discounts given to the customers, is the Sales Discounts Justification (Business snapshot/Sales Statistics/Customer sales Statistics).
This list allows us to check WHICH discounts our customers have gotten and HOW (incorporated to invoices due to item, due to customer agreement or over credit discount invoices/rebates).
On the 1st level, the customers with the basic turnover information appear, while in the next columns it is analyzed for the “Starting turnover” (amount beginning with), as well as in regards to the discounts given (“on invoices” and “due to turnover”, that is retrospective discounts. The average percentage of discount is being calculated along with the “scale” of the average % (1-100 by 10% intervals), in order for anyone to be able to handle a categorization of the customers.
On the 2nd level, we can see a DISCOUNT TYPE (“Origin”). The amounts that have been granted, separated into 2 basic categories: “Invoice Discounts” and “Retrospective Discounts” while all the displayed data allow access to the related invoices. It has been assumed that the “price” is not decreased by discounts, but they are placed to the discount fields:
In «%Disc 1» the customer discount (header),
in «%Disc 2» the “Item Discount” and
in «%Disc 3» the user Discount
We’ll also be able to see:
All of the Discount type special accounts, which have possibly been used with their title in the “Origin”. As an effect, if discount special accounts are in use, the title of the special account, will be displayed here, as a reasoning of the discount (e.g. “3% due to payment method”, “5% due to invoice revenue”). Especially the “autonomous” accounts (which don’t affect the turnover) will be displayed only to the 2nd level distinguished by the coloring of their line, for informative reasons.
The Discount Credit Invoices for the selected date range, one by one
- Any “no charge” Invoices will not be displayed either in the starting turnover or in the Discount amount either a price = 0 or a Discount = 100% has been used.
Sales and distribution performance indicators
A summarizing presentation of Sales processes indicators is being displayed by the Sales and distribution performance view (Business Snapshot/Performance Indicators). Those “indicators” cover a wide range of the Sales process and allow us to locate problematic spots in general and also allow us to see if the Ratios are being improved or getting worse ( in correlation to the same month a year before):
The Customer & quotations administration is in the 1st part:
- New Customers created, based on the 1st Trade Document entered for the customer (offer, order, invoice)
- Prime Clients Ratio: In the “Advanced” parameters () the % of the turnover considered to represent the Prime customers can be set. The 80% is recommended in this case and the indicator will display HOW MANY (in number) customers have reached the 80% of the turnover,
- Average Quotation close time, which in a later state became an Order.
- Lost Offers Ratio, using the “workflow step” of offers (could updated through a transition “in-place”), which is configurable to the parameters () with a proposed value “LOST”.
- Lost Sales Ratio, which updated by the “lost sales quantity” (if used the transition “Discard sales order)”.
In the 2nd part, the average “Order fulfillment cycle”:
- Average order routing time: Time taken between the order and picking. The document SRC is recommended for the picking and is defined in the “Advanced” parameters.
- Average order preparation time: Time taken between the picking and the actual delivery of the order, where the “Delivery” based on closing entries of the picking process.
- Average order shipping time: Time taken between the order and the delivery, where the “Delivery” based on closing entries of ordering process.
- Average order delivery delay time: Comparison between the actual delivery date (date of issuance) and the scheduled delivery date (of entries that the delivery “closes”, e.g. picking or order).
Retail sale points
The functionality of the Retail Sales, as to the behavior, the concepts, the sub-ledgers update and the configurability resembles the Sales cycle in general.
A large differentiation found in the User Interface because in Retail case, the screen will need to contain the minimum required data that the user would most likely need. At the same time, all the Actions will need to be gathered so that the user will be easily trained, and also complete every transaction in the minimum time. The proper dynamic forms should designed and implemented, covering the aspects and needs of the business. Ideally, the ESRetail ™ should be used, which is addressing to this type of market, covering and resolving matters of usability and speed in the best way.
In this chapter, we are going to examine some special functions and customizations of Sales addressed mainly to the Retail points (either we refer to occasional retail sales or to intensive Retail). More information on the functionality of the fields, discounts, invoice policies, dimensions-sizes etc. see in detail to the previous chapters about Ordering and Invoicing.
Simple retail Sale (intensive)
Appropriate document type: RCR (RETAIL NOTE - DELIVERY NOTE)
This document does not update the Accounting. The accounting is being updated through a packing procedure of the retail slips which creates a summarized entry, to be posted by series and date.
In the example, we see one of the many alternative forms that retail receipt may have.
- The document series is automatically proposed, based on the user and its access to series.
- The customer usually is a “General retail customer” which is defined in the document type or in the Branch of the Series (in the “Retail customer” field)
- The user has no access to the date unless the series is manual. Otherwise, the date is the login date.
- The gross prices of the Items used in the retail receipts (the Item price + VAT charge).
Those may contain special charges of any tax type if it has been defined as a special account of the “Tax” type depending on the “Item” and they are of % type applied on the initial (net) value.
- The easiest way for the user to provide a discount is by pressing Alt-F7
- If an Item line is concerning a returning Item, use Shift-F4 to declare this, while the line itself will appear with a different color, for visible distinction.
- For the completion of the transaction, the user must enter the payment. In order to move from the Items tab-page to the payment page, press F6. See details for payment, during retail sale, in next chapter.
Retail sale to a particular customer
If an Order is entered previously or the customer had an advance payment or, in general, if the customer presents a receipt of an advance-payment, instead of the General Customer, the particular Customer is the one who should be declared to the header. There are cases of Retail Sales, which do not have an intensive rate, for example Jewelry stores or Electronics stores, where for Customer Relationship Management reasons, the identification data of the customers are used and stored.
In case the customer has already been entered, it will be searched by one of the known search methods (based on the name, phone number etc). On the other hand, if the customer is not found, it will be immediately entered using the icon and a dialog containing the minimum entering requirements will appear, in order to create the customer’s register.
The payment can take place in a number of different ways. Through the (general) customer, the payment method must be proposed in the retail receipt, and this must be a “mixed payment method”, so that all payment types to be covered. The receipt is configured to disallow the storing, printing or exiting without having completed the total payable amount in the payment part.
If the total amount given to the “Cash” line, the entering has been completed showing the change as well (if the receiving amount is greater than the payable amount).
If the user attempts to store, a dialog confirming the total amount in cash appears (with the ability to choose the individual coins received).
Using the virtual keys showing notes and coins, we are able to interact with the “Receipt” field and according to the amount, the change is also calculated. The coins and notes displayed are the “available” ones for the currency of the document (Tools/ Customization/Organizational parameters/Currencies/Notes- Coins)
If the payment method is by credit card, the user will choose the type of credit card in the “Credit Card” line. This way, the relevant liquidity account will be filled in, and the maximum number of installments of the card type will be used. If the card corresponds to more than one clearance banks (in effect more than one liquidity accounts) the proper one will have to be chosen by the user.
If an advance payment has been entered, or a credit balance is valid, then in the “Credit/Advanced payment” line we’ll have the following:
- If the receipt is concerning a particular client, the Ctrl-Y can be used in the “Amount” column. This shortcut causes the proposal of the customer’s credit balance (if any) to the column “amount”.
If we need to maintain the information of the matching (in case that advance payments are more than one) and need to avoid the typing of a specific receipt, we are able to use the alternative document column pressing F3 to search and select among the available outstanding credit documents. By pressing “Accept”, the amount updated with the open amount of this transaction.
If the receipt is about a retail customer, the amount should be typed, and to the “alternative document” column to enter the exact receipt code that the customer carries (in order the correct matching to be done).
In case the payment has been given to an order, by choosing this document, it will be added automatically to the “related documents”, so that an automatic closing of the ordered quantities to be done also, without the need for any further actions by the user.
What is generally recommended, is the advance payments to be entered in the Order (which is the Order of the Inventory Items as well as the collection receipt) and not in independent Cash Receipts, which contain no description of the reasons they were entered.
Goods return and buy options
When the return policy allows no returns but only changes, the way to enter the return is by returnable Items in the Retail receipt itself, with which the customer buys new items.
For declare the returning line we use Shift-F4 and the payable amount will be the difference between the sold and the returning Items.
If the change cannot take place or the customer does not want it and the company’s policy allows it, we can always enter a Credit Document for the customer:
Appropriate document type: RCN (Credit note for a retail sale) or RSC for mass posting, after packing process
In this document, the money return can be entered in the payment part of screen:
If no money is returned, as usual, this document can be used at the future (buy option), for example at the next season. The way to use this later as a “payment method” has been explained before.
Electronic signature per receipt
This functionality is extremely useful in shopping stores on which more than one salesperson work on the same terminal (computer). It provides us with the information of which salesperson / user served how many customers, no matter who logged in (an employee often takes the place of another without re-logging).
The activation of the electronic signature can implemented as follows:
- We create all the users to the users table (General/User administration)
- Activate the “Save key” and guide the users to type in the key (which must be unique, because through this, the identification of the user will be done, whereas the login password just used to authorize the user entrance to the system and it can be anything).
In the document series in which this functionality is required, all we need to do is activate the relevant field:
The result will be that in every attempt to store the document, in the document types where we activated this setting, the mandatory typing of the “Save key” will be enforced. This way, the user typing the password will be identified and authenticated so, instead of the login user, the user to which this password belongs is used as the document “creator”, during saving process. Later this information can be used in views, for example in “Retail Documents” list, which contains such a filter (“created by…”).
Retail posting process
The purpose of this procedure is the packing of the detailed Retail receipts into summarizing documents for posting to General Ledger.
Appropriate document types: RSR (Summary note for the effected Retail sales)
RCS (Summary Credit note of Retail sales)
The procedure groups the retail receipts (RCR, RSC) by date, branch, VAT status, and cancellation status. Furthermore, there is the possibility to define grouping by trade account, document series and grouping of the payment lines per Liquidity account (e.g. for cases that in Chart of Accounts monitored the credit cards by Bank). A scheduling utility is also available so that the process to run completely automated every certain period of time, for example daily or weekly.
The documents produced contain a SINGLE item line per “Accounting category” and “VAT category” (instead of the actual sold items). The reason is that the ONLY updating concerns the Accounting (which never may be updated by RCR, RSC even if a posting process runs, by mistake).
The procedure updates the “reasoning” of every produced document with the limits of the issued retail receipts (in the form “Numbers of receipts RSR -Α-00001 up to RSR -Α-00105” etc.). In case there are any cancelled receipts, they are grouped and cancelled automatically producing one cancellation document, listing the numbers of cancelled Retail receipts (separated by a comma). In the original Retail receipts, the “Alternative document“ field is updated with the number of the Summarized Document (RSR -ΧΧΧΧ) where they participated, and they are “locked” so that they will not be able to take part in this procedure again.
The trade account of the produced Summarizing Document is the one declared in the Branch (“retail customer”) or in the document type (used, when no grouping by trade account has been chosen).
The series choice of the produced document is done automatically: either by the unique branch series or based on the same series code with the grouped retail documents (source documents).
- If a grouping by series has been chosen, for every Retail document series a corresponding one must exist (with the same code) in the summarizing Retail document type.
- If no grouping has been set, the summarizing Retail document type will have to contain the definition of ONLY ONE series per branch (1 normal and 1 cancelling) which will be automatically traced.
If any error occurs, the Summarizing Documents can be deleted and the process can be executed again using “NO” in the question: “Exempt the processed”
Opening (cash receiving)
In the beginning, the user counts the cash received of the current cash register (issued through “Cash/Notes/Money transfer).
Appropriate document type: CCN (Cash counting entry)
In this form, the current balance of every Liquidity Account – Cashier (in its own currency) is available (as it is calculated of all system transactions). If there is a difference between this balance and the counted amount (surplus or deficit), it is calculated to the last column, using color indications for the “sign” of difference.
Being in the “Counting” column, we can use the “Coins counting” button to easily enter and sort all of the quantities of the different types of notes and coins. Based on these quantities, the counted amount is calculated and pressing “Accept” the main display will be updated.
Until the storing of the current document, the cashier would remain closed and inactive, to avoid mistakes during the counting process.
Closing (cash delivering)
During the closing and delivering the cashier from one user to the next, a counting is taking place again. The procedure should always be done and the handling is exactly the same as in the opening of the register.
Until the storing of the document, the register should remain closed and no transactions should take place in it.
Following those simple steps, we can solidify the fact that during any shift (while the register is accessed by one user in a specific time frame), the full history of the receiving’s as well as the source (day, time and user) of any differences.
Cashier deficits and surpluses
Through every counting document, the updating of possible deficits or surpluses is available by the use of the first button on the bottom left “closing of cash counting differences”. The best practice in this case is to run this process immediately or at least before the next counting takes place for that particular cashier.
This action will call the transition:
202. CCN=>CCD (Cash deficits-surpluses from counting)
This transition will produce the document:
CCD (Cash differences)
In every Liquidity Account which shows a counting difference, a corrective entry is entered which will balance the account.
The posting of this document will use the G/L Account entered in document’s header,
The path: Business snapshot/Sales statistics/Branches statistics leads us to a number of relevant views on the branch activity.
Stores’ sales statistics (online)
This view contains sales and receipts data by branch. It is configured to be able to self “refresh” every 10 minutes, making it useful for someone to keep an eye out from a central site, on the actual activity of each branch in real time. The proposed time period is current day. It presents the Net and the Gross (net + VAT) sales value, as well as the actual cash receipts, with a constant display of the time passed from the last receiving and the last sale.
Sales per Store by hour
This cube addresses mostly to installations having a large number of sales throughout the whole day and need to have a solid view on the data about the turnover and quantities sold by hour. Some additional dimensions like the salesperson, item grouping, geographic region, year, month day and business unit, are also available.
Average transaction value per store by hour
This cube addresses to installations of a large number of sales during the course of the day, in cases of intensive retail and contains information on the:
Total number of transactions per hour (without cancelled or cancelling documents)
The total net turnover per hour
The average value per transaction (taking into account only the “positive” transactions, without credit notes)
There are some additional columns too, to move to the visible ones from the “data” list of the cube:
Positive transactions value: Displays the value of transactions without taking into account the cancelled and the credit documents
Number of positive transactions: Just like before, it takes into account only positive transactions. It is used to form the “Average value per transaction” indicator.
Dependency of sales by weather conditions
This cube displays the sales value and quantity in relation to the weather conditions in each store at the time the sale was made.
- A periodical update of the weather conditions in every branch can be scheduled by using the «Update METEO data» (Tools/System- Database management). The weather is coded in 5 values (Fine, Rainy, Snowfalls, Erratic, Very warm), which are “dimension values” for the cube. The requirement for this procedure to function correctly is to first run the “Update Postal codes file” (Tools/Maintenance tasks) so that, the unique key used of every area to be updated properly.
Visits per store over time
This printout provides us with information about the way the visiting is progressing through the hours of the day per month and year. The printout displays the summarized result for all the recording cameras of the company, and then, in more analytic levels for every store in particular.
This printout connects sales data (value and number of transactions) to the number of visits, as recorded by the visit recording cameras installed. Grouping the results is possible to do by year, month, day, store and geographical region, in order to get valuable conclusions on the store traffic.
- In order to acquire this type of information, the proper equipment recording the visits is necessary to be installed and the relevant customization of the application should be done.
Stores’ audit view
Displays in a “Dashboard” way, information on the sales related to the stores and also the company as a whole:
Total turnover, Turnover per salesperson , Top selling items
Stores’ sales in the current week, month, and quarter compared to the corresponding previous year range.
Average transaction value average number of items per receipt
Sales value compared to the stock value
The documents used for the cases of Services provision are available through the Sales options (of menu and toolbar).
Services rendered Invoice
Appropriate document type: SSI (Invoice - Services provision)
Services rendered Receipt
Appropriate document type: SSD (Receipt for a retail sale - Services provision)
Issued in cases of Customers - Physical Persons instead of a services Invoice.
The difference is that the proposed selling price is the “retail price”. A payment can be entered at the same time.
Various revenues (interests etc)
Appropriate document type: BXR (Various revenues Note (with payment))
Used like the services invoice or receipt, for small expenses that paid at the same time. The customer is not updated, so, the payment must be entered anyway.
Service repair Invoice – Items’ shipping with no charge
This document used after repairing Items that have been received from the customer through a “Goods receipt Note – without value” (GRN), that is a pure quantitative document (without an invoice pending. After checking or repairing, the Item returned to the customer while charging for the work done.
Appropriate document type: SIQ (Delivery Note – Services provision)
The Items sub-page of this document has got a ZERO value and the update of the Inventory is only regarding the quantity, like exactly we would entered a SPC (Goods Return Note (without pending Credit Note)) document. The Services sub-page will be acting just like the SSI (Invoice - Services provision) document. The total amount charged to the customer is the value of the services.
Service credit Invoice
It is issued when a mistake has been made and the Invoice cannot be cancelled.
Appropriate document types: SCS (Credit note - Services provision)
SSC (Credit note - Services provision (reversal))
Retail service credit Note
Appropriate document types: SCP (Credit note for a retail sale - Services provision)
SCR (Credit note for a retail sale - Services provision (reversal))
All of the Service documents can accept a payment or money refund. The handling of those monetary transactions is exactly the same with the one used in the Cash invoices.
How we check the results of issuing Services provision documents?
||Sales/Shipments||List of all Sales documents concerning quantities or values|
||Invoicing documents||A list of the documents creating Turnover.|
||Services Trial Balance & Transactions Register||
||Revenues Journal per VAT rate||
||Customer’s statement and Trial Balance||The customers are charged by Services Invoices and we can check their balance through Trial Balances and their detail transactions through Statements.|
||Accounting||An accounting entry is created to the Customers, Services and VAT accounts and it updates the Accounting journals, the Account Statements, the Trial Balances etc.|
This chapter will examine the process of receiving the claims from customers in different ways (cash, credit card, cheques, deposits), as well as the organizing and scheduling of the receivables.
The instructions and examples given are mostly based on the proposed customization, as far as the documents, the screen forms and the informative tools are concerned.
In order to issue a Receipt, the following procedures can be used:
Appropriate document type: CRC Cash receipt (from customers)
|Document Type and Series||
How we check the results of issuing Cash Receipts?
||Receipts||A list of the collection documents entered, along with a classification of the amount in Cash/Deposits, Credit Cards and Cheques/Notes. The list contains receipts not only from documents like the above, but also from Retail Sales or advance payments through Sale orders etc.|
||Cash check statement||
A list of receipts and payments sorted by branch, user and payment type:
||Receipts-Payments||Information like the previous, but providing the layout and the analysis functionality of the cubes.|
||Accounts Receivable Trial Balance||The receipts are displayed in the Credit columns of the Trial Balances and the corresponding Detail Ledger Statements.|
Within a Sales Invoice, it is possible to declare the customer’s payment without create a separate Receipt document. There are two ways to declare the payment in an invoice:
- Choosing the payment method “Cash” and asking “Apply” (): a payment line will be produced (for the total payable amount). If this payment method is set as “auto-apply” then, during storing of the document, the payment will be produced (and update the proper sub-ledgers) without any user’s action. The selection of the payment method is enough in this case.
- The user fills out the payment data. If the payment method is null or it is NOT an “auto-apply” payment method, the user can maximize () the footer area and fill out the cash register and the amount manually. If the Cash (liquidity) account of the current Branch has been set as an “automatic payment” account, it will be automatically proposed, and the user would only enter the payment amount.
Possible cancellation of the Invoice will also cancel the payment.
Collecting by credit card
For using credit card for payments, the necessary customization of the Liquidity accounts must have been done. As far as the payment takes place during the issuing of a retail receipt, there is specific information available in the corresponding chapter. In case that the payment issued by using a separate receipt, the recommended document is:
Appropriate document type: CRC Cash receipt (from customers)
Having customized properly the payment methods (to be applicable to the collection receipts), in the appearing dialog, we select a payment method that contains “credit card line”, we define the amount and the number of installments and press the “Accept” button:
Customer deposit in our bank account
The deposit made by a customer in one of our bank accounts can take place in the exact same way as the cash collection (using the CRC document), filling out our bank account in the “Liquidity Account” column.
This can be useful in cases where we receive a deposit receipt by the customer and we need to immediately update his balance.
In case “Valeur Days” have been set to the account, they will be added to the Issue Date of the Document for calculate of the payment “due date” which will in turn update the cash flow (this is the date when the cash will be available).
Usually the customer deposits entered in mass, based on the Bank’s statement, which may scheduled to take place daily or in any periodical basis. In this case, either manually or via a pre-configured import procedure, we enter one document for many customers’ deposits:
Appropriate document type: BCR (Remittances from Customers)
In the header, we declare:
- The bank account
- In the alternative document, the Bank’s statement number
In the lines
- The customers, along with each deposited amount
There are two methods available for the outstanding balance to be correctly updated as well as the cash flow which is depending on the “Due date” (Valeur):
- For EACH DAY the statement displays transactions, we enter ONE document. If there are “valeur days” declared to the bank account, they will be added to the issuing date, producing the “Due date” on which the money will be available in our account.
- We enter ONE document in which the issuing date is the date that we received the bank’s statement and for each line, we enter the due date (valeur) which is stated. From an accounting point of view (trial balances, transactions statements), in this case the Ledgers will be updated by the “Issue date” (on which we enter the document), the matching of our customers though, their Pay-out ratios as well as the Cash Flow will be correctly updated by the “Due date”.
Collecting by a customer’s cheque
Appropriate document type: NRE (Note receipt from customer)
To take receivable cheques (or other receivable notes like sights drafts, day bills, trade bills, etc.) from a customer, we can use the document type CRC (which covers all payment methods) from the sub-page “Notes” either this special document:
For the cheque details to become available for filling in, we must use the icon for insert a new line , which will activate a dialog allowing the full cheque details to be entered. The required fields are the following: