in converting an accounting module (one that involves 'journalising' a
purchase order and its line items), the Journalise script process needs
to be modified from that used in FM6 to force a refresh, or else the
results are quite different. As it took me some time to pin down (wade
through the variations), and having encountered other variations on FM7
and its quirky refresh requirements, I though this may be of interest
to some. Others may be well aware of it.


Scenario: a purchase order with 6 line items, some of which have the
same account. The object is to loop through the line items portal, group
items by account by grabbing the account number to a global and using
it as a key , and create a single record in the Purchase Journal for
each account, and enter the sum for items by account. Simple enough, and
used numerous times in FM6.

6 line items, 3 accounts should result in 3 Purchase Journal records;
leave out the Force Refresh and 6 PJ records will result. Which is often
a bts event.
The force reshresh requires going to another layout, then returning to
the (original) PO layout, an additional global needs to be set to jump
back to the correct portal row. The key to file C (PJ) just for simple
description, is account






A PO
B POLI
C PJ


• Allow User Abort [ On ]
• Go to Field [ B::PO ]
• Go to Portal Row [ Select; First ]
• Loop
• If [ Get ( PortalRowNumber ) ? Count ( B::PO) ]
• Set Field [ A::key; B::Acct ]
• Set Field [ C acrr::ACCT; B::Acct ]
• Set Field [ C acrr::PO; A::PO ]
• #grab Acct for rel key
• Set Field [ A::g_Acct; B::Acct ]
• Set Field [ C acrr::TotAmt; Sum(B 2::Amt) ]
• #FORCE REFRESH
• #first grab row to return to
• Set Field [ A::_PortalRow; Get ( PortalRowNumber ) ]
• Go to Layout [ "B" (B) ]
• Go to Layout [ original layout ]
• Go to Portal Row [ A::_PortalRow ] [ No dialog ]
• #continue
• Go to Portal Row [ Next; Exit after last ]
• Else
• Exit Script
• End If
• End Loop



regards

Chris Brown
Neurosurgery
University of Adelaide