Debtors Ledger
The main components of the new Debtors Ledger are complete. We now have a calculated 50 hours of components to create and introduce which are being done during the next few days.
We had a problem in that the code is now condensed and reading it is challenging on 24" 1080P monitors. To solve the problem we have introduced 43" monitors on the work stations.
One observation is that when you get to this size monitor, a curved screen could be better.
The result is that we can now read 2 times the code in one display and this makes a huge difference.
1 Month to 90% Build Completion!
A recalculation of the rebuild time has suggested that as at the 21/6/2018 we are 30 days from a 90% rebuild position and 2 months to a full release.
The 90% rebuild date is very important because when the 90% position is achieved, we are then into a process of refining the build which is a different phase.
For example; the Budgeting Module (yet to be complete) is an analysis tool of the Accrual. The module is not as complex as the Accrual so its build will be faster.
So when we hit the 90% section, things get easier and so releases will happen sooner.
We have tried to release the current build but it just won't work. The new version is a completely different architecture and components like the current reporting section will not work until we have completed more of the build so we are avoiding releasing the new components until we are sure everything will work correctly.
Some of the completed modules. The menu screens are also being modified so that each user has their own relevant display.
We were to push out our statements this month with the new statement procedure but unfortunately we hit a snag.
The statement procedure requires the 'set up' components to let it know what it it should do. It also draws information from the customer database and both these modules are not complete.
So we have had to use the old statement procedure to process this month's statements.
The New Setup Module
All our focus is currently on the build of the new setup module.The old version had a setup for each module where as the new version only has one setup section.
It is a very smart setup section and includes a lot of features to help the administrator of the system quickly set up any area they want to change.
Once a set up is changed, there is no need for anyone to exit the program as the changes happen instantly.
The new setup module is multilingual and has a wizard to step you through setup areas.
As at 13 June 2018 we had completed the following*
Completed
- Accrual Ledger
- Journal Entries
- Depreciation Schedule
- Balance Day Adjustments
- Reporting
- Cash Book
- GST
- Debtors Ledger main components
- Allocations
- Statements
- Creditors Ledger
- Allocations
* There are still components to tie into each other but the module itself is done.
Still To Do
This is not the complete list of things to do but it is the main components.
Area | ||
1 | Budgeting | |
2 | Accrual Analysis | |
3 | Database X 3 | |
4 | Product Register | |
5 | Product Templates | |
6 | Debtors Ledger Sub Components | |
7 | Invoices and Credit Notes | |
8 | Quotes | |
9 | Job Management | |
10 | Ordering System | |
11 | Call Centre | |
12 | Staff Database | |
13 | Time Module | |
14 | Time Sheet Module | |
15 | Audit Trails | |
16 | Staff Log on | |
17 | Email/print/pdf | |
18 | Printer Setup | |
19 | End of Year Procedure | |
20 | End of Month Procedure (done but will be refined) |
It seems like a lot, and it is, so we are working around the clock to complete the build as quickly as possible.
Training and the Series Technicals
The new version is designed to require little training.
The basic functionality will be familiar to you and we are not changing the basic concepts.
We are changing the background architecture to what we have dubbed 'SoEasy GENERATION III'. SoEasy has involved two previous builds, this is the third build, and there will be a further build after this one:
- First build: 1991 to 2003: Entry Level Programming Architecture ( Generation I )
- Second build: 2003 to 2017: Continuance of Monolithic Code ( Generation II ) but the beginning of code containerisation
- Third build: 2018 to 2019: Module Containerisation and production of proprietary Algorithms ( Generation III )
- Fourth build: 2019 > Hybridisation and refinement into a multi code open source platform ( Generation IV )
Hybridisation means components of SoEasy will be able to run locally on devices such as computers, tablets, and smartphones; and on the cloud in a synergistic process of maintaining centralised final data
Multi code means that SoEasy will be built in lots of different codes.
Open Source means that lots of different programmers in lots of countries can contribute to the functionality of SoEasy.
The Algorithms (which process the data into tables) will be locked and accessed through secure Gateways that have a high level, three verification encryption key access process.
Other programmers will be able to use our open source modular code as a basis and create their own modules that access SoEasy in a fully open integration. This means they can (with your authorisation) add, edit, delete data throughout every area of the program except for Audit Trails where every action is recorded.
Sugar bad but really good when designing the file structures
The modifications are also designed to eliminate any area of the program where we have had a lot of support issues or customer enquiry.
The question is always, how can we support a million users around the world?
Current Project: Setup Module
Currently we are working on the set up area which will be functional by the end of this week and be further developed as we convert the existing modules.
Next Project: The Products Register
We have to convert the Product Register as it will be required when we build the Invoicing and Quote System.
Luckily we have already spent over 20 years developing the current Product Register and we know where it is good and bad.
The new PR will be much faster and have a lot of AI (Artificial Intelligence) built in.
This is a major component and it could blow out a three day re-build plan so we will have to see if we can really focus on it.
It's all about planning. The current product register has 344 fields of information (individual features of a specific product).
We are going to reduce the number of fields and increase the number of supporting files that give it a huge amount of flexibility.
We are aiming for a PR that will read 20,000 records a second. This means that a PR of 200,000 records (we do have customers with this much data) will be fully read within 10 seconds.
The normal user search will be instant.
Onwards...
Thank you for keeping support questions to a minimum and prompt payment of accounts. It all helps.