Maximo

Maximo

Come for answers, stay for best practices. All we're missing is you.

 View Only

  • 1.  WO actuals fields vs. trans tables

    Posted Sun August 22, 2021 12:57 AM
    Edited by System Admin Wed March 22, 2023 11:52 AM

    MAM 7.6.1.2:

    It's my understanding that there are two different ways to query for actuals:
    1. The ACT fields in the WORKORDER table:
         - actlabcost
         - actmatcost
         - actservcost
         - acttoolcost,
    2. The related transaction tables:
         - labtrans
         - matusetrans
         - servrectrans
         - tooltrans

    Question:
    Are there any scenarios where the values in ACT fields in WORKORDER aren't exactly the same as the values in the transaction tables?

    The reason I ask is:
    The team that set up my Maximo implementation had a habit of querying the transaction tables.

    Example (from a node in the WO workflow):

    exists (select 1 from matusetrans where refwo=:wonum) 
or exists (select 1 from labtrans where refwo =:wonum) 
or exists (select 1 from servrectrans where refwo=:wonum) 
or exists (select 1 from tooltrans where refwo =:wonum)


    I don't understand why we would want to do that, since we have ACT fields right in the WORKORDER table. If I understand correctly, it would have been simpler/faster to query the ACT fields instead of the transaction tables.
    With that said, I want to make sure that there isn't a reason to query the tables instead of the WO fields.

    Thanks.

    (Note: Neither approach includes task actuals.)


    #Maximo
    #AssetandFacilitiesManagement


  • 2.  RE: WO actuals fields vs. trans tables

    Posted Sun August 22, 2021 01:24 AM
    To my knowledge, it's quite rare for the ACTMATCOST, ACTSERVCOST, ACTLABCOST AND ACTTOOLCOST fields to be incorrect.  The only case I can remember (in 20 years) was when there was a bit of a bug whereby when an item was returned, the ACTMATCOST value was not getting updated.  I haven't checked lately to see if that was fixed.

    Personally I would use the cost fields rather than trying to draw from the transaction tables for workflow - it will improve performance and the risk is low.
    If you find that one of the cost fields is being updated incorrectly, you can always try to fix the cost field update problem rather than adjusting workflow.


    ------------------------------
    Shannon Rotz
    InComm Solutions
    New Westminster BC
    ------------------------------

    Original Message


  • 3.  RE: WO actuals fields vs. trans tables

    Posted Mon August 23, 2021 09:09 AM
    A few thoughts:
    1) If you do choose to stay with querying the related tables, SITEID ought to be included in those WHERE clauses.

    2) As for when the values might not match -- if a user were to do a backend UPDATE or DELETE of data, this would throw it off.  That is, if there were one LABTRANS record for that Work Order, and someone goes directly to the database and deletes that row, your WORKORDER.ACTLABCOST would have a value.

    3) I'm assuming your intent would be to test to see if the Work Order's ACT fields are > 0.00.  If Inventory, a Direct Issue purchase, or approved Labor Transaction are charged to the Work Order at zero cost, then querying the ACT fields would give you incorrect results but the EXISTS statements would do it right.

    4) You may need to also consider whether or not the LABTRANS has been Approved or not.  For example, if your Work Order has one LABTRANS entry that is not approved, then the ACTLABCOST should still be 0.00 until that LBATRANS record is approved.

    ------------------------------
    Travis Herron
    ------------------------------

    Original Message


  • 4.  RE: WO actuals fields vs. trans tables

    Posted Tue August 24, 2021 08:51 AM
    Thanks Travis.

    Regarding #3: "...querying the ACT fields would give you incorrect results​…"

    Would you mind elaborating? Why would the ACT fields produce incorrect results?

    Thanks.
    Original Message


  • 5.  RE: WO actuals fields vs. trans tables

    Posted Tue August 24, 2021 09:39 AM
    Let's say that in real life, a Widget costs $1 and a Gizmo costs $3. You issue 5 widgets and 12 gizmos to your Work Order, but the Maximo data is wrong and both are in Inventory with a cost of $0.00. Then your work order would have rows that EXISTS in the matusetrans table, but WORKORDER.ACTMATCOST > $0.00 would be false.  ACTMATCOST would equal $0, but your intent had been that ACTMATCOST be (5 x $1) + (12 x $3) = $41.

    However, let's change the example a little.  What if those Widgets and Gizmos really do cost $0?  In this situation, you'd be okay with ACTMATCOST = $0.

    So the question really is: what are you trying to test?  Do you need to know if the work order has associated costs, or if there's been any related activities against the work order?
    • If a PO/Invoice line item (part, service, or tool) charged to the Work Order has $0 cost, then the EXISTS test would be true but your "> $0" test would be false.
    • If an Inventory item or Stocked Tool is charged to the Work Order, and whichever costing method you use has $0 for the cost, then the EXISTS test would be true but your "> $0" test would be false.
    • If a Labor Transaction is charged to the Work Order, but the Craft's Hourly Rate is $0, then the EXISTS test would be true but your "> $0" test would be false.
    • If a Labor Transaction is charged to the Work Order, but the transaction is not approved yet, then the EXISTS test would be true but your "> $0" test would be false.

    Or to look at it another way:  changing that thing you originally asked about so that it checks to see if the ACT fields are greater than zero is probably fine so long as you are confident in the quality of the data it's being fed.

    ------------------------------
    Travis Herron
    ------------------------------

    Original Message


  • 6.  RE: WO actuals fields vs. trans tables

    Posted Mon August 23, 2021 06:25 AM
    There is a functional difference between having costs on a wonum and having transactions. For example you could issue an item to a wonum and then return it, in that scenario you would have zero cost but two transactions. Looking at your example, I guess the team are searching for transactions charged on the wonum.

    In an standard installation, cost fields should mirror the costs in transactions. The opposite would be a bug.

    I hope this could be helpful.

    Thanks.

    ------------------------------
    Daniel Torrescusa
    Piensa en nube, SL
    ------------------------------

    Original Message


Related Content