How do we equip an alternative to 1C
Since the task of writing “analogs” and “alternatives” 1C is non-trivial, it makes sense to present your vision and key points based on the experience of writing your knee crafts. Well, as a bonus to hear criticism and in time to remake where I missed.
In fact, at the moment 1C occupies an overwhelming segment in the niche of accounting systems. This is due to several reasons, including aggressive marketing. Let me remind the technical side. 1C in general, consists of two physically separate parts, the platform itself (the core, engine) and the so-called configuration.
Configuration is the part where application business logic is actually implemented. The platform provides persistent storage, high-level business objects, all sorts of designers and report builders, and a special programming language. But the technology platform itself, even with such capabilities, would not have been successful. Therefore, the configuration comes with already written logic - accounting, trading, warehouse, etc. subject to the current legislation. This is a fairly voluminous work, but as a result, the user gets a complete finished solution. And since the code of the configuration itself is open, it remains possible to adjust the business logic in any way and adjust it to your business.
')
These are pluses. But there are lots of downsides. In order not to describe here you can read for example here .
Attempts to oust 1C undertaken a great many. Most projects are trying to surpass the benefits of 1C. To deal with a huge corporation is not very promising. Products written in Delphi or .NET, that is, requiring recompilation, are generally noncompetitive, those who try to use javascript or VBA engines as DSLs look a little better, but in any case such solutions can be used mainly if there is a full-time programmer, which is small business, as a rule, can not afford.
Let's try to get on the other side. Do not try to surpass the advantages of 1C and offer solutions to those problems where 1C has disadvantages.
Since the minuses balance somewhere with the pros and we don’t have these minuses, even if we don’t have the pros at 1C, the balance will be about the same.
So, what characteristics should be created by the system.
There is no explanation required.
Multi-user mode with the possibility of direct access from mobile devices without the need to write special clients, synchronize directories, etc.
A language with a low threshold of entry, familiar to most web developers. Only a text editor is required for changes. The web application is easily updated by replacing individual files (hi to the 1C configurator). A weakly typed scripting language in combination with a set of high-level business objects is well suited for writing business logic.
It would seem that still need to be happy. However, in reality, open source accounting systems are, as a rule, curved porting of foreign developments.
And the curve is not only localization. To bring to the domestic legislation requires a lot of work. But that's not all. An accountant looking at the page of such a system will not understand why half of the fields and in general how to work here. Do not forget that the user probably already has experience with 1C and for sure this is his only experience with the accounting system. This means that of the hundreds of ways to make the layout of the invoice input page and sign the input elements, you need to choose the one that resembles 1C to the maximum (which means you need to shovel all the pages of the foreign creation).
When I gave freelancers to fill in their system with demo data (such as how the demo configuration in 1C), the question never arose - how to work here.
A more common problem is over-complication of the system. I think this is the main reason why projects are not brought to mind.
The programmer usually makes the system as flexible as possible (and how else!) Spends two thirds of the time on writing numerous settings, wizards, generators, or even worse tools for the command line, etc.
A user, an aunt, an accountant, without being an IT person, looks at all this good with anguish, not understanding why you can’t just put a couple of buttons. Then he calls the programmer to come in, set up the program after the next order of the Ministry of Finance. The programmer is sincerely indignant that for a stupid user, is it really difficult to deal with a couple of dozen checkers and combo boxes. The truth of his crush subsides when it turns out that the setting is not enough and now we have to wade through the jungle of the infrastructure code, providing the notorious flexibility.
An example is itself 1C - from version 2.0, where accountants really introduced formulas in a special “bird” language to monster 8.3. Try to give the manual to the uninitiated and count from which attempt he gets into the ornate verbal construction of the “plan of types of characteristics.”
This implies the following idea. Since it’s all the same to invite a programmer and the cost of this programmer’s work is proportional to the trickyness of the system, then why bother with it. Isn't it easier to throw out everything that is cunning and allow the programmer to work only with business logic, because the implementation of business logic is actually the task of the program.
Let me explain by example. Chart of Accounts. It changes extremely rarely. It is configured once during the implementation of the program and, as a rule, does not change in the process of work (I remind you that this is not about enterprise systems). It may be necessary to add some subaccount sometime. But under it, you probably need to adjust the code, which means calling the programmer. But for two seconds, the programmer will insert a new entry into the chart of accounts using the usual phpMyAdmin and there is no need to write the editor of the chart of accounts and force the user to specify in advance the unknown accounts in the input forms of primary documents.
Similarly, you can leave only the really necessary and, most importantly, user-understandable settings for business logic — addresses, tax rates, etc.
Here is the main ideology, which, in my opinion, should be present in the implementation of this class of tasks.
And now some general technical ideas that can be useful to "cyclists" when writing their own 1K killer.
A typical question on the forums asked by writers CRM, accounting, storage systems and workflow systems. How to store documents that obviously have a heterogeneous structure. A separate table for each type of document, a common table with a bunch of universal fields, now NoSQL repository fashionable ...
It is proposed to store all documents in one table in a blob, packaged in XML. Separately - only general fields that are shown in lists and journals - document number, creation date, author, status. Wrapping in XML takes precedence over serialization or json — each value is framed by a named tag, which means you can perform an end-to-end search without stumbling on unnecessary lines. That is, find a link to the counterparty
, XPath. - , , Document — header details ( ) — . , — .
.
, . , id , . , «» .
— , .. , , , , . . XML. , , ( ).
-.
HTML. , , Fenom.
— , . , HTML Word Excel. — HTML docx xslx. ( , ) . , . , . , .
pdf TCPDF , , PDFCreator .
, - , — .
, . 1. — , ROLAP . , ( - ), , . — — , , , . ( ) — . - . .
, . , , .
, . , .
, 1. «» «». , (). — , , . . . — 4 : , php — (-), php (Entity), . PHP «» . , invoice goodsissue. . , . , , , “”. «» …
, Lego. . . .
, , , WAMP .
, - — . 1 PHP. - - (, ) .
, — , , , . , , 1.
, , . 1 — , . .
In fact, at the moment 1C occupies an overwhelming segment in the niche of accounting systems. This is due to several reasons, including aggressive marketing. Let me remind the technical side. 1C in general, consists of two physically separate parts, the platform itself (the core, engine) and the so-called configuration.
Configuration is the part where application business logic is actually implemented. The platform provides persistent storage, high-level business objects, all sorts of designers and report builders, and a special programming language. But the technology platform itself, even with such capabilities, would not have been successful. Therefore, the configuration comes with already written logic - accounting, trading, warehouse, etc. subject to the current legislation. This is a fairly voluminous work, but as a result, the user gets a complete finished solution. And since the code of the configuration itself is open, it remains possible to adjust the business logic in any way and adjust it to your business.
')
These are pluses. But there are lots of downsides. In order not to describe here you can read for example here .
Attempts to oust 1C undertaken a great many. Most projects are trying to surpass the benefits of 1C. To deal with a huge corporation is not very promising. Products written in Delphi or .NET, that is, requiring recompilation, are generally noncompetitive, those who try to use javascript or VBA engines as DSLs look a little better, but in any case such solutions can be used mainly if there is a full-time programmer, which is small business, as a rule, can not afford.
Let's try to get on the other side. Do not try to surpass the advantages of 1C and offer solutions to those problems where 1C has disadvantages.
Since the minuses balance somewhere with the pros and we don’t have these minuses, even if we don’t have the pros at 1C, the balance will be about the same.
So, what characteristics should be created by the system.
Open source. Cross platform
There is no explanation required.
Web application.
Multi-user mode with the possibility of direct access from mobile devices without the need to write special clients, synchronize directories, etc.
Php
A language with a low threshold of entry, familiar to most web developers. Only a text editor is required for changes. The web application is easily updated by replacing individual files (hi to the 1C configurator). A weakly typed scripting language in combination with a set of high-level business objects is well suited for writing business logic.
It would seem that still need to be happy. However, in reality, open source accounting systems are, as a rule, curved porting of foreign developments.
And the curve is not only localization. To bring to the domestic legislation requires a lot of work. But that's not all. An accountant looking at the page of such a system will not understand why half of the fields and in general how to work here. Do not forget that the user probably already has experience with 1C and for sure this is his only experience with the accounting system. This means that of the hundreds of ways to make the layout of the invoice input page and sign the input elements, you need to choose the one that resembles 1C to the maximum (which means you need to shovel all the pages of the foreign creation).
When I gave freelancers to fill in their system with demo data (such as how the demo configuration in 1C), the question never arose - how to work here.
A more common problem is over-complication of the system. I think this is the main reason why projects are not brought to mind.
The programmer usually makes the system as flexible as possible (and how else!) Spends two thirds of the time on writing numerous settings, wizards, generators, or even worse tools for the command line, etc.
A user, an aunt, an accountant, without being an IT person, looks at all this good with anguish, not understanding why you can’t just put a couple of buttons. Then he calls the programmer to come in, set up the program after the next order of the Ministry of Finance. The programmer is sincerely indignant that for a stupid user, is it really difficult to deal with a couple of dozen checkers and combo boxes. The truth of his crush subsides when it turns out that the setting is not enough and now we have to wade through the jungle of the infrastructure code, providing the notorious flexibility.
An example is itself 1C - from version 2.0, where accountants really introduced formulas in a special “bird” language to monster 8.3. Try to give the manual to the uninitiated and count from which attempt he gets into the ornate verbal construction of the “plan of types of characteristics.”
This implies the following idea. Since it’s all the same to invite a programmer and the cost of this programmer’s work is proportional to the trickyness of the system, then why bother with it. Isn't it easier to throw out everything that is cunning and allow the programmer to work only with business logic, because the implementation of business logic is actually the task of the program.
Let me explain by example. Chart of Accounts. It changes extremely rarely. It is configured once during the implementation of the program and, as a rule, does not change in the process of work (I remind you that this is not about enterprise systems). It may be necessary to add some subaccount sometime. But under it, you probably need to adjust the code, which means calling the programmer. But for two seconds, the programmer will insert a new entry into the chart of accounts using the usual phpMyAdmin and there is no need to write the editor of the chart of accounts and force the user to specify in advance the unknown accounts in the input forms of primary documents.
Similarly, you can leave only the really necessary and, most importantly, user-understandable settings for business logic — addresses, tax rates, etc.
Here is the main ideology, which, in my opinion, should be present in the implementation of this class of tasks.
And now some general technical ideas that can be useful to "cyclists" when writing their own 1K killer.
Document storage
A typical question on the forums asked by writers CRM, accounting, storage systems and workflow systems. How to store documents that obviously have a heterogeneous structure. A separate table for each type of document, a common table with a bunch of universal fields, now NoSQL repository fashionable ...
It is proposed to store all documents in one table in a blob, packaged in XML. Separately - only general fields that are shown in lists and journals - document number, creation date, author, status. Wrapping in XML takes precedence over serialization or json — each value is framed by a named tag, which means you can perform an end-to-end search without stumbling on unnecessary lines. That is, find a link to the counterparty
<contragent>12</contragent>
, XPath. - , , Document — header details ( ) — . , — .
.
, . , id , . , «» .
— , .. , , , , . . XML. , , ( ).
-.
.
HTML. , , Fenom.
— , . , HTML Word Excel. — HTML docx xslx. ( , ) . , . , . , .
pdf TCPDF , , PDFCreator .
, - , — .
, . 1. — , ROLAP . , ( - ), , . — — , , , . ( ) — . - . .
, . , , .
, . , .
, 1. «» «». , (). — , , . . . — 4 : , php — (-), php (Entity), . PHP «» . , invoice goodsissue. . , . , , , “”. «» …
, Lego. . . .
, , , WAMP .
, - — . 1 PHP. - - (, ) .
, — , , , . , , 1.
, , . 1 — , . .
Source: https://habr.com/ru/post/270087/
All Articles