Confessions of a Dynamics 365 Business Central Consultant
My journey in the world of consulting using Microsoft Dynamics 365 Business Central
Got a suggestion to make the product better? Go here to log your suggestions (or complaints, rants, raves, etc). It’s about time Microsoft has something like this.
https://connect.microsoft.com/dynamicssuggestions
Make your voice count! Microsoft is listening!
In Dynamics NAV 5.0SP1, the caption for Your Reference has been changed to Customer PO No. For us, we’ve always used External Document No. to store the Customer PO No. on the sales order.
It’s obvious that the change in 5.0 SP1 was done due to partner requests. I just want to get your opinion on where you put the Customer PO No. when entering a sales order. Please vote here:
http://dynamicsuser.net/forums/t/23238.aspx
Just thought I post some etiquette for Solution Centers (NSC) and contractors when dealing with each other.
For Contractors:
1. There’s no such thing as job security when you’re a contractor. If you want security, find a full time position at a NSC.
2. Do not set your rates based on how much the NSC charges their customers. Figure out a market rate for your skillset and make it fixed.
3. Contractors are used only for the short term. If you want long term, find a full time position at a NSC.
4. Learning time is not billable. Companies hire your skillset to produce, not to learn. If you want to be paid for learning, find a full time position at a NSC.
5. You have the right to say no to a project. But say no before a single minute is charged.
6. Make a conscience effort to not steal your client’s customers. The end users will decide on their own, but do not push it.
7. Do not make a promise to deliver you cannot keep. Sometimes, a lot of people are waiting on you to finish before they can continue.
8. Make doing business easy with you. NSCs do not need you if you give them more headaches than they already have.
9. The NSC has the right to shop around for whatever reason, you’re a vendor and this is a business transaction. Don’t take it personal.
For NSCs:
1. Pay your contractors on time. You hired them to produce, if they’ve done so, pay them. Don’t play games.
2. Sometimes, trial and error is needed to get to a solution. If the contractor bills you for it, pay; because you will need to do the same if you were doing the project yourself.
3. Murky project scope will get murky results. If you cannot properly define the project, no contractor in the world will be able to clarify it for you. And pay the large bill your contractor will surely bill you because you didn’t do your job.
4. If you rely on the contractor to take care of your customer, you WILL lose the customer. Guarenteed.
5. Contractors you hire have their own priorities, so plan accordingly. If you want the contractor’s dedication, offer them a full time position.
6. Contractors are used to address specific needs. They’re not there to organize an implementation for you.
Did I miss anything? Any additions to both sides are welcome.
If you’re in an environment where you have multiple companies setup and each company uses the same items, you might be tempted to share the item table across all companies.
In versions prior to 5.0, you can get away with this since the Adjust Cost process are done using the Item Ledger and Item Application Entry table. When inventory is taken out, it’ll use the proper average cost when the Adjust Cost process is ran.
However, in version 5.0, they introduced the Avg. Cost Adjmt. Entry Point table and the Cost is Adjust field on the item card. This means that if if you just share the tables and adjust cost is ran for Company A, it’ll mark the Cost Is Adjusted to true. This means that the Adjust Cost process will never be ran for Company B. In addition, when transactions are posted for Company B, it’ll look at the Avg. Cost Adjmt. Entry Point table and detect that the cost has not been adjusted and mark it for adjustment again.
The best solution to this problem is to suggest the users to update item information for both companies. However, if the business requirement is to share the Item table, it’s recommended that you keep the tables separate. And write a batch process to update items at the end of day or if it needs to be real time, write code to something like:
ItemCompanyB.CHANGECOMPANY(‘Company B’);
IF ItemCompanyB.GET(“No.”) THEN BEGIN
CostPostedGL := ItemCompanyB.”Cost is Posted to G/L”;
CostAdj := ItemCompanyB.”Cost is Adjusted”;
UnitCost := ItemCompanyB.”Unit Cost”;
ItemCompanyB.TRANSFERFIELDS(Rec);
ItemCompanyB.”Cost is Posted to G/L” := CostPostedGL;
ItemCompanyB.”Cost is Adjusted” := CostAdj;
ItemCompanyB.”Unit Cost” := UnitCost;
IF NOT ItemCompanyB.INSERT THEN
ItemCompanyB.MODIFY;
END;
You can probably write a better code, but you should be able to get the idea. This will also require that all the item master information be entered into one company.
This will only apply if the following is true:
1. You’re upgrading from 3.x or 4.x to 5.0
2. You’re using average cost
3. You have the Avg. Cost Calc type to Item&Variant&LocatoinIF you are using Average Cost and IF your Average Cost Calc. Type is Item & Location & Variant, when you upgrade to 5.0. The cost calculation type will be set to ITEM.At this point, DO NOT RUN ADJUST COST!!! It will calculate your average by ITEM for all historical transactions irregardless if you changed the Average Cost Calc. Type to item & location.This is a problem in the Avg. Cost Adjmt. Entry Point table and the Accounting Period table. You will need to write a process to update the Avg. Cost Adjmt. Entry Point table so it’s by location, and change the Accounting Period to Item & Location & Variant.
Here’s the code for download.