Jump to content


  • Posts

  • Joined

  • Last visited

1 Follower

Profile Information

  • Activity

Brazzan's Achievements


Newbie (1/14)



  1. Wanted to add another wish, a very small one. In discounts, when you want to add a gift if x is in the cart. Place an option that let you decide how many gifts to be added Add [1] of this product (input field) Add the same quantity of gifts as the quantity of the product that triggers the gift /Peace
  2. My suggestions mostly involve B2B-mode. So, here we go Customer number For some businesses the id_customer might work as a customer number. But for most, it won't. Most of us have a business system behind the scenes (SAP, Visma, Navision etc) where customer information is stores, amongst other things. Those customer numbers are the ones we tend to want to use. When a new customer account is created via the shop, it's also created in the business system and the customer id is returned. This way there are no collitions, and every customer follows the same customer number standard. No matter if the customer is created by hand (email/phone orders) or automatically (via the shop). We implemented a field for this on the customer card in Prestashop ourself. The integration part is up to everyone to figure out themselfs. One account, multiple contacts More often then not in a B2B-shop, there is a need for multiple "contacts" under one customer account, and where every contact has their own login credentials. In our case we have big businesses that have businesses in multiple geografical areas, but collectivly one customer number. Each area has their own "buyers" that decide what to buy and when. The customer as a whole has some discounts, so to create multiple (sometimes up to 50) separate accounts, and manage certain discounts for these, would be an administrative nightmare. We solved this by having one customer account, and then develop a module that could handle multiple contacts, all with different logins. We managed to build this and keep all the login functionality as it is, with forgot password and everything. All these contacts order under the same customer number, with the same discount, and same company details. But we have multiple addresses for the contacts to choose from. This would be a fairly easy thing to implement as a standard if B2B mode is activated I believe. If B2B activated - classify addresses When we solved the above point, we also implemented a classification of the addresses connected to the customer. Addresses are classified as invoice or delivery. Most of our customers that have the need for multiple contacts also have the need for multiple delivery adresses, but only one invoice address. SIRET - make it a general business identification number Siret is the french version of a business identification number. This number has a validation function connected to it, which basically meens that most other identification numbers won't be validated. We removed this validation and called it Organisation number instead. It would be better to make this a general text field with no validation. If you want to get more advanced, build a setting that allowes us to decide the validation ourselfs (much like how you validate zip codes). Prices - pricelists Every other B2B business uses pricelists in their business system. A big customer often make a deal with the supplier (us) for better prices. These prices exist in a separate pricelist that's connected to that customer or customer group in the business system. To be albe to solve this, we used a combination of specific prices and customer groups in prestashop. It works, but it's not managable on a larger scale. Limited import funcitonality, specific price not editable etc. We manage this with our own developed scripts outside of prestashop, that talks purely to the database. Macros in text In some of the other e-commerce platforms I've worked with there is the option to use macros in the product description, meta-description, meta-title etc. That way, the texts can be created dynamically and alter depending on the base information. For instance, if I where to use the product name in the description text I could do something like this: "[:name:] is an awesome product." [:name:] fetches the product name. If the product name is changed, the description is changed. If you've read this far, hurray
  3. Update The part with to many redirects I'm guessing has to do with out 404-page not working. So I think that something on the category pages can't be loaded, and it tries to redirect to 404.. wich does not work, and it tries again with a / on the end, and that does not work.. and around we go. So there is probably two problems if I'm not mistaking. It tries to load a "none" url... example.com/category/none... then example.com/category/none/ then the 404, and then again the 404 with /. I have no idea where to start looking :/
  4. Hi, I have a annoying problem on our category pages (only category pages). net::ERR_TO_MANY_REDIRECTS. From what I can see, it's only related to when you stand on category pages. And I think the problem starts with it tryng to go to "http://www.example.com/category/none" which fails, and it tries to go to 404, but that fails... it tries to add / at the end, but that fails.. and around we go. Now, the page content loads just fine.. visualy everything works. Check the image I've attached for more info. Red = category Black = domain "sidan-kunde-inte-hittas" = page could not be found (404) I use Prestashop 1.6, block categories and Advance URL Module (I tried without advance url module, still the same). I have tried regenerate the htaccess, but still the same. I also noticed that our 404-page have stopped working for some reason. Any ideas?
  5. But it does not seem to work if you change global settings. In other words, there is no 301 if you in the Preferences->SEO & URLs change the delimiter for example. Route to product Before: {category:/}{rewrite}-{id}.html After: {category:/}{rewrite}_{id}.html
  6. The job has been filled. Thank you all for shown interest!
  7. We are a pure B2B company who are planning to start using Prestashop as our new ecommerce platform. The standard functionality regarding the customer structure in Prestashop does not meet our own customer structure though. We are hoping to find someone who can develope a module for this. Our customer structure looks like this: Company (customer number 123) - Contact 1 - Contact 2 - Contact 3 We need the ability to have multiple logins for one customer, that can shop as if it's the main customer (meaning all specific prices and so on are still in effect). The contact who made the order also needs to be connected to the order. This also meens that in front office->order history, we need to display all the orders connected to the customer number, and which contact who did the order. There also needs to be a way to add more contacts in front office, but restricted to a main user. We are hoping to find a serious and experienced developer to discuss this with, and hopefully work with in this project. When the specifications of the project is clear to all involved, we will need a price to be set by the developer. If we agree on that price, then it's time to rock
  8. We are trying something right now, should work in theory. The hard thing to know as a novice prestashop developer, is if this is a good idea in the first place. We are overriding all the nessecary files to not mess up the core. - Creating new field for the customer (customer id) - Creating same field for orders - Making sure the customer id is saved to the order - Instead of connecting a customer via e-mail, we use customer id (so multiple customers with same customer id use the same addresses) - In the front office order history, instead of selecting orders based on id, we select them by customer id. If there are multiple customers with the same id that have placed orders, all of these would show.
  9. Even if B2B-mode is activated, there isn't s field for customer number what I can see. The customer number (customer identification number) is the id of the customer in our Business system... this is basic stuff to have for B2B. The customer number needs to be applied on the orders also. What's the best approach here... add a custom field (somehow) or reuse the APE-field (removing validation)?
  10. Yeah I've thought in those lines too. Though choosing this method would probably change alot of other things too. How pricelists are assigned, how the order data is saved and the functions for presenting correct order history, how customer specifik products are made visable for only certain customers and so on and so on. Seems like an awful fuzz for what is standard in many other platforms (though not open source.. Magento and OpenCart has the same limitations). Thanks for your input!
  11. The multiple logins for one company (customer) is not optional (that was the first thing I tried to change). Otherwize it would be a piece of cake. One customer, one login, and if that customer has a specific pricelist, they are put in a group with that pricelist connected to it.
  12. I've re-looked at this and I still see no way to do this in Prestashop. I've considered to use one group per customer that need multiple logins for multiple personel. But that would result in an estimated 2 000 customer groups for the current customer stock our company has. I'm not sure that's even a good idea... It feels like this is the only solution for handling our customer structure in Prestashop, and it would probably result in the mother of all adminastrative tasks to keep it running smooth.
  13. Would it be fairly easy to build a module in presta that works like this. And would it be possible to make it fairly protected from future updates of the platform? First create a new column in the order table (ex. file_id). Then create a separate table (ex. file_attach). When a customer buys a certain product, that also demands a file upload before the order is complete, the file is saved on the server, and it's path and some file information is saved in the table file_attach. Then we save the id of that row in file_id in the order table. In back end, there is a module with different funktions for handling what's in the table file_attach table. The module is also accessable from the order module with a custom link of some sort, that leads you to the custom module. I hope you understand.
  14. The problem with the last thing you wrote is that one person that's involved in different regions need to have different login credentials. To ask a customer to keep track of as much as 5-10 accounts is alot to ask. These people are buyers, and sometimes they are in charge of multiple offices supply. Also, have in mind that everything must be connected, so that orders from different persons in one regional office is connected to that offices customer number.
  15. Hi there! I'm investigating platforms for a pure B2B business. I've looked at Presta 1.6 for a day or two now and I have a couple of issues that seems to be without solution as the platform sits now. - In our business we have may different pricelists, in two categories. Normal pricelists per market, and customer specifik price lists. - We also have customer specifik products, thats unique for the customer that we hold in stock. - In many cases our customers has one company, but regional offices. Each of these regions has their own customer number, the same organisationnumber, but different delivery addresses and sometimes even different invoice addreses. - There are sometimes multiple contact persons for each region that shop online with us. And there are also cases where the same contact person are connected to two different regions... and in a few cases even different companies with their own customer id. Ex. Company 1 INC in region x - Contact person 1 - Contact person 2 Company 1 INC in region y - Contact person 3 - Contact person 1 Company 2 INC in region a - Contact person 4 - Contact person 2 Worth mentioning is that our business system is the core in our busines. The e-commerce platform is the external face for our customers. My eyes are starting to wander towards other solutions.
  • Create New...