• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

What are CSTO and SO13?

Stewart

Active Member
Hi List,
I've got an interesting problem... we print consolidated invoices, but have just had a situation where for 1 customer, 2 invoices were produced. The only differences I can see when I look at the F4211 is that the CRR (exchange rate), CSTO (Cost Override Code) and SO13 (Sales Order Status 13) are different. I don't think the CRR is causing the problem, but I can't find where the other fields are being populated from. The problem may be something to do with the Euro conversion we're doing, but any help or advice on direction would be gratefully received

Thanks,
Stewart

Stewart
Customer: Xe/NT/Oracle (and FCC1.5)
Office: B7331/NT/SQL
 

Stewart

Active Member
OK, I've sorted out SO13 (in the words of Homer the Great "D'oh") I checked the Data Dictionary - it is used to signify that the field has been Euro converted.
Now back to the original problem...
One of my colleagues replicated it in Demo Jr, but it occurred on consolidated invoices with multiple exchange rates, so my ideas around CSTO or SO13 are wrong (but I'd still like to know how or where CSTO was getting its value from).
Stupid question #1: Why are the invoices breaking on change of exchange rate?
Stupid question #2: Is there any way to get round it?

TIA


Stewart
Customer: Xe/NT/Oracle (and FCC1.5)
Office: B7331/NT/SQL
 

Sef

VIP Member
Hi Stewart

Only half an answer from me I am afraid.
The CSTO flag is similar to the PROV flag. Whenever the Cost field is manually overwritten by the user, the CSTO field is set to '1'. This will also exclude this record from cost updates (R42950 or updates triggered through P4205 or R42800).
I believe that all lines for which no F4105 record exist eg extra freight charges also have this field populated.
Maybe have a look in the sales ledger F42199 whether your cost (UNCS) has changed, when the flag changed from 0 to 1 and what program (PID) was responsible.

As for the invoice program, a large number of level breaks are set in this UBE (eg Customer, Payment terms, Currency code and I guess exchange rate as well (Although I can't recall processing any orders with multiple exchange rates and I couldn't see Exchange rate in the BSVW of the main section).
I guess the reason for this break is be to consistent with Sales update where individual pay items are written to A/R (F03B11) where changes in currency and/or exchange rate occur.
If a pay item would be written to A/R with a mixture of exchange rates, the conversion from AG (gross amount) to ACR (Foreign amount) would not be consistent and would cause integrity issues. As such I don't believe it would be advisable to modify the invoicing program, but since the invoice program only creates a pdf and only updates KCO,DOC,DCT and IVD (and writes to F42199), there is no technical reason not to mod R42565.

Hope this helps a little in your quest.

Rgds,





Sef van den Nieuwelaar
Australia
B732 on NT, XE on NT, B732/A73 on AS400, B733 on NT
 

Stewart

Active Member
Thanks Sef,
Maybe the F03B11 is the reason for the break, but I couldn't see anywhere in the R42565 that would cause a level break at change of exchange rate, although that doesn't mean it doesn't exist!

My intrigue about the CSTO was because it was blank before Euro conversion, and 0 after, but I guess that has nothing to do with the level break.

Thanks again,

Stewart
Customer: Xe/NT/Oracle (and FCC1.5)
Office: B7331/NT/SQL
 
Top