|
Allocations
< Previous Next >
Re: Replace allocation message
Leigh Thompson / The Royal Bank of Scotland
26 Aug 2005 7:18AM ETI'm guessing you are using 4.2, as the fields below have been replaced in 4.4. It looks like you could get into problems with the AllocID, but the AllocReportID introduced in 4.4 might resolve this.
The scenario you've described is similar to fix-42-with_errata_20010501.doc Appendix K 2. Buyside-initiated with Misc Fee computation, to which I've added my 2p worth.
-> Allocation (AllocTransTyp=Preliminary, AllocID=1a)
<- AllocationACK (AllocStatus=Received Not Yet Processed, AllocID=1a)
<- Allocation (AllocTransTyp=Calculated, AllocID=1b, RefAllocID=1a)
-> AllocationACK (AllocStatus=Received Not Yet Processed, AllocID=1b)
-> AllocationACK (AllocStatus=Rejected, AllocID=1b, AllocRejCode=)
-> Allocation (AllocTransType=Replace,AllocID=2a, RefAllocID=1a,)
<- AllocationACK (AllocStatus=Received Not Yet Processed, AllocID=2a)
<- Allocation (AllocTransTyp=Calculated, AllocID=2b, RefAllocID=2a)
-> AllocationACK (AllocStatus=Received Not Yet Processed, AllocID=2b)
-> AllocationACK (AllocStatus=Accepted, AllocID=2b)
Also from the 4.2 spec
"Replacement allocation messages must contain all data for the replacement allocation. Calculated allocations should have a unique AllocID and use RefAllocID to specify the AllocID from the preliminary."
I'm not 100% on this, can anyone else confirm?
regards
> What would be the correct response to the following situation:
>
> A client sends an allocation AllocTransType=preliminary this is accepted
> and then we send back an AllocTransType=calculated.
>
> That message is then rejected by client and then they wish to replace
> the initial allocation.
>
> Would we send an unsolicited AllocTransType=Replace? OR an unsolicited
> AllocTransType=calculated? OR would the client send a new
> AllocTransType=preliminary with a new Allocation ID?
Re: Replace allocation message
Leigh Thompson / The Royal Bank of Scotland 26 Aug 2005 7:18AM ET
|
