i need help please
I have a problem with the storage of a dynamic value on a journal entry applying to Vendor Bill.
I have 2 fields:
The First : not stored which is filled via a summary saved search ( ref of the vendor bill payee)
The second: a field that must take the value of the first field and store it
However my workflow that executes the set field value with the after record submit does not work because the journal entry is applied as a payment on a vendor bill. I get the following message: This journal is paying other transactions. Editing the journal will cause these payments to be unapplied. Are you sure you want to edit it?
So i don't know how to store this dynamical value .. ( script ??)
it is possible to modify a journal entry without unapplied ?
Thanks and have a nice day
Workflow to set new value ( working for other record but not for JE applying to vendor bill)
Related
I have two collections
Customers
Products
I have a field called "orders" in each of my customer document and what this "orders" field does is that it stores a reference to the product Id which was ordered by a customer, now my question is since I'm referencing product Id and if I update the "title" of that product then it will also update in the customer's order history since I can't embed each order information since a customer may order thousands of products and it can hit 16mb mark in no time so what's the fix for this. Thanks.
Create an Orders Collection
Store ID of the user who made the order
Store ID of the product bought
I understand you are looking up the value of the product from the customer entity. You will always get the latest price if you are not storing the order/price historical transactions. Because your data model is designed this way to retrieve the latest price information.
My suggestion.
Orders place with product and price always need to be stored in history entity or like order lines and not allow any process to change it so that when you look up products that customers brought you can always get the historical price and price change of the product should not affect the previous order. Two options.
Store the order history in the current collection customers (or top say 50 order lines if you don't need all of history(write additional logic to handle this)
if "option1" is not feasible due to large no. of orders think of creating an order lines transaction table and refer order line for the product brought via DBref or lookup command.
Note: it would have helped if you have given no. of transactions in each collection currently and its expected rate of growth of documents in the collection QoQ.
You have orders and products. Orders are referencing products. Your problem is that the products get updated and now your orders reference the new product. The easiest way to combat this issue is to store full data in each order. Store all the key product-related information.
The advantage is that this kind of solution is extremely easy to visualize and implement. The disadvantage is that you have a lot of repetitive data since most of your products probably don't get updated.
If you store a product update history based on timestamps, then you could solve your problem. Products are identified now by 3 fields. The product ID, active start date and active end date. Or you could configure products in this way: product ID = product ID + "Version X" and store this version against each order.
If you use dates, then you will query for the product and find the product version that was active during the time period that the order occurred. If you use versions against the product, then you will simply query the database for the particular version of the product itself. I haven't used mongoDb so I'm not sure how you would achieve this in mongoDb exactly. Naively however, you can modify the product ID to include the version as well using # as a delimiter possibly.
The advantage of this solution is that you don't store too much of extra data. Considering that products won't be updated too often, I feel like this is the ideal solution to your problem
I would like to be upfront. I am by no means an expert or even really all that technologically savy. However, I inherited a training system where the only way to find out if someone was current was to dig through physical file cabinets and try to find the hard copy. I have put together a basic access database to try and improve the situation. It is working okay, but I've run into a problem.
Previously, most training occurred in small enough batches that data entry is not a problem. (No more than 15-20 entries at any one time). However, regulatory changes now mandate the company put everyone through a mandated training course annually. This means all information about the training will be identical, except for the employee ID associated with the record.
Right now I can manually enter this training just like any other, but I have to perform this nearly identical data entry for each of the several hundred employees in the company.
I would like to be able to enter the pertinent details about the training and then have access create an training record for each employee.
The current form asks the user:
Who is the employee that was trained? (The appropriate employee ID # is entered)
Which subject was trained on? (the appropriate selection is made via combo box)
On what date was the training completed? Date picker is used to fill.
What is the file path to the scanned training certificate? (The majority of this field is prepopulated so only the actual file name needs to be typed. For the specific training in question all the employees of the company will be included in the same scanned pdf. Subsequently, this filed will be identical for all employees.)
The fields on the current form are:
txtEmpID – Text box, where employee ID # is entered. Corresponds to
field "empID"
cboTask – Combo box, where the appropriate training
subject is selected. Corresponds to field "reqID"
txtDate – Text box, the date the training was completed.
Corresponds to field "trngDate"
txtFilePath – Text box, file path to the scanned pdf of the physical
training record. Corresponds to field "trngLocat"
I would like to be able to fill in the information for 2-4 but then have access create a record, for each employee in my employees table, where all the data from 2-4 is identical.
Is this possible?
Pertinent Tables:
tblEmployees – keyed on field “empID” which is the employee number.
tblTrngSubjects - Keyed on field "reqID" which is autonumber.
tblTrngRec – keyed on field “recordID” which is autonumber. Relates
to tblEmployees through field “empID”. Relates to tblTrngSubjects
through field "reqID".
tblTrngRec is the table in which the records will be stored.
Other information that may be relevant:
I am using Access 2016.
I once had a copy of Access 2010 the missing manual…but that was in 2010. It has been almost a decade since I did anything more advanced than “docmd.openform”
I greatly appreciate any and all advice. Thanks, in advance.
I admit I haven't worked with access in quite some time, so some of the syntax might be slightly off. You need to know a list of employee IDs that were in that training.
Insert into tblTrngRec(empID,ReqID,txtDate,txtFilePath)
select empID
,25 'You need to enter this manually
,"6/9/2020" 'You need to enter this manually
,"Enter your file path"
from tblEmployees
where EmpID IN (enter a comma delimited list of employee IDs)
So I have a form I have Vendors fill out when they want to ship to us. It's an excel form that I then import into Access so I can run reports. Sometimes when they send the form back it's in a format in which I have to manually enter the data into our database.
The form looks like this:
The middle section is just for example purposes so it's a rectangle with text in it.
So everything seemed simple enough until I got to the middle section. See in my excel form I have a section for multiple PO's and units. So essentially each shipment can have one to many PO's and Units. Currently I can approach this task with the redundant method of reentering information per PO on the form. But I want to make this simple.
So the task at hand is that I want to have a form field for PO's and Units where I can input multiple lines of information so that when I hit a submit button. It appears in the database on separate lines with the same vendor information.
So if I filled out my form had this in the middle section:
PO | Units
111111 22
222222 33
333333 44
When I hit submit I want it to attach the rest of the forms information to each PO on separate lines so it'd be like:
Vendor | City | State | PO | Units
Nike Memphis TN 111111 22
Nike Memphis TN 222222 33
Nike Memphis TN 333333 44
So how would I go about accomplishing this task?
From your description of the problem and your example of how the data appears to ultimately be stored in Access it looks to me like you are using Access as a spreadsheet and not as a database. This is ok, but you might want to consider normalizing the data to take advantage of the power of databases in general.
For example:
Create a Vendors table whose sole purpose is to keep details about each Vendor you work with. A very basic implementation would have an ID field to uniquely identify each vendor and a Name field for the vendor name.
If Vendors will only ever have a single location you could also store City, State, ZipCode and Email in this same Vendor table, but I suspect having a separate VendorLocation or VendorAddress table would be a better fit long term.
Create a VendorShipment table that tracks the higher level information on your mockup, such as:
ShipmentID (primary key of this table)
VendorID (foreign key back to Vendor table)
Ready Date
Carrier
Estimated Cost
FreightClass
Tracking #
Estimated Transit Time
Finally, create a VendorShipmentDetail table that tracks the information of each shipment, including:
ShipmentDetailID (primary key of this table)
ShipmentID (foreign key back to VendorShipment table)
PO
Units
Any other details that you want to or need to track
Organizing and storing the data in a normalized fashion would ultimately help simplify your data entry \ data management process and potentially make for a better user experience.
For example, rather than having to enter the Vendor Name, Address information, etc. each time you could instead use a combo box control that is tied to the Vendor table. If the Vendor exists in the table you select it from the list and you already have the Address information, no need to re-enter it each time. If the Vendor did not already exist you enter it once (probably on a Vendor screen where you maintain the details for each Vendor) and draw upon the information in the future.
You would then use queries to tie the information back together for reporting purposes (de-normalize the information).
The art of database design can take a while to pick up, but a good starting point might be to check out the Northwind database that Microsoft has maintained over the years. It has some examples you could draw from immediately to get a practical understanding of how to use normalization within Access. You can find more information here: http://office.microsoft.com/en-us/templates/northwind-sales-web-database-TC101114818.aspx
With the main purpose of posting Tasks, displayed as either 'to-do' or 'done', how would one better structure a NoSQL DB of the following objects:
Datetime Created Not Null
Task ID Not Null
Task ID as a Str Not Null
Task Title Not Null
Task Description
Time &/or Date Due
User Not Null
ID Not Null
ID as a Str Not Null
Name Not Null
Username Not Null
Location
Contacts Count
Date Created Not Null
UTC Offset Not Null
Time Zone Not Null
Geo-Enabled Not Null
Verified
Task Count Not Null
Language Not Null
Geo-Location
Coordinates
Place
Shared with Whom
?
Task Status
Marked Done
Auto-Moved to Done (because datetime-due is passed)
Labeled (True/False)
Edited
Edit Count
Edit Datetime
Deleted
Users can post an unlimited number of Tasks, and Tasks can be shared between users. How is this relationship best captured?
Tasks can be manually 'marked done', or 'auto-labeled' and 'auto-moved-to-done' because the date-time due is passed.
Edits & Deletes are to be recorded as well.
As a starting place, what are the upsides &/or downsides of the following schema (with scalability a prime focus):
{
"created_at":"Day Mon ## 00:00:00 +0000 20##",
"id":#####,
"id_str":"#####",
"title":"This is a title",
"description":"The description goes here..",
"date_due":"Day Mon ## 00:00:00 +0000 20##",
"user":{
"id":####,
"id_str":"####",
"name":"Full Name",
"user_name":"Username",
"location":"",
"contacts_count":101,
"created_at":"Day Mon ## 00:00:00 +0000 20##",
"utc_offset":####,
"time_zone":"Country",
"geo_enabled":true,
"verified":false,
"task_count":101,
"lang":"en",
},
"geo":?,
"coordinates":?,
"place":?,
"shared_with":?,
"moved_done":false,
"marked_done":false,
"edited":false,
"deleted":false,
}
Edits & Deletes are to be recorded as well.
Do you only need to know that a task was altered, not how or by whom?
Otherwise, that will probably require versioning, i.e. for every Task there can be a number of TaskVersions. Alternatively, you could store the modification only - it depends on your needs. In particular, having many writers isn't easy because of locking - what if two people try to change the same object at 'the same time'? You might want to consider optimistic vs. pessimistic locking or mvcc. Be warned that the "Tasks can be shared between users" requirement must be designed carefully.
As a starting place, what are the upsides &/or downsides of the following schema (with scalability a prime focus):
I guess that user refers to the user who logs in. I wouldn't denormalize that information. Suppose a user created a thousand tasks and adds a new contact. Now the contacts_count of 1000 documents must be updated or it will be wrong. Denormalize only what's really necessary, e.g. the user_name.
Depending on what kind of lists you show, you can also choose to only store the user id and actually fetch the user object whenever you need to display the user name. While complex joins aren't supported, doing a $in query on, say 50 or 100 ids (like you would have to query in a list of tasks) is pretty fast.
Goal: Pull data from a SharePoint 2010 List using a WEB ENABLED form. Then, from the repeating table that contains the secondary data, extract only the desired data and mirror it in my main form fields. The extracted data would then be modified, and submitted to another sharepoint list using Nintex Workflows or, if the IT department smiles upon this project, a database.
What I've Tried: Created a field, named "TEST_CyS", in a repeating group, named "TEST", in my main form fields to store the mirrored data. This field has a default value of:
xdXDocument:GetDOM("REMOVED")/dfs:myFields/dfs:dataFields/d:SharePointListItem_RW[(count(../preceding-sibling::*[local-name() = "TEST"]) + 1)]/d:Cy_Statement
This is refreshed when the form updates.
If I set the default value to count(../preceding-sibling::*[local-name() = "TEST"]) + 1 it accurately counts each inserted group.
if I set the default value to xdXDocument:GetDOM("REMOVED")/dfs:myFields/dfs:dataFields/d:SharePointListItem_RW[<INT>])]/d:Cy_Statement where <INT> is any whole value between 1 and n then the field will display the correct information, for the secondary data field whose index is referenced.
It's when I combine the two that things fall apart.
Main Data Tree:
Secondary Data Tree:
Assumptions: I am guessing that the preceding-sibling::*[local-name() = "TEST"] axis is not returning a value due to the fact that it's being called along with the GetDOM() method. I've tried to point the preceding-sibling back to the correct group in the Main form fields, but then I felt silly for trying that as it wouldn't know where to start counting AND infopath presented me with an error:
Function 'GetDOM' did not return a value, or it returned a value that cannot be converted to an XSL data type.
Summary: Is this a lost cause without code or purchasing some "plugin" for Infopath like qRules? The IT department will not budge on allowing Forms with code in them to be run on the SharePoint site, and the requirements placed on the form state that it must be a web enabled form to be filled out in SharePoint.
Edit: We also do not have access to VSTA, and the possibility of having it installed is very, very slim.
Is there an alternative method I could use to pull this off?
SharePoint admins don't need to be involved if the InfoPath form uses code, so long as it is limited to the SharePoint 2010 sandbox APIs.