Skip to main content

Can a Stock Item be available for sale to only one customer? We have custom products that are made specific for one customer and we don’t want these available to other customers or to be accidently sold to other customers. 

@scottaisd00 Perhaps you can create the customer as a warehouse bin location and transfer items to this location. Make sure you have sales allowed unchecked as an extra precaution:

 


@scottaisd00 On top of this you could add an item pop up note which will pop up on the screen every time the item is used on an order

 


Hello,

Restriction Groups may work to create a relationship between a customer and Inventory Item(s).  Try it out in  your Test tenant first, to make sure it works as you need.

 


All great suggestions that might work on this use case but I think if you have this case often, then you will need a customization as follows:

  1. Add a bool field to inventory item indicating whether “Restricted by Customer” or not?
  1. Add a Simple Custom Tab to Costumers to Assign the “Restricted Inventory Items” to the desired customers.
  2. In your Sales Order (or any screen you want restrictions be applied) override the Inventory Item Selector to retrieve only Unrestricted Inventory Items + the Customer Specific Restricted Inventory Items.

I guess this is your foolproof go to option but of course requires customization.


  • estebanperalta54 I moved product into a new Warehouse Location via the Location Table. But when i need to sell the item to the customer, i check Allow Sales in that location, but i get error when making a shipment that says, “no items in warehouse to ship” Any ideas?


  • estebanperalta54 I moved product into a new Warehouse Location via the Location Table. But when i need to sell the item to the customer, i check Allow Sales in that location, but i get error when making a shipment that says, “no items in warehouse to ship” Any ideas?

HI @scottaisd00 

Did you move the items via Transfer? Or did you only change the location on the Item?


Hi 

scottaisd00

I would recommend using Restriction groups and restrict the item to a single customer. If you restrict by “not allowing sales” checkbox on the warehouse location then each time you want to sell the item then you need to do an inventory transfer from that location to another location where sales are allowed. This will add additional work.


Curious about @aaghaei’s idea and if anyone has a customization in place to accomplish this?  If so, i’m interested in meeting with you.

@scottaisd00, please try the Restriction Groups idea and see if this meets your needs.  


I would like to try the solution of Restriction Group for Items to a single customer. What would be best way for me to learn the steps for this action? 


Hello,

Restriction Groups may work to create a relationship between a customer and Inventory Item(s).  Try it out in  your Test tenant first, to make sure it works as you need.

 

Hello,

Step 1 is shown above. Give your group a name, Select Entity Type “Inventory Item.” Check the box at left, to include the custom inventory item for your customer.  Save.

Step 2: change the Entity type to Customer.  Check the box at left, to include the customer in the same group with their item. Save.

Test.

If the above steps work fine in your testing then repeat the Restriction Group in Live. Good luck!


  • Laura02

  • i followed your steps and did the Apply Restriction Settings to All Items.

  • Didn’t work. Still lets me sell items to all customers. Any ideas what to try next?


 


I am disappointed; I have used Restriction Groups successfully before, but not for Customer-Stock Item combinations specifically.  I wonder whether it is a ‘bug’.  Maybe a support ticket to ask about a possible bug?

Otherwise, it seems like the only option left is to customize as aaghaei mentioned.


Guys, I might be wrong but I guess there is a misunderstanding about the “Restriction Groups”.

 

My understanding is RGs are meant to restrict a “User” Access to entities like “Projects”, “Stock Items”, and … not cross-reference “Entities” Access to each other. If you open up the “Project Access” screen it is very clear and the same logic applies to the “Neighbour Entities” as per Acumatica terminology. In the PM Access you can clearly see you have a “RelationGroup” which is the form header, A tab for “Projects” which is tied to this Group, and another tab indicating who has access to the selected “Projects” as per the “GroupType” settings.

 

This logic applies to all other Entities to the best of my knowledge. For example, in your last screenshot you have a group (you can name it whatever doesn’t have any impact in your case “Josh Lewis Games”) then once you are selecting “Inventory Items” Entity and related stock items. One more time you are selecting “Customer” Entity and the associated customers. I assume that you have selected the “User” Entity type here as well and have identified the users who are part of this Group.

 

Now considering your Group Type is “A” then in fact you are telling the system that the associated user to this group has access to the selected customers and selected inventory items. You are not telling the system that the selected customers are allowed to purchase the selected inventory items.

 

This is how Acumatica determines whether a user has access to a RelationGroup Neighbor Entities or not. This is for Projects but the same validation goes to other entities as far as I know.

 

RelationGroup.SpecificModule == null or 
RelationGroup.SpecificModule == typeof(PMProject).Namespace or PX.SM.UserAccess.IsIncluded(EntityGroupMask, RelationGroup)

// The code is not like this. I just put it like this for presentation purposes

 

To me it all perfectly makes sense. As mentioned in my first response, the only possible way for the aggregated restriction I believe is customization. 

 

I guess there are some exceptions like Company, GL Account, and Subaccount … but I don’t believe all entities can be used as mish-mash together.


Here we go. I found the help document on it. As you can see User always is on one side and given entities on another side. As mentioned the only exception I am aware of it is Company/Branch, Account, and Subaccount.

 


Yes!  You are teaching me today Reza. 

I did think in the Restriction Groups screen we can connect many entities -->because they exist 😉 in the list and because the system lets me choose them together with no message.  I didn’t try it; as you know,  sometimes I run out of time to test every answer here in the community.  I’m not a developer so I don’t have access to or understand the code that is posted.

If we add Users to the Restriction Group I suggested, will the combination of User-Customer-Inventory ID help Scott to solve  his question?

Thank you!

 

Laura


I am still thinking about this question, and I think I can answer my own question: If we add Users to the Restriction Group I suggested,  Scott’s question is not solved, because he’ll need multiple restriction groups by customer and then, his employees will be in all groups and will see all customers anyway.

 

I am still disappointed; it would be really cool if Customer-Item restriction groups could work like they did in my imagination.  I’m hopeful Dana is asking because Acumatica is considering adding this feature. :-) 

 

One related idea we can vote for:

 


@Laura02 i have a Product Backlog Item for the idea that you referenced and have conducted several customer interviews on this topic to limit the sale/selection of items.  There could be regulatory requirements (ie. cannot sell/ship product to a certain geography, hazmat item requires certain carrier service), business policy requirements (target marketing - doesn’t make sense to sell the item to a certain geography/class of customers). 

If community members, would like to meet with me to provide additional input, please indicate your interest here.

-Dana


P.S.  I am still interested in seeing any customizations, if there are any out there!  -Dana


I am interested in this feature.  


Yes!  You are teaching me today Reza. 

I did think in the Restriction Groups screen we can connect many entities -->because they exist 😉 in the list and because the system lets me choose them together with no message.  I didn’t try it; as you know,  sometimes I run out of time to test every answer here in the community.  I’m not a developer so I don’t have access to or understand the code that is posted.

If we add Users to the Restriction Group I suggested, will the combination of User-Customer-Inventory ID help Scott to solve  his question?

Thank you!

 

Laura

we all collectively learn from each other every day.
 

If you mean using exiting functionality then No but if you mean developing new feature, then apparently this client doesn’t care who creates the invoice they just want to mix customer/inventory item entity. In fact user SHOULD NOT be a part of equation at all.

To me this is a way bigger discussion because maybe another client need to include Sales Person in equation and combine 3 entries. Or another client some other mixed or maybe mixing and combining more entities.

if Acumatica wants to rethink about the engine I believe it needs structural redesign. As an idea, for example when we create. Restriction Group, there could be grid in the header that shows list of entities with ✅ option that user selects the entities willing to combine.

but as mentioned this has structural impact as I believe Acumatica then will need to platform wise revise all “Match<>” functions which are countless. 
I am just a volunteer on community and do not have a say what Acumatica decides to implement at the end and you guys will decide though.


I was able to solve my problem using Restriction Groups.

Since I am the Salesperson for this account and the Items to restrict should only ever be sold to this one account, I made the restriction relationship between the Items and the User, me (as recommended by Reza above). I also put non-salesperson users in this group, so our buyer, etc… can see these items.

This is an elegant solution for us. I greatly appreciate everyone’s input and help.


Thank you all for your help.  This Restricted feature solved our issue.


@scottaisd00, we have similar requirements to what you had few months ago.  I am glad you could solve the problem. 

Could please let me know steps to accomplish the goal of “Making a Stock Item available to only one customer”.  I am assuming you are not able to create sales orders to customers who are not in the restricted group. 

Following is what I did:

I created a restriction group similar to you, having Items, Users and Customers.  It works in restricting the visibility of the items and customers entities to the users in the restricted group only.  The issue is, if anyone in the restricted group tries to sell an item (in the restricted group) to a customer who is not in the restricted group it lets them enter sales order for the item.  in other words, if I am in the restricted group Iam able to sell any customer who are not in the restricted group.


@Laura02 i have a Product Backlog Item for the idea that you referenced and have conducted several customer interviews on this topic to limit the sale/selection of items.  There could be regulatory requirements (ie. cannot sell/ship product to a certain geography, hazmat item requires certain carrier service), business policy requirements (target marketing - doesn’t make sense to sell the item to a certain geography/class of customers). 

If community members, would like to meet with me to provide additional input, please indicate your interest here.

-Dana

Hi @Dana Moffat,
Was any progress made on this? I would be happy to join an interview or exchange emails.
Our need is to reserve stock to be sold specific customers, while sales would be restricted to everyone else.
What would solve this easily is if warehouse locations were on option in restriction groups. This way we could received the desired qty into a specific location, and put that location in a group with the desired customers. However currently only warehouse as a whole is available as a restriction entity.

We can work with a pretty broad set of criteria - it can be restricted by user, sales person, customer, customer class or branch.

 

 


Reply