Сахават Юсифов wrote:
> Wolfa
>
> > Например, пользователь хлопнул приход 10 ед., хлопнул расход 10 ед.,
> > затем зашел бесперпятсвенно в приход и исправил на 9 ед., система не
> > должна такого позволять - это мое мнение. Или спокойно перенес дату
> > прихода.
> Вообще говоря, спорно. Обычно (но не всегда) так и должно быть. Но я бы
> такое в ТЗ оговорил, все-таки. Хотя если не оговорено, то так и должно
> быть. Похоже, что в данном месте система бухгалтерская (удобно для буха
> и пофиг какие убытки, пусть бухгалтер сам проверяет). А должна быть для
> оперативного управления (контроля). Это уже консерватория. Потому как
> разработчик должен "чувствовать" ЦЕЛИ работы системы.
>
> > дальше бухгалтер сдает отчет в Соцстрах,
> > из неправильного расчета среднего заработка болеющего, неправильная
> > декларация, но бухгалтер доверяет системе и поступает так как она ей
> > рассчитывает, результат штраф от соцтраха
> А ЗП вообще нельзя доверять. никакой. потому как на Украине что ни
> соцстрах, так свои особенности. И правилах расчета среднего тоже,
> кстати. А вот показатель качества системы, на мой взгляд, это то, как
> она позволяет выдать протоколы расчета и прочую диагностику, чтобы можно
> было удобно и быстро проверить, что алгоритм настроен правильно.
>
>
>
> Не гоните пургу.
> Вытрите слюны.
Вы об чем, лебъезный? какая пурга? какие слюни?
Навскидку:
Заказчик 1. Недопустимы отрицательные остатки в рамках месяца. т.е.
приход 30 числа, расход 15 - с 15 по 29 отрицательные остатки.
Заказчик 2. Недопустимы отрицательные остатки на кажды день, т.е. если
приход 15-го, то расход не ранее 15-го.
Заказчик 3. Отрицательные остатки допустимы по некоторой аналитике, но
по другим разрезам аналитики - отрицательные не допустимы. Суммарные
отрицательные остатки недопустимы.
Заказчик 4. партионный учет. Недопустимы отр. остатки по партиям (как
вариант - по хранению/давальческому в разарезе контрагента). Или... если
очень хочется, то - допустимы, но не по всем... но опять-таки, чтобы
общая сумма была положительная...
И еще несколько весьма занимательных ситуяций...

А по поводу зарплаты - та еще песня... это не законодательство, а бог
знает что. Плюс у каждого главбуха своё видение (или видЕние) того, как
должно быть... Плюс масса мест в расчетах, которые с первого взгляда не
понятны в явной и ясной форме, откуда настоятельное желание иметь
подробнейший пошаговый протокол расчетов...

Так шта... Может не стоит так уж сразу наезжать то? а?
Тем более, кому... ;-)
>


--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3

saasa wrote:
> *Oleg_Mar*
> Решать проблему надо и лучше всего начать с получения статуса CIO c
> cоответствующими полномочиями при принятии решений по финансированию и
> техническому обеспечению.
>
> p.s. не будет полномочий - ничего не будет !
э'т точно... упаси меня бог иметь ответственность и не иметь полномочий...
--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3

wellx wrote:
> - До всего этого обязать разработчиков сдать документацию и исходники.
> Желательно с комментариями.
не желательно, а обязательно. причем в техдокументации должна быть
описана применяемая идеология, применяемые подходы к проектированию,
инструментарий и т.д.


--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3