За несколько лет мне неоднократно приходилось делать прикладные программы, в которых формировался файл с проводками в формате dbf, который после этого загружался стандартной операцией БЭСТ4 ИМПОРТ в ФОРМАТЕ DBF (выручки магазинов, суммовой учет поступлений от поставщиков и многое другое).
Делаю я это обычно над Excel в VBA. Удобный интерфейс, кнопочка, выгруженный файл.
Вероятно, можно было бы произвести запись в Main.DBF и непосредственно из VBA.
Может быть кто -нибудь это делал. Не могли бы привести код.
Возникла проблема. Видимо в результате сбоя.
В прих. накладной введен НОВЫЙ ТОВАР (новое наименование и номенклатурный номер).
Товар видится в Номенклатурном справочнике, в картотеке, в картотеке партий.
Но когда открываешь прайс (основной, но номенклатуре), то видишь только ГРУППУ и НОМЕР ТОВАРА, но не наименование (там ПУСТО). Пытаемся назначить цену (по CTRL-Enter) - водится, но не сохраняется.
Провел восстановление данных, просмотрел mlabel, mkart, spr_part. Никакой грязи или пустых записей.
Видимо появилось несколько дней назад. И теперь любая новая номенклатура ведет себя также. ......
Недавно делали расчет по "Записке-расчет на увольнение Т-61".
Теперь включает в расчет и месяц, когда уволен. Например, уволен 5.08.2011, а в расчет идет август.
А так должно быть только если УВОЛЕН ПОСЛЕДНИМ ЧИСЛОМ МЕСЯЦА (31 или 30)
Интересно мне, почему если я заменяю в приходной накладной (в MDOCM) CENA0 на CENAOUT (то есть учетную цену в накладной по ЦЕНЕ ПОСТАВЩИКА, то после расчета себестоимости она не становится УЧЕТНОЙ ценой в партии.
В организации производство.
В теч. месяца они приходуют гот. продукцию по условным ценам.
И тут же отгружают ее.
По окончании месяца они рассчитывают реальную цену продукции.
Ее надо внести в качестве учетной.
Учет ПАРТИОННЫЙ. Списание - по УЧЕТНЫМ ЦЕНАМ
Если в приходные накладные поменять ЦЕНЫ ПОСТАВЩИКА, то они не ложатся в качестве УЧЕТНОЙ цены.
И расчет себестоимости НЕ ИЗМЕНЯЕТ учетную цену (хотя я думал, что этого будет достаточно)
Я собираюсь сделать спецфункцию, которая должна изменить в SPR_PART цены CENA_P, CENA_F и др. для тех строк в MDOCM (для выделенных накладных прихода) где ЦЕНА ПОСТАВЩИКА не равна УЧЕТНОЙ ЦЕНЕ.
Но, возможно, кто то это сделал раньше - есть же производство у кого -то.
Или есть другой способ, без спецфункции?
ERROR: Не удалось получить монопольный доступ к файлу: Z:\Program Files\BEST\BEST5_34\Server\DATA\PRO\DIC\B5TABLES.DBF
ERROR: Ошибка открытия: DIC\B5TABLES
С 1 июля 2011 в Нижегородской и еще одной области стартовал пилотный проект ФСС. Речь идет о о том, что предприятия должны отправлять в ФСС заявления, реестры и описи, либо что то из них.
Подготовка этих документов - весьма объемная работа.
Уже появились программы, частично уменьшающие затраты на подготовку.
Но лучше бы все это формировать из БЭСТ
Хотелось бы знать, прорабатывалась ли разработчиками эта тема?
Cсылка на этот файл "tovar из PLGL11_07_13" - это папка TOVAR из архивной копии БД БЭСТ4+ СП 79. В эту папку я кладу файлы BOOK, sh_fact и s_kredit из рабочей БД . В этом случае книга формируется штатно
Недавно главбух попыталась напечатать КНИГУ ПОКУПОК. И там то же самое. Так же Excel (и ДОС и Блокнот) пытается создать колонок слишком многою........
Посылаю 2 архива "tovar из PLGL11" - это папка TOVAR из рабочей БД БЭСТ4+ СП 79. Здесь выходим на ошибку
"tovar из PLGL11_07_13" - это папка TOVAR из архивной копии БД БЭСТ4+ СП 79. В эту папку я кладу файлы BOOK, sh_fact и s_kredit из рабочей БД. В этом случае книга формируется штатно
Оказалось, что если в рабочую копию за апрель положить файлы book.dbf, book.cdx, book.fpt из текущей БД, то передача в Excel происходит нормально!!!!! Таким образом я распечатал КНИГУ ПРОДАЖ за апрель, май, июнь.
Нет, не стоит.
Но я уже понимаю, что сильно запортился файл book.fpt
Выдаче в DOS я рано радовался. Там формируется более 8000 !!! колонок, в том числе и нужные про 18% 10% 0? и еще 8400 колонок с 0%
Восстановил копию БД за апрель - там все в порядке.
Как отремонтировать book.fpt ? В book.dbf 67000 записей
Помогал бухгалтерам выдавать СЗВ 6 примерно в 30 организациях
Если кратко - то выдача в основном проходит штатно (90%).
Однако замечания на будущее есть.
1. Если в БД Зарплата один сотрудник увольнялся и потом его при приеме поставили на другой таб. номер, то БЭСТ его выгружает в СЗВ. Однако при импорте в СПУ ОРБ попадает справка только по одному таб. номеру. Было бы полезно при наличичии справок с одним СТРАХ.НОМЕРОМ суммировать взносы и объединять периоды стажа
2. Если в БД Зарплата у сотрудника есть начисления, но нет страхового номера, то такой сотрудник вообще не выгружается. Надо бы выгружать, подставляя несуществующий номер, типа ХХХ-ХХХХХХ ХХ. ОН выявится при приеме в СПУ ОРБ
3. БЭСТ4 (и 5) выгружает не всех, отфильтровывая, например, тех, у кого нет в табеле рабочих дней!!!! В то время как при формировании ГРУППОВОЙ СПРАВКИ по взносам во внебюджетные фонды - такие сотрудники выдаются. Таким образом, в БОЛЬШИХ ОРГАНИЗАЦИЯХ, приходится напрягаться, что бы найти ТЕХ, кто не попал в СЗВ, но есть в СПРАВКЕ. Важно, что в РСВ-1 также попадают все, у кого есть СТРАХ, ВЗНОСЫ!!!
Предложение - в СЗВ должны попадать все сотрудники, имеющие ВЗНОСЫ в отчетном периоде!!!! Желательно игнорировать и признак ИСКЛЮЧЕН. Так как в организациях с численностью более 300 человек текучесть большая и в исключенные попадают многие. Если включать их по ALT-F10, то с в ГРУППОВУЮ справку попадает многие с нулевыми взносами.
4. Для некоторых сотрудников, например, которые были ранее уволены, но получили выплаты в отчетном периоде, иногда наблюдается ошибка - не закрыт тэг \СТАЖЕВЫЙ ПЕРИОД. НАдо бы исправить, так как в больших фирмах приходится искать ошибку так. Сначала СПУ ОРБ ругается про ТЭГ (не по русски). Затем программа CheckXML указывает строку (line). Затем в Far находим строку, добавляем ТЭГ, опять проверяем CheckXML пока не выявим всех. Исправляем в FAR потому, что там присутствует НОМЕР СТРОКИ, в то время как в БЛОКНОТЕ номера строки не видно.
Наконец, принимаем в СПУ ОРБ. Где для обнаруженных работников удаляем совсем данные о стаже.
Короче - получается длинная процедура
5. Иногда возникает совсем не распознанная ситуация. А именно, если указываешь тип работников "НР", то выдаются СИЛЬНО меньше сотрудников и в АДВ 6 сумма начисленных взносов СИЛЬНО МЕНЬШЕ той, что в ГРУППОВОЙ справке.. При этом сумма УПЛАЧЕННЫХ ВЗНОСОВ - правильная!!!!!! Я обхожу эту ситуацию так. Вместо "НР" пишу, например, "SS". Тогда АДВ 6 и СЗВ по суммам ПОЛНОСТЬЮ правильные. Но, конечно, в СПУ ОРБ, в таком виде вообще ничего не попадет. Поэтому, при загрузке в СПУ ОРБ я запускаю БЛОКНОТ, и делаю замену "SS" на "НР". И потом правильно загружаю в СПУ ОРБ.
Все это обнаружено опытным путем при выгрузке СЗВ в разных организациях