Feature Requests

Acquisition projects should be able to allocate expected revenue and order probability. If you add a schedule, the potential income was included as a separate “light green” category on the revenue side of liquidity planning (can be switched on and off). The calculation would be as follows: Order amount x probability (in percent) = potential revenue. For example, a service with 100,000€ order value of an acquisition project with a 10% order probability in December 2023 would appear with 10,000€ on the credit side of the liquidity - obviously deducted from the services actually commissioned.

When it comes to the overview of payment plans, I would like to see 2 adjustments: Summarization of all amounts (paid, disputed, due, pending, draft, pending) in the fixed line at the top Filtering or grouping options for project groups

Personnel costs in the Liquidity->Liquidity Expedition view initially represent the total amount. The composition should be indented and broken down into personnel AG gross (balance from contract information), additional payments once (balance from contract information), additional payments recurring (balance from contract information), personnel planned (direct entry here). In each monthly column, pay attention to the respective drill down.

In liquidity planning with past (which can be activated via Settings->Costs->Liquidity planning with past), the “account balance”, i.e. the balance in “net”, is displayed. Here, the difference between input tax deduction and advance sales tax payment should be displayed as an additional line and thus also the balance in “gross”. This also makes it easier to maintain the account balance, as the “gross” balance would then be able to relate to this.

In the office area under Costs, “Analyze Overheads” tab, January is missing, see screenshot.

Tags can be defined and assigned per project phase (this was the following Canny point https://projo.canny.io/feature-requests/p/tags-definieren-zb-lp1-lp2-und-pro-leistung-vergeben ). These tags should also be evaluable: 1) In the project (i.e. across all contracts, e.g. under Project Controlling), the following should be visible per day: total order amount cumulative direct costs cumulative (own) costs cumulative third-party service costs Outcome Question: If you want to evaluate ongoing projects, how should the result be calculated? By level of performance? 2) per day (e.g. LP5) you want to see a list of all projects with this tag and exactly the same columns as under 1). 3) Performance period—dependent evaluations: You want to see the following evaluations across projects: Overview of the result per performance day, e.g. in 2021 (i.e. how did LP1 go in 2021?) , with drill-down option. Requirement 3) is much more complex because projo must first set up an internal warehouse. Therefore, this Canny point refers to 1) and 2) for now.

The look & feel of uploading the payroll journal should be the same as the (new) BWA upload. The file should be saved and you should be able to read it again. Records that are not uploaded should be set back to 0€.

The Control Total column in Liquidity Access, for example, shows how much the payment plan deviates from the order amount (difference to the order total). This makes sense for manually generated payment plans. For automatic payment plans, however, this figure is only partially meaningful. Projo should therefore proceed as follows in future: In automatic payment plans (depending on time planning), the checksum should form the sum of the figures “Order sum of services without a date”, “Payment plan (in the past)” and “Difference to order amount.” With manual payment plans, on the other hand, only the “difference to the order amount” should be included in the checksum.

In liquidity planning (regardless of whether with or without a past), the balance of the control sum for all unarchived contracts should be displayed in a second, fixed column. The checksum should also be displayed in liquidity access (there is currently no past in liquidity planning, but not in MIT).

When entering the costs, it should be shown field by field whether it is an automatically adopted value or a value that has already been changed manually.