id|Felels|Subsystem|Lers|llapot|submitdate|submitter|longdesc

spnu200742629|lovasg|ng_Replica|I027_V_HW_SALES nem trldtt|Submitted|2016-08-18 16:

24:54|takacsed|a del_day eljrs vlheten hibzik: nem takartotta ki a hw_sales tblt.
Imnt trlted nekem a 08.09-i adatokat a tblkbl.
Viszont az I027_V_HW_SALES tblban mg ltom a rgi adatokat.
A tbbi tblban nem ltom a rgi adatokat.
Order: 1-34622561996
Submitted: 2016.08.09. 14:14:35
Rgi id-k
control_table_unid='338'
service_event_unid in ('158' , '160', '161')
service_fee_unid in ('139' , '157', '163')
discount_unid in ('331', '332', '366', '367')
hw_sale_unid in ('338')
j id-k
control_table_unid='821'
service_event_unid in ('2006' , '2007', '2008')
service_id_for_status in ('1-FWLCE9F', '1-FWLBCKD', '1-FWLBCLQ')
service_fee_unid in ('1797' , '1811', '1819')
discount_unid in ('4586', '4587', '4638', '4642')
hw_sale_unid in ('822')

spnu200742611|lovasg|ng_Replica|A ServiceEvent.CommitmentDuration nem lehet res|S

ubmitted|2016-08-18 13:41:09|takacsed|Mller Pter:
A ServiceEvent.CommitmentDuration nem lehet res, mert ebben kell a hsgid hossza, ezt
sehol sem tudnnk kezelni ha nem jn pontosan!
A ServiceEvent.CommitmentDuration kitltsre szksg van, s a hsgid hosszt kell megadni
is, ha a hsgkedvezmny nem jr le. Az IFRS szempontjbl nem rdekes, hogy utna megkapja-e
kedvezmnyt (csak a hsg alatti idtartam van jelentve). Ez gy megoldhat?

Pusztai Pter:
@ Karesz, krlek ahogy telefonon is megbeszltk dertstek ki hol rejtzik a commitment dur
ation termk szint attribtumknt s mdoststok a ServiceEvent.CommitmentDuration mez tl
ikjt gy, hogy ha OLI szinten nem tallhat Duration, akkor termk szintrl kerljn kiolva

spnu200742582|lovasg|ng_Replica|Ugyanazon a napon indtottak olyan Modification or

der-ekre StatusChange mdosts|Submitted|2016-08-18 10:24:03|takacsed|Karesz:
nem az eredeti orderek kerltek trlsre, akkor tnyleg nem lett volna szabad ilyen reko
rdoknak keletkezni. Ezekben az esetekben az eredeti Activation order-ek eljutott
ak Completed-be, mi csinltunk is hozzjuk megfelel SE/SF/SD rekordokat. A ServiceSta
tusChange rekordok pedig azrt jttek ltre, mert mg ugyanazon a napon indtottak olyan M
odification order-eket (tech. vlts ill. djcsomag mdosts), amikben leszereltk az SE rek
rdok alapjait ad hsgeket.
Az albbi felttelek teljeslse esetn trlnnk a vonatkoz SE/SF/SD/HW rekordokat:
- az eredeti SE mr Completed sttuszban van (ez elvileg nem is lehet mshogy, hiszen
mg folyamatban lv aktivls order esetn hogyan s mit is terminlhatnnk egy msik orderb
- az SC rekordot ugyanabban a futsban hoznnk ltre (ugyanaz a control table uid)
- az SC rekordot a grace period alatt trtn terminlst figyel programg hozta/hozn ltre
Megvalsts szempontjbl egyszerbbnek tnik, ha a jelenlegi funkcionalitson nem mdostun
m egy extra gban hasonltjuk ssze az adott futsban ltrejtt SE s SC rekordokat, majd sz
esetn mindkettt trljk a kapcsold rekordokkal egyetemben.
Peti:
megfelelnek tallom a megoldsi javaslatot, azt kln dvzlm, hogy nem nylntok bele a me
ba, hanem inkbb egy j eljrs kapn el s trln az rintett rekordokat.

Mivel a kiegszt szolgltatsok esetn (amelyeket nem kell fizikailag ltesteni) vagy hs
bbts esetn van esly az albbi szituci kialakulsra (pr 10 percen bell le tud teljes

an Order, amiben csak annyi trtnik, hogy megrendelnek egy hsges HBO MaxPack-ot vagy
mondjuk egy meglv hsget meghosszabbtanak), ezrt indokolt az albbi kezels megvalsts
spnu200742557|lovasg|ng_Replica|Kiegszt szolgltatsnl is root asset asset_integ_id|Subm
itted|2016-08-17 16:33:14|takacsed|A problma a service_event_id-val van a kiegszt sz
olgltatsbl (IPTV HBO MaxPak) kszlt SE-nl.
Annl az SE-nl is ennek kne lennie (ez a root asset asset_integ_id-ja): 1-FWQD20Y
ServiceEventId Id of root-product?s asset integration id in the order.

spnu200704180|pusztaip|ng_Replica|Contact data handling|Submitted|2015-11-20 15:

02:25|kovacst|- User name:
User name and User profile / Screen Name and View Name:
Date/ time:
Process name:
MT ID & Order ID / Test Data:
TestCase step / Steps to reproduce the issue :
workaround:
Justification if the Defect is A-Critical or B-High severity:
The contact data provided in IBF by partner should be populated/mapped at techni
cal contact fields of the created order in Siebel.
The following automata processes are involved:
Aktivls KbelNet
Aktivls NDSL
Aktivls OptiNet
ISP vlts ADSL
ISP vlts KbelNet
ISP vlts NDSL
ISP vlts OptiNet
Lemonds
Mdosts KBH
Sebessgmdosts
Aktivls KBH ADSL
Aktivls KBH NDSL
spnu200704179|pusztaip|ng_Replica|RST modifications|Submitted|2015-11-20 14:49:5
0|kovacst|User name:
User name and User profile / Screen Name and View Name:
Date/ time:
Process name:
MT ID & Order ID / Test Data:
TestCase step / Steps to reproduce the issue :
workaround:
Justification if the Defect is A-Critical or B-High severity:
Replica Status Table (RST)
During the testing process the below requirements are raised about the RST funct
ionality:
1.
When a Siebel activation order reaches ?Done? status, the RST should stor
e the Service ID of the new subscription in a new field (i.e.: the A-number of a
WS internet subscription)
2.
A new field should be created to store the WS partners own order id. On S
iebel side it should simplify the search on the PartnerPortal.
3.
The installation address should be stored and displayed in every case in
the right field.

Missing parameters check in Replica

The requirement is a new business check, which inspects the integrity of the par
ameterization and parks the record if it is incomplete. The new function should
check these conditions:
?
Is there a record in the Replica parameter table for the SR fourplet? (m
andatory check)
?
Is there a record for the combination of the WS partner id and the fourp
let id in the proper parameter table?
?
Does the ordered product exists in the parameter table?
?
If it does not exists, it should be checked in the Siebel product direct
otry. If it can not be found in the Siebel, the Replica should decline the reque
st (?Order for non-existent product").
If one or more of the above checks fails, the request should be put to "Parking"
state - similar to the existing open order check. In this case the status descr
iption should contain one of the above possibilities:
?
?Missing fourplet admin? - means no record found for the SR fourplet in
the parameter table
?
?Missing fourplet admin (BP_ID)? ? means no record found in the paramete
r table which assigns the BP id to the WS partner id ? fourplet id combination.
?
?Missing product parameters? ? means the ordered product does not exists
in the parameter tables, but does exists in the Siebel.
The parking function also should be modified to handle these cases. The fourplet
parameter table should be extended by one field to control the implemented chec
k for each scenarios.