hello,
i have a problem that someone might be able to help me.
In my invoice layout, i have an add line item for my products. The
thing is that i want to make another addline item for my services and
this is where i have the problem.
i actually copied the way the first addline item works, by creating a
new table, make the proper relationships, duplicating the script( Sets
variable with INVOICE ID, Create new record, set INVOICE ID, and
return to original layout) for the addlineitem button but still when i
press the button it says "this operation cannot be completed because
the target is not part of a related table".
, is it a problem that i use the invoice id again?? any
suggestions???

vaggelis wrote:

it sounds like you created two line items tables? one for
productlineitems and one for service lineitems? And then hoped to see
them in the same portal? Probably not, but not clear from your description.



one line items table, and if there are 2 source tables (products,
services) that you want to reference, teh line item table:
lineitem_id
invoice_id
item_id ( ie product_id OR service_id)
type (prod, serv)

then you couuld have invoice::lineitems:roducts and
invoice::lineitems::services as branched hopped rels for displaying the
product/service details in teh lineitems portal.


If you are using a bts_lineitems layout:
parse product_id or service_id to variable ($_item)
set $_type = prod or serv as appropriate
parse invoice_id to $_inv
bo bts_invoicelines
new record
set invoicelines::invoice_id = $_inv
set invoicelines::item_id = $_item
set invoicelines::type = $_type
return to original layout


the add line item can be the same single script for both prod and serv,
it is only the input to the initial variables that is different, and
this is dependant on how you are selecting the product or service.

If it is a pop window with filtered portal ...

On 21 Ïêô, 21:50, 105 <corti... (AT) internode (DOT) on.net> wrote:

hello again and i really thank you for your quick answer!
I indeed created 2 addline item table , each for every portal but from
what i read , it's not gonna work!
So, you tell me to create 2 tables ( for products , and services) have
only one addline item table and modify the script ?
right?

vaggelis wrote:

yes to one lineitem tabl
maybe to individual product and services table
yes to modify the script

well you could have 2 lineitem tables (your 'created 2 addline item
table') , but that would mean you needed a portal for each, and what
would be the point? It would also be a design transgression, and
require calculating the invoice total as the sum of the line items in
each lineitem table...). An invoice has associated (related) lineitems.
The line items can be of different types. Simple.

So Invoice table:
invoice_id
company_id
date, subtotal, tax, total, (description)...

InvoiceLines table
invoiceLine_id
invoice_id
item_id
=/- sourceTBL/type
qty, cost, aec_cost_ext...

and a portal on the invoice form, invoice to invoiceLines using
invoice::invoice_id to invoiceLines::invoice_id
(this is a non-acrr rel)


a bts_invoiceLines table; used for the script creation of new invoice lines

script to create a new invoice line


As for the products/services. These can be one table (e.g. items) with a
type field (prod or serv), or 2 tables. There are advantages to each
approach, but one table is arguably better design, but 2 may be more
pragmatic in your situation.


How are you selecting the item (service or product) to add?

On 22 Οκτ, 21:00, 105 <corti... (AT) internode (DOT) on.net> wrote:




i want to ask you some clarifications cause even if i try i need the
opinion of an expert as you are!
you said that the invoiceLine table should be like
InvoiceLines table

regarding that i have one invoice table, one invoiceLine table and one
table with both the products and services
how should i relate the item_id with what? what is =/- ?

and what do you mean i should make a a bts_invoiceLines table ? (;
used for the script creation of new invoice lines )
this is more strange for me..:S

If am trying to fix it and still can't, just waisting time and time..i
am kinda disappointed for not being able to slove such an easy thing..

Can you plz help me?
thanks in advance

vaggelis wrote:

I am assuming you are using FM10


=/- was a typo, it was meant to be +/-
It was unclear whether you were using 2 source tables (products and
services)
- if you were using 2 source tables, a (source) type field in the
invoicelineitems table would be worthwhile
- now that it is clear you are using one source (items) table, which
contains both products and services, a 'type' field (values: prod, serv)
is probably optional, although I would suggest including it. A type
field in the lineitems table could be used for a filter to separately
subtotal services and products on the invoice, for example.



bts_ is just shorthand for 'behind the scenes'
bts_layoutname layouts are used in scripts etc, and are normally hidden
from the user.
there are different ways of creating new related records.
You can use an acrr rel, establish the appropriate key fields, and
create a related record via the acrr rel (either in a portal or single
field) . Which is probably what you are familiar with.

You can also grab the relevant id values, and appropriate data, into
variables ( eg $_inv $_item.... or $_invoice_id, $_item_id...; syntax
variations )
then have the script
- go to the bts_lineitems layout
- create a new record
- the invoicelineitem_id primary key will automatically enter (you have
the key appropriately defined?)
- hard code the lineitems::invoice_id ( = $_invoice_id)
- hard code the lineitems::item_id (= $_item_id)
hard code the type (if used) as prod or serv (from another variable...
- etc (etc can be using lookups to enter cost.. or parse these into
variables as well
- then return to the invoice layout, commit/refresh


The advantage of using a go bts_layout is one less dedicated
relationship. Both approaches achieve the same result. I used to use
acrr, now I routinely use the go bts_layout approach.


If you use the parse into variables approach, use $ (local) and not $$
(global) variables; $ variables automatically clear there values once
the script has completed. Be clear and consistent with naming variables;
think about another developer looking at your script, or even yourself 2
years down the track; how obvious are the names?
example $_inv, $_inv_id , $_invoiceID, $_invoice_id
pick a pattern and generally type to stick to it; sometimes one has to
be prgmatic rather than dogmatic, but generally try to be consistent in
naming patterns (same applies to fields, table names...)


It always takes a while for the basic processes to become familiar
vaggelis; we have all been through it :-) It is easy to get swamped
with the details, think about the process e.g.
- parse relavant values to variables
- go line items layout
- new lineitems record
- hard code details from variables to line items record
- return to parent invoice record

It will come together, keep at it.


regards


Chris