Hi all,
In preparation of the final release of LedgerSMB 1.8, the release branch
has been created for a period of stabilization. In order to release the
most stable version released by the project ever released, a preview
version was published earlier today: 1.8.0-beta1.
Users are encouraged to download the Docker images (tag:
ledgersmb/ledgersmb:1.8) or the tarball (
https://download.ledgersmb.org/f/Beta%20Releases/1.8.0-beta1/) for
evaluation purposes. Bugreports either in response to this mail or as
GitHub issues are highly appreciated!
The 1.8 release shifts away from HTTP Basic authentication, using encrypted
cookies instead. This eliminates the popup authentication dialog on expired
sessions. Additionally, does it provide a broader range of settings for
outgoing e-mail and has support been added to upload logos and other files
which can be used in downloadable documents.
Please test LedgerSMB 1.8.0-beta1 with your use-cases (but not in
production) and report any issues you're experiencing so they can be fixed
before the final 1.8.0 release!
Thanks,
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
The LedgerSMB development team is happy to announce yet another new
version of its open source ERP and accounting application.
This release contains the following fixes and improvements:
Changelog for 1.7.15
* Fix tax on invoice differs from search results (#4651)
* Fix COGS for purchased-in-arrears parts (#4658)
* Update Dojo to 1.15.3
IMPORTANT
The COGS fix addresses a bug which results in incorrect accounting
in case inventory is used and parts are sold before they are
purchased. This problem doesn't impact services or GL-only accounting.
While this fix addresses the core problem, it doesn't fix any data
that may have been recorded incorrectly! If you use inventory *and*
have sold parts before buying them (such that inventory ended up
being negative), LedgerSMB may have debited income and credited
expenses instead of crediting inventory and debiting expenses.
This leads to too high inventory, too low income and too low expenses.
The LedgerSMB team recommends consulting an accountant if this bug
affects your books or contact a LedgerSMB consultant to identify if
your books are affected (e.g. from
https://ledgersmb.org/content/commercial-support).
Downloads
For installation instructions and system requirements, see
https://github.com/ledgersmb/LedgerSMB/blob/1.7.15/README.md
The release can be downloaded from our download site at
https://download.ledgersmb.org/f/Releases/1.7.15
The release can be downloaded from GitHub at
https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.15
Or pulled from Docker Hub using the command
$ docker pull ledgersmb/ledgersmb:1.7.15
These are the sha256 checksums of the uploaded files:
868cfb31edfb62a404d5f264327c84e5ea5999aeb56a4adac5c7ac532c156f8d ledgersmb-1.7.15.tar.gz
f28a92326f99a4440f1be9ba74187ae4e61101a28262b8287ac8fca08e3e6d11 ledgersmb-1.7.15.tar.gz.asc
The LedgerSMB development team is happy to announce yet another new
version of its open source ERP and accounting application.
This release contains the following fixes and improvements:
Changelog for 1.6.21
* Fix COGS for purchased-in-arrears parts (Erik H)
* Update Dojo toolkit dependency to 1.13.7 (Erik H)
Erik H is Erik Huelsmann
IMPORTANT
The COGS fix addresses a bug which results in incorrect accounting
in case inventory is used and parts are sold before they are
purchased. This problem doesn't impact services or GL-only accounting.
While this fix addresses the core problem, it doesn't fix any data
that may have been recorded incorrectly! If you use inventory *and*
have sold parts before buying them (such that inventory ended up
being negative), LedgerSMB may have debited income and credited
expenses instead of crediting inventory and debiting expenses.
This leads to too high inventory, too low income and too low expenses.
The LedgerSMB team recommends consulting an accountant if this bug
affects your books or contact a LedgerSMB consultant to identify if
your books are affected (e.g. from
https://ledgersmb.org/content/commercial-support).
For installation instructions and system requirements, see
https://github.com/ledgersmb/LedgerSMB/blob/1.6.21/README.md
The release can be downloaded from our download site at
https://download.ledgersmb.org/f/Releases/1.6.21
The release can be downloaded from GitHub at
https://github.com/ledgersmb/LedgerSMB/releases/tag/1.6.21
Or pulled from Docker Hub using the command
$ docker pull ledgersmb/ledgersmb:1.6.21
These are the sha256 checksums of the uploaded files:
d64ae4d5a457a8bc6096982b0fde6d8002df29b59831a0940136519b915ed482 ledgersmb-1.6.21.tar.gz
2cca4d598c02e701c0e80e562ce7c23f83ce40f8aadc1ea27b40273311b0ddc0 ledgersmb-1.6.21.tar.gz.asc
The LedgerSMB development team is happy to announce yet another new
version of its open source ERP and accounting application.
This release contains the following fixes and improvements:
Changelog for 1.7.14
* Fix AR/AP account being reset to default on transaction Update-s (#4599)
* Fix CSV, ODS or TXT reports being downloaded without extensions (#4613)
* Fix 'To pay' amount resetting on second updates in single payments (#4633)
* Fix 'Paid' amount incorrect when 'Apply discount' unchecked (#4514)
* Fix income statement failing to filter on invoice reporting units (#4615)
* Fix payment discount not being posted (#4616)
* Fix tax base and amount doubled on printed invoice (#4645)
For installation instructions and system requirements, see
https://github.com/ledgersmb/LedgerSMB/blob/1.7.14/README.md
The release can be downloaded from our download site at
https://download.ledgersmb.org/f/Releases/1.7.14
The release can be downloaded from GitHub at
https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.14
Or pulled from Docker Hub using the command
$ docker pull ledgersmb/ledgersmb:1.7.14
These are the sha256 checksums of the uploaded files:
3d66daeaf62e6c236d168619d8ebf2f5f7e2adf4505c36f334ec507445614d48 ledgersmb-1.7.14.tar.gz
5969e1e883cc8339d501f74ed91da1479519237f18fd2f1fdca2874b1c338710 ledgersmb-1.7.14.tar.gz.asc
Hi,
As promised on my GitHub Sponsors account (
https://github.com/sponsors/ehuelsmann) I've drawn up a selection of bugs
that I'm ready to take on. The community will be offered an opportunity to
help select the bug that adds most value when being solved.
These are up for selection:
* Cannot delete business unit class
A bug reported for 1.7; for details see
https://github.com/ledgersmb/LedgerSMB/issues/4597
* AR Search for using salesperson doesn't filter
A bug reported for 1.7; for details see
https://github.com/ledgersmb/LedgerSMB/issues/4604
* Adding a reporting unit fails under some circumstances
A bug reported for 1.7; for details see
https://github.com/ledgersmb/LedgerSMB/issues/4614
* Payment discounts not posted
A bug reported for 1.7; for details see
https://github.com/ledgersmb/LedgerSMB/issues/4616
* Filtering the income statement by salesperson doesn't filter
A bug reported for 1.7 as
https://github.com/ledgersmb/LedgerSMB/issues/4615
Please provide your feedback by Wednesday May 20. Please note that sponsors
get an actual vote; all others provide advisory feedback.
If you most-wanted bug isn't in this list, please mail me directly about
that and I'll check to see if I can add it to the list on its next
iteration. Before you mail me, please make sure your bug is registered as a
bug on GitHub (https://github.com/ledgersmb/LedgerSMB/issues).
--
Thanks!
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Hi,
Talking on our chat channel, we were talking how to best implement our API.
Over the past months, the idea was to implement our new API as JSON:API.
This mail serves to lay out experiences and thoughts so far. Maybe it helps
to determine good next steps.
As a first step, it would probably be a good idea to list why we need an
API followed by what we need/want from it. The Why's:
* Integration with other applications, not all provided by the project
* Better support the needs from our web front-end: Vue, Dojo, react all
want to be hooked to REST APIs
* Development of custom front-ends
What would we like our API to be?
1. Standards compliant where we can; if a generic browser could be used to
"surf" the API, even better
2. Preferably well-defined semantics for good guidance on implementation
3. Resource definitions don't mirror internal table structures, but define
logical concepts
4. Easy to understand and use by non-project developers
5. Easy to expand by project developers while maintaining consistency
6. Development supported by Perl libraries on CPAN
7. Supports returning the same resource in many forms (e.g. invoice as
JSON, PDF or HTML)
From the investigations we did, it seems JSON:API supports (1), (2), (5)
and (6): it provides good guidance on the structure of resource URL naming
as well as the structure of the JSON object returned. There's a even PONAPI
on CPAN: Perl's implementation of a JSON:API server.
With respect to (3) [resource definitions], I'm finding the standard
extremely limiting: due to the structure imposed on returned documents,
references to other resources are always "top level" members. I mean that
the standard allows resources to be complex structures, with arrays and
objects nested in the definition. However, those nested structures can't
refer to other resources. As an example: if the lines of a GL journal is
included in the resource definition as an array, then the lines themselves
can't refer to other resources, such as accounts or batches. The standard
authors solve this by making the lines separate (nested) resources, which
are returned with the request for the journal. With this limitation, the
resources in the api quickly start to mirror the internal table structure:
GL lines need to refer accounts, invoice lines need to refer to parts and
inventory. Orders need to refer to multiple addresses (billing, shipping).
Journal lines need to refer to batches, payments, transactions, accounts,
etc. Most examples where JSON:API explains related and nested resources, it
takes a blog post with its comments. For that use-case, I understand the
structure chosen. However, in the use-case of a GL transaction, the
transaction *is* its lines.
On the topic of (7) [support for returning multiple forms of the resource],
I can be short: allowing any other mime-type on a JSON:API endpoint than
application/vnd.api+json is a violation of the spec.
Then there's (6) [supported by Perl libraries]. The good thing are: it's a
PSGI app that can be mounted in our URL space and building the JSON:API
server is work we don't have to do anymore. It seems pretty low on activity
though: its latest release was in Feb 2019, with a bit of prior activity
in Dec 2017, Feb 2017 and Sep 2016. The number of open issues is pretty
low: 13, but none newer than 2016; from the open issues, it's clear that it
doesn't support the full specification yet, because it doesn't support
paging of "referred to" resources. The issue that's been untouched the
longest (https://github.com/mickeyn/PONAPI/issues/45) calls for thorough
investigation before we jump on this module, however: "Creating a
repository is non-trivial" (a repository in PONAPI is where the data is
sourced from); apparently, implementing a data source is still a lot of
work, even though the framework is there. Another downside that I found
from PONAPI is that it doesn't pass the web-request context on to the data
provider. Normally that isn't a problem, likely, but for our project, where
the web request context equals database access, this is a big problem.
In short:
* PONAPI is incomplete and development is slow (but has releases on CPAN
dating back to 2015, so maybe it's mostly "done")
* JSON:API has -by design- some serious limitations in the way we can
define our resources, resulting - quite likely - in mirroring internal
table structure in the resource definition
* our desire to return various representations of the same resource
conflicts with the JSON:API standard
Given the above, I'd welcome your thoughts, opinions and reseach
contributions.
To address some (or all) of the short-comings of PONAPI, I've started
developing our own JSON:API server component. However, there is a lot of
work to be done to move that anywhere. I hope this mail will stir
discussion and provide direction on whether or not to continue on our own
JSON:API component, seeking contact with PONAPI or to move in a different
direction entirely.
Regards,
Erik.
The LedgerSMB development team is happy to announce yet another new
version of its open source ERP and accounting application.
This release contains the following fixes and improvements:
Changelog for 1.7.13 (to be released)
* Fix listing asset classes throwing an error (#4569)
* Solve failure to create initial user by requiring input (#4525)
* Fix links at the bottom of the CoA screen (#4568)
* Fix CoA export (ODS, XLS or XLSX) throwing malformed XML error (#4580)
* Fix downloaded reports missing extension (e.g. '.pdf') (#4584)
* Improve performance of deleting batches (#4449)
* Fix error thrown when opening reporting unit 'edit' screen (#4592)
* Fix transdate being NULL in journal lines from bulk payments (#4587)
For installation instructions and system requirements, see
https://github.com/ledgersmb/LedgerSMB/blob/1.7.13/README.md
The release can be downloaded from our download site at
https://download.ledgersmb.org/f/Releases/1.7.13
The release can be downloaded from GitHub at
https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.13
Or pulled from Docker Hub using the command
$ docker pull ledgersmb/ledgersmb:1.7.13
These are the sha256 checksums of the uploaded files:
2378fa5870bad1d6a2f3098f27e3842e7d77c6062b8b77fd19396ae455386be5 ledgersmb-1.7.13.tar.gz
ab8871c030f8fc458997e967591c65539fe9b46ddab1179b3de1d28327245ce2 ledgersmb-1.7.13.tar.gz.asc
Hello,
I've submitted a number of the Perl ports for OpenBSD.
Most have an OK. New imports require a second OK.
At some point that will happen.
I also submitted an issue with some suggested description improvements
to the author of Plack::Request::WithEncoding. He liked my suggestions
and that module is now at v13. There are some other dependency changes,
too, which might need to be addressed for building. Or maybe not
relevant.
Those building changes from Module::Build to Module::Build::Tiny have
now led me down the road to properly understnading those modules, so
that's going to take up a little of my time. Time that's probably well
spent.
I'll keep submitting new modules. I doubt that I'll get everything in
for this upcoming -release (OK, I'm sure I won't), but probably will get
things into -current after -release.
I'm having fun so far. I hope that everyone is doing OK right now.
Chris Bennett
