This is a bigger one.

For invoicing, we want to integrate with the eAccounting API for us to achieve two things, for the most part:

1. Ensure correct creation and detailed itinerary of invoices sent to participating personnel organisations
2. Ensure correct payment and subsequent data basis for payroll executions

The latter is particularly useful, as we want to reduce the dependency of organisation representatives on the financial administrator.

The documentation is fairly easily available on Visma's site, and despite how hard it has to get anything done on this, it is more for a lack of prioritisation than any technical hurdles.

Current wage reports are too simplistic, not very useful, and even more importantly almost entirely useless for verifying the correctness of an externally executed payroll.

A new view should:

• Show a total overview of the sum to be added before taxes
• A sorted list (over external wage IDs) of the personnel on the payroll
• How much each gets before taxes
• Listing each invoice it belongs to

Furthermore, that's just for the singular view, but the main overview should show a more complete overview of issues preventing a wage report from being created, and even more so there needs to be a mechanism for editing in some way. This is however not important to begin with.

This can lead to the invoice page failing to generate the required information, as there's suddenly an unexpected division by zero.

Amend the invoicing view for better safety, but unless a second booking type of free is introduced, no booking should be able to have a zero-cost sum.

Includes the work that goes along with improving the interface for actually entering this information in a useful manner.

• Any instance of a start and end time overwrites hours.
• If hours are entered, and then a start time, then the end time will be set automatically.
• Hours entered that do not match with start and end time will be changed in accordance with the actual duration.

The status bar show now -51, tried to close the periode with no luck. The error resulting in a that there is nothing that lets you end the month without having an event. This seems problematic during the summerholidays having 60 days off.

Maybe make an boolean checking for events, if there is no event then the status/counter start at 0 the 15th every month?

This involves either rounding the invoices data when it multiplied with each other, or using the Python format tools to correct it.

Initially I used

models.DecimalField(decimal_places=2)

which didn't help, oddly enough on postgres, which has been changed to

models.DecimalField()

in 2e17503 for the meanwhile. These details can be seen in spbm/apps/society/models.py.

Added by @thor.

IntegrityError occurs due to an attempt at violating the unique constraint for an event's shift and its worker.
Should be amended to provide a better error message, as the IntegrityError certainly shouldn't go away in itself.

Originally reported by: roht (Bitbucket: roht, GitHub: thor)

• Bitbucket: https://bitbucket.org/Aleksi/spf/issue/3

Originally reported by: roht (Bitbucket: roht, GitHub: thor)

• Bitbucket: https://bitbucket.org/Aleksi/spf/issue/1

We should take a look in to if there is possible to add this to the output file SPBM gives us after closing a period. And if norlønn can read somewhere yrkeskode from the file. I think the easiest way is to add a section on every worker that works at a event. To make it easier we should have a drop down so you could select if the person was "barmedarbeider", "barsjef" or "lydtekniker" or similar names.
Any thoughts, @thor ?

The new rules can be found her:
To download the list of type look here:

The language need to be more consistent, both in regards to mixing English/Norwegian, abbreviations and language typos.

Example of undesired behaviour:

I can´t seem to find out how to inactivate a worker. I have tried selecting one worker and clicking "edit", but the option of inactivating (or de-selecting "Active") does not exist.

For the payroll to be executed correctly, whoever executing it must be able to know whether statuses are recent enough to execute payroll.

Alternatively, they simply need to be stopped in the event they aren't.

See PR #8, which made a warm mess here due to lacking an integration test for the PDF-generation.

There's a lot of room for code improvement, even with the high amounts of things that have been fixed.

Thus, we should look at things like:

• pylint
• mypy

Or maybe packages of them, like:

• pylama

Code analysis and formatters too:

Unfortunately our OneToOneField usage limits each worker to one society, which means these workers that are active in more than one society have to be duplicated. This kills the normalisation.

• Change to ManyToManyField.
• Create a manual migration to migrate back to them.

Originally reported by: roht (Bitbucket: roht, GitHub: thor)

This could etiher be done rather easily by simply adding more fields to our Event model, but I'm not sure if that's the cleanest or most neat way to go about it.

Possibly each Event could have a OneToOne relationship with something such as Booking, but I'm afraid that might dilute the meaning of both.

Fields in consideration

Booker/renter

Who booked the event. Fairly easy, combination of name and contact e-mail could be added as two separate fields.

Start and end-time

These I believe to be essential to allow for some smarter calculations of money.
Each Shift would initialise with the start and end-time specified for the Event, but with the opportunity to add a positive/negative difference to both the start and end-time. If not, it's still something that can be added for the sake of completeness.

Is there possibly a need for breaks to be taken into consideration, @maxiix3?
What would make things easier for you, or do you have an entirely separate tracking system (like CYB, e.g. Jira or similar)?

Description

In the spirit of avoiding too many fields, it might be easier to simply have a description available.
Alternatively it's possible to have a custom-fields sort of setup that allows each society to add details they want, but that's quickly going down a dangerous road.

Booking information

Trickier. Should it only be an e-mail address? Any reference field? What for, if so? We're not invoicing the rentees, just the cellars, which have to do that.

• Bitbucket: https://bitbucket.org/Aleksi/spf/issue/2

The fields are not verified, and are used solely as a form of help to keep data in one location, even though it has to go into the wage system as well.

This field should verify that it is a valid bank account number, so that it can be trusted.