Предишната тема :: Следващата тема |
Автор |
Съобщение |
forfavore
Регистриран на: 09 Мар 2018 Мнения: 16
|
Пуснато на: Пет Мар 09, 2018 18:47 Заглавие: Някои предложения за склад про |
|
|
Здравейте,
предполагам че все повече фирми имат взимане даване с фирми от ЕС и поради тази причина според мен би било хубаво да има възможност номенклатурите в Склад Про да се въвеждат на български и на ангглийски примерно, както има такава възможност в Инвойс про, и да има възможност за разпечатване на международна фактура, както е в Инвойс про.
Другото което е, имам въведени около 2000 номенклатури. Имам им въведени доставни, на дребно и на едро цени. Последно време започнахме да изнасяме стока към Гърция и изнесената стока я продаваме на по високи цени. Партньорите от Гърция ги вкарвам в ценова група 8. Имам екселска таблица с код на продукта и новата цена. С администриране -> импорт на номенклатури искам да импортна новите цени от екселската таблица в ценова група 8 но програмата ми иска и въведени наименования на номенклатурите. Според мен би било идеално да има възможност да се обновяват/добавят полета чрез екселска таблица и и баса само кода на продукта. |
|
Върнете се в началото |
|
 |
andrewa
Регистриран на: 01 Юли 2008 Мнения: 441 Местожителство: Пловдив
|
Пуснато на: Съб Мар 10, 2018 09:59 Заглавие: |
|
|
И аз ползвам често импорт на ценови групи и се чудя защо е необходимо освен код задължително да се задава и име на стока при положение че то може да не е нужно да се променя. Може би така се прави все пак някакъв контрол в прозореца за импорт преди да се потвърди операцията.
Не е голям проблем да се импортира с това ненужно ограничение: веднаж се прави експорт и върху тази подложка впоследствие всеки път се редактират ценови групи преди да се импортират промените в ЦГ заедно с код и наименование.
Но ако междувременно в СкладПро са нанесени промени в наименованието на някои стоки, след импорт от стара подложка тези промени се затриват.
Поддържам предложението за премахване на задължително указване на поле "Наименование на стока" при импорт със заместване по код. _________________ Технически консултации.
Експертът не мисли, той знае!
 |
|
Върнете се в началото |
|
 |
Виктор Павлов Microinvest

Регистриран на: 12 Авг 2002 Мнения: 21312
|
Пуснато на: Нед Мар 11, 2018 18:40 Заглавие: |
|
|
Това може да стане единствено, ако направим полето Код задължително и уникално, но вероятно много други клиенти ще пострадат. Полетата Код, Име и Баркод са ключ за намиране на стоката. _________________ Клиентите на Microinvest по света: http://www.microinside.ru |
|
Върнете се в началото |
|
 |
forfavore
Регистриран на: 09 Мар 2018 Мнения: 16
|
Пуснато на: Пон Мар 12, 2018 12:42 Заглавие: |
|
|
Виктор Павлов написа: | Това може да стане единствено, ако направим полето Код задължително и уникално, но вероятно много други клиенти ще пострадат. Полетата Код, Име и Баркод са ключ за намиране на стоката. |
Три полета за съответствие според мен да много, или поне трябва да има опция както е при избор Замяна, да може да се избере само код и на база код да се търси прилика. При необходимост, но не задължително да има възможност за избор на код, баркод и наименование.
Скоро може да ми се наложи да добавям и баркод за който предполагам пак ще имам само код и баркод.
Също така какво мислите за добавяне на допълнително поле за наименование на продукт на друг език, който да се разпечатва за издаване на международна фактура? В момента за тази работа ползвам инвойс про, където имам и въведени английски наименования, импортиране на документите, издаване на международна фактура. Би било добре, всичко това да се направи в склад про без необходимост от други приложения. |
|
Върнете се в началото |
|
 |
forfavore
Регистриран на: 09 Мар 2018 Мнения: 16
|
Пуснато на: Пет Мар 16, 2018 12:05 Заглавие: |
|
|
Ако е трудно с ъпдейт, има ли вариант да се работи върху базата директно с Access? |
|
Върнете се в началото |
|
 |
Виктор Павлов Microinvest

Регистриран на: 12 Авг 2002 Мнения: 21312
|
Пуснато на: Пет Мар 16, 2018 12:22 Заглавие: |
|
|
Опишете точно какво искате да направите, посочете стъпка по стъпка.
Опитите да изградите приложение за Access, вместо да направите правилен XLS файл е много лош вариант.
Като прочетох вашия първи пост аз виждам следните проблеми:
1. Не са поставени кодове на стоките. Поставете ги!
2. Няма или липсват баркодове на стоките. Поставете или генерирайте уникални баркодове;
3. Дори и да имате променени имена на стоките, направете експорта непосредствено преди промяната на цените, след това променете цените със средствата на Excel и направете импорт.
Всяка една от точките 1-3 решава въпроса, а ако ги направите и трите ще сте изключително стабилни при решаване на поставената задача. _________________ Клиентите на Microinvest по света: http://www.microinside.ru |
|
Върнете се в началото |
|
 |
forfavore
Регистриран на: 09 Мар 2018 Мнения: 16
|
Пуснато на: Пет Мар 16, 2018 17:34 Заглавие: |
|
|
Това с експорт към Ексел, обработка и импортиране ми е ясно.
Но проблемът ми е такъв че цените които искам да ги импортна в група 8 нямат определено аритметично правило и таблицата която имам с тези цени е с гръцки наименования. Единственото което ги обединява е кодът на продукта, така че няма как да импортна в Ексел, да пейстна стойностите и да кача обратно. Същият проблем ще имам и с баркодовете. Те ще са в таблица с английски наименования и единственото което ще ги свързва е кодът на артикулите.
Според мен, кодът на артикулите трябва да е фиксиран, както е в повечето софтуери и платформи за онлайн магазини. Или поне да има опция.
Нищо не казвате за второто предложение относно допълнителният език за наименованията на артикулите, предполагам добавянето на допълнително поле не би трябвало да е проблем. |
|
Върнете се в началото |
|
 |
Виктор Павлов Microinvest

Регистриран на: 12 Авг 2002 Мнения: 21312
|
Пуснато на: Пет Мар 16, 2018 20:03 Заглавие: |
|
|
Цитат: | предполагам добавянето на допълнително поле не би трябвало да е проблем. |
Това предположение не е вярно.
По предишното също не разбрах. Нали кодове съществуват, какъв е точно проблема да се синхронизира по код? _________________ Клиентите на Microinvest по света: http://www.microinside.ru |
|
Върнете се в началото |
|
 |
andrewa
Регистриран на: 01 Юли 2008 Мнения: 441 Местожителство: Пловдив
|
Пуснато на: Пет Мар 16, 2018 20:38 Заглавие: |
|
|
Ако правилно се досещам, проблемът с експорт/редакция/импорт е следния:
- в експортирания файл всяка стока има номер, БГ име и цени за съответната ЦГ. Примерно:
№ име ЦГ8
1 круши 3
2 ябълки 2
3 портокал 1
- корекцията на цените е зададена като друг файл с име на гръцки/английски или китайски. Примерно:
1 qwerty 2.5
3 ytrewq 5
Вероятно на не всички стоки се прави корекция в цената и затова във втория файл редовете не съвпадат с редовете на първия файл и не може да се копира цялата колона.
За да се нанесат автоматично корекциите на цените от файл 2 във файл 1, копирайте файл 2 като стр.2 във файл 1 и използвайте функциите на Excel да попълни нова колонка с цени само за тези редове, за които номер стока от стр.1 и стр.2 съвпадат. После с още едно сравнение в нова колонка ще се попълнят новата цена или старата цена, ако няма нова цена. И тази колонка се импортира в СкладПро заедно с номер стока, име стока и т.н.
Предварително се извинявам ако не съм разбрал правилно целта на занятието и обяснявам тривиални неща за Excel. Аз ползвам OpenOffice и синтаксиса на функциите е малко по-различен от Excel, затова не ги пиша. _________________ Технически консултации.
Експертът не мисли, той знае!
 |
|
Върнете се в началото |
|
 |
andrewa
Регистриран на: 01 Юли 2008 Мнения: 441 Местожителство: Пловдив
|
Пуснато на: Пет Мар 16, 2018 20:53 Заглавие: |
|
|
Виктор Павлов написа: | Цитат: | предполагам добавянето на допълнително поле не би трябвало да е проблем. |
Това предположение не е вярно. |
На чужд гръб тоягите не се броят!
Преди време предложих да се добави параметър "тегло" и "обем" за всяка стока за да се смята културно как ще се вози една продажба/доставка, за онлайн магазините с доставка по куриер това са просто задължителни неща.
Добавката и обработката на такива полета сигурно не е елементарна, защо едновременно с това не се помисли и за чуждоезично име? То може да се разположи в колонка Описание на стоката (който иска втори език - губи описанието) и само да се избира кое поле да се разпечатва. Не зная дали смяната на името на стоката е достатъчно да направи фактурата международна: трябва да се превежат и други неща, например мерна единица, или такива да се задават с латински букви защото в БГ сме умни и разбираме m2 kG pcs _________________ Технически консултации.
Експертът не мисли, той знае!
 |
|
Върнете се в началото |
|
 |
Виктор Павлов Microinvest

Регистриран на: 12 Авг 2002 Мнения: 21312
|
Пуснато на: Пет Мар 16, 2018 21:31 Заглавие: |
|
|
При първото описание на съпоставянето на 2-та файла има един въпрос - как се разбира кое от първия файл съответства на елемент от втория файл?
Добавянето на колони е сложно при съществуващи системи, а при системи с репликация SQL сървърите забраняват промяна на базата. Всичко трябва да се спре, да се конвертира и да се построи отново. А това трябва да е оправдано икономически. _________________ Клиентите на Microinvest по света: http://www.microinside.ru |
|
Върнете се в началото |
|
 |
forfavore
Регистриран на: 09 Мар 2018 Мнения: 16
|
Пуснато на: Пет Мар 16, 2018 22:44 Заглавие: |
|
|
Виктор Павлов написа: | При първото описание на съпоставянето на 2-та файла има един въпрос - как се разбира кое от първия файл съответства на елемент от втория файл?
|
Кодът на продукта. Предполагах че кодът на артикула в приложението е така нареченият SKU (stock keeping unit) който е уникален за всеки артикул.
Колегата от предишните коментари не е разбрал правилно. Точно това имах в предвид и предполагам че така с двете страници в един файл и съпоставка ще стане това което искам, само дето трябва да намеря как в Ексел да направя тази проверка и ако има стойност да го добави в съответното поле и след това обратно качване в склад про.
Идеята за обем и тежест е също добре дошла, като се има предвид че това е част цялата операция. Относно езика за фактура, направата на темплейта на друг език и избор преди принт ще е най лесно.
Лошото тъй е че за международни фактури трябва да ползвам инвойс про и там да дам вторият език което напразно утежнява процеса.
Според мен трябва сериозно да помислите за възможността за втори език, днешно време фирмите които имат взимане даване с чужди фирми е доста голям. Чудя се как се справят другите колеги които изнасят за чужбина. |
|
Върнете се в началото |
|
 |
andrewa
Регистриран на: 01 Юли 2008 Мнения: 441 Местожителство: Пловдив
|
Пуснато на: Съб Мар 17, 2018 14:31 Заглавие: |
|
|
Функцията на Open Office за копиране на съдържанието на клетка от друга страница при съвпъдък на съдържанието на клетки е:
=VLOOKUP($A5;$PAGE2.$A$4:$I$9000;4;0) - тази формула стои примерно в клетка Н5 на стр.1, размножена е в колона Н. В тази колона ще цъфнат променените цени.
$A5 е клетката, по чиято стойност се търси на стр.2. Колона А трябва да съдържа SKU на експорта от склад про.
PAGE2 е името на стр.2 във файла (тук се записва таблицата с SKU, име на стоката на чужд език и променените цени)
А4 - I9000 е областта от стр.2 в която се прави сравнение и от която се извличат данни (според областта която заема записът от предишното пояснение)
4 означава четвърта колонка от стр.2 - от клетката на съответния ред на тази колонка се дърпа стойността в стр.1 ако има съвпадение на SKU. В 4-та колонка на стр.2 трябва да са записани новите цени
Пример за функция за сравнение и попълване на дадена колонка със стойности при изпълнение на някакви условия:
=IF(((INDEX($F$4:$M$65007;;$T$3)-P5)*INDEX($F$1:$M$1;1;$T$3)-S5*E5)*S5>=0;" ";"НЯМА")
Вече не помня какво точно беше условието, в клетката в която е записана тази функция излиза число или текст НЯМА. Тази функция се размножава в колонката. В тази колонка ще се запише старата цена или новата цена ако има корекция. И тази колонка ще се импортира в СкладПро.
Синтаксисът в Excel е различен, но е сходен. Четете документацията му.
Добра практика е всяка стока да има складов номер (SKU). Не виждам лошо потребителят да се информира че това е задължително изискване за успешен импорт, ако поле Наименование на стока не присъства в импортирания файл и старото име не се затрупва с новото. Който не желае да въвежда SKU складови номера - да задава Наименование на стока. _________________ Технически консултации.
Експертът не мисли, той знае!
 |
|
Върнете се в началото |
|
 |
andrewa
Регистриран на: 01 Юли 2008 Мнения: 441 Местожителство: Пловдив
|
Пуснато на: Съб Мар 17, 2018 15:13 Заглавие: |
|
|
Виктор Павлов написа: |
Добавянето на колони е сложно при съществуващи системи, а при системи с репликация SQL сървърите забраняват промяна на базата. Всичко трябва да се спре, да се конвертира и да се построи отново. А това трябва да е оправдано икономически. |
Просто или сложно - не знам. Когато друг го върши за мен е просто
Относно репликацията - да разбирам ли че проблем би се появил при апгрейд на СкладПро и свързаните с това промени в базата данни? Това за M$ SQL ли се отнася? Защото за MySQL пишат че няма грижи да се добавят колонки в таблица в режим на репликация:
https://dba.stackexchange.com/questions/72442/how-to-safely-add-column-to-replicated-mysql-database
Ако има такова ограничение, не може ли да се заобиколи като по време на апгрейда се създаде нова таблица с разширена структура от колони и в нея се копират данните от старата таблица? Създаването на нова таблица също не пречи на репликацията (при MySQL):
https://dev.mysql.com/doc/mysql-replication-excerpt/5.5/en/replication-features-create-select.html В режим на репликация ROW никакви проблеми, а в режим STATEMENT - с определени уговорки.
Погледах моя my.cfg, пише binlog_format=ROW, т.е. няма проблем да добавям на мастъра таблици без ограничения в заявките. _________________ Технически консултации.
Експертът не мисли, той знае!
 |
|
Върнете се в началото |
|
 |
Виктор Павлов Microinvest

Регистриран на: 12 Авг 2002 Мнения: 21312
|
Пуснато на: Съб Мар 17, 2018 20:07 Заглавие: |
|
|
В указания файл има посочени реалните проблеми:
Regarding replication, ALTER TABLE will be transmitted through the replication process in a fully consistent manner. However, no writes to that table are sent to the slave (as they are not applied to the master) until the alter finishes. The table is not ALTERed and locked on the slave until then, when the alter will be applied. Replication will pause for that period (as replication is applied serially). Everything will be done consistently (as you shouldn't be doing out of band writes on the slave), but a lag equal to the time the alter takes to execute on the slave will occur.
От тук следва:
1. Ако се стартират 2 работни места (всяка едно вижда, че базата от данни е в стария формат и се опитва да конвертира данните), то конверсията ще се скапе;
2. В същата статия препоръчват да се използва ваншно решение - https://www.percona.com/doc/percona-toolkit/3.0/index.html
3. Написаното: Writes to that table, however, are blocked "Waiting for table metadata lock" and queued during the whole process означава, че SQL сървърът е блокиран в процеса на конверсия на данните, а понякога това е много време.
От документацията на MySQL: https://dev.mysql.com/doc/mysql-replication-excerpt/5.5/en/replication-features-create-select.html е още по-весело. Всяка версия работи по различен начин и най-готиното е това: "Nothing is inserted or logged.", значи нищо нито се случва, нито се появява съобщение. Въобще прекрасно - изпращате команда на сървъра и не знаете какво става, няма лесен начин да се разбере дали операцията е успешна или не. _________________ Клиентите на Microinvest по света: http://www.microinside.ru |
|
Върнете се в началото |
|
 |
|