Русская версия статьи находится здесь: «Снова о разных подходах к внедрению iScala»
Over the past months I have been able to “be impressed” with the customization of iScala among several clients. Of course, I will be «silent like a fish» with respect to their names, but I can not help but say about my impressions. I saw some great external applications that fully automate the sales process instead of the standard functionality of the iScala Sales Orders module. Everything is designed taking into account the wishes of users, with a good distribution of duties, very impressive! Also saw the «external» program of interaction with the bank client. Great work, significantly reduces the routine work. The program even understands when a client writes “payment of bills 100234, 235, 240-242” in the payment assignment, spreading payment on bills 100234, 100235, 100240, 100241, 100242. Really makes an impression!
But I was even more impressed that everything described above writes «directly» to the iScala tables! This is a method that I have always been against and continue to be against. I will not describe what this is fraught with and what consequences users of these applications sometimes encounter, I have no desire to discuss something specific or, God forbid, to criticize my colleagues who developed it, I only criticize the approach.
Of course, it is much easier to do what the client asks, than to convince him that writing directly to the database is dangerous, it is an attempt to rewrite the standard iScala functionality and this can make it impossible to migrate to the new version of the system in the future, and if you change the settings inside iScala, applications may not take this into account and there will be a discrepancy in their work and that of iScala. I prefer to implement the «external» functionality in such a way as to prepare the data for iScala, and then insert it there in some correct way, for example, using a standard import or using the Epicor Service Connect mechanism.
Helping clients to switch to the new VAT rate in 2019, I ran into one place with the system modifications by Epicor consultant dated year 2008.
This is also impressive! Almost 10 thousand lines of code — stored procedures are called from a snap search and write information in the tables of VAT, invoice journal, payment journal, day book journal…
And for what all this? I did not understand the sacred meaning of all this. Even if we recognize that we need to create additional lines of transactions when printing journals, and automatic allocations does not work or are not convenient, and periodic allocations cannot be used for some reasons either, it is absolutely clear that it was possible to prepare data for import and import additional lines of transactions using standard way without all these terrible stored procedures.
The thing is, in my opinion, that at one time, Epicorus took a person to the position of director of consulting, who sold consulting very well, but did not understand anything at iScala and lost control over what his subordinates were doing by implementing iScala. I already wrote earlier that the less experience a consultant has, the more he is inclined to use some kind of “external” procedure instead of doing everything by standard means. Here, for example, at the same client, where I ran into 10 thousand lines of code, I discover that the field «Supplier Code» has been renamed to «VAT Code» in the customer record and is used in the stored procedure. The thing is that the field «VAT code» in the customer record is available only when the corresponding parameter is enabled in the company settings:
The consultant apparently did not know this and did not find anything better than to use another field for these purposes.
After some time (in 2009), the consulting director left the company, and the curse of such «decisions» remained.
And why am I writing this? Probably, my diploma in management does not allow me to pass by this calmly 🙂 🙂 🙂
