Overview
This is one issue that I hear from customers using Dynamics NAV (formerly Navision) quite often is why does the Expected Receipt Date keep changing?

The Expected Receipt Date in Dynamics NAV is the main driver for inventory planning. Dynamics NAV uses this field to calculate the availability of the item. Based on this date, Dynamics navNAV calculates when the item can be received into your warehouse.

On the purchase order, the field is on the header and on the lines. Dynamics NAV will only use the field on the purchase lines in the calculation.

What the Help Says
Looking at the help, the explanation is simple enough:

Basically, what it says is that the Expected Receipt Date on the purchase line should copy the information from the purchase header, if it exist. Otherwise, it will follow a formula:

Planned Receipt Date(Order Date on the purchase line + Lead Time Calculation on the Vendor/Item Catalog, if it’s blank, then the Lead Time Calculation on the vendor card)
+ Safety Lead Time(On the Item card or SKU card)
+ Inbound Whse. Handling Time(On the Inventory Setup or the Location card)
= Expected Receipt Date

However, if you continue to drill into the help, you’ll find another formula for the Expected Receipt Date:

Order Date (on the Purchase Order)
+ Lead Time Calculation(From the Item Vendor table, if blank it’ll use the field on the SKU, then the item card)
= Expected Receipt Date

If you drill down on the Lead Time Calculation Help, it will say:

If I follow the formula correctly based on the help:
Order Date + Lead Time Calculation =
= Planned Receipt Date
= Planned Receipt Date + Inbound Warehouse Handling Time + Safety Lead Time
= Expected Receipt Date

Yes… Nice and Simple…

Other Fields that Affect this Date
What the help doesn’t mention is that there are other fields that will affect the Expected Receipt Date. To test this, just create a purchase order and go to the Shipping Fasttab (or tab if you’re using the classic client) in your version of Dynamics NAV.

The Safety Lead Time, Lead Time Calculation and the Inbound Whse. Handling Time explanation is pretty straight forward. In our test, the CRONUS database has 1 day on the Safety Lead Time.

Here’s what happens when you change the following dates on the Purchase Header:

Requested Receipt Date, it will changed/updated on the Purchase Line:
– Order Date
– Planned Receipt Date
– Requested Receipt Date

Promised Receipt Date, it will changed/updated on the Purchase Line:
– Planned Receipt Date
– Expected Receipt Date
– Promised Receipt Date

Expected Receipt Date, it will changed/updated on the Purchase Line:
– Planned Receipt Date
– Expected Receipt Date

Here’s Where It Gets Awkward
These dates work FIFO. So whatever date you change on the Purchase Order header will take precedent over what was entered before.

Worst, when you update the dates on the header, you’ll get a message asking if you want to change the Purchase Lines, WHERE ALL THE INVENTORY CALCULATION TAKES PLACE!

Conclusion
There are a lot of instances where the user will want to look at the purchase order header and get a feel for what is coming in what by who. Make sure the user know exactly what’s going on.

An option would be to remove these dates from the header and force the user to enter the lines. But if you have long purchase order, this is not really an option.

In the end, becareful about changing those dates when you’re entering purchase orders in Dynamics NAV!

¡Como estas amigos! Our good friend Pablo “CRMGamified” Peralta takes the podium again with another pepita de oro!

What does each field in my SLA configuration mean?

(To create new SLA: Configuration > Service > Management > Service Level Agreements: +New)

• Name: Basically, a descriptive name for our SLA, i.e. “Service Level for VIP Clients”. You can edit this field later on.
• Applicable from: This field sets the starting point for calculations. Typically, you would want to track a case since its creation, but you can choose dates and/or hours. It is important you know this information at this point since this field can’t be modified after creating your SLA.
• Business Hours: Select your business work days -and hours- needed to track SLA fulfillment. Keep the following in mind:
  1. If left blank, the system will consider your business hours to be 24×7
  2. So if a VIP client’s case needs to be resolved in 2 days tops, and we receive the case on a Friday afternoon, we would need to resolve the case by Sunday afternoon. Depending on the type of business, this is generally NOT the desired outcome. The system doesn’t consider holidays either.
  3. Therefore, it’s important to set the correct business schedule to properly reflect our organization’s work days and hours.
  4. We still need to be careful when selecting work hours (and not just days) because we can get unexpected results. In order to track the SLA’s fulfillment, the system calculates 24 hours over total work hours per day. Therefore, if my business hours are typically set at 8 per day and my SLA service needs to be resolved in 2 days (as in the last example), my Dynamic CRM will set my deadline at 6 days. Why? Because the system uses the following formula: (24 hours / x daily work hours * n SLA tolerance days) + Date Created (assuming you selected “Created On” as your starting point). So, (24 / 8 * 2) + Date Created = 6 days to close a case after opening it.
  5. You can find a very good explanation for this here.
  6. Conclusion: if measuring minutes and seconds is not mandatory, I would recommend basing your schedule on work days, making each day 24 hours long. I explain how to set a business schedule in the next part.
  7. Good news: you don’t necessarily need to set a business schedule when creating the SLA. You can edit Business Hours later.
• SLA Type: We need to opt for an “Enhanced” SLA unless we have no other choice, or need it to be compatible with the “Standard” SLAs introduced in previous versions. Not only do enhanced SLAs allow pausing, success actions and individual KPI tracking, Standard SLAs are to be discontinued and will become obsolete.
• Allow Pause and Resume: This lets us select if we will allow our SLA to be paused or not. This feature is useful if our case enters a waiting period that depends on the client, or for when a client isn’t reachable. We can set different scenarios that will automatically pause our SLA in Configuration > Administration > System Settings.

Rome was not built in a day and neither are long-term relationships. But on May 19^th Ledgeview Partners will be holding a free one day Lunch ‘n Learn in South Bend, Indiana featuring live demonstrations of two of the leading Customer Relationship Management (CRM) solutions on the market today.

>> Microsoft Dynamics CRM and Salesforce

At this event you can research and evaluate each separately, or compare them head-to-head.

Product specialists are going to show you (in-person) not only the features, but the power of these two amazing products. But it really goes way beyond what these products can do for your sales, marketing and customer service teams. It’s how to connect you with your customers and build long-term mutually beneficial relationships.

If you implement CRM at your organization, will it magically connect you to your customers, increase revenue, or make your employees break into song?  No.

This is something you may be already experiencing with your current CRM product (or lack thereof). It is crazy how many people I encounter that say “I have a CRM but don’t use it” or “We have a CRM but everyone hates it”. Companies are investing a large amount of money and resources into solutions that are failing.

How long are you going to allow that to continue?  – Go ahead, actually say those words out loud.

Think about these questions:

• What is your current pipeline visibility to new leads and opportunities?
• How are you managing your territory, sales quota or company/individual/product goals?
• Can you access a complete 360 degree view of ALL customer information including order history and trends?
• How easy and effective is it to communicate with your customers – and they with you?

At this Lunch N Learn Ledgeview Partners will be demoing Microsoft Dynamics CRM and Salesforce featuring “A Day in the Life” scenarios – but they are doing more than that as trusted business advisors by discussing PROVEN ways companies are implementing CRM, achieving HIGH user adoption rates and seeing MEASURABLE results.

You can buy the fastest car on the lot, but if you don’t know how to drive what good will it do you? Perhaps some driving lessons are in order. You might be content with your current CRM product but just not realizing its full potential?

Attend this South Bend event and talk to Ledgeview about training opportunities they provide to both entire teams as well as for CRM and Salesforce Administrators.

All it will cost you is a few hours away from the office. I know, in today’s world time is more precious than gold, but I guarantee you won’t leave empty handed (or with an empty stomach). After all it is a “Lunch ‘N Learn”.

If South Bend is not in the cards, contact Ledgeview Partners to set up a personal demo and discovery call or ask us about our next live event. They might be coming to your city.

I’m just sayin’ – it’s worth checking out.

The post Ledgeview is bringing Dynamics CRM and Salesforce to South Bend, IN appeared first on Ledgeview Partners.

Do you ever feel overwhelmed by the sheer volume of product numbers in your ERP system? Do you have to constantly decode your product numbers because you have one product ID for every color/size combination you offer? Do you feel a general sense of despair when viewing pages and pages of item numbers for the same core item? Then you may be suffering from Complexitis.

Outbreaks of Complexitis commonly occur among organizations using outdated or legacy ERP systems that lack the ability to manage item variations outside of the product. Every time there is change to a product color or size offering, or an altogether new product number needs to be created, you are creating unnecessary complexities for your self— there‘s a better way. Let’s explore the phenomena of Complexitis with a short example.

Imagine a shoe manufacturer, Bob’s Boots, with a severe case of Complexitis. Bob’s Boots makes work boots in five industry-specific styles. However, each of the five different styles of boots comes in 15 sizes, three colors, and three widths. That’s over 600 product numbers for what essentially boils down to five styles of boots! What if Bob’s Boots wants to add another color or more widths? That’s a lot of new product IDs to create in the ERP system. Let’s not even talk about reporting the aggregated performance to the style level—it’s a total mess. Finally, Bob’s Boots’ parent company, Frank’s Fabulous Footwear, has decided that work boots for women should be offered next season. If that comes to pass, Bob’s Boots will be drowning in product numbers.

If left untreated, Complexitis is rarely fatal. However, it can spread and cause a chronic ripple effect throughout the rest of the organization, as in the case of Bob’s Boots. They experienced painful, manual, overly complex reporting and massive amounts of product data. In the purely fictional scenario of Bob’s Boots, it’s easy to see how Complexitis can quickly get out of control.

Luckily, there is a cure. It can be found in the multi-dimensional product capabilities of Microsoft Dynamics AX. Right out of the box Dynamics AX can deal with the product complexities that are inherent to apparel, footwear, and furnishings companies like size, color, width, configuration, and more, while keeping only the style as the core product number.

Now, before you get too worked up about where your color/size dimensions will go if they aren’t in the product number, rest assure they are still there! Microsoft Dynamics AX allows you to have one core product number (In this example, A0107) with multiple dimensions such as size, color, and width attached to that core number.

The beauty of Microsoft Dynamics AX is that you can have your cake and eat it too. That is, you can still have the multiple product details you need, but can also report on a single variant. Let’s say you just want to see how many colors of each type of boot you have on hand. Instead of having to sort through hundreds of product numbers, you can simply roll up the data, as illustrated in this screen shot. Easy, right?

When it comes to treating Complexitis, you’ll want someone with experience in the field, a history of success, and a familiarity with the problem. If you think you may be suffering from a case of Complexitis, don’t let it linger, call the leading primary ERP care provider: Sunrise Technologies.

I was reading code complete 2, which is an excellent book and I would recommend all CRM developer read it, you will learn lots of things.

The book mentions information hiding, this may be a new concept to some CRM developers because it’s not a term you hear very often.

Steve McConnell the author of Code Complete 2 has a great article on it called Missing in Action: Information Hiding

Information hiding would be a by product of code using the S.O.L.I.D principles

What is information hiding

I find it helpful to use multiple definitions, design principles it can be difficult to understand and different perspectives can be beneficial.

Programming Practices

Information hiding focuses on hiding the non-essential details of functions and code in a program so that they are inaccessible to other components of the software. A software developer applies information hiding in software design and coding to hide unnecessary details from the rest of the program. The objective of information hiding is to minimize complexities among different modules of the software. Note that complexities arise when one program or module in software is dependent on several other programs and modules.

Information Hiding

The basic idea is that if code chunk A doesn’t really need to know something about how code chunk B (which it calls) does its job, don’t make it know it. Then, when that part of B changes, you don’t have to go back and change A.

 

Hosk Definition of Information hiding

Information hiding is not just about hiding data but hiding how it implements those behaviours.   Classes  have public methods but hides the private methods and variables which implement the logic behind the public methods

Why is information hiding important

Information hiding reduces dependency on class variables, allowing classes/methods to act like black boxes, hiding logic from the consumers of the class.  Hiding variables reduces potential coupling and dependant classes, which will reduce the effect of change on your code.

Information hiding is not just hiding variables but the methods and internal logic.  Hiding information results in less code being dependant on concrete classes/implementation, allowing internal workings of classes without needing to change any other classes.

This blog post highlights some good points about information hiding

Why you should care about information hiding

Information hiding makes methods and variables private, hiding the internal logic from other classes.  Developers can change the internal logic without changing dependent code.

Methods should only accessed is via the public methods, hiding the internal workings of the class.  CRM developer can change the internal workings of the class and not effect any of the classes which call those methods.

If classes have public variables, public variables might be used by other classes creating a dependency, if you change a public variable you need to check the calling classes still work.

Changing the logic of public variables/methods can effect any dependent classes which will result in more code changed, more testing and an increased chance of creating a bug.

To help understand information hiding it’s helpful to think the CRM SDK.  When we call IOrganisationService.Update(Entity).  We don’t have access to any fields, we have no idea how the code updates the CRM database or what steps it does.

Microsoft could change the IOrganisationService.Update(Entity) to use a different language but because I only consume the public method none of my code would need to change (assuming it works the same way).  Code calling the CRM SDK is loosely coupled.

How you use Information hiding outside of coding

Information hiding and Encapsulation in OOP has a great definition of information hiding

“Showing only those details to the outside world which are necessary for the outside world and hiding all other details from the outside world.”

Real life examples

Facebook

You can hide private information from certain people to stop them using it and only show your name.

Computer operating system

Windows/Linux give you a nice GUI operating system to manage your computers but underneath there are lots of private files and programs.

Encapsulation

Hiding the internals of the object protects its integrity by preventing users from setting the internal data of the component into an invalid or inconsistent state. A supposed benefit of encapsulation is that it can reduce system complexity, and thus increase robustness, by allowing the developer to limit the inter-dependencies between software components^{[citation needed]}.

The benefit of encapsulation,  hiding business logic by using private methods and interfaces/abstract classes.  Encapsulation limits the effects of change.  Encapsulation hides/removes dependency on the concrete code behind your public methods

Information Hiding helps reduce the effects of change

Code changes all the time and there are lots of things which can result in code change

• Change in requirements
• Fixing a bug
• Refactoring
• Extension

Developers cannot control change but they can control how the code will be affecting by change.  Good code design using the S.O.L.I.D principles will reduce the effect of code changes in the code.

Information hiding is one of the tools developers have to reduce the effect of change, hiding the information will create loosing coupling/low dependency and using interfaces/abstract classes will isolate your concrete implementation code from the rest of the system and create loose coupling.

This design principle is described in the Law of Demeter, which described excellent in this article  SOLID Design principles

I find it useful to refer to these principles when writing code because it helps to create

Information hiding helps reduce the complexity of code by creating loosely coupled code and more modular code.  Information hiding reduces the dependencies on classes, a class coupled with multiple classes in a system, it’s difficult to understand and change the code because you need to understand how the change would effect all the dependent classes.

Information hiding helps reduce coupling by hiding concrete logic which helps mitigate the effects of changing the concrete logic.

The more independent/loosely coupled code you have the more code reuse you will have.

Benefits of Information hiding

• Simplifies the code
• Reduce complexity
• Limit dependencies in code
• Improved code readability/Increased understanding

futher reading

http://c2.com/cgi/wiki?InformationHiding

http://en.wikipedia.org/wiki/Information_hiding

High Cohesion – Loose Coupling

information hiding with Javascript

Why you should care about encapsulation

In the Microsoft Dynamics community, there can be a stereotype that contractors are “mercenaries” due to misconceptions that they are an expensive necessary evil who simply look to milk an end customer. In reality, the best contractors rely purely on reputation and place more importance on integrity than end users typically give them credit for. They cannot afford to burn bridges due to the niche nature of the market across which they operate, so this stereotype needs to be turned on its head. Here we show why contractors can in fact be critical to the successful delivery of an end-user’s Microsoft Dynamics project:

1) They’re veterans in their field

Contractors allow the end user to have a solution expert in-house for Microsoft Dynamics. If any problems arise they are the “go-to” individual to quickly resolve problems. This provides a healthy challenge as to whether the solution is the best fit for the business’s long term plans. Having that point of expertise is re-assuring to the team as they have been there and done it. With such a requisite level of foresight and an ability to know when and where things are likely to go wrong (as they inevitably do) this can prove valuable for plans across each particular phase of a Microsoft Dynamics implementation.

2) They smooth the knowledge gaps between an End User and Partner

By using contractors, it is easier to question the decisions of partners to ensure an effective relationship; contractors often come from the partner channel and therefore provide useful insights about working practices and commercial pressures. Good, experienced contractors can independently advise on the best course of action across a programme saving time and money. This is not to undermine the role of the partner, but simply to question, from an end user perspective, why certain decisions are being made, working almost like a neutral arbiter and advisor to the end client.

3) They can teach their permanent colleagues a thing or two

On Greenfield projects there will be a serious lack of skills in-house and awareness as to how the implementation will progress. Good contractors can assist in the creation of the project road map and bring previous experience of how things were done on successful previous programmes. This knowledge rubs off on permanent resources working with them such as in-house .Net Developers or Functional BAs. These permanent resources who have worked with an end user for a number of years will reap huge rewards from working with experienced contractors by broadening their knowledge. The end user itself is also likely to gain, as they will end up with a better skilled workforce that will be able to utilise this knowledge if the decision is taken further down the line to do an upgrade or re-implementation of a later version of the Microsoft Dynamics solution.

4) They can help you market your business

Within a niche skills market, contractors will always be incentivized to perform to the best of their ability because reputation within such a shallow market means everything. Having reputable consultants with a history of delivering successfully is a major selling point for anyone else looking to join your project. In a highly competitive market this could help your brand when competing for the best people. This brings us on to the last point regarding availability…

5) They are more readily available than permanent employees

The best permanent consultants work for the most prestigious consultancies/partners and tend to be loyal to their employer. The length of Microsoft Dynamics implementation means that a consultant brought in on this basis has a similar shelf-life to what a contractor has once the project is completed. Unlike end users, partners can offer project variety and career growth specific to Dynamics that will outlast a 2-3 year programme (contingent on the partner’s success as well). A Junior Consultant can join an organisation in a technical capacity – say a Developer role – and know that once they have built up a reputation for themselves across several projects that they can look at progression to a more Senior or Architect level role. This makes it harder for end users to compete with this the career progression on offer as an end user programme will always have a shelf life. Therefore, opportunities to bring in contractors who increase the marketability of a project with their considerable skills and experience should not be viewed as a “necessary evil” but more as something that is critical to successful solution delivery.

These points show how the contractor market across the Microsoft Dynamics channel is misunderstood. Contractors who work onsite for end users further diversify the understanding of the Microsoft Dynamics product on offer as they will work with in-house teams increasing their knowledge of the product as well as an awareness of best practice. This helps the market for Microsoft Dynamics professionals as those with no previous experience can get to a level where they can begin to consider working across the partner channel or become a specialist.

But… Proceed with caution!

Of course, not all Dynamics contractors are going to be great and you need to look out for tell-tale signs that a contractor should be approached with caution. These include expensive contractors who lack experience of end-to-end projects, contractors who have never worked on a long term project, and those who have never had a contract renewal. Don’t let this scare you – these contractors are definitely in the minority! Put simply, the majority of contractors add value and it can be easy to avoid the bad ones.

There are ways that employers can protect themselves from troublesome contractors to reduce the risk to the business: you could consider retention clauses, bonus payments for successful work or putting a short notice period into the contract – all good contractors in the Microsoft Dynamics community will be happy with these, as they know that they can perform to the desired standard. To know whether or not a contractor is trusted you could to speak to a specialist Microsoft Dynamics recruitment agency like Cognitive Group, who know the contractors to avoid. The chances are we have been burnt before, so we are keen to avoid a repeat as much as you!

If you would like to discuss contract or permanent jobs with us, please get in touch:

UK Tel: 020 3587 7772

EU Freephone: +800 4433 2929

Email: info@cognitive-group.com

The post Why contractors are critical to the successful delivery of an end-user’s Microsoft Dynamics programme appeared first on .