Re: item codification

Hi Robert,

Answers below:

On 10-Feb-2012, at 1:24 PM, Robert Becht wrote:

Hi ,

Thanks for yr suggestions on stock updating earlier this morning.
Indeed the idea to start with a “dummy” on 1.1.12 is a good one.

What about this to allow a certain degree of negative stock. Just yr opinion, for discussion.
I see yr point of garbage in garbage out, but I will also know the frustration of the end user who want to sell an item and first has to update quickly inventory levels in order to do so. This will also create garbage, because the sales person (me, my wife, our business friend) will not go to the paper invoice files, look for the the last suppliers invoice, enter the data, while the client is waiting. What will happen in practice is that a) the item is not entered at check out (most likely) or b) quickly the item will be “created” by a stock reconsilliation with most likely a random number to the discretion of the user. Please consider that a client is waiting, and is not interested in the fact that ERPNEXT is not allowing negative stocks. So thew quick fixes are also introducing garbage, where with negative stock you can properly do the correct accounting later on.

I have seen a few implementations and what I have realized is good inventory control is also about good practices. In the ideal case, the system inventory should closely reflect the real inventory only then will you learn to rely on the system and hence benefit from it.

Once you are confident that the system has accurate stock, then it will make life much easier later on. Like you can just check the system if you have a particular item in stock or no instead of hunting around. I would recommend that you make a system entry as soon as you receive material and keep the stock as accurate as possible.

It is also about fixing responsibility and accountability - I know that can be tricky with your wife :wink:

What I could consider as an alternative is that I enter say 10 units as default on opening. (or at an other moment). So I artificial raise every item count by 10.
In all further processing, I should considwer this (with definitely some disadvantage, eg that the stock value is not represented correctly.

Not sure whether, with a file upload I can “reconcile” the opposite way at a certain moment, namely to subtract 10 UoM of all items in the inventory.

Stock can be reconciled both ways (If I am correct, even if you make entries before that date, entries after the reconciled date will not be changed)

Please share yr view.

Nice that u wrote on codification.
I fully agree on the need of codification but there are some other considerations as well.

What you subscribe is an internal consistent way of coding, where the code itself contains info on the item.

What I have done so far (the last 2 yrs running Dogs Love IT) is to observe the “supplier code” (if available) and for repacked item use a post-fix.

Using supplier code has the advantage that there is absolute no confusion about the article, especially useful if you sell the(almost) the same article from different suppliers.

Example. We sell dried fish prepacked and bulk and than repacked.

AAA dried fish 100g
BBB dried fish 100g
CCC dried fish 5 kg
CCC_250g dried fish 250g

So I maintain the suppliers code (AAA,BBB and CCC) so that I know which dried fish I 'm talking about, and secondly if I repack I derive the code from the suppliers code, by adding the weight info at the end, so also for repacked stuff I know the origin/supplier.

This is a good idea, my suggestion for your example would be,

DF-250-AAA
DF-250-BBB
DF-5000-CCC
DF-250-CCC

(this way when you type DF- you will know what options you already have)

We can argue about the pros/and cons of different systems, but I feel that the search should be as fast and generic as possible.

I don’t know whether it would be very difficult to implement a Property Setting of the select box where the end use can define the search properties/preferences.

If that were possible my search setting would be to search default in name/or decription , now it is ID. Secondly I would alternate the % and “no prefix”, meaning that by default I would search “string inside a string” (that is now indicated by %) and use say the % if I would constrain it to “match the beginning of two strings”, now the default setting.

I could do that, but just worried about the extra search effort the system might have to make and its effect on speed… Let me give this a thought, this may be possible.

An additional advantage of maintain suppliers code is when entering the purchase invoice, one just have to type in the item codes on the paper supplier invoice and add quantity. No search necessary. If the item does not “pop up” when entering the code it means that I have never bought before, and I can than “create” that item from the invoice.

Well, during this discussions “my system” is emerging; I think I will set up a coding system along your guidelines in item_ID, maintain the supplier code in Name, and have the description in description. That seems to be the best of both worlds

May be we should copy this discussions to the forum to have interaction with other users of erpnext

Sure I will copy it to the forum!

Rgds robert

-----Original Message-----
From: Rushabh Mehta [mailto:rm...@gmail.com]
Sent: Friday, February 10, 2012 7:20 AM
To: Robert Becht
Subject: item codification

wrote an article on it:

http://frappe.erpnext.com/#!item-codification


ERPNext - World’s most affordable ERP.

W: https://erpnext.com
T: @rushabh_mehta

Faculty of Geo-Information Science and Earth Observation (ITC)
University of Twente
Chamber of Commerce: 501305360000

E-mail disclaimer
The information in this e-mail, including any attachments, is intended for the addressee only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the content of this information is strictly prohibited. If you have received this e-mail by mistake, please delete the message and any attachment and inform the sender by return e-mail. ITC accepts no liability for any error or omission in the message content or for damage of any kind that may arise as a result of e-mail transmission.

In order to fine tune user friendliness:

I have set up a coding scheme. I believe that the system could provide
some assistance in quickly and correctly coding when in the item code
field a droplist would produce all existing codes with the type
charcters.

What i mean: say i have code upv1,upv2,and upv3 already used.

typing u would list all codes starting with u, typing up all codes
starting with up, and upv thus upv1,upv,2 and upv3 so that the user
easily sees that that upv4 is the new item to be created.

Well, nothing spectacular, but just easy to manage codes i believe,
robert

On Feb 10, 9:26 am, Rushabh Mehta rm...@gmail.com wrote:

Hi Robert,

Answers below:

On 10-Feb-2012, at 1:24 PM, Robert Becht wrote:

Hi ,

Thanks for yr suggestions on stock updating earlier this morning.
Indeed the idea to start with a “dummy” on 1.1.12 is a good one.

What about this to allow a certain degree of negative stock. Just yr opinion, for discussion.
I see yr point of garbage in garbage out, but I will also know the frustration of the end user who want to sell an item and first has to update quickly inventory levels in order to do so. This will also create garbage, because the sales person (me, my wife, our business friend) will not go to the paper invoice files, look for the the last suppliers invoice, enter the data, while the client is waiting. What will happen in practice is that a) the item is not entered at check out (most likely) or b) quickly the item will be “created” by a stock reconsilliation with most likely a random number to the discretion of the user. Please consider that a client is waiting, and is not interested in the fact that ERPNEXT is not allowing negative stocks. So thew quick fixes are also introducing garbage, where with negative stock you can properly do the correct accounting later on.

I have seen a few implementations and what I have realized is good inventory control is also about good practices. In the ideal case, the system inventory should closely reflect the real inventory only then will you learn to rely on the system and hence benefit from it.

Once you are confident that the system has accurate stock, then it will make life much easier later on. Like you can just check the system if you have a particular item in stock or no instead of hunting around. I would recommend that you make a system entry as soon as you receive material and keep the stock as accurate as possible.

It is also about fixing responsibility and accountability - I know that can be tricky with your wife :wink:

What I could consider as an alternative is that I enter say 10 units as default on opening. (or at an other moment). So I artificial raise every item count by 10.
In all further processing, I should considwer this (with definitely some disadvantage, eg that the stock value is not represented correctly.

Not sure whether, with a file upload I can “reconcile” the opposite way at a certain moment, namely to subtract 10 UoM of all items in the inventory.

Stock can be reconciled both ways (If I am correct, even if you make entries before that date, entries after the reconciled date will not be changed)

Please share yr view.

Nice that u wrote on codification.
I fully agree on the need of codification but there are some other considerations as well.

What you subscribe is an internal consistent way of coding, where the code itself contains info on the item.

What I have done so far (the last 2 yrs running Dogs Love IT) is to observe the “supplier code” (if available) and for repacked item use a post-fix.

Using supplier code has the advantage that there is absolute no confusion about the article, especially useful if you sell the(almost) the same article from different suppliers.

Example. We sell dried fish prepacked and bulk and than repacked.

AAA dried fish 100g
BBB dried fish 100g
CCC dried fish 5 kg
CCC_250g dried fish 250g

So I maintain the suppliers code (AAA,BBB and CCC) so that I know which dried fish I 'm talking about, and secondly if I repack I derive the code from the suppliers code, by adding the weight info at the end, so also for repacked stuff I know the origin/supplier.

This is a good idea, my suggestion for your example would be,

DF-250-AAA
DF-250-BBB
DF-5000-CCC
DF-250-CCC

(this way when you type DF- you will know what options you already have)

We can argue about the pros/and cons of different systems, but I feel that the search should be as fast and generic as possible.

I don’t know whether it would be very difficult to implement a Property Setting of the select box where the end use can define the search properties/preferences.

If that were possible my search setting would be to search default in name/or decription , now it is ID. Secondly I would alternate the % and “no prefix”, meaning that by default I would search “string inside a string” (that is now indicated by %) and use say the % if I would constrain it to “match the beginning of two strings”, now the default setting.

I could do that, but just worried about the extra search effort the system might have to make and its effect on speed… Let me give this a thought, this may be possible.

An additional advantage of maintain suppliers code is when entering the purchase invoice, one just have to type in the item codes on the paper supplier invoice and add quantity. No search necessary. If the item does not “pop up” when entering the code it means that I have never bought before, and I can than “create” that item from the invoice.

Well, during this discussions “my system” is emerging; I think I will set up a coding system along your guidelines in item_ID, maintain the supplier code in Name, and have the description in description. That seems to be the best of both worlds

May be we should copy this discussions to the forum to have interaction with other users of erpnext

Sure I will copy it to the forum!

Rgds robert

-----Original Message-----
From: Rushabh Mehta [mailto:rm...@gmail.com]
Sent: Friday, February 10, 2012 7:20 AM
To: Robert Becht
Subject: item codification

wrote an article on it:

http://frappe.erpnext.com/#!item-codification


ERPNext - World’s most affordable ERP.

W:https://erpnext.com
T: @rushabh_mehta

Faculty of Geo-Information Science and Earth Observation (ITC)
University of Twente
Chamber of Commerce: 501305360000

E-mail disclaimer
The information in this e-mail, including any attachments, is intended for the addressee only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the content of this information is strictly prohibited. If you have received this e-mail by mistake, please delete the message and any attachment and inform the sender by return e-mail. ITC accepts no liability for any error or omission in the message content or for damage of any kind that may arise as a result of e-mail transmission.

Hi Robert,

I would suggest you make a 1 page manual for codification - you will need sequencing of codes, but your most significant digits should have a meaning.

best,
Rushabh


---------------------------------------------------------
ERPNext - World's most affordable ERP.

W: https://erpnext.com
T: @rushabh_mehta

On 13-Feb-2012, at 7:37 PM, robert wrote:

In order to fine tune user friendliness:

I have set up a coding scheme. I believe that the system could provide
some assistance in quickly and correctly coding when in the item code
field a droplist would produce all existing codes with the type
charcters.

What i mean: say i have code upv1,upv2,and upv3 already used.

typing u would list all codes starting with u, typing up all codes
starting with up, and upv thus upv1,upv,2 and upv3 so that the user
easily sees that that upv4 is the new item to be created.

Well, nothing spectacular, but just easy to manage codes i believe,
robert




On Feb 10, 9:26 am, Rushabh Mehta <rm...@gmail.com> wrote:
Hi Robert,

Answers below:

On 10-Feb-2012, at 1:24 PM, Robert Becht wrote:

Hi ,

Thanks for yr suggestions on stock updating earlier this morning.
Indeed the idea to start with a "dummy" on 1.1.12 is a good one.

What about this to allow a certain degree of negative stock. Just yr opinion, for discussion.
I see yr point of garbage in garbage out, but I will also know the frustration of the end user who want to sell an item and first has to update quickly inventory levels in order to do so. This will also create garbage, because the sales person (me, my wife, our business friend) will not go to the paper invoice files, look for the the last suppliers invoice, enter the data, while the client is waiting. What will happen in practice is that a) the item is not entered at check out (most likely) or b) quickly the item will be "created" by a stock reconsilliation with most likely a random number to the discretion of the user. Please consider that a client is waiting, and is not interested in the fact that ERPNEXT is not allowing negative stocks. So thew quick fixes are also introducing garbage, where with negative stock you can properly do the correct accounting later on.

I have seen a few implementations and what I have realized is good inventory control is also about good practices. In the ideal case, the system inventory should closely reflect the real inventory only then will you learn to rely on the system and hence benefit from it.

Once you are confident that the system has accurate stock, then it will make life much easier later on. Like you can just check the system if you have a particular item in stock or no instead of hunting around. I would recommend that you make a system entry as soon as you receive material and keep the stock as accurate as possible.

It is also about fixing responsibility and accountability - I know that can be tricky with your wife ;)

What I could consider as an alternative is that I enter say 10 units as default on opening. (or at an other moment). So I artificial raise every item count by 10.
In all further processing, I should considwer this (with definitely some disadvantage, eg that the stock value is not represented correctly.

Not sure whether, with a file upload I can "reconcile" the opposite way at a certain moment, namely to subtract 10 UoM of all items in the inventory.

Stock can be reconciled both ways (If I am correct, even if you make entries before that date, entries after the reconciled date will not be changed)









Please share yr view.

Nice that u wrote on codification.
I fully agree on the need of codification but there are some other considerations as well.

What you subscribe is an internal consistent way of coding, where the code itself contains info on the item.

What I have done so far (the last 2 yrs running Dogs Love IT) is to observe the "supplier code"  (if available) and for repacked item use a post-fix.

Using supplier code has the advantage that there is absolute no confusion about the article, especially useful if you sell the(almost) the same article from different suppliers.

Example. We sell dried fish prepacked and bulk and than repacked.

AAA   dried fish 100g
BBB dried fish 100g
CCC dried fish 5 kg
CCC_250g dried fish 250g

So I maintain the suppliers code (AAA,BBB and CCC) so that I know which dried fish I 'm talking about, and secondly if I repack I derive the code from the suppliers code, by adding the weight info at the end, so also for repacked stuff I know the origin/supplier.

This is a good idea, my suggestion for your example would be,

DF-250-AAA
DF-250-BBB
DF-5000-CCC
DF-250-CCC

(this way when you type DF- you will know what options you already have)



We can argue about the pros/and cons of different systems, but I feel that the search should be as fast and generic as possible.

I don't know whether it would be very difficult to implement a Property Setting of the select box where the end use can define the search properties/preferences.

If that were possible my search setting would be to search default in name/or decription , now it is ID. Secondly I would alternate the % and "no prefix", meaning that by default I would search "string inside a string" (that is now indicated by %) and use say the % if I would constrain it to "match the beginning of two strings", now the default setting.

I could do that, but just worried about the extra search effort the system might have to make and its effect on speed.... Let me give this a thought, this may be possible.

An additional advantage of maintain suppliers code is when entering the purchase invoice, one just have to type in the item codes on the paper supplier invoice and add quantity. No search necessary. If the item does not "pop up"  when entering the code it means that I have never bought before, and I can than "create" that item from the invoice.

Well, during this discussions "my system" is emerging; I think I will set up a coding system along your guidelines in item_ID, maintain the supplier code in Name, and have the description in description. That seems to be the best of both worlds

May be we should copy this discussions to the forum to have interaction with other users of erpnext

Sure I will copy it to the forum!







Rgds robert

-----Original Message-----
From: Rushabh Mehta [mailto:rm...@gmail.com]
Sent: Friday, February 10, 2012 7:20 AM
To: Robert Becht
Subject: item codification

wrote an article on it:

http://frappe.erpnext.com/#!item-codification

---------------------------------------------------------
ERPNext - World's most affordable ERP.

W:https://erpnext.com
T: @rushabh_mehta

Faculty of Geo-Information Science and Earth Observation (ITC)
University of Twente
Chamber of Commerce: 501305360000

E-mail disclaimer
The information in this e-mail, including any attachments, is intended for the addressee only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the content of this information is strictly prohibited. If you have received this e-mail by mistake, please delete the message and any attachment and inform the sender by return e-mail. ITC accepts no liability for any error or omission in the message content or for damage of any kind that may arise as a result of e-mail transmission.

Hi Robert,


I have been looking at your discussion with Rushabh, I would like to point out one most important thing that item codification can is the most critical part in setting up of a good system.

Now I had a similar problem in my company where we are manufacturing cutting tools now I would like to share my item code which we have devised over the years and I hope I am following the best practices. Even this system of codification is not sufficient to cater to the vast items we manufacture but it does take care of the 80% of the things and the other 20% which are MADE to order are all tracked by one item code. Let me explain my scenario:

We are manufacturing cutting tools of HIGH SPEED STEEL & CARBIDE which are SQUARE, RECTANGULAR, ROUND in shapes to name a few. There are all in all 6000 item codes currently running on ERPNEXT.

I have the item codes like this:

H     RE      0250       1905     0200  -     0        1       0

  1.  H= The base material of the tools which is H in case of HSS and C in case of CARBIDE
  2. RE= Denotes the type of tool, so for SQUARE it is SQ, RECTANGULAR = RE, ROUND= RD, ENDMILL =SE, Ball Nose Endmill = BE, Drill = DR
  3. 0250 = Denotes the first dimension of the tool and is denoted by millimeters so 0250=2.50mm, 1000=10mm, 9999=99.99mm since we don’t manufacture anything above 25mm and max is 80mm we have gone to therefore we are using only 4 digits
  4. 1905 is the same as item 3, but in case of SQ where 3=4 we are not using the 4th part so HSQ09530200-010 is the item code for HSS SQUARE 9.53mm x 9.53mm x 200mm
  5. The DASH is actually a redundant character in our system as of now.
  6. 0 = Denotes the number of Flutes (I know I am getting technical, but I am just giving example of my company)
  7. 1= This actually denotes the quality of tools since we have different kind of qualities in 2 major materials
  8. And the last 0 is for denoting some kind of special treatment and each letter has a meaning like 0=No Special Treatment, 1=TiAlN Coating, 2=TiN Coating, 3=ACX Coating…and so on.

I hope this helps, as for the suggestion by Rushabh for your codification is great according to me. Suppose you have item codes as per the supplier

> AAA   dried fish 100g
> BBB dried fish 100g
> CCC dried fish 5 kg
> CCC_250g dried fish 250g 

Now if you enter the system with AAA it would list all the items from AAA supplier but whereas you should have a system where you can give your customer a choice between brands therefore


DF-250-AAA
DF-250-BBB
DF-5000-CCC
DF-250-CCC 

is a much better option than the one mentioned by you earlier. Lets face it a customer comes to buy Dried Fish, so he/she can take AAA or BBB or CCC but not something else from AAA instead of Dried Fish. SO the most important thing should come first and that is DF followed by the quantity.

Hi Aditya,

 

I know you as one of the most active contributors on the forum.

 

Well I have uploaded my final files yesterday, after having “played” with ERPNext for more than a month.

 

Let me point out that I have no accounting or business background, what makes things a bit more complex (I’m a hydrogeologist/water management person).

 

Since we use the system basically as a POS system quick data entry is paramount. We have no personnel and it is a from our home business.

 

I finally opted for the following system : aabb1, aabb2, where aa is a short for the supplier and bb the “material” (fish, beef, chicken, deer, and all the other nice things we Westerns feed our dogsJ .  and than a sequential number. This I have mixed with categories describing “frozen”, “dried”, supplement and other characteristics.

 

Umair has finalized setting up tax, delivery and discount functionality about an hour ago. Yet, the “acid test” in the real world. Anyway, I do like the direct contact with the guys in Delhi, and hope erpnext will become more widespread.

 

Well your business seems to be a lot more complex than ours, so if erpnext can do the job for you, it should be able to the same for us. However, I have read yr contributions and it seems to me that you rin erpnext on yr own server and are an expert in Python programming allowing to fine tune things yourself.

 

Regards Robert

 

 

 

From: Aditya Duggal [mailto:ad...@rigpl.com]
Sent: Wednesday, February 15, 2012 2:27 PM
To: er...@googlegroups.com
Cc: Robert Becht
Subject: Re: item codification

 

Hi Robert,

 

I have been looking at your discussion with Rushabh, I would like to point out one most important thing that item codification can is the most critical part in setting up of a good system.

 

Now I had a similar problem in my company where we are manufacturing cutting tools now I would like to share my item code which we have devised over the years and I hope I am following the best practices. Even this system of codification is not sufficient to cater to the vast items we manufacture but it does take care of the 80% of the things and the other 20% which are MADE to order are all tracked by one item code. Let me explain my scenario:

 

We are manufacturing cutting tools of HIGH SPEED STEEL & CARBIDE which are SQUARE, RECTANGULAR, ROUND in shapes to name a few. There are all in all 6000 item codes currently running on ERPNEXT.

 

I have the item codes like this:

 

H     RE      0250       1905     0200  -     0        1       0

 

  1.  H= The base material of the tools which is H in case of HSS and C in case of CARBIDE
  2. RE= Denotes the type of tool, so for SQUARE it is SQ, RECTANGULAR = RE, ROUND= RD, ENDMILL =SE, Ball Nose Endmill = BE, Drill = DR
  3. 0250 = Denotes the first dimension of the tool and is denoted by millimeters so 0250=2.50mm, 1000=10mm, 9999=99.99mm since we don't manufacture anything above 25mm and max is 80mm we have gone to therefore we are using only 4 digits
  4. 1905 is the same as item 3, but in case of SQ where 3=4 we are not using the 4th part so HSQ09530200-010 is the item code for HSS SQUARE 9.53mm x 9.53mm x 200mm
  5. The DASH is actually a redundant character in our system as of now.
  6. 0 = Denotes the number of Flutes (I know I am getting technical, but I am just giving example of my company)
  7. 1= This actually denotes the quality of tools since we have different kind of qualities in 2 major materials
  8. And the last 0 is for denoting some kind of special treatment and each letter has a meaning like 0=No Special Treatment, 1=TiAlN Coating, 2=TiN Coating, 3=ACX Coating....and so on.

 

I hope this helps, as for the suggestion by Rushabh for your codification is great according to me. Suppose you have item codes as per the supplier

 

> AAA   dried fish 100g
> BBB dried fish 100g
> CCC dried fish 5 kg
> CCC_250g dried fish 250g 

 

Now if you enter the system with AAA it would list all the items from AAA supplier but whereas you should have a system where you can give your customer a choice between brands therefore

 

 

DF-250-AAA
DF-250-BBB
DF-5000-CCC
DF-250-CCC 

 

is a much better option than the one mentioned by you earlier. Lets face it a customer comes to buy Dried Fish, so he/she can take AAA or BBB or CCC but not something else from AAA instead of Dried Fish. SO the most important thing should come first and that is DF followed by the quantity.

 



Faculty of Geo-Information Science and Earth Observation (ITC)
University of Twente
Chamber of Commerce: 501305360000

E-mail disclaimer
The information in this e-mail, including any attachments, is intended for the addressee only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the content of this information is strictly prohibited. If you have received this e-mail by mistake, please delete the message and any attachment and inform the sender by return e-mail. ITC accepts no liability for any error or omission in the message content or for damage of any kind that may arise as a result of e-mail transmission.

Hi Robert,


First of all let me thank you for all the great words that I am not used to and don’t deserve, since all the kudos should go to the developers who are developing this product.

I would also like to inform you that I have no knowledge of the python language or for that matter any programming language and I am using the system as SAS on the erpnext servers as hosting on my own server is going to be a big job for me.

I would like to mention here that I have been working on this system since Oct-2010 and have been playing with this system myself to see what things do and how they react to my changes and if you take my word for it then it is extremely easy to modify the system and I don’t know if Rushabh agrees but I think people should be encourage to play around with the system to know the system from within, and take my word for it that you don’t need to be a programmer for this.
Hi Aditya,

Thanks for the kind words :)

The project started more as a hobby / fun thing rather than a focussed approach to build a product --- which is only recent, hence I think its a lot more "hackable".... Also the Open Source factor (though we never get any credit for that!)

But yes, there a lot of settings users can play with - like DocTypes but we also need to be careful. Documentation is a bit todo now and will also help users uncover the hundreds of subtle settings!

best,
Rushabh



---------------------------------------------------------
ERPNext - World's most affordable ERP.

W: https://erpnext.com
T: @rushabh_mehta

On 15-Feb-2012, at 9:00 PM, Aditya Duggal wrote:

Hi Robert,

First of all let me thank you for all the great words that I am not used to and don't deserve, since all the kudos should go to the developers who are developing this product.

I would also like to inform you that I have no knowledge of the python language or for that matter any programming language and I am using the system as SAS on the erpnext servers as hosting on my own server is going to be a big job for me.

I would like to mention here that I have been working on this system since Oct-2010 and have been playing with this system myself to see what things do and how they react to my changes and if you take my word for it then it is extremely easy to modify the system and I don't know if Rushabh agrees but I think people should be encourage to play around with the system to know the system from within, and take my word for it that you don't need to be a programmer for this.