ERPNext Implementation Implications to look out for?

Hi,

I’m looking to implement ERPNext within a company I work at. We basically sell bottle filling machines (Already assembled, building of the machine is outsourced) and we are around 10 people. I currently use the free package to test and familiarize myself with ERPNext, but before I start implementation and deployment I thought it best to gather some information regarding the potential problems or issues faced when implementing ERPNext specifically.

So getting to the point, I made this thread hoping the kind community may share some of their experiences specifically with ERPNext implementation.

  • Thus any problems to look out for when starting implementation
  • Any problems during setup or data transfer(from old ERP or any data in general).
  • Problems with users w.r.t training, usability, learning curves etc.
  • Problems that might occur afterwards, meaning post implementation. Maybe server issues, connection issues, the things users constantly nagged you and/or the support team about.

The above mentioned are mostly guidelines, so feel free to post any issue you might feel fits this discussion.
Remember this thread is not to help you fix a problem you are experiencing, but rather the sharing of experience w.r.t ERPNext implementation planning and deployment.

I understand this is quite a broad topic, but my thought here is to accumulate your thoughts here and afterwards when I personally experienced ERPNext, I would like to compile and sort this information and redistribute it to the community in a organized format.

And please if there are any other topics or resources that might be useful of similar feel free to direct me.

Thanks

Without diving into a ton of detail, I would say that the single most important part of implementation, PERIOD, is how you structure your data, specifically with items for a distribution business.

Take the time to do that right, and map your current workflow to how it’ll work within the ERP, and things will run smoothly. If you rush it, you can get stuck with all kinds of workflow and naming problems, among other things, and it makes the users a lot more hesitant to adopt the product.

3 Likes

Hi Alec, thanks for the advice
Can’t agree more, we are definitely in the process of setting our standards i.t.o workflows and item codes/names w.r.t an ERP.

Not sure if this works, but BUMP :stuck_out_tongue:

I am new to erp but sound advice I suspect.

On that note here’s a resource worth a look I think:

http://www.osoe-project.org/ To access the notes, look for these links => Access full Lecture

My focus is erpnext, I just spent a few days with erp5 and discovered these lecture notes.

Highlights include a ceo questionnaire and spreadsheet to capture and map the business data. The spreadsheet is used to script the implementation!

Have fun.

1 Like

Also, backup.

ERPNext has a rapid update schedule. Often an update a day, with a small team managing. Which means issues come up with bugs that weren’t found before the update was committed because the manpower isn’t there to beta test everything. I don’t find it an issue but it is something to note.

Long story short, never update without a backup ready to deploy just in case.

1 Like

@whatdoIknow @alec_ruizramon1 @Dbone @Dale_Scott

Yes people forget how fast you did a job, but they remember how well you did it :slight_smile:

Here are better links

https://www.erp5.com/documentation/user/osoe-Lecture.ERP.Configuration.Introduction

https://www.erp5.com/documentation/user/osoe-Lecture.ERP.Configuration.Introduction/P-CLOUDIA-Category.Spreadsheet.HowTo/view

1 Like

We have recently starting switching to ERP.

I did a lot of testing first and found it very flexible, just what we were looking for to replicate what we had build our selves in MS Access

So we started the switch and wow it has been hard work.

It is very easy to test, but however much you test, it tends to be of the normal things. Those slightly abnormal, but fairly frequent things are the ones that catch us out.

I would offer a few pointers

  1. Do not take anything for granted. Just because something is logical to you, does not mean it is logical to others. For example I assumed that the purchase cost of items would be automatically updated in the “buying cost” list. But it isn’t. Currency exchange rates can cause havoc because of rounding. Little things that you assume will be there may not be. So test, test and test some more

  2. If possible start with one aspect only. We have just done the quote > Sales Order > Invoice > Payment cycle to start with. Got that under our belts now (after 5 months) and now progressing on to purchasing and manufacturing

  3. It is difficult to change things afterwards, for example bill of materials. Get a UOM wrong, you cannot just change it, you have to start again

  4. If at all possible run things in tandem. Use your current system WHILE implementingt the new system

  5. The support team, and board members are all brilliant

3 Likes

Hi, I’m kicking tires and working on a demo, but no company and no client… :frowning:

How is everyone documenting your (new) workflows? (or are you?). Do you make your own operations manual with step-by-step instructions? Do you rely on ERPNext documentation? Are you adding to ERPNext documentation somehow?

Also, is anyone doing software testing in anyway? I understand not having manpower (e.g. @Dbone), but is there a way to capture and add company-specific test cases to the ERPNext test suite? (btw, I don’t actually know if there is an “ERPNext test suite”, but I very much hope so).

@whatdoIknow, please say so if this is too far off topic. It’s been great hearing the experiences and recommendations of others. A job came through on the job board that made me think about how much functionality will always require custom client-specific development.

I’m pretty much aligned with this job request so far as a custom Engineer-to-Order or low-volume niche-product engineering-driven Make-to-Stock or Make-to-Order business, and I wouldn’t mind seeing ERPNext move in this direction. However, I suspect ERPNext would perhaps become less simple and generic, as well as being more complicated - which could be a bad thing. Where do you draw the line between base and custom? How much functionality do you expect you will have to add to ERPNext to satisfy your needs? How long do you expect it will take? (e.g. 3 months of kicking tires with out-of-box, 3 months custom development to get the minimum functionality needed for the first aspect (thanks @Ron_Taylor), 6 months for people to absorb the change, then 3 to 6 months of custom development for a more complicated aspect, another 6 months to absorb the change, and pretty soon it’s 3 years down the road. Is this what you expected from the get-go?

How much custom code do you will have when you go live? How do you plan to manage code version control, regression testing, etc.? Is building a continuous release process starting with the erpnext code in github something to aim for, or a waste of time and effort? Do you trust your implementation partner and don’t ask questions? :wink:

Here’s the job posting, but I’ll include it here also for convenience.


We are looking to use Frappe and ERPNext to create a custom B2B portal/marketplace for our trade. The model will work on similar lines as with Flipkart etc. We will have both sellers and buyers on our portal. The front end should have the following features:

  • Our products are industrial in nature and sell by specification. Hence, we do not want any images to show against the products.
  • Products should get listed right below one another without any major space or padding so that maximum products can be seen without scrolling (almost like a table in MS Excel).
  • Apart from product name, product availability i.e the stock quantity, quantity unit, product location, quantity box with update/remove buttons needs to be shown.
  • We want a single button to add multiple products to the cart for which user fills the quantity. This button should hover on the right and scroll alongwith the page so that it is always visible.
  • We want to have filters to be able to search a product better. The filters will be based on the product length width, height, location and manufacturer fields. We need the length width height filters as sliders & location and manufacturers fields as multi checkbox. We want to be able to configure the filters entirely as want.
  • There will be no price during listing of products without customer having logged in.

We want to have our vendors (sellers) be able to login in to the backend and upload/update their products/stock. If more than one vendor adds the stock for the same SKU, it should show total quantity on the product page.

We would require specific customisation for freight (delivery charges) and taxes based on the location, weight etc.

Hi all, thanks for the advice from everyone so far. Unfortunately I am having difficulty being active lately, but please continue to discuss and give your advice as implementers of ERPNext and ERP systems in general. I attended a webinar not to long ago regarding implementations of ERP systems and I will try to get hold of the more complete notes than that which I currently have and share it here when able.

@Dale_Scott Regarding your last question I can’t say I have much experience here just yet, and I don’t mind the question here at all. Implementation for us is still on hold as workload won’t allow time for change just yet. We are aiming to start early next year, maybe February/March. I haven’t come across the need for us to do heavy customizing yet, but will update my experience here as we move forward.

An acquaintance of mine has been implementing ERPNext for small manufacturing companies and from what he tells me the need for customization there is almost zero apart from some that would like an extra field on a certain form etc. To me your use case seems a ‘bit’ more tricky than I might be able to handle at this point.

So please if anyone has some expertise or advice w.r.t @Dale_Scott 's use case, let us know.

People really tend to underestimate what is involved in an implementation, unless they have been thru it before. And every one is different, depending on the client situation and approach. But there are general steps involved in most implementations, which should be detailed in a plan, with as much detail as possible. Some companies try to phase in different parts of the system in logical phases, but most tend to favour the “big bang” approach since everything is integrated. Each one has advantages and disadvantages depending on the circumstances. Managing and monitoring the project is important, and for this you need a plan. Assign responsibilities for important tasks if it isn’t obvious. Don’t skip steps like training for users. Test all the key processes, and look for gaps. Test the data migration before you go live. You can always clear out the transactions data (from the bottom of the company screen). Export and import your master files, and transfer over opening balances, or opening transactions, from the old system but not history, since that will cause a lot of problems in balancing different parts of the accounting (ex. Control accounts in GL to subledgers, like AR or AP or Inventory). You will, also have to balance the summarised GL to financial statements, at a point in time, (which have already been issued). They have to balance or you will have lots of problems with the corporate tax department. You have to involve the accounting people if you are converting the accounting.
Its good to have a test copy and a production copy of the data base. If you want to run parallel its a lot of work, and you will have to reconcile between the old and the new system. Sometimes it might make sense, but sometimes it is not feasible. Try to minimise customisation that affect the accounting unless they are critical to be able to go live. Otherwise they can be done in phase II. Make sure they are well tested. This applies to all ERP implementations with accounting, and not just Erpnext.

1 Like