23.12.2009, 20:57 | #61 |
Участник
|
Валера, обрати внимание на одну из фраз:
Цитата:
все предидущие джобики писались знающими людми
|
|
23.12.2009, 21:12 | #62 |
Аманд
|
Да ладно, все когда-то делали или делают ошибки, неосознанно или по необходимости, аргументированно или нет. В некоторых "других" системах такие действия вообще считаются нормой.
Очевидно одно, что руководители служб поддержки не занимаются обучением специалистов и не заботятся о качестве оказываемых услуг. Собственно, это будет продолжаться до тех пор, пока вопрос о качестве услуг не задаст сам клиент. |
|
|
За это сообщение автора поблагодарили: Raven Melancholic (2). |
23.12.2009, 21:24 | #63 |
Участник
|
А что делать пока этого не произошло? Программировать или настаивать на своем? Есть люди, которые уже достигли того, что могут спорить, но не все же такие. Что делать им? С моей точки зрения, нужно спорить, но где гарантия, что после этого спора не придется забирать свою кружку (ну я заберу, а что с другими)?
|
|
23.12.2009, 21:59 | #64 |
Аманд
|
Цитата:
А что делать пока этого не произошло? Программировать или настаивать на своем?
Цитата:
Есть люди, которые уже достигли того, что могут спорить, но не все же такие. Что делать им?
Следует иметь ввиду, что в зависимости от принципа выставления счетов за поддержку, чем больше программинга, тем больше денежек. Соответственно, лучший способ - исправлять программингом. Тем более напрягать персонал откатывать проводки и всякие закрытия ещё сложнее. В том числе по методологическим причинам: специалист должен чётко описать процедуру, в этот момент его знания проходят проверку перед клиентом... Дальше сами понимаете, если он ошибётся, то огребёт от клиента и от начальства поддерживающей конторы. Ошибки программинга менне заметны или замылены, к тому же исправляются незаметно. Итого, как правило, чтобы исправить ошибку консультантскими методами нужно хорошо знать систему. Более того, после этого, персонал научится подобные ошибки исправлять сам, в большинстве случаев (если была инструкция, а она должна быть). И тогда обращений будет меньше. Если идти дальше, то при частом повторении однотипных ошибок нужно менять процесс, вводить доп настройки в системе, чтобы избежать повторение ошибок. И этот вариант даёт меньшее количество обращений. Подводя небольшой итог: как-то задумался я над идеей "умной" поддержки и анализа работоспособности системы и пришёл к выводам, что оценивать поддержку нужно по снижению количества обращений и инцидентов. Чем меньше - тем лучше. Иногда это сложно объяснить руководителям предприятий. Но для решения этого вопроса тоже есть своя концепция Цитата:
С моей точки зрения, нужно спорить, но где гарантия, что после этого спора не придется забирать свою кружку (ну я заберу, а что с другими)?
Вообще, надо бы общий мануал написать, что-то вроде "Исправления и сторно в DAX всех возрастов". Последний раз редактировалось Vals; 23.12.2009 в 22:18. |
|
|
За это сообщение автора поблагодарили: belugin (2). |
23.12.2009, 22:26 | #65 |
Участник
|
Мы как-то далеко ушли от темы
Из собственного опыта: раньше тоже заставляли пользователей самостоятельно отсторнировать неправильные документы. Где-то месяц плакали, жаловались. Иногда мне пришлось сам делать это за другими (когда был слишком много ошибок и они не успели все переделывать). Но потом привыкали... и привыкли. Хотя, сложно сказать, любят пользователи такой порядок или нет. Если уж использовать программисткое решение для этой задачи, то я бы написал джобик, который автоматически создает сторнирующий складской журнал. В 3-ке, по-моему, этой функции нет, но написать ее не сложно. Зато не сломать логику системы. Можно весить джобик на кнопку и научить пользователей ее использовать. |
|
23.12.2009, 22:29 | #66 |
Аманд
|
Цитата:
Мы как-то далеко ушли от темы
Ждём ответа от Opuss и трындим потихоньку Последний раз редактировалось Vals; 23.12.2009 в 22:32. |
|
23.12.2009, 22:38 | #67 |
Участник
|
Но я тоже не согласен с твоим подходом про поддержку.
Бываеет, что количество обращений становится меньше из-за того, что пользователи устали от медленных и слишком долго продуманных ответов от консультантов |
|
23.12.2009, 23:21 | #68 |
Аманд
|
Бывает
|
|
24.12.2009, 01:34 | #69 |
Участник
|
Vals 1.Про путь истины и сторно, я уже понял что так правильней, но в свое время когда начиналась поддержка клиент изъявил желание, на равне со сторно, иметь возможность и подчищать базу по мелочам. Сторно то они делают, когда я как понимаю, крупный косяк по вине клинта. А мелочевку мы подчищаем )) (так и хочется сказать подтираем))). Ко мне обратились с просьбой о подчистке, к тому же как говорит longson, сторно я то же не нашел.
2. Про поддержку и деньги, не совсем о близко оплачено в поддержке 2 дня в неделю моего присутствия и правки базы. (кстати это по моему даже прописано в договоре), весь программинг по отдельной плате, но именно этот программинг будет free т.к. не они его заказывали я туп(( и не знаю как надо сделать. А те кто у нас был и могли это знать давно поувольнялись... 3. Про консультантский метод и незнание системы, абсолбтно правильно, но ничего поделать не могу, к сожалению, и так стараюсь как могу не показывать свою неграмотность, и изучаю дополнительно. 4. Да "бросают" не обеспечив но не от хорошей жизни)). Raven Melancholic, знающие люди может сами job и не писали (раньше вобще все в sql правилось, а и мой колега перешли только недавно на job) но подход правки в базе они допускали, т.к. я уже говорил что сторно клиент делает причем много. А люди на форуме есть, но называть уж простите не буду. Далее про код все таки, получается следующее X++: delete_from INVENTTRANSPOSTING where INVENTTRANSPOSTING.InventTransId == "номер лота из строк журнала"; delete_from LEDGERTRANS where LEDGERTRANS.Voucher == "номер Документа ГК из строк журнала"; // запуск «Пересчёт сальдо по периодам», запускать надо здесь или можно когда весь job отработает? //!!! будет закоментарено но надо что то запустить // delete_from LEDGERBALANCESDIMTRANS where LEDGERBALANCESDIMTRANS.AccountNum == "не знаю может если повезет по одной //из сумм и дате"; delete_from INVENTJOURNALREPORTTABLE_RU where INVENTJOURNALREPORTTABLE_RU.JournalId == "номер журнала"; delete_from InventJournalTrans where InventJournalTrans.JournalId == "номер журнала"; delete_from TRANSACTIONLOG where TRANSACTIONLOG.Txt == "не знаю может если повезет по юзеру и дате"; delete_from INVENTJOURNALTABLE where INVENTJOURNALTABLE.JournalId == "номер журнала"; // удаление INVENTTRANS и пересчет INVENTSUM ttsbegin; while select forupdate InventTrans where INVENTTRANS.InventTransId == "номер лота из строк журнала" { InventTrans.delete(true); } ttscommit; /* delete_from INVENTTRANS where INVENTTRANS.InventTransId == "номер лота из строк журнала"; // спертый кусок из посоветанного для правки INVENTSUM if (dialog.run()) { itemId = dialogItemId.value(); } if (itemId) { while select inventTable where inventTable.ItemId == itemId { reCalcItem = new InventSumReCalcItem(inventTable.ItemId, true, CheckFix::Fix); reCalcItem.updateNow(); } } //конец спертого куска */ P.P.S. блин сделать надо все завтра часов до 11 (( P.P.P.S. Как клево быть крутыми перцами/дядьками которые много знают)), ну ничего еще пару-пятерку лет, глядишь, и я квам присоеденюсь))). |
|
24.12.2009, 01:43 | #70 |
Аманд
|
Цитата:
P.P.S. блин сделать надо все завтра часов до 11 ((
Цитата:
2. Про поддержку и деньги
|
|
24.12.2009, 08:55 | #71 |
Участник
|
Внимание ОШИБКА !!!
Приношу свои извенения. Мой английский меня подвёл .В своём сообщении Удаление разнесенного складского журнала. Цитата:
Сообщение от S.Kuskov
Повторюсь. Самостоятельный пересчёт InventSum можно не делать если воспользоваться параметром dropInventOnHand метода InventTrans.delete(). T.е. если
X++: delete_from INVENTTRANS where INVENTTRANS.InventTransId == "номер лота из строк журнала"; X++: ttsbegin; while select forupdate InventTrans where INVENTTRANS.InventTransId == "номер лота из строк журнала" { InventTrans.delete(true); } ttscommit; я ошибся с точностью до наоборот. Параметр dropInventOnHand (название этого параметра меня и подвело, оказывается drop - в смысле пропускать) нужно оставить равным NoYes::No (значение по умолчанию), если хотите чтобы InventSum пересчитался сам. Т.е. код можно оставить ваш (он и InventTrans удалит и одновременно InventSum пересчитает): Правильный вариант X++: // удаление INVENTTRANS и пересчет INVENTSUM delete_from INVENTTRANS where INVENTTRANS.InventTransId == "номер лота из строк журнала"; Последний раз редактировалось S.Kuskov; 24.12.2009 в 08:58. |
|
24.12.2009, 10:35 | #72 |
Участник
|
итого код: X++: delete_from INVENTTRANSPOSTING where INVENTTRANSPOSTING.InventTransId == "номер лота из строк журнала"; delete_from LEDGERTRANS where LEDGERTRANS.Voucher == "номер Документа ГК из строк журнала"; // запуск «Пересчёт сальдо по периодам», запускать надо здесь или можно когда весь job отработает? //!!! будет закоментарено но надо что то запустить // delete_from LEDGERBALANCESDIMTRANS where LEDGERBALANCESDIMTRANS.AccountNum == "не знаю может если повезет по одной //из сумм и дате"; delete_from INVENTJOURNALREPORTTABLE_RU where INVENTJOURNALREPORTTABLE_RU.JournalId == "номер журнала"; delete_from InventJournalTrans where InventJournalTrans.JournalId == "номер журнала"; delete_from TRANSACTIONLOG where TRANSACTIONLOG.Txt == "не знаю может если повезет по юзеру и дате"; delete_from INVENTJOURNALTABLE where INVENTJOURNALTABLE.JournalId == "номер журнала"; // удаление INVENTTRANS и пересчет INVENTSUM delete_from INVENTTRANS where INVENTTRANS.InventTransId == "номер лота из строк журнала"; по идее все? |
|
24.12.2009, 10:47 | #73 |
Участник
|
Ну так а эту кнопку 'Копировать' пробовали нажимать-то?
|
|
24.12.2009, 10:51 | #74 |
Участник
|
Да, пробовал... коируются строки журнала в новый журнал...
|
|
24.12.2009, 11:01 | #75 |
Участник
|
У меня в приложении (правда на GLS слое) в диалоге, который открывается по этой кнопке, присутствуют параметры 'Обратный знак' и 'Сторно'. Возможно кто подскажет после какого обновления они появляются.
|
|
24.12.2009, 11:25 | #76 |
Участник
|
Мужики, видите, у меня сторно даже в приложении нет))). Помогите допрограммировать до конца джобик несчастный, вроде бы осталось немного совсем, и запустить процедуру пересчета.
|
|
24.12.2009, 11:57 | #77 |
Участник
|
Цитата:
Хотя неплохим методом изучения было бы написание такого функционала в Ax3.0 |
|
24.12.2009, 12:01 | #78 |
Участник
|
Цитата:
Vals, извини. |
|
24.12.2009, 12:01 | #79 |
Участник
|
Это да, все напишу)), тока потом, щас уже надо сделать, чел пришел, а я все не сделал...
Подтвердите кто-нить правильность джоба, хот примерную... и про процедуру "пересчет данных по периодам" как я понял можно безболезнено совершенно запускать. |
|
24.12.2009, 12:30 | #80 |
Участник
|
Ладно хрен с ним с job если что-то то лишнее удалю или оставлю, не так страшно, а вот запуск "пересчет данных по периодам" меня сильно напрягает, подскажите безопастно его все таки запустить?
|
|