Translate

Tuesday, April 14, 2015

JDE Technical Interview Questions

1.How many numbers detail sections possible in a report template?
A)Multiple. But the physical page size of report template should not exceed 45 inches in length and width. Report template that exceeds this limit might faces problems at runtime…

2.How many detail sections can be added in a report template using report director?
A)Using the Director, only one detail section can be inserted in the report template. Later RDA can be used to enhance the report template and add extra detail sections

3.How many numbers (max) of Page Header/Page Footer sections possible in a report template?
A) Only one

4.How many numbers (max) of Report Header/Report Footer sections possible in a report template?
A)Only one

5.Can a business view be attached to a Page header section?
A)No. Business views can be attached to details sections only

6.what is the default font used to generate PDF reports in E1?
A)Arial

7.Is it possible to print the attachments that are inserted in the report?
A)No. They are just useful to explain the functionality of the report, any special logic used, documenting the changes etc.,

8.The properties and format of report headers and footers and of page headers and footers are similar to which detail section?
A)Group section

9.Report Templates Vs Batch Versions
A)Report templates are master specifications of the report. It defines the data used, how the data is
Selected , sorted, displayed, and formatted etc.
Batch versions read the master specifications from the associated report template and over ride one or more specification of the report template like:
• Section layout
• Section data selection
• Section event rules
• Section database output
• Section sort sequence
This concept allows creating requirement specific reports (versions) without touching the Master (i.e Report Template). Basically you create one report template and create multiple version by overriding the specifications.
Report Power points:
·      Report template is a Master specification
·      Batch version is a child i.e business need based customization of the Master

JDE Interview Questions

  1. What is an Object in JDE? Define Some…
    Traditionally a OneWorld Object was defined as any object created in Object Librarian.
    Ex: Applications, Business Functions,Business Views, UBEs, Data Structures, Tables, Media Objects
  2. How do JDE Stores Objects?
    Central Objects
    Provides a central location for managing all OneWorld objects. Only used for Development &  Software deployment.
    Never used at runtime.
  3. What are Replicated Objects?
    Replicated Objects are stored in a directory on every workstation and logic server that will run OneWorld
    Built from Central Objects, Deployed via packages (‘point-in-time’ snapshot of selected objects)
    Stored in runtime (TAM vs. RDB) format
  4. What are Control Objects?
    Control objects are like buttons on the Form as Control obj. Fields on the Form are also control objects.
    We set control errors on the form design so that it stops the processing of error is set on the control.
  5. What are tokens?
    A Token has a One-to-One relationship with the following objects:
    Applications, Business Functions, Business Views, UBEs, Data Structures, Tables, Media Objects and Batch Versions
    The Token is used to minimize the possibility of one user overriding another user’s changes to an object.
    When an  object is checked out and is not already checked out by another user The project receives a Token.
    A Token can be released, switched or inherited.
    The Token is released by the project when the project reaches the status designated by the administrator for release.
    A Token is not released by the project when the object is checked back in.
  6. What is OMW?
    As a OneWorld developer I sometimes long for the simple days before XE.  I could check out objects from any environment and check them back into any environment. I could more easily view if an object was checked out and to who and which environment.  I could easily see what objects I personally still had checked out locally. I could also transfer objects from one environment to another with a few mouse clicks. 
    The OMW was designed to replace the old tools we were used to using such as the Object Librarian, Promotion Manager, and Object Transfer.  I believe that the OMW is a great tool when it comes to developing for new projects.  I like the fact that I can group up all of the objects I am working on into a project so I never forget the objects I created or modified for the new module I am creating.  In the old days you would have to keep track of objects in a separate file to give to the CNC guy once it was ready to deploy. Using the old method, how many times do you remember leaving off 1 or 2 objects because you forgot to write them down?
    • Promotion Manager
    • Object Transfer
    • Object Librarian
    • Object Librarian Check-in Log
    • To Hide Object Management Tasks
    • To Provide Better Control of OneWorld Objects
    • To Unify all Development into One Interface
    • To Automate Change Management Process
    • To Provide Detail Logging of Objects
  7. What is Check In & Check Out?
    Check In – We send the updated specs to the server. It will replace the specs on the server with the specs which we are doing check in. User will not lose the Token.
    Check Out – It will override the local specs of the object which we are trying to check out. We will get the latest specs from the server. User will get the token
  8. What is the difference between GET & Check Out?
    Checking out an object allows you to modify the object and check it back in to Central Objects.  Performing a Get copies the latest specifications to your workstation but does not allow you to check in.  This is similar to erasing a check out for those familiar with previous releases of OneWorld.
  9. What are the Object Librarian and Non-Object Librarian Objects?
    Only Object Librarian objects have tokens and Non Object Librarian Objects do not have token.
    non-Object Librarian objects  are based on data source rather than path code.
    One World objects include the following non-Object Librarian objects: 
    • Data dictionary items
    • User defined code items
    • Workflow items
    • Menus
  10. What are the required fields when adding an Object?
    Object Name, Description, Product Code, System Code, Object Use


Tuesday, March 31, 2015

Order Mangement Scheduling ATP


Actual Arrival Date - The date the order line arrives at the customer site.

Actual Ship Date - The date the order line is shipped. This date is recorded by the
ship confirm action.

Arrival Set - A set of order lines which arrive at the same time at the destination.

Available to Promise (ATP) - The quantity of current on-hand stock, outstanding
receipts and planned production not already committed to sales orders or other
sources of demand.

ATP Date - The date that a requested quantity will be available to promise.

Delivery Lead Time - Time (in days) for items to reach the customer once they are
shipped.

There are two ways to help system calculate this date.

1) Create a location for the Ship-to address and assign it as the internal location and then define inter-location transit time
2)Create a Zone/Region and then assign the inter-location transit time

Demand - Requests which consume inventory such as sales orders. Discrete
manufacturing work orders and flow manufacturing schedules place demand for
component items, and sales orders place demand for finished goods.

Promise Date - The date on which you agree you can ship the products to your
customer or that your customer will receive the products. This field is for tracking
purposes only. It may be defaulted from the schedule ship date or the schedule
arrival date.

Request Date - The date the customer requests that the products be either
shipped or received.

Reservation - A guaranteed allotment of product to a specific sales order. Once
reserved, the product cannot be allocated to any other source of demand. Also
known as a hard reservation.

Reservation Time Fence - Time (in days) before the schedule date, within which a
line should be automatically reserved.

This is Set by Profile option OM:Reservation time fence

Schedule Arrival Date - The date returned by the system on which your customer
can receive the products.

* Schedule Arrival Date = Schedule Ship Date + Delivery Lead Time

Schedule Ship Date - The date returned by the system on which you can ship the
products.

Ship Set - A set of lines which will be shipped together from the same warehouse
to the same location.

Sourcing - Selecting the warehouse for the order lines.

Supply - Incoming inventory. Some Oracle transactions that generate supply are
purchase orders, discrete manufacturing work orders and flow manufacturing
schedules.

Latest Acceptable date (LAD):
LAD is populated only when the Latest Schedule Limit (LSL) is provided at the time of order creation.

Latest Schedule Limit is defaulted from the site level or customer level based on defaulting rules.


* Latest Acceptable Date = Request date + Latest Schedule Limit

Request Date Type - Possible values are arrival and ship. If the value is arrival
then the request date and promise date will be considered arrival dates by the
system; if the value is ship then they will be considered ship dates. The request
date type can be defaulted from the customer information to the order, and
the user can change it on the order if required.
 Latest Schedule Limit - This field can contain any numeric positive integer
value. When you enter an order line, the latest acceptable date will be
calculated by adding the latest schedule limit to the request date. When the
scheduling action occurs, the schedule date will only be returned if it is
between the requested date and the latest acceptable date. If it is not within
this range, the scheduling action fails.




WHAT HAPPENS ON SCHEDULING:


Scheduling is an action performed on an order line or a group of lines. The action
does the following -



• Determines the source (warehouse) for the order line. If the warehouse is
entered on the line, either manually or using defaulting rules, the scheduling
action uses the requested warehouse and the other scheduling results are based
on it. If the warehouse is blank, the scheduling action determines the best
warehouse based on the sourcing rules.
• Determines the schedule ship date, the schedule arrival date, the delivery lead
time and the shipping method.
• Makes the line visible to the planning applications and consumes supply for
the item. When a line is successfully scheduled the
VISIBLE_DEMAND_FLAG is set to Yes.
• If the reservation time fence is set and the schedule ship date is within the
reservation time fence, automatically reserves the line.

The request date may be either the requested ship date or the requested arrival date
depending on the request date type of the customer. If the customer’s request
dates are requested arrival dates, the scheduling action calls MRP’s scheduling API
with the requested arrival date. The API returns the first date on or after the
requested arrival date that the items could arrive at the customer location, and
enters that date into the scheduled arrival date field for the line(s). The schedule
ship date is calculated by subtracting the delivery lead time (number of days for
items to reach the customer once they ship) from the schedule arrival date. If the
shipping network has not been defined for this combination of locations, the
delivery lead time will be considered 0 days and the schedule ship date and
schedule arrival date will be the same.
If a user enters a schedule ship date on the order line before performing the
schedule action, when the schedule action occurs the system tries to schedule on
that date. If it can’t, the schedule action fails.
You can define for each customer the delivery window in days that they will accept
by entering the latest schedule limit on the customer form. When you enter an
order line, the latest acceptable date is calculated by adding the latest schedule limit
to the request date. When the scheduling action occurs, the schedule date will only
be returned if it is between the requested date and the latest acceptable date. If it
is not within this range, the scheduling action fails. For example, suppose that you
have a customer who only accepts orders that ship within 5 days of the request
date. You would enter 5 in the latest schedule limit fields on the Order
Management tab of the customer form. When you enter an order line, if the
request date is September 10, the latest acceptable date would be September 15.
When the scheduling action occurs, if the schedule date returned is not in the date
range of September 10 through September 15, the schedule request fails.


NUMBER OF WAYS TO SCHEDULE:


• Autoschedule - The line is scheduled when it is saved. A line can be saved
manually by the user or will automatically be saved when the user leaves the
line. If either the Autoschedule check box on the order transaction type is
checked or the OM: Autoschedule profile option is Yes, the sales order will be
opened in Autoschedule mode. You can turn Autoschedule on or off from
the sales order form by going to the Tools menu. Note that if autoschedule is
turned on the availability window is automatically displayed when the sales
order form is opened. The user can close the availability window, but the lines
will still be autoscheduled unless the autoschedule check box on the tools
menu is unchecked.

• Manual - You can access the scheduling sub menu either by selecting schedule
from the list of activities on the tools menu or by placing your cursor on a line
and pressing the right mouse button. Selecting schedule from these menus
will trigger the scheduling action. If the action is selected from the order
header tab, all the lines on the order will be scheduled. If the action is selected
from the lines tab, it applies only to the line or group of lines selected.

• Scheduling Concurrent Program - This program selects all lines which are
eligible for scheduling and attempts to schedule them. The user can select
orders based on the order number







CALCULATING THE ATP:




ATP will be automatically calculated during scheduling, and may be calculated
manually by pressing the Availability button on the line items tab of the sales order
form.

There are several setup steps required for ATP calculations to work. 

1)ATP rules must be defined to determine the sources of supply and demand which are
included in the calculation. 

2)The ATP rules must be associated with items and/or Inventory organizations.

3)The data collection program must be run. A concurrent process known as data
collection must be run to summarize the supply and demand picture. This
program is part of the Oracle Advanced Planning and Scheduling application.

The ATP calculation is then performed on the summary tables.


ATP Rules are created in the Inventory module. They indicate which sources of
supply and demand to consider when calculating ATP. They can be assigned to
inventory organizations and items. If an ATP rule is assigned to an item that is
used. If the ATP rule for the item is blank, then the ATP rule for the inventory
organization is used. 

You must define sourcing rules if you want ATP to determine the warehouse for
your order lines. Once sourcing rules are defined, they must be assigned to
particular items, categories and/or inventory organizations. You do this using
assignment sets. 

For scheduling to work in OM you must successfully run the data collection
concurrent request set. As previously stated, calculating ATP must happen almost
instantaneously, but searching through all the possible sources of supply and
demand to calculate ATP is very complex. Therefore, a concurrent process known
as data collection must be run to summarize the supply and demand picture. The
ATP calculation is then performed on the summary tables. To run the data
collection request set, choose Scheduling -> Collect Data from the OM navigation
menu. There are two programs in the request set. Enter parameters for both and
submit the set. The Planning Data Pull program has a parameter named Complete
Refresh. If this is yes, then the collection will select all scheduling related
information from the relevant tables. If it’s no, then only the updated information
will be selected. For details on running the data collection programs see the Oracle
Advanced Supply Chain Planning and Oracle Global ATP Server User’s Guide.
The scheduling level on the order transaction type determines what type of
scheduling is allowed. The possible values for this setting are ATP Only, No
Reservations and Allow All Scheduling Actions. If the value is ATP Only then you
will not be able to schedule or reserve lines on the order. If the value is No
Reservations then you can perform all scheduling functions except for reserving
inventory. If the value is Allow All Scheduling Actions or NULL then all
scheduling functions can be performed.





EXAMPLES OF SCHEDULING


Example 1:
The warehouse for the order is defaulted from the ship to site. A shipping
network is defined for this warehouse/ship to combination with the shipping
method of UPS ground, and the transportation lead time is 5 days. The customer
requests the shipment as soon as possible, so the request date is entered as today’s
Scheduling in Oracle Order Management Page 15
date. On-hand inventory is available to fulfill the order. Autoschedule is on, and
the reservation time fence is 5 days.
The user enters an order line with the item, quantity and request date. When the
line is saved, because autoschedule is on, it is automatically scheduled for the
requested warehouse with a schedule ship date of today and a schedule arrival date
of today plus 5 days. Because the schedule ship date is within the reservation time
fence the line is also automatically reserved.
Example 2:
No warehouse is defaulted or entered for the order. No shipping network is
defined for the customer. The customer requests the shipment as soon as
possible, so the request date is entered as today’s date. There is no inventory
available to fulfill the order, but there is a work order scheduled for completion in
10 days, and your ATP rule includes work orders as a source of supply.
Autoschedule is off, but the line level workflow process has the scheduling activity
immediately after booking as a synchronous activity.
The user enters an order line with the item, quantity and request date and saves the
line. Because autoschedule is off, no scheduling action occurs at this time. The
user enters additional lines and then books the order. As soon as the order is
booked, the scheduling activity from the workflow executes. The warehouse is
determined by the sourcing rules. The schedule ship date is today + 10 days (the
day that the work order is scheduled to complete.) The schedule arrival date is the
same as the schedule ship date, because the shipping network is not defined for
this combination of customer, warehouse and ship method.

Example 3:

The warehouse is defaulted from the customer ship to site. No shipping network
is defined for the customer. The customer requests the shipment as soon as
possible, so the request date is entered as today’s date. There is no inventory
available to fulfill the order, and there are no work orders or purchase orders for
the items. Your ATP rule specifies an infinite supply time frame of 30 days. The
customer has a Latest Schedule Limit of 10 days. Autoschedule is off, but the line
level workflow process has the scheduling activity immediately after booking as a
synchronous activity.
The user enters an order line with the item, quantity and request date and saves the
line. Because autoschedule is off, no scheduling action occurs at this time. The
user enters additional lines and then books the order. As soon as the order is
booked, the scheduling activity from the workflow executes. The ATP date is
calculated to be today + 30 days because of the infinite supply days of the ATP
rule. However, the Earliest Acceptable Date is today + 10 days because of the
customer setup. So the scheduling activity fails, the user sees an error message,
and the line remains at the workflow activity of Schedule - Eligible until a source
of supply can be created or until the Latest Acceptable Date is changed. Then the

line can be scheduled by either manually progressing the line or running the
scheduling concurrent program.

PROFILE OPTIONS THAT PLAY CRUCIAL ROLE


• OM: Schedule Lines on Hold - Possible values are yes and no. If this field is
yes, the scheduling action processes order lines even if the order or line is on
hold. If no the scheduling action will fail.

• OM: Autoschedule - Possible values are yes and no. If this field is yes the
availability window is displayed when the sales order form is opened and
scheduling occurs automatically as each order line is saved.

• OM: Reservation Time Fence - This may be any positive integer numeric
value. When a line is scheduled it is also automatically reserved whenever the
schedule date is within the reservation time fence.

• OM: Auto Push Group Date - Possible values are yes and no. If the value is
yes and a line is added to a scheduled configuration, and the new line cannot
be scheduled on the date that the rest of the configuration is scheduled, then
the system will try to reschedule the complete configuration at a different time.
If the value is no and the new line cannot be scheduled, then scheduling for
the new line will fail and the rest of the configuration will not be affected.

• MRP:ATP Assignment Set - This can be any valid assignment set which is
defined in the MRP application. It specifies the assignment set that will be
used for calculating ATP. Assignment sets are mentioned later in this section.

• INV: Capable to Promise - Possible values are Enable Product Family ATP
and CTP; Enable Product Family ATP; Enable ATP; Enable PL/SQL based
ATP with Planning Output; and Enable PL/SQL based ATP without
Planning Output. This profile option indicates whether and how to enable the
CTP calculation. For ATP to work in OM, the value must be Enable
PL/SQL based ATP without Planning Output.

RESERVATIONS

In OM, you can reserve on-hand inventory to a sales order. Reserved inventory
cannot be used for any other purpose. The reserved quantity for a sales order line
is displayed on the shipping tab. You may reserve part or all of the ordered
quantity.

A line must be scheduled before it can be reserved. If you try to reserve an
unscheduled line, the system will first try to schedule the line. If the line is
successfully scheduled then the system will try to reserve it.

There are two ways to reserve from the sales order form. 
1)You can select reserve from the scheduling option under the tools menu 
2) select reserve from thescheduling sub menu which is displayed when you press the right mouse button.
If you are on an order line the line will be reserved. If you are on the header, all
the lines will be reserved.

Reservations are performed automatically whenever a line is scheduled and the
schedule date is within the reservation time fence.
 For example, suppose the today’s date is November 25th. An order line is scheduled for December 1st, whichis 6 days away. If the reservation time fence is 10, the line will be reserved because
6 < 10. If the reservation time fence is 2, the line will not be reserved because 6 >
2. If the reservation time fence is NULL, then lines will not be automatically
reserved. The reservation time fence is set using the profile option OM:
Reservation Time Fence.

When you create reservations manually on the sales order form or automatically
using the reservation time fence, the items are reserved at the warehouse level with
no inventory details specified. You can specify inventory details for a reservation
by using inventory’s reservation details form. To access the form from the sales
order form, go to the tools menu and select scheduling. From the list of options
select Reservation Details. A form will appear which allows you to reserve by lot,
revision, subinventory and/or locator. You can only access the reservation details
form for lines that are scheduled.