dservgun / erp

erp

erp

Objective

• To enable small to medium businesses manage their business.

Technical architecture

• Haskell encapsulates most of the architecture as part of the type system for the application.
• Use a database as way to copy state periodically.
• Needs to be configurable: currently we support acid state, but the model needs to be scalable to support different databases and configurations.
• Internationalization of requirements and language strings: including company, tax code definitions etc.
• A cloud haskell based implementation to handle distributed processes.
• Internet enabled devices running on Arduino or similar devices need to be treated as first-class members of the enterprise to help manage realtime changes to the process. For example,

General running installation guide

• cabal clean
• cabal configure --enable-tests --user (i dont recall the need for this flag, its on haskellwiki somewhere)
• cabal build
• (there are no tests cases yet, so we do this) ./dist/build/tests/tests (If you see some output, things might be working)

General Feature list

• No SQL based implementation -- acid state.
• Social anywhere
• Websockets enabled

Feature list -- to be completed

• Offline and realtime messaging: Users need to be able to send messages and all messages are persisted.
• Each entity needs to be in draft/commit mode - Save/Save draft need to be default.
• Realtime messaging needs to be context sensitive: for example if a user is working on a specific transaction that requires supervisory/cross functional approval, the system should set up an interface to discuss the particular transaction. All messages will be associated with the transaction for audit trail.
• Approval workflow needs to be customizable.
• Realtime data feed for currencies if needed. Usually currency transactions are end of day settlements. The system should be able to customize the sleep interval for querying currency rates.

UI choices

• Seaside: My opinion is that ui has an oo bias and Smalltalk is a better solution. Need to investigate that.
• For internal testing, wxPython seems to be a more suitable option.
• Haxe
• Scala FX

Coding standards (mostly borrowed from haskellwiki)

The server (ErpServer.hs) and the model (ErpModel.hs) are getting out of control. Needs a rewrite. Naming of variables: this happens when we do a match for maybe and have to come up with another set of readable names for each case.

Notes (discrepancies between the tryton and the current model):

• The accounting method that simplifies computation of inventory and probably preferable is to manage products as batches is in this (link)[http://www.oldschoolvalue.com/blog/valuation-methods/fifo-lifo-average-inventory-valuation/#fifo-method]. To handle this additional requirement, the model deviates a bit from the tryton definition.
• Account entity maintains a set of auto-complete tax types for a journal. This is better managed by the journal entitiy
• The initial version was not using lenses, but it seems to be the right way to go, specially when we need to traverse/update tree-like structure: Account, Tax Code, Categories, UOM etc.
• Error handling is using the ErpError across all constructors and this seems to be ok, because not doing this seems to complicate the rest of the interface. This design lead to the Applicative and Monadic instances of ErpError.

Notes on testing the application

• Current tests run on arbitary instances using sample'.

References

• Tryton
• Accounting methods
• Batch based computation

Issues: Because of the multiple declarations error for overloaded attribute names, we have to create modules for each entity. Also, the conventional support for an inheritance based generic class, such as RequestType, Entity (where entity could be a data constructor) is not a recommended pattern, therefore we need to model entity as case expression when processing the entity. We need a request log to manage log for the requests : time, ip etc.

erp's Issues

Handle acid exceptions

Handle exceptions across the server: send the exception message back as a json response.
Design a response type in the server.

Integrate with travis for ci

Host acid server remotely

webserver and acid should not be hosted on the same server.

Mac OSx seg fault

Cant test the application on mac.

Rewrite processRequest with the ErpError type.

processRequest :: WS.Connection -> AcidState (EventState M.GetDatabase) 
            -> M.Request -> IO()

Create Error types instead of Exceptions

per @S11001001 and i guess general haskell guidelines, we need to avoid exceptions instances because they can get eaten up etc.
This issue is a catch-all to remove exceptions from the model.

Create an mvar to communicate that the server has started

Currently the TestRunner uses a wait (that can change to retry, though the core issue remains for testing):
TestRunner should be able to start the client connection thread only after the server has started.

Though not ideal, the mvar is set just before the call to
putMVar m "Started..presumably" WS.runServer "127.0.0.1" portNumber $ handleConnection m acid
This seems to work for now.

Copy acid state to rdbms forking a thread

Based on the #haskell channel chat, using acid state for database persistence is not ideal and we need to copy state to persistent data store. Successful copy should remove the records from the acid state.

Move websocket thread to snap websocket

snap websocket
snap acidstate
for deployment. The current architecture is for testing purposes.