Filtertrouble

dn

Hi

I am going to design a form for delivery monitoring. The form is based on Purchase Line. In form u have some fields to filter, like Vendor, Location Code and Purchaser code. It was easy get all Purchase lines with Vendorfilter and Locationfilter. But I am stuck with Purchaserfilter. It is possible to get all Purchase Line based on Purchasercode in form??
](*,)
Is there anyone who have a good solution??

zeninoleg

You will have to go through your set of records, for each one get a Purchase Header and in case it matches yours, MARK it. Then filter by MARKEDONLY.
Another workaround is to create a flow field on the purchase line taht will have a Lookup formula to the corresponding Header.Purchaser Code field and then do your filtering.

dn

Can you give an example how the code should like. I have tried with Mark and MarkOnly but I did not worked so well. :-k

zeninoleg

OK, here is an example

IF Rec.FIND('-') THEN
  REPEAT
    PurchaseHeader.GET(Rec."Document Type", Rec."Document No");
    IF PurchaseHeader."Purchaser Code" = NeededValue THEN
      PurchaseLine.MARK(TRUE);
  UNTIL Rec.NEXT = 0;
Rec.MARKEDONLY(TRUE);
CurrForm.UPDATE;

I have not tested it but should work. This sets up a filter on the single value. Setting "real" filter (like 1..4, 8 ) is possible but more complicated
Let me know if that helps

Miklos_Hollender

Sigh... No! This is a common error in many questions on this forum: why do you want to build all the business logic into the report, instead of the actual transaction? It will be slow as hell.

Instead, add a Purchaser Code field to Purchase Line table. Add code to Puchase Header - Purchaser Code - OnValidate to update this field on all the lines if it is changed (SETRANGE - FIND('-') - VALIDATE - MODIFY(TRUE), check them out in C/SIDE help). Also add code to Purchase Line - OnInsert to grab the Purchaser Code from the header (GET - VALIDATE, nothing else. Check GET in C/SIDE help).

alwaysguna

Since Buy from vendor no is already available in the purchase lines , its very easier to use that and filter based on that

zeninoleg

This is a common error in many questions on this forum: why do you want to build all the business logic into the report, instead of the actual transaction? It will be slow as hell.

I agree, performancxe will be an issue. I am just coming from my current situation when we were forced to add the whole bunch of fields to the Sales Line table and ........ up to the record limit . Personally I prefer FlowFields, however they are slower ....
You make the choice anyway: either you lose some performance during creation of the order, or during reporting. Usually I look what is done more ofthen and by how much more often.

dn

I created a new field for Purchaser Code in Purc. Line table..and update with data from Header...