Inconsistency between profitable segments

Dear all,
We are processing the J1IIN excise capture for billing document. At this point of time system is throughing the above message.
This problem is coming only for call off order scenario only.
this problem is coming after pactch upgradation from 14 to 19 in ECC 5.0
please do the needful.
With kind regards
jakku
Edited by: sudhakara reddy jakku on Jan 3, 2011 11:19 AM

HI
refer  Note 1290255 - Error in excise invoice during cancellation in J1IH
This relates to J1IH, i guess it should apply to you as wel
Ajay M

Similar Messages

  • Link between profitability segment and profit center

    Hi
    Could you please let me know where we link the profit center to profitability segment. Please let me know the path and complete steps
    Regards,
    Krishna

    Hi,
    These two are independent entities; there is no link between them.
    Regards,
    Eli

  • Assignment between profitability segment and operating concern

    Hi,
    When i get error like, Profitability segment (with some number say 002345) does not exist in operating concern. Then what are the Tcodes i should check in controlling?
    Thanks
    Swetha

    use se16,
    enter the table name ce3****
    - Operating concern.
    In this table u can view all the profitability segments.
    assign points if it is useful.
    guru

  • Profitability Segment : FI Linkage to PA

    Dear All,
    Could Help me how we can link Profitability Segment No from BSEG table to CO-PA area.
    Example: FI Doc No: 1400003 ( In this Document Profitably Segment Value is 12789)
    CO: With Respect to above document, document posted to PA i.e 100569.
    How System co-relate Profit Segment: 12789 to CO PA document 100569 as we dont have master table for Profitability Segments.
    Thanks inadvance.
    Regards,
    Venkat

    Hello,
    The profitability segment what is derived in FI docuement is , as per the derivation strategy COPA.
    Your COPA document is genarated with the Profitability segment mentioned by you.
    There is NO direct relationship between Profitability segment and COPA document.
    When you refer to the mentioned COPA document, system will display full information, in addition to Profitability segment.
    Hope, I have clarified your doubts.
    Please revert for further clarifications , if any.
    Thanks,
    Santosh

  • Inconsistency between a document field and the prof. segment number

    Hi,
    While processing an invoice in one company code for vendor# XXX with the PO# AAAA line# 10, it is showing below error message while posting. Please advise on the below error or fix the issue to post the invoice in to SAP. The using screen T-code is miro.
    Inconsistency between a document field and the prof. segment number
    *Message no. KE396
    *Diagnosis
    A line item was assigned to a profitability segment (number 0008629207) which has the value 0000101000 for characteristic Profit Center. The original document (FI document, sales order, internal order, etc.), however, contains 0000102020 in this field. It is therefore inconsistent with the profitability segment found.
    System response
    The characteristics in Profitability Analysis (CO-PA) must have the same characteristic values as the original document. For example, you cannot assign a sales order to a different customer or product than the one contained in the original sales order. If you wish to fill the characteristics with different contents, you must change the original fields.
    Procedure
    Enter the correct characteristic values on the CO-PA assignment screen. The system will automatically assign a corresponding profitability segment number. If it is not possible to enter values in some of these fields, delete the entire assignment to a profitability segment number and then enter it again.
    As a rule, you should first enter the fields in the original sender document and then make the assignment to a profitability segment.
    What should I do for the above pl ?
    Regards
    Murali

    Hi,
    While doing PGR at VL32N, we are facing this error. Can someone assist.
    Regards,
    Aruna

  • Difference between New G/L Segment and Profitability Segment

    Dear friends,
    Can somebody explain what is the difference between New G/L segment and Profitability segment.
    Thanks, Prakash

    Hi,
    Segment in New G/L is puerly for external reporting purpose.A segment is a sub area of a company for which has separate financial data and which has expenses and losses.For this segment we need virtually complete balance sheet for external reporting purpose.
    Profitability segment is for analysis of profit within the organisation.A Profitability segment is a combination of different characteristic for which we want to analyse sales revenue and cost.These characteristic can be any thing for example customer, product, sales organisation etc.
    For example We want to analyse what is the total sales of product A for customer group B under the sales organisation XYZ. Here profitability segment = Product+customer group +sales organisation

  • Inconsistency between catalog authoring tool & Search engine

    Hi,
    We are on CCM2.0 and SRM5.0 with catalog deployment in the same client as SRM.
    In our implementation we are using master catalog and product catalog. We have very recently deleted around 65 items from our product catalog which is mapped to mater catalog and hence those 65 items are not found anymore in master catalog in CAT (Catalog authoring tool).
    This master catalog when published, we expect that these 65 products should not be available for end users.
    But end users can still see the deleted items through CSE (Catalog search engine). Thus there is data inconsistency between CAT & CSE.
    Has anyone faced similar issue before if yes can you please share the same with us.
    Edited by: Manoj Surve on Mar 24, 2009 7:05 AM

    Run TCODE SE38 program /CCM/CLEANUP_MAPPING to look for errors/orphaned records in test mode.
    If you want to clear out orphaned records uncheck the Test Mode but:
    Warning: This program can slow down a production system as it clears out the memory buffers for user catalog searches and these have to be built up again by the users doing searches.  This can be  hours to days depending upon the size of your system and the number of users.
    In Dev or UAt no problem.
    Hope this helps?
    Regards
    Allen

  • Inconsistency between get-childitem -include and -exclude parameters

    Hi,
    Powershell 2.0
    Does anyone else consider this a minor design bug in the Get-ChildItem command?  
    # create dummy files
    "a","b","c" | % {$null | out-file "c:\temp\$_.txt"}
    # this "fails", returns nothing
    get-childitem c:\temp -include a*,b*
    # this "works", returns desired files
    get-childitem c:\temp\* -include a*,b*
    # this "works", excludes undesired files
    get-childitem c:\temp -exclude a*,b*
    # this "fails", excludes undesired files BUT RECURSES sub-directories
    get-childitem c:\temp\* -exclude a*,b*
    I'm writing a wrapper script around the GCI cmdlet, but the inconsistency between the two parameters is problematic.  My end user will surely just type a path for the path parameter, then wonder why -include returned nothing.  I can't unconditionally
    add an asterisk to the path parameter, since that messes up the exclude output.
    I'm just wondering why Microsoft didn't make the parameter interaction consistent???  
    # includes desired files in the specified path
    get-childitem -path c:\temp -include a*,b*
    # excludes undesired files in the specified path
    get-childitem -path c:\temp -exclude a*,b*
    # combine both options
    get-childitem -path c:\temp -include a*,b* -exclude *.log,*.tmp
    # same as above, the asterisk doesn't matter
    get-childitem -path c:\temp\* -include a*,b*
    get-childitem -path c:\temp\* -exclude a*,b*
    get-childitem -path c:\temp\* -include a*,b* -exclude *.log,*.tmp
    # same as above, but explicitly recurse if that's what you want
    get-childitem -path c:\temp\* -include a*,b* -recurse
    get-childitem -path c:\temp\* -exclude a*,b* -recurse
    get-childitem -path c:\temp\* -include a*,b* -exclude *.log,*tmp -recurse
    If I execute the "naked" get-childitem command, the asterisk doesn't matter...
    # same results
    get-childitem c:\temp
    get-chileitem c:\temp\*
    If this isn't considered a bug, can you explain why the inconsistency between the two parameters when combined with the -path parameter?
    Thanks,
    Scott

    The Get-ChildItem cmdlet syntax is horrific for advanced use. It's not a bug in the classic sense, so you shouldn't call it that. However, feel free to call it awful, ugly, disastrous, or any other deprecatory adjective you like - it really is
    nasty.
    Get-ChildItem's unusual behavior is rooted in one of the more 'intense' dialogues between developers and users in the beta period. Here's how I recall it working out; some details are a bit fuzzy for me at this point.
    Get-ChildItem's original design was as a tool for enumerating items in a namespace -
    similar to but not equivalent to dir and
    ls. The syntax and usage was going to conform to standard PowerShell (Monad at the time) guidelines.
    In a nutshell, what this means is that the Path parameter would have truly just meant Path - it would not have been usable as a combination path specification and result filter, which it is now. In other words
    (1) dir c:\temp
    means you wanted to return children of the container c:\temp
    (2) dir c:\temp\*
    means you wanted to return children of all containers inside
    c:\temp. With (2), you would never get c:\tmp\a.txt returned, since a.txt is not a container.
    There are reasons that this was a good idea. The parameter names and filtering behavior was consistent with the evolving PowerShell design standards, and best of all the tool would be straightforward to stub in for use by namespace
    providers consistently.
    However, this produced a lot of heated discussion. A rational, orthogonal tool would not allow the convenience we get with the dir command for doing things like this:
    (3) dir c:\tmp\a*.txt
    Possibly more important was the "crash" factor.  It's so instinctive for admins to do things like (3) that our fingers do the typing when we list directories, and the instant failure or worse, weird, dissonant output we would get with a more pure Path
    parameter is exactly like slamming into a brick wall.
    At this point, I get a little fuzzy about the details, but I believe the Get-ChildItem syntax was settled on as a compromise that wouldn't derail people expecting files when they do (3), but would still allow more complex use.  I think that this
    is done essentially by treating all files as though they are containers for themselves. This saves a lot of pain in basic use, but introduces other pain for advanced use.
    This may shed some light on why the tool is a bit twisted, but it doesn't do a lot to help with your particular wrapping problem. You'll almost certainly need to do some more complicated things in attempting to wrap up Get-ChildItem. Can you describe some
    details of what your intent is with the wrapper? What kind of searches by what kind of users, maybe? With those details, it's likely people can point out some specific approaches that can give more consistent results.

  • Inconsistency between tbtco and tbtcs

    Hello guys,
    we have a big problem after our HWU upgrade.
    We have copied the content of tbtco into a new table tbtco_copy before the upgrade to save all the job entries.
    After this we have deleted the contant of tbtco. So we had no scheduled jobs for the HWU
    After the HWU we have copied back the content of tbtco_copy into tbtco.
    But now we have a inconsistency between tbtco and tbtcs. This means that all planed and released jobs are not starting (delay goes up).
    How we can start this jobs << Removed >>
    Br
    Christian
    Edited by: Rob Burbank on Apr 19, 2009 4:23 PM

    USer TR: SM65

  • How to update sales order number (KAUFN) characteristic in the profitability segment of the PA document created at the time of service entry sheet confirmation, as a result of shipment cost document

    Hi,
    We have a scenario wherein we create shipment cost documents against delivery. As a result of shipments fully transferred, a PO for freight vendor is automatically created and a service entry sheet confirmation happens. As a result of service entry sheet confirmation, we have Financial accounting, Controlling and profitability analysis documents created. We have a requirement wherein we need to have the characteristic “sales order number (KAUFN)” populated in the profitability analysis document created as a result of service entry sheet confirmation.
    Could someone please advice how could this be attained in COPA. Thanks for your help in advance.
    Regards,
    Sandeep

    Hi Ajay,
    Thank you for the quick update.
    The document is updated to COPA through OKB9 settings. The profitability segment is updated with fields like customer, product, company code, plant, sales area data, profit center, etc; however the sales order number is missing.
    Could you please elaborate further how could FI substitution be implemented to call for the FM COPA_PROFITABILITY_SEGMENT through user exit? Are you recommending the substitution through GGB1? What could be the possible validation to call for the user exit to be implemented?
    Regards,
    Sandeep Kulkarni

  • Missing data: Profitability segment no. in Sale order creation

    Hi Gurus,
    while creating a Sales order, I am getting the Below Error;
    "Error while the Operating Concern being determined"
    Massage no: KE/AD817
    Error: Missing data: Profitability segment no.
    Its Urgent..
    Can anybody suggest....
    Thanks
    BKT

    Hi Bani,
    Please check if note 380102 helps in this case. From the long text of the error message you can find out which charachteristic is responsible for the error message.
    Regards,
    Abhisek

  • Profitability Segment while releasing invoice to Accounting

    Hi,
    I am configuring a scenario in which a debit memo request and a corresponding debit memo will be created. Users want to put in a WBS element at the line item level of the debit memo request (which is fine). Business gave me a GL account in which the profitability segment is a required entry. Now, when I try to release the invoice to accounting, I get an error saying "Field Prof.Segmt is a required field for G/L account" (Msg Number F5808). I know that by changing the field status group on the GL account, i can make it post, but that is not the point. I want to know
    a. Why system is unable to determine the profitability segment (i entered GL account in OKB9 and checked auto determination of profitability segment)
    b. Is it because I am using the WBS element and trying to post to both FI and CO (because, when i use WBS in sales order, during account determination, system looks for KOFK condition type to determine the GL account) and i am not supposed to do that? If i do not use a WBS, then, the posting happens (using KOFI) and the profitability segment is also determined.)
    Please let me know if you need more information.
    Your help is most appreciated.
    Regards,
    Mukund S

    We closed this issue by changing the field status group for the GL account. Though this is not the perfect answer, we had to do it for the business need.

  • In KEPM  error msg ' not all profitability segment can be processed'

    Hi
    PL  HELP ME WITH  THE FOLLOWING  ERROR, when doing   'enter planning'  in KEPM.
    Message no. KG803
    Diagnosis
    You cannot maintain all of the profitability segments in the current transaction. This could be due to the following:
    1. Errors occurred when characteristic values were derived for the profitability segments.
    If this is the case, you can display the error messages under the menu option "Extras -> Error logs -> Derivation".
    In   the   log , it says
    Diagnosis
    The characteristic "PRCTR" ("Profit Center") should be posted to Profitability Analysis (CO-PA). When the system checked the entries, it was established that the transferred characteristic value (" 1000 YB999") is not valid in CO-PA.
    Thanks
    kamala

    Hi Kamala,
    I would kindly ask you to check transaction OKEQN with your relevant planning version you are using in KEPM and where the above error occurs.
    The system checks within derivation (where the error comes from) if the characteristic value is valid for a specific date set within the version (thus trans. OKEQN). If you have PRCTR '1000 102C511' not valid for the date set in the version within OKEQN, then this error message is justified, as the system realises that the PRCTR was not valid by that time.
    Could you please check this? If the profit center is not valid for this date please adjust the date to a more recent one.
    Best Regards,
    Abhisek Patnaik

  • Error in Derivation and Profitability Segment

    Hello Gurus,
    I am two issues, which isnt allowing me to create a sales order in IDES.
    I am referencing a quotation when i want to create the sales order. But i got a warning message 'error in derivation rule' and the log text has
                                                                                    Error occurred in derivation rule. See long text                                                                               
    Message no. K/ 111                                                                               
    CO-PA Characteristic Derivation                                                                               
    Diagnosis                                                                               
    Step 0006 Country Ship-to   > Intern.Reg                                                                               
    No entry in a derivation rule was found for the specified source field
                                                                                    The derivation rule was set up so that an error message appears when 
         this happens.                                                                               
    The required derivation rule entry would need the following source   
         fields:                                                                               
    Country Ship-to                                                      
    I proceeded and the sales order couldnt save. An incompletion log pointing towards the profitability segment was generated. I have put the profit center, yet i have this issue.
    Kindly help resolve it.
    Thanks

    Hi Luqman,
    This issue is realted to the COPA Issue.
    Please Try by giving the Profit Center at sales order Header by giving the Derivation rule and most important thing here is we have to mention the country of ship to here.
    Please Reward IF Really Helpful,
    Thanks and Regards,
    Sateesh.Kandula

  • Problem with profitability segment derivation while posting sales order

    Hello,
    We have the issue of profitability segment being not derived when the sales order is changed using BAPI 'BAPI_SALESORDER_CHANGE'. Subsequent to calling this BAPI we execute a BDC - to derive the profitability segment - which runs well in the foreground but fails in the background. Immediate help in this regards would be of immense help.
    I have searched the forum but could not locate anything useful. There is this thread (Re: BDC for profitability segment VA02 (sales order)) citing the same problem but without answers.
    Kind Regards,
    Indu Shekar

    Probability Segment is maintained but  Profitability Segment is still grayed out.
    The only way i was able to move things to COPA  was to do a project Settlement from
    WBS element to Profitability Segment (PSA).
    But does anyone know if we can move things to COPA during Sales Order (specifically for a project-based Sales Order)?
    Thanks.

Maybe you are looking for