For now we will allow the member to simply fill in mandatory fields with "-". For technical reasons they need to fill in an e-mail address. It is ok to use a throw away address though (e.g. https://www.mailinator.com/).

If you create an account with Zynatic (without real personal info) you can trigger all of our payment options there.

If you pay with Swish, Paypal or a debit card some info will be stored in our bank and/or the membership system.

If you choose "Pay later" you can get your membership number via the automatic e-mail. You will have to contact us to find out how to pay your membership fee using this number.

@Gitta You are active in another organisation which allows anonymous membership are you not? Do you know if there are any tax office related issues to this?

In T230863, @Lokal_Profil wrote:

... this could mean that one member has more than one vote.

Note that this is already possible by being the proxy for multiple organisations which are members. Might be worth plugging this loophole to avoid the "one person controls >25% of votes" clause of the 90-konto rules.

Postal adress might be necessary, according to this:

Innehållet i en faktura
[...]
En faktura ska innehålla uppgift om både säljarens och köparens namn och adress (11 kap. 8 § 5 ML).
[...]

I haven't been able to find anything about there being exceptions for individuals.
Edit: Here's information about a possible exception when you send invoices to individuals. But they refer to the demands on verifications in Bokföringslagen, and there I was only able to find that we need to know who the other party in a transaction is, but not what it means to know who they are (5 kap. 7 §).
Edit 2: Maybe it isn't an actual invoice, since it isn't in exchange for a given service, they pay for the coming year. Opad has explained that we don't need to save the invoices we send for membership fees if they are not paid, and we don't save the paid invoices with the bookkeeping (but it's good that we can access them). If what we are sending are not actual invoices, we can change the heading "Invoice" to something else in Zynatic.

According to a reply from Skatteverket, if we send an invoice we need to have the recipients address on it. I've put the answers here.

Here's an organisation who asks their members to pay the membership fee and include a paying-in form without calling it an invoice: https://farr.se/sv/aktuellt-a-press/notiser/1546-farr-medlem-kolla-din-mailbox

Here's another example (but without any attached document): https://www.orsask.se/EGNANYHETER/medlemsavgifter20192020

Here's information about "simplified invoices", which the membership might be considered as but probably not. Förenklad faktura

@Evelina-Bang-WMSE @Maria_Burehall_WMSE
While we never got a chance to look at it before the reminders were sent out I think it would be good to have a quick think about this one at some point next week (i.e. relabelling it from Faktura to e.g. Inbetalningskort and reconsidering making the physical address mandatory).

In T230863#5926440, @Lokal_Profil wrote:

@Evelina-Bang-WMSE @Maria_Burehall_WMSE
While we never got a chance to look at it before the reminders were sent out I think it would be good to have a quick think about this one at some point next week (i.e. relabelling it from Faktura to e.g. Inbetalningskort and reconsidering making the physical address mandatory).

I've sent an invitation to a meeting. Meeting cancelled, we'll try and find a new time when everyone's at the office.

@Jenny_Brandt_WMSE @Jopparn We should revisit this again.

In short we only require physical address in the membership system (and thus also for the Scrive form) because of a percieved legal necessity of this data for invoices. By renaming Faktura -> Inbetalninskort this requirement could probably be dropped.

To actually do either of these we would have to ask Zynatic to implement a) A configurable text field on Invoices (to change the actual text), b) a setting for not having physical address being mandatory.

Before making such an ask we should however first decide if physical addresses is indeed something which we are ok with being optional.

Adding this under T368885: ☂ Implementation of new CRM to evaluate: if what we are collecting today is compatible with the new system, if there are any additional bits of information which are required/desired in the new system.