You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ofbiz.apache.org by "Swapnil Shah (Jira)" <ji...@apache.org> on 2026/07/01 04:53:00 UTC
[jira] [Updated] (OFBIZ-13452) MRP applies the global SUPPLIER calendar to resolve ProductFacility.daysToShip instead of Facility specific Calendars
[ https://issues.apache.org/jira/browse/OFBIZ-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Swapnil Shah updated OFBIZ-13452:
---------------------------------
Description:
Currently in MRP, the {{requirementStartDate}} for a purchased product (no BoM) is computed by walking backward from the {{requiredByDate}} over a single global {{TechDataCalendar}} with {{{}calendarId = "SUPPLIER"{}}}.
Part of that backward offset is {{ProductFacility.daysToShip}} (honoured for {{SALES_ORDER_SHIP}} events). However, {{daysToShip}} is a *facility-level* attribute representing handling/ship work performed at the facility — so applying a *supplier-side* calendar doesn't look like a sound approach.
OFBiz already models facility-specific calendars via the {{FacilityCalendar}} entity ({{{}facilityId{}}} -> {{{}calendarId{}}}, with {{{}fromDate{}}}/{{{}thruDate{}}} and a {{facilityCalendarTypeId}} discriminator), mirroring the established {{FixedAsset.calendarId}} pattern. However, {{FacilityCalendar}} and {{FacilityCalendarType}} are currently {*}dormant{*}: there are no references to them in any Java, Groovy, service, or screen definition, and no seed/demo data exists. The current {{{}SUPPLIER{}}}-calendar usage is legacy — the affected code block historically carried a {{// TODO: REVIEW this code}} comment, and {{SUPPLIER}} was the only calendar that path ever consulted.
h2. Proposed change
# Resolve the {{daysToShip}} working calendar from {{FacilityCalendar}} for the requirement's {{{}facilityId{}}}, using some dedicated {{facilityCalendarTypeId say "SHIPPING"}} (a new seeded type), filtered active by date.
# Walk {{daysToShip}} backward over that facility calendar.
# Fall back to the global {{DEFAULT}} calendar, then to direct day arithmetic, when no facility calendar is configured.
Suggested resolution order for {{{}daysToShip{}}}:
{code:none}
FacilityCalendar(facilityId, facilityCalendarTypeId="SHIPPING", active) -> calendarId -> global "DEFAULT" TechDataCalendar -> direct day arithmetic (no calendar)
{code}
h2. Seed data
Add a new facility calendar type (and optionally demo {{FacilityCalendar}} rows):
{code:xml}
<FacilityCalendarType facilityCalendarTypeId="SHIPPING" description="Shipping/handling working calendar"/>
{code}
h2. Backward compatibility
* Behaviour changes *only* for purchased products at facilities that have a {{SHIPPING}} {{FacilityCalendar}} configured. With none configured, the result is identical to today (global DEFAULT calendar, or direct arithmetic when absent).
* This activates the previously-unused {{FacilityCalendar}} / {{FacilityCalendarType}} entities for their intended purpose.
* The pre-existing limitation that {{TechDataServices}} backward functions ({{{}capacityRemainingBackward{}}}, {{{}endPreviousDay{}}}) do not honour {{TechDataCalendarExcDay}} / {{TechDataCalendarExcWeek}} exception days applies equally here and is {*}out of scope{*}.
was:
Currently in MRP, the {{requirementStartDate}} for a purchased product (no BoM) is computed by walking backward from the {{requiredByDate}} over a single global {{TechDataCalendar}} with {{{}calendarId = "SUPPLIER"{}}}.
Part of that backward offset is {{ProductFacility.daysToShip}} (honoured for {{SALES_ORDER_SHIP}} events). However, {{daysToShip}} is a *facility-level* attribute representing handling/ship work performed at the receiving facility — so applying a *supplier-side* calendar doesn't look like a sound approach.
OFBiz already models facility-specific calendars via the {{FacilityCalendar}} entity ({{{}facilityId{}}} -> {{{}calendarId{}}}, with {{{}fromDate{}}}/{{{}thruDate{}}} and a {{facilityCalendarTypeId}} discriminator), mirroring the established {{FixedAsset.calendarId}} pattern. However, {{FacilityCalendar}} and {{FacilityCalendarType}} are currently {*}dormant{*}: there are no references to them in any Java, Groovy, service, or screen definition, and no seed/demo data exists. The current {{{}SUPPLIER{}}}-calendar usage is legacy — the affected code block historically carried a {{// TODO: REVIEW this code}} comment, and {{SUPPLIER}} was the only calendar that path ever consulted.
h2. Proposed change
# Resolve the {{daysToShip}} working calendar from {{FacilityCalendar}} for the requirement's {{{}facilityId{}}}, using some dedicated {{facilityCalendarTypeId say "SHIPPING"}} (a new seeded type), filtered active by date.
# Walk {{daysToShip}} backward over that facility calendar.
# Fall back to the global {{DEFAULT}} calendar, then to direct day arithmetic, when no facility calendar is configured.
Suggested resolution order for {{{}daysToShip{}}}:
{code:none}
FacilityCalendar(facilityId, facilityCalendarTypeId="SHIPPING", active) -> calendarId -> global "DEFAULT" TechDataCalendar -> direct day arithmetic (no calendar)
{code}
h2. Seed data
Add a new facility calendar type (and optionally demo {{FacilityCalendar}} rows):
{code:xml}
<FacilityCalendarType facilityCalendarTypeId="SHIPPING" description="Shipping/handling working calendar"/>
{code}
h2. Backward compatibility
* Behaviour changes *only* for purchased products at facilities that have a {{SHIPPING}} {{FacilityCalendar}} configured. With none configured, the result is identical to today (global {{SUPPLIER}} calendar, or direct arithmetic when absent).
* This activates the previously-unused {{FacilityCalendar}} / {{FacilityCalendarType}} entities for their intended purpose.
* The pre-existing limitation that {{TechDataServices}} backward functions ({{{}capacityRemainingBackward{}}}, {{{}endPreviousDay{}}}) do not honour {{TechDataCalendarExcDay}} / {{TechDataCalendarExcWeek}} exception days applies equally here and is {*}out of scope{*}.
> MRP applies the global SUPPLIER calendar to resolve ProductFacility.daysToShip instead of Facility specific Calendars
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: OFBIZ-13452
> URL: https://issues.apache.org/jira/browse/OFBIZ-13452
> Project: OFBiz
> Issue Type: Improvement
> Components: manufacturing, mrp
> Reporter: Swapnil Shah
> Priority: Minor
> Fix For: Upcoming Branch
>
>
> Currently in MRP, the {{requirementStartDate}} for a purchased product (no BoM) is computed by walking backward from the {{requiredByDate}} over a single global {{TechDataCalendar}} with {{{}calendarId = "SUPPLIER"{}}}.
> Part of that backward offset is {{ProductFacility.daysToShip}} (honoured for {{SALES_ORDER_SHIP}} events). However, {{daysToShip}} is a *facility-level* attribute representing handling/ship work performed at the facility — so applying a *supplier-side* calendar doesn't look like a sound approach.
> OFBiz already models facility-specific calendars via the {{FacilityCalendar}} entity ({{{}facilityId{}}} -> {{{}calendarId{}}}, with {{{}fromDate{}}}/{{{}thruDate{}}} and a {{facilityCalendarTypeId}} discriminator), mirroring the established {{FixedAsset.calendarId}} pattern. However, {{FacilityCalendar}} and {{FacilityCalendarType}} are currently {*}dormant{*}: there are no references to them in any Java, Groovy, service, or screen definition, and no seed/demo data exists. The current {{{}SUPPLIER{}}}-calendar usage is legacy — the affected code block historically carried a {{// TODO: REVIEW this code}} comment, and {{SUPPLIER}} was the only calendar that path ever consulted.
> h2. Proposed change
> # Resolve the {{daysToShip}} working calendar from {{FacilityCalendar}} for the requirement's {{{}facilityId{}}}, using some dedicated {{facilityCalendarTypeId say "SHIPPING"}} (a new seeded type), filtered active by date.
> # Walk {{daysToShip}} backward over that facility calendar.
> # Fall back to the global {{DEFAULT}} calendar, then to direct day arithmetic, when no facility calendar is configured.
> Suggested resolution order for {{{}daysToShip{}}}:
> {code:none}
> FacilityCalendar(facilityId, facilityCalendarTypeId="SHIPPING", active) -> calendarId -> global "DEFAULT" TechDataCalendar -> direct day arithmetic (no calendar)
> {code}
> h2. Seed data
> Add a new facility calendar type (and optionally demo {{FacilityCalendar}} rows):
> {code:xml}
> <FacilityCalendarType facilityCalendarTypeId="SHIPPING" description="Shipping/handling working calendar"/>
> {code}
> h2. Backward compatibility
> * Behaviour changes *only* for purchased products at facilities that have a {{SHIPPING}} {{FacilityCalendar}} configured. With none configured, the result is identical to today (global DEFAULT calendar, or direct arithmetic when absent).
> * This activates the previously-unused {{FacilityCalendar}} / {{FacilityCalendarType}} entities for their intended purpose.
> * The pre-existing limitation that {{TechDataServices}} backward functions ({{{}capacityRemainingBackward{}}}, {{{}endPreviousDay{}}}) do not honour {{TechDataCalendarExcDay}} / {{TechDataCalendarExcWeek}} exception days applies equally here and is {*}out of scope{*}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)