[16.0] PMS refactor roadmap

[jesusVMayor]

At Roomdoo we've been analyzing the current state of the PMS and have been working on a roadmap to refactor the PMS modules, with the main objectives of simplifying the code and making it more compliant with OCA standards. In this issue, we will be updating our internal roadmap.

• General

  • Remove obsolete fields.
  • Review computed fields and simplify.
  • Separate in different modules specific functionalities.

• res.partner

  • Remove obsolete fields.
  • Simplify all the computes who takes the values from checkin.partner. ([16.0][REF] replace res.partner computes with inverse function in checkin.partner #353)
  • Remove some fields like lastname2 from the pms module, instead, we will create a module who adds it to the pms for the localizations who needs it.
    • lastname2: [16.0][REF] Split partner fields in different modules #356
    • id_numbers: [16.0][REF] pms partner identification #362
  • Remove residence address fields: [WIP][16.0]pms: refactor res partner residence #361
  • account related fields
  • agency related fields
  • pricelist related fields

• multi_pms_properties

  • Analyze the need of this module ( [18.0] Refactor & Split Proposal for PMS #349)

• pms.availability

  • Simplify availability calculations

• payments

  • Allow to select journal and payment method in payment wizard. Being more consistent with odoo invoice register payments. [16.0][REF]pms: move payment from journal to payment method line. #392

• Invoicing

  • Remove self bill: Very specific functionality, it doesn't make sense for it to be in the base module or the OCA. [16.0][REM]pms: Remove self bill functionality. #366
  • Remove autinvoice: Highly customized feature that adds a dependency to queue_job [16.0][[REM]pms: Remove autoinvoice functionality #367
  • Fix payments to reconcile widget: [16.0][FIX]pms: Fix account type in payments to reconcile widget compute. #371
  • Remove autoreconcile folio payments: Another customized feature that don't make sense in the base module [16.0][REM]pms: Remove autoreconcile functionality. #372

[jesusVMayor]

Refactor res.partner computes #353

[jesusVMayor]

Make pms base module independent of partner_second_lastname module #356

[jesusVMayor]

Remove residence address fields [WIP]: #361

[jesusVMayor]

Move id_numbers into a new module #362

[BitStab]

After 4 intense weeks of development i'd like to give you some insights of my opinions, what could be changed/optimized in the refactoring.
i won't upload my latest developments public on github yet, because they ar WIP and i'm working on our local gitea sc, but i can provide some details if you'd like.

imho it should not be splitted into too many modules. i can understand the necessity of splitting it up and refactoring, especially in terms of migration it's an absolute plus to reduce the amount of code to review per module and also in terms of usability in different scenarios it can be more convertible into better fitting solutions.

for my specific implementation i tried to create modules per functionality and some bridge-modules for existing oca modules (f.e. for fiscal_epos_print - fiscal-printer module for POS app, and the pos_pms_link).
i've also done a website-booking-request module for the frontend, as well as a pms_amenity_capacity_module.
The amenity capacity module is for things like sofa-beds - amenities already existing in the rooms which can increment the capacity of a room in case of necessity. Btw those amenities have also a product related to them and a price if applied to the reservation (if exceeding the normal capacity of a room). Therefor i have changed the booking engine as well and i don't find the code for the availability check too complex either. Imo it's not even deep enough - there should be a stepping recursive function of replanning reservation distribution on the available rooms per room-type to get the maximum for non confirmed room-assignments.

Maybe it could be better to have some kind of "feature-picker" to activate or deactivate certain functionalities. For example the existing pricelist modifications, where the status quo is to have a board-service per room-type price. But in fact it's overcomplicating things and less transparent for the user, where the pricing is actually coming from.
I reverted that change for my implementations and have gone a different route:

• Stay-product + Room type (i'm calling it "residential unit" to make it more compatible to apartments and rooms) + Board Service line products + local tax

All those are coming from the pricelist. To see the room types (product.product not sellable) i added the type "room type" as a selection on the pricelist item entry wizard. So the pricelist manages the products on the board service lines directly and the board service itself doesn't differ in price per room-type.
If someone books all inclusive i'd appreciate to have an automatic switch of the applied pricelist to make any consumptions being with 100% discount, or to have a field to set the applicable discount on billable consumptions/services. the pricelist switch would be more versatile, so you could apply different discounts and have f.e. spa discounts of 30% but drink discounts of 100%

I'm also no big fan of the flags on the products (for example overnight stay adult you have to set per person, per day, consumed before/after the night). If you ask me, it should be part of the board service to pick the stay-type including the board service. So you would ending up with Board-Service model having the products for the stays (splitted by adults and children) and the lines for the services included. One spot to manage the base-data of the possible accommodation-types.
This would split administrative work (pricing and product-management) from receptionists or property-managers work.

The hops from app to app (even if the menu inside pms-app is there) someone has to make inside odoo is not very user friendly. The different looking UI in product and board-service can be confusing for the user and lead to bad use of your basic idea.

So resuming short what things should be taken on to refactor with a clear plan:

• Board Service, Room Type, Product-Template and Pricelist, we need a explicit decision if it's the right way, or the wrong way how it's done actually.
• Agency-related parts should be totally a separated module (as already planned i assume?)
• Cancellation rules need a rework to make them easier to understand for the user and more flexible, invoicing strategy has no option for goodwill in case of cancellation
• Starting-Point for the user should not be a list of reservations. Better to start on the timeline. The timeline should have also the name of the Customer, not only folio/reservation number. And where is the colorization and legend for reservations and timeline?
• Check-Ins: There should be a configurator to pick the fields which should be required to be filled (or even what should be shown). Not any property has the same amount of data requested and too many fields to fill make usability worse.
• the Folio and Reservations should have the possibility to be archived, especially the cancelled ones. No big deal, only applying the odoo standards with some failsafe-proofs