Repository navigation
[16.0][IMP] pms: derive room type prices from another room type - #466
Open
DarioLodeiros wants to merge 1 commit into
Open
DarioLodeiros wants to merge 1 commit into
DarioLodeiros wants to merge 1 commit into
Conversation
Properties often price their room types as a fixed offset of a main one (e.g. Superior = Double + 10, Family = Superior + 20) and have to keep the daily items of every room type in line by hand. A room type can now take its price from a base room type, varied by a fixed amount or a percentage, with an optional rounding and the pricelists it applies in (all of them by default). The derivation is a fallback of the pricing engine: it only applies on the days a pricelist has no rule at all for the room type, so an item of the derived room type overrides it on its dates and category or global rules keep winning. The base room type is priced by the same pricelist with the date and the property of the stay only, so derivations can be chained and whatever depends on the guests applies once, to the derived room type. The derivation is configuration, read as stored whatever the user pricing can access: a restriction to pricelists of properties out of their access must not read as empty, i.e. as all the pricelists, or prices would depend on who computes them. Reservation lines now pass their pricelist when pricing a night with no rule, so they get the derived price as well. With no room type selected, the massive changes wizard leaves the room types deriving their price out of the price changes, keeping their overrides, as an item of their own would stop them from following their base.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Properties often price their room types as an offset of a main one (Superior = Double + 10, Family = Superior + 5 %) and have to keep the daily items of every room type in line by hand.
What this adds
pms.room.typegets Price Derived From (base room type), a variation (fixed amount or percentage), an optional rounding multiple for percentages and the pricelists it applies in (empty = all of them). Loops, chains deeper than 10 levels, percentages ≤ −100 % and incompatible properties are rejected.pms.potand Spanish translations.Nothing changes until a room type is configured; no migration.
Tests
New
test_pms_room_type_price_derivation(32 tests). Full/pmssuite: 445 tests, with only the two failures already present on 16.0 (TestPmsFolio.test_pms_folio_priority_fiscal_position_property,TestPmsPayment.test_do_payment_sets_payment_method_line).