периодическое задание коррекции себестоимости товарных операций - Страница 2 - NAV: Функционал

Wizard_imported · 16.06.2005, 17:04

Цитата:

Сообщение от dik

моя версия - NAVW13.00,NAVRU3.60.02.01 :-(((((((((((((

надо ещё юнит 5895, у меня числится NAVW13.70.01,NAVRU3.60.04.03 - это соответствует последнему сервис-паку, который я накатывал на 3.60. Потом бросил это занятие и по-этому не уверен, что он самый лучший. Имхо надо в этом направлении копать - были серьезные проблемы с этим пакетником.

Wizard_imported · 16.06.2005, 17:09

Цитата:

Сообщение от dik

разработчик нашел какие то подозрительные операции, выкусил их т.к. причину установить в отладчике не удалось

<{POST_SNAPBACK}>

чего-чего разработчик сделал?

dik_imported · 16.06.2005, 17:10

поменял report на свежий из 3.70В - резултат стабильный - циклится

asacom_imported · 16.06.2005, 17:12

Цитата:

Сообщение от Wizard

чего-чего разработчик сделал?

<{POST_SNAPBACK}>

реализовал функцию: накося-выкуси()

Галина · 16.06.2005, 17:12

Ну меняйте тогда и там где разрабочик выкусил. где в кодеюните или еще каком репорте?

dik_imported · 16.06.2005, 17:14

объекты я не менял, когда наступил на эти грабли в первый раз то долго рылись пришли к выводу что некорректно в таблице 339 Item Application Entry. Даже установили десяток строк на которых происходит зацикливание. и удалили значения из этолй таблицы. Причину сбоя так и не установили. програмный код - это просто Чума!!!!!!!!!
Задание прошло себестоимость скорректировалась (правильно или не очень это уже сторой вопрос :-))) )
А теперь опять теже вилы, у меня от перспективы лазить по коду тускло делается но видно никак не обойтись, нужно искать первопричину.

asacom_imported · 16.06.2005, 17:16

а если серьезно, то надо было разбираться, а не выкусывать...
сейчас можно попробовать восстановить из архива(на ту дату) и все таки разобраться... да и база наверняка была меньше, ходить по циклам не так муторно...

dik_imported · 16.06.2005, 17:24

поменял CU 5895 на из 3.70В не помогло. Действительно придется разбираться. Сначала было оч горячо, не до разборок было, щас те же грабли, оч похоже что где то не корректные данные. буду искать по коду. мож что найду

Wizard_imported · 16.06.2005, 17:24

Цитата:

Сообщение от dik

поменял report на свежий из 3.70В - резултат стабильный - циклится

<{POST_SNAPBACK}>

ещё юнит 5895, раз есть где взять, собсно код-то весь в нем, 795 - это только обертка.
Однако...

Цитата:

пришли к выводу что некорректно в таблице 339 Item Application Entry. Даже установили десяток строк на которых происходит зацикливание.

Каким образом?

Цитата:

удалили значения из этолй таблицы

Очень плохо, очень...
чем помочь-то теперь?
база SQL или native?

Галина · 16.06.2005, 17:24

Очень интересно и как вы удалили записи в таблице 339. Если вы клиент - то с вашей лицензией это сделать нельзя. А если разрабочик-то вызывает удивление что удалили эти записи. Эту таблицу просто так удалять нельзя. Только если хорошо понимаешь связи между таблицами.

asacom_imported · 16.06.2005, 17:27

Цитата:

Сообщение от dik

оч похоже что где то не корректные данные. буду искать по коду. мож что найду

<{POST_SNAPBACK}>

только искать надо до удаления...
сейчас это выяснить практически невозможно...

dik_imported · 16.06.2005, 17:28

установили по коду, после 8 часового ползанья, что зацикливание происходит именно в этом десятке строк, вырезали их из таблицы и сохранили в Excel файле. Не смогли найти в коде именно условие которое определяет что пора выходить из цикла. упарились ползать.

сервер - native, но на моей машине поднят SQL локально, можно поднять на нем базу, если это поможет разобраться с данными

Галина · 16.06.2005, 17:37

Если у вас циклит и с данными за прошлый год-которых в принципе нет. То разбиритесь с прошлым годом. Там будет меньше передвижений по циклу. И вам будет проще разбираться. И разбиретесь с кодом.

Wizard_imported · 16.06.2005, 18:12

эксельник сохранился?
глянуть можно?
сейчас в 339 тб записей много?

dik_imported · 16.06.2005, 18:40

сохранился
ща попробую приклеить его

dik_imported · 16.06.2005, 18:41

во, приклеил, удивительный форум, куда ни ткнешь - все работает :-)))

dik_imported · 16.06.2005, 18:42

именно в этих строках и елозили пока не выкусили.

dik_imported · 16.06.2005, 23:05

Нашли причину после ползанья по кодеюниту 5895. Резюмирую: НЕ ИДИТЕ НА ПОВОДУ У ПОЛЬЗОВАТЕЛЕЙ НИ ПОД КАКИМ ПРЕДЛОГОМ ВПЛОТЬ ДО ВАШЕГО УВОЛЬНЕНИЯ!!!!!!!!!!!!!!
НЕ ПРАВЬТЕ ДАННЫЕ В ТАБЛИЦАХ РУКАМИ!!!!!!!!!!!!!!!!!! (особенно если еще и не знаешь до конца что на что влияет).

Суть проблемы была в том что по просьбе, нет не по просьбе а по требованию бухов, я правил даты учета в таблице 5802 Value Entry и от большого ума поправил и даты переоценки. а этого делать нельзя. дата переоценки должна синхронно возрастать вместе с номером операции в этой таблице. Не может быть такого что 1-я операция имеет дату переоценки 10-02-05 а 2-я операция дату переоценки 05-02-05. дата переоценки второй операции должна быть более или равна дате переоценки первой операции.

Блин, но что делать с бухами?! они меня уже просто разорвали, дай им механизм отмены учтенных операций, их переделки, отмены примененых оплат, отмены учтенных применений, короче хочут 1С-ного раскалбаса. это просто чума какая-то

**mazzy** · 17.06.2005, 00:04

о... про отмену учтенных операций...
сколько обсуждений и баталий было...
ищите на этом форуме и на http://www.mibuso.ru/forum/
в двух словах: не идите на поводу у пользователей

про 1Сный расколбас здесь хорошо написано
http://www.axforum.ru/forums/showthread.ph...69819#post69819

asacom_imported · 17.06.2005, 09:39

Цитата:

Сообщение от dik

НЕ ПРАВЬТЕ ДАННЫЕ В ТАБЛИЦАХ РУКАМИ!!!!!!!!!!!!!!!!!! (особенно если еще и не знаешь до конца что на что влияет).

<{POST_SNAPBACK}>

Блин, об этом на всех заборах пишут!

Цитата:

Сообщение от dik

Нашли причину после ползанья по кодеюниту 5895. Резюмирую: НЕ ИДИТЕ НА ПОВОДУ У ПОЛЬЗОВАТЕЛЕЙ НИ ПОД КАКИМ ПРЕДЛОГОМ ВПЛОТЬ ДО ВАШЕГО УВОЛЬНЕНИЯ!!!!!!!!!!!!!!

<{POST_SNAPBACK}>

Работал я с одним начальником ИТ-отдела... Использовалась самописная система. Велся "белый" учет.
Так он, на любое вмешательство в работу системы, требовал от пользователей оформления служебной записки, с подробным описанием проблемы и ПРИЧИН ее возникновения! Служебка обязательно одобрялась высшим руководством. Все выполненные действия фиксировались и подшивались к служебке!
И система работала изумительно... И проверки налоговой проходили без "конвертиков"!
Затем этот начальник ушел, взяли другого, который очень любил выслуживаться перед руководством. Он вместо детального анализа лез своими руками во все, по первой просьбе пользователей...
В результате этой деятельности, через полгода ушел главбух, а еще через полгода фирма развалилась...

Может я не очень красиво описал, но суть вроде показал...