Hello,
We have a situation here where we associated an incorrect price map to a price type of a show that has gone on sale. I have ended the date on the wrong price map and have the new correct price map associated with the price type so that all future sales are correct.
How do I fix the sales that happened with the incorrect price map?
Hi Rosa,
Good day.
Tessitura price structure is a bit complicated.
I only can explain what I know.
What is this price structure?
step1, we first need to setup a T_PAMP.
SELECT pmap_no, description, zmap_no, gl_hold_no, gl_realize_no, gl_benevolent_no, desig_code, price_category, inactive, created_by, create_dt, last_updated_by, last_update_dt, create_loc FROM T_PMAP
This links zmap_no with pmap_no and GL code.
Step 2, then the second table is t_subprice.
SELECT zmap_no, pmap_no, zone_no, price, min_price, not_on_sale_ind, editable_ind From T_SUBPRICE
this links zmap_no, pmap_no, zone_no, price together.
it gives a price map no a price.
step3, we need to give each seat a price. the table is tx_perf_pmap
SELECT perf_no, price_type, start_dt, pmap_no, design_no, end_dt, gl_hold_no, gl_perf_realize_no, base_ind, price_category FROM TX_PERF_PMAP --where perf_no=1022
SELECT
perf_no, price_type, start_dt, pmap_no, design_no, end_dt, gl_hold_no, gl_perf_realize_no, base_ind, price_category FROM TX_PERF_PMAP --where perf_no=1022
now price_type, perf_no, pmap_no are sitting in same boat.
so at this stage, you can sale tickets with a real price.
Other links will be tx_perf_mos, tx_perf_hc, these two are Mode of sale, and Hold code.
Now we can check your price map issue.
Part A,
if price type has a wrong pmap_no, what is envolved here?
it will affect step 3 only.
So how to check step 3? check tx_perf_pmap table.
select * from tx_perf_pmap where price_type=@problem_price_type and perf_no in (select perf_no from t_perf where season=@myseason)
Then you need to update the price_type with correct pmap_no.
update tx_perf_pmap set pmap_no=@new_pmap_no where perf_no=@myperf_no and price_type=@myprice_type
notice: as perf_no, price_type, pmap_no are PK, you MAY get errors when you try to do the updates.
Part B,
after some tickets are sold with wrong price map, this could record wrong GL in T_GL_POSTING_HISTORY, if these pmap_no in T_PMAP have different GL codes.
All finance reports are pointing to this table.
if this happened, you need to ask finance people to do some adjustments.
In sales records, T_SLI_DETAIL, T_TRANSACTION should record with incorrect pmap_no.
but I don't think you should change them. So, finally what you should do just these: 1, update tx_perf_pmap table. 2, check t_pmap compare the two pmap_no GL codes. if they are different, you should tell finance people. good luck and have fun. Ben
but I don't think you should change them.
So, finally what you should do just these:
1, update tx_perf_pmap table.
2, check t_pmap compare the two pmap_no GL codes. if they are different, you should tell finance people.
good luck and have fun.
Ben
good day.
If you want to fix the sales record, I don't think it is good idea.
But you can try.
t_sli_detail table has the pmap_no (price comes from T_subprice).
t_transaction table has the pmap_no.
t_transaction will affect T_POSTING_GL_HISTORY.
what you can do?
Answer A,
If pmap_noA and pmap_noB have same gl code, you are lucky.
update t_transaction set pmap_no=@ new_pmap_no where transaction_no=@mytransaction_no and pmap_no=@ wrong_pmap_no
update t_sli_detail set pmap_no=@new-pmap_no where detail_sli_no=@mysli_deail_no
Done.
If pmap_noA and pmap_noB don't have same gl code, you are lucky too.
because you do not need to do these updates.
you need to use SELECT instead of UPDATE.
you should pick up the wrong_pmap_no from t_transaction table.
Then tell finance people, wrong_pmap_no_gl should take off $$$sales.
and correct_pmap_no_gl should add on $$$sales.
have fun.