Добрый день. Произошел сбой в программе 1С 7.7 Торговля и склад. После сбоя восстановили работоспособность и все функции но после того как происходит изменения точки актуальности с приходно кассовом ордере перестало показывать оставшийся долг контрагента. Помогите советом, пожалуйста.

Торговля + склад редакция 9.2

[url=https://ibb.co/5hP63cg][img]https://i.ibb.co/zVzrgfT/bg1111.jpg[/img][/url]

https://ibb.co/5hP63cg скрин

ну и что? долг = 0. в чем проблема?

второе действие - Меню-Отчеты-Ведомость по контрагентам - отчет по этому проблемному клиенту с разворотом по всем доступным группировкам.

Злопчинский - проблема в том что долги после обновления даты пропали у всех контрагентов и в отчетах цифры актуальные - проблема только в приходно кассовом ордере - только туда не подставляет долги - хотя если я откатываю все данные до 31 июля то все нормально - но система показывает что точка неактуальна и после ее обновления там перестает все отображаться(

(4) открой по этому клиенту другой документ, например, расходную накладную - цифра правильная?
и убить за описание проблемы.
из скриншотов совсем не следует наличие проблемы как таковой.

сделать бэкап.
откатить на 30 июня ТА.
потом сдвинуть ТА на сейчас с перепроведением всех проведенных документов.
Посмотреть ситуацию после этого.

Злопчинский - прошу прощения за оформление темы, в следующий раз я буду более внимательнее. Во всех отчетах по остаткам, и по долгам - да, цифры верные. https://ibb.co/5hP63cg не выводит долг только сюда - остальном все верно.

открой по этому клиенту другой документ, например, расходную накладную - цифра правильная?

Злопчинский По расходной накладной, да. https://ibb.co/0Z9p6h3 - если я сдвигаю дату ТА через программу то у меня происходит данная ситуация которая не лечится. Поэтому дату я передвинул через MS Access в данном файле: 1SSYSTEM.DBF вручную - все заработало кроме данной функции.

Злопчинский - может мне через конфигуратор запустить пересчет итогов?

В дбф есть некоторые ограничения и они чуть меньше аналогичных sql. Количество строк в документе например. При архивировании периода иногда нарушается. Обычно панацея это выгрузка-загрузка. Если не получается выгрузка-загрузка, то создание периферии и поэтапная миграция.

acanta огромное спасибо за обратную связь, выгрузка и загрузка не помогла - мы ждали 3 часа окончания и проблема не решилась. Мигрировать не получится (хотя я предлагал) т.к. бух. привыкла работать только с данной программой и, она непреклонная. Может есть варианты попробовать что то еще?

Мигрировать я имела ввиду урбд периферийную базу, иногда делают как бакап для дбф, когда нет sql и требуется копия в разделенном режиме.

acanta Может вы дадите какой нибудь мануал - я был б вам очень благодарен.

Мдя.. Гланды через попу...
удалить все RG*.dbf, *.cdx и запустить в монопольном режиме...

не забыть сделать бэкап перед (15)

ДенисЧ - сбиваются все настройки, и конфигурация предлагает заполнить данные новой организации. Расскажите пожалуйста подробнее что мне необходимо сделать, дабы сохранить настройки, остатки и вернуть работоспособность функции созданной темы.

Злопчинский конечно на работающей машине я не буду тестировать все это.

(9) ошибка 310 - скорее всего проблемы с достижением технологического предела в таблицах ДБФ на 16 млн записей. отсюда и прочее может лезть.

(12) "- мы ждали 3 часа окончания и проблема не решилась. "
- при кривом учете (незакрытые регистры) загрузка может и несколько суток идти.
скорее всего у вас учет развален, а прога используется исключительно как печатная машинка.

Выкладывай сюда размеры самых больших файлов ДБФ

Злопчинский да. Как мне вылечить данную проблему? Если я запущу пересчет иготов - есть вероятность того что это поможет?

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

(22)
1. возьми любой дбф редактор
2. осмотри файлы на предмет количества записей в файлах ДБФ (от большего размера к меньшему)
если где-то колов записей приближается к 16 млн (погугли ошибку 310) - то это плохо, "автоматически" это может и не полечиться... надо смотреть предметно...

(17) бред, от удаления файлов RG*.* данные организаций в принципе не могут сбиваться.
это просиходит только в том случае если вы неправильно/бездумно удаляете и другие файлы, кроме упомянутых

для начала следует сделать
0. сделать бэкап
1. удалить все RG*.*
2. в режиме конфигуратора запустить ТИИ включив только галочки ПЕРЕИНДЕКСАЦИЯ И ПЕРЕСЧЕТ ИТОГОВ
.
но если у вас идет загрузка очень долго, то с очень высокой вероятностью вы не дождетесь и пересчета итогов.
.
приведенный рецепт лечит проблему с неправильными итогами/цифрами типа в (0), но судя по переписке у вас там еще вагон проблем.
так что лучше не рисковать (ибо явно квалификация недостаточна), а пригласить специалиста

к (26): п.1а удалить все *.cdx

Злопчинский удалить все RG*.* - (27) это файлы этого типа? RG3549.DBF??????

(28) типа этого типа
RG3549.DBF - подходит под маску RG*.*

как успехи?

(30)
-Фуххх! ну, всё!
-- сделал?
- нет, сломал!!!

(26) Злопчинский второй день проверяет - ждем результат)

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

(0) зайти в каталог с базой ДО ваших манипуляций, отсортировать файлы по убыванию размера, скриншот сюда.

И это, итоги сутками не пересчитываются, если че

(32) Возьмите программку confstat и она с большой вероятностью покажет что в реальности в окне конфигуратора и какой период в данный момент пересчитывается. Могу кинуть или она у Вас есть?

(32) Не пойму а зачем скрывать e-mail?
Я бы уже вам эту программку скинул бы

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

(34) я просил уже размеры файлов. ТС забил.

Кстати я вот все мучился как в УТ сделать чтоб было видно по каждой накладной маржу как сейчас в ТИС.
А получается так - назначаю минимальную цену и все что выше нее - это грубо интерес продажника. А сама эта минимальная цена устанавливается исходя из определенных параметров и критериев

может в каком регистре дата 1980 есть?

(41) До чего 7-ка затейливая :)
Хорошо хоть не 1080

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

(43) может они автомобилями торгуют. там нужна маржа итоговая. чтобы понять какую скидку можно еще дать, а какую нет

(43) Нет, электротехническими товарами. Просто так повелось когда-то. А вот сейчас мне кажется (43) очень правильно рассуждает

Хз. у нас можно посмотреть профит по каждой накладной, и бонусы и компенсации и сумму для агентов и т.д и т.п

кодить надо

(46) в УТ? Ну да, бонусы все это есть. Ну а профит по накладной - в 7-ке или в 8-ке?

(48) было и в 7-ке и в упп текущей

А так, похрен где закодить, прижелании

(50) Ну если партии есть то можно

(0) Переходи на 8-ку, там это реализовано

(52) Что это? И я не (0) :)

(51) это вранье. про партии. ты по партиям посчитал что маржа у тебя 50%. бонус продавану = 1000рублей. а на складе взяли из другой партии, и в реальности маржа = 20%. бонус продавану = 400 рублей. в результате твоих расчетов - контора потеряла на бонусах продавану 600 рублей.

(54) Не по партиям а по ФИФО.

(54) Тебе лишь бы не платить бабки

(51) у нас нет партий

(53) А я не теб

(55) если по фифо - манагеры не могут никак влиять на исчисление маржи. в момент продажи. каков смысл тогда исчисления маржи прям вот по накладным чтобы видеть. Что это дает пользы в практическом смысле?

(59) Могут влиять через изменение продажных цен

(54) не надо считать "по партиям", "по фифо". надо считать от некоей учетной цены. Торговый выполняет задачу - продавать не ниже учетной минимальной цены продажи (а лучше - по установленной цене продажи в установленных объемах). Закупщики - должны закупать не выше учетной максимальной цены закупа.  Разница между максимальной ценой закупа и минимальной ценой продажи [всех товаров] -  это минимальная маржа, необходимая  для функционирования компании.
а давать рулить маржей линейному персоналу глупо.

Учетная цена это хорошо. Теоретически в 8ке с ее запросом сумма(тч.количество*тч.товар.учетнаяцена) и регистры то не особо нужны, не то что бухгалтерия.

(62) учетная цена меняется. причем часто

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

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

(65) ну так я про то и говорю. продаваны на маржу никак не влияют. рынок влияет. На маржу можно влиять выйдя на рунок с каким-то супер-пупер уникальным продуктом или создав его спрос. но это не для рядовых продаванов. как-то так. н аистину не претендую.

(66) ну не обязательно уникальным - можно просто делать то же, что и другие - но чуть лучше. и постепенно увеличивать долю рынка, выигрывая на эффекте масштаба. (ну, типа "красный океан и синий океан")
продаван (особенно рядовой) может просто не видеть всей картины. например, многим производителям требуется АКБ. АКБ расчитывается по представленности определенного ММЛ. И продаван должен продавать весь товар из ММЛ, а не умничать, продавая "высокомаржинальный".

(67) АКБ? Автоматическая Кумулятивная Батарея? ММЛ? Минимальная Максимальная Логистика?
... я таких словов-то и не знаю даже...

(68) Автомат Калашникова Баллистический, Минимальная Масса Летальности...

))

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

(68) пардон... просто после обсуждений с торгашами это уже на автомате подразумеваю "всем известным"... АКБ - "активная клиентская база" (клиенты, которые работают с данным дистрибьютором и отгружаются данной продукцией), MML – minimum must list – список необходимого ассортимента ("как минимум в точке должно быть вот это, чтоб производитель посчитал, что это активная точка").
Т.е. какой-нибудь условный хохланд хочет, чтобы на полке в магазине было три "круга" (из 8 разных), три "блока" (из 6 разных), две "нарезки" (тоже из 6). Если такой ассортимент представлен, то магазин  считается "клиентом, работающим с продукцией хохланд", т.е. входит в Активную клиентскую базу. А от размера АКБ зависит уровень скидки дистрибьютору. Поэтому продавая какой-нибудь низкомаржинальный товар, торговый  выполняет ММЛ, отчего растет АКБ, отчего растет маржа по всему товару данного производителя....
Т.е. торговому не надо "рулить маржей" - его дело "выполнять поставленные задачи" (уговорить конкретного ЛПР в магазине взять нахрен не нужный товар, входящий в ММЛ, который после компенсируется какой-нибудь скидкой на товар популярный).

(70) Точка актуальности - где находится?