Scipio ERP 2.0.0 is here and it is another evolution of the software. For this release we focused on security, continuous integration, various application improvements and new developer tools, while also adding further premium plugins for our Enterprise clients.
New Developer Tools
IntelliJ IDEA Plug-in
We have created a new IDE plug-in for IntelliJ IDEA which makes it much easier to setup and work with Scipio ERP projects. Features:
Scipio project import
Automatic marking of src as source directories
Automatic marking of and lib as jar library roots.
Templating Toolkit- & Freemarker -support
Recognition of Scipio config files (Custom icons for each config file type)
Recognition of component file locations (starting with “component://”)
Navigating to services, entities and view entities (by clicking on their names)
Custom Structured Views for all file types
Quick help and full docs (Ctrl-Q) for
Templating Toolkit macros
Navigating to Java classes and methods referenced by service definitions
Run configuration templates
Simplify your data import with Excel
Import and Export data with our new Excel plug-in. This Enterprise Edition exclusive allows the synchronization of Order, User, Product & Category data right from within Excel. All sources are provided alongside the new component so that the Excel plug-in can be customized.
Lightning (Bitcoin) Payments
Run your own Bitcoin node and accept Lightning payments
Be one of the first to accept Lightning (Bitcoin) payments. Lightning is one of the fastest growing Bitcoin implementations and is known to be the most popular second layer Bitcoin technology to date. Our Enterprise exclusive lightning integration allows you to run your own network and be one of the first to accept Lightning payments.
If Bitcoin wants to become a broadly accepted payment method, it will have to overcome some of its flaws that make it unattractive for many commerce applications. One of its biggest problems is “transaction speed”, which pretty much precludes it from day-to-day use and will limit its reach as a mean of payment. Crypto developers have taken on the challenge and developed new technologies that intend to improve or fix some of Bitcoins flaws. The Lightning Network is one of them and we wanted to give it a try.
We created a new Lightning Addon for Scipio ERP. It adds “dated currency conversion”, “historical prices”, the full integration of the LND mechanics and support of the entire order process, including invoicing, payment capturing, accounting and more. In short: it provides all the necessary steps to allow businesses to accept the new currency, while remaining in the legal framework government requires. If you already own a Lightning Wallet and a few Bitcoin, you can check out the implementation with one of our demo-products (if you want to receive order and payment confirmations, please provide a working email address).
Here is what we learned:
Lightning is a step in the right direction
I cannot overstate how essential transaction speed and reliability under load is for businesses. As a merchant, you’d want all order payments to be processed immediately and reliably so that the order process can continue. An interruption in the process can result in dissatisfaction for the customer, or a delay in your own workflow. Unfortunately, Bitcoin is too slow to process the payments and it takes an average of ~20 minutes until an order is “confirmed”. Any risk-averse merchant will wait for the confirmation before delivering digital goods or acknowledging the order of physical merchandise, therefore the process is slowed down. This is very problematic from an ergonomic point of view since customers are in the dark about the status of their order for an undetermined time span. At its worst, Bitcoin had spikes of > 11.000 minutes of confirmation time.
Lightning fixes this aspect by using its own network to collect and confirm transactions. And indeed, in our fastest tests, we managed to secure a confirmation within 5-10 seconds. That makes all the difference in terms of payment process and one should recognize the achievement by the Lightning community.
…but not without its own flaws
However, actual transaction speed is only one piece of the equation. As payment performance also needs to be reliable, merchants will want to also reduce dependence on single Lightning installations and therefore distribute their own traffic to multiple servers. Clustering, running several servers redundantly, is a cornerstone strategy for successful online businesses. The problem: Lightning does not really implement the means to allow for this kind of distributed setup. Lightning, or in this case the LND implementation, only allows incoming connections from a pre-configured list of IPs. In fact, the system is pretty much setup to run on the same server, i.e. allow the commerce application, bitcoin and lightning nodes to share the same server resources. There are ways to connect from an outside system, but setting it up is tricky and dynamic IPs won’t be an option. The competitor c-lightning shares a similar design. As a result, clustering, in particular in a dynamic cloud setup, is very hard and would require a lot of workarounds and configuration management.
Of course we should keep in mind that Lightning is still in its early stages, so I want to be less critical. But because of how Lightning currently is implemented, scaling the system will have its limits. Without the ability to scale, Lightning will remain unattractive for larger installations.
Lightning has a bad user experience
With most payment providers, the process of setting up and integrating them in you shop is rather painless: it takes a few minutes for an account to be created and a day or so for the bank account to be confirmed and off you go. Unfortunately, things are a little different in the Lightning world, or as this author summarizes his experience:
TL;DR: Sending payments using the Lightning Network is cheaper than the regular Bitcoin network, but suffers from routing errors and wallet bugs that make it impractical even for highly technical users.
Our experiences have been similar:
Interdependence of technology
Lightning is not exactly light-weight. You will require a Bitcoin node and a Lightning node and both should ideally be installed on the same server as your business application. All of which will requires a lot of time to setup and configure. Bitcoin will need ~10 days to synchronize the 250GB package (the blockchain) to operate. If one of the systems fails, your business application will not be able to handle cryptocurrency transactions. This is even more problematic, as redundacy cannot be easily achieved (see above).
Incredibly difficult to use
Lightning is not easy to use, neither for merchants or customers. Don’t believe me? Here’s the steps you have to go through to enable Lightning payments:
Setup Bitcoin node & wait for Bitcoin node to synchronize blockchain (~7-14 days expected wait time)
Create a Bitcoin wallet
Buy Bitcoin through Bitcoin exchange
Fund Bitcoin wallet
Setup Lightning node
Create a Lightning wallet. For this you will need a cipher seed, ie. a password that has to be a 24 word string. It will look like this:
------------------BEGIN LND CIPHER SEED------------------
1. one 2. two 3. three 4. four
5. five 6. six 7. seven 8. eight
9. nine 10. ten 11. eleven 12. twelve
13. thirteen 14. fourteen 15. fifteen 16. sixteen
17. seventeen 18. eighteen 19. nineteen 20. twenty
21. twentyone 22. twentytwo 23. twentythree 24. twentfour
------------------END LND CIPHER SEED--------------------
There are generators for it – write it down!
Unlock the wallet. This will generate a TLS certificate and key. If you want to access the wallet from an external system (and you managed to configure lightning to allow the access from that specific IP), you will have to make sure that your wallet is unlocked with a specific kind of certificate (x509 P-256 curve). The certificate Lightning creates is not of the right kind, so you will have to create it yourself with OpenSSL and override the original cert. Remember to restart lnd and unlock the wallet once the cert is changed and write down the cert location for later.
Fund the wallet
Open a Lightning channel
Fund the channel, so that it can cover the transaction costs. The channel has to be funded by both parties. Since you are only interested in sending out invoices / payment requests to your customers, this would have to be your customer, although you can also take over the funding. The funding amount has to be sufficient (the rules of what is considered sufficient are not exactly straightforward, either).
Wait for channel confirmation by at least 6 peers/broadcasters
Remember the certificate and key? Copy them. The certificate and key will be required by each of your application systems, which will use it to connect to the node via client. This hard-binds the application server to a single lightning node.
LND (a specific Lightning implementation) relies on “Macaroons”, a cookie-like file, which will be generated once you unlock your wallet. These have to be copied to you business application, too.
Remember: if you miss one step, you will not be able to accept payments.
Buy Bitcoin through Bitcoin exchange
Get Lightning Wallet or use the Lightning client
Fund wallet from another address (Bitcoin wallet or otherwise)
Open a new channel
Fund your channel
Go through checkout, receive Payment-Request. This is a string of ~228 characters length. Copy the string to your phone (or scan a QR-Code. Cross your fingers that the QR-Code is large enough, because 228 character strings don’t translate well to qr-code images).
Accept payment and pay. By default you only have 30-60 Minutes to complete, otherwise Payment will terminate itself. (This is the default Lightning setting, although the merchant can modify this as part of his config)
Wait for payment to be accepted by network
Wait for payment to be processed by business application
Note: You can skip steps 1-3 on subsequent payments (unless you run out of Bitcoin).
Lightning is fun, but very early-stage. We have been operating the system for 4 months and crashes can and will happen all the time. Transaction channels can close or may not have enough peers at any time. There are no push notifications for these events, so you won’t know until a new transaction is placed and fails. Just like with other online payment gateways – there are no offline payments to make up for this design.
Only small payments accepted
Lightning limits each channel to 0.16777216 Bitcoin. Once the limit is reached a new channel will have to be created. Likewise 0.04194304 Bitcoin are allowed for a single transaction. To bring this into perspective: as of writing a single channel would only allow payments in total of €500 and single transactions of €125. So if you are a merchant selling products through your online store, you’d only be allowed to create invoices of €125 or less and for every €500 of income a new channel would be required.
The €500 limit alone breaks the neck for many merchants. Meanwhile, the process of opening a channel and funding it with some Bitcoin value for the process fees will make it extremely difficult to automate for business applications.
So what’s the take away?
Lightning sets out to improve the overall performance of the Bitcoin-like technologies and at that it largely succeeds. It is faster in terms of transaction time and our tests have shown that, once set up, Lightning can process single transactions at a fraction of the time Bitcoin would.
Where Lightning fails is at its usefulness for professional clustered environments. Yes, Lightning does allow multiple nodes in its network, but at the same time it limits the number of systems that can connect to a Lightning node. And sure, payments are considerably faster than Bitcoin, but they are not “instant”. Even under best conditions, it still takes more time for transactions to be secured and processed than with you average credit card payment. In addition, Lightning is neither easy to setup, nor convenient to run.
All of which means that at the current state, Lightning payments, though interesting, are not ready to be used as the primary means for business transactions. That being said, the technology has potential and we will be updating our own components with future releases. Regardless, the demo we provided is fully functional and the component is available to Enterprise users and interested parties on request.
Early in 2018 we decided to adopt Bitcoin payments and to experiment with second layer technologies, such as the Lightning Network. And although the technology is interesting, there are some real-life issues with Bitcoin and second layer technologies that make it awkward to work with in the context of real business applications. Speaking of real business:
Bitcoin is a nightmare for accounting
Businesses around the world are required to abide by their governmentally prescribed accounting standards. For their own income statements & balance sheets, they must use the main legal tender, i.e. the primary accepted medium recognized by a legal system as means of payment (for the US this would be the US dollar). This is the case regardless of whether they accept Bitcoin payments as an additional payment method (or any other currency, for that matter). Regardless of whrether or not a government accepts Bitcoin payments, governments will require businesses to turn in legal documents and these in turn are bound by the legal tender. This implies that any business application touching the creation of vouchers and calculations relevant to accounting (invoices, balance sheets etc.), will ultimately have to convert payments and receipts to legal tender just so that it can comply with the law.
In preparing financial statements, each entity—whether a stand-alone entity, an entity with foreign operations (such as a parent) or a foreign operation (such as a subsidiary or branch)—determines its functional currency in accordance with paragraphs 9–14. The entity translates foreign currency items into its functional currency and reports the effects of such translation in accordance with paragraphs 20–37 and 50.
IAS 21 – The Effects of Changes in Foreign Exchange Rates
This of course is true for all foreign currencies and you can still accept foreign currencies internally as long as you provide your tax statements in the correct form. But because of its volatility, Bitcoin is exceptionally unsuited for the job. The reason is simple: businesses must be able to keep their own assets value and potential gains constant or they risk losing money due to a drop or gain in exchange value. That is why it is common practice for businesses to pay a good amount to hedge the value of foreign currencies in larger sale contracts, despite the fact that currency exchange rates between major currencies (e.g. EUR/USD) are very non-volatile (compared to BTC).
The market price of Bitcoin in Dollar can fluctuate a lot
With Bitcoin, price changes are frequent and can result in a loss for either party. In 2017 we first saw a steep rise of the Bitcoin value from $930 to nearly $20,000, just to fall back to $3,500 in 2018. This is a nightmare for companies, as any change can result in a loss by selling or holding their assets in Bitcoin. Depending on the industry even a small change of the exchange rate can turn a sale unprofitable and easily ruin the company value over night.
Working with eleven decimal places is a no-go
The rules of accounting are written with currencies in mind which have at most two significant decimal places. Some currencies with very low values per unit might have less, but there is no currency where you are required to keep track of more. Sure, for some purposes – e.g. trading large amounts of low value goods like some commodities, screws or nails – you might have to consider the third or even fourth decimal place when calculating a price. But the government will still only require two decimal places in your tax documents.
That means that you can safely work with 3 decimal places in business applications to round for the end-users or accounting purposes without a significant loss of information. Now compare this to Bitcoin, which currently uses up to 11 decimal places (called “millisatoshi”). On top of that, there is no universally agreed upon number of decimal places which should be used for rounding. There really can’t be for a currency which jumps orders of magnitude in value in the span of only a couple of months.
To be able to show customers values that are at least somewhat understandable, you would have to continuously adapt the rounding rules which is not feasible from an accounting point of view. As a result, Bitcoin amounts are unpractical from a user perspective. Granted, you can use Bitcoin to exchange values, but that doesn’t make it a good experience. People dislike the use of decimals and are heavily biased towards digits. This is not news to anyone who ever worked in retail – it makes a psychological difference whether you purchase a product for $13 or $12.99. What it means is that if systems were to entirely switch to Bitcoin prices as a currency, it would be a lot more difficult for customers to compare prices or evaluate their worth.
Unregulated currencies aren’t practical
Another fundamental issue comes from Bitcoin’s greatest strength: it is unregulated. That doesn’t mean that Bitcoin is unregulated in a sense that no common law applies, but rather that because Bitcoin hasn’t become a legal tender by any government, it hasn’t gone through the various levels of standardization yet. It may sound absurd, but the reality is that for this reason alone, many things cannot be taken for granted that otherwise would apply:
Bitcoin doesn’t have a currency code
Yes, there is a Unicode character, but that doesn’t mean that a real currency code has been introduced. The most commonly used “BTC” is not likely to be adopted by the International Organization for Standardization (ISO), as currency codes are regulated according to the country code where it was first used as legal tender (USD = US dollar, GBP = Great Britain Pound Sterling etc.). “BT”, however, is already taken as a country code by Bhutan, which hasn’t adopted Bitcoin as a legal tender and is unlikely be the first. So BTC is not likely to be a candidate for ISO. The next equivalent “XBT” is more likely to be accepted by ISO, but doesn’t seem to be recognized by customers as a currency code for Bitcoin. Nobody can decide what the currency code is going to be as long as the debate is going on. This matters, because programming languages and framework like ours often rely currency codes to identify currencies. As the currency code is pending, programmers will have to live with workarounds.
On top of that, it is basically impossible to revert an erroneous transaction. Businesses are run by people and errors happen all the time, including transferring money in wrong amounts or to the wrong accounts. With our banking system, its almost always possible to get your money back (at least if the error is noticed within a day or two and you can give a plausible explanation why the transaction should be reverted). With Bitcoin, the money is gone unless the recipient is honest enough to transfer the money back (which also means high transaction fees for both of you).
Bitcoin is slow
It deserves mentioning again how slow Bitcoin truly is. The average confirmation time, the time it takes to process a transaction, was an overwhelming 55,500 seconds in 2017/2018. The reason is that Bitcoin on average only handles around 1 MB of data to be written to the blockchain every 10 minutes. This remained the case even after the initial cap of 1 MB has been lifted. That is an incredibly small amount of data, which means the number of transactions is very restricted. Considering that the average transaction size is currently measured at ~500byte, this translates to ~2000 transactions every ten minutes, or less than 4 transactions per second.
Average Confirmation Time of a Bitcoin Transaction in Minutes over the last 2 years
This may be well enough for small-scale operations, but it is hard to imagine what would happen if Bitcoin was the legal tender globally and only 4 people got to make a purchase every second. There are more children being born each seconds than Bitcoin transactions can occur. At the same time, it has a peculiar impact on transactions themselves: as more and more people are demanding their transactions to be processed, the processing time has become a scarce resource. For this reason, transaction fees have skyrocketed. In 2017, during an explosion of Bitcoin prices, transaction fees increased to an average of over $55. It has slowed down again since, but will repeat itself whenever transaction numbers increase. This is a growing issue, as more and more people use Bitcoin payments, transactions will only take longer and cost more to process.
So where does it leave us?
Bitcoins problems are well-known in the scene and there are solutions in the work that may improve or work-around some of its bigger architectural flaws. The biggest problem with Bitcoin at the moment, however, comes from its inner workings, the slow performance and overall bad design choice. Some of which, like the performance, can be improved but it is for these reasons that Bitcoin is not a good choice as either a primary base for business application, nor as a good payment method (at least at the moment).
The question is going to be, if second-layers improvements can be enough to solve the issues, or if the added complexity will keep Bitcoin from ever becoming a standard in the business world.
Let’s not kid ourselves: Scipio ERP is most often used by mid- to large-size businesses who are looking to add a complex e-commerce store to the mix. It is a niche in which our clients demand an enormous feature-set, coupled with a fitting modern design. It is tricky to show both off in a generic demo application, which is why we so far has opted for a very generic look-and-feel.
To make up, we often opted to showcase specialized demos to our Enterprise clients and stuck with our generic demos for the public, but these are now days of the past! In preparation for our release 1.14.5 we are adding additional demo applications & themes for anyone to try. As a start, “Major League” has been added to the system, which happens to be a stylish interpretation of a generic retail store. Additional themes “Ignite Fall” and “Major League” have been made available to backend users as well.
A new Excel Add-In is currently being developed, which grants our users direct access to Order-, Product- and Catalog data of their own Scipio ERP installation. This is particularly handy for those of us, who are looking for a nifty little spreadsheet to keep track of current affairs. A feature to import data back into the system (for a simplified workflow) is currently being discussed as well.
Now to the good news: As we are still testing the new component, we are interested in honest user feedback… and this is where you come in:
We are currently looking for 2-3 users, who are willing to test and give their thoughts on the current state of development. All beta testers will be given full access to the component at our Scipio Extranet and will be able to keep access to the component after release. This will allow you to open bug reports like other enterprise users and receive enterprise support on future releases of the component.