New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MRP Product Info Just in Time #2646

Closed
metas-mk opened this Issue Oct 4, 2017 · 7 comments

Comments

Projects
None yet
3 participants
@metas-mk
Member

metas-mk commented Oct 4, 2017

Is this a bug or feature request?

Feature Request.

What is the current behavior?

Currently, the MRP Product Info is created w/ different Data that does not belong to core data of material management (e.g. daily counting data). Additionally, the recalculation of the MRP Product Info data takes too long (avg 20mins).

Which are the steps to reproduce?

Open, check and see.

What is the expected or desired behavior?

Provide a Window in WebUI that allows to see/ filter/ select the MRP Product Info data similar to today. See if we can move special data usage nearer to core functionalities (like inventory). Provide/ Recalculate data just in time.

@metas-ts

This comment has been minimized.

Show comment
Hide comment
@metas-ts

metas-ts Nov 27, 2017

Member

The "main class" of the info window is de.metas.fresh.gui.search.MRPInfoWindow

Query-Fields

date

  • Datum => Date widget with an up- and a down-arrow

product related

  • Product => Lookup
  • Name => substring
  • Suchschlüssel => substring
  • M_ProductCategory_ID => opt list field

Other

  • Purchased => opt Y/N (list) field
  • Sold => opt Y/N (list) field
  • Konferenz

The main table

Main table fields

the main table is backed by the view X_MRP_ProductInfo_V

  • M_Product_ID
  • Name
  • Value
  • M_ProductCategory_ID
  • QtyOnHand_OnDate_Plant1 (Zählbestand "particular-plant-1")
  • QtyOnHand_OnDate_Plant2 (Zählbestand "particular-plant-2")
  • Fresh_QtyOnHand_OnDate (Zählbestand)
  • Fresh_QtyPromised (Zusagbar Zählbestand)
  • PMM_QtyPromised_OnDate (Zusage Lieferant)
  • QtyReserved_OnDate (Reservierte Menge Tag)
  • QtyOrdered_OnDate (Bestellte Menge Tag)
  • QtyMaterialentnahme (Materialentnahme)
  • Fresh_QtyMRP (MRP Menge)

The view X_MRP_ProductInfo_V

  • uses the table X_MRP_ProductInfo_Detail_Poor_Mans_MRP (just for the Fresh_QtyMRP column)
  • selects the other columns from X_MRP_ProductInfo_Detail_MV (with sum and group-by)
    • X_MRP_ProductInfo_Detail_MV is kept up to date by the function
      "de.metas.fresh".x_mrp_productinfo_detail_mv_refresh(dateat date, m_product_id numeric, m_attributesetinstance_id numeric)
    • ...where the actual data is coming from the function X_MRP_ProductInfo_Detail_V(datefrom date, m_product_id numeric)

The function X_MRP_ProductInfo_Detail_V

... is one large parameterized select

It's building blocks are

  • "de.metas.fresh".M_Product_ID_M_AttributeSetInstance_ID_V
    • selects all distict relevant M_Product_IDs, M_AttributeSetInstance_IDs, and dates from a UNION from the tables
      • M_Transaction
      • C_OrderLine
      • Fresh_QtyOnHand
      • PMM_PurchaseCandidate
    • everything else is left-joined to this view, so this view decides which (product, ASI, date) tuples needs further data to be joined to it
  • "de.metas.fresh".RV_C_OrderLine_QtyOrderedReservedPromised_OnDate_V
    • selects the reserved and ordered quantities
    • based on the tables C_Order, C_OrderLine and M_ShipmentSchedule
  • "de.metas.fresh".RV_HU_QtyMaterialentnahme_OnDate
    • M_Transactions related to the DirectMove-Warehouse SysConfig de.metas.handlingunits.client.terminal.inventory.model.InventoryHUEditorModel#DirectMove_Warehouse_ID
  • "de.metas.fresh".X_Fresh_QtyOnHand_OnDate
    • "plain table" with just product, ASI, date and qty
    • updated via trigger-function "de.metas.fresh".m_transaction_update_x_Fresh_qtyonhand_ondate on inserts and deletes regarding MTransaction records with MovementType IN ('C-', 'C+', 'V-', 'V+')
  • Fresh_QtyOnHand_Line
    • one time for a sum (=> Fresh_QtyOnHand_OnDate)
    • and one time per plant
  • PMM_PurchaseCandidate
    • for column PMM_QtyPromised_OnDate (Zusage Lieferant)

Sorting

..can be defined date stored in

  • AD_User_SortPref_Hdr
  • AD_User_SortPref_Line
  • AD_User_SortPref_Line_Product

in class org.compiere.apps.search.Info.java

Sub tab fields

The two sub tables relate to the currently selected main table row.

X_MRP_ProductInfo_AttributeVal_V (Aufschlüsselung nach Attributgruppen)

  • Shows the different lines with their different "attribute keys" and quantities that are summed up in the respective main table row
  • The attribute keys to group by are defined in DIM_Dimension_Spec (InternalName='MRP_Product_Info_ASI_Values')

The function X_MRP_ProductInfo_AttributeVal_V, is basically a parmeterized select from X_MRP_ProductInfo_AttributeVal_Raw_V which in turn leans on X_MRP_ProductInfo_Detail_MV, just like the main table

MRPInfoWindowAttribs (Aufschlüsselung nach Attributen)

based in the view C_OrderLine_HU_Info_v

  • C_Order, C_OrderLine, M_ShipmentSchedule
  • shows reserved and ordered quantities per ASI and M_HU_PI_Item_Product_ID

Notable details:

  • Group names is an array of varchars; the chars that were mapped from ASI-ID with demension-stuff
Member

metas-ts commented Nov 27, 2017

The "main class" of the info window is de.metas.fresh.gui.search.MRPInfoWindow

Query-Fields

date

  • Datum => Date widget with an up- and a down-arrow

product related

  • Product => Lookup
  • Name => substring
  • Suchschlüssel => substring
  • M_ProductCategory_ID => opt list field

Other

  • Purchased => opt Y/N (list) field
  • Sold => opt Y/N (list) field
  • Konferenz

The main table

Main table fields

the main table is backed by the view X_MRP_ProductInfo_V

  • M_Product_ID
  • Name
  • Value
  • M_ProductCategory_ID
  • QtyOnHand_OnDate_Plant1 (Zählbestand "particular-plant-1")
  • QtyOnHand_OnDate_Plant2 (Zählbestand "particular-plant-2")
  • Fresh_QtyOnHand_OnDate (Zählbestand)
  • Fresh_QtyPromised (Zusagbar Zählbestand)
  • PMM_QtyPromised_OnDate (Zusage Lieferant)
  • QtyReserved_OnDate (Reservierte Menge Tag)
  • QtyOrdered_OnDate (Bestellte Menge Tag)
  • QtyMaterialentnahme (Materialentnahme)
  • Fresh_QtyMRP (MRP Menge)

The view X_MRP_ProductInfo_V

  • uses the table X_MRP_ProductInfo_Detail_Poor_Mans_MRP (just for the Fresh_QtyMRP column)
  • selects the other columns from X_MRP_ProductInfo_Detail_MV (with sum and group-by)
    • X_MRP_ProductInfo_Detail_MV is kept up to date by the function
      "de.metas.fresh".x_mrp_productinfo_detail_mv_refresh(dateat date, m_product_id numeric, m_attributesetinstance_id numeric)
    • ...where the actual data is coming from the function X_MRP_ProductInfo_Detail_V(datefrom date, m_product_id numeric)

The function X_MRP_ProductInfo_Detail_V

... is one large parameterized select

It's building blocks are

  • "de.metas.fresh".M_Product_ID_M_AttributeSetInstance_ID_V
    • selects all distict relevant M_Product_IDs, M_AttributeSetInstance_IDs, and dates from a UNION from the tables
      • M_Transaction
      • C_OrderLine
      • Fresh_QtyOnHand
      • PMM_PurchaseCandidate
    • everything else is left-joined to this view, so this view decides which (product, ASI, date) tuples needs further data to be joined to it
  • "de.metas.fresh".RV_C_OrderLine_QtyOrderedReservedPromised_OnDate_V
    • selects the reserved and ordered quantities
    • based on the tables C_Order, C_OrderLine and M_ShipmentSchedule
  • "de.metas.fresh".RV_HU_QtyMaterialentnahme_OnDate
    • M_Transactions related to the DirectMove-Warehouse SysConfig de.metas.handlingunits.client.terminal.inventory.model.InventoryHUEditorModel#DirectMove_Warehouse_ID
  • "de.metas.fresh".X_Fresh_QtyOnHand_OnDate
    • "plain table" with just product, ASI, date and qty
    • updated via trigger-function "de.metas.fresh".m_transaction_update_x_Fresh_qtyonhand_ondate on inserts and deletes regarding MTransaction records with MovementType IN ('C-', 'C+', 'V-', 'V+')
  • Fresh_QtyOnHand_Line
    • one time for a sum (=> Fresh_QtyOnHand_OnDate)
    • and one time per plant
  • PMM_PurchaseCandidate
    • for column PMM_QtyPromised_OnDate (Zusage Lieferant)

Sorting

..can be defined date stored in

  • AD_User_SortPref_Hdr
  • AD_User_SortPref_Line
  • AD_User_SortPref_Line_Product

in class org.compiere.apps.search.Info.java

Sub tab fields

The two sub tables relate to the currently selected main table row.

X_MRP_ProductInfo_AttributeVal_V (Aufschlüsselung nach Attributgruppen)

  • Shows the different lines with their different "attribute keys" and quantities that are summed up in the respective main table row
  • The attribute keys to group by are defined in DIM_Dimension_Spec (InternalName='MRP_Product_Info_ASI_Values')

The function X_MRP_ProductInfo_AttributeVal_V, is basically a parmeterized select from X_MRP_ProductInfo_AttributeVal_Raw_V which in turn leans on X_MRP_ProductInfo_Detail_MV, just like the main table

MRPInfoWindowAttribs (Aufschlüsselung nach Attributen)

based in the view C_OrderLine_HU_Info_v

  • C_Order, C_OrderLine, M_ShipmentSchedule
  • shows reserved and ordered quantities per ASI and M_HU_PI_Item_Product_ID

Notable details:

  • Group names is an array of varchars; the chars that were mapped from ASI-ID with demension-stuff

metas-ts added a commit that referenced this issue Dec 15, 2017

cambrian explosion of event types
* all needed to update the mrp cokpit, many but also to for material dispo
* fire those events from model interceptors
* make sure they are all serializable/deserializable
* also move e.g. de.metas.material.model.interceptor => de.metas.material.interceptor and other refactorings
* add model class for the new material cockpit base table MD_Cockpit
* also add InterceptorUtil to figure out when some record was activated etc just now (important to avoid firing too many events)

MRP Product Info Just in Time #2646

metas-ts added a commit to metasfresh/metasfresh-webui-api that referenced this issue Dec 15, 2017

use the new events to update the MD_Cockpit table
that table will be the new base of the material cockpit view

also minor improvement in MaterialCockpitView

MRP Product Info Just in Time metasfresh/metasfresh#2646

metas-ts added a commit that referenced this issue Dec 15, 2017

move model interceptors to better package names;
also add event from ppOrder removal, but it's not yet used

MRP Product Info Just in Time #2646

metas-ts added a commit that referenced this issue Dec 15, 2017

remove material-dispo-client; extend AttributesKey; add dimension-spec
* material-dispo-client was very webui-product-lookup specific, so I move it there and call it adapter
* AttributesKey now distinguishes between NONE, ALL and OTHER. When you create one for an ASI, you need to tell it what you want in case of empty ASI
* add dedicated dimension spec with support for "other" for material cockpit
* add SQL migration stuff

MRP Product Info Just in Time #2646

metas-ts added a commit to metasfresh/metasfresh-webui-api that referenced this issue Dec 15, 2017

move the code based on I_X_MRP_ProductInfo_Detail_MV to a dedicated l…
…egacy package

also
* copy that code and switch it to MD_Cockpit
* work on view invalidation on MD_Cockpit changes

MRP Product Info Just in Time metasfresh/metasfresh#2646

metas-ts added a commit to metasfresh/metasfresh-webui-api that referenced this issue Dec 15, 2017

metas-ts added a commit to metasfresh/metasfresh-webui-api that referenced this issue Dec 15, 2017

add code of material-dispo-client; use new dimension-spec
* material-dispo-client was very webui-product-lookup specific, so I move it there and call it adapter
* add dedicated dimension spec with support for "other" for material cockpit

MRP Product Info Just in Time metasfresh/metasfresh#2646

metas-ts added a commit to metasfresh/metasfresh-webui-api that referenced this issue Dec 15, 2017

metas-ts added a commit that referenced this issue Dec 15, 2017

add indices, for performance and consistency
MRP Product Info Just in Time #2646

metas-ts added a commit that referenced this issue Dec 15, 2017

rename "Material Cockpit" to Materialcockpit", to be consistent with …
…"Materialdispo"

MRP Product Info Just in Time #2646

metas-ts added a commit that referenced this issue Dec 15, 2017

solve unit test issues
MRP Product Info Just in Time #2646

metas-ts added a commit that referenced this issue Dec 15, 2017

Merge pull request #3217 from metasfresh/gh2646-app
MRP Product Info Just in Time #2646

metas-ts added a commit to metasfresh/metasfresh-webui-api that referenced this issue Dec 16, 2017

@metas-ts metas-ts removed their assignment Dec 18, 2017

metas-ts added a commit that referenced this issue Dec 18, 2017

Update ReleaseNotes.md
[#706](metasfresh/metasfresh-webui-api#706)
Port current MRP Product Info Window to the webui
[#755](metasfresh/metasfresh-webui-api#755)
Processes: support for parentViewSelectedIds and childViewSelectedIds
[#1427](metasfresh/metasfresh-webui-frontend#1427)
d3 errors on dashboard
[#2646](#2646) MRP
Product Info Just in Time
[#751](metasfresh/metasfresh-webui-api#751)
Picking Tray Clearing: packing HUs: Add to Transportation Order action
[#1437](metasfresh/metasfresh-webui-frontend#1437)
Language bug: The language in Settings is not respected
[#746](metasfresh/metasfresh-webui-api#746)
Picking Tray Clearing: Scan picking slot barcode filter
[#1455](metasfresh/metasfresh-webui-frontend#1455)
error when updating an attribute multiple times
[#747](metasfresh/metasfresh-webui-api#747)
Picking Tray Clearing: filter picking slots by Partner
[#1433](metasfresh/metasfresh-webui-frontend#1433)
Support Lookup view attributes
[#3211](#3211) Picking
Tray Clearing: right side view shall display only the HUs for current
BP/Location
[#1444](metasfresh/metasfresh-webui-frontend#1444)
Attributes are empty in material receipt candidate
[#3202](#3202) Error in
Paymentjournal Process/ Report in Payselection
[#3193](#3193) Improve
Window for manual OnHand Qty in WebUI
[#1448](metasfresh/metasfresh-webui-frontend#1448)
jenkins: fix current lint issues
[#1435](metasfresh/metasfresh-webui-frontend#1435)
Problem regarding multiple filters
[#1436](metasfresh/metasfresh-webui-frontend#1436)
Remove legacy docs
[#3169](#3169) Updating
PMM_Week availability trend fails
[#1206](metasfresh/metasfresh-webui-frontend#1206)
Use automatic code style enforcement
[#717](metasfresh/metasfresh-webui-api#717)
picking terminal: open HUs to pick shall display Best Before date and
Locator

me-45
@metas-dh

This comment has been minimized.

Show comment
Hide comment
@metas-dh

metas-dh Jan 11, 2018

Member

Results of IT1
tested in mf15

  • qties in Material Cockpit were changed shortly after order / receipt was created
    => stopped testing bc connections crashed (a lot of requests were sent for material cockpit update)
Member

metas-dh commented Jan 11, 2018

Results of IT1
tested in mf15

  • qties in Material Cockpit were changed shortly after order / receipt was created
    => stopped testing bc connections crashed (a lot of requests were sent for material cockpit update)

@metas-dh metas-dh self-assigned this Jan 23, 2018

@metas-dh

This comment has been minimized.

Show comment
Hide comment
@metas-dh

metas-dh Jan 24, 2018

Member

Results of IT2
tested in releasetest

Material Cockpit:

I. Just in Time: qties in cockpit were changed about 1-2 sec. after the resp. action, OK

II. Correct updating of qties:

  • Fresh_QtyOnHand_OnDate (Zählbestand / Bestand):

    • increased correctly after material receipt: OK
    • decreased correctly after material receipt reverse: OK
    • decreased correctly after shipment complete: OK
    • increased correctly after shipment reactivate: OK
    • decreased correctly after Materialentnahme: OK
  • Fresh_QtyPromised (Zusagbar Zählbestand / Zusagbare Menge):

    • increased correctly after Zählbestand (Einkauf) processed: OK
    • decreased correctly after Zählbestand (Einkauf) unprocessed OK
    • decreased correctly after sales order complete: OK
    • increased correctly after sales order reactivate: OK
    • increased correctly after material receipt: OK
    • decreased correctly after material receipt reverse: OK
    • decreased correctly after Materialentnahme: OK
  • Schätzmenge:

    • decreased correctly after shipment complete: OK
    • increased correctly after shipment reactivate: OK
    • decreased correctly after Materialentnahme: OK
    • increased correctly after material receipt: OK
    • decreased correctly after material receipt reverse: OK

=> problem i had with Bestand, Zusagbare Menge & Schätzmenge: reactivated and completed the same shipment sev. times, expected those to decrease / increase by the resp. qty of the shipment: but they only increased, as if i had created & completed new shipments: => fixed: OK

=> Bestand, Zusagbare Menge & Schätzmenge: qties are increased correctly after material receipt, but are not decreased when that qty is disposed: shouldn't dispose cause a decrease in qty? NOK i think

  • PMM_QtyPromised_OnDate (Zusage Lieferant): tested in customer db:

    • increased correctly after creation of purchase candidate created via procurement WebUI: OK
  • QtyReserved_OnDate (Reservierte Menge Tag):

    • increased correctly after sales order complete: OK
    • decreased correctly after sales order reactivate: OK
    • decreased correctly after shipment complete: OK
    • increased correctly after shipment reactivate: OK
  • QtyOrdered_OnDate (Bestellte Menge Tag):

    • increased correctly after purchase order complete: OK
    • decreased correctly after purchase order reactivate: OK
    • decreased correctly after material receipt: OK
    • increased correctly after material receipt reverse: OK
  • QtyMaterialentnahme (Materialentnahme):

    • increased correctly after Materialentnahme: OK
  • Fresh_QtyMRP (MRP Menge):: Benötigte Menge für Produktion:

    • increased correctly after manufacturing order complete:
      => the qties did not add up correctly for my PP_Order; also: the qty in Fresh_QtyMRP was changed right after the PP_Order component qties were created, and was not changed anymore after i changed the qty in PP_Order or reactivated it: not sure this is ok (tested with manual PP_Order)
Member

metas-dh commented Jan 24, 2018

Results of IT2
tested in releasetest

Material Cockpit:

I. Just in Time: qties in cockpit were changed about 1-2 sec. after the resp. action, OK

II. Correct updating of qties:

  • Fresh_QtyOnHand_OnDate (Zählbestand / Bestand):

    • increased correctly after material receipt: OK
    • decreased correctly after material receipt reverse: OK
    • decreased correctly after shipment complete: OK
    • increased correctly after shipment reactivate: OK
    • decreased correctly after Materialentnahme: OK
  • Fresh_QtyPromised (Zusagbar Zählbestand / Zusagbare Menge):

    • increased correctly after Zählbestand (Einkauf) processed: OK
    • decreased correctly after Zählbestand (Einkauf) unprocessed OK
    • decreased correctly after sales order complete: OK
    • increased correctly after sales order reactivate: OK
    • increased correctly after material receipt: OK
    • decreased correctly after material receipt reverse: OK
    • decreased correctly after Materialentnahme: OK
  • Schätzmenge:

    • decreased correctly after shipment complete: OK
    • increased correctly after shipment reactivate: OK
    • decreased correctly after Materialentnahme: OK
    • increased correctly after material receipt: OK
    • decreased correctly after material receipt reverse: OK

=> problem i had with Bestand, Zusagbare Menge & Schätzmenge: reactivated and completed the same shipment sev. times, expected those to decrease / increase by the resp. qty of the shipment: but they only increased, as if i had created & completed new shipments: => fixed: OK

=> Bestand, Zusagbare Menge & Schätzmenge: qties are increased correctly after material receipt, but are not decreased when that qty is disposed: shouldn't dispose cause a decrease in qty? NOK i think

  • PMM_QtyPromised_OnDate (Zusage Lieferant): tested in customer db:

    • increased correctly after creation of purchase candidate created via procurement WebUI: OK
  • QtyReserved_OnDate (Reservierte Menge Tag):

    • increased correctly after sales order complete: OK
    • decreased correctly after sales order reactivate: OK
    • decreased correctly after shipment complete: OK
    • increased correctly after shipment reactivate: OK
  • QtyOrdered_OnDate (Bestellte Menge Tag):

    • increased correctly after purchase order complete: OK
    • decreased correctly after purchase order reactivate: OK
    • decreased correctly after material receipt: OK
    • increased correctly after material receipt reverse: OK
  • QtyMaterialentnahme (Materialentnahme):

    • increased correctly after Materialentnahme: OK
  • Fresh_QtyMRP (MRP Menge):: Benötigte Menge für Produktion:

    • increased correctly after manufacturing order complete:
      => the qties did not add up correctly for my PP_Order; also: the qty in Fresh_QtyMRP was changed right after the PP_Order component qties were created, and was not changed anymore after i changed the qty in PP_Order or reactivated it: not sure this is ok (tested with manual PP_Order)

metas-ts added a commit that referenced this issue Jan 26, 2018

metas-ts added a commit that referenced this issue Jan 26, 2018

Solve unit test failure
#2646
(cherry picked from commit 12b6810)
@metas-ts

This comment has been minimized.

Show comment
Hide comment
@metas-ts

metas-ts Jan 26, 2018

Member

Cherry picked the last two commits to 2018-06

Member

metas-ts commented Jan 26, 2018

Cherry picked the last two commits to 2018-06

@metas-dh

This comment has been minimized.

Show comment
Hide comment
@metas-dh

metas-dh Feb 1, 2018

Member

Testing with attribute qties:

  • attribute qties correct after sales order: OK

  • attribute qties correct after shipment: OK

  • attribute qties correct after purchase order: OK

  • attribute qties correct after material receipt: OK

  • in case the purchase order had attribute set, but the material receipt not, the attribute qty in QtyOrdered_OnDate (Bestellte Menge Tag) was decreased nevertheless, is that ok?

Member

metas-dh commented Feb 1, 2018

Testing with attribute qties:

  • attribute qties correct after sales order: OK

  • attribute qties correct after shipment: OK

  • attribute qties correct after purchase order: OK

  • attribute qties correct after material receipt: OK

  • in case the purchase order had attribute set, but the material receipt not, the attribute qty in QtyOrdered_OnDate (Bestellte Menge Tag) was decreased nevertheless, is that ok?

@metas-dh

This comment has been minimized.

Show comment
Hide comment
@metas-dh

metas-dh Feb 9, 2018

Member

Update:

checked again during last e2e for customer:

  • Fresh_QtyMRP (MRP Menge):: Benötigte Menge für Produktion: incorrect in WebUI (Swing was ok, MRP qty for the production i needed): NOK

EDIT/Reply ts-2018-02-22:
hi @metas-dh

  • looking at the event log, material dispo evaluated the available-to-promise-qty and decided not to plan any PP_Orders..that's why we didn't have any "Benötigte Menge für Produktion"-Qty.
    • Why did it make that decision: idk without looking deeper..generally it does plan PP_Orders if there is no qty in sight and if the PP_ProductPlanning etc is set up accordingly
    • but i plan to make material-dispo much more understandable
  • PS: in swing, we just see "static" numbers from the respective BOM..it doesn't care whether the production is really needed or whether there is already enough stuff available

  • Fresh_QtyMRP (MRP Menge):: Benötigte Menge für Produktion: not updated when the order is closed: NOK imho

EDIT/Reply ts-2018-02-22:
hi @metas-dh, i'll check it out

Member

metas-dh commented Feb 9, 2018

Update:

checked again during last e2e for customer:

  • Fresh_QtyMRP (MRP Menge):: Benötigte Menge für Produktion: incorrect in WebUI (Swing was ok, MRP qty for the production i needed): NOK

EDIT/Reply ts-2018-02-22:
hi @metas-dh

  • looking at the event log, material dispo evaluated the available-to-promise-qty and decided not to plan any PP_Orders..that's why we didn't have any "Benötigte Menge für Produktion"-Qty.
    • Why did it make that decision: idk without looking deeper..generally it does plan PP_Orders if there is no qty in sight and if the PP_ProductPlanning etc is set up accordingly
    • but i plan to make material-dispo much more understandable
  • PS: in swing, we just see "static" numbers from the respective BOM..it doesn't care whether the production is really needed or whether there is already enough stuff available

  • Fresh_QtyMRP (MRP Menge):: Benötigte Menge für Produktion: not updated when the order is closed: NOK imho

EDIT/Reply ts-2018-02-22:
hi @metas-dh, i'll check it out

metas-ts added a commit that referenced this issue Feb 21, 2018

Also fire an event on inventory-M-Transaction
this relates to #2646 (comment)

> => Bestand, Zusagbare Menge & Schätzmenge: qties are increased correctly after material receipt, but are not decreased when that qty is disposed: shouldn't dispose cause a decrease in qty? NOK i think"

MRP Product Info Just in Time #2646

metas-ts added a commit that referenced this issue Mar 12, 2018

WIP on fixing wrong qty on PP_Order close
see #2646 (comment)
not yet done!
MRP Product Info Just in Time #2646

metas-ts added a commit that referenced this issue Mar 13, 2018

metas-ts added a commit that referenced this issue Mar 14, 2018

Merge pull request #3696 from metasfresh/gh2646-app
#2646-app MRP Product Info Just in Time
@metas-dh

This comment has been minimized.

Show comment
Hide comment
@metas-dh

metas-dh Mar 16, 2018

Member

Checked once more in mf15:

  • Fresh_QtyMRP (MRP Menge):: Benötigte Menge für Produktion: not updated when the order is closed: qty is correctly updated after order is closed, also after qty in the order is changed: OK

=> closing this one since we have a bunch of other tasks in that area for specific problems.

Member

metas-dh commented Mar 16, 2018

Checked once more in mf15:

  • Fresh_QtyMRP (MRP Menge):: Benötigte Menge für Produktion: not updated when the order is closed: qty is correctly updated after order is closed, also after qty in the order is changed: OK

=> closing this one since we have a bunch of other tasks in that area for specific problems.

@metas-dh metas-dh closed this Mar 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment