Форум OlegON > Программы и оборудование для автоматизации торговли > Системы автоматизации торговли > КИС Lack & УС Land

Для производителей и оптовиков. EDI при отгрузке товаров покупателям - серьёзным торговым сетям

14.08.2020 23:54


16.02.2020 11:55
AndreyZh
 
Хотите работать с большой тройкой: АО Тандер, юридические лица Х5, ООО Лента?


Минимальное требование для этого - полный документооборот с данными торговыми сетями по EDI! Минимальный комплект электронных документов в обороте:

order - заказ торговой точки покупателя, который вы принимаете и на его основе оформляется расходные операции в вашей УС;

ordrsp - подтверждение приёма заказа, отправляемое покупателя в случае, если вы готовы отгрузить конкретный заказ;

desadv - уведомление об отгрузке, отправляемое в "момент отправки" груза в торговую точку покупателя с указанием расхождений относительно заказа;

recadv - уведомление покупателя о приёмке груза с указанием фактически принятого товара;

УПД - юридически значимый электронный документ, формируемый на основе данных предыдущего обмена цепочкой "заказ - уведомление о приёме", отправляемый получателю.


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

GLN - глобальный идентификатор юридического лица и/или торговой точки;
GTIN - глобальный код товара;
Идентификатор вашего провайдера и юридичсекого лица покупателя - 3х значный код провайдера.

В случае небольшого числа отгрузок (до 20 в сутки) вполне можно работать через Web интерфейс, предоставляемый каждым провайдером... и понятно, что у каждого провайдера он уникальный, а иначе вам придётся задуматься об автоматизированной системе электронного документооборота.

Автоматизированная система EDI - это очень дорогое "удовольствие" (из тех которые пришлось изучать у конкретных ЮЛ: от 1.5 до 8 млн. рублей), которая долго внедряется, если можно данный процесс когда-либо закончить (от 8 месяцев до 3 лет). У меня старт работ начался в июне 2019, а сейчас, с декабря 2019, продолжается лишь опытно-промышленная эксплуатация по всей цепочки документов EDI, с периодическими доработками под всплывающие нюансы и новые торговые сети со своими особенностями.

Однако стоимость АСУ ничтожна в сравнении с затратами на сам процесс обмена! Конечно всё зависит от умения договариваться, условий провайдера, количества торговых точек для отгрузки, но ориетировочно можно считать 3 руб. за документ, т.е. при небольшом объеме 10.000 отгрузок в год = от 100.000 в год... и наличие быстрого интернета и мощных рабочих компьютеров, грамотных пользователей, способных адекватно реагировать на постоянные проблемки.


... ну а дальше, если тема будет интересна, то она будет продолжена описанием конкретных деталей, нюансов торговых сетей и провайдеров ...

Правка: AndreyZh, 16.02.2020 11:58
24.02.2020 09:33
AndreyZh
 
Пока очередная команда «одинэсников» пыталась решить задачу комплексной интеграции в EID в 2016 году объем заказов в виде XML файлов стал очень большим и мне была поставлена задача – хотя бы сделать закачку заказов в учетную системы, что бы операторам не было необходимости читать данный формат и переносить данные из него руками. К данному времени уже на «УСЕга» нацчился читать и разбирать данные файлы, т.ч. взялся за данную задачу и к марту 2016 она была в начальном виде сделана.

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

Для создания заказов в УС нужно много меньше, чем для полной системы, по этому можно данное сообщение пропустить и вернуться к нему позже… Конечно форматы заказов от разных провайдеров различаются, однако у всех изучаемых необходимый набор тегов был идентичный, а используемый мной принцип потокового парсинга файла позволил «избежать» нюансов различия форматов. Для УС был необходим набор тегов – параметров заказа:
Код:
DOCUMENTNAME		Вид документа
NUMBER			Номер заказа – важный везде атрибут и его, как и даты желательно сохранять в отдельных полях УС
DATE			Дата заказа
DELIVERYDATE		Дата доставки
DELIVERYTIME		Время доставки. Может отсутствовать. Для ООО Лента используется в уведомлениях об отгрузке.
SUPPLIER		Продавец – наше предприятие
BUYER			Покупатель - GLN клиента, юридического лица
DELIVERYPLACE		GLN адреса доставки
POSITIONNUMBER		Номер позиции – обязателен в отправляемых документах
PRODUCT			GTIN продукта
ORDEREDQUANTITY		Заказываемое количество
ORDERPRICE		Цена без НДС
Далее сопоставляя с атрибутами учетной системы можно создавать «полные» расходные документы прописывая атрибуты непосредственно в БД УС.

Встречаемые нюансы:

- На начальном этапе у некоторых покупателях в заказах были перепутаны тэги поставщика и получателя. У меня в программе смотрю в каком теге есть наш GLN и тогда определяю атрибуты из соответсвующих тегах не обращая внимание на «стандарты»;

- Дата для отгрузки. Было всё и постоянно меняются «правила», а по этому параметр регулируется настройкой. Варианты:

А – неотрицательное число: текущая дата плюс указанное число дней.
Б – (-1) беру равное дате заказа.
В – (-2) беру равное дате доставки.

- У ряда покупателей PRODUCT не соответствует стандартизированному коду, используемому нами. В случае, когда его нет в нашей БД можно задать таблицу преобразования «кривых» кодов, по которой неверный код для юридического лица преобразуется к «правильному»
- Сети работаю по утвержденной «матрице», но зачастую мы больше не предлагаем товары, они выведены из «матрицы», а некоторые торговые точки продолжают присылать, выведенные из оборота GTIN. Есть настройка «отбраковки» кодов, когда программа приёма заказов их просто игнорирует, а не анализирует на «существование».

Нельзя от операторов требовать телепатических навыков, т.е. все этапы приемки заказов должны журналироваться с подробных описанием причин отказа во внесении заказа и способам исправления ошибки, а так же иметь легкий способ, после исправления его подробно принять. Документы «кидаются» в текущий каталог. У « меня» во всех подсистемах EDI принят подход: «отбракованные» заказы/операции сохраняются в подпапке err, а обработанные в ok, т.е. после исправления в УС заказ можно вернуть в рабочий каталог.

P.S. Есть и используются программы от 2011, 2012 года закачки заказов из электронных таблиц: (а), где по пачке магазинов заказы в одном файле (АО Тандер) и (б) каждый магазин делает заказ в отдельном файле. Программа имеют внешние средства настройки схемы «чтения» таких XLS(X) файлов. Так же есть программа автоматизированного внесения в УС возвратов от покупателей – desadv, сделанная в 2017 году, но сейчас, после запретов возвратов от сетей она не используются.

P.P.S. Позднее опишу уже «новую» универсальную комплексную систему документооборота по EDI, создаваемую мной в 2019-2020, которая уже не зависит от используемой учетной системы… и нюансы провайдеров, сетей, документооборота.
01.04.2020 10:10
AndreyZh
 
У всех провайдеров разные требования и рекомендации к процедуре обмена! Так получилось, что пришлось «подстраиваться» под все и программа интеграции работает так – если есть доступ к нужному каталогу ftp сервера, то программа «просто» переносит из него / в него файлы локального каталога, а на следующих этапах читает или пишет только в локальные папки, т.е. эти процессы независимы:

1. Обмен осуществляется программами провайдера;
2. Обмен возможен любой программой, удовлетворяющей набору требований;
3. Желательно, что бы процесс обмена делался из программы интеграции.

Кроме того у разных провайдеров разные процедуры «манипуляции» с ХМЛ файлами их сервера, например у кого-то считываемые файлы папки inbox, а имена папок у всех разные, что «регулируются» настройками, необходимо перенести в архивный каталог archive, а затем удалить из inbox. Программа эти требования обрабатывает, анализируя наличие или отсутствие к папкам сервера разного назначения.





В результате опыта и многочисленных переделок программы интеграции определился список обязательных атрибутов сохраняемых программой интеграции в своей БД, которые необходимы для своих учетных систем или для формирования файлов обмена. Многие из атрибутов «необязательные», но требуемые некоторыми сетями. В описаниях правил обмена у разных провайдеров имена тегов и требования по ним могут различаться, что в программе интеграции регулируется настройкой «под провайдера». В «стандартах» провайдеров их сотни, но реально используются мной и достаточно для отгрузки не маркируемых товаров. Опишу их:

Обязательно сохраняю из заказов orders, но не все нужны для УС, а требуются при создании исходящих документов. Ниже дано описание атрибутов, разбитых по блокам с минимальными требованиями по их форматам:
Код:
o_numb	    C 35    Номер заказа по EDI - уникальный идентификатор   
o_dat	    D	    Дата заказа по EDI. Ключ
o_devid     D	    Дата поставки по заказу. Нужна всегда
o_devti     C 8	    Время поставки по заказу. Обязательно Лента.      
o_buyer	    C 13    GLN КА. Покупателя
o_place	    C 13    GLN АДРЕСА ДОСТАВКИ. Ключ
o_gtin 	    C 14    GTIN. Может быть 8,10,13,14 знаков
qtyOld	    N 7	    Номер позиции в заказе. Ключ второго индекса                
o_qty	    N12,3   Количество по заказу. Возможна резка и удаление позиции
o_sales     N10,2   Цена в заказе с НДС
o_id	    C 16    Внутренний номер позиции у покупателя. Нужно для подтверждения
o_unit	    C 3	    Код единицы измерения
o_lessnds   N10,2   Цена в заказе без НДС. Для ТС обязательный атрибут
o_desc	    C 70    Наименование товара у покупателя
o_nds	    N2	    Ставка НДС
Атрибуты подтверждения заказа ordrsp, выгружаемые из учетной системы обязательно сохраняю в БД, т.к. они нужны будут для всех последующих исходящих документов. Трактовка данных атрибутов незначительно различается у разных провайдеров:
Код:
p_numb	    C 19    Номер подтверждения в УС
p_dat	    D	    Дата подтверждения
p_sales	    N10,2   Цена с НДС в моих документах
p_tip	    C 1	    Кол-во 1-по заказу, 2-изменено кол-во, 3-отказ в поставке
qtyPak	    N12,3   Фасовка товара. Нужно для уведомления отгрузки Лента
codMin	    C4	    Мой системный код номенклатуры
p_qty	    N12,3   Поставляемое количество
p_send	    L	    Признак выгрузки подтверждения в EDI
У «меня» номер, дата, количество, цена в подтверждении заказа, уведомления об отгрузке desadv, которое посылается сразу после подтверждения заказа и в УПД совпадают, а по этому атрибуты «подтверждения» беру и для «уведомления». Далее обрабатываю входящие recadv - уведомление покупателя о приёмке груза с указанием фактически принятого товара, которые нужны для контроля фактически принятого товара в УС и формирования УПД. Сохраняю информацию в БД программы интеграции:
Код:
i_inp	    L	    Признак, что подтверждение отгрузки обработано по всем записям
i_qty	    N12,3   Подтвержденное покупателем количество
i_numb	    C 16    Номер подтверждения от покупателя
i_dat	    D	    Дата подтверждения
i_enddat    D	    Дата фактической приемки товара. Для разборок в будущем
Наконец, по данным из УС, выгруженным в программу интеграции, данным предыдущим документам проведения заказов формируется УПД по жестким требованиям ФНС, описанным в отдельной инструкции, идентичным для всех провайдеров. Однако число, порядок и набор «дополнительных» атрибутов УПД существенно различается для разных сетей, но все необходимое есть в УС и БД программы интеграции. Заполняется единственный атрибут:
Код:
u_send      L	Признак отсылки УПД на FTP провайдера
На настоящий момент, отчасти в силу дороговизны программа интеграции не формирует электронную подпись для УПД, а по технологиям всех провайдеров такие УПД попадают в «черновики» на платформе, где их «пачкой» можно сразу подписать и отправить, тем более, что по срокам и порядке отправки УПД требования у всех торговых сетей разные.

Правка: AndreyZh, 01.04.2020 11:59
05.05.2020 08:45
AndreyZh
 
Уф наконец нашел "где собака зарыта"... и это дало повод для сообщения

Одними из серьёзных проблем промышленной эксплуатации системы EDI является - покупатели косячат, "они большие - им всё можно", а страдают поставщики... ну и разработчик, на которого все валят Приведу ряд примеров:

1. Самый свежий. На новый товар матрицы покупателям дают новый GTIN, который внесен в "мировой реестр" и базы провайдеров, но по какой-то причине покупатель в своей БД вводит некий другой, а то и липовый GTIN и по нему начинает присылать заказы. Проблема старая - имеется таблица преобразования кривых GTIN, через которую проходят заказы и в обратную сторону преобразуются GTIN в исходящих документах...

Оказывается, без предупреждения, через 7 месяцев покупатель у себя в БД может проставить правильный GTIN, что сейчас наложилось с новым товаром и новым косяком по GTIN… При этом таблица преобразования для него "отключалась" при приеме заказа, но проходило неверное обратное преобразование. Структура таблицы со свежими комментариями для операторов:
Цитата:
Схема для преобразования кривых GTIN у клиентов. Через запятую в отдельных строках отражаются GLN клиента/GTIN у него/GTIN по БД LeraData. Нет 3 запятых - строка игнор
05.05.2020... Если хотя бы для одной строке по gln будет gtin2 из УС (БД LeraData), то бракуется вся таблица при загрузке из Lera и будет обратное неверное преобразование при выгрузке в программе Lera_edi

Первая строка - по ней стали использовать правильный
460******9995-4607124662150-4607124662228
Новая "кривая" у покупателя позиция
460*******995,4607124662181,4607124662020
****ер, а этот так и не исправил в течении 2 лет - у них другой товар под этим кодом
46*********95,4607124662181,4607124662020

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

2. Версия 14.02.2020г. При переходе на новый формат УПД, требования к форматам УПД у **** резко стали отличаться от остальных ТС. Сделана отдельная ветка построения файлов УПД для ****ы на основе образца УПД, создаваемого на платформе *****.

3. Версия 05.03.2020г. Подстройка нюансов, выявленных при реальной эксплуатации - от отдельных магазинов приходили "глупые" количества, по ним разбирались с менеджерами, исправляли, но часть исходящих документов уже отправлялось в EDI:

«Неверная» выгрузка фактического количество заказа в УПД. Раньше программа брала количество из «подтверждения заказа», а если оно не отсылалось, то фактическое количество из предзаказа. Что порождало «непонятки»: приняли заказ, отправили подтверждение, изменили количество, отправили УПД, а в УПД выгрузилось не измененное количество.

Сейчас. Программа в УПД всегда передаёт количество из предзаказа, но если подтвержденное количество не равно этому, то выдаётся сообщение об ошибке в логах по УПД в каталоге log.

 Довольно большой процент УПД бракуется покупателем, если для него назначены «некорректные» цены, а он ведёт учет от «цены без НДС», например ему отгружают по 46.95, а он, округляя до 2 знаков учет ведёт от 39.13 (цена без НДС).

Сейчас. В настройке программы можно задавать точность расчетов и отражения цен в УПД. Кроме того все «суммы», на всех этапах отражения подгоняются под точное соответствие: Цена/сумма без НДС + НДС = Цене/сумме с НДС с точностью указанной в настойке программы.

Например, для «нашей» цены с НДС = 46.95 и точностью в настройке 4 знака и количеству 3 единицы будет: Цена без НДС = 39.1250, НДС = 7.8250, цена с НДС = 46.9500 Сумма без НДС = 117.3750, НДС = 23.4750, сумма с НДС = 140.8500

 Перевыгрузка документов в EDI. При ошибочной выгрузке документов любого типа – подтверждение, уведомление об отгрузке, УПД программа не даёт повторно выгрузить документы в EDI. Сейчас это можно исправить – в новом режиме «Предзаказы / группы / Выгрузка заказов в EDI - чистить признак отсылки». Программа создаёт файлы DLT*.DLT, которые обрабатываются программой и по заказам из него удаляются все атрибуты «отсылки» всех видов документов. После обработки можно заново выгрузить, НО ВСЕ ВИДЫ документов, т.к., например, для выгрузки УПД нужно выгруженное подтверждение заказа.

4. Версия 26.03.2020г. По вопросам *****, только для **** должна быть точность в УПД обязательно равная 2 знакам, а для любых других ТС она определяется в настройке программы. Это актуально для Х5, где цены ведутся без НДС. Для **** настройка всегда назначается 2 знака.

5. Версия 21.04.2020г.
Цены в УПД берутся из заказов учетной системы, а не заказов покупателей. В случае их расхождения даётся сообщение в фале логов. Косяки покупателей при проведении акций...
28.07.2020 10:09
AndreyZh
 
Создание программ интеграции с EDI, как впрочем любого приложения для бизнеса – это процесс не имеющий даты завершения. Начиная автоматизацию нужно это помнить и смириться с потерями времени и денег, в том числе на оплату ненужной работы. Как пример приведу «процесс» решения одной из множества «дополнительных» небольших задач в рамках интеграции с EDI в течении времени и комментариями. «Главным» является провайдер, т.к. только он владеет своими алгоритмами взаимодействия с клиентами. Приведу почтовую переписку.

Цитата:
4 февраля, 10:56 … Однако накопилось несколько непонятных проблем, которые необходимо разрешить:
2. Очень много УПД, в большинстве Х5, в том числе делаемые в Web бракуются получателем по несостыковки по суммам без НДС и НДС… Исходная причина понятна - округление при расчете сумм, например цена с НДС - 10.0руб, НДС - 1.66666666, без НДС - 8.333333 при округление до 1.67/8.33 могут давать расхождение с другими алгоритмами расчетов. От сюда вопросы/просьбы:
а. Может быть можно в УПД цены и суммы задавать не с 2, а большей точностью, например 43.98754, если да, то с какой
б. Почти все УПД с Web принимаются получателем без ошибок. Можете дать алгоритм подгона цен/сумм для начала по Х5?
Цитата:
5 февраля, 12:55 По второму вопросу, Вы можете добавить необходимое количество знаков после запятой, но сделать это нужно будет как в цене так и в суммах. Связано это действительно с округлением. Торговая сеть Х5 работает по прямому методу расчета. Можно так же проверить в 1с какой метод расчета стоит и дальше отталкиваясь от метода добавлять необходимое количество цифр.
Цитата:
5 февраля, 13:31 б. С округлениями и дробной частью понятно и это снимет 90% проблем — спасибо! Однако по методам расчетов — у нас нет «1С», а даже если бы и была — это «внутренние алгоритмы»… В то же время «платформа», как-то подгоняет «цифры» под требования Х5 и вам эти алгоритмы известны. Прошу дать вашу методику для подгон цен и сумм для торговой сети Х5?
Цитата:
5 февраля, 14:45 По поводу методики. Методики как таковой нет. Все зависит только от метода расчета и округления.
Необходимо было решать более срочные задачи EDI, а посему по округлениям притормозил:

Цитата:
6 марта, 9:53 Переделал программу интеграции под ваше допущение «Вы можете добавить необходимое количество знаков после запятой, но сделать это нужно будет как в цене так и в суммах»… При попытке отправить УПД с 4 знаками в ценах и суммах оно перешло в папку error — приложен файл, откатил программу и отправил, как раньше с 2 знаками — УПД попало на платформу… Почему?
1. Ваша рекомендация ошибочна? Тогда — как выкручиваться с проблемами округления? Всё таки дайте алгоритмы подгона цен и сумм для сетей
2. У «меня» в УПД есть какие-то другие ошибки… и по этому файл был забракован?
Уже потребовалось несколько звонков в техподдержку и менеджеру, что бы дали ответ…

Цитата:
13 марта, 16:31 Согласно требованиям торговой сети Лента от 01.08.2019г, цена в УПД нового формата принимается на их стороне, только с двумя знаками после запятой. Цена товара [ЦенаТов] Если один товар присутствует в нескольких позициях УПД, проверяется, что все эти позиции имеют одинаковую цену. Цены должны округляться до целой копейки (не допускается дробное количество копеек). Цены проверяются на соответствие заказу на поставку. По товарам из соответствующих категорий (алкоголь, табак) выполняется проверка на соответствие цены и МЗЦ, МРЦ.
Цитата:
13 марта, 18:21 Добрый вечер! Только сегодня увидел ваш ответ, т.к. вы его отослали не адресату вопроса. Позвольте уточнить? Требование округления только до копейки относится ко ВСЕМ торговым сетям, с которыми работает … или только к ООО Лента
Опять пинание ТП и менеджера..
Цитата:
17 марта, 17:08 Данное требование относится только к ТС ООО "Лента"
Очередная пауза – уже из-за меня… Море других задач, а описываемая была неактуальной. Кроме того серьёзно изменил алгоритмы настройки цен

Цитата:
14 июня, 10:29 Добрый день уважаемые специалисты!
Вынужден возвратиться к «старому» вопросу суть, которого в переписке ниже — возможность задания точности цен и сумм в УПД. В начале вас спросил — вы ответили, что допустима любая точность, но она должна быть единой для цен и сумм… Сделал в настройке задание точности от 0 до 9 знаков. Приведу пример «отказанного» УПД:
Затем отправили УПД с точностью 4 знака и для ООО Лента УПД было забраковано, т.к. «неправильный значения». Отправил вам вопрос и вы ответили (см. ниже), что ТОЛЬКО для Ленты нужна точность 2 знака, а для других «произвольная»…. Опять переделал программу.
При попытке отправить УПД для Ленты 2 знака, для остальных 4 знака. ООО Лента прошла, а по Тандеру снова пришел отказ по точности… на чём временно были прекращены попытки решить с вами эту проблему
Проблема осталась! Ответьте пожалуйста чётко и определенно, как могу работать с точностью в УПД для различных контрагентов?
После очередного цикла пинания – задача снова стала весьма актуальной
Цитата:
22 июня, 10:30 ТС X5 Retail Group и ГУЛЛИВЕР работают по прямому методу расчета и допустимо 4 знака после запятой. ТС МАГНИТ, Лента и Тамерлан работают по обратному методу расчета и допустимо 2 знака после запятой.
прямой метод:
Цена без НДС х Кол-во х ставку НДС = сумма с НДС Пример: 500 x 2 x 0,2 = 1200 - сумма с НДС

обратный метод: 1. Cумма с НДС\(1+ставка НДС) = сумма без НДС
2. Сумма без НДС х ставка НДС = Сумма НДС

Пример: 1. 1000 \ 1,2 = 833,33 - сумма без НДС
2. 833,33 х 0,2 - 166,67 - Сумма НДС. Данная информация есть в общедоступных источниках.
Очередная переделка программы. На этот раз сделал настройку точности для каждой сети. За проект мне оплатили… и такие косяки уже стали вызывать раздражение заказчика, чем и связано моё раздражение… В принципе уже давно просил дать официальный ответ, что возможна лишь точность 2 знака, что бы «отвязаться» от этой проблемы и «народ» ставил «правильные» цены через программу: https://olegon.ru/showpost.php?p=346316&postcount=33 Послал письмо только менеджеру, что бы «не обидеть» «тонкую душу» специалистов:

Цитата:
3 июля, 12:17 Что специалисты плохо разбираются или я чего-то не понимаю? Цитата из ответа «ТС X5 Retail Group и ГУЛЛИВЕР работают по прямому методу расчета и допустимо 4 знака после запятой». В очередной раз переделал программу и опять отказ по точности. Сделав 2 знака приложенные документы ушли. Прикладываю файлы из каталога error
Цитата:
6 июля, 13:44 Данные предоставленные Вам в соответствии с спецификацией торговых сетей.
Типа «пошел на…» - пришлось снова долбить менеджера, что бы дали однозначный ответ

Цитата:
6 июля, 14:42 Изумительный и конкретный ответ на вопрос =) Вам приложил файлы (УПД для Х5) из папки error сервера LeraData, т.е. забракованные платформой по некой причине, надеясь на совет — что у меня неверно, а Вы ссылаетесь на некую «закрытую» для меня спецификацию ТС. Будьте добры дать ответ о причине отправки файлов в error?
После прямого обращения к руководителю отдела разработки провайдера от лично его пришел ответ «закрывающий» тему, но времени потеряно почти в пустую очень много

Цитата:
8 июля, 20:29 Прошу прошения за изначально не верно отправленную Вам информацию. Выяснили, что обновилась спецификация, нас к сожалению разработчики не предупредили, но мы рады что у вам удалось самостоятельно доработать документы. Верное количество знаков после запятой для основных ТС (х5, Лента, Гулливер, Магнит) до 2х. Цены должны округляться до целой копейки (не допускается дробное количество копеек). Доработку Вы выполнили верную, сейчас Ваши документы обрабатываются корректно.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.