Accounting deployment and maintenance principles for ERP-system based on 1С

Publications: Accounting deployment and maintenance principles for ERP-system based on 1С
Considerations on the technique of accounting deployment and maintenance based on the 1С systems in the form of short principles, explanations and illustrations for them in the form of examples and conclusions. Refers mainly to the business accounting, however, applies to any industry and, as it seems to me, not necessarily to 1С. The purpose of writing this article was to present the practically available information, rather than to fill up the theory, in spite of the resulting volume. The article is intended for the deployment specialists, contains, in addition to the technical information, the accounting and taxes.


  1. Payback principle
  2. Trust principle
  3. Principle of business scheme availability
  4. Advanced IBM principle for automated accounting
  5. Closing principle
  6. Principle of standard functionality preservation
  7. Principle of methodical correctness


I do 1С deployment since 2004. Mainly I had to be engaged in the business accounting or near-accounting tasks in the management accounts as well as directly in the management accounts in a variety of forms.
During my activities, I had to deal with a variety of projects — form simplest projects to the complex projects with distributed base and double (management and business) accounting, with automatic generation of business transactions, complete development and deployment of the tax accounting scheme according to the RAS18/02 in absolutely non-standard business configuration, etc.
In a number of cases, coming to the client with already installed but operating incorrectly accounting, it was enough to look thoughtful at what is happening in the accounting and to put a few accurately adjusted «screw key hits», after which everything started to work properly…
There were several unsuccessful deployments that are ashamed to remember, but though they gave their own unforgettably valuable experience.
Given this experience, I have formulated certain principles of accounting which I would like to share with respected community. Sometimes, setting the accounting subject to these principles allowed me to solve the complex tasks with minimal man-hours, obtaining the solutions that have worked for years with no problems and ensure satisfaction and recommendations of clients.
In addition, all the successful deployments that I saw showed observance of these principles in the analysis. At the same time, their breach always leads to the deployment (or maintenance) problems, and vice versa – the analysis of unsuccessful projects always detected a breach of any principle.
Of course, an observance of these principles by itself is not the only sufficient condition of deployment success — an extremely important thing is a proper organization, adequate IT-infrastructure, and more. In general, the criteria of success are different in all situations.
Under the criteria of deployment success (deployment, not a project as a whole) I mean:

  • client satisfaction of deployment result;
  • absence of permanent flow of problems incriminated to the implementer (and, of course, required a free solution within «warranty»);
  • absence of unsolvable problems caused by the incorrect deployment;
  • preservation and enhancement of cooperation in the questions of maintaining the current tasks (update, prevention, technical audit);
  • recommendations for the potential clients and new employers (during the transition ob the client employees to another job).

I do not consider as a criterion a direct commercial benefit from the project and the timeliness of payment believing that these questions are successfully solved at the planning stage of relations, execution of contract or signing the documents.
This summary does not pretend to the ideality, reflects my personal, not a perfect view. Applicable, for the most part, for automation based on 1С of exactly business accounting, but is quite adaptive for the other sections, and the examples I cited different.

1. Payback principle

I think this is the main principle according to which it is possible to evaluate the deployment or maintenance success: Automation must cover itself in any way.
a) Permanently bring the direct and indirect proceeds.
For example, to increase the passability of continuous stream of customers by reducing the time of closure of the deals. To help in minimization of accounts receivable by simplifying the work of managers responsible for collecting payments. To contribute to a better and faster satisfaction of customer demand for their attraction by the service quality.
b) Save the costs, and at a greater sum than it was spent for the deployment.
In order to contribute to the reduction of associated capital (for example, to minimize the warehouse remains by effective planning and goods distribution). To save the resources of users allowing them to solve a larger or at least possible number of tasks for the same rate of time or removing from their shoulders the complex computational tasks. To contribute to the minimization of risks for the tax penalties (using the timeliness preparation and presentation of all the necessary reporting by the accountant)
c) Ensure the existence of business process which compensates an automation.
For example, to ensure a fast and convenient accounting of the tasks and operating time of 1С implementer specialist (or franchise company). Without this accounting his activity is impossible, because all the time constraints will be disrupted, all the tasks will be forgotten, all the incomes will be lost and this «paper» accounting in any case will be inclined sabotaged because of large time-consuming and impracticality.
In addition, automation payback is present both at the corporate level and at the level of individual users from the customer side.
Automation should not be done for the sake of technologies, because in the absence of clear targets and understanding of corporate and individual benefit, the project can be sabotaged at the executor or customer level.
In this regard, it will be useful for the implementer specialist to carry out with the customer representatives an explanatory work during which the concrete benefits will be explained for them that will appear for each of them, as well as to schedule an automation so that each person did obtain the benefits, the work simplified, the lights went on in a hard working life.

2. Trust principle

Automated accounting must be either trusted and used or immediately calculate on paper and do not in front of someone that we have an automation.
On of the main problems faced by the client: accounting distrust. Let’s imagine a situation: an automated accounting system is deployed on the enterprise. A group of users work in this system. Each of users has a large ledger where he keeps his own paper and then enters the operational data in the computer and compares a synthetic between computer and paper accounting ensuring the compliance.
As a result, the users do the double work, they do not have time to re-check the results, they make the arithmetic errors and later search them heroically. As consequence, the time-frame is disrupted, they complain about the life, program and their evil destiny. The system, as a result, display false data or the data with damages that do not allow using them in the higher sections (for example, incorrect conduction in the “Enterprise accounting” of the VAT of advances completely discredits an idea of VAT automated accounting and compiling the sales and purchases books, and the Vat of advances, in turn, depends on the reflection correctness of mutual payments with customers and suppliers).
It may happen also that the users begin to check data of quite obvious reports and aggregations manually, on the calculator (that is, however, is described more in detail in principle №4).
This state can be characterized as automated accounting distrust.
This behavior of users and, as consequence, the accounting distrust, can be caused by the following reasons:

  • the user is not trained enough, does not own the system in terms of his accounting areas – operationally and/or methodically;
  • the user is conservative, does not trust “these new technologies, damn it”, prefer his “proven and reliable” methods deliberately sabotaging automation;
  • it is not convenient for the user to use the system – some operations must be objectively calculated on paper, because the system capabilities do not correspond to the real accounting process (usually for non-standards sections or accounting features on the enterprise);
  • the system is frankly working incorrectly (that happens not only in the ordered, but also in the typical behavior)

The main consequences of accounting distrust are:

  • absence of relevant and valid data in the accounting system, because the efforts of the users are focused not to ensure their validity, but to provide the doubling trustworthy accounting;
  • ineffective work of users, failure of reporting deadlines, dissatisfaction of automation at the user level, sabotage;
  • delaying the deployment time constraints, overrun of the resources of specialists and inability to go to the next projects;
  • inability to automate the individual accounting sections that depend on the lower sections;
  • dissatisfaction of client leaders by the automation results, problems with paying the jobs.

To provide the accounting trust, it is required to eliminate the listed above reasons by any available means: carry out the training, make the work of users in the system advantageous, bring to the attention of decision-makers the situation related to the sabotage, provide the users with convenient mechanisms for non-standard accounting sections.
Also, it is required to develop an ordered functionality without the errors and monitor the problems of standard functionality operation in order to protect the users from the cases when the system really operates incorrectly.

3. Principle of business scheme availability

If the user does no have a business scheme — no automation can save him.
Under the business scheme it is meant a scheme of interaction of its component parts, established traditions of accounting, understanding the business processes at the enterprise, knowledge how to properly reflect the business transactions in front of the law and founders.
Here, for the right illustration of this principle, I will have to go into a long and common example from practice (in addition to the technical information there will be the business accounting and taxes)
In my practice I met the complex cases of business accounting automation of single holdings that includes several interactively operational legal entities and entrepreneurs. For example, when in the trading business there the following business entities:

  • LLC that applies a general taxation system (GTS) and trades wholesale with VAT;
  • LLC or IE with STS 15% that sales the goods for the state employees and other clients who do not require the incoming VAT;
  • Individual entrepreneur (IE) who applies a unified tax on imputed income (UTII) and sells at retail.

The goods in the holding are the same, the management records of the goods (usually, based on the configuration «Commerce and warehouse » or «Commerce management ») is performed according to the common warehouse, mutual payments and cash flows – separated by the business entities.
In general, all these cases were divided into the cases when the holding had a clear scheme of work and when it did not have it.
The most common and serious problem of such interaction example of business entities is a distribution of the goods between the entities.
In case of scheme presence, the goods were usually predictably bought for the distributing organization, with correctly and legally designed marketing politics of dealer network (in order to avoid the violations of articles 20 and 40 of the Tax Code of Russian Federation). This organization was selling the goods for other business entities as needed. These entities wee selling the goods for the end customers (the managers chose the sales entity subject to the client needs and payment form). All free balance was concentrated on the distributing organization, the distribution of goods, — a question of pure arithmetic — was performed once a month, automatically, using a special written processors. The accounting department dumped the prepared documents of external and internal trade, negative balance was absent as a class (except the cases of operational re-sorting). From a managerial point of view, the goods were moving in one direction, the money — towards, an organization had an opportunity of absolutely legal optimizing maneuver over VAT and income tax, predictable financial planning.
Quite a different situation exists where there is no scheme. The goods are bought chaotically, for any business entity, according to the current availability of cash assets. Sold by the managers from any entity (how is it possible to refuse permanent buyer to buy goods wholesale when it is showcase?). Given a common warehouse, it is impossible to determine whether the goods were bought for the entity from which the sale is performed. Thereafter, when dumping the documents of product distribution in the accounting department, the entities that were with GTS and STS 15% (it is critical for them, in contrast to the IE with UTII) had a situation when the wrong goods were sold that were bought, but the ones that were bought were not sold.
Therefore, it was even considered a question of illegality of such activity and complete disorder of VAT taxation, financial planning, offset of debts, any automated accounting of expenses for the income taxation turned impossible, because the enterprise sold the missing goods.
In such situation, a view of the customer was quite naive about the fact that an automation can eliminate somehow the business problems. Usually, in such cases, it is possible to automate relatively not bad an operational trade and warehouse accounting by giving it the features of managerial one. It succeeded somehow to set the initial business accounting (by entering the leftovers according to the data of the last, hastily «drawn» by the accountant, inventory) and more or less effectively solve according to it the local tasks, provided that the accountant manages himself the «redness» of invoices.
In the described situation, the problems begin when the client demands to automate the distribution of the goods between the business entities that is impossible not because of poorly installed accounting (as sometimes client thinks), but because of the absence of legal (in terms of legal relationship and taxation) way to do that. Since, for example, it is impossible to give the goods overbought from IE to LLC that applies GTS – otherwise, en entrepreneur «loses» UTII in terms of this deal and is forced to keep the full separate records of GTS/UTII according to all the rules that discredits the entire entrepreneur idea with UTII.
I have not once seen a situation when a specialist took on this task and by the end could not solve it due to the absence of theoretical possibility of such solution. Or the task was solved somehow according to the customer outlines (with large time-consuming and costly), but later its solution did not help at all the customer who, based on that, tried to refuse to pay the work or distributed among the other clients unflattering recommendations.
In addition, the problems of the distribution of goods in this situation often absorb 90% of accountant time and nerves. He does not have time for accounting, the reporting time constraints are disrupted and all of t his often is motivated by the supposedly bad program.
The absence of scheme becomes apparent within the described above situation of goods distribution. For example, often the client has no suitable for automation the calculation scheme of product prime cost, and to deploy it, it is required to be significantly modified. Sometimes, automation detects the accounting problems that were used carefully disguised or solved with invalid simplifications.
Thus, when analyzing the project, it is required to pay attention well developed business scheme, to check how it is correlated with possible automation and in case if there are the mismatches, like listed above, it is required:
a) abandon this project at all;
b) point out the need to develop by the client the individual scheme items BEFORE automation and wait for completion of this development or for the paid time to assist in the development of these items (or hint at how these items should be properly organized);
c) separately and documentarily fix on the absence of implementer responsibility for the accounting section that corresponds to the non-developed business scheme item.
It is advisable in this case to provide an advance payment 🙂
Otherwise, it is possible to face a situation when the performed work will not be paid or the client’s dissatisfaction will produce the negative recommendations.
There is also a special type of cooperation, when you, in addition to the accounting automation, develop and deploy for the customer the business scheme. However, it should be kept in mind that this work should no be carried out for free, in addition, the developer may be responsible (in the legal field, but rather out of it), if there will be the problems with government agencies related to the use of your scheme by the customer.

4. Advanced IBM principle for automated accounting

IBM device is a phrase «Computer must be running, human — think». However, I have seen his phrase in the «Murphy’s» laws and other sources. I don’t know, honestly, from where it occurred. But every time, within my recollection, when this postulate was violated, the client in IT had a terrible mess.
Extend it for the automated accounting as follows:
«Human has to provide data, request the reports and performed analysis. Computer has to calculate everything».

A typical violation of this principle is a situation, when the accountant, making the implementations, tries to determine an overall sales sum for the period by displaying the journal of implementations and summing the columns «Sum» on the calculator, rather than to make a report «Account turnovers» or to display any other report. Also an alarming sign which warns about infringement of this principle is a frequent use by the accountants of the quite archaic verification method of direct enumeration and with the use of printed information on paper at that.
With a properly working principle, the users enter in the information base the primary documents, reflect other business transactions, and then, using the reports, verify over each accounting section a certain number of «checkpoints». Moreover, this verification, if possible, should be limited to a visual view and formal data analysis without frequent switching between different sources.
Of course, it is impossible sometimes to abandon from the use of direct data enumeration, but it must remain still a last resort applied practically only when verifying the correctness of system functionality operation.
The task of implementer specialist is to explain the user a methodologically correct order of accounting over the section and to bring to the notice the ways of quick and not time-consuming check of this section using the reports - «checkpoints». I will try to publish the individual articles and put the links here about the checkpoints of VAT, mutual payments and other sections. In addition, some information will be presented below.

5. Closing principle

The accounting scheme should be, if possible, closed on the maximum number of (implemented in the program and appropriate for the automation installation) sections.
The specified principle can be considered both at the technical and operation level.
At the technical level this principle applies not to the accounting on the accounting registers, but to the accounting on the accumulation registers (for example, to the tax accounting of VAT in any configuration, accounting of mutual payments in terms of orders and documents of payments (for CA / PEM), etc. It means that the remains of accumulation registers should not grow uncontrollably, «breaking away» from the considerable reality substance. Violation of this rule leads to the growth of information base, slowing its operation as well as causes the problems of accounting convolution.
The cases when the registers «scatter» in non-standard functionality we will leave on the conscience of the programmers of corresponding sections. Consider the following situation on the standard one.
For example, in the configuration «Commerce and warehouse 9.2» the tax records are kept for presented and accrued VAT: arrival and sales documents receipt the remains in the registers «PurchaseBook», «SalesBook», and the documents «Generation of book records…» - spend. In most accounting cases of considered configuration, nobody is interested in the tax accounting of VAT — it is performed in the accounting system. At the same time, the remains of mentioned above registers are constantly accumulated and transferred when closing the subsequent period creating the additional records in the information base.
In addition, when using the standard mechanism of information base convolution, the remains of these registers are displayed for the convolution date by separate documents «Record ob purchase book », «Records of sales book» for EACH initial purchase and sales document with preservation of the reference to this document! As a result, in convolution we receive all the initial documents of purchases and sales marked for deletion (or not extracting), for each of them a separate document «Book record…» and the same unclosed remains of purchase and sales books at the start of convolved accounting. In addition, the convolution itself (if not to modify it directing to ignore these registers) can be executed for several days.
In this case, the problem solution is elementary — to enter each month the documents «Generation of purchase book records» and «… sales …» and not to forget to re-conduct by restoring the corresponding sequences.
In addition, it is possible to disable at all the generation of records by the VAT tax accounting registers by commenting several lines in the global module. When I first did that, re-conducting the information base for 2 years, after packing the tables I found that its size was reduced by almost twice. Sometimes this «twice» steps over a threshold of the forced costly transition from the file-server version to the SQL.
A similar problem occurs in the system «Commerce management 8» (in release 10 exactly, the 11-th I did not have a chance to examine and deploy completely for a while) — the tax accounting is maintained by itself, nobody thinks about its «redemption», the remains grow, the users «face by transactions» when conducting the documents. Disabling the generation of records for the VAT tax accounting (comment 10 lines in general module) allows reducing by a quarter an information base size and accelerating the document conduction.
In the business accounting it is possible to note the situations when there is a disorder on the account — red and black «comb» of remains that scattered randomly between the analytical objects that are related to a single accounting unit.
And (for accounting 8) on the accounts that have subcount of composite type sometimes «counter» remains are formed by the «empty» (null reference of any type) and «very empty » (undefined value) subcount value. The same thing is with measure «Subdivision» - a situation occurs when a part of records is written for the null reference, and а part— for NULL (fixed in the mode «Testing and restoring IB» in the Designer). AS a result, the typical documents see and do not see unpredictably the remains viewed by the reports bringing the user to hysteria (in the turnover balance sheet the goods exist, but its sales hard not sees it).
At the operation level the closing principle is expressed in some a different way. Formulate it as follows: All the used accounting sections should receive, if possible, the most complete data and the checkpoints should be developed and set between them for the mutual check.
Following this principle allows preparing the accounting tolerant to the errors and falsifications, complete and actual.
Consider an example for preparing the checkpoints:

  1. It is required to reflect correctly the records over the cash office and bank, (checkpoints – correspondence of discount bank remains to the statements received from bank, correspondence of the discount cash office remains to the previously printed and signed cash book).
  2. This, in turn, will allow minimizing the input errors of primary documents for the expense reports (checkpoints — debts of advance holders) and goods records (checkpoints — mutual payments with suppliers and customers).
  3. Monthly audit of warehouse remains and mutual payments with clients will also allow minimizing the error of primary documents (checkpoints — circulating assets for acc. 08, 10, 41, 62, subcount analysis 62, report on detection of negative remains for 10, 41, etc.), verifying the materials and other costs, registering OS, etc.
  4. Correctly entered and included mutual payments will allow automatically preparing VAT reporting, particularly — for VAT from advances (considered in the illustration to the «IBM principle»), checking the opposite goods records and remains (checkpoints — universal reports of VAT registers, verifying the advances and VAT of advances, verifying the data of registers and business accounting).
  5. The timely requested through the telecommunication channels verifications for the taxes, together with p. 1., will allow keeping the actual state of payments for the basic and other taxes and controlling their timeliness charge (and appropriation to the costs) (checkpoints — TBS for the keeping account of taxes and duties, payments).
  6. Verification of the business accounting and text accounting (on the income tax, STS or IE) allows checking the accounting fullness and correctness of the incomes and expenses for the taxing purposes (checkpoints — report «Analysis of business and tax accounting correspondence», «Analysis of STS tax accounting», universal reports on the IE tax accounting registers, TBS with enabled flags of tax accounting).
  7. The correct accounting for all the sections gives a reliable base for automated filling all the regulated reporting.

Each of checkpoints can be verified by the formal analysis of data displayed in the report. Each algorithm of such verification can be fully given for the user to record. Dual recording of business accounting or relation of different accumulation registers via the typical documents are the natural closing «conductor», and the changes made in one accounting section immediately «surface» in any other allowing fixing the chains of errors (or detecting the unauthorized changes).
In the open accounting no mutual checks are possible and it is possible to refer to the primary documents only using the direct enumeration.
The listed example is not complete. At the same time, I hope that I could explain the essence — the correct accounting closure allows developing and using a number of checkpoints that lead to the execution of «IBM principle», promote forming the trust to the accounting, significantly simplify an internal audit and correction of errors. Be sure — if you will be able to give the accountant a system vision of checkpoints that allow quickly and reliably detecting the chains of errors in the accounting, you will gain not only reliable and listened to you client, but also the positive recommendations.

6. Principle of standard functionality preservation.

When deploying the systems for which it is important to be supported by the supplier (Enterprise accounting, SSM, PEM), it is required to follow as much as possible the standard functionality. Sometimes, it is possible to use it unconventionally. If for any section it is reasonable to develop non-standard one, then it is extremely desired to add it «at the side». For such cases it is good to use a term “nondestructive configuration” that was kindly and neatly prompted by the user with nickname “Archibald”.
Incorrectly added functionality or modification of standard one significantly obstruct the product update and force the user to ask himself «why do we pay so much for the update?» and «why after update the section A, B, C, D, E… do not work again?». As well as to break into angry abuse «Do not send to us anymore this boy/girl for update — he/she knows nothing and will destroy all the accounting for use again».
For such configurations as “Commerce management” this principle is less topical, because in most cases this configuration is updated extensively and by force under the operational needs to please of payback principle, but it does not require the updates. However, with issuing a new resolution of VAT accounting in 2012 the extremely required and important documents “Arrival correction”, “Sales correction” appeared that are correlated enough to the general modules, and the update task of extensively modified solutions based on the CM became for a short time extremely topical, critical and emergency.
It is necessary to think separately and carefully about the deployment and modification of configuration «Complex automation» and «Production enterprise management», since they combine the elements of operational management accounts (that usually require an extensive modification that obstructs the updates) and business and payroll accounting (which requires the regular updates). If the customer enterprise can afford a long maintenance of 1C staff specialist, then this principle, probably, is not so topical, because the staff specialist (if he will organize his work competently) is not so heavily and simultaneously charged with the update tasks like the contract one. In addition – the staff specialist is a carrier of automation scheme and can easily extract from the configuration a non-standard functionality (add by himself) and transfer it to a new release without errors. A contract specialist deals with all the clients at once, but tomorrow he will leave his job at all and another one will come to the customer enterprise who (still) does not know the essence of made changes. This may cause far-reaching and unpleasant consequences identified in a long time after update, when an operational copy with undamaged data is already unavailable.
The maximal use of standard functionality allows:

  • easily applying update even by the specialist of little qualification;
  • moving the knowledge of accounting scheme to the user — that is, solving the questions of complex sections not in software, but operationally, and giving the operational knowledge for the customer to record, rather than to enclose the software «know how» on the specialist (however, sometimes this is necessary too 🙂 ) by forcing him always keep in mind the client accounting features;
  • using relatively reliable, for a wide range of situations для (currency accounting, different measurement units, features of accounting politics), tested many times interface and code from 1С developers, rather than to write independent hack for a strictly particular accounting case.

In a number of cases it is possible to «extricate yourself» by applying unconventionally the standard functionality or by applying it not on purpose.
In some situations it is absolutely impossible to dispense with modifications. And here, of course, it is reasonable to add all the changes «at the side» - using the event subscriptions (to finish conduction of documents over their own registers), documents entered based on, information registers (to store the qualifying information for the standard objects), properties and characteristics of objects, etc. – in such way that the update would be performed easily as much as possible and the use of standard objects in the standard cases did not differ from the official documentation.
Also it is required to note that sometimes (unfortunately, quite often) the standard functionality operates incorrectly (error in release (or in DNA of methodologist)). In this case, it is required to understand the ideology inherent in the standard functionality by the supplier, to intervene in the configuration and restore its operability (for example, by rolling back the individual metadata objects to a previous release or by your own corrections, very minimal and annotated). It is recommended for the users of basic versions to propose (for recording) more of less suitable way for passing the section failure by manual corrections of conductions and registers.
Of course, you should not forget that in this case about a reasonable compromise between the concept of nondestructive configuration and operation convenience preserving the execution of the next in succession principle.

7. Principle of methodical correctness

A principle inobservance of which, in my experience, produces during deployment the highest number of flippers.
It is unacceptable to solve the local tasks without taking into account the correct technique of automated accounting.
Such errors occur mainly from two sources: from client and from a lack of specialist knowledge. Consider the first consequence:
It is unacceptable to allow the client to promote incorrect technique of automated accounting.
In particular, if you take a good programmer from the executor and a good accountant from the customer and, meanwhile, neither of them understands the methodical essence of deployed system, then they will make together from the project uncomfortable in operation, hardly updated and giving unreliable results nightmare.

If the blind lead the blind, both shall fall into the ditch (English proverb)

To illustrate this principle, I will bring a long, but hopefully noteworthy example.
A certain company kept records for a long time in the system «1С: Enterprise 7.7» using an extensively modified accounting configuration with release 4.5. In general, a simple accounting combined the wholesale and retail trade (with GTS), the production elements. Somehow it was automated, the accountant has developed an operating scheme to which they used. As it was often the case with accounting 7.7, the subsystem of regulated reporting was not used (the reports were generated in the external program), the legislation at that time did not change significantly, the tax accounting for the income tax coincided instructively with the business accounting and was not kept. Therefore, the updates themselves were not required.
One day, the enterprise leaders decided to transfer the accounting to «1С: Enterprise accounting 8» (release 2.0). Skip the reasons for the transition — they were well-grounded.
The organization invited for deployment a franchise company from which a specialist was sent (programmer on the profile). From the customer side an accounting department was involved in the project in the amount of several people.
The transition of remains was performed more or less correctly. And then the miracles began. Since neither programmer nor chief accountant had the methodical grounding for installing the accounting in the target configuration, the accountant began to require from the programmer an exact repetition of version 7.7 functionality and the usual modifications.
In this case, the programmer absolutely correctly and precisely solved those tasks that the chief accountant set, at the same time, without thinking about the consequences of made changes.
For a start, the accounting politics was configured incorrectly, in particular — a simplified VAT accounting was set. «Your VAT tax accounting is so complicated, let’s just the documents will get to the purchase/sales books — it was so in the seventh version». The fact that the VAT of advances had to be generated manually did not confuse anyone, because «it was so in the seventh version».
Then several new types of documents were developed (related mainly to the retail) and the standard documents were corrected (sales, arrival, etc.). The chart of accounts was significantly fixed, for example, the accounts were added for the retail accounting of goods 41.13, 41.14 and 41.15 which, in fact, differ only by classification of warehouses in terms of management accounts (i.e. their business accounting was the same). A mechanism of margin calculation was completely modified on account 42 (of course – the standard mechanisms did not expect the new indistinct subaccounts and refused to work).
In general, already at the first stage the information base was updated with significant man-hours and the most of automated mechanisms provided by the modern version of accounting system were disavowed. It was then that I came to a new place of work, was temporarily assigned to this project like «looking», was horrified and tried to improve somehow the situation. But considering the accounting neglect and the accounting department conservatism, in general, I managed to fix only few local errors in the remained standard sections and to introduce a little order in the modifications. Then I moved to the other projects, but watched for the interest.
And a year later, it happened so that a number of enterprise warehouse shops that performed the retail sales went to UTII and it took to organize a separate GTS/UTII accounting according to all the rules. At this time, a chief accountant remembering the «seventh version» ordered the same programmer to create the accounts 44.01, 44.02, 44.03 (What for? For the costs of GTS, UTII and distributable, he does not care that the cost item has the corresponding attribute and the corresponding closing mechanism is written). «Well, or course — we find it comfortable — you performed the processor and see the costs for GTS, UTII and distributed — on different accounts. It was so in the SEVENTH VERSION….».
Thereafter, the programmer had to completely rewrite the standard closing mechanism of account 44, because it was shocked by such arbitrary direction of the standard charts of accounts.
In addition, it became SUBBENLY clear that the VAT distribution of indirect costs will not work automatically because of the foresight included one year earlier mode «Simplified VAT accounting». And besides, the inclusion of VAT will be work in the price of goods / composition of costs for the goods to be sold by the activity covered by the GTS — again, because of the fact that this requires the existing balances of lot-size VAT accounting which is not kept in the mode «simplified VAT accounting».
Thereafter, the entire most complex VAT, except the purchases and sales (namely, VAT of received advances, VAT of indirect costs, VAT included in the price/costs) is now conducted manually.
Because of innovations in the Tax Code of Russian Federation, the expenses appeared in the organization that are not accepted for the purposes of income tax calculation, and it turned out again suddenly that they should be taken into account manually, because nobody took care to set the tax accounting for the income tax.
In the accounts 60/62 on the sub-accounts of payments and advances — red and black «comb», (the counter debit and credit balance in the third subcount that converge in the contract and contractors) accordingly, the balance is automatically generated with the distortions in the lines of notes and bills payables. On the 19th account there is also a «comb», where the debit balance is in terms of documents and the credit — on the empty subcount that, together with the simplified VAT accounting, allows verifying the purchase book with the business accounting only by checking for hundreds of incoming documents.
As a result — no one report is generated with button «fill» so that not to correct it completely. The purchase and sales books are compiled only after a long manual modification by the documents «VAT reflection to deduction», «Reflection of VAT charge» (to distribute VAT of indirect costs and include it in the price / costs). The tax accounting for the income tax — is not performed and the income tax is not calculated. The automation mechanisms of separate GTS / UTII accounting — do not work. Each update (that are performed rarely and on major holidays) is transformed for the specialist into the 10-hour headache and for the enterprise — in the costs and in fact — is absolutely useless.
Among all the standard mechanisms, in fact, only the journal of conductions and the business analytical reports are working. The accounting department employees are engaged 90% of the time in that they introduce manually and recheck everything that could be automatically calculated with a single button and constantly complain that it was everything was good in the «SEVENTH VERSION», but now everything is bad and it is difficult for them to live.
In this case, the huge costs (relative to their size and objective complexity) were invested in the project that were focused not on the completion of minimum required modifications and training the staff for methodically correct accounting, but to solve a stream of local tasks using a method of unrestrained intervention in the configuration and to make the patches for all locations.
At the same time, everything seems to work. The programmer did exactly that the accountant asked. And the project is objectively failed, because the payback principle is violated and the expenses of accounting department resources for keeping the records after deployment became more than they were before.
The most annoying is that I have seen these projects very much and all of them had a similar story: an authoritative customer representative began to «lead» arbitrarily strong programmer (who has no methodical preparation). The programmer solved a stream of local tasks in exactly way it was required by the customer. But together they brought the project to the horrific state – up to the re-deployment.
Before deploying the task solution, it is required to examine the standard functionality and a technique of its application.
There are the cases when the implementer has insufficient preparation and takes his one methodically incorrect decisions leading off the project to the side of non-standard functionality and difficulties of operation and maintenance. For example, your humble servant in my project for deployment of configuration «Commerce management 8» wrote my own mechanism for calculating the retail prices from the purchasing prices according to the remembered margin completely ignoring the presence of a similar standard one. I spent a lot of time in this case getting not very reliable mechanism and even did not disable completely the standard one that started to cause the problems during pricing.
And I just casually acquainted with the standard capabilities.
The correct approach for deployment of accounting automation system required a presence of specialist with methodical preparation who know an order of accounting in all the standard sections and is able to analyze the non-standard needs of client and to give a task for the programmer to develop the changes in the configuration (or develop them himself). In this case, the changes must follow the above listed principles in order to be convenient, useful and repaid.
The specialist must have the sufficient authority and communication skills to introduce for the client the correct technique of automated accounting.
I hope this information will help in the accounting deployment and maintenance, and thank you for attention, if you have read this up to here 🙂

[Total: 0    Average: 0/5]

Leave a Reply

Your email address will not be published. Required fields are marked *