Welcome Guest Login SignUp

Home

Technical

Functional

CNC

AS400

DB2

    Citrix

JDE News

Live Radio

Feedback

Latest Updated Posts
JDE TECHNICAL 2020-01-27 21:52:46

FAQ - Frequently Asked Questions on Table Conversion (TC) in JDE E1 2020-01-10 09:50:09

What is MVC Architecture? 2020-01-08 03:26:12

Power Forms in JDE E1 2019-12-29 12:59:17

Difference Between EDI Process and Z files 2019-12-10 11:32:31

test 2019-07-06 14:18:19


Page Visits:-434977 (Since:-January-2014)
Loading

Oracle JD Edwards EnterpriseOne Main Topic Category

JDE Forum Comments/Reviews/Query
194 day(s) ago   #356
Name: Admin1
Category: Technical
Location: Singapore
Date: 2020-01-27 21:52:46
Replies(4)

Status: 

JDE TECHNICAL

Hi Asad,

I need to know few things before I can suggest anything.

1. Is your sales order process followed is as per JDE standard?
2. Currently Sales order is at what status, as system allows sales order to be cancelled at certain status only?
211 day(s) ago   #354
Name: Admin1
Category: Technical
Location: Singapore
Date: 2020-01-10 09:50:09
Replies(0)

Status: 

FAQ - Frequently Asked Questions on Table Conversion (TC) in JDE E1

Q1. What is Table Conversion (TC)?
TC is a type of batch process that enables you to rapidly manipulate the data in tables

Q2. What type of conversions can be done in TC?
- Data Conversion
- Data Copy
- Data Copy with Table Input
- Batch Delete

Data Conversion: enables you to transfer or copy data from an input table or business view into output tables using the logic that is necessary to perform the transfer. You can also use Data Conversion to update records in a table or business view.

Data Copy : enables you to copy tables from one data source or environment to another source or environment when the tables are identical.

Data Copy with Table Input: enables you to copy tables based on information from an input table. For example, the input table provide information about which tables are copied, where they are copied and so on.

Batch Delete: enables you to delete records from a table or business view.

Q3. What is table conversion process flow?
When you process a table conversion, the system triggers events that are similar to the events that are triggered when a report or application is run. These events are specific to the table conversion that you defined. Events provide pauses in the processing of the table conversion where you can attach logic.
In general, the event flow is the same for all table conversion types because these conversion types are all subsets of a data conversion:
Data Copy : This conversion type does not include input and output tables. All actions are accomplished through the Process Begin event.

Data Copy with Table Input: this conversion type does not include output table, all actions are accomplished through the Process Begin, Process End and Row Fetched event.

Batch Delete: As with the data copy with table input type, this conversion type does not include output table, all actions are accomplished through the Process Begin, Process End and Row Fetched event.

Q4. How many inputs a TC can have?
One

Q5. What is foreign table?
Tables that do not have a JD Edwards EnterpriseOne definition but reside in a database that is supported by JD Edwards EnterpriseOne. Basically Non - JDE tabless are called foreign table not defined by JDE E1.

Q6. How many outputs can be attached in a Batch Delete?
None

Q7. What is flow of events in TC?
Process Begin, Data Changed, Row Fetched, Format Fetched and Process End

Q8. What is difference between User Insert Row and TC Insert Row?
A User Insert Row can defined anywhere but TC Insert has to be defined at the end of the event

Q9. What is a processing option and where do you attach it in a TC?
It is a run time user input and you attach po in the external data of the navigation window

Q10. List few table conversion system functions.

TCInsertRow
UserInsertRow
Set Selection Append flag
Set User Selection
Stop Conversion Processing
Stop Event Processing
CopyTableDataSource
CopyTableEnvironment

213 day(s) ago   #353
Name: Admin
Category: Technical
Location: Singapore
Date: 2020-01-08 03:26:12
Replies(0)

Status: 

What is MVC Architecture?

There is a lot of software design pattern used for developing any application. During early days of application development, the approach of designing the User Interface, building the business logic as well as coding the logic part for the application was programmed and prepared in a single file which usually created lack of maintenance, make testing of application uneasy as well as reduce the scalability of any application. To overcome this, a model came into existence and gradually became popular. known as the MVC architecture.

MVC is abbreviated as Model View Controller is a design pattern created for developing applications specifically web applications. As the name suggests, it has three major parts. The traditional software design pattern works in an "Input - Process - Output" pattern whereas MVC works as "Controller -Model - View" approach. With the emergence of the MVC model, creation of application takes different aspects individually into consideration. These aspects of the application are:

- UI Logic
- Input logic
- Business Logic



But there is a loose coupling between these aspects or elements. According to this model, each element needs to exist in an application but not tightly connected or interlinked. The UI logic deals with the view or front end of the application. The Input logic deals with the controller. Lastly, business logic deals with the model of an application. This loosely coupled element helps developers handle development complication when building any application. It helps users` enables in focus on one specific element of the implementation at a time. Take a scenario where you are working with business; you can specifically deal with that and focus on the business logic building without depending on the view logic.
223 day(s) ago   #352
Name: Admin1
Category: Technical
Location: Singapore
Date: 2019-12-29 12:59:17
Replies(0)

Status: 

Power Forms in JDE E1

A power form is a web application form that enables users to view multiple, interrelated views of data, grids, and tab pages on one form and to pass logic among them. The tab pages can have their own business views, and these business views can communicate with each other and can update data based on selection and changes that occur in other business views on the form. Power forms are designed for advanced end users.

Advantages:-
Multiple views on a form.
Multiple grids on a form.
Multiple tab controls on a form.
Tab pages with their own business views.
Business views that communicate with each other and are updated based on selection and data changes that occur in other views on the same form.


The types of power forms are:
• Power Browse.
• Power Edit.
• Reusable Browse subform.
• Reusable Edit subform.


Power Browse Form


Similar to a Find/Browse form, a Power Browse form is designed only for browsing data. Editing capabilities are not available on this form.

Power Edit Form


Similar to a Headerless Detail form, a Power Edit form is designed for browsing and manipulating data.

Reusable Browse and Edit Subforms


Reusable subforms are discrete objects in the system that represent one data view. Reusable subforms are referenced through other applications with aliases. Subforms own the data flows between the interface and the database.

Power Form Performance


Power forms work best when you use an object-oriented design to create them. When you design modifications or applications, you need to identify objects (subforms), how the objects interact with each other (business logic or actions), and when their attributes (variables or fields) interact or change (states). This design is necessary to minimize the data passed between parent and child forms.

Power Form Key Standards


When using Power forms and subforms to create an interactive application, follow these key standards:
• Do not implement search and edit use cases on the same form.
• Avoid toolbars on Power forms.
If your application includes a hierarchical layout of subforms and these subforms include push buttons, do not use the toolbar. Hide the toolbar and provide form and subform level push buttons instead. Toolbars should be avoided as much as possible in 8.12 applications
• Follow a standard naming convention.
For example: - for Requisition Inquiry - Search for Requisitions.
• Title all subforms, unless they contain tabs.
• Name grids so that the displayed information is clearly identified, unless the grid appears alone on the form.

Power Browse Form


The Power Browse form enables:
• View-only.
• Subforms.
Power Browse forms with a business view should always have a grid with at least one column.

Power Edit Form


The Power Edit form enables:
• Data modification.
• Data browsing.
• Subforms.

Power Edit forms without a business view have the characteristics of a Headerless Detail form. Power Edit forms with a grid enable users to update and enter multiple records simultaneously.

The Power Edit form enables:
• Data modification.
• Data browsing.
• Subforms.
Power Edit forms without a business view have the characteristics of a Headerless Detail form. Power Edit forms with a grid enable users to update and enter multiple records simultaneously.

The Power Edit form enables:
• Data modification.
• Data browsing.
• Subforms.
Power Edit forms without a business view have the characteristics of a Headerless Detail form. Power Edit forms with a grid enable users to update and enter multiple records simultaneously.

Subform Types


The two subform types are:
• Standard subforms.
• Reusable subforms
Subforms can exist as discrete objects in the system. You can place the subform itself on a power form; this action is referred to as embedding. You can also reference an existing subform on a power form with an alias; this action is referred to as reusing. Typically, you reuse subforms that are designed to appear on numerous forms, such as the display of address book information. In this way, you can more easily standardize the interface.

Reusable Subforms


A reused subform is actually just a pointer; therefore, it is unaware of its parent and children in any given context. If you want a reused subform to communicate with its parent or children, you must do so through ER. While you cannot embed a subform within another subform, you can reuse a subform within another subform. In other words, you can embed or reuse a subform within a reusable subform, but you cannot embed or reuse a subform within an embedded subform. Inserting reusable subforms in a form is different from inserting an embedded subform. They exist as two different control types in the user interface. Therefore, the FDA Menu/Toolbars contain two different insert actions. If you insert an alias, you are prompted for the application. If you insert a reusable subform, you are prompted for the subform. You cannot insert a subform onto a form until the application the subform has been defined in has been saved. Reusable subforms can be written once and then reused in any other power form. They are created as their own entity within an application. The different types of reusable subforms are Browse and Edit.

A subform is a control designed for use on a power form or another subform. Although technically a control, subforms have some form characteristics as well. Each subform represents one data view. That is, each subform control can have a single business view (BSVW) attached to it. Power forms can contain several subforms, so a single power form with multiple subforms enables users to see multiple data views. For example, a user selecting a purchase order in a grid could see related shipping information in one subform and fulfillment information in another subform on the same power form. When the user selects a row in the grid, all of the data is updated. Most importantly, the user does not have to open a new form to see the updated data.

Together, power forms and subforms provides you with the ability to code:
• Multiple views on a form.
• Multiple grids on a form.
• Multiple tab controls on a form.
• Tab pages with their own business view.
• BSVWs that can communicate with each other and even react to selection and data changes that occur in other views on the form.

Processing Of power forms:-


Power Browse:-


When a Power Browse form is called, runtime initializes these items in this order:
1. Thread handling.
2. Error handling process.
3. Business view columns.
4. Form controls (FC).
5. Grid fields.
6. Static text.
7. Help.
8. Event rule structures.

Events


The Power Browse form supports these events:
• Dialog is Initialized.
• Post Dialog is Initialized.
• End Dialog.
• Grid Record is Fetched.
• Write Grid Line-Before.
• Last Grid Record Has Been Read.
• Write Grid Line-After.
• Row is Selected.
• Notified By Child.

Power Edit Form


When a Power Edit form is called, runtime initializes these items in this order:
1. Thread handling.
2. Error handling process.
3. Business view columns (BC).
4. Form controls (FC).
5. Grid fields.
6. Static text.
7. Helps.
8. Event rule (ER) structures

Events for a Form with Grid Control


These events can occur on the Power Edit form during runtime if the form contains a grid control:
• Dialog is Initialized.
• Post Dialog is Initialized.
• Grid Record is Fetched.
• Last Grid Record Has Been Read.
• Clear Screen Before Add.
• Clear Screen After Add.
• Write Grid Line-Before.
• Write Grid Line-After.
• Post Commit.
• Notified by Child and End Dialog

Events for a Form without a Grid Control


These events can occur on the Power Edit form during runtime if the form does not contain a grid control:
• Dialog is Initialized.
• Post Dialog is Initialized.
• Clear Screen Before Add.
• Clear Screen After Add.
• Add Record to DB - Before.
• Add Record to DB - After.
• Update Record to DB - Before.
• Update Record to DB - After.
• Post Commit.
• Notified by Child.
• End Dialog.

When you place subforms on a power form or another subform, the system treats the interactions among them as parent-child relationships. The power form or subform acts as the parent, and the subforms act as the children of the power form and as siblings to each other. This hierarchical relationship governs logical relationships. It is also represented visually in the Form Design Aid (FDA) application tree view as a hierarchy to help you understand the relationships.

Similar to a form, a subform owns the data flows between the interface view and the database, including browse, insert, update, or delete. In fact, you create a subform as if it is a form, and then you place it as a control. Do not let its appearance fool you: a subform is really a control, and the FDA interface treats it accordingly. For example, if subform B is contained in power form A, then when you select B the FDA control bar still displays the title of A. Additionally, if you view the data structure, you will see the data structure for A and not for B. Hierarchical Structure

The two hierarchies in FDA are:
• Control hierarchy.
• Business view hierarchy.

Control Hierarchy


In this hierarchy, controls are contained within other controls.

Business View Hierarchy


The business view hierarchy enables you to connect business view containers (subforms) to each other. Subforms can only interact with their parent and their children. This hierarchy should be created based on relationships between business views. Data flows between parent and child in the business view hierarchy. There is no direct data flow among siblings or from the power form to the grandchild subform

Transaction Boundaries


Power forms include the transaction property, which functions in the same way with other form types. By default, the transaction property is scoped to OK button processing; however, the scope can be extended to business functions, table input/output (I/O), and form interconnects.Subforms are scoped to Save button processing; however, the scope can be extended to business functions, table I/O, and form interconnects. When you include all forms in the transaction boundary and the roll back data on any one form, the system rolls back the changes on all of the forms.

242 day(s) ago   #351
Name: Admin1
Category: Technical
Location: Singapore
Date: 2019-12-10 11:32:31
Replies(0)

Status: 

Difference Between EDI Process and Z files

Many times it came to my mind "why does JDE have 2 differently referenced systems that bring in outside data?" Why is AP and AR typically brought in via Z-file processes, but sales orders, invoicing, ASN`s and others have something called a system 47?

I don`t think there`s a good answer as to why JDE decided "this one is 47, but this one is Z-files". If I had to guess, I`d say that they tried to marry the typical ANSI-X12 standard EDI docs that manufacturers typically exchange (850, 810, 856) to something with an overarching name called system 47. I think system 47 processes are a bit more robust/complicated. More screens and logic dedicated to them. Whereas the Z-files, though effective, are a little more "thrifty", if you would. The initial interfaces are maybe a bit more basic, the UBE`s that process them aren`t really more than shells which call the same business functions that are used in the interactive screens to process data. System 47 re-uses some BF`s too, but again in my experience they`re a bit more robust.

The bottom line answer is they both serve to process in outside data (or prep internal data for transfer), but just have different system codes.

Ref. from jdelist.
399 day(s) ago   #350
Name: abbakunutt
Category: Technical
Location:
Date: 2019-07-06 14:18:19
Replies(1)

Status: 

test

test
488 day(s) ago   #346
Name: Admin1
Category: Technical
Location: Singapore
Date: 2019-04-08 11:23:34
Replies(2)

Status: 

JD Edwards EnterpriseOne Reporting-Suppress Section Write

Hi WY24,

Wonder if you already found the solution.
You could try the "Suppress Section Write" system function.

Did you try the show section/Hide section functions?.
If you use them you have a custom section for the number of records which you can accumulate in your "show section" loop.

Hope this helps!

Thanks!

Page: 1 2 3 4 5 ...[>>]
Post Comments/Queries
Role:*
Subject:*
Email:*
Name:*
Details:*
 
   
* Please keep the forum clean.  * Your comments may subject to varification.  * Your email ID will not appear in the forum.
Related
JDE List JDE Source    JDE Upgrade JDE Fusion     The CNC Guy     Itz about ERP JDE Dev JDE Tech
E1 Tips & Tricks JDE CNC JDE Tips IT Toolbox JDE Tech Tips JDE ERP JDE Advisor JDE Wikipedia
 
Disclaimer: Most of the posts in this blog cater solutions/suggestions/workaround to issues for specific tools release or JDE E1 version and are just information only. Please be carefule while applying it in your environment. JDEthread will not be responsible for any data loss or spec corruption (if any).
Copyright © 2010 - 2020 JDEthread.in