Translate

Friday, January 30, 2015

Hide Process Table in Oracle Screen


Please follow this way to safely hidden the processes table.
(Have to do this responsibility by responsibility)

Example for Payable

1) Navigate to Sysadmin> Security> Responsibility> Define

2) Query the responsibility that has the processes tab which is to be

removed.

3) In the lower part of the Responsibilities form you will see 3 tabs :

>> Menu exclusions

>> Excluded Items and

>> Securing attributes.

4) Select the Menu Exclusions Tab and in the type field select Function
--Note: the processes tab is actually a function of the type "process"
5) In the name field select the processes you want to be excluded from this

responsibility.

After put all of three list , the "PROCESSES" table will be removed from

Payable Navigator.

Type Name Description
Function 1099 Reporting Process Navigator Definition for 1099

Reporting Process
Function Procure to Pay Process Navigator Definition for Procure to

Pay Process
Function Close Payables Accounting Period Process Navigator

Definition for Close Payables accounting Period Process

The all of pages under this PROCESSES TAB is only the procedure guide which

is created by Oracle, this is only reference document (just like user

guide) and without any impact for current actual procedure in system.

That means, If we hidden PROCESSES TAB, end-user can not see this PROCESSES

TAB page and no any impact for other daily / monthly business, like month-

end closing / transaction booking etc.

10. Save changes 

Wednesday, January 21, 2015

Sub Ledger Accounting Oracle

Subledger Accounting (SLA) plays a central role in standardizing and implementing accounting policies, leveraging the R12 ledger architecture and legal entity enhancements.
As organizations continue to evolve, merge, acquire and divest, having ERP Applications that can easily and quickly adapt to structure changes is essential to their needs.
The R12 architecture ensures that legal compliance issues are isolated at the Legal Entity level, and the operation and security issues can be setup at the Operating Unit level. This, along with Multiple Organizations Access Control (MOAC), enables multiple legal entities and multiple lines of business—operating as a single operating unit with a single subledger and place—to implement standard processes and policies.
SLA is the repository of policies that control the accounting convention (one of the 4C`s) that’s tied to a ledger and ensures reconciliation of all the journals before they hit the ledger balances.
SLA features ease the pain of implementing accounting policies by taking away the need for customizations with certain setups (e.g. multiple liability accounts for different supplier types, matching entries for cost recognition and revenue within a single legal entity, multiple ledgers for regional reporting needs, etc.).
1





















These are the SLA components that enable policy implementations:
Journal Line Type (JLT):
Defined for particular event class such as Accounting of an Invoice, JLT controls basic attributes of a journal line—balance types, the side, etc.—that determine the nature and treatment of that journal line.
Seeded JLTs may need extensions for implementing accounting policies. JLTs are defined for a seeded list of events, restricting them to modules within EBS. A separate, licensable product, Financials Accounting Hub (FAH), leverages the same structure but allows a definition of events to import accounting information from third-party applications.
Journal Entry Descriptions (JED):
JEDs determine the description of a journal line. We can add more information to a seeded journal line so that journal-based reports have richer information and ease reconciliation and other processes. Using the conditions and priorities, JEDs can carry attributes or different descriptions for the same journal entry.
Note: It’s best practice to leave one as default that uses a seeded description if none of the conditions are met.
Mapping Sets:
Similar to lookups and lookup sets, mapping sets store mapping of a transaction attribute to accounting segment values/flex field. The mapping sets are Key elements when we are mapping a particular segment (i.e. natural account to multiple supplier types.)
Account Derivation Rules (ADR):
ADRs are the rules which help implement accounting policies. They link source values in order to fetch target valuesSetting up the extensions to Seeded SLA involves creating custom sources and using mapping sets to map them to target segment values.
Oracle provides a list of seeded sources which can be leveraged (using PLSQL code) to derive custom sources or be mapped to segment values using mapping in the account derivation rules.
It’s good practice to refer to the definition of the sources (sources are extracted in seeded views by Oracle and may have a different meaning than what its name might indicate).XLA_EVENT_SOURCES and XLA_AAD_SOURCES are the tables to use for identifying the view and the exact column name for your source. (To see it in the tables, you must assign a source on some ADR under AAD).
Journal Line Definition (JLD):
JLD brings all the elements together. It ties the JLT, descriptions and accounting rules to an event class. Any extensions done to SLA involves creating a custom JLD, copying the seeded one, and laying the changes on top.
Application Accounting Definition (AAD):
The AAD is a collection of JLD for a Module. SLA patches bring over new versions of these AADs (implemented as packages). Thus, the best practice is to copy over the seeded ones and make extensions on them. This means that, each time Oracle enhances the AAD, you need to analyze any subsequent patches to ensure the extensions are overlaid on a new copy. 
Sub ledger Accounting Method (SLAM):
The SLAM is collection of all the modules combined. It links the AAD collectively to a ledger.
For a detailed guide on how to implement SLA for your organization, refer to the Oracle Sub – Ledger Accounting Implementation Guide.

Tuesday, January 20, 2015

Difference in MRP and ASCP Oracle

The main difference between Material Requirement Planning and ASCP is that MRP doesn’t look at the constraints (material or resource) when planning the material supply. It assumes infinite capacity and plans the supply on the same day as the shipment date of the assembly. To prepare an achievable production schedule, planners have to do Capacity Requirement Planning (CRP). CRP presents the load chart of the machines including available hours and required hours, but the production schedule is still far from complete. So now a third tool is required to realign the planned production jobs on each machine and finally come up with an achievable production schedule.

The challenge does not end here. Although we have an achievable production schedule, but is it going to be cost effective? Are we building the product in the right sequence so we do not have to carry excess inventory? Are we minimizing the change-overs? Do we have means to decide which supplier to source the material from so as to have least impact on the production/shipping schedule still keeping the cost low? How do I tell MRP that every vendor has a different work schedule and our calendar does not match with theirs? The list goes on. MRP does not have answers to these questions.

ASCP comes with answers to all the above questions and more. Sounds too good to be true. So the clients begin lining up to buy the product. They invite consulting firms to implement the product and wait for the grand returns. Since they are eager to get the results, they implement ASCP with its functionality enabled, enforce capacity constraints (ECC), Optimization turned on, vendor constraints enabled, dynamic safety stock calculation, and automatic release of supply orders from the planning workbench, online planner and so on.

Wednesday, January 7, 2015

Oracle GOP Functionality

REQUIREMENTS

1. Why is the Expected Available Quantity set to 10 even though the

availability cannot be met for the requested date ?
2. How is the Expected Arrival Date calculated ?

SOLUTION

1. The Expected Available Quantity is not related to how much is available

on the requested date. There is no field in Order Promising that shows you

the quantity available on the requested date.

2. To check if there is Available Quantity on the requested date you should

compare the Expected Date and Requested Date to infer that there is no

quantity available on the Requested Date. I.e if these dates do not match

this implies there is no availability on the requested date.

3. The Expected Availability On Requested Date is a redundant field and GOP

does not have logic currently to derive the value in this field (RUP1 --

January 2012).

In the Examples provided The ATP Rule is not Lead Time based, it is a

regular ATP rule but with a Infinite time fence corresponding to the Total

Lead Time. The results are correct, and as expected for the Supply Chain

Search enabled ATP mode with an Infinite Time Fence.

TEST CASE 1.

1. Why is the Expected Available Quantity set to 10 even though the

availability cannot be met for the requested date ?

The Expected Available Quantity is not related to how much is available on

the requested date. It just shows the quantity of the promise, and this is

showing up as 10 since the requested quantity is 10. There is no field in

OP that shows you the quantity available on the requested date.

2. How is the Expected Arrival Date calculated ?

First the ship date is calculated. Since no supply is found until the

Infinite Time Fence, which is on 14-Dec (based on sysdate + Total Lead

Time) the Expected Ship Date is set to 14-Dec. Expected Arrival Date =

Expected Ship Date + Lead time (since no transfer lead times seem to be

setup) which is again 14-Dec.
TEST CASE 2.

3. How is the Expected Arrival Date calculated --- The date was calculated as

request date + lead time. Should the Arrival date be calculated as being

the same as the requested date if the lead time can be met ?

This is not 'Lead time based' promising mode. In this scenario, the request

date is beyond the Infinite time fence. Hence, availability is assumed to

be infinite on this date, and the Ship and Arrival Dates equal the

requested date.



Org has 5 day shipping calendar. (Monday to Friday are working days,

Saturday and Sunday are non shipping days).
Customer has requested to ship the materials on Sunday (20th Nov-2011).
Received order 8-Nov-2011 and Item lead time is 3 days.

System will suggest schedule ship date = 18th Nov 2011
(this is less than the non shipping day the customer requested)


SOLUTION

GOP uses calendar days(7 days) for lead time calculations.
For a 5 day shipping calendar GOP will back up to the previous working day

as long as item as item can be manufactured on or before that date.

Monday, December 15, 2014

Oracle Standard Pegging

Standard Pegging

The standard pegging process makes two passes through the demands and supplies.

First Pass

The planning engine groups demands into daily windows. It does not use profile option MSO: Demand Window Size. The first window starts at the first demand date and the last window ends at the end of the planning horizon.
For example, the demand window size is 1 day, the first demand is due on day 5. The first demand window is from day 5 to day 5, the second demand window is from day 6 to day 6, and the third demand window is from day 7 to day 7.
Demands in each window are sorted by demand priority in ascending order.
The planning engine groups supplies into daily windows. It does not use profile option MSO: Supply Window Size. The first window starts at the first supply availability date and the last window ends at the end of the planning horizon.
For example, the supply window size is 1 day, the first supply is available on day 7. The first supply window is from day 7 to day 7, the second supply window is from day 8 to day 8, and the third supply window is from day 9 to day 9.
Supplies in each window are sorted by type using the following order:
  1. Firm supplies
    1. On-hand
    2. Receipt shipment, intransit shipment, payback supply (Oracle Project Scheduling)
    3. Work order (firm), job by-product supply (firm), purchase order (firm), non-standard jobs, non-standard job by-product supply (always considered firm)
    4. Purchase requisition (firm)
  2. 2. Existing supplies
    1. Work order (non-firm), job by-product Supply (non-firm), repetitive schedule, repetitive schedule by-product supply, flow schedule, flow schedule by-product supply, purchase order (non-firm)
    2. Purchase requisition (non-firm)
  3. Planned supplies
    1. Planned order (firm), planned order by-product supply (firm). You can raise the pegging priority of firm planned orders by releasing them.
    2. Planned order (non-firm), planned order by-product supply (non-firm)
The supplies in each type are sorted as follows:
  • On-hand: Lot expiration date and then quantity in ascending order to use expiring lots first. A demand pegging to an expiring lot must have its demand date earlier than the lot expiration date; therefore, some expiring lots may not peg.
  • Firm: By date in ascending order within each type.
  • Non-firm: By quantity in ascending order within each type.

Second Pass

The planning engine begins from the first demand window and pegs demands by demand priority to supplies of the first supply window. If necessary, it continues the pegging process with the next supply window.
As all demands in the each demand window are pegged, it moves to the next demand window and pegs as it did in the first demand window
Unpegged supplies are posted to excess.
In this example, demands D1 and D2 are sorted by priority in ascending order and supplies S5 and S6 are sorted by type. Pegged entities are connected by arrows.
Pegged Entities
the picture is described in the document text
Standard Pegging Example
This example shows standard pegging for two items. It begins with various settings and then shows the pegging for each item.
Profile option MSC: Use FIFO Pegging is No.
Plan option Peg Supplies by Demand Priority: Cleared.
In standard pegging, the planning engine uses 1 as the value for MSO: Demand Window Size and MSO: Supply Window Size and ignores the entered values.

Item A101 Pegging

This diagram shows the demands, supplies, and pegging information for item A101. Demand priorities are in parentheses, pegged entities are connected by arrows, and split supply quantities are in brackets.
The first demand window starts on day 3 at the first demand date.
Supplies in the first supply window [day 1] are pegged in the following order:
  • On-hand of quantity 25 on day 1 and demand quantity of 100 on day 3
  • Firm planned order of quantity 10 on day 1 and demand of quantity 100 on day 3
  • Non-firm planned order of quantity 50 on day 1 and demand of quantity 100 on day 3
Supplies in the second supply window [day 2] are pegged in the following order:
  • Firm planned order of quantity 5 on day 2 and demand of quantity 100 on day 3
  • Non-firm planned order of quantity 35 on day 2 (for partial quantity 10) and demand of quantity 100 on day 3
  • Non-firm planned order of quantity 35 on day 2 (for partial quantity 25) and demand of quantity 100 on day 4
Supply in the third supply window [day 3] is pegged as non-firm planned order of quantity 75 on day 3 and demand of quantity 100 on day 4
Pegged Entities

the picture is described in the document text

Wednesday, November 12, 2014

Oracle Gantt Chart Scheduling

Interactive Scheduling Using the Gantt Chart

Interactive scheduling provides a time-phased graphical interface to your plan's scheduled activities and resources to help resolve inevitable shop floor problems. It lets you troubleshoot exceptions arising from resource or material constraints; overloaded or underloaded resources; absenteeism, or machine downtime. Use interactive scheduling to pinpoint affected jobs and operations and simulate changes towards effective, timely resolution.
You can use the Gantt Chart for plan type Constrained.

To access the Gantt Chart

Follow the appropriate navigation path as shown in the table:
Current WindowNavigation
Exception Details window[Select any field] > [right-click] > Gantt Chart
Supply window[Select any field] > [right-click] > Gantt Chart
Resources windowClick the Gantt Chart button
NavigatorSelect a resource>[right-click]>Gantt Chart
Select a resource and click the Gantt chart button and the bottom of the navigator window.
The title in the Gantt Chart window reflects the view selection that you make-- Orders View, Resource Activities View, or Supplier Capacity View.
When the Gantt Chart opens, there are two group boxes.
  • The first group box displays "Gantt Chart" and the instance and organization selected.
    The icons provide options for various Gantt chart views.
    The Preference set determines the user preferences for Gantt chart display options.
    The Go To option enables you to go to a specific date when the Gantt chart is displayed, and the Today option enables you to view the current date.
  • The next group box displays the view that is selected, with a left and a right pane.
    The folder icon enables you to save selected settings.
    The View field enables you to select a view.
The left pane displays a tree structure with multiple columns. The columns are dependant on the view that is selected.
Depending on the view selected, the left pane displays a list of resources, orders, or item suppliers.
To select a view, use the drop down menu in the left pane.
The right pane panels begin at the plan start date. To go to another date, you can:
  • Scroll horizontally
  • Enter a date and time in Go to: and press Enter. To go to today, click Today.

The right panel header also shows the planning granularity that was used for a certain portion of the planning horizon. This is different from the display granularity. For example, you may be viewing the Gantt chart in weekly buckets, but the portion of the planning horizon you are viewing may have been scheduled at the day level of granularity

Tuesday, October 21, 2014

R12 Advanced Supply Chain Planning ASCP Supply Chain Bidirectional Alternate Sourcing or Circular Sourcing Situation

R12 Advanced Supply Chain Planning ASCP Supply Chain Bidirectional Alternate Sourcing or Circular Sourcing Situation and Strategic Network Optimization SNO


Material should be transferred between Org M1 and Org M2 so as to balance any excess inventory at either organization.

USUALLY,  M1 and M2 obtain material from Organization S1 - where it is made - BUT, for some reason S1 is running out of capacity.

So, ASCP needs to check if quantity  is available in M1  and plan a Transfer to M2, since M2 cannot get it from S1,
and vice versa if M1 needs material and cannot get it from S1.

In a Constrained Plan, you could set up Sourcing Rules for M1 with Rank1 Transfer From S1, Rank2 Transfer from M2.
Similarly for M2, Rank1 S1, Rank2 M1.  Will that work, or could it cause unnecessary demand by M1 on M2 and vice versa?

The idea is to oblige M1 and M2 to help each other out if they can, without creating demand that they cannot accommodate.

Does anyone have a suggested approach on how to set this up so that the system is smart enough to do this automagically?


Answer
------
ASCP will not handle circular sourcing unless you are using a DRP plan type which can do inventory rebalancing.  But ASCP/DRP plan
types are not what you would want here.

So I would consider handling it in a couple of ways:

1) Do not plan for this situation, rather handle it manually.  As you said “USUALLY” S1 would supply, so plan for the usual case.
   Manual process is good for exceptions.

2) Run a plan with a sourcing rule that works in one direction only (M2 -> M1).  You can then run another plan with a sourcing
   rule in the opposite direction.  Then compare the results

3) Just a general note and something to keep in mind - if circular sourcing is a true requirement for the customer -  then perhaps
   a consideration could be using ASCP with SNO to refine the sourcing matrix.  SNO can support circular sourcing relationships
   and pass the decisions on to ASCP for tactical planning purposes.  The idea would be to let SNO resolve the relationship then
   pass the sourcing assignment set into ASCP without the circular relationship.

   Basically, If implemented in an integrated manner with ASCP, the sourcing decisions made in SNO can be reflected in the ASCP assignment
   sets, which should remove the overlapping circular sourcing rules when sent into ASCP.  Meaning, SNO can resolve the inventory balancing
   questions at a higher level and your resulting plan would be what Danny mentions in bullet point 2, but time phased.   The assignment
   sets sent back to ASCP would not reflect    the circular sourcing relationship as it would be disabled when and if the other shipping
   direction kicks in.  SNO wouldn’t circular source in the same period, so you’d see time phase assignment sets.
If you have a loop, check out: