I have been experiencing the use of a vast variety of accounting and ERP solution for the past 8 years of my working career, and I felt there are huge flaw in some, if not most of the solution available during that particular period of time..and.. it sort of prompted me to develop a version, that has all the flaws eroded, and to improvise on some of the defects.
I do not wish to condemn or criticise, but what I could tell is, there are no such thing as one perfect solution that fits all users requirement. There bound to be some limitation or weaknesses in every form of solution, we can only reduce some of these, by fine-tuning or compromising on some elements in exchange of something better in return.
It was not my initial plan to develop and to commercialize DES accounting software, although, it took a lot of my personal leisure time and a great amount of effort to fully complete DES accounting software. It started five years ago, when I was working with some of the accounts staff in an IT firm, and during that period, I was generating a list of customer statement, and my curious thought was, how does the computer know the age of each of the customers account? and how would the system compute and come out with those profit and loss statement, and those trial balance? It is all this impending thoughts that drives my mind to actually think, and find out how does all this pieces of clues comes together and work around like a complete jigsaw puzzle. I was determined to go further, and begun doing some research on database design, communicating and getting feedback from online forum and my understanding grew as I begin to go deeper in my research. It came a point in time, where I actually hit a brick wall, while I was designing the architecture of DES accounting software, but it all went well, after pausing and given some thoughts to it.
Well, as you know, cloud-computing and software as a service, or subscription base model was not popular at that point of time. Every system seems to run on windows platform, and I thought, it would be technically compatible to use visual basic as a basic user interface, connecting to sql server as its storage back-end.
Well, that is the whole objective in mind, on the outlook itself, you can tell, how and where to navigate your mouse to reach your goal. Let me explain, if I were to look for a button to set-up my customer account, there is already a command button labeled, Setup under the Accounts Receivable screen. If I want to print some customer-related report, there is a button labelled Report, that contains a bundle of reports for you to choose from. I decided to do away with the conventional menu bar, which sometime brings confusion to user in finding the right button.
If I were to choose one, it has to be on the sales return mechanism. When I went through the costing mechanism design for the inventory module, I thought it must be the most challenging work to go through, but, I was wrong. The workaround on the GL interface, for a sales return entry is the toughest of all. The coding work on the server-side for the costing mechanism for the inventory costing method, is only half way complete of the sales return cycle. You have to figure out how would the system keep track of which sales invoice, which unit and at what unit cost and selling price, should the system take and reverse, when a user perform a sales return for a particular customer. Not to mention, the GL interface and the complexity of incorporating foreign currency features in the design.
There are some solution provider that claim such statement, but the genuine truth of the word Integrated, is one entry, one result across all platform. There are some package that says it is integrated, but you will find your cash out balanced, if you forget to post a batch for the cash clearing account. For example, the cash and GL module is bundled from different vendor, and in order to cross your cash entry into your GL module, it has to link to a suspense, temporary or I preferred to called it a clearing account. If you forget to post any of these clearing entry, in a batch system, for instance, you will find differing figures for your cash balance printed from your cash module vendor.
I have tried to achieve a smaller bytes for DES accounting software, particularly one that needs to be deployed remotely online. Some of the ways to squeeze some bytes, is by adopting the thin- client/fat- server model, incorporating fewer object files and cutting out unnecessary image files. If you have smaller size, you will consume less disk space at desktop level, and rely on your server processing speed for greater work efficiency.
As I have mentioned in the FAQ section, current version is only suitable to small trading company. If you are from a manufacturing company, you may still use DES accounting software, but you won't be provided with any manufacturing modules.
No. The system is designed as such, there would be no time limit, in terms of transactional posting to any particular period. You can close your book at any point of time, and still get your financial information out in real-time.
It has the basic function for collection and payment, but, what I have done in DES accounting software, is to cut short one of the manual process. Example, if you received a payment from a customer, you would normally start off by entering a receipt for the amount collected, and later proceed to match the received amount against the invoiced amount. In DES accounting software, you would only need to go through the first phase, and your collection is already matched against your invoiced amount, once you have posted the collection amount.
I do not support the use of control account. It would only serve you the benefits if you are keeping a manual book-keeping entry. In the traditional method of book-keeping, a book-keeper would create a sub-ledger account for each customer, and later transfer all the sub-ledgers' balance to a debtor control account, and would prepare a trial balance. In a nutshell, you are merely summarizing your debtors account into one single total. Now, this could also be done, in a computerized system, however, you would have additional reconciliation work, just to ensure your total sub-ledger account coincide with your debtor control account. Well if you directly link all your debtors entry to GL, you could do away with the account reconciliation.
As you may know, asset management basically covers asset purchase, disposal and depreciation. This is only the surface of asset management. If I were to do an impairment review or an asset revaluation, can this be done in a computerized manner? Of course, these are not daily operation activity of a company, but can we be sure that the asset employed, would not be subjected to impairment or revaluation in years to come. In the event of such occurrence, can we rely on our system to perform such activity? So, I wouldn't want to expose such vulnerability to users, and would generally encourage user to either employ excel or other simpler format to keep track of the assets in details, and later book the asset depreciation amount as one journal entry posting in the Journal Entry screen.
These are features that allows a user to perform a periodic translation of its accounts receivable and payables, denominated in foreign currency. I say periodic, because, you have a choice to translate your AR/AP balance at month end or at year-end closing. In accounting practice, we are required to reassess the value of our existing AR / AP balance which are denominated in foreign currency, at the close of each financial year-end. If I'm operating in US, and transacted with a UK customer, at the end of the year, if there are still outstanding debts from my UK customer, the value of the debts would have fluctuated, and that is why, I need to revalue the value of my UK debt, based on the closing rate existing at that point of time. If you have an upward translation, giving you a rise in your debt value, you would recognise the extra value as unrealised gain, and if it is a downward translation, you would recognise an unrealised loss in your profit/(loss) statement. Now, click on FOREX Translation, select a closing month of your choice, and the system will compute and show you a preview of the unrealised gain/(loss). When we reach the end of the next financial year, we would generally reverse our previous unrealised gain/(loss) using the FOREX Reversal feature and repeat the year-end translation cycle again.
If we are talking about cash settlement, you would need to specify the rate at which you have agreed with your bankers on your customer's remittance, and you would see a realised gain or loss being reflected in your profit/(loss) statement. Now, in business, there are other form of settlement other than cash basis, and if I also carry an outstanding debts owing to my customer, I would prefer to contra my debt owing to my customer against my customer's outstanding debts, as such I would have to determine an equitable rate of settlement, of which my customer agrees, and on such arrangement, it would also give rise to realised gain or loss.
Ok. When I mentioned this, I am actually implying two layer of control, the first layer is at the user interface, and the second control is triggered from the first one. To give you a simple illustration, let us take an example of a goods received note transaction. If you leave every input box emptied or unpopulated, try clicking the post button, and observe the error message triggered. The first layer of control are basically enforcing the rules of business processes, say, you need to assign a purchase order, a user, date of your goods arrival and foreign exchange rate, if your are dealing with foreign supplier. Presuming you have successfully populated all mandatory input fields, and if you have passed through the first control layer, you would triggered the next layer of control. The second layer of control would verify that, the passing input data is a non duplicate data (purchase order no) and the system would execute and send a posting number, if the user has passed both validation concurrently.
Well, what I think most user would found this useful, is when there are situation where you need to readjust the value of your inventory, for instance, a physical stock-count, that would sometime yield a different number of quantity, a revaluation of your stock item unit cost, as accorded by the accounting measurement principle of lower of cost or net realisable value (NRV). A stock loss for an example, would also allows you to transfer out your loss to your profit/(loss) statement.
I have to say that, in a general public perspective, given an inflationary environment, which is the norm for most businesses, LIFO method is likely to understate your profit. LIFO is permitted in US but is unacceptable under IAS 2 and SSAP 9. Tax authorities also do not allow LIFO.
Well, I hope I don't jump to any technical jargon, here, while we are discussing this. I would break my research into few layers, first, the technical design, second, the scripting, and third, integration. If you are keen to find out more on database design, get some book written by Thearon Willis and Robert Vieira. These authors is full of technical knowledge, and you will probably understand more if you cover most of the chapters. As for the scripting side, I will shorlist books coverred by Joe Celko, Ben Forta and Robert Vieira. You really need to grasp the concept if you want to master your query skill. As for the integration research, you will probably need to find out more on the flow of business processes, the business practises in general, and the accounting principles in a generally accepted accounting practises (GAAP) in the global industry. You will probably need to find out more on certain topics which are hardly found in technical books, either through the internet, forums, or other sources.
Both. If you are a business start-up, it is even easier, in terms of system configuration and account set-up. All that you need is to define your chart of account, assign your sub-ledger code, and you are ready to run. If you are running an existing system, then, you will need to follow the step-by-step procedures (Question : I am currently using another accounting system, how do I migrate my current accounting information into DES accounting software?) as I have mentioned in the FAQ section in the website.
If you asked the same question to a fair number of vendor, I bet 90% of them would say, "You need not know double entry or accounting skill, system will take care for you", right? Wrong. Holding a licence, does not mean you can drive safely on the road. Your wheel is your basic accounting skill, without it, you will lost in direction. I definitelly encourage user to equip themselves with some basic accounting knowledge, before they even begin to set-up their chart of account, even more so, to those who are from non-accounting background. You will also need to understand the nature of your business, the type of reports you would need to generate, your country tax regulation and its accepted accounting practices. All of these I have mentioned, can only be answered by the user themselves.
If you google the word ERP, you would find out more details on this word. My understanding of ERP, can be quite simple. The word resource, implies to your financial resources, human resources, production resources, supplier resources, your sales and marketing resources and so forth. The word Planning means, how would an enterprise, group and align all these resources as one stream of components, that are able to work in sync in providing better information and results to one another. This will normally entails a change in organisational working pattern and reporting structure, in order to drive these stream of resources. Thus, an organisation that runs an ERP system would generally have better internal control and business processes in place, as the system will fails if one of its channel of resources breaks down. DES accounting software is not an ERP, it is a modular accounting application, that facilitates and automate some of the accountant's job. I would associate DES accounting software as a free accounting software, a free small business software, free billing software, free database software, free stock software and as a free inventory software, but not an ERP.
I would not discount such possibility. The traditional licensing and service model would gradually fade, and replaced by the subscription based model. The new model offers greater scalability and flexibility in terms of hardware storage, processing speed and investment cost. If you can subscribe to a usage of a software, as a service, with a small sum of fee, wouldn't it be more economical and efficient, than to invest in hardware, software and human resources. I predict, in short period of time, you would see a significant shift to subscription model, with vendors either providing software as a services on premise or on the cloud.
It is a matter of choice. The only drawbacks of SaaS, is in terms of data security and internet connection speed. Adopting this new model would literally means giving all your corporate confidential data to a third party and indirectly granting free access to your corporate database, the possibility of data abuse is higher. You would also be frustrated if your local connection is slow in processing and frequently down at times. Now, there is still room for desktop application to thrive in these area, if data security and connection speed is your top priority.
Well, standard if you incorporate the principle of accounting in your modules. I have encounterred other system, that allows you to bill customer with a negative inventory, a billing issued without a delivery order number or purchase order number. Such features extends user flexibility, at the expense of proper accounting treatment. In DES accounting software, every delivery order must be triggered by a customer's purchase order, and every invoice is substantiated with a delivery order number. The customer's purchase order serves as a common identifier, that will eventually facilitates in your monthly reconciliation, and to better identify any inventory that has been deliverred but not invoiced to customer. Likewise, in our inventory purchase, to enforce the accrual concept, there is the payable account that captures your goods that has been received, but pending invoicing from your supplier. In your inventory costing, there is the first-in-first-out (FIFO) and Average (AVEG) costing mechanism to choose from. We also incorporated the standard treatment for foreign currency translation in the accounts receivable and payables.
I would not say that DES accounting software, is the perfect software solution. I am sure there are plenty of room for improvement, limitation that may have not been discovered, as we speak, but the advantage of using DES accounting software, lies on its robust and scalable architectures design. The last thing that you want to do, is to confuse user with a bundle of features, that they would probably would not use. The interface is designed with a simple look, the features are categorised for easy navigation, the screen for all modules are basically the same, the installation guideline is simplified and a set of tutorial is provided online.
All the above three costing methodologies relates to Manufacturing environment. Unfortunately, the current system does not have the features, functionalities to these three elements. Nevertheless, I always inform our interested developer or user to customize their existing job-costing or production information system to interface with DES accounting software. In a much simpler approach, they may continue to use their existing tools or simply use a spreadsheet to record their production costing in a standard template and they can then advise their Accountant to perform the journal entries to reflect the movement of their inventory cost from Raw Material Inventory to Work-In-Process Inventory to Finished Goods Inventory. These 3 Inventories would then be reflected as a closing balance in the Balance Sheet at end of a period, and of course, you need to ensure your Direct Labour and Manufacturing Overheads Accounts are zerorized at the close of each period, as the accumulated cost in these accounts need to be charged out into your Work-In-Process Inventory Account. On your Income Statement, you will only see the Cost of Goods Sold derived from your Finished Goods Inventory Account at the end of a period. Oh! Yes, and you will also need to expense off your under or over absorption of your Manufacturing Overheads, at the end of a period. These variances are generally charge out to your three Inventory Accounts or in COGS Account. I know these would sound confusing, but let me explain from a top down illustration. In a typical manufacturing environment, cost is accumulated progressively from the purchase cost of your initial raw material up to the final production stage in producing finished goods. As you start to record your raw material cost in your current period, you will also add in the balance brought forward from previous period. Thus, you will have the total raw material cost available for production, next you would then determine your closing balance at the end of the period and deduct it from your total raw material cost available for production to derive the total raw material consumed in the production (WIP). Thus in a nutshell, you are using the general formula of [Opening Stock + Current Period Purchase – Closing Stock = COGS] a typical merchandise or trading company in determining the consumption value of your production. This formula applies similarly in deriving the cost of goods manufactured under the Work-In-Process (WIP) Account and the Cost of Goods Sold under the Finished Goods Account. The only differences in a WIP Account, is you would also add in the additional cost incurred in current period for Labour and Manufacturing Overheads.
Well, in my personal opinion, an ERP would integrate the whole supply chain elements in a manufacturing industry into a centralised system. These modular components that make up the whole supply chain is generally consist of individual department or functions that make up an Organisation Structure. It would basically include modular functions for Human Resource (HR), Production, Procurement and Logistic. I believe these are the main functions that are not included in our current DES version. These modules which I have mentioned, is also made up of two or more sub-module, which would provide different functions and support in itself. Example, in a HR module, you can generally cascade to several functions that may include payroll, timesheet, claims, appraisal, attendance and employee profiling. In a Production module, I would say this is the main component that differentiate an ERP to a bookkeeping or accounting software. In a Production environment, you would need to cover numerous activities that a typical manufacturing environment would have in their various functions like, material requisition, production planning or scheduling, wastage and quality controlling, with the integrated accounting entries for raw material, work-in-process and finished goods inventory movement. In order to manufacture a complete finished product, the first requirement is to procure and tabulate the material (bill of materials) that makes up the final product. This is facilitated by a material requisition planning (MRP) module. Once the type, quantity and cost of the material is determined, the production worker would start its production planning to schedule, plan, monitor and control the timing and volume of each production floor in a plant, hence the application of process costing methodology arises here. As the materials are fed from each stage of production, a standard costing approach is generally applied in charging out manufacturing overheads, which are non-department specific, for example, your machinery fuel consumption, rental of production floor, depreciation of machineries and the production supervisor’s compensation cost. These overheads can also be measured against actual overhead incurred, and allow production to be recalibrated for future production in a more cost effective and time efficient manner.
I remember, one of my reader wrote to me personally with this same question. I would say that the double entries of these two inventory system differs in terms of accounting treatment and reporting format. The periodic system generally has one posting entry to be made at year-end, which typically reflects the booking of a closing inventory value, derived from a financial year end stock count. The double entries are to debit the balance sheet’s closing stock and crediting out from the income statement’s closing stock. Some system generally provides a simple interface for user to book in the value of each month Closing stock value without the need to perform this journal entry, keeping the financial reports updated simultaneously. On a year-end closing Process, the closing stock at balance sheet would then be transferred (credited) out and then becomes the Opening Stock (debited) in the next financial period appearing under the income statement’s cost of goods sold header. On a perpetual inventory environment, the inventory movement are basically reflected in and out between the cost of goods sold and the inventory account itself. These provides a much simpler interface and easier understanding of the income statement as the cost of sales of each product and services can be determined and analyzed separately against revenue. There is no need to perform any journal entry for closing stock, as the inventory balance is updated concurrently with the procurement and sales transaction. I think in a manufacturing industry, a perpetual inventory system can only thrive in a fast paced production environment.
Moving forward, I am looking at moving DES accounting software to web-based platform, basically employing the use of open-source technology, and it would probably take me some time before I can release my first beta version.