[jira] [Created] (OFBIZ-13452) MRP applies the global SUPPLIER calendar to resolve ProductFacility.daysToShip instead of Facility specific Calendars

["Swapnil Shah (Jira)" <ji...@apache.org>]

Swapnil Shah created OFBIZ-13452:
------------------------------------

             Summary: 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: mrp, manufacturing
            Reporter: Swapnil Shah
             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 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}} / {{SUPPLIER}} 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" / "SUPPLIER" 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{*}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)