Total Pageviews

Thursday, October 18, 2012

How to Cancel Sales/ Purchase order


I would like to share about how to cancel Sales or Purchase order. If a Sales order or Purchase order status needs to update as “Cancelled” status then follow the below steps.
Sales/ Purchase order cancellation process
Select a Sales/Purchase order and have one sales/Purchase line(s).
image
Go to Sales/Purchase order à select Sales/Purchase lines àclick Update line as shown in the below screenshot à select Deliver remainder
image
It opens-up “Update remaining quantity” window àClick on Cancel quantity button as shown in below screenshot.
image
Once you perform this for a single line where no items are not delivered then automatically Sales/Purchase line status will be updated to “Cancelled” as shown in below screenshot.
image
Once you perform this for all lines which are not processed (means no items were delivered from all the lines) then automatically Sales/Purchase order header status will be changed to Cancelled as shown in below screenshot.








Monday, January 2, 2012

Microsoft Dynamics AX 2012 Architecture

Understanding the internal architecture of Microsoft Dynamics AX 2012 can help you make decision when planning and developing a Microsoft Dynamics AX 2012 system. Here are some pointers on DAX 2012 architecture primarily for DAX 2012 architects & solution developers.
System architecture
This diagram provides a high-level over of a Microsoft Dynamics AX 2012 system with all components installed, and describes how communications flow between the components.


Model store architecture
The model store is the part of the Microsoft Dynamics AX database where all application elements for Microsoft Dynamics AX are stored. Customizations are also stored in the model store. The model store replaces the Application Object Data (AOD) files that were used in earlier versions of Microsoft Dynamics AX.
Layer information and model information are integral parts of the model store. The Application Object Server (AOS) has access to the model store. The AOS manages layer flattening or overshadowing at runtime. That is, when you make an object modification in one layer, the modification overshadows the object on a lower layer at runtime. You could, for example, decide to change a caption on a standard form. The change is saved on your layer only, and the revised—or flattened—form replaces the standard form at runtime. The AOS also provides all the Microsoft Dynamics AX subsystems with model data, such as form rendering, report rendering, and X++ code.
Microsoft Dynamics AX contains sixteen layers. Each layer consists of one or more logical parts called models. A model is generated for each layer. For example, VAR Model is the model that the system generates for the VAR layer. The system-generated models let you install and work with the base Microsoft Dynamics AX system. When you customize the Microsoft Dynamics AX program, you can take advantage of the capabilities of models.
   
The following table describes the application object layers in Microsoft Dynamics AX 2012:
Layer
Patch Layer
USR
USP
CUS
CUP
VAR
VAP
ISV
ISP
SLN
SLP
FPK
FPP
GLS
GLP
SYS
SYP
Application Object Server (AOS) architecture
This diagram describes the functionality with the AOS windows service, and describes how communications flow within it.


Note: Clients communicate with an AOS by using remote procedure calls (RPCs), Windows Communication Foundation (WCF), or AOS services. In previous releases, other components and third-party programs could communicate with an AOS by using either .NET Business Connector or Application Integration Framework (AIF). For this release, we recommend that third-party programs use AOS services to communicate with AOS.

Client architecture
This diagram describes the functionality within the client, and describes how communications flow within it.


Client/server communication

The client communicates with various Microsoft Dynamics AX components in the following ways:
·         The client uses the remote procedure call (RPC) protocol to communicate with Application Object Server (AOS). The client never accesses the database or metadata directly. AOS sends the application objects and data to the client.

·         The data layer that the client uses is based on data sources that are specified in metadata for forms and queries. In addition, any X++ code that is required to retrieve data can use the built-in language support to query and adjust data.

·         The client uses a report Web Part to interact with the report server. By calling the web services that are exposed by the report server, the report control in the Web Part displays information that is contained in Reporting Services reports. These reports can include either transactional data from the Microsoft Dynamics AX application or OLAP cubes from Microsoft SQL Server Analysis Services. Cubes provide business analytics and key performance indicators (KPIs).

·         The client provides workflow forms, alerts, and controls so that users can participate in the business process by using the Workflow system. The Workflow system is a Microsoft Dynamics AX component that enables workflow processes by using Windows Communication Foundation classes.

·         The client provides a Help viewer, which is an application that displays context-sensitive Help topics. The Help topics are retrieved from a Help server that is located on-premises.

·         The client also provides Role Centers, or role-based home pages, for users. Role Centers provide role-specific tasks, activities, alerts, reports, and business intelligence that help users increase their productivity. To interact with the Role Centers that are provided by Enterprise Portal and hosted on Internet Information Services (IIS), the client uses a browser control.

Services and AIF architecture
 This topic describes the high-level architecture of services and Application Integration Framework (AIF).
Enterprise Portal architecture
This diagram provides a logical overview of a Microsoft Dynamics AX 2012 system with an Enterprise Portal server, and also describes the various components of the Enterprise Portal architecture.


Security architecture
This following diagram provides a high-level overview of the security architecture of Microsoft Dynamics AX 2012.


Workflow system architecture
This following diagram provides a high-level architecture of the workflow infrastructure.



Analytics architecture
The following diagram shows the Microsoft SQL Server Analysis Services cubes that are included with Microsoft Dynamics AX, and the components that are used to access them.


Reporting architecture
The following diagram illustrates the architecture of the reporting functionality in Microsoft Dynamics AX.


Sunday, December 4, 2011

Six Basics of Preventing Pain in Your ERP Implementation

"Simplicity is the ultimate sophistication." -Leonardo DaVinci

Over the last decade of being involved with customers and implementation partners for ERP projects, I simply cannot overstate the above sentiment - if you keep everything simple, you make an ERP project smooth and constructive.

Let me explain further. I remember hearing multiple horror stories related to heavy solutions like SAP and Oracle including implementation failures, busted budgets, law suits, and other negativity. It is contrary that the ERP project is aimed at easing organization's way of working ends up being another pain itself.

I don't wish to paint a simplistic picture that the ERP journey is necessarily tough and complex. Things have changed with the advent of more user friendly ERP products like Microsoft Dynamics AX 2012. But even with the best tools, if you are involved in an ERP implementation you can avoid repeating the mistakes of those who walked before you by heeding these important points:

  1. Did you check your expectations from the project? Are they realistic and timely? If not, get down to drawing board and write down what you want to achieve. One simple exercise would involve business shareholders discussing their pains before finding a solution. E.g. Is high inventory cost your problem or lack of supply chain visibility bothering your business? Do you get your payments on time and your profitability ratios remains green? Information Technology is definitely an enabler and the journey to implement business solution should start from the business issues.
  2. Once you know your problems, you can begin your journey for solutions. The next step is finding the right solution and the partner. Did your solution partner devote time to exploring your problem further before jumping to conclusions? An have they done similar projects? It's a clear analogy to when you fall sick - you go to a specialist and highlight your pain areas. Would you like to go to a doctor who wouldn't have time to explore your problem, has never treated your illness before, and jumps to prescribing the cure?
  3. Once you select your solution and the partner, please ensure that their team remains in place. You cannot invest time and effort sharing your business problems with one consultant and expect a replacement to have the same understanding. Ensure continuity of the team involved right from start till the end of the project.
  4. Break the project into more and smaller milestones. Create 10 milestones instead of 4 or 5. It will create better control and accountability of project stakeholders. Remember the time management principle of taking realistic and smaller targets and achieving them. It creates positive energy in the implementation teams as the smaller targets are easier to achieve. Plus, celebrate your each milestone to compound this positive energy.
  5. A carrot and stick approach works well. Keep the stick around to push your implementation teams - internal and external team members - to achieve the milestones. Dangle lot of carrots too, you need to create a motivated and committed energy around the project. Did you provide any bonus to project team for putting in extra hours?
  6. Customisations - the most evident hurdle to any ERP success. Did you weigh the risks for any customizations to the product? I think this is one area where customers should definitely meet other existing customers of the same product. How has their experience been with customizing the product? Did you evaluate all the options to the customized approach and their benefits?

Beyond these points, the customer users need to love the solution. It is going to be part of their daily routine of activities. I favor the user centric design of ERP products like AX 2012, since historically most ERPs fail in ‘connecting with the users'. Microsoft's entry into business applications market has changed the rules of the game in the last decade. It has brought more customers into the ERP fold and has introduced more customers to user friendly ERPs.

Simplicity should rule - both in the product and the implementation process!!

by Raman Dhooria, IT Consultant, Microsoft India

http://msdynamicsworld.com/story/six-basics-preventing-pain-your-erp-implementation

Sunday, October 16, 2011

Dennis Ritchie: The Shoulders Steve Jobs Stood On


Dennis Ritchie (standing) and Ken Thompson at a PDP-11 in 1972. (Photo: Courtesy of Bell Labs)


The tributes to Dennis Ritchie won’t match the river of praise that spilled out over the web after the death of Steve Jobs. But they should.


And then some.

“When Steve Jobs died last week, there was a huge outcry, and that was very moving and justified. But Dennis had a bigger effect, and the public doesn’t even know who he is,” says Rob Pike, the programming legend and current Googler who spent 20 years working across the hall from Ritchie at the famed Bell Labs.
On Wednesday evening, with a post to Google+, Pike announced that Ritchie had died at his home in New Jersey over the weekend after a long illness, and though the response from hardcore techies was immense, the collective eulogy from the web at large doesn’t quite do justice to Ritchie’s sweeping influence on the modern world. Dennis Ritchie is the father of the C programming language, and with fellow Bell Labs researcher Ken Thompson, he used C to build UNIX, the operating system that so much of the world is built on — including the Apple empire overseen by Steve Jobs.

“Pretty much everything on the web uses those two things: C and UNIX,” Pike tells Wired. “The browsers are written in C. The UNIX kernel — that pretty much the entire Internet runs on — is written in C. Web servers are written in C, and if they’re not, they’re written in Java or C++, which are C derivatives, or Python or Ruby, which are implemented in C. And all of the network hardware running these programs I can almost guarantee were written in C.

“It’s really hard to overstate how much of the modern information economy is built on the work Dennis did.”
Even Windows was once written in C, he adds, and UNIX underpins both Mac OS X, Apple’s desktop operating system, and iOS, which runs the iPhone and the iPad. “Jobs was the king of the visible, and Ritchie is the king of what is largely invisible,” says Martin Rinard, professor of electrical engineering and computer science at MIT and a member of the Computer Science and Artificial Intelligence Laboratory.
“Jobs’ genius is that he builds these products that people really like to use because he has taste and can build things that people really find compelling. Ritchie built things that technologists were able to use to build core infrastructure that people don’t necessarily see much anymore, but they use everyday.”

From B to C
Dennis Ritchie built C because he and Ken Thompson needed a better way to build UNIX. The original UNIX kernel was written in assembly language, but they soon decided they needed a “higher level” language, something that would give them more control over all the data that spanned the OS. Around 1970, they tried building a second version with Fortran, but this didn’t quite cut it, and Ritchie proposed a new language based on a Thompson creation known as B.

Depending on which legend you believe, B was named either for Thompson’s wife Bonnie or BCPL, a language developed at Cambridge in the mid-60s. Whatever the case, B begat C.
B was an interpreted language — meaning it was executed by an intermediate piece of software running atop a CPU — but C was a compiled language. It was translated into machine code, and then directly executed on the CPU. But in those days, C was considered a high-level language. It would give Ritchie and Thompson the flexibility they needed, but at the same time, it would be fast.

That first version of the language wasn’t all that different from C as we know it today — though it was a tad simpler. It offered full data structures and “types” for defining variables, and this is what Richie and Thompson used to build their new UNIX kernel. “They built C to write a program,” says Pike, who would join Bell Labs 10 years later. “And the program they wanted to write was the UNIX kernel.”

Ritchie’s running joke was that C had “the power of assembly language and the convenience of … assembly language.” In other words, he acknowledged that C was a less-than-gorgeous creation that still ran very close to the hardware. Today, it’s considered a low-level language, not high. But Ritchie’s joke didn’t quite do justice to the new language. In offering true data structures, it operated at a level that was just high enough.

“When you’re writing a large program — and that’s what UNIX was — you have to manage the interactions between all sorts of different components: all the users, the file system, the disks, the program execution, and in order to manage that effectively, you need to have a good representation of the information you’re working with. That’s what we call data structures,” Pike says.

“To write a kernel without a data structure and have it be as consist and graceful as UNIX would have been a much, much harder challenge. They needed a way to group all that data together, and they didn’t have that with Fortran.”

At the time, it was an unusual way to write an operating system, and this is what allowed Ritchie and Thompson to eventually imagine porting the OS to other platforms, which they did in the late 70s. “That opened the floodgates for UNIX running everywhere,” Pike says. “It was all made possible by C.”


Apple, Microsoft, and Beyond
At the same time, C forged its own way in the world, moving from Bell Labs to the world’s universities and to Microsoft, the breakout software company of the 1980s. “The development of the C programming language was a huge step forward and was the right middle ground … C struck exactly the right balance, to let you write at a high level and be much more productive, but when you needed to, you could control exactly what happened,” says Bill Dally, chief scientist of NVIDIA and Bell Professor of Engineering at Stanford. “[It] set the tone for the way that programming was done for several decades.”

As Pike points out, the data structures that Richie built into C eventually gave rise to the object-oriented paradigm used by modern languages such as C++ and Java.
The revolution began in 1973, when Ritchie published his research paper on the language, and five years later, he and colleague Brian Kernighan released the definitive C book: The C Programming Language. Kernighan had written the early tutorials for the language, and at some point, he “twisted Dennis’ arm” into writing a book with him.

Pike read the book while still an undergraduate at the University of Toronto, picking it up one afternoon while heading home for a sick day. “That reference manual is a model of clarity and readability compared to latter manuals. It is justifiably a classic,” he says. “I read it while sick in bed, and it made me forget that I was sick.”

Like many university students, Pike had already started using the language. It had spread across college campuses because Bell Labs started giving away the UNIX source code. Among so many other things, the operating system gave rise to the modern open source movement. Pike isn’t overstating it when says the influence of Ritchie’s work can’t be overstated, and though Ritchie received the Turing Award in 1983 and the National Medal of Technology in 1998, he still hasn’t gotten his due.

As Kernighan and Pike describe him, Ritchie was an unusually private person. “I worked across the hall from him for more than 20 years, and yet I feel like a don’t knew him all that well,” Pike says. But this doesn’t quite explain his low profile. Steve Jobs was a private person, but his insistence on privacy only fueled the cult of personality that surrounded him.

Ritchie lived in a very different time and worked in a very different environment than someone like Jobs. It only makes sense that he wouldn’t get his due. But those who matter understand the mark he left. “There’s that line from Newton about standing on the shoulders of giants,” says Kernighan. “We’re all standing on Dennis’ shoulders.”


Additional reporting by Jon Stokes.