The LedgerSMB development team is happy to announce yet another new
version of its open source ERP and accounting application.
This release contains the fix for a dataloss issue that was reported
to us two days ago. The issue concerns the deletion of batches, which
causes loss of information linking payments to the transactions being
paid. This issue is present in all 1.8 releases before 1.8.25.
Additionally, it contais the following fixes and improvements:
Changelog for 1.8.25
* Fix batch details printing throwing a PSGI error (#6325)
* Fix saving of AR/AP vouchers throwing errors (#6327)
* Fix account initialization in tax calculation module (#6335)
* Require gain/loss account setup to post FX transaction payments (#6360)
* [DATALOSS] Fix deletion of any batch removing payment information (#6368)
For installation instructions and system requirements, see
https://github.com/ledgersmb/LedgerSMB/blob/1.8.25/README.md
The release can be downloaded from our download site at
https://download.ledgersmb.org/f/Releases/1.8.25
The release can be downloaded from GitHub at
https://github.com/ledgersmb/LedgerSMB/releases/tag/1.8.25
Or pulled from Docker Hub using the command
$ docker pull ledgersmb/ledgersmb:1.8.25
These are the sha256 checksums of the uploaded files:
185d12a8f4e75b8c519042b98e0c7e2142193b2c3c4874fc2eaea193c61f2f24 ledgersmb-1.8.25.tar.gz
c5438af7ccddda0aa0d485df6d077624df5b65c2a436df041023b19b19dca76e ledgersmb-1.8.25.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.38
* Fix batch details printing throwing a PSGI error (#6325)
* Fix saving of AR/AP vouchers throwing errors (#6327)
* Fix account initialization in tax calculation module (#6335)
For installation instructions and system requirements, see
https://github.com/ledgersmb/LedgerSMB/blob/1.7.38/README.md
The release can be downloaded from our download site at
https://download.ledgersmb.org/f/Releases/1.7.38
The release can be downloaded from GitHub at
https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.38
Or pulled from Docker Hub using the command
$ docker pull ledgersmb/ledgersmb:1.7.38
These are the sha256 checksums of the uploaded files:
fcb593db1760ad37f1d428f657fecb4a34361bf62db8e320b271128d666a0969 ledgersmb-1.7.38.tar.gz
91697911649244be9628261914279dd8691de1d3e043904ca50a68388d678c07 ledgersmb-1.7.38.tar.gz.asc
With permission of Johann, I'm forwarding the mail below to the public
mailing list for inclusion in the list archive: There are a number of
answers which might benefit other (potential) users.
---------- Forwarded message ---------
From: Erik Huelsmann <ehuels(a)gmail.com>
Date: Sun, Jan 2, 2022 at 10:37 PM
Subject: Re: Questions
Hi Johann,
Thank you for your patience while you waited for my reply. Christmas
and New Year's are traditionally busy times and this year even more
so.
> I have attempted to configure your program. I include some questions
> (some daft ones - but rather safe than sorry) that I would appreciate
> some answers on before embarking on a more comprehensive evaluation.
No problem. Happy to answer. Before I do, one question though:
generally I tend to handle as many replies as possible through public
channels so others can benefit from the replies. There are cases where
details can't be shared. I do handle those through private
communications channels, including private e-mail. These are very
often linked to (paid) support requests though. Is there a compelling
reason to stay private? Or can we share our conversation with other
(potential) users for their benefit?
> Which version is the most up to date and stable one for such an
> evaluation as I would not like to get bogged down with testing at this
> stage?
Depending on which features you want to use, I'd advise you to use
1.8: 1.9 has had a few changes where people are currently experiencing
problems when converting orders to invoices. Other than that, I'm not
aware of any problems with 1.9 which would prevent you from getting
your testing done.
> Questions:
> 1. As no COA for my country is available I had to create a new Chart of
> accounts from scratch.
> I also had to specify the currency as ZAR
> The tax tables were also created with corresponding tax accounts in the
> GL.
> Are the above sufficient to have a program fully functional for
> evaluation or are other country
> specific modules also required to be installed?
There are no further requirements to use the application for your
country. However, other configuration may be required to take
advantage of certain functions in the application: In order to track
outstanding receivables and payables, you need to create "Contacts"
and within them "Accounts" as one example.
> 2. Must the user entering transactions be listed as an emplyee?
Currently, in order to be able to log in, you need to create an
employee for every user. That's correct. (It's something which I want
to change, but it's how it is today.)
> 3. When creating a part I would assume that the choice exists to enter a
> mark up% or a selling price
> but not both as these could in some instances contradict each other when
> cost prices change?
That does sound how it should work, but I just ran some tests and it's
not how it actually works: the markup is calculated from the last cost
and the sellprice: I entered a sellprice of 12 and then purchased at
8. When I returned to the part definition screen, the markup showed
50%.
> Furthermore must the list and selling prices be vat inclusive?
That's not how I use the application. There's a checkmark on the
customer which indicates "Tax included", but I think it's impractical
to use it on customers (on vendors it's a different story), because
then sometimes the prices will be regarded as being VAT inclusive and
on other customers, they will be regarded as VAT exclusive, because
you can only register one sellprice (not one with and one without VAT;
nor can you indicate in the part that the price is VAT inclusive).
> 4. I was able to generate tax inclusive and exclusive Purchase Orders
> depending on how the
> Vendors were configured. Is this observation correct or does the program
> only allow for tax
> inclusive processing. Pardon this dumb question. I really hope it is
> permissible!
This is a completely correct observation.
> 5.When creating GL accounts I also included Heading accounts. Presumably
> these will reflect the
> totalled balances of the child and other heading accounts of which it is
> a parent?
That's correct. You will find that both for the PnL and the balance
sheet reports the headings will be presented with the totals of the
children.
> 6. When recording a purchase several workflows seem possible:
> 6.1When no warehousing or goods – receive work flow is present an
> invoice can be generated from
> the PO?
That's correct: you can generate an invoice from the order directly
for the amount received. Once you post the invoice, items will be
added to inventory (without a specific warehouse). The number of items
entered in the "Rec'd" column will be taken out of the outstanding
order.
> 6.2 An invoice for a vendor can be generated from within the AR menu
> where a PO number is
> required in the input?
A specific PO is not required in this case. The goods will simply be
added to the inventory when the the invoice posts. To be explicit:
when you *do* enter a PO number, this workflow leaves the PO untouched
-- it does *not* reduce the number of items outstanding in the PO.
> 6.3 When using the goods receive workflow (Goods – Transfer) which is
> useful for a picking list
> workflow to be included, is it only permissble when a warehouse has been
> defined or can it be used
> without the existence of any warehouses? (as would be the case for a
> small business)
The Goods > Transfer workflow is intended to move stock between
warehouses. If you want to use picking list type workflows for
shipping to customers, I would recommend using orders and the
shipping menu (Shipping > Ship for customer shipments ; Shipping >
Receive for vendor shipments).
> 6.4 When is the Stock account in the GL updated – only once an invoice
> for the vendor has been
> posted?
Yes. And it's decremented when the inovice for the customer has been
posted. I've contemplated making a difference between "being in stock"
and "being in inventory" where the former would be "available in the
warehouse" and the latter "accounted for in the balance sheet". But I
think that's too complex for most smaller businesses, although, if you
think differently, I'd love to hear your opinion too.
Regards,
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
--
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.9.6
* Populate more fields in batch approval details report (#6271)
* Fix error when posting an invoice created from an order (#6280)
* Fix saving invoices and transactions as part of vouchers (#6327)
* Fix printing batch details from batch details approval screen (#6324)
For installation instructions and system requirements, see
https://github.com/ledgersmb/LedgerSMB/blob/1.9.6/README.md
The release can be downloaded from our download site at
https://download.ledgersmb.org/f/Releases/1.9.6
The release can be downloaded from GitHub at
https://github.com/ledgersmb/LedgerSMB/releases/tag/1.9.6
Or pulled from Docker Hub using the command
$ docker pull ledgersmb/ledgersmb:1.9.6
These are the sha256 checksums of the uploaded files:
8748d005601557a690898758c06a3c7a88c3b3130ca778a53ade630a46e1a342 ledgersmb-1.9.6.tar.gz
97fb3bbfa6ce1cc4a52eab767bf65ec7780935132263db73ab3c45eee45de920 ledgersmb-1.9.6.tar.gz.asc
