Geoprise Technologies - Responsive

What? Another General Ledger Application?

admin — Wed, 12 Dec 2018 07:24:01 +0000

By: Nelson M. Nones CPIM, Founder, Chairman and President, Geoprise Technologies Corporation

On November 30th, 2018, Geoprise Technologies released a brand-new General Ledger subsystem. It’s the first of four new financial applications we are adding to the GM-X ERP for Blockchain application suite. We’ll be adding Accounts Receivable, Accounts Payable and Fixed Assets subsystems soon.

The sceptics out there (and the world is full of sceptics) are already asking, “What? Another General Ledger Application?” If you are one of them, this blog post is for you.

Here I shall focus on what makes our General Ledger subsystem different from all the other accounting software on offer these days, and why those differences are important.

It Runs on the Blockchain

The GM-X General Ledger subsystem is the world’s first and only fully-functional financial application to run on blockchain technology, out of the box. Our nearest competitors are still in the proof-of-concept phase. Don’t expect to see fully-functional, enterprise grade applications from them until 2022 (at least).

Why is this important? Forget about paying suppliers in cryptocurrency, and using artificial intelligence (AI) to seamlessly execute “smart contracts” with trading partners. These are indeed bold, exciting and forward-thinking ideas, but way out in front of what matters today to every Chief Financial Officer (CFO) I know. Instead, focus on just one pressing concern: security.

Nearly a year ago, when Geoprise first published its GM-X ERP For Blockchain White Paper (PDF), I wrote:

As hacking by cybercriminals and state sponsored entities grows ever more frequent and sophisticated, ‘hardening’ existing systems has become a never-ending, costly and ultimately futile effort. Businesses and consumers no longer trust the patchwork approach to adequately protect their information assets.

In October 2018, Bloomberg BusinessWeek reported how operatives of China’s People’s Liberation Army inserted tiny microchips into server motherboards to infiltrate America’s top companies, among them Amazon Web Services (AWS) which dominates the market for cloud infrastructure services. To be fair, Amazon (and Apple, which was also named in the report) immediately denied that their servers were compromised, but Bloomberg BusinessWeek continues to stand by its story. Still, intellectual property theft remains a major issue in the ongoing trade dispute between the U.S. and China which has roiled world markets in recent weeks.

For today’s CFOs the stability of capital markets, and managing information security as well as intellectual property risks, are much more urgent concerns than figuring out how to receive payments in Bitcoin. Recent news from the information security front is reinforcing their widely-held belief that mission-critical financial applications must remain on company premises, under lock and key, even if it were less expensive to run them on cloud services.

An enterprise, like Geoprise, which operates from several locations around the globe, can keep its information assets completely secure by running the GM-X General Ledger (along with other integrated GM-X ERP subsystems) on premise at each location. Journal entries created within those organizations are posted immediately to the local GM-X ledger, and are also passed immediately and automatically to the headquarters organization over a private blockchain network, where they are posted again to the global GM-X ledger which runs on premise at the headquarters office. This gives both the local and headquarters organizations instant visibility of their current financial position.

This solution is completely secure because:

It runs completely on premise. Each of the local GM-X applications, and the global GM-X application, are accessible only from trusted corporate networks situated behind internal firewalls.
Everyone on the blockchain is trusted. The only participants in the private blockchain network are the headquarters organization and its subsidiaries, so all participants are trusted.
Only headquarters can unlock the data. Although each participant has a complete copy of the blockchain database, each local GM-X application encrypts every journal entry before adding it to the blockchain, and only the headquarters organization is given the decryption key. Confidentiality is preserved because the remaining subsidiaries cannot read or post these journal entries to their local GM-X ledgers.
Data in transit can’t be hacked. Even if the blockchain propagates over the public Internet, no one other than the headquarters organization can read the journal entries because they are encrypted end-to-end. Any attempt to tamper with the blockchain database will be immediately and automatically rejected by all participants because, by its very design, a blockchain database is permanent, tamper-proof and verifiable; and cannot be hacked.

You Can Run It on Your Smartphone (If You Want)

The GM-X ERP for Blockchain application, including our new General Ledger subsystem, is the first and only full-fledged ERP application in the world that you can run completely from your smartphone.

SAP enthusiasts will say that SAP Fiori®, which runs in front of the New General Ledger available with SAP S/4HANA®, delivers a “mobile first” user experience which is both responsive and adaptive (depending on the use case). But SAP’s Help documentation for displaying general ledger account balances says that this application runs on desktops only. Not so with GM-X General Ledger, which you can run on any device in any orientation.

Now, there are many reasons why users will continue to prefer their desktop and laptop computers over their smartphones, particularly when entering lots of data, but seeing today’s general ledger account balances is something a busy CFO just might want to do from a smartphone.

My point here is not to disparage SAP® software, but rather to prove our claim that the GM-X is the first and only full-fledged ERP application in the world that you are free to run completely from your smartphone ― or your tablet, laptop or desktop PC.

It’s A Modern, Perpetual General Ledger Built for The Age of Big Data

Let’s face facts: most general ledger applications in use today were designed a quarter-century ago, or even earlier. That takes us back to the dawn of the Internet.

Greybeards like me still remember when “perpetual” inventory systems replaced old-fashioned “periodic” inventory control. Back in the day, you had to roll closing inventory balances over at the end of each month to create opening balances for the next month, and people couldn’t use the system at all before this was done. Actually, old-fashioned general ledger systems used to work the same way, and only kept one or two years of history online.

These limitations existed for a very simple reason: online storage was scarce, and extremely expensive. In 1981, when I designed and built my first ERP system, an 80 megabyte hard drive cost today’s equivalent of about USD 70,000!

But fast forward to today, and you’ll find that all of the world’s popular general ledger systems (except GM-X General Ledger) require organizations to run some sort of procedure at year end which carries closing account balances forward to the next fiscal year. Until that happens, users (including the CFO) will not be able to see the closing balances for the previous year. Yet in this day and age there is no economic or technical reason why this needs to be done.

For this reason, the GM-X General Ledger subsystem only has one set of opening account balances. These are the initial opening balances created when migrating from a legacy application to the GM-X General Ledger subsystem. From that point in time forward, the system automatically calculates opening and closing balances on-the-fly (including the accumulation of profit and loss balances into retained earnings) for whatever time frame is of interest ― be it the current month, current quarter, current year-to-date, quarter-to-date last year, year-to-date last year, or any other time frame for that matter.

And, because the GM-X General Ledger subsystem keeps a full history of journal entry details alongside the original business transactions and historical account balances, CFOs can instantly drill down to individual business events ― shipments, invoices, payments, inventory movements, expense reports and so on ― no matter when these events occurred.

I invite you to explore the many features and functions which our new GM-X General Ledger application delivers. You will see that it has all the multi-company, multi-currency and multi-language capabilities you would expect from a robust, enterprise-grade application; but it should be clear at this point that a simple feature comparison isn’t the whole story. Thanks to its use of secure and proven blockchain technology, mobile-first design and perpetual general ledger built for the age of big data, it’s a product which delivers value that no other application on the market today can match.

GM-X: The World's First Mobile-First ERP

admin — Sun, 26 Aug 2018 23:00:00 +0000

By: Tony Marston, Director, Research & Development, Geoprise Technologies Licensing

GM-X is an enterprise resources planning (ERP) system which was first created in January 2007 and went live at the first customer in June 2008. It was designed from the ground up as a Web application comprising a group of interconnected subsystems, and was developed using the RADICORE framework which I built in 2002 and published in 2006. GM-X has been continually enhanced and new subsystems added since its debut. Today it has 17 subsystems.

Each subsystem has its own database and its own collection of tasks (user transactions). Currently there are 389 tables, 759 relationships, and over 3,000 tasks of which 2,720 have visible screens. Others use portable document format (PDF) output, comma-separated value (CSV) output for use in spreadsheet software such as Excel, or have no visible screens at all.

Recently, Geoprise introduced a completely new responsive Web user interface for our GM-X ERP for Blockchain application suite using the Bootstrap library. Unlike traditional enterprise resources planning (ERP) applications which were designed exclusively (or primarily) for use on desktop computers, GM-X is now the world's mobile-first ERP. How this was achieved is the subject of this article.

What Is "Responsive Web?"

Here is where we need to delve into the recent history of mobile device capabilities. The Apple® iPhone®, launched in 2007; and the iPad®, launched in 2010, were the first mobile devices to really gain traction in the consumer marketplace. Not coincidentally, these were the first devices to combine the color graphical user interface (GUI) found on personal computers (PCs) with touchscreen interaction (no stylus required) plus automatic screen rotation.

Before then, with the exception of mobile barcode scanners, virtually all business applications used conventional desktop layouts and a color GUI which worked equally well on desktop PCs and laptops, using mouse (and occasionally touchscreen) interaction but no automatic screen rotation. This meant that most screens for business applications could be designed using a single static form or table which fit inside a standard computer monitor.

The introduction of smartphones and tablets changed all that. Now, the same Web application can be displayed on at least 3 different screen sizes (desktop, tablet, smartphone) and 2 different orientations (vertical and horizontal, for tablets and smartphones). In order for the application to be just as easy to use in one mode as in any other, an adaptive user interface design requires a multiplicity of static layouts to deal with different combinations of screen sizes and orientations.

It is possible to display a Web page incorporating a static layout designed for desktops on a tablet or smartphone, but the browser will shrink the content to fit depending on the screen size and orientation. This often makes screens unusable without zooming in to make the contents legible, and to make touchscreen interaction practical. But most people (especially those who suffer from fat finger syndrome) complain that applications are cumbersome to use when they have to zoom in and out.

Mobile-First Principle

It’s a fact of life that small screens are the hardest to design. Consider a screen with more than 50 possible functions that can be executed when the user touches or clicks an icon, hyperlink, button or control, all designed to fit on a 1024 x 768 resolution display (108 square inches on a 15-inch monitor). An equivalent set of functions would also need to fit inside 10½ square inches on a Samsung® Galaxy S4 smartphone, either vertically or horizontally, and should be just as legible and easy to use as a desktop display. The resulting number of functions per square inch is 6.2 on a smartphone versus 1.7 on a 15-inch monitor — almost four times the density.

To make full use of new device capabilities, best practice evolved into two competing schools of thought:

Progressive enhancement (“mobile-first”) assumes that mobile design, which is the most difficult, should be done first. This means that the smallest screens will have only the essential functions. Additional, less-essential functions are exposed as screen size increases.
Graceful degradation is the opposite. All functions are included for the largest possible screen size, and then the less-essential functions are removed as screen size decreases.

“Mobile-first” is generally considered better practice because mobile devices have the most constraints; therefore designing within these constraints forces the ruthless prioritization of content (i.e. “mobile-first = content-first”).

This principle however only makes sense for use cases which require the content and functions to be delivered satisfactorily regardless of device size and orientation. This frequently isn’t the case for business applications. For example, mobile barcode scanners used in warehouses must follow a “mobile-only” principle because you’ll never find warehouse personnel lugging PCs or laptops around when they pick or put away products. On the other hand, in a business setting, intensive data entry screens would almost never be used on anything other than a traditional desktop PC having a full keyboard with numeric keypad, because:

Operator mobility is not a requirement;
Even though they are much bigger than tablets and smartphones, PCs and laptops are frequently much cheaper, so there is no economic incentive for using mobile devices; and
The virtual keyboard available on tablets and smartphones is simply not as productive, especially when the virtual keyboard conceals some of the content.

In general, I think the “mobile-first” principle is most appropriate for use cases which consume content — for example, reading data in tables, tree views or read-only forms, after looking it up using a search form — but is often (yet not always) inappropriate for use cases which create content, as is the case for data entry forms unless, for example, you are using mobile scanners in a warehouse or approving employee timesheets while traveling. So the basic approach we took when creating the Proof of Concept (PoC) was to focus primarily on the performance of screens which consume content, regardless of screen size or orientation.

As it turns out, the original philosophy of the RADICORE framework on which the GM-X application was built lends itself perfectly to a “mobile-first” approach, even though it was never conceived for this purpose. I posted this reply to a question in April 2006 — before the advent of the iPhone and iPad:

I avoid the situation where I try to pack as much information as possible into a single screen for the following reasons:

It becomes slower to build the screen due to the amount of data that has to be retrieved.

As well as the data for each zone you may also need a separate scrolling/pagination area or each zone, which adds to the clutter on the screen.

Although a small number of people like to see everything on a single screen, most other people complain that the screen is ‘too busy’, and that the information they are looking for is lost amongst all that ‘noise’.

Some people seem to think that having to navigate to different screens to see different sets of data is a slow and cumbersome process. Such people have not experienced the navigation buttons within Radicore.

The Radicore philosophy is to keep each screen as small as possible so that it loads fast, and use navigation buttons to quickly jump between associated screens.

In another place I wrote: “The Radicore philosophy is to have a large number of small and simple components instead of a small number of large and complex components.”

I think everyone can agree that “graceful degradation” is impossible to achieve without a massive amount of manual effort when all the content and functions are packed into a single, complex screen. But “progressive enhancement” (i.e. “mobile-first”) is straightforward, and can be accomplished with relatively little manual effort when you are starting out with screens that were deliberately kept as small as possible from the get-go.

Note that some “progressive enhancement” design decisions were made when developing the PoC. For example, smartphone-sized screens the static English text “You are logged in as:” as well as the last login date, time of day and user time zone do not appear — only the user name is displayed. This avoids wrap-arounds on vertical orientations without eliminating any functionality, particularly since most smartphone devices display the current time of day just above the screen anyway. The print and noprint icons were removed from the top right of small screens as they are irrelevant for mobile devices. As the screen width increases, the desktop-style “You are logged in as:” as well as the last login date, time of day and user time zone will appear along with the user name, print icon and noprint icon.

Another example of “progressive enhancement” is the use of hamburger menu (bars) on small or narrow screens instead of navigation buttons. As the screen width increases, the hamburger menus will disappear and individual navigation buttons will be displayed instead.

The third example of “progressive enhancement” is what happens when tables are displayed on screens which are narrower than the minimum width of the table’s columns. This makes each row become a table in itself, but only as wide as the screen, and each column is displayed as a separate row. As the screen width increases, the table will display in the standard row-column format familiar to desktop users.

Responsive Web Design Approach

The differences between responsive and adaptive design are discussed in GM-X: The No-Page Web Application. For the PoC a decision had to be made between using the responsive or adaptive approach, and the responsive design was the winner. For further insight see Responsive vs Adaptive Design — Which is Best for Mobile Viewing of Your Website?.

For Geoprise the most important factor is that, as far as we can tell, the adaptive design approach doesn’t work when you rotate a tablet or smartphone screen, because:

Tilting the device won’t cause a page to be reloaded; and
When deciding which layout to load, the server can only tell the screen size but not the orientation.

While testing our responsive Web design we could see that screen appearance and behaviour may differ between horizontal and vertical orientation – something which is not possible using an adaptive design approach.

Proof of Concept

It all started in May 2017 when Nelson Nones, the Founder of Geoprise, demonstrated to me a hypertext markup language (HTML) document which he had created as a PoC. This document was originally generated by the GM-X application, but had been amended to incorporate references to the Bootstrap library. He showed how, by changing the size of the browser window, the document automatically resized the controls so that they were readable whether you were using a full-sized desktop monitor, a tablet or a smartphone.

HTML=XML+XSL

The modifications to the original unresponsive HTML document included adding links to a series of cascading stylesheet (CSS) and JavaScript files as well as modifying certain HTML tags in order to reference the necessary CSS and JavaScript elements. The GM-X application currently contains over 2,700 HTML forms, so it would appear that converting all of these forms would be a major exercise requiring huge amounts of man-hours. However, this was not the case as the application was written using a model-view-controller (MVC) framework in which every Web page is constructed at run-time in two steps:

Construct an eXtensible Markup Language (XML) document containing all the relevant application and framework data.
Convert this document into HTML using an eXtensible Stylesheet Language (XSL) stylesheet.

This is explained more in GM-X: The No-Page Web Application.

The uninitiated may assume that every single web page requires its own XSL stylesheet as each page has different content, but they would be mistaken. While this was indeed true in the original development of the framework, by refactoring all the duplicated code so that it could be instead referenced from a shared library I gradually reduced the amount of code in each stylesheet to such an extent that by 2004 I had 12 reusable stylesheets which could produce any page required by the application. Yes, that is correct — all 2,720 forms are produced from just 12 stylesheets.

LIST view and DETAIL view

When writing software the aim is to reduce the amount of code which is written by making use of reusable components so that instead of writing another piece of code to perform a function you instead call a pre-written component from a central library which performs that function for you. In order to do this you must first identify repeating patterns which become candidates for insertion into the central library. Those of you who have built many Web forms should recognize that when displaying application data there are basically two views, a LIST view and a DETAIL view.

The LIST view displays data from several database rows in a table. On a screen designed for desktop and laptop monitors, each row’s data goes horizontally across the page. Above these rows is a single row of labels (column headings), as shown in the following diagram:

The DETAIL view displays data from a single database row. On a screen designed for desktop and laptop monitors, the row’s data goes vertically down the page with labels on the left and data on the right, as shown in the following diagram:

It is also possible for several pieces of data to be displayed on the same line in a DETAIL view, as shown in the following diagram:

But wait; there is more. In a DETAIL view it is also possible to have labels and/or data spanning more than one line, as shown in the following diagram:

Each web page contains more than just application data. It also contains a series of zones or areas, each having a different purpose and filled with data which is extracted at run-time. The following diagram shows the various zones in a simple LIST view:

The various zones in a DETAIL view are shown in the following diagram:

These zones may be used for read-only forms, and also for data entry forms which insert, update or delete database rows.

Other transaction patterns used for GM-X screens have different mixtures of both DETAIL and LIST views in the same screen, but is not necessary to document each and every one in this particular article.

Embed Each Screen’s Structure in the XML Document

Those of you who have dabbled with XSL transformations may be asking how is it possible to have a single XSL stylesheet which displays a different set of columns from different tables in the database? My biggest breakthrough when developing my reusable stylesheets was to discover how to embed the structure of the eventual HTML document within the XML document, and to have the XSL stylesheet process this XML data to produce the desired structure. This data in the XML document for a LIST view looks something like the following:

This tells the XSL stylesheet that data from table ‘x_option’ goes into the zone called ‘main’.

This data gets transferred into the XML document from the contents of a small screen structure script which is written in PHP, and which looks something like this:

This script also identifies which XSL file is to be used to perform the transformation.

The XML structure for a DETAIL view is slightly different:

The associated PHP script is also quite similar:

For the more complicated DETAIL view where each line of the screen contains labels and data for more than one column the structure details are slightly different:

While reading the bootstrap documentation I noticed that the column widths used in the DETAIL view could not be as varied as they currently were as, due to the way in which it was built, there can be no more than 12 cells to a row, and each cell must be a multiple of 1/12th or 8.33% of the current screen’s width.

Implementing the Change

Before I changed the software to access all the Bootstrap components we discussed how best to implement this change. Instead of making an irreversible global change we decided that, as some of our pages are very large and complicated and suitable only for a desktop monitor, we would make the switchover to be entirely configurable. To achieve this I amended the Menu Subsystem database to include a column called allow_responsive_gui (boolean) in both the Task and User tables. Unless both these switches are turned ON the screen will still be displayed in the old non-responsive mode.

As I had to make changes to my collection of XSL stylesheets in order to generate the different HTML output required by the Bootstrap library I decided to put all the necessary code, which includes the CSS and JavaScript (JS) files, in a separate directory called responsive-web. If any installation does not contain this directory then no responsive HTML can be generated.

As for application code, as I have stated previously all HTML output is generated at run-time by generating an XML document which is then transformed using an XSL stylesheet, and all this processing is performed in a single View object. Any changes to the contents of the XML document which are required by the responsive XSL stylesheet can be made in this single object and then be instantly available to the entire application. When this object detects that the responsive web option is available and has been turned on it can then add in the links to the necessary CSS and JS files. The biggest problem I had to address concerned the column widths in the DETAIL view as the Bootstrap library divides the screen into a grid having no more than 12 cells across. This means that each cell has a fixed width which is 1/12th of what is available in the current browser window. I then had to modify the contents of the <columns> element so that instead of this:

It included a new attribute called grid_size:

You should notice here that the sum all of the grid_size attributes is 12, and no cell is allowed to have a grid_size which is less than 1. All the other sizes have to be rounded down to the nearest 1/12th. Fortunately there is no such limitation on the LIST view so that you can continue to have any number of columns with any width.

I then to went through all the GM-X XSL stylesheets and modified the code for each DETAIL view so that it output the correct HTML required by the Bootstrap library. It took me one week to modify the first stylesheet, then once this was done it was a relatively simple matter to duplicate those changes in the remaining stylesheets. If I had a separate stylesheet for each of my 2,720 screens this would have been a mammoth task, but due to my development of reusable stylesheets this number was reduced to 12 (twelve).

That is why this task was completed in less than one man-month and not several man-years.

The only other task was to test each screen to ensure that when a column width was reduced to the nearest 1/12th that it did not become too small, otherwise I had to amend the screen structure script to specify a better width. This took a little longer, but was purely a cosmetic exercise.

Geoprise Technologies - Responsive

What? Another General Ledger Application?

Tags:

GM-X: The World's First Mobile-First ERP

Tags: