Вход | Регистрация


1С:Предприятие ::

Метки:документы

Как перегнать накладные в dbf?

Я
   1С-никЕ2
26.07.04 - 14:38
Две типовые бухии 7.7 на двух компах в разных концах города. Нужно накладные за опред. период перетащить в комп, где ведется полный учет. Хочу через dbf, но поля "контрагентов", "договоров" ..., очевидно из-за использования справочников, формируются не текстовыми, а с непонятным цифровым кодом. Думаю, что с многострочностью тоже не все просто, так как номер дока и другие реквизиты единичные: их или повторять в записях или ???
Кто-нибудь может помочь советом? Или я не там и не так копаю?
 
  Рекламное место пустует
   427
 
1 - 26.07.04 - 14:45
поимаешь гемороя с ДБФ... и продумай вопрос с нумерацией доков  и кодов справочников...
   sam_sam
 
2 - 26.07.04 - 14:46
перетащить это фигня, вот как ты справочники синхронизировать будешь
   Громобой
 
3 - 26.07.04 - 14:49
Для этого есть специально написанные обработки, в частности Универсал. Можно написать и свою, но чуть-чуть дольше будет :)
   Diter
4 - 26.07.04 - 14:53
Привожу свою схему (отработана и отлажена). Может конечно и не моя, но додумался до неё сам.
Итак
На этапе формирования пакета данных для отправки делаешь так
1. файл с шапками документов - все реквизиты-справочники - пишешь в файл код, все реквизиты перечисления - строку
2. Файл с ТЧ документов с полем "документ", в который пишешь номер документа от которого эта ТЧ
3. Файл с данными по контрагентам, которые участвуют во всех документах, которые та передаёшь
4. Файл с товарами - аналогично контрагентам
Загрузку делаешь так
1. Загружаешь и проверяешь справочники (синхронизируй по коду с проверкой соответствия наименования)
2. Новый документ - запись из файла шапок-заполняешь все реквизиты документа, какой реквизит - справочники ищешь в соответствующем справочнике. Когда дохожишь до ТЧ открываешь файл с ТЧ документов и ищешь по документу-владельцу соответствующую ему ТЧ - заполняешь. Всё.
   SnarkHunter
 
5 - 26.07.04 - 15:09
Синхронизация по коду - неверное решение...
   Diter
6 - 26.07.04 - 15:13
(5) Почему же?
Ситуация 1 Элемента с таким кодом не существуе вовсе
Проверяем, не ввели ли его под другим кодом (по наименованию) если нет - вводим новый, да ввели - меняем у существующего код.
Ситуация 2 Элемент с таким кодом есть, но другое имя - меняем у существующего элемента код на любой возможный и добавляем новый элемент с нужным кодом
Ситуация 3 Элемент с таким кодом и именем существует - ничего не делаем.
   1С-никЕ2
7 - 26.07.04 - 15:22
Diter-у
Спасибо. В принципе понятно.

427-му и sam_sam: тоже спасибо, но вопрошаюший, как правило, жаждет позитивных предложений.
   SnarkHunter
 
8 - 26.07.04 - 15:29
Ну ты с такими позитивными предложениями дублей в справочниках-то наловишь...
   Diter
9 - 26.07.04 - 15:34
(8) Спорим не наловит. Объясни почему? Только не голословно а с примером.
Единственная ситуация, которую эта схема не отлавливает, если в наименовании элемента справочника есть в начале или конце пробелы, т.к. используется СокрЛП(). Но это во-первых редкость, во-вторых - неправильно и кривые руки у юзеров отбивать надо.
   1С-никЕ2
10 - 26.07.04 - 15:38
Громобою.
Универсальную обработку на хипо "бездвоздмездно" не дают скачивать.
 
 
   sam_sam
 
11 - 26.07.04 - 15:40
если у всех поотбивать, работать не с кем  будет.:))
Не только дублей, но и трюплей и четверей.:))
Плюнь на это дело, реально можно сделать только, когда выгружаешь в чистую базу.Или придется усе руками сопостовлять
   Diter
12 - 26.07.04 - 15:49
(11) Опять пустой трёп. Я же просил на конкретном примере показать как можно поймать дубля при двойной проверке (и по коду и по наименованию)?
   Diter
13 - 26.07.04 - 15:52
(11) Эта схема работает в трёх моих разработках у реальных клиентов уже в течении месяца. Никаких дублей замечено небыло. Все справочники заполняются на нескольких машинах. Весь обмен идёт через dbf. Ни разу, я повторюсь, дублей выявлено небыло.
   SnarkHunter
 
14 - 26.07.04 - 16:39
Код - 1
Наименование - ИмяДляДэбильногоПримера
  
При загрузке записали новый элемент (1, ИмяДляДэбильногоПримера)
 
В базе источнике изменили наименование на ИмяДляДебильногоПримера
В базе приемнике при загрузке создается новый элемент (2, ИмяДляДебильногоПримера)

В базе источнике изменили наименование на ИмяДляПридурковатогоПримера
В базе приемнике при загрузке создается новый элемент (3, ИмяДляПридурковатогоПримера)
 
В сухом остатке получаем:
в базе-источнике все остатки/движения на элементе (1, ИмяДляПридурковатогоПримера)
в базе-приемнике те же остатки/движения разбросаны по ТРЕМ разным элементам...
 
Если это не дублирование, то...
   Diter
15 - 26.07.04 - 16:54
(14) Извени, но это уже явные косяки. Если все будут менять имена и коды во всех базах, то бардак будет при любой схеме синхронизации. Даже если ты будешь использовать внутренний ID МОДа от ПиБи всё равно ничего путнего не получится. Пользователь то работает не с внутренним кодом а с именем клиента и ты хоть лопни, но доказать ему что Вася это Петя только исправленный ну никак нельзя.
Если разбираться, то это тот уровень защиты от дурака, когда программно ты ничего не сделаешь. Нужны административные решения. Вплоть до запрета ввода новых элементов справочников в перефирийных базах. Предупреждаю крики - это для примера, хотя один мой клиент заказал такое при обмене с удалённым складом. Всё равно все заказыоформляются и печати ставяться в центральной бухгалтерии. Вот только там и вводили новых контрагентов, а перефирийные базы - нет.
   lexa
 
16 - 26.07.04 - 16:58
попробуй урбд
   Diter
17 - 26.07.04 - 17:22
(+15) Кроме того забыл указать, что все вновь созданные элементы создаются в папке "Неопознанные при загрузке", а все существующие элементы, у которых был изменён код - в папке "Изменённые при загрузке". Юзеру остаётся только разобраться с ними. Опять же обмен между базами предполагает обмен хотябы раз в несколько дней, лучше конечно каждый день, а то и раз в несколько часов. При этом количество новых клиентов и товаров обячно не превышает десятка-двух. Уж разобраться с ними не проблема ни времени и ни сил. Было бы желание.
   Соратник
 
18 - 26.07.04 - 17:29
можно еще и на ИНН проверку привязать, уж он то точно индивидуален
В остальном согласен с Diter, когда необходимо синхронизировать информацию, то и дисциплина должна быть. Хотя она должна быть в любом случае.
   Diter
19 - 26.07.04 - 17:43
(18) Пробовал синхронизировать и по ИНН и по ОКПО и по р/с всё не то. Эти реквизиты относятся к тем, которые бухи не всегда заполняют. Я вот ставлю "клиент-банк" так не могу юзеров заставить повводить ОКПО, МФО и р/с. Так тут деньги завязаны, что для бухгалтера святое. А на косяки при обмене им вообще начихать. Звонит вчера часов в 9 вечера клиент и говорит "программа отказывается добавлять контрагента в справочник". Спрашиваю "Чего пишет" (нужно отметить, что воткнул проверки и защиту от дурака куда только дотянулся). Говорит "Пишет, что неверное имя контрагента". Спрашиваю "Какое имя", отвечает "ЗнакБольше-меньше" (т.е. вообще без имени). Я спрашиваю "А зачем вам документы с таким контрагентом?" отвечают - "А решили списать товар, проданный за наличку, и чтобы никого не ставить завели нового контрагента с пустым именем, чтобы НЕ ВЫЛАЗИЛО В ОБОРОТКЕ". Спрашиваю "А вы оборотку то смотрели после этого?" ответ "Нет, а зачем". "А затем, что там пустой контрагент всё равно появится". Говорят "Быть не может". И этот диалог происходит при условии того, что я русским языком рассказывал, что нельзя вводить пустых контрагентов или контрагентов, имя которых начинается с пробела.
   SnarkHunter
 
20 - 26.07.04 - 17:47
(18)В том-то и проблема, что ИНН не уникален...
(17)Синхронизацию либо делать по ИД, либо не делать совсем... Используя ИД мы имеем взаимно-однозначное отображение, в противном случае потенциальные грабли, которые стукнут по лбу если не через месяц, так через год...
   SnarkHunter
 
21 - 26.07.04 - 17:49
(19)Если ставил "защиту от дурака", то почему при записи не проверяется пустое наименование контрагента?
   Diter
22 - 26.07.04 - 17:56
(20) какое же однозначное отображение если всё равно в одной базе увидят ИмяДляДэбильногоПримера а в другой ИмяДляПридурковатогоПримера и ИмяДляДебильногоПримера? А? Да код один, он и в моём случае один, но имена то разные.
(21) Ты знаешь как то не подумал, что юзер может до такого додуматься. Как раз сегодня поставил запрет выгрузки таких документов с пустыми именами элементов справочников.
   SnarkHunter
 
23 - 26.07.04 - 18:08
(22)Если у тебя действительно синхронизация, а не абы как сделанная выгрузка, то все реквизиты, измененные в базе-источнике, должны стать таковыми и в базе-приемнике... Иначе это не синхронизация...
   hanprog
24 - 26.07.04 - 18:36
Не сложно но выгружать лучше в txt формат я выгружал при помощи команды ВСтроку ИзСтроки главное здесь не запутаться делаешь одельные функции для выгрузки справочника (со всеми реквизитами) и документов (шапка и табл) перебирая все метаданные если все сделать правельно то получится универсальная выгружалка и загружалка а лучше использовать даже не txt а xml
   cardy
 
25 - 26.07.04 - 20:24
Делал подобную обработку, принцип работы такой же как у  Diter (4). Единственно, что мы сразу определись, что делать приход и заводить новых контрагентов могут только в центральной базе, в 2-х подчиненных магазинах сделал запрет на это дело. Все работает уже 8 месяцев, за 1-й месяц правда пришлось побегать и поисправлять косяки.
Так что сразу определяйся какая контора будет главной и вперед.
УРБД пробовать даже не стал, т.к. не было под рукой, и был критерий чтобы все данные помещались на дискету.
Правда я еще сделал в подчиненных (в смысле в 2-х других) базах что при начале работы Константа Дата Запрета Редактирования документов равна вчерашнему дню, дабы они ничего не могли изменять задним числом, и изменять эту константу они не могут.
И когда происходит выгрузка то выгружаю документы за целую неделю (на всякий случай, если все же умудрились что то сделать задним числом).
   SAS_Chelny
 
26 - 26.07.04 - 20:52
(24) сделал примерно также. Через текст все работает быстро, Там все по секциям, шапка, ТЧ. Написал это давно и везде применяю. Если обмен односторонний, то развожу коды в разные разряды. По этой схеме успешно работают три последовательных базы, правило одно-справочники заводятся только в головной базе. Если конфы одинаковые и есть XML-схема, то в конфе Конвертация данных урезаю общую схему до нужных документов. С нуля писать схему нет ни желания ни времени.
   ProgMer
 
27 - 26.07.04 - 22:40
У меня тоже проблема была. Нужно было накладные с одного компа на другой комп перегнать каким-нибудь ёбразом. в принципе я поступил способом dbf-ок, ориентацию по номенклатуре осуществлял кодами (я просто номенклатуру перегнал с одной базы в другую). Сразу скажу: -Я так думаю тут ничего сложного нет.
Если что задавай вопрос по конкретнее, постараемся ответить!!!
:)
   427
 
28 - 26.07.04 - 22:52
Синхронизация через код или наименование - бАльшие грабли...
Если на большом поле в5 гектар есть две коровьих лепешки - юзеры всегда их найдут и вляпаются... причем не один раз...

Так что делаете синхронизацию, не зависящую ни от кода, ни от наименования (можно менять ВСЕ реквизиты) и все фиолетово....

На самом деле гораздо сложнее в белой базе соблюсти требования закона в нумерации доков....
   SnarkHunter
 
29 - 26.07.04 - 22:58
(28)Что характерно - никто это не воспринимает... Глас вопиющего в пустыне... Предпоследние четыре поста  - откровенное сравнение размеров...
   427
 
30 - 26.07.04 - 23:06
(29) Прогульщикам будет выдаваться отдельно.... маленьких размеров.... съемный...



Список тем форума
  Рекламное место пустует
Независимо от того, куда вы едете — это в гору и против ветра!
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Ветка сдана в архив. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует