Development ideas

Hungarian Payment Request - middle priority

In many cases, Hungarian practice requires that only a specific amount of money is claimed. In some cases, an advance invoice must be issued after the amount has been received, and sometimes a final invoice must be issued after the amount has been received. The current practice in Odoos is not in line with Hungarian practice. It would therefore be useful if a given pro-forma could be converted into an "invoice" either automatically or manually and a different solution would be useful then the current one

Intermediated service - middle priority

Intermediated services (purchased from another company and resold unchanged) must also be reported in the data return or shown on the invoice as including an intermediated service

Continuous settlement invoice - middle priority

In the case of a continuous invoice, the period for the entire invoice must be entered in the NAV data reporting (earliest start and latest end date). Thus, in addition to the current Odoos solution, you should also be able to enter a period for the entire invoice and display this in the data entry
invoiceDeliveryPeriodStart, invoiceDeliveryPeriodEnd, periodicalSettlement

Storno invoice - high priority

Correction and amending invoices are different in accounting and reporting terms, so it is necessary to distinguish between them

Tangible asset management - accounting

Two types of depreciation at the same time (TAO and Accounting Act).

Also often used is depreciation on a pro rata basis, which can also be useful to implament

Some more info

Delivery_date - high priority

Delivery_date makes sense for supplier invoices not only for outgoing invoices, so it should be shown there too

Currency display - medium priority (without the warning)

Display HUF/EUR exchange rate instead of EUR/HUF exchange rate (under currency, now it is eur/huf which is not so user friendly). Also, Odoo does not calculate with the right exchange rate, we have already talked about this
Display the date from which the exchange rate is from
If the exchange rate is not today's, a warning that the exchange rate may need to be updated

Car/ship sales - low priority

There are additional fields to be filled in the invoice line items

Certificate of Performance - middle priority - ask other partners

It is a common document used to confirm the billability of a draft invoice to the customer before the invoice is issued.

Automatic NAV invoice upload - wont implement

Under Hungarian law, the invoicing software must automatically upload the invoice to the NAV OSA system as soon as possible. In Odoo, this is currently a manual operation, which can be switched off for each invoice.

NAV invoice verification - low priority

Sometimes there is a question as to whether all invoices match the information stored at the NAV, a wizard can be created to check the data and verify the period entered:

The invoice exists in NAV but not in Odoo
The invoice exists in Odoo but not in NAV
- the invoice exists in both places but with different data content
- gross total is incorrect
- customer different
- VAT amount is incorrect
- different date of execution
- different date of issue
- number of line items different

Budget check - low priority

If the taxpayer is exempt (max HUF 18million per year), please warn if this amount is exceeded

Also, e.g. cash payments to 2 companies per month or per transaction max HUF 1.5 million, above which both companies will be fined

This "warning" list will be extended

Customer and product data protection - wont implement

At the moment of issuing the invoice, save what the buyer and seller's contact details were and always use this when printing the invoice image.

The workflow is important:

I issue an invoice for the wrong buyer data
overwrite the business card with the correct data
(I even issue an invoice for the good customer data)
I should be able to issue a cancellation invoice for the wrong customer data

In case of a storno invoice, I need to be able to use the previous customer data and display everything there, but in case of a modify invoice, I need to be able to correct the customer's data, in which case I need to use the "new" customer data

Invoice download management - wont implement

Tracking whether or not the invoice has been verifiably received by the customer. The best way to achieve this

is to not sending the invoice by e-mail
all customers should go to the portal view
press the download button there
save the date (and IP address) in a separate field when
- they opened the portal view
- downloaded the invoice
filter and search for invoices that have already been opened / not yet opened

Bilingual invoice - low priority

The NAV only accepts invoice images in a few languages (e.g. the buyer is Indian, the buyer's language is set to Indian to make the portal view look like that, but the invoice image cannot be Indian, but Hungarian is no good either, Odoo should print it in English instead).
A good solution is a bilingual invoice image, where you can have Indian+Hungarian, or Indian+English. All captions should be double in two languages.

CashBox Management - low priority

Strictly numbered cash movement, with some extra information and a tidy print view.

Strictly numbered cash report

More info

Electronic invoice - generally implemented

I think there's a new single EU regulation coming out on e-invoicing, so I'm not sure if we need to work on that at all.

Excise tax - wont implement - partner needs implementation

Accounting and management of excise goods.

This also requires the implamentation of a tax warehouse and/or an excise licence, as they are interrelated.
The tax warehouse keeps strict records and must submit daily reports to Nav on stock movements. For tax suspension shipments, EMCS is mandatory.

A license is also required to sell excise goods and an excise return must be prepared monthly based on the quantity of excise goods sold.

Record extended data (invoice line) - low priority

Additional data can be coded per invoice line, e.g. order number, etc.

Basically, we need a new table where we can add the data types and a subtable for the invoice rows.

"EKÁER" Electronic Public Road Transportation Control System - smalles implementation - middle priority

Hungarian Goods Transport Register system, for specific transports, the road transport must be declared in advance and the EKÁER identifier must be included on the invoice.

The EKÁER field is included in the extended invoice item fields.

Automatic tax number check before issuing an invoice - good to go

Before issuing the invoice, run a tax number check, which NAV provides (API).

It is much better to check it in advance than to have it rejected by the NAV afterwards and not allowed to be sent up, because then the allocated serial number is "lost" and the accountant has to report the data.

Automatic cash rounding selection - internal talk needed

Cases of cash rounding:

Cash, HUF: 5.00
Transfer, HUF: 1.00
*, EUR: 0.01

In principle, the system should automatically know which cash rounding to apply. According to the Hungarian rules, the invoice should not be rounded per line item, only the total amount of the invoice. Therefore, the correct setting is to round HUF currency to 0.01 and apply a cash rounding principle to all HUF invoices depending on the payment method.

Recording of vendor bills - high priority

NAV automatic incoming invoice

manual recording of all fields(example: delivery date), etc.

Different EU tax number - middle priority

number. Alternatively, there are businesses that do not have an EU tax number but do have a valid Hungarian tax number, which is why VIES checks do not give a correct answer to the question of whether the customer's tax number is valid.

Hungarian: 12345678-1-12
EU: HU12345678 but sometimes HU87654321

Proof of purchase of agricultural products / purchase ticket - low priority or wont implemented

It is a kinf of self-bill that is issued in place of a pre-farmers and can only be used for specific taxes. The printout image is a little different from the original, but more because of the extra pre-farmers data.

Self-billing - like wont implement, but think about it

An incoming invoice issued by us, the customer, instead of the issuer. So, in effect, an incoming invoice, which

we assign a serial number (there must be a serial number object per supplier)
we specify the data content
when printed it should look as if it was sent by the customer
we also have to send it to the NAV

In realization we could have a log dedicated to a supplier and then the serial numbering is solved and the log should be able to save the NAV technical user.

Environmental product tax - middle priority

The calculation of the product charge depends on the weight of the item and is therefore not a simple tax object. In addition, the monthly statement should indicate how much of each product charge is payable.

Cases:

the product charge must be shown on the invoice
the product charge must be accounted for by Odoo for the calculation of the monthly return, but it does not have to be shown on the invoice and the amount of the product charge must be included in the net price
on a supplier invoice, I receive the product with a product charge, but I sell it to the customer without one
on the supplier's invoice I have X amount of product charge, I sell the product at a higher price, but I have to invoice X amount of product charge
In Odoo, when recording the price of the product, the super net may be given (product price + product fee + VAT), but it may be the net with product fee, and the product fee and the real net should be charged back, while VAT should be charged on top

Deposit and Return System - DRS

For each item sold, there must be a corresponding item (usually HUF 50) in the account, and they must move together. This is only for certain packages. It is for certain products where this amount is collected after the packaging.

Collective invoice - middle priority

An invoice where the date of settlement is not defined for the invoice as a whole, but per line item. Typically a monthly invoice where the daily movement of goods is recorded item by item.
For example: a café does a monthly settlement with a pastry supplier, on Monday they ask for 10 pastries, on Tuesday they ask for 12 pastries, on Tuesday they have 3 pastries left over and send them back, on Wednesday they ask for 6 pastries, etc. etc. According to Hungarian rules, an invoice should be issued for each day of performance, but with a summary invoice where they can record performance by item, this can be done with one invoice per month.
This requires agreement with the partner if the settlement is on a different day. Alternatively, only invoices belonging to the same tax period can be "combined"

QR code payment (qvik) - high priority

Hungarian QR code instant payment

https://mnb.hu/letoltes/mnb-afr-qvik-brandbook-2024.pdf

e-Receipt (Odoo 20+)

This will be the new PoS ordering system, whereby QR code-based receipting will be possible.

The new regulation will come into force from July 2025

Issue of an advance invoice for payment - maybe 20+

According to Hungarian rules, I can only issue an invoice for the advance payment once the money has been transferred or has appeared in the bank account.
The date of payment is the date of receipt of the money.
Amounts related to the advance invoice (not yet finalised with a final invoice) must be recorded under a separate general ledger number, because it is legally considered as a loan.

NAV OSA XML as attachment - high priority

The NAV OSA XML 3.0 is why not attached to the PDF?

Invoice with cash payment method - low priority

There are some special rules for cash invoices:

I can only issue a cash invoice when I have received the money, so if I issue a cash invoice, I have to book the payment immediately
The deadline for payment of a cash invoice can only be today - as by law the invoice must be issued immediately after recieving the cash