Adam M. Erickson » Tag » Programming

Tag Archives: Programming

SAP-B1 | Pack List for Sales Orders | SQL | Crystal Report

  By | , , , , ,
Leave a comment

Looking for a better packing list for your shippers to view?

This one will add descriptions and notes from the sales order text lines (unless the word “Freight Charge” is in the text line). Lines will be  added them in the same ‘visual order’ as the shipping order.
It will also add the Shipping Type from OSHP so the you know how to pack the material for certain shipping companies.

SQL Used as a command in Crystal Report:

The SQL and DocKey@ are the tough part of the report. Go ahead and design a report to look the way you want. I’m just helping you join all the information together with a couple inner joins and an union so you don’t have to figure it out on your own. If you would like to add additional data to this SQL. Remember a Union had to have the same amount of columns on both of the Union selected.
SELECT *
FROM
(
SELECT
docnum, linenum, visorder, itemcode, dscription, 0 as ordernum, OpenInvQty, U_SSI_ModPart, cardcode, cardname, docduedate, taxdate, doctime, StDlvTime, docstatus, TrnsCode, trnspname
FROM
rdr1
INNER JOIN ordr ON rdr1.docentry=ordr.docentry
INNER JOIN OSHP ON rdr1.TrnsCode=oshp.TrnspCode
WHERE docstatus != 'C' AND dscription!='Freight Charge'
UNION
SELECT
docnum, aftlinenum, visorder, '' , cast(linetext as nvarchar(500)), rdr10.ordernum, OpenInvQty, U_SSI_ModPart, cardcode, cardname , docduedate, taxdate, doctime, StDlvTime, docstatus, TrnsCode, trnspname
FROM
rdr10
INNER JOIN ordr ON ordr.docentry=rdr10.docentry
INNER JOIN rdr1 ON rdr10.docentry=rdr1.docentry AND rdr10.aftlinenum=rdr1.visorder
INNER JOIN OSHP ON rdr1.TrnsCode=oshp.TrnspCode
WHERE docstatus != 'C' AND dscription!='Freight Charge'
)
PICKLIST
ORDER BY
docnum
, visorder
, ordernum

If you have an issue where the report looks good but when imported into SAP it has the incorrect Sales Order Number. Add a Formula that changes the DocKey@ to increment by the difference.

number is off

{?DocKey@}={Command.docnum}-n

In the below image is to remind you to add a parameter for DocKey@ here in the parameter list. You will need to add one to the report also. Make sure it is a number. It will default to text if you are not careful.CR-Command

 

Once you have your report built, don’t forget to add a DocKey@ to the report also. I change the text of mine to white so it would not be seen.

Java | Constructor vs. Method

  By |
3 Comments

If you are within your first year of application development in Java you may have asked yourself this question. I know I did.

What is the difference?

Java

Here is a reference list that I have compiled for your convenience.

Download the excel file and build upon other comparisons you need to keep track of –>constructor-vsmethods.xlsx

Topic

Constructors

Methods

Purpose

 Create an instance of a class – Object Initialization Grouped Java statements – Each performs a small unit or task

Modifiers

 No – Cannot be abstract, final, native, static, or synchronized, already marked as final & static. Yes – Can be abstract, final, native, static, or synchronized

Has a Return type

 No – not even void Yes – void or a valid return type

Naming Convention

 Same name as the class, first letter is capitalized by convention) — usually a noun Any name except the class. Method names begin with a lowercase letter by convention — usually the name of an action

Inheritance

 No – Constructors are not inherited Yes – Methods are inherited

Compiler automatically supplies a default constructor

 If the class has no constructor, a no-argument constructor is automatically supplied Does not apply

Compiler automatically supplies a default call to the super-class constructor

 If the constructor makes no zero-or-more argument calls to super, a no-argument call to super is made Does not apply

Can be Overloaded/Overwritten?

 Yes Yes

Can be public, protected, private?

 Yes Yes

Must be same name as Class?

 Yes No, arbitrary

chained and they are called in a particular order

 Yes No

Model View Control

  By | ,
Leave a comment

Introduction

MVC

MVC

Model View Control (MVC)  is a 3 level architecture that decouples the interface from navigation and application behavior, mostly because keeping the applications together creates a huge mess when it is time to redesign you program. MVC patterns will simplify implementation and greatly enhance re-usability. It should always be used in O.O.P. (object oriented programming)

Model

The term Model stands for Data Module Objects, it holds all the application state information (ie data) and all operations that can modify the data.

A model is a computational approximation or abstraction of real world process, entity, or system. An example is the shopping cart when you order an item on-line using e-commerce. It would hold the information of the order number, what is being ordered, the quantity being ordered, and all the code that could interact with this data usually in SQL code. It is also called business logic and provides the connections to the data source as well as to the controller.

View

The view contains the interface functions, it is the GUI code. It will produce all the visual components of your program. It provides the access to the data and processing logic to the user.

It needs to allow the user enough functionality to provide the user with the tools the program is being developed for.

The view is tied into the Data model, if you delete an item from a shopping cart it will be removed immediate or upon a page refresh usually from an Event Object handler that contains the change and then updates the cart to show a page in HTML with the previously deleted item gone.

For an inexpensive home server try a Linux server with Apache Web-server, a MySQL database and PHP coding. All the software can be installed for free.

Controller

As its name implies, the controller component controls the overall flow. The controller code interacts with the view and model components to deliver a modular yet integrated solution.

It is the Controller that accepts input from the user in a particular modality, interprets that input (the interpretation may depend on the View), and invokes the appropriate operation on the Model.

For example, when the Controller detects a mouse click event on the “remove” button of an item it invokes the remove operation on that item. Any state changes that this operation causes on the

Model are sent by the Model to the registered Views via events. The controller component is normally written in Java and implemented as a Servlet.

 MVC usage rules

In order to support reusability, the interactions which do occur should be well defined and the dependencies between the elements (M-V-C) should be minimized. One of the goals of the MVC pattern is to enable the combination of a single Model with multiple Views and Controllers. The MVC pattern ensures that the Views are kept synchronized. When the Controller recognizes a valid command from the user’s input, it invokes the corresponding method on the Model. The

Model verifies that the operation is compatible with its current state, executes it and changes the state of the Views correspondingly. The views, as they have registered themselves as observers, get now informed about the Model’s state change and update their rendering correspondingly.

 The dependencies must be kept minimal

To support multiple views and controllers the dependencies must be kept minimal.

 Note: A is said to be dependent on B when the code of A embeds knowledge about B.

This leads to the following rules:

  1.  The Model does not have any dependency on Views or Controllers.
  2.   A View depends on its associated Model. It has to know the structure of the Model’s state to be able to render it.
  3.   A View does not have a dependency on Controllers. Therefore several different Controllers can be associated with the same View.
  4.  A Controller depends on its associated Model and View. The Model defines the operations the Controller can invoke and the View defines the context in which the Controller interprets the user input. This makes the Controller tightly coupled to the View.

 The interactions must be kept minimal

Another precondition to support multiple Views and Controllers is to keep interactions minimal.

In particular a Controller must never directly affect the rendering of its associated View. Instead user input must make a complete round trip through the Model before its effects become visible in the View. This rule guarantees that a state change updates all Views and that the Views remain synchronized. Often implementations with a single Controller violate this rule because of sloppy

thinking: “I already know that this state change will occur, and therefore do not need wait for the Model to tell me about it”. This is wrong for two reasons:

1. The Model can veto the operation for some reason. The operation will not occur.

2. Other Controllers may concurrently invoke operations on the Model. Some other operation can slip in between, which fundamentally changes the rendering and makes any assumptions about it invalid.

In addition it is impossible to extend such shortcut implementations later with additional Controllers.

 The MVC pattern in Web applications

Although the MVC pattern was originally devised for the organization of fat client GUI libraries, it has in the past several years received widespread acceptance as a suitable architectural pattern for implementing Web based solutions, too. Its structure has been applied, (with limitations), in recent Web applications. This is not surprising, since in both cases the separation of concerns is the driving force behind architectural choices.

 Extending the MVC pattern to distributed applications

Although the MVC pattern was originally devised for GUIs running on a single machine, it can be extended relatively straightforward to distributed systems, where some interfaces between Model, View and Controller may cross the network. The placement of the Model, the View and the Controller then becomes a crucial issue.

The client-centric approach puts all three functions: Model, View and Controller on each client device. The Model, which exists conceptually only in one instance, is “replicated” among the devices. A replication protocol keeps the copies of the Model synchronized.

The server-centric approach puts both Controller and Model on a server. The client devices contain only the Views.

 Why you should MVC

  • Separation of data from presentation

Drawbacks on MVC

  • Is not easy and requires planning
  • Thorough testing and more files needed
  • May overkill small applications

Develope a Web Based CMS Using PHP

  By | , , , , , , , ,
2 Comments

Download this File Here

Abstract
The Content Management System (CMS) is a web based application using a Linux Server,
Apache Web-server, MySQL Database, and PHP Programming Language (LAMP). The
objective of managing users, and information in any given network environment can only be
hindered by the creativity of an information technology professional and not by technology. The
main objective of this thesis is to develop the early development steps of a LAMP software bundleCMS. By creating the
building blocks for developing, and taking into consideration basic methods for creating the core
platform of a CMS for further development. All information gathered, and experience gained will
assist with developing and offering my own personal e-commerce business solutions in the future
and to obtain additional business and practical knowledge in an open source software and ecommerce.
Continue reading →