paoloilling
Member
Good day everyone,
This is a call for all the users of dadabik 8.0.
I have a client, a furniture importer and retail store, who would like somehow to reduce the amount of work that is needed for determining the local prices.
All of the published price lists (mostly Italian) arrive either in paper format, or PDF or both.
There are probably 25 to 30 suppliers, each of whom has probably 50 to 100 products (average), each product with variation of colour, leather, fabric, dimensions, etc.
Currently the Italian catalogs are normalized and typed in a spreadsheet (developed in 1999 and still working!!!), because it is very difficult to extract data from PDF's. Once the spreadsheet determines the price for each item, the spreadsheet is massaged to produce an "internal price list" on paper.
I do not have a count, but I suspect we have probably 10000 items and prices. Maintenance of this is very time consuming, and error prone (as I explain below).
After this, a good portion of the same data is re-typed and re-entered in many places (at least 3 more):
- web site (Joomla + hikashop)
- Cut Sheet (this is a 1 page 2 sided print with colour photos of the item, dimensions, line drawings (picturing sofa without arm, with left arm, with right arm etc.) price (s) , fabric or leather categories (and relative prices) , etc. A cutsheet is always near or on the product, so that a customer can take it.
- Price Tags (or labels) size 4" by 2" (10 cm. x 5 cm) approx, attached to the item that is for sale, containing PRODUCT CODE, Description, Dimensions, etc. PRICE of the item ON THE FLOOR.
- When a customer buys, (sales order entry) the item sold, code, description and price, is typed in again to produce the invoice.
- Probably there is a fifth place where the data is re-entered that I do not know (proposals, etc)
So, my thought today is:
1) Attempt PDF extraction
2) Attempt extorting from each supplier a READ-ONLY view on their data base (the same one they use to produce and publish their PDF)
3) Store everything in a db. But the DB could also have graphics.
Three kinds of graphics are used: 1) line drawing (black and white), 2) Photos of the item (with web resolution often two sizes, small and full page), 3) Photos of the item (high resolution, usually provided by the manfacturer for advertising purposes (more than 1 graphic/picture for each item)
Here is my first call for help (we use postgresql)
Is it better to store the pictures in the db or is it preferable to store the path to the location of the image?
4) From the new db, writhe the necessary code and/or filters to interface with the existing software such as invoicing and price tags.
5) use Adobe Indesign for cut-sheets with template for reading postgres db.
6) Use DADABIK for an internal web site to quickly do searches and display any of the items, including pictures.
7) Create a global "update" for the prices of a supplier for the web site (note , NOT ALL THE ITEMS are on the web site)
So my second call for help is for your ideas and suggestions on point 6) . If you have already experienced this, and you have created some solutions (perhaps customizing DADABIK a bit), we are open to either purchase your solution, or hire you to direct us with the design, and to implement your solutions.
Thank you kindly.
This is a call for all the users of dadabik 8.0.
I have a client, a furniture importer and retail store, who would like somehow to reduce the amount of work that is needed for determining the local prices.
All of the published price lists (mostly Italian) arrive either in paper format, or PDF or both.
There are probably 25 to 30 suppliers, each of whom has probably 50 to 100 products (average), each product with variation of colour, leather, fabric, dimensions, etc.
Currently the Italian catalogs are normalized and typed in a spreadsheet (developed in 1999 and still working!!!), because it is very difficult to extract data from PDF's. Once the spreadsheet determines the price for each item, the spreadsheet is massaged to produce an "internal price list" on paper.
I do not have a count, but I suspect we have probably 10000 items and prices. Maintenance of this is very time consuming, and error prone (as I explain below).
After this, a good portion of the same data is re-typed and re-entered in many places (at least 3 more):
- web site (Joomla + hikashop)
- Cut Sheet (this is a 1 page 2 sided print with colour photos of the item, dimensions, line drawings (picturing sofa without arm, with left arm, with right arm etc.) price (s) , fabric or leather categories (and relative prices) , etc. A cutsheet is always near or on the product, so that a customer can take it.
- Price Tags (or labels) size 4" by 2" (10 cm. x 5 cm) approx, attached to the item that is for sale, containing PRODUCT CODE, Description, Dimensions, etc. PRICE of the item ON THE FLOOR.
- When a customer buys, (sales order entry) the item sold, code, description and price, is typed in again to produce the invoice.
- Probably there is a fifth place where the data is re-entered that I do not know (proposals, etc)
So, my thought today is:
1) Attempt PDF extraction
2) Attempt extorting from each supplier a READ-ONLY view on their data base (the same one they use to produce and publish their PDF)
3) Store everything in a db. But the DB could also have graphics.
Three kinds of graphics are used: 1) line drawing (black and white), 2) Photos of the item (with web resolution often two sizes, small and full page), 3) Photos of the item (high resolution, usually provided by the manfacturer for advertising purposes (more than 1 graphic/picture for each item)
Here is my first call for help (we use postgresql)
Is it better to store the pictures in the db or is it preferable to store the path to the location of the image?
4) From the new db, writhe the necessary code and/or filters to interface with the existing software such as invoicing and price tags.
5) use Adobe Indesign for cut-sheets with template for reading postgres db.
6) Use DADABIK for an internal web site to quickly do searches and display any of the items, including pictures.
7) Create a global "update" for the prices of a supplier for the web site (note , NOT ALL THE ITEMS are on the web site)
So my second call for help is for your ideas and suggestions on point 6) . If you have already experienced this, and you have created some solutions (perhaps customizing DADABIK a bit), we are open to either purchase your solution, or hire you to direct us with the design, and to implement your solutions.
Thank you kindly.