Sales forecast is missing
S
Stahl, Friedemann
The presentations of payment plans and liquidity do not correspond to the sales presentation (sales revenue presentation), which is necessary for a GmbH and is used for planning. Turnover at a GmbH is not determined by the receipt of an amount, but by the date of invoicing. This also applies accordingly to input tax deduction. The input tax must be paid on the date of invoicing and not on the day the invoice is received.
In Projo, the invoices to be issued are marked in green under the payment plans, in yellow the outstanding invoices and in red the due ones. Under Liquidity/Liquidity Access, the invoices to be issued are also shown in green under the current month, the outstanding invoices in yellow and the invoices due in a separate column. Both representations do not include the term turnover.
What is missing is a list of revenue planning, similar to that of liquidity planning. This should correctly list past sales (by invoice date), for which the data from the invoices issued must be used. For the future, the data may come from the payment plans, but with the forecast date of invoicing and not including the payment destination. Sales for the current month would then be mixed. A presentation with past months, the current month and future months (similar to liquidity planning) would be great!
Under Office/Outgoing Invoices, you can select each month by date and the sales presentation for the previous months is then correctly displayed. However, nothing is available there for the future and no sales forecast is possible. A separate filter would have to be set for each month.
Depending on whether an architecture or engineering firm is a GmbH or not, it should be possible to adjust the calculation methods by checking the settings.
Arne Semmler
Merged in a post:
Invoices issued are missing
S
Stahl, Friedemann
Both payment plans and liquidity/liquidity access lack issued invoices after the project has been archived, i.e. completed. In some cases, this significantly distorted both payment plans and liquidity planning.
While invoices from the current month are only displayed under Liquidity Access, invoices from the previous 5 months can still be displayed in the payment plans. The sums both under access to liquidity and the payment plans are therefore incorrect. There are even major errors with payment plans over the past few months, as all old invoices are gone when archived to today.
Here, it would be very useful to also list archived projects if invoices were issued within the last 5 months (for payment plans) or if invoices were issued in this month (for access to liquidity).
Arne Semmler
Hello Stahl, Friedemann, I can't quite understand why archived contracts should appear in payment plans. After all, you can no longer expect payments here once the contract is archived. Payments made from archived contracts, including payments made from archived contracts, are taken into account in the past. Invoices from archived projects are also displayed in the invoice lists. Payment plans from archived contracts for past and future, on the other hand, are hidden, as we assume that you check before archiving whether all payments have been received (or no more are expected, i.e. outstanding items can presumably no longer be collected - if you are orderly, you would of course set them to “disputed” or “booked out”).
S
Stahl, Friedemann
Arne Semmler: 1. Payment plans should only include payments for archived contracts where payments are still pending (my wish). Otherwise, a new definition of the end of the contract would have to be defined, e.g. “completed.” But then you must first select “completed” and then, when the payment has been received, “archived”. That is more complex.
- In the case of disputed payments, archiving could take years, e.g. if proceedings are ongoing.
- The payment plans also display the last 5 months. There, payments for archived orders are then omitted and as a result, the payment plans are no longer correct. Example: If an order has finally been paid, it is archived and then the sum of the payment plan for the month in question is incorrect. For monthly invoices, all totals shown are incorrect.
- Our project managers call up their abbreviation in the payment plans and look at the sum. You can therefore no longer calculate the total amount if projects have already been archived. However, this monthly turnover, which is shown here, is very important. Because this is where invoices created, created and paid are displayed in individual totals and total amounts. I don't know any other place in Projo where you can easily read the invoices according to the subdivisions mentioned above. That is a huge advantage.
- Liquidity access shows receipt of payment from the ongoing project, but no longer from the archived project in the current month. The future months are right, as there is nothing more to expect from the archived project. But the current month is not correct.
Arne Semmler
Stahl, Friedemann: Thanks for your detailed explanation with the background. We actually assumed that projects would only be archived when no more payments were expected (as far as I know, that's how most customers use it). The archive flag is also sometimes important in order to “quiet” migrated projects from old systems that were only insufficiently maintained so that they do not falsify the current liquidity planning or payment plans - that is also the reason why I would probably find it a bit difficult to get more data from the archived projects to the surface without further ado.
By the way, payments from archived contracts are actually also displayed in liquidity planning with a past. But as a result, not what is yet to be expected in the current month. If you archive so quickly, the ad is weird. In fact, I always handled it in my office in such a way that I differentiated between closed, stopped, approved and archived. And there was a policy that only stopped and accepted projects could be archived (and, of course, acquisitions for which you no longer expect an order). Here you could of course click on (possibly configurable?) Set blocks that prohibit archiving projects that still contain open invoices (and not signed out or marked as disputed).
Overall, I would currently rather think about producing the evaluations/ads you have missed elsewhere or improving or even partially automating the workflow of contracts from finished to accepted to archived. Would that be a way?
S
Stahl, Friedemann
Arne Semmler: Yes, great! That would be one way! Maybe you can also take a look at my feature request “Sales forecast is missing” again. https://feedback.projo.berlin/feature-requests/p/umsatzprognose-fehlt
In contrast to liquidity access and payment plans, a sales forecast would then correctly include the turnover for the past, the current month and the future. Everything would then fit and there would be no need to change liquidity access and payment plans.
S
Stahl, Friedemann
Addition to the last paragraph: Instead of “whether an architecture or engineering office is a GmbH or not”, it should be better read “whether an architecture or engineering firm is subject to accounting or not”
A
Angelika Rehe
As far as I know, input tax only has to be paid on individual and final invoices on the date of invoicing. In the case of advance invoices (and thus “down payments” on a service that has not yet been completed), it is only due upon receipt of payment (so-called actual tax).
See target/actual taxation: https://datenbank.nwb.de/Dokument/269694_181/
Arne Semmler
Angelika Rehe: That is also my level of knowledge.