Галактика в вопросах и ответах

можно тем же форматом общаться напрямую.
Там просто свои навороты - типа подписи и так далее.
Закон на вскидку не помню - но он есть.

edward_K писал(а):можно тем же форматом общаться напрямую.
Там просто свои навороты - типа подписи и так далее.
Закон на вскидку не помню - но он есть.

Да, я посмотрел- это безбумажная технология. И чтобы её применять, надо наш каталог МЦ привести в соответствие с неким стандартом, так? А там ещё единицы измерения разные, коэффициенты пересчёта.. Это тоже в стандарте прописано?

Насколько помню , стандарт обмена не предусматривает какой то оптимизации наименований - это просто формат обмена и не более того.
Ну там есть заморочки с иностранными контрагентами и все - другая секция может быть по ним.
А уж как вы там себе его заберете это ваши проблемы.
Кстати - есть же еще варианты наименований МЦ - можно там хранить код контрагента.
В любом разе если вы не хотите клеить на товар свои ярлыки, вам нужно как то получать соответствие штрихкода и параметров МЦ от поставщика - так почему бы не получать сразу в документе? Тем более что всегда идет правило - лишнее можно, то что есть по закону убирать нельзя.
вот вам кусочек из накладной, аналогично есть и по СФ.

Спасибо, Эдвард. Ответы, как всегда- обстоятельно и в точку.
Рисуется такая схема автоматизации прихода МЦ от поставщиков для нашего случая:
1. Поставщики вместе с бумажным документом (это форма ТОРГ-12 или УПД- универсальный передаточный документ) как-то передают нам электронный файл (Excel, Word, txt), который помещается в папку, скажем, Input.
2. Периодически запускается некая процедура, которая сканирует папку Input, читает файл и парсит его- определяет его структуру, идентифицирует поставщика. Это понятно.
3. Самое интересное- чтение спецификации. Здесь определяется наименование МЦ, которое может отличаться от наименования в каталоге МЦ. Сопоставление с записью каталога МЦ производится по внешнему аттрибуту к записи. Мыслится сие так: наименование внешнего аттрибута = наименованию организации (attrnam.name = katorg.name), а значение внешнего аттрибута = наименованию МЦ из файла. Естесственно, эти внешние аттрибуты к каталогу МЦ должны быть предварительно заполнены. Как- отдельная тема. Не вручную, стандартные интерфейсы не годятся. Для каждой МЦ должно быть внешних аттрибутов по числу поставщиков.
4.Дальше- дело техники. Из п.2 и п.3 лепится katsopr + spsopr+spdocnal... Накладная есть, осталось найти соответствующее ДО, связать и выдать протокол. Обработанный файл перекладываем в папку, скажем, Output
5.Если файл обработался с ошибкой- перекладываем в другую папку, чтобы обработать как-то полуавтоматизировано, с участием пользователя. Пока неясно.

Как?

1. Да. Как вариант это может быть например парсинг некого почтового ящика или ручное подкладывание, но для ручного уже проще руками и обработать
Word хуже всего - на него лучше не соглашайтесь.
2.Делает лог файл и складывает его в подпапку _log .
3. ВА плохо. Если есть возможность лучше создать табличку(я в сапорт- SQL создаю, а вот drop пашет только в "компиляторе").
Индекса нет там подходящего с vString. Есть еще пользовательская аналитика, но опять же ее придется привязывать через ВА к МЦ.
варианты наименований все таки рассмотрите. Сие и в фейсах выбора может светиться.
5. сам файл при успехе помещается в папку Arhiv, при неуспехе в Err(можно туда же и протокол ошибок сложить). По идее обработчик должен быть один и тот де, только при запуске в ручном режиме предлагать выбор варианта решения, а при автоматическом писать в лог. И опять же в ручном сделать выбор файлв, в автоматическом сканировать все файлы в папке Inpit.
+6 опция. При приходе товара кладовщик проходит со сканером и подтверждает кол-во в уже существующей накладной.
Интересно как база устроена в магазинах - они же со штирхкодам поставщика работают.
В штатной галке тоже есть розница, и там штрихкодирование встроено, но определенного оборудования.

Ок, будем думать..