|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
У меня необычный вопрос. Я уже 12 лет не занимаюсь программированием, но "есть IT background". Волею судеб столкнулся с внедрением ERP Infor на производственном предприятии (БД - Oracle), и недавно дошли руки посмотреть код, которым это все реализовано. Просто приведу несколько примеров того, что у меня вызывает удивление: - процедуры построения отчетов не используют возможности sql (типа join). Вместо этого есть код, который вытаскивает из базы селекты, а потом в цикле обрабатывает их, каждый раз вызывая новые запросы. - отчет генерируется в файл excel (типа xlsx, xml представление). Но! Нет общей функции выгрузки в файл, в каждой функции своя реализация, все xml тэги перемешиваются с данными прямо в коде. - везде в коде - сокращения, нечитаемые названия переменных и полей таблиц - есть "магические числа" - просто стоят в коде, не объявляются как константы - в самой базе oracle - только таблицы, вьюшки вообще не используются - ну и в результате отчеты генерятая часами, потом пользователи дообрабатывают их в экселе (если удается открыть файл) Я понимаю, что я много пропустил в индустрии, есть application server, где вся бизнес логика крутится. Но так что, действительно принято писать теперь код? Или я немного прав, и проект делали низкопоофессиональные консультанты? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2013, 02:44 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
dabinoЯ понимаю, что я много пропустил в индустрии, есть application server, где вся бизнес логика крутится. Но так что, действительно принято писать теперь код? Или я немного прав, и проект делали низкопоофессиональные консультанты? Вам нужно в раздел "Программированиие", здесь все же вопросы кодирования не сильно обсуждаются. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2013, 10:53 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
dabinoНо так что, действительно принято писать теперь код? ? код коду рознь, для ERP описанная ситуация типична, от 1С до SAP ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2013, 16:37 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
dabino- ну и в результате отчеты генерятая часами, потом пользователи дообрабатывают их в экселе (если удается открыть файл) За такое в нормальной компании - увольнение.... ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2013, 07:42 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
foxwizarddabino- ну и в результате отчеты генерятая часами, потом пользователи дообрабатывают их в экселе (если удается открыть файл) За такое в нормальной компании - увольнение.... за откаты в нормальной компании - тем более увольнение. какой процент договоров на внедрение заключается без откатов? или, другими словами - какой процент нормальных компаний? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2013, 11:56 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
s_ustinov за откаты в нормальной компании - тем более увольнение. какой процент договоров на внедрение заключается без откатов? или, другими словами - какой процент нормальных компаний? процентов 10-15 ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2013, 13:30 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
Shuhards_ustinov за откаты в нормальной компании - тем более увольнение. какой процент договоров на внедрение заключается без откатов? или, другими словами - какой процент нормальных компаний? процентов 10-15 отож хотя я наверно больше верю в людей и обычно называю цифру "до 20%" учитывая, что "нормальных" клиентов максимум один из пяти - о каком качестве (продуктов, консультантов, результатов проектов в целом) можно говорить? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2013, 13:45 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
foxwizarddabino- ну и в результате отчеты генерятая часами, потом пользователи дообрабатывают их в экселе (если удается открыть файл) За такое в нормальной компании - увольнение.... По некоторым пунктам нормальность компании ваще не при чем. Скажем так - по основным пунктам. Например, использование констант в коде на скорость не влияет, так же как и нечитаемость имен. А все остальное - в основном проблемы архитектуры и языковых средств, реализованных в ERP. Вообще (это моя точка зрения), ERP возникли как средство автоматизации бизнеса. Но очень скоро до производителей дошло, что одними настройками (галочками в формах) не обойтись, стали придумывать свои языки. Я даже не говорю про уровень языков и сред программирования... с содроганием вспоминаю C-AL(интересно, с 4-й версии что-нибудь в лучшу сторону поменялось?). Проблема в том, что этит языки она делали на своем уровне, вне СУБД. Ну и возникло деление по уровням. которое преподносится как типа круто (и местами оно может так и есть, например, говорят, что, вроде, масштабировать легче). Но КМК это ведет в тем проблемам, про которые тут написано, и проблем больше чем преимуществ. Очень много маркетинга. Одной конторе втюхали тот же нафижн со словами, что де отчеты в Excel так же просто выводить, как в Access'e, и ваще - это тот же ассесс адаптированый под бизнес . А по факту , для каждого отчета надо отдельный выводить в Excel прописывать со всеми навижнскими танцами. Но даже если бы Навик был бы так же удобен как среда VBA , то от принципиальных проблем, связанных с разделением по уровням, это не избавит. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2013, 19:51 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
ТС говорит про "Infor" и "Производственное предприятие", следовательно это Infor LN. Я бы посоветовал прочитать про BAAN и его историю. Описываемые ТС проблемы характерны для БД-независимых учетных систем. Возможно, со временем остался только Oracle, как в том же NAV / DAX - только MS SQL. С Уважением, Георгий ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2013, 09:38 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
Описываемые ТС проблемы характерны для БД-независимых учетных систем. Возможно, со временем остался только Oracle, как в том же NAV / DAX - только MS SQL .Увы, это не решает сабжевых проблем, т.к. все равно подход остается навигационным (ставим фильтр, считываем запись, перебираем до конца + куча вычислений и навигаций). Проблема отчасти решится, когда вычисления будут только на сервере и только на родном SQL и на оптимальной структуре таблиц/полей. :) Удивление ТСа непонятно. Для него это открытие ? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2013, 11:46 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
LSVПроблема отчасти решится, когда вычисления будут только на сервере и только на родном SQL и на оптимальной структуре таблиц/полей. :)Welcome to OEBS :) LSVУдивление ТСа непонятно. Для него это открытие ? :)Видимо да... не каждый день разработчики сталкиваются с ERP-системами, да еще родом из 80х годов. С Уважением, Георгий ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2013, 11:59 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
George NordicВидимо да... не каждый день разработчики сталкиваются с ERP-системами, да еще родом из 80х годов. А что-то сейчас принципиально изменилось в мире ERP ? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2013, 15:07 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
IgorKGeorge NordicВидимо да... не каждый день разработчики сталкиваются с ERP-системами, да еще родом из 80х годов. А что-то сейчас принципиально изменилось в мире ERP ? Не особо, просто у "свежих" систем меньше унаследованного кода. И кстати, sql относительно редко используют скорее всего в силу низкого уровня внедренцев (консультантов и программистов) и заказчиков - мало кто может нормально разобраться в sql коде, не говоря уже о доработке. С процедурными языками людям почему-то проще. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2013, 15:24 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
Всем большое спасибо за комментарии и мнения (которые разделились). из свежих приколов: при построении отчета от пользователя требуется указать, сколько же дней в этом феврале - 28 или 29... ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 11:57 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
dabinoВсем большое спасибо за комментарии и мнения (которые разделились). из свежих приколов: при построении отчета от пользователя требуется указать, сколько же дней в этом феврале - 28 или 29... Это никакой архитектурой не исправишь :). Помню "квалифицированных" нави-разработчиков, которые никак алгоритм разнесения таможенных платежей по товарным позициям отладить не могли. В конце концов они решили отделаться от меня, нарисовав красивое "итого" по целой поставке, тупо изменив стоимость последней строки на расхождение. Это видно было прямо по цифирькам. Ничего не поменялось, а последняя строка вдруг на рупь-сорок-три меньше и всё (о-чудо!) сходится. Стимулировал (в связи с длительностью и многочисленностью косяков) матом. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 13:46 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
dabinoВсем большое спасибо за комментарии и мнения (которые разделились). из свежих приколов: при построении отчета от пользователя требуется указать, сколько же дней в этом феврале - 28 или 29... зачет... ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 14:08 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
IzyaПомню "квалифицированных" нави-разработчиков, которые никак алгоритм разнесения таможенных платежей по товарным позициям отладить не могли. В конце концов они решили отделаться от меня, нарисовав красивое "итого" по целой поставке, тупо изменив стоимость последней строки на расхождение. Это видно было прямо по цифирькам. Ничего не поменялось, а последняя строка вдруг на рупь-сорок-три меньше и всё (о-чудо!) сходится. Стимулировал (в связи с длительностью и многочисленностью косяков) матом. это стандартная ситуация, когда требуют поделить неделимое, нави-разработчики здесь не причем. Посмотрите в других программах, найдете тоже самое, чтобы далеко не ходить в 1С можете покопаться. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 14:14 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
dabinoиз свежих приколов: при построении отчета от пользователя требуется указать, сколько же дней в этом феврале - 28 или 29... представляю какое замешательство вызовет у вас вопрос "количество периодов в году?" ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 14:19 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
IzyaПомню "квалифицированных" нави-разработчиков, которые никак алгоритм разнесения таможенных платежей по товарным позициям отладить не могли. В конце концов они решили отделаться от меня, нарисовав красивое "итого" по целой поставке, тупо изменив стоимость последней строки на расхождение. Это видно было прямо по цифирькам. Ничего не поменялось, а последняя строка вдруг на рупь-сорок-три меньше и всё (о-чудо!) сходится. Стимулировал (в связи с длительностью и многочисленностью косяков) матом. а там точно дело не в округлении было? или не в "приблизительном" алгоритме? у вас получалось правильно автоматически распределить издержки по позициям - пропорционально сумме (есть такой стандартный функционал в распределении товарных издержек)? если нет, то проблема почти наверняка не в разработчиках. а то обвинять легко... ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 14:55 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
IzyaПомню "квалифицированных" нави-разработчиков, которые никак алгоритм разнесения таможенных платежей по товарным позициям отладить не могли. В конце концов они решили отделаться от меня, нарисовав красивое "итого" по целой поставке, тупо изменив стоимость последней строки на расхождение. Это видно было прямо по цифирькам. Ничего не поменялось, а последняя строка вдруг на рупь-сорок-три меньше и всё (о-чудо!) сходится. Стимулировал (в связи с длительностью и многочисленностью косяков) матом. расхождение относить все равно куда-то относить надо... или на последнюю строку или на самую большую. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 16:12 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
instantIzya... это стандартная ситуация, когда требуют поделить неделимое, нави-разработчики здесь не причем. Посмотрите в других программах, найдете тоже самое, чтобы далеко не ходить в 1С можете покопаться. Ви доктор, что ви меня лечить хотите? На 10-15 тестовых позициях - "рупь-сорок-три" погрешность алгоритма, который доли посчитать должен? Ага-ага. Это исключительно кривые руки, хотя бы потому, что в описываемом случае, после правок алгоритма эти "рупь-сорок-три" (и другие тесты) таки были правильно распределены. Насчет 1С не знаю, но,после сказанного, боюсь его еще больше. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 16:21 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
Последний выдох ГПЖрасхождение относить все равно куда-то относить надо... или на последнюю строку или на самую большую. ребят, вы что, с ума посходили? 1) Сумма расхождения в копейках при долевом распределении не может быть больше чем половина количества строк (при правильном подходе). Это в наихудшем случае, когда все округлении пошли в одну сторону. Когда на 10-15 строк мне говорят "рупь-сорок-три", я начинаю нервничать. 2) Это расхождение можно раскидать по копейке на каждую строку, начиная с максимально распределенных сумм. А что, у вас иначе? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 16:31 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
s_ustinovIzya... у вас получалось правильно автоматически распределить издержки по позициям - пропорционально сумме (есть такой стандартный функционал в распределении товарных издержек)? если нет, то проблема почти наверняка не в разработчиках. а то обвинять легко... Я деталей не помню - это было лет 8 назад. Функционал нестандартный, связан с алкоголем. Алгоритм был копеечный. Доля по позиции= нормированные(Кол-во* объем штуки*процент алкоголя). Дальше по этим долям раскидываем по позиции сумму. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 16:37 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
IzyaЭто в наихудшем случае, когда все округлении пошли в одну сторону. Когда на 10-15 строк мне говорят "рупь-сорок-три", я начинаю нервничать как-т многовато... бухи любят считать ндс от "итого"и вопить что не сходится с документом. приходится объяснять что оно никогда не сойдется в общем случае, т.к. считается построчно ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 16:44 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
s_ustinovIzya... у вас получалось правильно автоматически распределить издержки по позициям - пропорционально сумме (есть такой стандартный функционал в распределении товарных издержек)? если нет, то проблема почти наверняка не в разработчиках. а то обвинять легко... Я деталей не помню - это было лет 8 назад. Функционал нестандартный, связан с алкоголем. Алгоритм был копеечный. Доля по позиции= нормированные(Кол-во* объем штуки*процент алкоголя). Дальше по этим долям раскидываем по позиции сумму. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 16:44 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
Последний выдох ГПЖ как-т многовато... бухи любят считать ндс от "итого"и вопить что не сходится с документом. приходится объяснять что оно никогда не сойдется в общем случае, т.к. считается построчно[/quot] Ну а я о чём! Мне с бухами везло - всегда построчно. Точнее, были стычки с бухами контрагентов, но я их за разъяснениями к своим отправлял. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 16:48 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
IzyaПоследний выдох ГПЖ как-т многовато... бухи любят считать ндс от "итого"и вопить что не сходится с документом. приходится объяснять что оно никогда не сойдется в общем случае, т.к. считается построчно Ну а я о чём! Мне с бухами везло - всегда построчно. Точнее, были стычки с бухами контрагентов, но я их за разъяснениями к своим отправлял.[/quot] но распределение суммы по некому массиву строк насколько я помню реализованно в типовых 1с как я писал - вычисляются коэффициент для каждой строки, потом они складываются. если есть разница т.е. исходная сумма <> сумме (строка * на свой коэффициент) то расхождение относится она строку с макс. коэффициентом - чтобы не "смазывать" распределение по другим более мелким суммам ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 16:53 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
IzyaЯ деталей не помню - это было лет 8 назад. Функционал нестандартный, связан с алкоголем. Алгоритм был копеечный. Доля по позиции= нормированные(Кол-во* объем штуки*процент алкоголя). Дальше по этим долям раскидываем по позиции сумму. мучают меня подозрения. сталкивался я с подобными расчетами... и есть у меня подозрение, что если на калькуляторе рассчитать суммы по каждой строке по этой формуле, а потом сложить все суммы - правильный итог не получится... хотя может программисты считали неправильно - такое тоже бывает. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 17:00 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
Последний выдох ГПЖно распределение суммы по некому массиву строк насколько я помню реализованно в типовых 1с как я писал - вычисляются коэффициент для каждой строки, потом они складываются. если есть разница т.е. исходная сумма <> сумме (строка * на свой коэффициент) то расхождение относится она строку с макс. коэффициентом - чтобы не "смазывать" распределение по другим более мелким суммам По уму, расхождение надо тоже разбросать по копеечке по самым крупным суммам. Прикидывая, как работает 1С, живо представляю. как они в переменной хранят максимально найденное значение, потом его находят и в эту строку прописывают расхождение. Просто потому, что так тоже просто. КМК второй раз распределение организовать - это выше сил, конечно. Но это мое сугубое мнения. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 17:07 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
s_ustinov. и есть у меня подозрение, что если на калькуляторе рассчитать суммы по каждой строке по этой формуле, а потом сложить все суммы - правильный итог не получится... хотя может программисты считали неправильно - такое тоже бывает. Дык! я ж сказал - на 15 строк в пределах (+-)7 копеек. Но не рупь-сорок-три. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 17:10 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
Да чё там, про криворукость говорить....мне надысь попалось на глаза мнение лидера немаленького, раскрученного облачного сервиса, связанного с логистикой, что себестоимость по FIFO невозможно посчитать, используя SQL, нужен ява. Что бы был понятен масштаб бедствия - речь идет о навороченном диалекте, типа TSQL или PLSQL. Так что в вопросе ТС между "так теперь принято кодить" и "лажей" надо часто знак равенства ставить. Это всё было КМК :) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 17:20 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
IzyaДа чё там, про криворукость говорить....мне надысь попалось на глаза мнение лидера немаленького, раскрученного облачного сервиса, связанного с логистикой, что себестоимость по FIFO невозможно посчитать, используя SQL, нужен ява. Что бы был понятен масштаб бедствия - речь идет о навороченном диалекте, типа TSQL или PLSQL. Так что в вопросе ТС между "так теперь принято кодить" и "лажей" надо часто знак равенства ставить. Это всё было КМК :) я не очень понимаю, почему, но много раз наблюдал ситуацию, что процедурные языки намного лучше усваиваются (понимаются) большинством людей. может дело в базовом образовании (хотя я сам по образованию экономист, а у меня проблем таких нет), может в неких способностях... а проблема ламеров (не разбираются, но считают себя экспертами) - это вообще всеобщая проблема, не специфичная для ИТ так что подобные ситуации меня совсем не удивляют... ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 17:32 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
Izyas_ustinov. и есть у меня подозрение, что если на калькуляторе рассчитать суммы по каждой строке по этой формуле, а потом сложить все суммы - правильный итог не получится... хотя может программисты считали неправильно - такое тоже бывает. Дык! я ж сказал - на 15 строк в пределах (+-)7 копеек. Но не рупь-сорок-три. там может быть не только проблема округления для расчета итоговой цифры могли использовать немного не те данные или не такую формулу - и в результате итог не сходится с суммой по строкам. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 17:35 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
>может дело в базовом образовании (хотя я сам по образованию экономист, а у меня проблем таких нет) имхо это просто что-то с мозгами... ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 17:35 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
Izyainstantпропущено... это стандартная ситуация, когда требуют поделить неделимое, нави-разработчики здесь не причем. Посмотрите в других программах, найдете тоже самое, чтобы далеко не ходить в 1С можете покопаться. Ви доктор, что ви меня лечить хотите? где я тебя лечу и нафиг ты мне вообще сдался? Давай, до свидания, если сказать по теме нечего ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 18:02 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
Izya, Чаще всего с ошибками округления дело обстоит именно так как Вы говорите, но не всегда. В общем случае величина ошибки определяется не только последней значимой цифрой, но и методикой расчета. Если Вы пытаетесь получить через опорную малую долю общей суммы (к примеру, являющейся 1% от общей суммы) саму общую сумму, то ошибка округления доли до последней значащей цифры может увеличиться на коэффициент, равный соотношению общей суммы и этой самой доли, то есть, при доле =1% - в 100 раз! Соответственно, на 10-15 позициях может набежать ошибка округления , не только "рупь-сорок-три", но и значительно больше. Подобные ошибки могут возникать при попытке расчета налоговой базы через сумму налога, которая считается заданной. Или при попытке рассчитать сумму выручки через заданную маржу при невысокой рентабельности. И при других аналогичных ситуациях. В двух словах, если ошибка округления возникает ДО умножения на некий коэффициент, и при этом коэффициент весьма значительный (десятки-сотни), то ошибка округления до копейки запросто может вырасти до рублей - даже в одной позиции. Просто посмотрите внимательно на формулу [Ошибка округления до копейки]*К=? Представьте, что K=100 или 1000. Я сталкивался на практике с ситуацией, когда считалась заданной цена без НДС, а цена с НДС получалась расчетным путем с ошибками округления. Затем полеченная уже с ошибкой округления цена умножалась на количество . А количество вполне могло достигать нескольких тысяч. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 19:54 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
GaryaВ двух словах, если ошибка округления возникает ДО умножения на некий коэффициент, и при этом коэффициент весьма значительный (десятки-сотни), то ошибка округления до копейки запросто может вырасти до рублей - даже в одной позиции. Просто посмотрите внимательно на формулу [Ошибка округления до копейки]*К=? Представьте, что K=100 или 1000. Я сталкивался на практике с ситуацией, когда считалась заданной цена без НДС, а цена с НДС получалась расчетным путем с ошибками округления. Затем полеченная уже с ошибкой округления цена умножалась на количество . А количество вполне могло достигать нескольких тысяч. +1 я про это и говорил, но сам не понимал, что это тоже ошибка округления есть сумма инвойса в евро надо пересчитать в рубли (гривны) если берем общую сумму и умножаем на курс - одна цифра. если для каждой позиции рассчитываем цену в рублях с точностью до копейки (цена в евро умножить на курс), потом умножаем цену на количество, и все суммируем - получаем сильно другую цифру. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 21:38 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
GaryaIzya, Чаще всего с ошибками округления дело обстоит именно так как Вы говорите, но не всегда. В общем случае величина ошибки определяется не только последней значимой цифрой, но и методикой расчета. Если Вы пытаетесь получить через опорную малую долю общей суммы (к примеру, являющейся 1% от общей суммы) саму общую сумму, то ошибка округления доли до последней значащей цифры может увеличиться на коэффициент, равный соотношению общей суммы и этой самой доли, то есть, при доле =1% - в 100 раз! Соответственно, на 10-15 позициях может набежать ошибка округления , не только "рупь-сорок-три", но и значительно больше. Подобные ошибки могут возникать при попытке расчета налоговой базы через сумму налога, которая считается заданной. Или при попытке рассчитать сумму выручки через заданную маржу при невысокой рентабельности. И при других аналогичных ситуациях. В двух словах, если ошибка округления возникает ДО умножения на некий коэффициент, и при этом коэффициент весьма значительный (десятки-сотни), то ошибка округления до копейки запросто может вырасти до рублей - даже в одной позиции. Просто посмотрите внимательно на формулу [Ошибка округления до копейки]*К=? Представьте, что K=100 или 1000. Я сталкивался на практике с ситуацией, когда считалась заданной цена без НДС, а цена с НДС получалась расчетным путем с ошибками округления. Затем полеченная уже с ошибкой округления цена умножалась на количество . А количество вполне могло достигать нескольких тысяч. да... помню методики расчета стоимости лекарственных средств при разукомплектации пачка -> блистер и обратно... чтобы все сходилось + цена укладывалась например в ограничения наценок на жизненноважные + ндс + налог с продаж и прочее... жесть была ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2013, 10:14 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
s_ustinovесли берем общую сумму и умножаем на курс - одна цифра. если для каждой позиции рассчитываем цену в рублях с точностью до копейки (цена в евро умножить на курс), потом умножаем цену на количество, и все суммируем - получаем сильно другую цифру.Так и есть. Но верным является второй способ. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2013, 11:15 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
LSVs_ustinovесли берем общую сумму и умножаем на курс - одна цифра. если для каждой позиции рассчитываем цену в рублях с точностью до копейки (цена в евро умножить на курс), потом умножаем цену на количество, и все суммируем - получаем сильно другую цифру.Так и есть. Но верным является второй способ. какой способ более правильный - вопрос философский. проблема в том, что расчет по разным алгоритмам дает существенно разный результат. и если требовать все рассчитывать вторым способом, а для проверки результата использовать первый способ - то тут проблема не в разработчиках навика... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2013, 12:59 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
здесь проблема в том, как уже говорилось, что требуется делить неделимое. Пример с таблетками был хороший. И т.п. Поставщик, определяя цену на свой товар, не предполагает, что им будут торговать в рознице в количестве 1/3 и т.п. от оригинальной упаковки. Если бы он предполагал такое, то не назначал цену на упаковку с тремя блистерами внутри 10 руб, а считал бы цену упаковки от цены одного блистера. Ошибки округления в таких ситуациях всегда являются риском. Причем, алгоритм подходящий для одной ситуации, может давать ощутимые погрешности в другой. Конечно можно реализовать такую математику что все будет с точностью до копейки. Здесь вопрос только в том, что для учета потерь в 100руб будет разработана система стоимостью в 10000руб. Вместо того, чтобы эти несчастные 100руб скинуть на последнюю строку в списке и забыть о них. p.s. вспомнился аудит C&L в восьмидесятые годы в одной компании... 10000$ при многомилионном обороте относили на "незначительные отклонения". А здесь речь идет об одном рубле. Оборот два рубля что-ли? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2013, 13:36 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
instantp.s. вспомнился аудит C&L в восьмидесятые годы в одной компании... 10000$ при многомилионном обороте относили на "незначительные отклонения". А здесь речь идет об одном рубле. Оборот два рубля что-ли? мне рассказывали реальный случай, как примерно миллион баксов на ошибки пересчета списали при аудите... отчетность в долларах, а учет в гривнах, а в конце 2008 курс как раз хорошо скаканул... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2013, 13:49 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
или, к примеру, распределение таможенных платежей пропорционально объемам контейнеров или весу в зависимости от типа перевозки и еще множества параметров, вместо простого распределения относительно стоимости... Давало разницу в несколько долларов на товаре стоимостью в сотню тысяч долларов, но при этом затраты на учет в тысячу долларов. Здесь как у хакеров: если выгода будет на порядки меньше затрат на взлом, то кому этот взлом нужен. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2013, 14:06 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
instantОшибки округления в таких ситуациях всегда являются риском. Причем, алгоритм подходящий для одной ситуации, может давать ощутимые погрешности в другой. п.э. у нас ценообразование было вынесено в отдельный "модуль" параметрический и настраиваемый... С готовыми пресетами настроек для "популярных" аптечных сетей. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2013, 15:57 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
Последний выдох ГПЖ... бухи любят считать ндс от "итого"и вопить что не сходится с документом. приходится объяснять что оно никогда не сойдется в общем случае, т.к. считается построчно Кстати, вы уверены, что считать НДС от "итого" - неправильно? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2013, 16:27 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
andr_andreyПоследний выдох ГПЖ... бухи любят считать ндс от "итого"и вопить что не сходится с документом. приходится объяснять что оно никогда не сойдется в общем случае, т.к. считается построчно Кстати, вы уверены, что считать НДС от "итого" - неправильно? есть форма с/ф в ней есть построчный учет суммы НДС (разные ставки по товарам тоже привет передают). То что бух берет итоговую сумму и начинает делать X*18/118 (что вообще возможно только для авансов) и вопить -"OMG, не сходицо!" - это его проблемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2013, 18:24 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
Последний выдох ГПЖandr_andreyпропущено... Кстати, вы уверены, что считать НДС от "итого" - неправильно? есть форма с/ф в ней есть построчный учет суммы НДС (разные ставки по товарам тоже привет передают). То что бух берет итоговую сумму и начинает делать X*18/118 (что вообще возможно только для авансов) и вопить -"OMG, не сходицо!" - это его проблемы. сейчас может поменяли, но раньше в Украине было правило, что сумма НДС по налоговой должна быть равна общая сумма без НДС * 20% то есть расчет надо было делать не по строке, а по документу в целом, и потом подгонять суммы в строках... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2013, 18:34 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
s_ustinovПоследний выдох ГПЖпропущено... есть форма с/ф в ней есть построчный учет суммы НДС (разные ставки по товарам тоже привет передают). То что бух берет итоговую сумму и начинает делать X*18/118 (что вообще возможно только для авансов) и вопить -"OMG, не сходицо!" - это его проблемы. сейчас может поменяли, но раньше в Украине было правило, что сумма НДС по налоговой должна быть равна общая сумма без НДС * 20% то есть расчет надо было делать не по строке, а по документу в целом, и потом подгонять суммы в строках... вы подрываете мою веру в более осмысленный подход к учету в других странах... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2013, 18:42 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
Последний выдох ГПЖs_ustinovпропущено... сейчас может поменяли, но раньше в Украине было правило, что сумма НДС по налоговой должна быть равна общая сумма без НДС * 20% то есть расчет надо было делать не по строке, а по документу в целом, и потом подгонять суммы в строках... вы подрываете мою веру в более осмысленный подход к учету в других странах... Вот так и мучаемся, с налоговой либо в суд, либо сделать так, чтобы не тратить на суд время. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.09.2013, 10:38 |
|
Infor - так теперь принято кодить или лажа?
|
|||
---|---|---|---|
#18+
dabinoУ меня необычный вопрос. Я уже 12 лет не занимаюсь программированием, но "есть IT background". Волею судеб столкнулся с внедрением ERP Infor на производственном предприятии (БД - Oracle), и недавно дошли руки посмотреть код, которым это все реализовано. Просто приведу несколько примеров того, что у меня вызывает удивление: - процедуры построения отчетов не используют возможности sql (типа join). Вместо этого есть код, который вытаскивает из базы селекты, а потом в цикле обрабатывает их, каждый раз вызывая новые запросы. - отчет генерируется в файл excel (типа xlsx, xml представление). Но! Нет общей функции выгрузки в файл, в каждой функции своя реализация, все xml тэги перемешиваются с данными прямо в коде. - везде в коде - сокращения, нечитаемые названия переменных и полей таблиц - есть "магические числа" - просто стоят в коде, не объявляются как константы - в самой базе oracle - только таблицы, вьюшки вообще не используются - ну и в результате отчеты генерятая часами, потом пользователи дообрабатывают их в экселе (если удается открыть файл) Я понимаю, что я много пропустил в индустрии, есть application server, где вся бизнес логика крутится. Но так что, действительно принято писать теперь код? Или я немного прав, и проект делали низкопоофессиональные консультанты? Это стандартные отчеты или кастомизация? скорее второе... я не знаю какой код вы смотрели, но конструкции джойнов активно используются, также есть возможность писать динамический SQL из 4GL скриптов. по отчетным системам есть такая проблема, но уже есть несколько написанных библиотек, которые делают быгрузку в файл более простой и отделают код от шаблона(библиотеки у внедренцев)... также никто не отменял hidox - внешняя отчетная система, которая стандартные отчеты LN приобразует к форматам pdf и xlsx. отчеты могут генериться часами если: -база очень старая и данные не архивировались -запускаете по полному диапазону(например обороты по складу при большом кол-ве номенклатуры и перемещениях) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2013, 18:15 |
|
|
start [/forum/topic.php?all=1&fid=29&tid=1525994]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
165ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
80ms |
get tp. blocked users: |
1ms |
others: | 11ms |
total: | 301ms |
0 / 0 |