Hi,
I have an urgent problem here... ](*,)
My customer gave me such request:
When someone input an purchase order into system, he/she will give system a signal that who have to approve this document.
So, it means, there should be some rule for system to judge who will this document be sent to ; the purchase order can be approved ; the purchase order can be approved by divided person.
We know that we can decide if a journal name should be approved in General Ledger, but how can we do the same thing in AP or AR?
I have another idea of using the purchase journal function which means the first person can only have the right to use "Purchase Journal", and the approvers can use the "purchase Order", but the question is how to define the approve route?
any suggestion can be useful, thank you all...
Speaker wang
0
Comments
I think you can solve with a little customization. Add 2 fields on purchase order caled Approved/Approved by, and a function in Functions called Approving, and only allow it to be available for Approvers (I guess u can cover this with the security keys on Menu items). Then make a small update in code so only the approved orders to be allowed to be posted (like disabling posting buttons on the Active() method of the datasource).
Hope this helps,
Ciprian
Ciprian Dudau
Axapta Developer
I've received the two replies. Thank you very much. It seems feasible. But I still have some doubt, Axapta don't provide such functions so that we have to do customization here and there, should it be a risk to the time and workload in project?
Will you solve such problems by customization in normal? And will you charge fee from your customer ?
Best Regards,
Speaker Wang
I'm not sure I understand. Are you thinking that customizing like that can be a problem for your implementation? Axapta is especially designed to support large amount of customizations, so I don't see what you have to lose; as long as the data is saved and posted correctly (the integration with standard Axapta is correct) there is a good idea to involve in customizations and to make the environment more appropriate to your business.
Yes, these are common customization requirements. Our fee's are at a hourly rate. However, if you are interested in a colaboration, please provide your email address and I will send you a solution for this issue free of charge .
With regards,
Ciprian Dudau
Axapta Developer
Ciprian Dudau
Axapta Developer
It seems that I didn't make me clear enough.
It's my first case of axapta, and I implement other ERP system before. In those cases, we always run away from customization. So, you see, I always get into such questions when I got a request extend from the standard function:
1. If I agree too much customization, maybe my customer will apply for more and more request. Can I keep my time in schedule?
2. If we do too much customization here and there, maybe some logical error will crash the system's logic.
3. If my customer have will to pay for all these customization:)
I always met such problems in my cases before, some reason is those systems are hard to be changed. And for my axapta, maybe I should change my thinking.
Thank you very much for your kindness.
Best Regards,
Speaker Wang
I understand your position. Yes, more customization can slow down the implementation process, is correct. However, it has the great advantage of considerable improving the system by making it more appropriate to the client's specific needs.
This is usually called "verticalization" of the implementation. Axapta, Navision and other ERP's like them, althogh they are providing standard modules with plenty of functionality, usable as a base for most of business areas, they also offer efficient tools for upgrading the base package to the "vertical" activity of customer (this is the specific business domain, like retail, construction, cuisine, farmaceutic, medical, real estates etc.).
I think this is something you need to think from the beginning and balance the benefits/weak points of customizing. The customer need to be informed and agreed from the start upon the time frame of the implementation, w/ customizations.
Only if the customization is done unprofessionally .
Axapta has very flexible base logic that allows end users to make customizations easily, without damaging existing features. Also, when dealing with customization, u need to set a paralel TEST instance who will be used to test functionality for any new piece of code before importing it into the LIVE instance.
You are the MS Partner doing the implementation. You will decide about programming/consultancy fee's that you will charge the customer for the time spent with these processes.
With regards,
Ciprian Dudau
Axapta Developer
Ciprian Dudau
Axapta Developer
Your answer gave me a large help. And I now know what should I do when request coming.
To know if the system can take it is the most important ](*,)
then we can analyse the cost with customer. [-(
It's hard to make sure if some request can be deal with system function or should be take by customization...
Thank you anyway. I have clear idea now.
Best Regards,
Speaker Wang