Всем привет!

Подскажите, есть база БП (старая и замусоренная). Задача - перенести остатки в новую чистую базу и продолжить ведение в ней. Делаю свертку (в БП 2.0 - внешней обработкой, в БП 3.0 - встроенной обработкой). В результате формируются операции ввода остатков на дату свертки. Через ВыгрузкаЗагрузкаXML пытаюсь перенести эти операции в новую базу. Но они либо переносятся пустыми (то есть не содержат никаких данных кроме даты и наименования), либо, если поставить галочку "Переносить со всеми движениями", переносятся почти все документы из старой базы (по сути смысла тогда в переносе и нет).

Как же правильно переносятся остатки после сверки?

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

Значит, так свернули

(1) Нет. Есть база БП 2.0 Пробую свернуть её внешней обработкой "Свертка БП 2.0". Формируются операции ввода начальных остатков. Пытаюсь перенести их с помощью ВыгрузкаЗагрузкаXML в чистую БП 2.0 такого же релиза. Результат описан в первом сообщении.

Может быть внешняя обработка так неправильно делает свертку. Тогда я обновляю конфу (до свертки) до БП 3.0 и уже в обновленной делаю свертку встроенной обработкой "Свертка". опять же формируются операции ввода начальных остатков, но при переносе тот же результат (либо пусто, либо вместе со всем старым хламом).

(2) Сворачиваю не я, а обработки, в т.ч. типовые. Настройки при свертке стандартные.

Ну кто ж типовой сворачивает-то... Да ещё и на результат потом не смотрит...

(4) А какой, если не сложно раскрыть тайну?

(5) hands.epf с расширением brain.epf

А зачем переносить куда-то? Удали старые доки, а копию разверни как "архивная база".

(7) Да дело в том, что там около 17 000 объектов после свертки помечены на удаление (вероятно, часть из них еще до свертки была помечена на удаление), а когда делаешь удаление, то удаляется всего несколько сотен объектов, а остальные так и остаются в базе просо с пометкой на удаление. База была нетиповой, привели её к типовой. Если это имеет какое-то значение.

(8) Приведи к типовой, сверни, жестко удали ПНУ объекты и сделай ТиИ с зачисткой объектов - профит

(9) +1

(9) (10) Куча пустых ссылок, где их быть не должно == разрушенная база.

(11) для этого есть ТиИ, не? а вы с какой планеты?
стотыщщщ раз так делал, что то не разрушились базы, или ЧЯДНТ?

(11) Пустые ссылки - если учет велся в 2.0 через ж..у

как правило это проявляется на счетах 76.ВА или 76.АВ частенько

Может быть это не выход для хорошего спеца - но почему бы не написать простенькие правила обмена для такого случая? Выгрузить МД конфигурации с выгрузкой движений, ну и перенести эти операции по дате. Если не надо данные никак "рихтовать" - то вроде должно нормально перекинуться, только надо проверить будет на дубли стандартные и предопределенные элементы. Или не вариант?

(12) Для базы (на уровне платформы) пустые ссылки норм. А вот для учета вместо остатков по сотне с.ф. (с датами, номерами и т.д.) получить кучу без аналитики = "угробить учет" (так корректнее чем "разрушенная база")

(13) пустые ссылки это не результат кривого учета, а прямое следствие (9)

(14) и на всех счетах расчетов с контрагентами

(16) Чушь, потому что база становится не кривая, а как с первого ввода остатков, если надо - конкретики редактируй ввод остатков , но в 99,9% этого не требуется

и еще, для конкретики и аналитике есть копия базы и два- базу срезать надо по такой период чтобу эта конкретика и аналитика была просто не актуальна

(9) "Жестко удали ПНУ" это что значит?

Помеченные На Удаление

(17) А! На вашей планете нет НДС, авансов, расчетов в валюте и партионного учета - тогда норм. У ТС не удалилось 90% помеченных, может ему не повезло и он попал в 0.1%

(18) Если у ТС не удаляется большинство ссылок значит период выбрал явно не так.

(0) В (9) в принципе правильный совет. Только я бы не зачищал битые ссылки, а "восстановил" бы пустые документы обработкой, на всякий случай. И стоило в итоге ТС портить себе праздники таким образом? Я как только не делал переход на Бух 3-ку, лучше всего - свои правила обмена с штатными документами ввода остатков. Но там, конечно, нужна минимум неделя, если все с нуля делать, чтобы была возможность нормально потестить перенос, особенно если с переходом на раздельный учет НДС. У меня есть правила обмена, но не поручусь, что они актуальные и на 100% адекватно отработают сейчас, ну и сильно привязаны к конкретному случаю, без перехода на раздельный учет НДС.

(0) "переносятся почти все документы из старой базы " - посмотри внимательно на эти документы - они наверняка не просто так переносятся, а привязаны к остаткам, или на них есть ссылки в документах, которые сидят в остатках.

Сделай в КД правила для переноса БП2 - БП2 и по идее все остатки должны хорошо перенестись. При этом не должно в чистую базу прийти ничего лищнего

(8) Аналогичная ситуация. Посмотрел, достаточно большое количество связей между документами. Удаление система осуществить не может. Пробую ручками.

(26) В файловой не удлаит - в скуле удалит...
(25) Как всё просто))))
(0) Переносятся не все документы, а те, на ктрые есть ссылки в остатках, причём эти ссылки, при использовании типовой свертки, будут так ж помечены на удаление, и не дадут жить спокой в новой базе, при необходимости что то удалить в новой базе - будет всё очень медленно и печально...

В принципе всё это проходили много раз, и, как всегда встают два вопроса:
Кто виноват? (ответ - кривой учёт, и сделать с этим уже ничего нельзя...ну или почти ничего)
Что делать?  (ответ - попытаться сделать свертку документами ввода начальных остатков - есть в природе и такие правила и есть обработки, которые это делают или написать свои, правдад неделей врядли обойдётся, хотя...всё зависит от базы, если не гнаться за универсальностью, то вполне возможно)

Есть ещё один совет - если колхохить с документами ВНО нет желания/возможности, то стоит после свертки базы, перед переносом в чстую попытаться разобраться с полученным результатом:
1. Проанализировать остатки по взаиморасчетам (60, 62, часть 76) - тут, часто, очень много мусора, который можно почистить. Мусор - это "бабочки" (одновременные остатки по Дт и Кт) или остатки с плюсом и минусом по одному контаргенту и договору,но разным документам расчетов - всё это можно свернуть, и документов расчетов в аналитике, и следовательно в новой базе, будет существенно меньше.
2. Если не нужен раздельный учет по НДС, то не нужно переносить соответствующие регистры по НДС, а вот там то, как раз основная масса неудаляемых документов.
3. Если в исходной базе включен партионный учет, то нужно выяснить, нужен ли он будет в свернутой базе, если не нужен, то опять можно избежать переноса партий (документов поступления ТМЦ) очистив их в операциях ВНО перед переносом
...
N.
Можн придумать ещё кучу советов, но, опыт показывает - каждая база уникальна, и тут нужно уже саму базу смотреть, что там, и тогда принять ещё какие то решения...