Sage 100

 View Only
  • 1.  IM ALE displayin On Sales Orders

    Posted 09-29-2020 12:23
    Client is wonder if he can have an ALE view in IM maintence that displays QTY on SO values.  I am not seeing a solution.  No SO value in CI_Item and no way to link to the table where the value is stored in IM_ItemWarehouse.

    Am I missing something?

    ------------------------------
    Jeff Schwenk
    FORMER 90M Board Member
    Bottomline Software, Inc.
    Waynesboro VA
    540-221-4444
    ------------------------------


  • 2.  RE: IM ALE displayin On Sales Orders

    Posted 09-29-2020 12:46
    Real time values are not possible, even with scripting (because the event doesn't trigger when updating OnSO in IM_ItemWarehouse).

    You could set up an external refresh into a CI_Item UDF, but the data would only be as current as the last time you ran the VI refresh.

    ------------------------------
    Kevin Moyes
    Technical Systems Analyst
    Munjal White Consulting Co.
    Toronto ON
    ------------------------------



  • 3.  RE: IM ALE displayin On Sales Orders

    Posted 09-29-2020 14:23
    If Premium you could set up a CI_Item UDF and a trigger in SQL to keep it current

    ------------------------------
    Phil McIntosh
    President
    Friendly Systems, Inc.
    Asheville NC
    678.273.4010 ext 5
    ------------------------------



  • 4.  RE: IM ALE displayin On Sales Orders

    Posted 09-29-2020 16:09
    If not premium, then we wrote a program to populate the UDF in CI_Item.

    ------------------------------
    Lee Graham
    Friendly Systems, Inc.
    ------------------------------



  • 5.  RE: IM ALE displayin On Sales Orders

    Posted 09-30-2020 05:10
    Edited by David Speck II 09-30-2020 05:17
    Is the Item Quantities By Warehouse BIE view not an option?

    ALEs typically can only be linked to other tables where there is a one to one relationship between tables, they don't have any built in functions to sum a value across multiple records in a one to many scenario like CI_Item and IM_ItemWarehouse creates.

    If you only need a one to one link, you can set up a calculated column and use function built into the ALE program called FNRead for numeric values and FNRead$ for string values. Here is an example. The first argument is the lookup value, i.e. the record in the target table will be selected if the first argument matches a key using the primary index in the target table. The second argument is the target table without the extension. I never quite figured out what the third and fourth arguments mean but after trial and error, what you see below works. The fifth argument is the target field, you do not need the trailing dollar sign for string fields in the fifth argument but you do need the trailing dollar sign on the function name for string fields. 
    FNREAD$(STR(ExtendedDescriptionKey), "CI_ExtendedDescription", "1", 0, "ExtendedDescriptionText")​​

    Here is an example of taking the above example a step further so the result is a single column that will contain the full description. This uses the TBL function and the boolean evaluation on the ExtendedDescriptionKey being greater than "0000000000" or not. If it isn't, the TBL function returns the second argument, in this case, the standard description, if it is, the TBL function returns the extended description.
    TBL(STR(ExtendedDescriptionKey)>"0000000000", STR(ItemCodeDesc), FNREAD$(STR(ExtendedDescriptionKey), "CI_ExtendedDescription", "1", 0, "ExtendedDescriptionText")) ​


    Now neither of these solve your problem since you need to sum the value of many records in IM_ItemWarehouse, to achieve this, you have to leverage a function called XEQ and a text file contain ProvideX code to return the value you are after. XEQ will do an in-line CALL to a program which is specified in the first argument and return the value in the variable passed as the second argument. Every argument after the second is dependent on the program being called. 
    Here is an example of using XEQ in a calculated column and passing the arguments that allow this to easily be recycled for other purposes. I could have hardcoded a lot of stuff so the only argument would be the variable used to return the value but i figured i'd do it this way so it can be used for other things as well.

    The first argument is the target program. The second argument is the variable that holds the value that will be returned by the XEQ function, this variable must be repeated once more as the third or greater argument so its value can be manipulated by the target program. The third argument in this example is the variable that holds the value that will be returned by the XEQ function. The fourth argument is the company code, i'm using the global variable for this but you could hardcode it as well. If you leave it blank (""), my target program will use the global variable %C$. The fifth argument is the two character module code, if you leave it blank (""), my target program will grab it from the first two characters of the target table. The sixth argument is the target table, if you omit the ".M4T" extension, it will automatically be added by my target program. The seventh argument is the target index, if you leave this blank (""), my target program will use "kPrimary". The eighth argument is lookup value that will be used to find records in the target table that begin with the eighth argument, this is needed due to multi-part keys. The ninth argument is the target field, you must include the trailing dollar sign for string fields.
    XEQ("..\CM\Script\ALE_IM_QtyOnSO.pl", nReturnedFieldData, nReturnedFieldData, (%C$), "", "IM_ItemWarehouse", "kPrimary", (dat.ItemCode$), "QuantityOnSalesOrder")​


    Here is the target program. This version uses a file channel which is opened once and stored into the session's script object as a variable that is retrieved each time so it isn't constantly opening the file using a new channel.

    ! XEQ("..\CM\Script\ALE_IM_QtyOnSO.pl", nReturnedFieldData, nReturnedFieldData, %C$, "", "IM_ItemWarehouse", "kPrimary", (dat.ItemCode$), "QuantityOnSalesOrder") SETERR ERROR_HANDLER ENTER nReturnedFieldData, (sCompany$), (sModule$), (sTable$), (sIndex$), (sKey$), (sField$) nReturnedFieldData = 0 IF sCompany$ = "" THEN sCompany$ = %C$ IF sModule$ = "" THEN sModule$ = MID(sTable$, 1 , 2) IF sTable$ = "" THEN GOTO EXIT_HANDLER IF POS(UCS(".M4T") = UCS(sTable$)) = 0 THEN sTable$ = sTable$ + ".M4T" sTable$ = "..\MAS_" + sCompany$ + "\" + sModule$ + sCompany$ + "\" + sTable$ IF sIndex$ = "" THEN sIndex$ = "kPrimary" IF sKey$ = "" THEN GOTO EXIT_HANDLER IF sField$ = "" THEN GOTO EXIT_HANDLER %SYS_SS'ScriptObject'GetStorageVar("nTable_Chn", nTable_Chn) IF nTable_Chn <= 0 THEN { OPEN(HFN, IOL = *, ERR=ERROR_HANDLER)sTable$ nTable_Chn = LFO %SYS_SS'ScriptObject'SetStorageVar("nTable_Chn", nTable_Chn) } IF nTable_Chn > 0 THEN { SELECT * FROM nTable_Chn, KNO = sIndex$ BEGIN sKey$ + $00$ END sKey$ + $FF$, ERR = *CONTINUE nReturnedFieldData = nReturnedFieldData + QuantityOnSalesOrder NEXT RECORD } GOTO EXIT_HANDLER ERROR_HANDLER: GOTO EXIT_HANDLER EXIT_HANDLER: EXIT


    Here is another version that does not use file channels and just reads from the file. I honestly don't know which method is better.

    ! XEQ("..\CM\Script\ALE_IM_QtyOnSO.pl", nReturnedFieldData, nReturnedFieldData, %C$, "", "IM_ItemWarehouse", "kPrimary", (dat.ItemCode$), "QuantityOnSalesOrder") SETERR ERROR_HANDLER ENTER nReturnedFieldData, (sCompany$), (sModule$), (sTable$), (sIndex$), (sKey$), (sField$) nReturnedFieldData = 0 IF sCompany$ = "" THEN sCompany$ = %C$ IF sModule$ = "" THEN sModule$ = MID(sTable$, 1 , 2) IF sTable$ = "" THEN GOTO EXIT_HANDLER IF POS(UCS(".M4T") = UCS(sTable$)) = 0 THEN sTable$ = sTable$ + ".M4T" sTable$ = "..\MAS_" + sCompany$ + "\" + sModule$ + sCompany$ + "\" + sTable$ IF sIndex$ = "" THEN sIndex$ = "kPrimary" IF sKey$ = "" THEN GOTO EXIT_HANDLER IF sField$ = "" THEN GOTO EXIT_HANDLER SELECT * FROM sTable$, KNO = sIndex$ BEGIN sKey$ + $00$ END sKey$ + $FF$, ERR = *CONTINUE nReturnedFieldData = nReturnedFieldData + QuantityOnSalesOrder NEXT RECORD GOTO EXIT_HANDLER ERROR_HANDLER: GOTO EXIT_HANDLER EXIT_HANDLER: EXIT

    The first line of both versions have what's required to be entered in the ALE column calculation for easy reference.

    Here's a sample of it in action.

    EDIT: Attaching the target program files because the forum is really screwing up the code sample.


    ------------------------------
    David Speck II
    Tennessee Software Solutions
    ------------------------------



  • 6.  RE: IM ALE displayin On Sales Orders

    Posted 09-30-2020 05:19
    Attached are samples of my program referenced in my last post.

    ------------------------------
    David Speck II
    Tennessee Software Solutions
    ------------------------------

    Attachment(s)



  • 7.  RE: IM ALE displayin On Sales Orders

    Posted 09-30-2020 09:39
    David,
    ?????? Cool - hadn't seen scripting and pvx execution within ALE before.
    Is there general0 documentation on that aspect of ALE?

    Lee
    --

    Friendly Systems, Inc.

    Sage 100 (Mas90/200), Sage 300 (Accpac), SageCRM, xTupleERP
    Visit us on the web at www.friendlysystems.com
    Office:?? 678.273.4010 ext 4
    Mobile: 404.202.9065
    Fax:?????????? ??678.273.4012
    See our blog at www.friendlysystems.com/blog






  • 8.  RE: IM ALE displayin On Sales Orders

    Posted 09-30-2020 10:43
    @David Speck II​ - One word comes to mind - DAMN!!!

    And to paraphrase a line from the movie Jerry McGuire - "You lost me at "ALEs typically can only be........"

    ------------------------------
    Jeff Schwenk
    FORMER 90M Board Member
    Bottomline Software, Inc.
    Waynesboro VA
    540-221-4444
    ------------------------------



  • 9.  RE: IM ALE displayin On Sales Orders

    Posted 09-30-2020 12:05
    No documentation (beyond the standard ProvideX documentation for the XEQ function) that I'm aware of, just figured this out after analysis of in memory variables (DUMP, which revealed the FNRead function being used by standard sage 100 to read values from linked tables and the "dat" REC prefix used for variables containing field data) and lots of trial and error back when I had a different reason to do this.

    The XEQ function is pretty useful, can also use this technique on fonted text on a panel, a VI field calculation, and IOLists.

    ------------------------------
    David Speck II
    Tennessee Software Solutions
    ------------------------------