In actual usage, you probably would never start with the TranGLC table. You would always start with another table and link to the TranGLC table. The link does not happen automatically. You have to do it manually. If you have tables in BAQ that are not linked, you can end up with a cross join where the database tries to output every combination of records in one table with every record in the other table. That can definitely hang your workstation.
To do this specifically for the PORel table, try the following. In BAQ, select the PORel table and then the TranGLC table. Set a criteria on the PORel table to get a range of about 20 purchase orders. Then select the TranGLC table and place a criteria on it where the field TranGLC.RelatedToFile = the constant "PORel". Click on the chain link, then click on the TranGLC table, then click the PORel table. With the link still selected, add 4 "TableRelations" lines:
PORel.company = TranGLC.company
PORel.PONum = TranGLC.Key1
PORel.POLine = TranGLC.Key2
PORel.POLineRel = TranGLC.Key3
This responds pretty quickly here.
To do this specifically for the PORel table, try the following. In BAQ, select the PORel table and then the TranGLC table. Set a criteria on the PORel table to get a range of about 20 purchase orders. Then select the TranGLC table and place a criteria on it where the field TranGLC.RelatedToFile = the constant "PORel". Click on the chain link, then click on the TranGLC table, then click the PORel table. With the link still selected, add 4 "TableRelations" lines:
PORel.company = TranGLC.company
PORel.PONum = TranGLC.Key1
PORel.POLine = TranGLC.Key2
PORel.POLineRel = TranGLC.Key3
This responds pretty quickly here.
--- In vantage@yahoogroups.com, Chris Thompson <chriselectrix@...> wrote:
>
> When I add the TranGLC to the BAQ and test it, the whole BAQ (and Epicor) locks
> up and eventually says 'Not responding'.
>
> If I filter on a criteria on Key1, it will load the results pretty quickly.
>
> This is happening a lot now - to the point where you have to add lots of
> criterias and also only do BAQs for one table then join them in Crystal or in a
> Dashboard.
>
> It can't be anything wrong with the BAQ itself, especially when only trying one
> table.
>
> Any suggestions?
>
>
>
>
> ________________________________
> From: al2trace <allen.larsen@...>
> To: vantage@yahoogroups.com
> Sent: Thu, 31 March, 2011 22:26:04
> Subject: [Vantage] Re: Link GL Account on PO Releases to GL Account
>
> ÂÂ
> It depends on which version you are using but if you are asking the question,
> you are probably in version 9.x . In earlier versions, the G/L account was a
> field in the PO release record (if I remember right). Now it is in a table
> called TranGLC. If you run a BAQ against that table you can see how it is
> structured. The data dictionary won't help a lot. For this purpose, you can set
> a criteria for the field called "RelatedToFile" equal to "PORel". Review the
> fields "Key1", "Key2" and "Key3". They should be equal to your purchase order #,
> purchase order line and purchase order release, respectively.
>
> --- In vantage@yahoogroups.com, Chris Thompson <chriselectrix@> wrote:
> >
> > I am trying to create a BAQ which looks at the PO releases and if a particular
>
> > part has a particular part class, I need to see which ‘GL Account’ has been
> >
> > assigned to it on the Purchase Order Entry > Releases > Detail tab.
> >  ÂÂÂ
> > Where is the GL account information held and what is the link between that and
>
> > the PO Releases?
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
> When
>
> [Non-text portions of this message have been removed]
>